1. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Use Cases Descriptions and Use Case Models

2. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2 Objectives  To explain what use case descriptions are  To specify the contents of use case descriptions  To present a use case description writing process  To present heuristics for use case descriptions  To explain the relationship between use cases and requirements  To explain what use case models are  To explain how to design with use case models  To outline how to use use cases in iterative development

3. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 3 Topics  Use case descriptions, their formats, and their contents  Writing use case descriptions  Use case description heuristics  Use case descriptions and requirements  Use case models  Designing with use case models  Use-case-driven iterative development

4. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 4 Use Case Descriptions A use case description is a specification of the interaction between a product and the actors in a use case.  What each party does  The order in which each party acts  All possible courses of interaction: complex activity flows

5. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 5 Use Case Description Contents 1  Use case name and number  Actors  Stakeholders and their needs  Preconditions—A precondition is an assertion that must be true when an activity or operation begins. Not checked by the use case  Postconditions—A postcondition is an assertion of what must be true when an activity or operation ends. Must satisfy stakeholder needs

6. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 6 Use Case Description Contents 2  Trigger—A trigger is an event that causes a use case to begin. May be the first step in the use case  Basic flow An action flow: a list of steps Documents a standard, successful interaction Begins at the trigger, continues until the use case ends  Extensions Alternative action flows May begin and end anywhere Extensions may have extensions

7. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7 Car Wash Example – Part 1 Use Case 2: Activate/Deactivate Actors: Soap sensor Stakeholders and needs: Customers—Need their cars washed with soap, and want a complete wash Operations—Want the carwash to operate without constant attention Preconditions: None Postconditions: The carwash is active if and only if the soap sensor indicates that there is soap. No wash currently in progress is interrupted.

8. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 8 Car Wash Example – Part 2 Trigger: One minute has passed since the last time the soap sensor was checked. Basic Flow: 1.The carwash queries the soap sensor. 2.The soap sensor indicates that there is soap. 3.If the carwash is active, it continues its operation and the use case ends. Extensions: 1a: The carwash is unable to query the soap sensor: 1a1. The controller logs the problem and the use case ends.

9. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 9 Car Wash Example – Part 3 Extensions (continued): 2a: The soap sensor indicates that there is no more soap: 2a1. If the carwash is inactive, the use case ends. 2a2. If the carwash is active, the controller displays an out-of- order message and becomes inactive; the use case ends. 2b: The soap sensor does not respond: 2b1. The controller logs the problem. 2b2. If the carwash is inactive, the use case ends. 2b3. If the carwash is active, the controller displays an out-of- order message and becomes inactive; the use case ends. 2a2, 2b3: A wash is in progress: 2a21. The carwash completes the current wash, then displays an out-of-order message; the use case ends. 3a: The carwash is inactive: 3a1. The carwash becomes active and displays a ready message.

10. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 10 Use Case Description Formats  Many alternatives  “Fully-dressed” format  Underlined text refers to another use case.  Extensions use a special numbering scheme: Numbers are for action step sequencing; Letters are for extension triggers; Extension identifiers have interleaved numbers and letters; An asterisk refers to all action steps; A dash is used for ranges of action steps; A comma separates action steps in a list.

11. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 11 Use Case Description Template Use Case number: name Actors: actorList Stakeholders and Needs: stakeholder—needsList. … stakeholder—needsList. Preconditions: what is assumed at the start. Postconditions: what is guaranteed at the end. Trigger: the event that starts the use case. Basic Flow: # stepDescription … Extensions: extensionIdentifier condition: extensionIdentifier # stepDescription … …

12. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 12 Description Writing Process

13. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 13 Filling in the Initial Fields  Stakeholders are human use case actors or anyone with an interest to protect.  Only state things that really matter as use case preconditions.  Postconditions must be true when the use case ends whether it is successful or not.  The trigger is often the first step in the use case (but not always).

14. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 14 Writing the Basic Flow 1  Choose a common, simple activity flow.  Trace it from the trigger through use case completion.  Scenarios are often good resources.

15. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 15 Writing the Basic Flow 2  Steps may assume the preconditions and should achieve the postconditions.  Each step should state an action of a single agent (the product or an actor).  Supplemental directions about conditions, iteration, or currency are allowed.

16. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 16 Brainstorming Branch Points  A branch point is a place where the action flow may diverge.  Brainstorm a list of branch points and failure conditions. Look at scenarios for failed or alternative interactions. Consider errors, faults, and alternatives at every step. Don’t forget an actor’s failure to act.

17. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 17 Rationalizing Branch Points  Remove from further considerations any conditions that the product Cannot detect Cannot do anything about  Rewrite poorly stated conditions

18. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 18 Writing Extensions  Treat an extension as if it were a separate use case: The condition is the trigger; Extension steps are the basic flow; Completing the use case or returning to the branch point are the goals.  Scenarios are a good resource.  Repeat the extension writing process for the extension (extensions may have extensions).

19. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 19 Use Case Description Heuristics 1  Fill in the use case template from top to bottom.  Obtain use case and actor names from the use case diagram.  Make human actors stakeholders whose needs include completion of the task done by the use case.  Write simple declarative sentences in the active voice.

20. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 20 Use Case Description Heuristics 2  Make actors or the the product the subject of each step description.  Write a basic flow with three to nine steps.  Avoid sequences of steps by actors or the product.  Don’t specify physical details.  Impose minimal order on activities.  Proofread the description.

21. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 21 Use Case Models  The diagram is a static model cataloging product interactions.  The descriptions are dynamic models detailing the interactions. A use case model is a use case diagram together with use case descriptions for each use case in the diagram.

22. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 22 Designing with Use Case Diagrams  Models a design alternative for the interactions that a product will support  Generate several design alternatives  Alternative can be evaluated in terms of Unmet needs Extraneous features or capabilities Development costs Time and risk Conformance to constraints Feasibility, simplicity, beauty

23. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 23 Designing with Use Case Descriptions  Use case descriptions refine the user-level specification in a use case diagram into operational-level specifications.  Design alternatives are specified in different descriptions.  Alternatives can be evaluated as already described.

24. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 24 Requirements and Use Case Models  Use case models do not provide atomized requirements statements. They are not traceable; Some product functions may not appear; Data and non-functional requirements are not explicit.  Use case models sometime serve as surrogates for requirements.

25. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 25 Extracting Requirements  Extracting requirements from use case models Helps designers understand their designs better; Helps find errors and improve designs; Produces a useful artifact for engineering design.  Additional requirements are also needed. Data and non-functional requirements Physical-level requirements

26. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 26 Use-Case-Driven Iterative Development In an iterative development project Choose several use cases for implementation in an iteration; Furnish product design details; Do engineering design, code, test, and (perhaps) deploy; Evaluate the result for the next iteration; Repeat these steps.

27. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 27 Process Guidelines  Start with a complete use case diagram.  Choose use cases for each iteration according the the following criteria: Important to stakeholders Requires a core system function Requires the essentials of the system architecture The implementation is technically challenging

28. © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 28 Summary  A use cases description is structured text that specifies the details of a use case.  Templates, processes, and heuristics guide use case description writers.  Use case descriptions, though not requirements, can be a source for them.  Use case diagrams and descriptions together form use case models.  These models are a powerful product design tool.  Use cases can drive iterative development.