A Student Guide to Object-

Orientated Development

Chapter 3 Use Cases

Use Cases
 Use cases model the user’s view of
the functionality of a system. Each
use case represents a task or major
chunk of functionality.
Use Cases
 The use case model consists of:
 a use case diagram
 a set of scenarios
 a set of uses case descriptions
 actors and actor descriptions.
Use Case Diagram
 The use case diagram models the
problem domain graphically using 4
concepts:
 the use case: Collection of all possible sequences of
interactions between the system and actors related to a
particular goal.
 the actor: All external entities that interact with a system
 the relationship link and
 the boundary.
Use Case Notation

Print
invoice

We start each use case label with a verb making the point
that the use case represents a major piece of functionality in
the system e.g. Maintain customer, Create order, Print
invoice.
Identifying use cases
 A use case describes a cohesive piece of the system’s
functionality as the user perceives it.
 A use case should represent a complete process; one end
to end pass through the system, a job that the user sits
down at the computer to achieve at one go.
 What we do when identifying use cases is to divide up the
system’s functionality into chunks; the main areas of
functionality. But what dictates the split is what the user
sees as the separate jobs or processes that he will use the
system to achieve.
 The user may see a chunk of functionality as a task that he
uses the system to achieve, one of the jobs that make up
his daily workload, or it may produce a list or report he gets
from the system.
 Each use case must have a goal – something it achieves for
the user.
An Actor

Receptionist

An actor represents any user or thing that interacts with

the system.
An actor represents a role not a person.
Actors identified in the use case diagram represent users
who interact with the system in some way, who use the
system to achieve a particular task.
Each actor may represent several different people.
Actors
 Use cases divide the world into two
parts: the system and all entities
external to the system.
 The external entities are actors.
Kinds Of Actors
 Users
– This includes all human users including targeted
end-users, administrators, manager, and
customers.
 Applications
– This includes all systems and programs that
interact with the system.
 Devices
– Normally this does not include things like
keyboards or mice, but deals with sensors and
actuators.
 External Events
– Periodic triggers such as a clock
A Sample Use Case Diagram: A University Course
Registration System

Login

Registrar Maintain Professor Information

View Report Card

Student
Register for Courses Maintain Student Information

Close Registration Billing System

Select Courses to Teach

Professor

Submit Grades
 Use Case Diagrams (Watch)
Package
SimpleWatch

Actor
ReadTime

SetTime
WatchUser WatchRepairPerson

Use case ChangeBattery

Use case diagrams represent the functionality of a system

from user’s point of view
Use Case Relationship

Is s ue bike
Receptionis t

This relationship is known as a

communication relationship
Boundary – separates use cases from
actors

Issue bike

Receptionist
Wheels use case diagram
Use Case Modeling: Core Elements
Construct Description Syntax
use case A sequence of actions, including
variants, that a system (or other UseC aseNam e

entity) can perform, interacting with

actors of the system.
actor A coherent set of roles that users
of use cases play when interacting
with these use cases.
A ctorN am e

system Represents the boundary between

boundary the physical system and the actors
who interact with the physical
system.
 Use Case Modeling: Core Relationships
Construct Description Syntax
association The participation of an actor in a use
case. i.e., instance of an actor and
instances of a use case communicate
with each other.
generalization A taxonomic relationship between a
more general use case and a more
specific use case.
extend A relationship from an extension use
<<extend>>
case to a base use case, specifying
how the behavior for the extension
use case can be inserted into the
behavior defined for the base use
case.
 Use Case Modeling: Core Relationships
(cont’d)

Construct Description Syntax

include A relationship from a base use case to
an inclusion use case, specifying how <<include>>

the behavior for the inclusion use

case is inserted into the behavior
defined for the base use case.
Example: Use Case Relationships
Supply Order
Customer Data Product Arrange
Payment

«include» «include» «include»

Place Order

Extension points «extend»

1 * additional requests : the salesperson asks for
after creation of the order the catalog

Request
Catalog

UML and C++ A Practical Guide UML Notation Guide

To Object-Oriented Development
Use Case Relationships - Include

<<include>>
Order Check
goods customer
credit

An include relationship between uses cases indicates

where one use case always includes the behavior of
another, the use case ‘Order goods’ always
incorporates a credit check
Use Case Relationships - extend

<<extend>>
Chase Issue
payment warning
letter

An extend relationship between two use case indicates

alternative behaviour; the use case ‘Chase payment’
sometimes calls the issue warning letter use case but not
always.
Scenarios
A sequence of interactions between the
user and the system.
 To achieve a specified goal
 Eachuse case represents a group of
scenarios
 Eachscenario describes a different
sequence of events involved in achieving
the goal
Successful scenario – Wheels

 Stephanie chooses a mountain bike

 Annie sees that its number is 468
 Annie enters this number into the system
 The system confirms that this is a woman’s mountain bike
and displays the daily rate (£2) and the deposit (£60)
 Stephanie wants to hire the bike for a week
 Annie enters this and the system displays the cost
 Stephanie agrees this
 Annie enters Stephanie’s details
 Stephanie pays the £74
 Annie records this and the system prints out a receipt
Scenarios
A successful scenario, one that
achieves the use case goal, is
sometimes referred to as
 a ‘happy day’ scenario or
 the ‘primary path’.
Scenarios
Scenario for the situation where the use case goal
is not achieved

 Michael arrives at the shop at 12.00 on Friday

 He selects a man’s racer
 Annie see the number is 658
 She enters this number into the system
 The system confirms that it is a man’s racer
and displays the daily rate (£2) and the deposit
(£55)
 Michael says this is too much and leaves the
shop without hiring the bike.
The scenarios should document:

 a typical sequence of events leading to the

achievement of the use case goal – e.g. a
customer hires a bike
 obvious variations on the norm, e.g. a customer
hires several bikes
 sequences of events where the use case goal is
not achieved e.g. the customer cannot find the
bike he wants
 Ch 10
A Sequence Diagram

registration schedule available

John : form form courses
Student
1: enter id

2: validate id

3: enter current semester

4: create new schedule

5: display
6: get courses
Use Case Descriptions
 Theuse case description is a
narrative document that describes in
general terms the required
functionality of the use case. The
description is generic and should
encompass every sequence of
events, every scenario relating to the
use case.
 Use Case Descriptions – High Level
Descriptions
Use case: Issue bike
Actors: Receptionist
Goal: To hire out a bike

Description:
When a customer comes into the shop they choose a bike to
hire. The Receptionist looks up the bike on the system and tells
the customer how much it will cost to hire for a specified
period. The customer pays, is issued with a receipt, then leaves
with the bike.
Expanded Use Case Description
More detailed and structured than the high
level description and should document:
– what happens to initiate the use case
– which actors are involved
– what data has to be input
– the use case output
– what stored data is needed by the use case
– what happens to signal the completion of
the use case
– minor variations in the sequences of events.
Use case : Issue bike
Preconditions: ‘Maintain bike list’ must be executed.
Actors: Receptionist
Goal: To hire out a bike
Overview:
When a customer comes into the shop they choose a bike to hire. The receptionist looks
up the bike on the system and tells the customer how much it will cost to hire the bike for a
specified period. The customer pays, is issued with a receipt, then leaves with the bike.
Cross reference R3, R4, R5, R6,R7, R8, R9, R10
Typical course of events
Actor action System response

1. The customer chooses a bike

2. The Receptionist keys in the bike number 3. Displays the bike details
4. Customer specifies length of hire
5. Receptionist keys this in 6. Displays total hire cost
7. Customer agrees the price
8. Receptionist keys in the customer details 9. Displays customer details
10. Customer pays the total cost
11. Receptionist records amount paid 12. Prints a receipt

Alternative courses
Steps 8 and 9. The customer details are already in the system so the Receptionist needs
only to key in an identifier and the system will display the customer details.
Steps 7 – 12. The customer may not be happy with the price and may terminate the
transaction.
Actor descriptions

An actor represents one

particular way of using the
system; an actor represents the
role someone plays in the use
case – e.g. the Receptionist
issues the bike. It may be that
several people can play this role.
Actor Descriptions - Examples from
Wheels
The Receptionist uses the system to answer queries
about bike availability and cost, to issue a bike for
hire and to register a bike return. The
Receptionist can be the Shop Manager (Annie),
any of the mechanics or the owner (Mike).

 The Administrator uses the system to maintain

lists of customers and bikes. The administrator
can be the head mechanic, shop manager or shop
owner.
Use Case Diagram for Appointment System
(Level of Information)
Use Case Diagram for Appointment System
(Level of Information)
Extends or Uses Associations
 Actor Relationships
UML an Actor (even it is an
external system).
Bank Employee

UML Uses A Triangle To

Represent The Generalization
Relationship
Bank Teller Bank Manager

This figure illustrates that a Bank Teller and a Bank Manager are
both Bank Employees
Further Reading
 Bennett, S., McRobb, S. and Farmer, R. Object-Oriented
Systems Analysis and Design Using UML, 2nd Ed, London:
McGraw-Hill, 2002.
 Brown, D. Object-Oriented Analysis: objects in plain English,
New York: John Wiley, 1997.
 Fowler, M. UML Distilled: a brief guide to the standard object
modeling language, 2nd Ed, Reading Massachusetts: Addison-
Wesley, 2000.
 Larman, C. Applying UML and patterns: an introduction to
object-oriented analysis and design, New Jersey: Prentice
Hall, 1998.
 Lunn, K. Software Development with UML, Hampshire:
Palgrave Macmillan, 2003
 Stevens, P., with Pooley, R. Using UML. Software Engineering
with Objects and Components Updated edition, Harlow:
Addison-Wesley, 2000.