1 / 19

2.2. Use Cases: Scenario based requirements modeling

2.2. Use Cases: Scenario based requirements modeling. Recommended: Booch, Rumbaugh, Jacobson: The Unified Modeling Language User Guide . Addison Wesley, 1999. Use Case (1). Specifies the intended behavior (the “what?”) of a system.

Download Presentation

2.2. Use Cases: Scenario based requirements modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related