2.2. Use Cases: Scenario based requirements modeling

1. 2.2. Use Cases: Scenario based requirements modeling • Recommended: Booch, Rumbaugh, Jacobson: The Unified Modeling Language User Guide.Addison Wesley, 1999 CPSC 333: Foundations of Software Engineering J. Denzinger

2. Use Case (1) • Specifies the intended behavior (the “what?”) of a system. • Is a set of sequences of actions (including variants) to yield an observable result of value to an actor. • Represents a functional requirement of the system as a whole. Used to • describe customer requirements (early analysis). • Validate your architecture / verify your system. CPSC 333: Foundations of Software Engineering J. Denzinger

3. Actor Use Case (2) • Each sequence (also called a scenario) represents the interaction of things outside the system (its actors) with the system itself (or parts of the system). • Separate main vs. alternative flows Use case Process loan Loan Officer CPSC 333: Foundations of Software Engineering J. Denzinger

4. Use Case Example Client Capture deal FinancialOfficer • Name: Capture deal • Precondition: Financial Officer is logged inMain flow of events: 1. Enter the client name & bank account 2. Check that they are valid 3. Enter number of shares to buy & share ID 4. Determine price 5. Check limit 6. Prepare order to NYSE 7. Store confirmation number and give it to client CPSC 333: Foundations of Software Engineering J. Denzinger

5. Use cases: terms and concepts • Unique namee.g.: “Place order”, “Validate user” • Sequence of actions (event flows) • textual (informal, formal, semi formal) Main flow of events: The use case starts when the system prompts the Customer for a PIN number. The Customer can now enter a pin number... Exceptional flow of events: If the Customer enters am invalid PIN number… • interaction diagrams CPSC 333: Foundations of Software Engineering J. Denzinger

6. Actors • Role that a human/hardware device/another system plays with respect to the system • Actors carry out use cases • look for actors, then their use cases • Actors do not need to be humans! • Actors can get value from the use case (Client in example) or participate in it (Financial Officer in example) CPSC 333: Foundations of Software Engineering J. Denzinger

7. Officer Loan Officer Actors • Actors can be specialized • connected to use cases only by association • association = communication relationship (both can send messages to, or receive messages from the other one) specialization relationship CPSC 333: Foundations of Software Engineering J. Denzinger

8. Use case description • Generic, step-by-step written description of a use case’s event flow • Describe precondition (initial system state) • List sequence of steps • Includes interactions with actor(s), and describes what objects are exchanged • May contain extension points • Clear, precise, short descriptions CPSC 333: Foundations of Software Engineering J. Denzinger

9. Organizing Use Cases: Generalization relationship • child use case inherits behavior and meaning of the parent use case • child may add or override the parent’s behavior • child may be substituted any place the parent appears Validate client Retinal scan Check password CPSC 333: Foundations of Software Engineering J. Denzinger

10. Organizing Use Cases: “Include” relationship • Used to avoid describing the same flow of events several times, by putting the common behavior in a use case of its own • Avoids copy & paste of parts of use case descriptions <<include>> Validate client Place order <<include>> Track order CPSC 333: Foundations of Software Engineering J. Denzinger

11. “Include” Example Use Case: Track order Precondition: Financial Officer is logged in Main flow: 1. Obtain and verify order number 2. Include (Validate client) 3. For each part in the order,… CPSC 333: Foundations of Software Engineering J. Denzinger

12. Organizing Use Cases: “Extend” relationship • Allows to model the part of a use case the user may see as optional • Allows to model conditional subflows • Allows to insert subflows at a certain point, governed by actor interaction • extension points (in textual event flows) Place orderExtension points: Set priority <<extend>> (set priority) Place rush order CPSC 333: Foundations of Software Engineering J. Denzinger

13. “Extend” Example Use Case: Place order Precondition: Financial Officer is logged in Main flow: 1. … 2. Collect the client’s order items 3. (set priority) 4. Submit order for processing CPSC 333: Foundations of Software Engineering J. Denzinger

14. Using “Extends” relationship • Capture the base use case if we later delete extension points, we still have to have a use case achieving something! • For every step ask • - what could go wrong? • - how might this work out differently? • Plot every variation as an extension of the use case CPSC 333: Foundations of Software Engineering J. Denzinger

15. Comparing extends/includes • Different intent • extend • to distinguish variants • associated actors perform use case and all extensions • actor is linked to “base” case • include • to extract common behavior • often no actor associated with the common use case • different actors for “caller” use cases possible CPSC 333: Foundations of Software Engineering J. Denzinger

16. A use case diagram <<include>> Valuation Analyze risks <<include>> Price details Trader Capture deal Sales person Limit exceeded <<extends>> CPSC 333: Foundations of Software Engineering J. Denzinger

17. Properties of use cases • Granularity: fine or coarse • Achieve a discrete goal • Use cases describe externally required functionality • Often: Capture user-visible function • Serve as basis for testing (see later) CPSC 333: Foundations of Software Engineering J. Denzinger

18. When and how When: • Requirements capture - first thing to do How: • Use case: Every discrete thing your customer wants to do with the system • give it a name • describe it shortly (some paragraphs) • add details later CPSC 333: Foundations of Software Engineering J. Denzinger

19. Recipe • Identify actors that interact with the system • Organize actors • Consider primary ways of interaction with actors • Consider exceptional ways • Organize behaviors as use cases, using generalize/include/extend relationships • Describe what actors require from system, not what goes on in the system! CPSC 333: Foundations of Software Engineering J. Denzinger