Use Cases 7/09

lnot part of the system lrepresents roles a user can play lrepresents a human, a machine or another system lactively exchanges information with the system: a giver or a recipient What Is an Actor?

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

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

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?

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

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

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?

Candidate Use Cases: Must be for the Actor

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

pAn actor represents an external entity that interacts with the system. pA 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

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

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

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

Scenarios Three Definitions Alternate path An instance A use case

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)

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

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

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.

Actor Generalization Registered User BorrowerManager

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 Withdraw Cash Deposit Cash Transfer Funds >

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.

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 Conference Call Show Caller Identity Caller Place Call Callee >

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

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. Phone Order Internet Order Customer Internet Customer Place Order

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

Difference between Include and Extend Include: Extends

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,

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

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 > when you know exactly when to invoke the use case. These should rarely nest more than 2 deep. Avoid using >

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)

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.