Chapter 3: Part 2
Use Case Modeling
Ian Summorvillie, Software Engineering, Chapter 4 (Further Reading)
slides adopted from Marty Stepp http://www.cs.washington.edu/403/
Outline
• What is UML
• What is a use case?
• Terminology
• Steps for creating a use case
2
Overview of UML
• The Unified Modeling Language (UML) is a general-purpose
visual modeling language that is used to specify, visualize,
construct, and document the artifacts of a software
system
– UML is not a programming language, but is a general purpose
modeling language
• UML helps Modeling a system from several separate but
related viewpoints which permits it to be understood for
different purposes
• The UML captures information about
– static structure of the system
• defines the kinds of objects important to a system and to its
implementation, as well as the relationships among the objects
– Dynamic behavior of the system
• defines the history of objects over time and the communications
among objects to accomplish goals.
3
Where Can the UML Be Used?
• System development focuses on three different models of the
system
The functional model:
– represented in UML with use case diagrams, describes the
functionality of the system from the user’s point of view.
The object model
– represented in UML with class diagrams, describes the
structure of a system in terms of objects, attributes, associations,
and operations
The dynamic model
– describes the internal behavior of the system
– can be described using
• Sequence diagrams describe behavior as a sequence of messages
exchanged among a set of objects
• state chart diagrams describe behavior in terms of states of an
individual object and the possible transitions between states
4
Use cases
• Functional Requirements
– Tell us what the user will do with the system.
– Not enough details for developers
– Need a way to describe the sequence of interactions
to accomplish a functional requirement.
• use case: a written description of the user's
interaction with the software product to
accomplish a goal
– It is an example behavior of the system.
• written from actor's point of view, not the system's
• Use cases capture functional requirements
– Not necessary one to one mapping between them
5
Benefits of doing use
cases?
• Establish an understanding between the customer and
the system developers of the detailed requirement
– success scenarios
• Alert developers of problematic situations, error cases
to test
– extension scenarios
• Capture a level of functionality to plan around
– list of goals
6
Qualities of a good use
case
• Focuses on interaction
– Starts with a request from an actor to the system.
– Ends with the production of all the answers to the
request.
• Focuses on essential behaviors, from the actor’s point
of view
– Does not describe internal system activities.
– Does not describe the GUI in detail.
• Concise, clear, accessible to non-programmers
– Easy to read.
– Summary .
– Main success scenario and extensions.
7
Use cases vs. internal
features
:
•
•
•
•
Use Cases
call someone
receive a call
send a message
memorize a number
•
•
•
•
Internal Functions
transmit / receive data
energy (battery)
user I/O (display,
keys, ...)
phone-book mgmt.
Point of view: user
Point of view: developer /
designer
8
Use cases and
requirements
• Which of these requirements would probably be
represented or mentioned directly in a use case?
1.
2.
3.
4.
5.
6.
Special deals may not run longer than 6 months.
Customers only become preferred after 1 year.
A customer has one and only one sales contact.
Database response time is less than 2 seconds.
Web site uptime requirement is 99.8%.
Number of simultaneous users will be 200 max.
• Answer: None!
– Most of these are non-functional requirements, so the use
cases wouldn't mention them.
9
– The user doesn't see them directly.
Terminology
• actor: an entity that acts on the system
– primary actor: initiates interaction to achieve goal
• goal: action that actor wants to accomplish
– E.g register, search,
• stakeholder: anyone interested in the system
– supplier, stock agency, vendor
Use cases are always initiated by actors and describe
the flow of events that these actors are involved in.
10
Terminology
• Actor can be a human being or another system
– External system –
•
E.g billing system needs to get the courses a student
registered to from registration system
– Human
•
a student, teacher, registrar
• An actor is not a person but a role played by a person
or an external system.
– E.g the same person can be a student or an instructor.
11
Use case diagram
• For example, if you work for a bank, you might be a
LoanOfficer.
12
Use case diagram…..
• The overall list of the system's use cases can be drawn
as high-level diagrams, with:
– actors as stick-men, with their names (nouns)
– use cases as ellipses, with their names (verb phrases)
– line associations, connecting an actor to a use case in
which that actor participates
– use cases can be connected to other cases that they use /
rely on
• E.g Check out book depends on login
13
Actor-goal lists: function
content of the system
Actor
Goal
Library Patron
Search for a book
Check out a book
Return a book
Librarian
Search for a book
Check availability
Request a book from
another library
It can be useful to
create a list or table
of primary actors and
their "goals" (use
cases they start).
The diagram
then capture
material
will
this
14
Use case summary
diagrams
15
16
How to describe a single use case
A. Name: Give a short, descriptive name to the use case.
B. Actors: List the actors who can perform this use case.
C. Goals: Explain what the actor or actors are trying to
achieve.
D. Preconditions: State of the system before the use case.
E. Summary: Give a short informal description.
F. Steps: Describe each step using a 2-column format.
G.Postconditions: State of the system after
response/completion.
17
For example: ATM can have ValidateUser, Withdraw, Tranisfer,Balance….
 you might describe the use case ValidateUser in the following way:
Name: validateuser
Actor: customer
Goal :checking wether the customer is authorized user or not
Precondition: the system prompts the Customer for a PIN number
Steps(main flow of events):
 The Customer can now enter a PIN number via the keypad.
 The Customer commits the entry by pressing the Enter button.
 The system then checks this PIN number to see if it is valid.
 If the PIN number is valid, the system acknowledges the entry, thus
ending the use case.
• Exceptional flow of events:
18
Exceptional flow of events 1:
• The Customer can cancel a transaction at any time by
pressing the Cancel button, thus restarting the use case.
• No changes are made to the Customer's account.
• Exceptional flow of events 2:
• The Customer can clear a PIN number anytime before
committing it and reenter a new PIN number.
• Exceptional flow of events 3:
• If the Customer enters an invalid PIN number, the use case
restarts.
• If this happens three times in a row, the system cancels
the entire transaction, preventing the Customer from
interacting with the ATM for 60 seconds.
19
Organizing use cases
• organize use cases by specifying
 generalization,
 include
 extend relationships among them
1. Generalization.
• child use case inherits the behavior and meaning of the parent use
case.
• The child may add to or override the behavior of its parent;
For example:
– in a banking system, you might have the use case Validate User, which is
responsible for verifying the identity of the user.
• You might then have two specialized children of this use case
 Check password
 Retinal scan
• Both add their own behavior (the former by checking a textual password,
the latter by checking the unique retina patterns of the user ).
• generalization among use cases is rendered as a solid directed line with
a large open arrowhead, just like generalization among classes.
20
21
2. <<includes>> relationship
• the base use case explicitly incorporates the behavior of
another use case
• the base use case pulling behavior from the supplier
use case.
• You use an include relationship
 to avoid describing the same flow of events several times,
 putting the common behavior in a use case of its own
(the use case that is included by a base use case).
 take a set of responsibilities of the system and
capture it in one place (the included use case), then let
all other parts of the system (other use cases) include the
new aggregation of responsibilities whenever they need to
use that functionality.
22
<<includes>>
relationship
Validate Use case may be used in other contexts
• <<includes>> (aka<<uses>>) relationship used for
events that are in the flow of events of the source use case.
• << >> are called stereotypes in UML
23
3. <<extends>> Relationship
 Used to make optional interactions explicit or
 to handle exceptional cases.
• An extend relationship between use cases means that
– the base use case implicitly incorporates the behavior of another
use case at a location specified indirectly by the extending use case.
• The base use case may stand alone, but under certain
conditions, its behavior may be extended by the
behavior of another use case.
• You can think of extend as the extension use case pushing
behavior to the base use case.
• You may also use an extend relationship to model a
separate sub flow that is executed only under given
conditions.
24
<<extends>>
Relationship
<<extend>>used for exceptional conditions,
especially those that can occur at any time.
• E.g Request Laboratory Test case may be performed after
Reviewing Patient’s Case
25
Use case exercise
• Consider a Netflix-like video rental web system.
– A customer with an account can use their membership
and credit card in the web app to order a video for rental.
– The software can look up movies and actors by keywords.
– A customer can check out up to 3 movies, for 5 days
each.
– Late fees can be paid at the time of return or at next
checkout.
• Exercise:
– Come up with 3-4 use case names for this software.
– Identify some of the actors and stakeholders in this
system.
26
2. Informal use case
• informal use case: a paragraph describing the
scenario
• Example (for a library management system):
– Patron loses a book
– The library patron reports to the librarian that she has
lost a book. The librarian prints out the library record
and asks patron to speak with the head librarian, who
will arrange for the patron to pay a fee. The system will
be updated to reflect lost book, and patron's record is
updated as well. The head librarian may authorize
purchase of a replacement book
27
What is an extension?
• A possible branch in a use case scenario, often
triggered by an error or failure in the process.
– Useful for finding edge cases that need to be handled and
tested.
• Do
– Think about how every step of the use case could fail.
– Give a plausible response to each extension from the
system.
– Response should either jump to another step of the case,
or end it.
• Don’t
– List things outside the use case ("User's power goes out").
– Make unreasonable assumptions ("DB will never fail").
– List a remedy that your system can't actually implement.28
Formal Use case
Goal
Primary a c t o r
Scope
Level
P a t r o n w i s h e s to r e s e r v e a book u s i n g the o n l i n e c a t a l o g
P atro n
L ib r a r y s y s te m
User
Pre c o n d i t i o n
P a t r o n i s a t the l o g i n s cre e n
S u c c e s s end
B o o k is r e s e r v e d
Failure end c o n d i t i o n B o o k i s not r e s e r v e d
T r ig g e r
P a t r o n l o g s into s y s t e m
Parts that make up a formal use case
(continued on the next slide).
29
Formal Use case
Main s u c c e s s
s c e n a r io
1. P a t r o n
2. S y s t e m
3. S y s t e m
4. P a t r o n
5. S y s t e m
6. P a t r o n
7. S y s t e m
s te p 3
E xt e n s ion s (e r r or
s c e n a r io s )
2 a . P a s s w o r d is incorrect
2 a . 1 S y s t e m r e t u r n s p a t r o n to l o g i n s cre e n
2 a . 2 P a t r o n b a c k s out or t r i e s a g a i n
5 a . S y s t e m c a n n o t f i n d book
5 a .1 …
4 . P a t r o n e n t e r s a u t h o r or s u b j e c t
Va riat ion s
(a l t e r n a t ive
s c e n a r io s )
e n te rs a c c o u n t a n d p a s s w o r d
v e r i f i e s a n d l o g s p a t r o n in
p r e s e n t s c a t a l o g with s e a r c h s cre e n
e n t e r s book t i t l e
f in d s m a t c h a n d p r e s e n t s lo c a tio n c h o ic e s
s e l e c t s l o c a t i o n a n d r e s e r v e s book
c o n f ir m s r e s e r v a t io n a n d c o n t in u e s f r o m
30
3. Formal use case
(goal of primary actor)
(level of goal [summary, user, subfunction])
(primary actor)
"Place an order"
(User goal / Clerk)
(action steps:
full sentences showing
who takes the action!
- 9 steps long.)
and3quantity.
Main scenario:
1. Clerk specifies customer, item
2. System accepts and queues the order.
...
(condition causing different actions)
Extensions:
(action step(s)
handling those conditions)
1a. Low credit & Customer is 'Preferred':
1a1. System gives them credit anyway.
1b. Low credit & not 'Preferred' customer:
1b1. Clerk performs Sign Up Preferred Customer
scenario and accepts only prepayment.
(calling
another use case)
2a. Low on stock: Customer accepts
rain-check:
2a1. Clerk reduces order to available stock level.
31
What notation is good?
• There are standard templates for requirements
documents, diagrams, etc. with specific rules.
• Is this a good thing? Should we use these standards or
make up our own?
– Standards are helpful as a template or starting point.
– But don't be a slave to formal rules or use a
model/scheme that doesn't fit your project's needs.
32
Alternative
• Sometimes
33
Cockburn's 4 use case
steps
1. Identify actors and goals
– What computers, subsystems, people
will drive our system? (actors)
– What does each actor need our
system to do? (goals)
2. Write the main success scenario
– easiest to read; everything else is a
complication on this
– capture each actor's intent and
responsibility
• say what information passes between
them
• number each line
34
Cockburn's 4 use case
steps
3. List the failure extensions
– usually almost every step can fail (bad credit, out of
stock...)
• note failure condition separately, after main success
scenario
– Describe failure-handling
• recoverable: back to main course (low stock + reduce
quantity)
• non-recoverable: fails (out of stock, or not a valued
customer)
• each scenario goes from trigger to completion
– Label with step number and letter:
• 5a failure condition
– 5a.1 use case continued with failure scenario
– 5a.2 continued
35
Cockburn's 4 use case
steps
• 4. List the variations
– Many steps can have alternative behaviors or scenarios
– Label with step number and alternative
• 5’. Alternative 1 for step 5
• 5’’. Alternative 2 for step 5
36
Summary
• Uses case describe example system behaviors
(contracts) from the user’s point of view.
• Can be diagrams, informal paragraphs, formal use
cases.
• 4 steps to create use cases
37