1
Chapter 6:
Use Cases
Chapter 6 in Applying UML and Patterns Book.
2
Overview

What use cases are and how to write them.

Different format of use cases.

How to draw a use case diagram.

Extend and include use cases.
3
By the end of this chapter, you will..

Understands the use case diagram and the different relationship
types inside the use case diagram.

Understands the meaning of “Use Case”.

Understands the different methods in writing the use cases.
4
Capturing functional requirements
with use case diagram

It describes the main system functions from the standpoint of an external observer.

Used during requirements elicitation to represent external behavior.

It emphasize on what the system does rather than how it.

It is created during the early stages of a project – during the analysis phase rather
than during the design phase.

It provides a high-level view of what the system does and who uses it.

It provides the basis for determining the user interfaces (UIs) to the system.
5
Example: Use Case Diagram
ATM Banking System
6
Use Case Diagram
Any use case diagram should contain:

Actor(s).

Use cases.

Associations/Relationships among
actors and use cases.
7
Use Case Diagram
Actor

Actors are drawn as stick persons with the role of the actor written
below.

Actor names are unique typically represent the role that
an actor plays with respect to the system.

Is someone (e.g. human beings) or something (e.g. other objects
or systems) that interact with the system.

Is entity external to the system who participates in the story of the
use case (receive or input), such as a person, computer system or
organization.

Example: a library clerk, cashier, customer, Passenger, GPS
satellite, bank, customer department.
Actor role name
8
Use Case Diagram
Use Case

Use cases are drawn as ellipses with the name of the use case written inside
the ellipse.

Use case name typically consists of an active verb and one or more nouns that
concisely describe the system function modeled.
Use case
9
Use Case Diagram
Use Case
Use Cases: is a collection of related scenarios that describe actors using a system
to support a goal.
Scenario (Use Case instance):

Is a possible example of what happens when an actor interacts with the system.

Represents a unit of functionality that the system provides.

Contains a specific sequence of actions and interactions between actors and the
system under discussion.

Example: the scenario of entering book information into the catalog, or buying items at
a store, or using an ATM.
10
Use Case Diagram
Association/Relationship

Actors are connected to the use case(s) with which they interact by a line, which
represents the relationship between the actor(s) and the use case(s).

One actor may be associated with one or more use cases.

One use case may be associated with one or more actors.
11
Example 1: Use Case Diagram
Banking System
12
Example 2: Use Case Diagram
Registration System
13
Example 3: Use Case Diagram
Library System
14
Activity: Use Case Diagram
Draw the use case diagram for an online airline reservation system
(min. 3 use cases).
15
Use Case(s)

Each use case have an associated behavior specification which describes the sequence
of actions making up a use case scenario.

Use case behavioral description has two formats:
High Level Use Case
Expanded Use Case
Describes a process very briefly, usually in 2 or 3
sentences.
Describes a process in details.
It has an additional section not present in HL.
It consists of :
• Use Case: Use case name.
• Actors: List of actors (external agents) indicating
who initiates the use case.
• Description (Success scenario): Narrative
description of the process.
• Purpose: Intention of the use case.
• Type:
1- Primary, Secondary or Optional.
2- Essential or Real.
• Cross References: Related use cases and system
functions.
• Typical course of actions: describes in detail the
conservation of interaction between the actors
and the system.
16
High Level Use Case Format: HL
Example 1: Buy Items
Use Case: Buy Items
Actor: Customer(initiator) , Cashier
Description (Success Scenario):
A customer arrives at a checkout with items to purchase. The
Cashier records the purchase items and collects payment. On
completion, the Customer leaves with the items.
17
High Level Use Case Format: HL
Example 2: Library - Add Resources
Use Case: Add Resources
Actor: Librarian
Description (Success Scenario):
The use case begins when the Librarian receives new resources
(books and videos) to add to the catalog. The title, call number,
and other information are recorded. Then the resources are
placed on a shelf organized by resource type and call numbers.
18
Expanded Use Case Types
Primary - Secondary - Optional
Primary
Secondary
Describes a major, common Describes a rare, unusual,
process.
or exceptional processes.
Ex: Buy items.
Ex: Request for stocking
new product.
Optional
Represents processes that
may not be tackled.
19
Expanded Use Case Types
Essential - Real
Abstract level use cases:
Essential
Real
• The essence of the process.
• Concretely describes the process in
terms of its real current design,
• Analysis-oriented.
committed to specific input and output
• Expanded use cases that are expressed in
Technology.
an ideal form free of technology and
• Design-oriented.
implementation details.
• Expressed in terms of the solution. Ex:
• HL are always essential.
screen shots of windows, entry into input
• Expresses process relatively independent
fields, and so forth.
of HW/SW solutions.
20
Expanded Use Case Types
Essential - Real
Examples of essential vs. real types:
Essential
Real
Ex1
The Librarian records the call
number.
The Librarian uses the laser wand to scan
the bar code for the call number, which is
transmitted to the computer.
Ex2
The Account Holder identifies
himself to the ATM.
The Account Holder inserts the card into
the ATM card reader. He is prompted to
enter his PIN (see screen shot 4), which
he inputs with a numeric keypad.
21
Expanded Use Case Format
Example: Buy Items with Cash
Use Case: Buy Items with Cash.
Actor: Customer (initiator), cashier.
Purpose: Capture a sale & its cash payment.
Overview (Success Scenario):
A customer arrives at a checkout with items to purchase. The Cashier
records the purchase items and collects a cash payment. On
completion, the Customer leaves with the items.
Type: Primary.
Cross References: Functions R1.2,…
22
Expanded Use Case Format
Example: Buy Items with Cash (cont.)
Actor Action
System Response
1. This use case begins when a Customer
arrives at the POST checkout with
items to purchase.
2. The Cashier records the identifier
from each item. If there is more than
one of the same item, the Cashier can
enter the quantity as well.
3. Determines the item price and adds
the item information to the running
sales transaction. The description and
price of the current item are
presented.
4. On completion of item entry, the
Cashier indicates to the POST that
item entry is complete.
5. Calculate and presents the sale total.
6. The Cashier tells the Customer the
total.
23
Expanded Use Case Format
Example: Buy Items with Cash (cont.)
Actor Action
System Response
7. The Customer gives a cash payment
possibly greater than the sale total.
8. The Cashier records the cash received
amount.
9. Shows the balance due back to the
Customer & generate a receipt.
10. The Cashier deposits the cash
received & extracts the balance
owing. The Cashier gives the balance
owing, & the printed receipt to the
Customer.
11. Logs the completed sale.
12.The Customer leaves with the items
purchased.
Alternatives:
Line 2. Invalid identifier entered. Indicate errors.
Line 7. Customer didn’t have enough cash. Cancel sales transaction.
24
Expanded Use Case - Essential vs. Real Types
Example 1: Buy Items with Cash
Essential use case
Actor Action
This Cashier records the identifier for
each item.
System Response
Determines the item price & adds the
item information to the running sales
transaction. The description and the
price of the items are presented.
Real use case
Actor Action
For each item, the Cashier types in the
UPC field of Window1. They then press
“Enter Item” button with the mouse or
Enter key.
System Response
Display the item price & adds the item
information to the running sales
transaction. The description & price of
the current item are displayed in
Textbox 2 of Window1.
25
Expanded Use Case - Essential vs. Real Types
Example 2: ATM Withdraw Cash
Essential use case
Actor Action
This Customer identifies themselves.
System Response
Presents options.
Real use case
Actor Action
System Response
1. The Customer inserts his card.
2. Prompts for PIN.
3. Enter PIN on keypad.
4. Display options menu.
26
Identifying Use Cases
Either by:
Type1: Actor based
• Identify the actors related to an organization.
• For each actor, identify the processes they
initiate or participate in.
Type 2: Event based
• Identify the external events that a
system must respond to.
• Relate the events to actors and use
cases.
Example:
Cashier
Log in, Cash out.
Customer
Buy items, Refund items.
27
Use Cases = Processes

A use case describes a process, such as business process.

A process describes, from start to finish, a sequence of events, actions and
transactions required to produce or complete something of value.

Example:
•
•
•
•
•
Withdraw cash from an ATM.
Order a product.
Register for courses at a school.
Check the spelling.
Handle a call.
28
Decision Point & Branching

A Use case may contain decision points such as in Buy Items, the customer may choose
to pay via cash, credit or check.

If one of them is the typical case (usual), then the typical case is the one written in
Typical course of events, and the other alternatives should be written in the Alternatives
section.

If all the alternatives are equal in their likelihood, (like the payment types), write in the
main section of Typical course of events a branch event, that indicates that the possible
branches are written in subsections.

Then write a subsection for each branch, again using Typical course of events.

If subsections have alternatives, write them in an Alternatives section.
29
Decision Point & Branching
Example: Buy items
Section: Main
Actor Action
System Response
1. This use case begins when a Customer arrives at
POST checkout with items to purchase.
2. …..
3. Customer chooses payment type:
a. If cash payment, see section pay by Cash.
b. If credit payment, see section pay by Credit.
c. If check payment, see section pay by Check.
4. Logs the completed sale.
5. Print the receipt.
6. The cashier gives the receipt to the customer.
7. The customer leaves with the items.
30
Decision Point & Branching
Example: Buy items (cont.)
Section: Pay by cash
Actor Action
System Response
1. The customer gives a cash payment- possible
greater than the sale total.
2. The Cashier records the cash tendered.
3. Shows the balance due back to the
Customer.
4. The Cashier deposits the cash received and extracts
the balance owing.
The Cashier gives the balance owing to the
Customer.
Alternatives:
Line 4. Insufficient cash in drawer to pay balance. Ask for cash from supervisor or ask
Customer for a payment closer to sale total.
31
Plan and Elaborate Phase Steps
1. Define system function.
2. Define system boundary, actors & use cases.
3. HL use cases.
4. Draw use case diagram.
5. Expand critical use cases (Essential / Analysis).
6. Real use case (Design).
7. Rank use case (not discussed).
32
Example 1
2- Define actors and use cases:
Cashier
Log in, Cash out.
Customer
Buy items, Refund items.
Manager
Start up, Shut down.
System Administrators
Add new users.
33
Example 1 (cont.)
3- Use cases in HL format:
Use Case: Buy Items
Actors: Customer (initiator), Cashier
Type: Primary
Description: A Customer arrives at a checkout with items to purchase. The Cashier
records the purchase items and collects a payment. On completion, the Customer
leaves the store with the items.
Use Case: Start Up
Actors: Manager
Type: Primary
Description: A Manager powers on a POST in order to prepare it for use by Cashiers.
The Manager makes sure the date and time are correct, after which the system is
ready for Cashiers’ use.
34
Example 1 (cont.)
4- Use cases diagram:
35
Example 1 (cont.) 5- Expand critical use cases:
36
Example 1 (cont.) 5- Expand critical use cases:
37
Example 1 (cont.) 5- Expand critical use cases:
38
Example 2
Use Case: Make a book Entry
Use Case: UC1 - Make Book Entry
Actor: Library clerk
Success Scenario:
A library clerk accesses a terminal in order to enter one or possibly many
book entries in a database. At the end of every entry, the system
displays a confirmation message. At the end of the session the system
would display an informative message.
39
Example 2 (cont.)
Use Case Diagram
40
The <<extends>> Relationship

<<extends>> relationships represent exceptional or seldom invoked cases.

A reusable use case (component) that conditionally interrupts (is invoked optionally - like a
menu selection in an application) the execution of another use case to augment its
functionality.

The functionality in the original problem statement needs to be extended.

The exceptional event flows are factored out of the main event flow for clarity.

The base use case can be executed without the use case extension in extend associations.

The responsibility for deciding when the extending use case should be used lies with the
extending use case.

Arrow points to use case being extended.
41
The <<extends>> Relationship

Use cases representing exceptional flows can extend more than one use case.

The direction of an <<extends>> relationship is to the extended use case.

For example: the use case “ReportEmergency” is complete by itself, but can be
extended by the use case “Help” for a specific scenario in which the user requires
help.
42
The <<extends>> Relationship

Major variation: If you have a major alternative path in the use case, and it’s
complex enough to have its own alternative paths, then placing it on your diagram
will honestly expose the complexity - which is helpful in costing, assignment and
scheduling.

Optional subgoal: If you have parts of the use case that would be optional to
implement (or even optional to execute) to meet the actor’s goals, put those parts
into their own use case. Doing so clarifies the relationships between actors and
their goals. It also emphasizes that you may deliver these optional goals in later
releases.
43
The <<extends>> Relationship
44
The <<extends>> Relationship
45
The <<extends>> Relationship
46
The <<extends>> Relationship
47
The <<extends>> Relationship
48
The <<include>> Relationship

<<includes>> relationship represents behavior that is factored out of the use case.

A use case uses another use case (“functional decomposition”).

Used to indicate that one use case includes the functionality of another use case.

A function in the original problem statement is too complex to be solvable immediately.

Describe the function as the aggregation of a set of simpler functions. The associated
use case is decomposed into smaller use cases.

A reusable use case (component) that is unconditionally called into the execution of
another use case (always included in the process – like running BIOS in a system boot).
49
The <<include>> Relationship

Responsibility for the decision about when to use it lies with the calling use case.

Arrow points to the included use case. The direction of a <<includes>> relationship is to
the using use case (unlike <<extends>> relationships).
50
The <<include>> Relationship
51
The <<include>> Relationship
52
The <<include>> Relationship
53
Generalization/Specialization Relationship

Called inheritance relationship.

Occurs when there is a general sequence of events, but when considering the details,
there are many specialised variations of the use case.

Graphically, this is shown by a generalisation line pointing from the specialised use case
to the more general use case.
54
Actor Generalization
55
Actor Generalization
56
Actor Generalization