Use Cases Alistair Cockburn, Writing Effective Use Cases, Addison- Wesley, 2000. Grady Booch, James...

download Use Cases Alistair Cockburn, Writing Effective Use Cases, Addison- Wesley, 2000. Grady Booch, James Rumbaugh, and Ivar Jacobson, Unified Modeling Language.

of 59

  • date post

    18-Dec-2015
  • Category

    Documents

  • view

    219
  • download

    6

Embed Size (px)

Transcript of Use Cases Alistair Cockburn, Writing Effective Use Cases, Addison- Wesley, 2000. Grady Booch, James...

  • Slide 1
  • Use Cases Alistair Cockburn, Writing Effective Use Cases, Addison- Wesley, 2000. Grady Booch, James Rumbaugh, and Ivar Jacobson, Unified Modeling Language User Guide, 2 nd edition, Addision- Wesley, 2005. Scott W. Ambler, The Elements of UML 2.0 Style, Cambridge University Press, 2005. 1
  • Slide 2
  • Groups of 3 Recorder/timekeeper Participation checker Devils advocate 2
  • Slide 3
  • Motivation One way to describe a system is to create a story, the interaction between a user and the system. This story should be just one path through the system, start to finish, that a user will want to take. 3
  • Slide 4
  • Task Read the ATM description Describe the withdraw transaction from start to finish Make sure you describe exactly one path 10 minutes 4
  • Slide 5
  • Report 5
  • Slide 6
  • Questions What questions did you come up with about the ATM? Other than the customer, what other things did you need to interact with? How did you decide what is inside and outside of your system? Where in your description could things have been different? 6
  • Slide 7
  • What Is an Actor? Not part of a system Represents roles a user can play (not people or job titles) Represents a human, a machine or another system Actively exchanges information with the system: a giver or a recipient 7
  • Slide 8
  • Charlie as Caller Charlie as Customer Charlie Phone Owner Phone Carrier A User Can Act As Several Actors 8
  • Slide 9
  • Phone System Voice mail CallerCallee Is the Voice Mail an actor or part of the system? What about other providers? System boundary? Actors Help Define System Boundaries 9
  • Slide 10
  • Questions to Identify Actors Who will use the system? Who needs support from the system to do regularly occurring tasks? Who will maintain the system? What hardware does the system support or interact with? What other systems are needed for this system to work? Who will supply, use, or remove information? Dont just consider people in front of a computer screen 10
  • Slide 11
  • Task Identify all of the actors in the ATM exercise. 3 minutes 11
  • Slide 12
  • Here on Thursday Fix ATM description so that only withdraw on sufficient funds. 12
  • Slide 13
  • ATM Actors 13
  • Slide 14
  • A use case defines a sequence of actions performed by a system that yields an observable result of value to an actor. Use Cases 14
  • Slide 15
  • Use Cases A use case is always initiated by an actor. A use case provides value to an actor. A use case is complete. 15
  • Slide 16
  • Use Cases A use case is always initiated by an actor. Is always performed on behalf of an actor. Actor must directly or indirectly initiate the use case. A use case provides value to an actor. A use case is complete. 16
  • Slide 17
  • Use Cases A use case is always initiated by an actor. A use case provides value to an actor. The use case must deliver some tangible value to an actor. A use case is complete. 17
  • Slide 18
  • Use Cases A use case is always initiated by an actor. A use case provides value to an actor. A use case is complete. A use case is a complete description. A use case is not complete until the end value is produced. 18
  • Slide 19
  • For Each Actor, Ask the Following Questions: What are the primary tasks the actor wants the system to perform? Will the actor create, store, change, remove, or read data in the system? Will the actor need to inform the system about sudden, external changes? Does the actor need to be informed about certain occurrences in the system? Will the actor perform a system startup or termination? 19
  • Slide 20
  • Think About Data: Who creates it? Who displays or uses it? Who updates or modifies it? Who deletes it? These are typical use cases for data objects in the system. 20
  • Slide 21
  • Candidate Use Cases: Must Be For the Actor Rule #1: Be sure the use case provides value to the actor. 21
  • Slide 22
  • Task Identify the main use cases of the ATM system. 3 minutes 22
  • Slide 23
  • Main Use Cases: 23
  • Slide 24
  • Task: Identify the main use cases for Gas Pump. 3 minutes 24
  • Slide 25
  • Gas Pump Use Cases: Pump gas 25
  • Slide 26
  • Documenting Use Cases Use case diagrams consisting of system actors use cases 26 > UserStudentFaculty Enter GradesValidate UserCheck GradesGet RosterRegister > system boundary use case actor Goldmine
  • Slide 27
  • Use Case Diagram: System Diagram starts with a bounding box and a subject Goal: determine the boundaries of the system, i.e., whats in, whats out. Cell-phone System 27
  • Slide 28
  • An actor represents an external entity that interacts with the system. A use case defines a sequence of actions performed by a system that yields an observable result of value to an actor. Actor Use case The Use-Cases Model Major Concepts 28
  • Slide 29
  • Actor Icons > Borrower These are the same, but the class rectangle is almost never used in use case diagrams. 29
  • Slide 30
  • Caller A model of what the system is supposed to do (use case), and the systems surroundings (actors). A Sample System Cell-phone System 30 Text MessagePlace CallBill Customer Customer Callee Billing manager Non-network provider
  • Slide 31
  • Task Draw the Use Case Diagram for ATM. Time: 5 minutes 31
  • Slide 32
  • Use Case Model Model of systems intended functions and its surrounding Answers the question what the system does to benefit users? Communicates the systems functionality and behavior to the customer or end user Use terminology that users understand. Verifies developers understanding of the system. Helps verify that all requirements are captured. 32
  • Slide 33
  • Use Case Model (Cont.) Identify external interactions Provides a basis for system design Provides a basis for system testing and walkthroughs Can help avoid requirements creep Well have to create a new use case and modify some existing ones Makes customers aware of impact of changes 33
  • Slide 34
  • So, Whats a Use Case? A scenario is a sequence of steps describing an interaction between a user and a system. The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorization on the credit card and confirms the sale both immediately and with a follow-up email. What if the credit card authorization fail? A separate scenario! 34
  • Slide 35
  • Use Cases (Cont.) A use case is a set of scenarios tied together by a common user goal (e.g., success and failure together, and other alternative paths). 35
  • Slide 36
  • An Example Use Case Main success scenarios along with alternatives and extensions 36 Buy product Main Success Scenario: 1.Customer browses through catalog and select items to buy 2.Customer goes to check out 3.Customer fills in shipping information (address) 4.System presents full pricing information, including shipping 5.Customer fills in credit card information 6.System authorizes purchase 7.System confirms sale immediately 8.System sends confirmation email to customer Extensions: 3a: Customer is a regular customer 3a1: System displays current shipping, pricing and billing information 3a2: Customer may accept or override these defaults, returns to MSS at step 6 6a: System fails to authorize credit purchase 6a1: Customer may re-enter credit card information or may cancel.
  • Slide 37
  • Another Presentation 37 Extensions: 3a: Customer is a regular customer 3a1: System displays current shipping, pricing and billing information 3a2: Customer may accept or override these defaults, returns to MSS at step 6 6a: System fails to authorize credit purchase 6a1: Customer may re-enter credit card information or may cancel. Customer: 1. Browses catalog and select items 2. Goes to check out 3. Fills in shipping information (address) 5. Customer fills in credit card information Buy product Main Success Scenario: System: 4. Presents full pricing information 6. Authorizes purchase 7. Confirms sale immediately 8. Sends confirmation email to customer
  • Slide 38
  • Scenarios - Flow of Events Represents what system does, not how the system performs behavior Should be clear enough for outsider to understand Guidelines: How use case starts and ends What data is exchanged between actor and use case Do not describe details of user interface Describe flow of events, not only functionality Do not describe what happens outside the system Avoid vague terminology (etc.; information) 38
  • Slide 39
  • Documenting Use Cases Not part of UML but include (see template): Brief description: describe the overall intent of the use case Preconditions: conditions that must be true before the use case can begin to execute Basic flow: used to capture the normal flow of execution through the use case Alternative flows: used to capture variations to the basic flows, such as decisions or error conditions. Pos