Use Case Diagrams

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 11

Slide
 Use Cases

What is a Use Case?
 A formal way of representing how a business system
interacts with its environment

 Illustrates the activities that are performed by

the users of the system

 A scenario-based technique in the UML

 A sequence of actions a system performs that yields a
valuable result for a particular actor.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 22

Slide
 Use Case Analysis

What is an Actor?
1. A user or outside system that interacts with
the system being designed in order to obtain
some value from that interaction

2. Use Cases describe scenarios that describe the

interaction between users of the system (the
actor) and the system itself.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 33

Slide
 Use Cases

 Use case diagrams describe what a system does from

the standpoint of an external observer. The emphasis is
on what a system does rather than how.

 Use case diagrams are closely connected to scenarios.

A scenario is an example of what happens when
someone interacts with the system.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 44

Slide
 Use Cases

Here is a scenario for a medical clinic.


A patient calls the clinic to make an appointment
for a yearly checkup. The receptionist finds the
nearest empty time slot in the appointment book
and schedules the appointment for that time slot. "


We want to write a use case for this scenario.

Remember: A use case is a summary of
scenarios for a single task or goal.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 55

Slide
 Use Cases


Step 1 Identify the actors

As we read the scenario, define those people or
systems that are going to interact with the
scenario.


A patient calls the clinic to make an appointment for a yearly checkup.
The receptionist finds the nearest empty time slot in the appointment
book and schedules the appointment for that time slot. "

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 66

Slide
 Questions for Identifying People Actors


Who is interested in the scenario/system?

Where in the organization is the scenario/system be
used?

Who will benefit from the use of the
scenario/system?

Who will supply the scenario/system with this
information, use this information, and remove this
information?

Does one person play several different roles?

Do several people play the same role?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 77

Slide
 Questions for Identifying Other Actors


What other entity is interested in the
scenario/system?

What other entity will supply the scenario/system
with this information, use this information, and
remove this information?

Does the system use an external resource?

Does the system interact with a legacy system?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 88

Slide
 Actors


An Actor is outside or external the system.

It can be a:
• Human
• Peripheral device (hardware)
• External system or subsystem
• Time or time-based event

Represented by stick figure

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 99

Slide
 Use Cases


A use case is a summary of scenarios for a
single task or goal.


An actor is who or what initiates the events
involved in the task of the use case. Actors
are simply roles that people or objects play.


So as we read our scenario, what or who is
the actor????

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 10
10
 Use Cases


So as we read our scenario, what or who is
the actor????


A patient calls the clinic to make an appointment for a yearly
checkup. The receptionist finds the nearest empty time slot in the
appointment book and schedules the appointment for that time
slot. "


The actor is a Patient.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 11
11
 Use Cases


The use case is a summary of scenarios for a
single task or goal.


So What is the Use Case????


The Use Case is Make Appointment.

It is a use case for the medical clinic.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 12
12
 Use Cases

The picture below is a Make Appointment use case for the medical
clinic.

The actor is a Patient. The connection between actor and use case
is a communication association (or communication for short).

Actors are stick figures. Use cases are ovals. Communications are
lines that link actors to use cases.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide
Slide 13
13
 Use Case Componentss


The use case task referred to as the use case
that represents a feature needed in a software
system.


The actor(s) who trigger the use case to activate.


The communication line to show how the actors
communicate with the use case.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 14
14
 Use Case Diagram - Use Case

 A major process performed by the system

that benefits an actor(s) in some way

 Models a dialogue between an actor and

the system

 Represents the functionality provided by

the system

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 15
15
 Use Case

Each use case in a use case
diagram describes one and only one
function in which users interact with
the system

• May contain several “paths” that a user

can take while interacting with the system
• Each path is referred to as a scenario

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 16
16
 Use Case

Labelled using a descriptive verb-noun
phrase

Represented by an oval

Make
Appointment

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 17
17
 Use Case - Actor

Labelled using a descriptive noun or
phrase

Represented by a stick character

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 18
18
 Use Case - Relationships

Relationships
• Represent communication between actor and
use case
• Depicted by line or double-headed arrow line
• Also called association relationship

Make
Appointment

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 19
19
 Use Case - Relationships

Boundary
• A boundary rectangle is placed around the
perimeter of the system to show how the actors
communicate with the system.

Make
Appointment

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 20
20
 Use-Case Diagram

A use case diagram is a collection of actors, use cases, and their

communications.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide
Slide 21
21
 Use Case Diagram

Other Types of Relationships for Use
Cases

• Generalization
• Include
• Extend

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 22
22
 Components of Use Case Diagram

Generalization Relationship
• Represented by a line and a hollow arrow
• From child to parent

Child use case Parent use case

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 23
23
 Use Case Diagram

Include Relationship
• Represents the inclusion of the functionality of
one use case within another

• Arrow is drawn from the base use case to the

used use case

• Write << include >> above arrowhead line

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 24
24
92
U
5s
e3 Include Relationship Between Use Cases
5
C
a1
s • Include relationship –
e a standard case linked to an mandatory use case.
S
y Example: to Authorize Car Loan (standard use case), a clerk must
s
run Check Client’s Credit History (include use case).
 tight coupling
e
m
s
• Standard use case can NOT execute without the include case.
A
n See next slide 

a
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide
Slide 25
25
 Use Case Diagram


Extend relationship
• Represents the extension of the use case
to include optional functionality

• Arrow is drawn from the extension

use case to the base use case

• Write << extend >> above arrowhead line

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 26
26
92
U
7s
Extend Relationship between Use Cases
e3
5
C
a1 • Extend relationship –
s
linking an optional use case to a standard use case.
e
S
y Example: Register Course (standard use case) may have

s Register for Special Class (extend use case).

e • Standard use case can execute without the extend case.

m  loose coupling
s
A See next slide 
n
a
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide
Slide 27
27
 Example of Relationships

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 28
28
92
U
9s
IncludeInclude
Relationship Between
Relationship Between Use Cases
Use Cases
e3
5
C
a1
s
e
S
y
s

e
m
s
A
n Careful: Arrows between Use Cases are NOT data flows!
a
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide
Slide 29
29
93
U
0s Extend Relationship Between Use Cases
e3
5
C
a1
s
e
S
y
s

e
m
s
A
n Careful: Arrows between Use Cases are NOT data flows!
a
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide
Slide 30
30
30
15
- Includes and Extends
U
s
e 
Includes

Extends
- • You have a piece of behavior • A use-case is similar to another
one but does a little bit more
C that is similar across many use
cases
a • Put the normal behavior in one
s • Break this out as a separate use-case and the exceptional
e use-case and let the other behavior somewhere else
ones “include” it • Capture the normal behavior
s • Try to figure out what can go wrong
in each step
• Examples include • Capture the exceptional cases in
• Valuation separate use-cases
• Validate user interaction
• Sanity check on sensor inputs • Makes it a lot easier to understand
• Check for proper authorization

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 31
31
 Use Case Relationships

Pro:
• Reduces redundancy in use cases
• Reduces complexity within a use case

Con
• May introduce complexity to use case
diagram

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 32
32
 Benefits of Use Cases

Use cases are the primary vehicle for requirements capture in


Use cases are described using the language of the customer
(language of the domain which is defined in the glossary)


Use cases provide an easily-understood communication mechanism


When requirements are traced, they make it difficult for
requirements to fall through the cracks


Use cases provide a concise summary of what the system should
do at an abstract (low modification cost) level.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 33
33
 Difficulties with Use Cases

As functional decompositions, it is often difficult to make the
transition from functional description to object description to
class design


Reuse at the class level can be hindered by each developer “taking a
Use Case and running with it”. Since UCs do not talk about classes,
developers often wind up in a vacuum during object analysis, and can
often wind up doing things their own way, making reuse difficult


Use Cases make stating non-functional requirements difficult (where do
you say that X must execute at Y/sec?)


Testing functionality is straightforward, but unit testing the particular
implementations and non-functional requirements is not obvious

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 34
34
 Use Case Model Survey

The Use Case Model Survey is to illustrate, in graphical
form, the universe of Use Cases that the system is
contracted to deliver.


Each Use Case in the system appears in the Survey with a
short description of its main function.
• Participants:
• Domain Expert
• Architect
• Analyst/Designer (Use Case author)
• Testing Engineer

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 35
35