Authoring Use Cases (Filled and Focused)

1. Authoring Use Cases (Filled and Focused) from Use Case Modeling, by Bittner and Spence, Chapters 4, 6, and 7

2. Introduction • Know that Use Cases represent / can capture the functional requirements of an application. • Know that there are ‘levels of maturity’ of Use Cases. • Know about Façade Use Cases and • Know about the use of a template. • Let’s continue. Here is our template… • and we know different organizations will likely require different formats, attributes…

5. Façade Use Cases • Placeholders • Help to establish a framework for further maturity development • Help to establish application boundary • Contain a number of attributes, but no basic course of events is included. • Now we address the paths…

6. Outline the Use Case • Difficult to assess the complexity of some use cases from sources of description • Use Cases can be a short as half a page to as long as a number of pages – required to capture both the basic and alternative flows in a form that satisfies ALL of the stakeholders.

7. 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! • Enumerate the alternate flows as A1, A2, etc. - just outlining here. Will undertake the real use case authoring shortly. • Example:

8. Sample Outline • The initial outline for use case, Withdraw Money in an ATM system could be: • Basic Flow (Outline format) • Insert Card • Validate 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 • A1. Card cannot be identified • A2. Customer cannot be identified • A3. Withdraw not required • A4. Non-standard amount required • A5. No money in the account • A6. Attempt to withdraw more than daily amount • A7. No connection to the banking system • A8. Link goes down • A9. Card stolen – the card is on the hot-card list • A10. The ATM is out of money • A11. The card cannot be dispensed • A12. A receipt is required • A13. The withdrawal is not from the card’s primary account • etc.

9. Sample Outline - Comments • Can see from outline format some decisions might be made regarding core functionalities and what is extra, or complementary functionality. • E.g. If receipt is always required, A12 is NOT an alternate flow (found in basic flow). • Also shows some non-essential flows (like withdrawing from other accounts than primary) Might not be needed. • Trace the use cases back to business rules, features, constraints, …

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 selected items and quantities, reserving them in the inventory Provide payment instructions Record payment instructions capturing payment terms and credit card type, number and expiration date using secure protocol Provide shipping instructions record shipping instructions, capturing billing address, shipping address preferences, and delivery options Complete transaction 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.

11. 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. Styles – a short list… • Outline formats • Conversational Format (illustrated) • Narrative formats in sentence format • The user …. • The system …. • 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. • There are other formats too, naturally…

13. Incidentally, Bittner and Spence: (their maturity levels • Discovered • Briefly Described • Bulleted Outline • Essential Outline • Detailed Description • Fully Described….

14. Flows in Use Cases • Many and varied. • Called different things by different authors. • Doesn’t really matter what they are called as long as they are captured and are understandable by all stakeholders.

15. Subflows, Extension Points, Alternate Behaviors • Some Use Cases are just complex and long – and we need to remove some of the complexity and break it up into more manageable segments. (Subflows) • We may abstract these parts out of basic flow. • Some use cases have behaviors that are executed conditionally. (Alternate / Exceptions) • Some use cases need to be able to insert additional placeholders, bound statements, or alternate behaviors that are not necessarily “conditional.” • We also need a syntax for indicating WHERE in the flow of events, these other behaviors are associated, inserted, referenced, etc. (Extension Points). • Essential thinking for mature use cases. • Let’s look at these…

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

17. Subflow Examples • Within the body of the flow of events, one might see: … 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 might be: … Perform Subflow Login …. • In this case, Login is not a use case…

18. Sample Subflow Narrative (3 of 4) • Subflow: S1 Login • When the user enters the system for the first time, the system • prompts them for the password • 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.’ • a. 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 matches, the user is granted access to the • system and the use case continues  note this; return otherwise, • the system reports that the password is incorrect.

19. Subflows - more • Must be documented as a flow of events. • Notice: “Perform” or “Do”…. • Like a subroutine / subprogram ‘call.’ • Captures specific functionality…

20. Extension Points (1 of 6) • 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.

21. Extension Points - Continued • No specific naming conventions for extension points. • The named extension point should sum up some aspect of where the position is in the use case such as {Process Order} or what the use case has achieved. {Order Processed} • 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.

22. Extension Points – Continued (3 of 6) • Three kinds of extension points • A single location – here, it defines a single point in the flow of events (insert behavior) • May be used to define a ‘state’ that the flow of events is in. (May appear multiple times) • May delineate a range of activities. • Examples: (next two slides)

23. Use Case Including Extension Points (4 of 6) • (In the flow of events) • The use case starts when the actor Customer selects to browse the • catalog of product offerings (note glossary indicator….) • {Display Product Catalog}(note, on a line by itself) e.g.2 • 2. The system displays the product offerings highlighting the product • categories associated with the Customer’s profile. • {Select Products}shows the state the flow is in. e.g 2 • The Customer selects a product to be purchased, entering the • number of items required. • For each 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} will address ahead e.g. 1 • Steps 3 and 4 are repeated until the Customer selects to order • the products. • {Process the Order}shows the state the flow is in. • The system prompts the Customer to enter payment instructions.….

24. Use Case Including Extension Points (5 of 6) (In the flow of events) Note the {Out of Stock}. This can 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. {Out of Stock} //additional behavior could be placed in here or referenced from here… (see slides on Alternatives/Exception) 5. Steps 3 and 4 are repeated until the Customer selects to order the products. …

25. Example of Extension Point (6 of 6) • 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} … and {pump deactivated}.

26. Alternate and Exception Behaviors (1 of 6) • Note: These are alternate or exceptional behaviors. • Always dependent upon some condition occurring at an explicit point in another flow of events. • Alternate / Exceptional Flows are conditional flows! • May be absolutely essential flows basic to the Use Case • May be Errors – also important to the Use Case. • Can use ‘step’ references • Other mechanisms…

27. Alternate / Exception Flows (2 of 6) • Three kinds: • 1. Specific Alternate Flow • Can start at a specific named point in another flow of events (public reference) • 2. General Alternate Flow • Can start at any point within a use case • 3. Bounded Alternate Flow • Like the general flow, but can only occur between two named points. • First, the syntax for alternative flows…

28. General Syntax for Alternative Flows (3 of 6) • Alternative (and exception) flows are named and numbered. • Can number the alternative flows A1…An and give them names that sums their purpose. • The first line of the alternative flow’s flow of events identifies the point at which the alternative will be activated and the conditions under which it will occur. • This clause is always of the form: At {extension point} when <some event occurs>…or At {extension point} if <some event occurs> • (Can name these in Extension Points attribute) e.g. {Funds Not Available in Checking Account}

29. General Syntax for Alternative Flows (4 of 6) • The last line of the alternate flow and any other exit points within it must state explicitly where the actor resumes the flow of events! • Will be where original extension point was triggered, or • Another extension point elsewhere in the flow of events – unless the use case ends. • If behavior is optional, return is normally to the original extension point • For ‘exceptional’ (e.g. error condition) behavior, return may be to the end of the use case • (If use case ends in the alternative flow, then an explicit ‘use case ends here’ needs to be included.)

30. Examples of specific alternate flow (5 of 6) • A3. Product Out of Stock • Could indicate this in Extension Points attribute. At {Out of Stock}, if there are insufficient amounts of the product in the inventory to fulfill the Customer request The system informs the user that the order cannot be fulfilled … the flow continues to describe the offering of alternative amounts and products to the customer The flow of events is resumed from the point at which it was interrupted.

31. Example of a Bounded Alternate Flow • A1. Undertake a Keyword Search • Documentation: At any point between {Display Product Catalog} and {Process Order}, when the Customer selects to undertake a keyword search The system prompts the Customer to enter the product search criteria The Customer enters the product search criteria …the flow continues to describe what the Customer and the System do to complete the search… The flow of events is resumed at {Select Product}

32. Summary • So, there is no ‘one style fits all.’ • Remember: the most important thing – by far – is to be certain to capture and document all the required functionality. • Ensure sufficient detail is present to support follow-on design. • All the ‘whats’ must be addressed.