1 / 32

Use Cases

Use Cases. 7/09. What Is an Actor?. not part of the system represents roles a user can play represents a human, a machine or another system actively exchanges information with the system: a giver or a recipient. A User Can Act as Several Actors. Charlie as Caller. Charlie as Customer.

leigh-cote
Télécharger la présentation

Use Cases

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. Use Cases 7/09

  2. What Is an Actor? • not part of the system • represents roles a user can play • represents a human, a machine or another system • actively exchanges information with the system: a giver or a recipient

  3. A User Can Act as Several Actors Charlie as Caller Charlie as Customer Phone Carrier Charlie Phone Owner

  4. ActorsHelp Define System Boundaries System boundary? Phone System Voice mail Caller Callee Is the Voice Mail an actor or part of the system? What about other providers?

  5. 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?

  6. Use Case Rule #1 A use case defines a sequence of actions performed by a system that yields an observable result of value to an actor

  7. Use Cases A use case is always initiated by an actor. A use case provides value to an actor. A use case is complete.

  8. 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?

  9. Candidate Use Cases: Must be for the Actor

  10. Use Case Diagram: System Diagram starts with a • bounding box • and a subject • Goal: determine the boundaries of the system: what’s in, what’s out. Cell-phone System

  11. The Use-Cases ModelMajor Concepts • 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

  12. Actor Icons <<actor>> Borrower These are the same, but the class rectangle is almost never used in use case diagrams Borrower

  13. A Sample System Cell-phone System Place Call Callee Caller Text Message Non-network Provider Customer Bill Customer Billing Manager A model of what the system is supposed to do (use case), and the system’s surroundings (actors).

  14. Use Case Model • Identifies external interactions • Provides a basis for system design • Provides a basis for system testing and walkthroughs • Can help avoid requirements creep • “We’ll have to create a new use case and modify some existing ones …” • Makes customers aware of impact of changes

  15. Scenarios • Three Definitions • Alternate path • An instance • A use case

  16. Flow of Events (Scenario) • 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)

  17. Scenario 1: Place Call Preconditions: A caller wants to make a call to a callee. The cell phone is on and connected to a cell phone network. The phone is idle. Postconditions: On successful completion, the phone is idle. The caller has been connected to the callee for voice communication. Actors: Caller, Callee, Network Provider

  18. Scenario 1: Place Call • The caller activates the “call” option. (this may be by opening the phone or selecting some UI element.) • The system displays a blank list of digits and indicates it is in “call” mode. • The user enters digits (ALT 1). • The system displays the entered digits. • The user selects the “dial” option (ALT 2). • The system sends the sequence of digits to the network provider. • The network provider accesses the network and makes a connection (ALT 3, ALT 4). • The callee answers (ALT 5). • The network provider completes the voice connection. • The caller and callee engage in voice communications. • The caller hangs up (ALT 6). • The system returns to idle mode. • End of Use Case.

  19. Scenario 1: Place Call ALT 1: The user uses speed dial. A1-1: The user enters a single digit and selects “dial”. A1-2: The system accesses the phone number associated with the digit (ALT 1.1). A1-3: Use case continues at step 6. ALT 1.1: No speed dial number is associated with the entered digit. A1.1-1: The system ignores the “dial” command and displays the digit. A1.1-2: Use case continues at step 4. ALT 2: The user cancels the operation. A2-1: Use case continues at step 12.

  20. Actor Generalization Registered User Manager Borrower

  21. Include-Relationship-1 • Inclusion always abstract • Used as follows: • Factor out behavior from base use case if not necessary for understanding of primary purpose of use case. • Factor out behavior that is common for 2+ use cases. Identify Customer <<include>> <<include>> <<include>> Withdraw Cash Transfer Funds Deposit Cash

  22. Include-Relationship Description • Define location within the behavior sequence of base case where inclusion is to be inserted. • Define location by referring particular step or subflow within flow of events • Includes the Identify Customer use case to determine the identity of the customer. • Describe include relationship from Withdraw Cash to Identify Customer as follows: • Identify Customer is inserted between sections 1.1 Start of Use Case and 1.2 Ask for Amount in the flow of events of Withdraw Cash.

  23. Extend Relationship • Often abstract, but does not have to be • Used to: • Show that a part of a use case is optional • Show that a subflow is executed only under certain conditions • Show that there may be set of behavior segments that are inserted depending on interaction with actors Place Call Caller Callee <<extend>> <<extend>> Show Caller Identity Place Conference Call Callee

  24. Extend Relationship Description • Each extend relationship has a list of references to extension points in the base case. • Extension points are referenced by name. • Example: • Condition: Receiving party must have ordered the service “Caller ID” • Extension Points: Show Identity – insert the whole use case • In main flow of events, show the extension point as follows: …(Show Identity). …

  25. Use-Case-Generalization • Use when two or more use cases have commonalities in behavior, structure, or purpose. • Describe in child spec how behavior sequences from the parents are interleaved with the child. Place Order Phone Order Internet Order Internet Customer Customer

  26. Use Case Place order <<include>> <<extends>> Request catalog pay Extends: Insertion of additional behavior into a use case that does not know about it. Credit card cash Generalization: relationship between general case and specific case that adds features to the general case

  27. Difference between Include and Extend • Include: • Extends

  28. Stages of Use Case Construction • Identify most important interactions • Fill in use cases • Triggers, pre and post conditions, basic course of events, document exceptions • Break out detailed use cases • Focus • Clarify scope, separate essential from non-essential, eliminate duplicates, focused and detailed scenarios,

  29. Candidate Use Cases: Verbs • Strong verbs: • Create, remove, merge, defer, switch, calculate, pay, credit, register, deactivate, review, view, enter, change, combine, release, search, migrate, receive, debit, activate, archive, browse • Weak verbs: • Make, report, use, organize, record, find, process, maintain, display, list, input

  30. Style Notes (Ambler, 2005) • Use case names begin with strong verbs • While use cases do not imply timing, order cases from top to bottom to imply timing (improves readability) • The primary actors should appear in the top left • Actors are associated with one or more use cases. • Do not use arrows on the actor-use case relationship • Include an actor called “time” to initiate scheduled events • Do not show actors interacting with each other • Apply <<include>> when you know exactly when to invoke the use case. These should rarely nest more than 2 deep. • Avoid using <<extend>>

  31. Subflows: parts • Extract parts of flow of events and describe these separately. • Alternative flow of events within base case (variant, option, exception) • Explicit inclusion in base case (include-relationship) • Implicit inclusion in base case (extend-relationship) • Separate subflow (e.g., Maintain Employee Information may have subflows for adding or deleting)

  32. Subflows • Flow may consist of several subflows. • Subflows can be reused in other use cases. • Avoid if-then-else constructs; pseudocode • Extract parts of flow of events and describe these separately.

More Related