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

© 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

© 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

© 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

© 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

© 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

© 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.

© 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.

© 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.

© 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.

© 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 … …

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

© 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).

© 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.

© 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.

© 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.

© 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

© 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).

© 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.

© 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.

© 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.

© 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

© 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.

© 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.

© 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

© 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.

© 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

© 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.