COM 6030 Software

Analysis and Design

Lecture 6 - Use cases and activity diagrams
Dr Richard Clayton & Dr Marian Gheorghe
Module (1st part) homepage http://www.dcs.shef.ac.uk/~marian

COM6030 Systems

University of Sheffield

Outline

Use case model

ATM system specification
Activity diagrams
Workflow description using activity
diagrams

Reading: Bennett chapter 6; Stevens chapters 7, 11

COM6030 Systems

University of Sheffield

FirstUse
part
of the
course
case
model
A user-oriented approach on systems analysis.
Identify the users of the system and the tasks they
must undertake.
UML uses technical terms actors and use cases.
Actor = a user of the system in a particular role (an
actor might be an external system as well); a
customer in the ATM system is an actor.
Use case = is a task which an actor needs to
perform with the help of the system; withdraw cash
from ATM is a use case; use case may describe a
simple or a fairly complex behaviour.
COM6030 Systems

University of Sheffield

Use cases
Use cases were first proposed by Jacobson (1992) for capturing
requirements:
identify single user interactions with a system;
identify stakeholder interactions with a business;
not a good formalism for expressing control logic.
Idea is to elicit required system functionality. No prior knowledge of
system assumed:
interview the client, taking notes;
collect use cases (i.e. scenarios, examples of usage);
concentrate initially on normal flow of events;
later, look for alternative or exceptional flows;
structure the model afterwards.

COM6030 Systems

University of Sheffield

Use cases
A use case is: "a single complete interaction of a user with a
system that delivers a result of observable value"
i.e. the smallest-level business task that has meaning and
delivers something of value for the user.
Limits:
single complete interaction - accomplishes a single objective, not
multiple (upper bound);
result of observable value - accomplishes a business function,
not a code instruction (lower bound).

Positive examples:
Deliver goods, Pay Invoice, Process order.

Negative examples:
Enter password, Increase productivity, Quit menu.

COM6030 Systems

University of Sheffield

Natural language
representations
There is deliberately no specified format. Natural
language representations can be:
informally structured descriptions
pseudocode with pre, post-conditions

Aim to use consistent style if at all possible.

Adopt format that is appropriate for type of scenario
in business system, may be terse or verbose.
Remember
inherent ambiguity in natural language, use cases should
be reviewed critically with client;
use cases are a description of interactions from the
users perspective.

COM6030 Systems

University of Sheffield

ATM example natural

language
Name:
Insert card and validate PIN
Type:
Functional
Description: Inserts the card; validates the PIN entered by the user
against the central record held on the bank system.
Returns an output indicating that the PIN is either
correct or incorrect. If the PIN is correct then the session
can continue. If the PIN is not correct then the session
will terminate, and the card should be returned to the
user.

Inputs:
PIN, bank system record.
Outputs:
PIN correct, PIN incorrect.
Criticality:
Validation of PIN is a key component of ATM function.
Risk:
Very high.
Dependencies: User input, communication with bank system.

COM6030 Systems

University of Sheffield

Use cases a summary

Use cases describe who (actor) does what
(interaction) with the System, for what purpose
(goal).
A complete set of use cases
Specifies all the different ways to use the system
Defines all the behaviour required of the system

Use cases are used to construct use case diagrams.

These are a formal description, defined as part of
the UML.
COM6030 Systems

University of Sheffield

UML use case diagram

syntax
Actor participant in use case; usually
a
user of the system, may not be a
human.
Cash
withdraw
from ATM

An individual use case.

Communication association.
Generalisation relationship.
Dependency relationship.
<<extend>
>

A stereotyped model element.

System or subsystem boundary.

COM6030 Systems

University of Sheffield

Actors
Actors are a fundamental component of Use Case diagrams
An actor interacts with a system to produce an observable result.
Actors are often users of a system.
Names correspond to role of actor in use case.
Actors may not necessarily be human.
A generalisation relationship may exist between actors. X is a
generalisation of Y if Y-is-a-X.
University
employee

Actor

Buyer Seller
Broker
Three actors in an
estate agency

COM6030 Systems

University employee is a
generalisation of
academics. All
academics are university
employees, but not all
university employees are
academics.

Academic
10

University of Sheffield

Use cases
System
ATM system
Actor - human

Insert card &

validate PIN

Actor
another
system

Manage
PIN

Customer

Use case

COM6030 Systems

Get
balance

Withdraw
cash

11

Bank
One can
distinguish a
Card Manager
actor

University of Sheffield

Use cases using

generalisations
ATM system

Insert card &

validate PIN

Transaction

Manage
PIN
Customer

Bank
Get
balance
Withdraw
cash

COM6030 Systems

12

University of Sheffield

Generalisations
A generalisation relationship may exist between use cases as
well as actors.
X is a generalisation of Y if Y-is-a-X.
Direction of generalisation is from specific to general.
For ATM system
Transaction
Bank

Get
balance

COM6030 Systems

Card manager
13

University of Sheffield

Requirements review
The system is specified as a set
of subsystems (only one for
ATM system).
Each subsystem consists of
a list of actors and their roles;
a list of use case descriptions;
associated use case diagrams;
activity diagrams (next slides)
optional.

Actor descriptions
Customer

Any card holder accessing an

ATM.

Bank

The bank system that

manages customers accounts.

Card
Manager

The bank system that

manages accounts and cards.

Use case descriptions

Insert card
&validate PIN

Inserts card; validates the PIN entered by the user against the central
record held on the bank system. Returns an output indicating that the PIN
is either correct or incorrect. If the PIN is correct then the session can
continue. If the PIN is not correct then the session will terminate, and the
card should be returned to the user.

Manage PIN

..

Get balance

Withdraw cash

COM6030 Systems

14

University of Sheffield

Use cases for requirements

capture
Use cases can help with requirements capture by providing a
structured way to deal with it:
Identify the actors.
For each actor find out:

what they need from the system their associated use cases;
other interactions which use cases they might take part in for
someone elses benefit.

Possible problems with use cases:

Build a system in a non-object oriented manner (functional
approach).
Danger of thinking too operationally; users describe the use
cases as a sequence of interactions in a given order, maybe not
the right one leads into design.
Danger of missing requirements by focusing too much on finding
actors and their uses cases; can be lessened by doing use case
analysis and conceptual class modelling in parallel.

COM6030 Systems

15

University of Sheffield

Activity diagrams
Activity diagrams are useful to
describe an overall workflow of an area of the customers activities;
specify how individual use cases unfold and may depend on other
use cases (all transactions of an ATM follow PIN validation);
represent how an operation (see object specifications) could be
implemented.
The fundamental block is an activity; a transition out of an activity
normally means that the activity has been completed.

Insert card

COM6030 Systems

Validate
PIN

16

University of Sheffield

Elements of activity
diagrams
Validate PIN

An activity a sort of state which is left

when the activity it represents is finished.
A transition a non-labelled arrow; it
might have a guard.
A synchronisation bar expresses either
waiting for all subtasks to finish before
proceeding (join) or starting several
subtasks in parallel (fork).
A decision diamond a non-labelled
arrow; it might have a guard.
A start marker points to the initial
activity.
A stop marker indicates the end task.

COM6030 Systems

17

University of Sheffield

Activity diagrams - example

Insert card & validate PIN:
Inserts card; validates the PIN entered by the user against the central record held
on the bank system. Returns an output indicating that the PIN is either correct or
incorrect. If the PIN is correct then the session can continue. If the PIN is not correct
then the session will terminate, and the card should be returned to the user.

Insert card

Validate PIN

[incorrect PIN]
[correct PIN]
Receive card

Transaction

It also shows that a transaction is executed after the

PIN is validated against the central record.

COM6030 Systems

18

University of Sheffield

Partitions and swimlanes

When activity diagrams contain several groups of related activities (belong to the
same objects, use cases etc) they can be split into partitions known as swimlanes.
ATM Insert card & validate PIN:
Customer

ATM system
Insert card

Validate PIN

[incorrect PIN]
[correct PIN]
Receive card

COM6030 Systems

Transaction

19

University of Sheffield

Summary
Two key UML diagrams for requirements
analysis: use cases and activity diagrams.
Requirements specification using use case
diagrams and natural language description.
Activity diagrams to specify formally a use
case description and to show
interdependences among use cases.
COM6030 Systems

20

University of Sheffield