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

2. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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.

3. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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 Process loan Loan Officer Actor Use case

4. CPSC 333: Foundations of Software EngineeringJ. Denzinger Use Case Example Name: Capture deal Precondition: Financial Officer is logged in Main 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 Client Financial Officer Capture deal

5. CPSC 333: Foundations of Software EngineeringJ. Denzinger Use cases: terms and concepts Unique name e.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

6. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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)

7. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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) Officer Loan Officer specialization relationship

8. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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

9. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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 Check password Retinal scan

10. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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 Validat e client Place order > Trac k order >

11. CPSC 333: Foundations of Software EngineeringJ. Denzinger “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,…

12. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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) > (set priority) Place order Extension points: Set priority Place rush order

13. CPSC 333: Foundations of Software EngineeringJ. Denzinger “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

14. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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

15. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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

16. CPSC 333: Foundations of Software EngineeringJ. Denzinger A use case diagram Valuatio n Limit exceeded Analyz e risks > Trader Price detail s > Capture deal > Sales person

17. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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)

18. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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

19. CPSC 333: Foundations of Software EngineeringJ. Denzinger 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!