Use Cases

7/09

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

What Is an Actor?What Is an Actor?

Charlie asCaller

Charlie asCustomer

Charlie Phone Owner

Phone Carrier

A User Can Act as Several ActorsA User Can Act as Several Actors

PhoneSystem

Voice mail

Caller Callee

Is the Voice Mail an actor or part of the system? What about other providers?

System boundary?

ActorsActorsHelp Define System BoundariesHelp Define System Boundaries

Questions to Identify ActorsQuestions 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 #1Use 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

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.

ActorActor

Use CaseUse Case

The Use-Cases ModelThe Use-Cases ModelMajor ConceptsMajor Concepts

Actor Icons

<<actor>>

Borrower

Borrower

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

Caller

CustomerBilling Manager

Callee

Bill CustomerBill Customer

Text MessageText Message

Place CallPlace Call

A model of what the system is supposed to do (use case), and the system’s surroundings (actors).

A Sample SystemA Sample System

Cell-phone System

Non-network Provider

Use Case ModelUse 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

ScenariosScenarios

• 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 Call1. 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>><<include>><<include>>

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

Callee

<<extend>><<extend>>

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 CasePlaceorder

pay

cashCreditcard

Requestcatalog

<<include>><<extends>>

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 <<include>> when you know exactly when to

invoke the use case. These should rarely nest more than 2 deep.

• Avoid using <<extend>>

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.