Use Cases
Alistair Cockburn, Writing Effective Use Cases, AddisonWesley, 2000.
Grady Booch, James Rumbaugh, and Ivar Jacobson, Unified
Modeling Language User Guide, 2nd edition, AddisionWesley, 2005.
Scott W. Ambler, The Elements of UML 2.0 Style, Cambridge
University Press, 2005.
1
Groups of 3
• Recorder/timekeeper
• Participation checker
• Devil’s advocate
2
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
Task
• Read the ATM description
• Describe the withdraw transaction from
start to finish
• Make sure you describe exactly one
path
• 10 minutes
4
Report
5
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
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
A User Can Act As Several
Actors
Charlie as
Caller
Charlie as
Customer
Charlie
Phone Carrier
Phone Owner
8
Actors
Help 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?
9
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?
• Don’t just consider people in front of a computer screen…
10
Task
• Identify all of the actors in the ATM
exercise.
• 3 minutes
11
Here on Thursday
• Fix ATM description so that only
withdraw on sufficient funds.
12
ATM Actors
13
Use Cases
A use case defines a sequence of actions
performed by a system that yields an
observable result of value to an actor.
14
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
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
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
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
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
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
Candidate Use Cases: Must
Be For the Actor
Rule #1: Be sure the use case provides
value to the actor.
21
Task
• Identify the main use cases of the ATM
system.
• 3 minutes
22
Main Use Cases:
23
Task:
• Identify the main use cases for Gas
Pump.
• 3 minutes
24
Gas Pump Use Cases:
• Pump gas
25
Documenting Use Cases
• Use case diagrams
consisting of
– system
– actors
– use cases
system boundary
Goldmine
Register
use case
User
Check Grades
<<include>>
actor
Validate User
Student
Get Roster
<<include>>
<<extend>>
Faculty
Enter Grades
26
Use Case Diagram: System
Cell-phone System
Diagram starts with a
• bounding box
• and a subject
• Goal: determine the
boundaries of the
system, i.e., what’s
in, what’s out.
27
The Use-Cases Model
Major Concepts
Actor
•
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.
Use case
28
Actor Icons
Borrower
These are the same, but the
class rectangle is almost never
used in use case diagrams.
<<actor>>
Borrower
29
A Sample System
Cell-phone System
Place Call
Callee
Caller
Text Message
Non-network
provider
Bill Customer
Customer
Billing manager
A model of what the system is supposed to do (use
case), and the system’s surroundings (actors).
30
Task
• Draw the Use Case Diagram for ATM.
• Time: 5 minutes
31
Use Case Model
• Model of system’s intended functions and its
surrounding
• Answers the question “what the system does to
benefit users?”
• Communicates the system’s functionality and
behavior to the customer or end user
– Use terminology that users understand.
– Verifies developer’s understanding of the system.
– Helps verify that all requirements are captured.
32
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
– “We’ll have to create a new use case and modify some
existing ones …”
– Makes customers aware of impact of changes
33
So, What’s 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
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
An Example Use Case
• Main success scenarios along with alternatives and extensions
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.
36
Another Presentation
Buy product
Main Success Scenario:
Customer:
System:
1. Browses catalog and select items
2. Goes to check out
3. Fills in shipping information (address)
4. Presents full pricing information
5. Customer fills in credit card information
6. Authorizes purchase
7. Confirms sale immediately
8. 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.
37
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
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.
– Postconditions: conditions that must be true for the use case
to complete.
39
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
40
Scenario 1: Place Call
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
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.
41
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.
42
Task:
• Write the use case scenario for
Withdraw.
• Include alternative flows.
• 10 minutes
43
More on UML Use Case
Diagrams
• Relationships
– Association between an actor and a use
case
– Dependency between two use cases
– Generalization between two actors
– Generalization between two use cases
44
Actor and Use Case
• Indicate participation of actors in use
cases
• Optional direction indicating the initiator
of the use case, e.g.,
Place Call
Caller
Callee
45
Actor Generalization
Generalization can be used to
clarify the model when users
have common behaviors;
however, systems are
frequently best understood by
understanding a person plays
more than one role.
Registered User
Manager
Borrower
46
“Include” Relationship
Withdraw
Cash
Deposit
Cash
Withdraw Cash
IC1
…
for identifying customer
ICm
W1
…
for withdrawing cash
Wn
Deposit Cash
IC1
…
for identifying customer
ICm
D1
…
for depositing cash
Dn
Withdraw Cash
include::Identify Customer
W1
…
Wn
Deposit Cash
include::identify Customer
D1
…
Dn
Identify
Customer
<<include>>
Withdraw
Cash
<<include>>
Deposit
Cash
Identify Customer
IC1
…
ICm
47
Include Relationship
• Used as follows:
– Factor out behavior that is
common for 2+ use cases.
– Factor out behavior from base
use case if not necessary for
understanding of primary
purpose of use case.
• Description
– Define location within the
behavior sequence of base case
where inclusion is to be
inserted, e.g.
includes the “Identify Customer”
use case to determine the
identity of the customer, or
include::Identify Customer.
Identify
Customer
<<include>>
<<include>>
<<include>>
Withdraw
Cash
Deposit
Cash
Transfer
Funds
48
“Extend” Relationship
Enroll
In Univ.
Enroll In University
I1
…
Im
C1
…
if int’l student
Cn
Im+1
…
Im+l
Enroll In University
I1
…
Im
(Ext: int’l student)
Im+1
…
Im+l
Check Security
C1
…
Cn
Enroll
In Univ
<<extend>>
Check
Security
49
Extend Relationship
• Used to:
Enroll in
University
Student
<<extend>>
Check
Security
– 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
50
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: The student is an international student.
– Extension Points: International Student– insert the whole
use case
– In main flow of events, show the extension point as follows:
…(Ext 1: International Student). …
51
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
Customer
Internet
Order
Internet
Customer
52
Use Case Relationships
<<include>>
Pay
Cash
Place
Order
<<extend>>
Request
Catalog
Extends: Insertion of
additional behavior into a
use case that does not
know about it.
Credit
Card
Generalization: relationship between
general case and specific case that adds
features to the general case
53
Difference Between Include
And Extend
• Include:
–
–
–
–
Several use cases have common action.
Action is not a use case on its own.
Factor common action and include.
“Always” included and “explicit”
• Extends
– Use case has as part of its action all of another
use case.
– This use case provides service beyond other use
case.
– “Optionally” extended and “implicit”
54
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 nonessential, eliminate duplicates, focused
and detailed scenarios.
55
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
56
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>>.
57
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 (includerelationship)
– Implicit inclusion in base case (extendrelationship)
– Separate subflow (e.g., Maintain Employee
Information may have subflows for adding
or deleting)
58
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.
59