Authoring Use Cases from Use Case Modeling by

Authoring Use Cases from Use Case Modeling, by Bittner and Spence, Chapters 4, 6, and 7 1

Outline the Use Case • Use Cases can be: • a short as half a page to • as long as a number of pages • Whatever is required to capture both the basic and alternative flows in a form that satisfies ALL of the stakeholders. • If at all possible, abstract out some of the details (glossary; domain model; subflows, include and extend use-cases). • KISS. 6

Start off with an Outline of Use Case • Start off with the Use Case name, a brief description of the use case and identify actors (persons, systems, …) • Identify the basic flow of events as steps. • �Walk through these! This is an art! • Enumerate the alternate flows as A 1, A 2, etc. • just an outline here. • Will undertake the real use case authoring shortly. • Example: 7

Sample Outline – Withdraw Money • Basic Flow (Outline format) • Insert Card • Validate Bank Customer • Select Withdraw • Select Amount from List of Standard Amounts • Confirm Transaction with Banking System • Dispense Money • Eject Card • List of Alternate Flows • A 1. Card cannot be identified • A 2. Customer cannot be identified • A 3. Withdraw not required • A 4. Non-standard amount required • A 5. No money in the account • A 6. Attempt to withdraw more than daily amount • A 7. No connection to the banking system • A 8. Link goes down • A 9. Card stolen – the card is on the hot-card list • A 10. The ATM is out of money • A 11. The card cannot be dispensed • A 12. A receipt is required • A 13. The withdrawal is not from the card’s primary account • � etc. 8

Sample Outline - Comments • Can see from outline format • some are core functionalities • some are extra, or complementary functions • e. g. If receipt is always required, A 12 is NOT an alternate flow (found in basic flow). • some are non-essential flows (like withdrawing from other accounts than primary) • Might not be needed. • Must be able to Trace the use cases back to business rules, features, constraints, … • Don’t create requirements that do not trace back to required features! 9

There a number of other Use Case Styles 10

Sample Conversational Form User Action System Response . . . Display product offerings showing categories selected by user Browse product offerings Select items for purchase For each selected item in stock record select items and quantities, reserving them in the inventory Prompt for payment instructions Provide payment instructions Record payment instructions capturing payment terms and credit card type, number and expiration date using secure protocol Prompt for shipping instructions Provide shipping instructions Record shipping instructions, capturing billing address, shipping address preferences, and delivery options Complete transaction 11 Record transaction and provide receipt containing a list of the products ordered, their quantity and prices as well as payment terms. Credit card information should be partially omitted, displaying only the last four digits of the cc number.

Comments – on Conversational Style • Good for single actor; where system/actor engage in interactive dialog. • Can contain a lot of detail – good – but this can become a liability. • Not good for capturing a number of actors • Not good for complex responses, like controlling an antilock braking system. 12

A Short List of Styles • Outline formats – extremely cryptic. • Conversational Format (shown) • Narrative formats in sentence format • • • The user …. • The system… • The user…. (almost like prose) Flexible format; can show multiple actions and actors. Supports ongoing evolution of use case and use of subflows…. � Often the preferred format for complex systems. This one is our choice… • There are other formats too, naturally… 13

Sample “Maturity Levels” � • Bittner and Spence: • • • Discovered Briefly Described Bulleted Outline Essential Outline Detailed Description Fully Described…. • Kulak and Guiney: • • Façade Filled Focused Finished (eliminated this one in latest book) • Other authors: other ‘maturity levels. ’ 14

Flows in Use Cases • • Many and varied. ‘Captured’ differently by different authors. Called different things by different authors. Doesn’t really matter what they are called as long as the alternate flows (all kinds) are indeed captured and understandable by all stakeholders. 15

Subflows, Alternate Behaviors, Extension Points • Subflows: Some Use Cases are simply just complex and long. • It is often best to remove some of the detail and/or complexity (factor it out), and • Break it up into more manageable segments. (Subflows) • We may abstract these parts out of basic flow. • This means we put some kind of note or designator or some kind of tag or notation into the flow to indicate that another segment ‘goes here. ’ 16

Subflows, Alternate Behaviors, Extension Points • Alternate Behaviors: Some use cases need to capture and insert alternate behaviors that are not necessarily “conditional, ” but ‘may’ be… ) (Alternates) • Paths that are perhaps just not quite as likely as the Basic Course of Events, but still viable paths! • E. g. Withdraw money from savings account vice checking. • Not ‘happy path’ but still quite commonly done. • Exceptional Behaviors: Some use cases have behaviors that are executed conditionally. (Exceptions) • especially error conditions – would be executed if some kind of unexpected condition occurs. • Some people call things like – not enough money in account as an exception; others might call this an alternative. 17

Subflows, Alternate Behaviors Extension Points • Extension Points: Some use cases have the need be able to insert additional placeholders, to • to bound statements, or • to tag alternate behaviors that may/may not be “conditional. ” • Also need a syntax for indicating WHERE in the flow of events, these other behaviors inserted, referenced, etc. (Extension Points). • Further, upon ‘branching’ to these behaviors, we need to be able to unambiguously indicate where the return, if any, should be. • • Essential thinking for mature use cases. Let’s look at these in more detail… 18

Subflows (1 of 4) • Subflows are often used • for complex use cases. • to break down the complexity of some use cases. • Different authors have different styles… • Normally (not always) a subflow may be given a tag of S 1 (, …, Sn) and/or a name. • Subflows are documented separately rather than inserting text in line …and cluttering basic flow. • Executions are atomic. • Use Case can ‘perform’ subflows in optional sequences or in loops or even several at a time. • Abstracting in ‘higher level flow’ greatly assists ‘complexity. ’ 19

Subflow Examples (2 of 6) • Within the body of the flow of events, one might see the specification: The system captures the payment instructions using a secure prototcol Perform Subflow Validate Payment Instructions The system prompts the Customer to enter shipping instructions The system captures the shipping instructions using a secure protocol Perform Subflow Validate Shipping Instructions … • Another example within the body of the flow of events: The client logs into the application Perform Subflow S 1 Login …. • (In this case, Login is not an “included” use case…) 20

Sample Subflow Login Narrative (3 of 4) Subflow: S 1 Login 1. When the user enters the system for the first time, the system prompts the user for a password 2. The user enters this password (the system echos only ‘*’ characters to the screen as they do so). When the user indicates (note: no implementation details…) completion of entering the password, the system compares the password to the one associated with the user’s profile. • If the password matches, the user is granted access to the system and the use case continues � note this…we’d ‘return. ’ If the user does not enter the correct password the system reports that the password is incorrect i. The user is given two additional opportunities to enter the correct password ii. If the user fails to enter a correct password in three attempts, the system logs the failure attempt date and time along with the user profile and the user is logged off the system b. If the password finally matches, the user is granted access to the system and the use case continues � note this; return otherwise, 21 the system reports that the password is incorrect.

Subflows – more (4 of 4) • • • Must be documented as a flow of events. Notice: “Perform” or “Do”…. Like a subroutine / subprogram ‘call. ’ Captures specific functionality… A great way to reduce complexity and clutter and yet keep essential functionality. 22

Extension Points (1 of 7) • Extension Points are named places in the flow of events where additional behavior can be inserted or attached. • May be ‘private’ (used only in the user case in which they appear) or ‘public’ (used by other extending use cases). • Can be found anywhere in flow of events. • Within a flow of events, extension points are shown in bold and enclosed in curly brackets (braces) • Example: {Display Product Catalog}, {Out of Stock}, {Process the Order}, and {Order Processed}. • These extension points are normally included as text in the Extension Point attribute of a standard Use Case template. 23

Extension Points – (2 of 7) • There are no specific naming conventions for extension points. • The named extension point should sum up or capture some aspect of where the position is in the use case such as {Process Order} or what the use case has achieved, such as, {Order Processed} (like a ‘comment’) • Extension Point is like a ‘tag’ or ‘label’ • While the extension point can normally occur anywhere in flow of events, it is best implemented when placed on their own line and not embedded in a chunk of text. 24

Extension Points – (3 of 7) • Three kinds of extension points • 1. A single location – here, it defines a single point in the flow of events (inserted behavior) • 2. May be used to define a ‘state’ that the flow of events is in. (May appear multiple times) • 3. May delineate a range of activities, that is, mark off a set of activities (begin…end) • Examples: (next two slides) 25

Use Case Including Extension Points (4 of 7) (In the flow of events) 1. The use case starts when the actor Customer selects to browse the catalog of product offerings {Display Product Catalog} (Note that this is: on a line by itself, and is an example of the ‘state’ the use case is in… and is an example of type 2 (see previous slide)). Next interchange shows this. 2. The system displays the product offerings highlighting the product categories associated with the Customer’s profile. {Select Products} (Note again, an example of type 2: shows the state the flow is in. ) Actor is selecting products… 26

Use Case Including Extension Points (5 of 7) (In the flow of events) – Continuing… 3. The Customer selects a product to be purchased, entering the number of items required. 4. For each (note: implies iterative behaviors) selected item that is in stock, the system records the product identifier and the number of items required, reserving them in the inventory and adding them to the Customer’s shopping cart. {Out of Stock} (This is an example of type 1 extension point. Behavior can be placed here or ahead…addressed ahead) 4. Steps 3 and 4 are repeated until the Customer selects to Order the Products. {Process the Order} (Again, shows the state the flow is in. type 2) • The system prompts the Customer to enter payment 27 instructions. ….

Use Case Including Extension Points (6 of 7) (In the flow of events) Recall the {Out of Stock} extension point: The extension point may be placed in multiple places in the flow of events if there were/are multiple places where the use case is dependent on the system not being out of stock. In this case, the behaviors would be documented separately – perhaps at the end of the use case. Or {Out of Stock} //additional behavior could be placed in here in line if the condition only appears once (style). Clearly the reference would be preferred to inline behavior if the condition appears multiple times. 28

Example of Extension Point (7 of 7) • And…example of the third kind: In a use case for a system that controls a pump to dispense fuel, you could delimit the section of the flow of events where fuel is being dispensed with extension points: {pump activated} … … {pump deactivated} 29