UML

Use Case Modeling

Minder Chen, 1994-2004

Use Case - 1

Objectives
Identify actors from a problem statement.
Identify use cases from a problem statement.
Learn how to create a use-case diagram that
accurately models the system.
Learn how to write use-case specification,
glossary, and supplementary specification
document.

Minder Chen, 1994-2004

Use Case - 2

The Purpose of the Requirements Discipline

The Requirements discipline intends to:
Find agreement on what the system should do.
Provide a better understanding of the system
requirements.
Define the boundaries of the system.
Provide a basis for planning the technical contents
of iterations.
Provide a basis for estimating cost.
Define a user-interface for the system.

Minder Chen, 1994-2004

Use Case - 3

Requirements in the Context of SDLC or RUP

Minder Chen, 1994-2004

Use Case - 4

Relevant Requirements Deliverables or Artifacts

Use-Case Model

Glossary
Actors
Use Cases

...

Supplementary
Specification

Use-Case Specifications
Minder Chen, 1994-2004

Use Case - 5

What Is a Use-Case Model?

A model that describes a
systems functional
requirements in terms of
use cases.
A model of the systems
intended functionality (use
cases) and its
environment (actors).

View Report
Card

Student

Register for
Courses

Login
Minder Chen, 1994-2004

Use Case - 6

What is Use Case Modeling?

A a view of a system that emphasizes the
behavior as it appears to outside users. A use
case model partitions system functionality into
transactions (i.e., use cases) that are
meaningful to users (i.e., actors).
System behavior is how a system acts and
reacts.
It is an outwardly visible and testable activity of a
system.

System behavior is captured in use cases.

Use cases describe the system, its environment,
and the relationship between the system and its
environment.
Minder Chen, 1994-2004

Use Case - 7

Usages of a Use Case Model

Minder Chen, 1994-2004

Use Case - 8

The software development life cycle

Minder Chen, 1994-2004

Use Case - 9

Use Case Granularity

Source: [Link]

Minder Chen, 1994-2004

Use Case - 10

Major Concepts in Use-Case Modeling

An actor represents anything
that interacts with the system.
A use case defines a set of usecase instances, where each
instance is a sequence of
actions a system performs that
yields an observable result of
value to a particular actor.

Actor

Use Case

Minder Chen, 1994-2004

Use Case - 11

What Are the Benefits of Use-Case Models?

Used to communicate with the end users and domain
experts

Provides buy-in at an early stage of system development

Insures a mutual understanding of the requirements

Used to identify

Who interacts with the system and what the system should do
The interfaces the system should have

Used to verify

All requirements have been captured

The development team understands the requirements

Minder Chen, 1994-2004

Use Case - 12

System Surroundings and Actors

Users who execute the systems
Main functions
Secondary functions, such as system
administration

External hardware that the system uses

Other systems interacting with the system

Minder Chen, 1994-2004

Use Case - 13

Useful Questions in Finding Actors

Who will supply, use, or remove information?

Who will use this functionality?
Who is interested in a certain requirement?
Where in the organization is the system
used?
Who will support and maintain the system?
What are the systems external resources?
What other systems will need to interact with
this one?

Actor

Minder Chen, 1994-2004

Use Case - 14

Actors and Roles

An actor represents a role that a human, hardware device,
or another system can play.
The difference between an actor and an individual system
user is that an actor represents a particular class of user
rather than an actual user.
Actor names should clearly denote the actors role
Actor description:

Area of responsibility
Dependency of the actor on the system
Minder as
Professor

Professor

A User May Have Different Roles

Minder as
Student
Minder Chen, 1994-2004

Student
Use Case - 15

Use Case Modeling: Core Elements

Construct Description
use case

actor

A sequence of actions, including

variants, that a system (or other
entity) can perform, interacting with
actors of the system.
A coherent set of roles that users
of use cases play when interacting
with these use cases.

Syntax

U seC aseN am e

A c to rN a m e

system
boundary

Minder Chen, 1994-2004

Represents the boundary between

the physical system and the actors
who interact with the physical
system.

Use Case - 16

Use Case Modeling: Core Relationships

Construct

Description

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.
extend
A relationship from an extension use
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.
generalization A taxonomic relationship between a
more general use case and a more
specific use case.

Syntax

association

Minder Chen, 1994-2004

<<extend>>

Use Case - 17

Use Case Modeling: Core Relationships (contd)

<<include>>

Minder Chen, 1994-2004

Use Case - 18

Example: Online HR System

O n lin e H R S y s te m
L o c a te
E m p lo y e e s

U p d a te
E m p lo y e e
P r o file

{ if c u r r e n t M o n th = O c t. }

U p d a te B e n e fits

E m p lo y e e

H e a lth c a r e P la n S y s te m

{ r e a d O n ly }

A c c e s s T ra v e l
S y s te m

Access P ay
R e c o rd s

Minder Chen, 1994-2004

M anager

In s u r a n c e P la n S y s te m

Use Case - 19

Case Study: Course Registration Problem Statement

Course Registration Problem Statement
(From Visual Modelling with Rational Rose and UML, Terry Quatrani 1998)

The university will require a new Course Registration system. At the

beginning of each semester, professors at the university will register
the courses that they are going to teach with the system. The system
then will allow students to request a course catalogue containing a
list of course offerings for the coming semester. Information about
each course such as professor, department and prerequisites are
included. The student then can select four-course offering. Once the
registration process is completed for a student, the registration
system sends information to the billing system so the student can be
billed for the semester. For each semester, there is a period of time
that students can change their schedule through adding or dropping
courses. Professors must be able to access the system to indicate
which courses they will be teaching and to see which students signed
up for their course offerings.

Minder Chen, 1994-2004

Use Case - 20

Practice: Find the Actors

In the Course Registration System
Requirements document, read the Problem
Statement for the Course Registration case
study.
As a group, identify the following:
Actors
Description of the actor

Minder Chen, 1994-2004

Use Case - 21

Finding Use Cases: Focus on the Actor

The system exists only for its users
Use cases should be based on the users needs
Answer the following questions to find use
cases.

For each actor you have identified, what are the

tasks the system would be involved in?
Does the actor need to be informed about certain
occurrences in the system?
Will the actor need to inform the system about
sudden, external changes?
What information must be modified or created in
the system?

Minder Chen, 1994-2004

Use Case - 22

MOT Analysis Example: Credit Card

Pri to MOT

MOT: Moment of Truth

Recognition
Information gathering
Comparison

MOT

Applying for Credit Card

Receiving Credit Card
Using Credit Card
Providing Information
Changing and Upgrading
Gifts giving
Emergency Assisting

After MOT

No usage follow-up
Stop membership follow-up

Minder Chen, 1994-2004

Use Case - 23

Practice: Solution

Billing
System

The external system

responsible for
student billing
Student
A person who is
teaching classes at
the University

Course
Catalog

Professor

Registrar

A person who is
registered to take
courses at the
University
The unabridged
catalog of all
courses offered by
the University

The person who is

responsible for the
maintenance of the
course registration
system

Minder Chen, 1994-2004

Use Case - 24

Name Use Cases

Register for
Courses

The name indicates what is

achieved by its interactions
with the actor(s).
The name may be several
words in length.
No two use cases should have
the same name.

Login
Maintain Student
Information
Minder Chen, 1994-2004

Use Case - 25

Practice: Finding Use Cases

In the Course Registration System
Requirements document, read the Problem
Statement for the Course Registrations case
study.
As a group, using the actors identified in the
earlier practice session, identify the following:
Use Cases
Use-Case names

Minder Chen, 1994-2004

Use Case - 26

Practice: Solution

Register for
Courses

View Report
Card

Submit
Grades

Maintain
Professor
Information

Minder Chen, 1994-2004

Login

Maintain
Student
Information

Select Courses
To Teach

Close
Registration

Use Case - 27

Use Cases and Actors

A use case models a dialog between actors and
the system.
A use case is initiated by an actor to invoke a
certain functionality in the system.

a use case:
. . .describes a sequence of actions,
performed by a system, that yields a
result of value to the user.

Minder Chen, 1994-2004

Use Case - 28

Concept: Communicate-Association
Use cases and actors interact by sending
signals to one another.
To indicate such interactions, use a
communicate-association.

Use Case

Actor
Communicate-Association

Minder Chen, 1994-2004

Use Case - 29

Practice: Use Case and Actor Communication

In the Course Registrations System
Requirements document, read the Problem
Statement for the Course Registration case
study.
As a group, using the actors and use cases
identified in the earlier practice session,
identify:
Communicate-associations between the actors and
the use cases.

Minder Chen, 1994-2004

Use Case - 30

Use Case and Actor Communication

View Report Card

Student
Register for Courses

Course Catalog

Maintain Professor Information

Login
Maintain Student Information
Select Courses to Teach
Registrar
Professor

Close Registration

Submit Grades

Billing System

Minder Chen, 1994-2004

Use Case - 31

Develop a Library System Use Cases Exercise

Identify actors
Determine major use major use cases
Draw a use case diagram

The library system is designed for a local public library.

Minder Chen, 1994-2004

Use Case - 32

Use-Case Specifications

Name
Brief description
Flows of Events
Relationships
Activity diagrams
Use-Case diagrams
Special requirements
Pre-conditions
Post-conditions
Other diagrams

Use-Case
Model

Actors
Use Cases

...
Use-Case Specifications

Minder Chen, 1994-2004

Use Case - 33

Use Case Description: Change Flight

Actors: traveler, client account db, airline reservation system
Preconditions:

Basic course

Traveler has logged on to the system and selected change flight

itinerary option
System retrieves travelers account and flight itinerary from client
account database
System asks traveler to select itinerary segment she wants to
change; traveler selects itinerary segment.
System asks traveler for new departure and destination information;
traveler provides information.
If flights are available then

System displays transaction summary.

Alternative courses

If no flights are available then

Minder Chen, 1994-2004

Use Case - 34

Use Case Flow of Events

Has one normal, basic flow Happy Case
Several alternative flows
Regular variants of the basic flow
Odd cases
Exceptional flows handling error situations

Minder Chen, 1994-2004

Use Case - 35

What Are Scenarios?

A scenario is an instance of a use case

Minder Chen, 1994-2004

Use Case - 36

Glossary
Course Registration System Glossary
[Link]
This document is used to define terminology specific to the problem
domain, explaining terms, which may be unfamiliar to the reader of the
use-case descriptions or other project documents. Often, this document
can be used as an informal data dictionary, capturing data definitions so
that use-case descriptions and other project documents can focus on
what the system must do with the information.
[Link]

Glossary

The glossary contains the working definitions for the key concepts in the
Course Registration System.
2.1Course: A class offered by the university.
2.2Course Offering: A specific delivery of the course for a specific
semester you could run the same course in parallel sessions in the
semester. Includes the days of the week and times it is offered.
2.3Course Catalog: The unabridged catalog of all courses offered
by the university.

Minder Chen, 1994-2004

Use Case - 37

Supplementary Specification

Functionality
Usability
Reliability
Performance
Supportability
Design constraints
Supplementary
Specification
Online Resource:
[Link]

Minder Chen, 1994-2004

Use Case - 38

Verify a Use Case Model

Is the use-case model understandable?
By studying the use-case model, can you form a clear
idea of the system's functions and how they are
related?
Have all functional requirements been met?
Does the use-case model contain any superfluous
behavior?
Is the division of the model into use-case packages
appropriate?

Minder Chen, 1994-2004

Use Case - 39

Verify Actors
Have all the actors been identified?
Is each actor involved with at least one use case?
Is each actor really a role? Should any be merged or
split?
Do two actors play the same role in relation to a use
case?
Do the actors have intuitive and descriptive names? Can
both users and customers understand the names?

Minder Chen, 1994-2004

Use Case - 40

Verify Use Cases

Is each use case involved with at least one actor?
Is each use case independent of the others?
Do any use cases have very similar behaviors or flows
of events?
Do the use cases have unique, intuitive, and
explanatory names so that they cannot be mixed up at a
later stage?
Do customers and users understand the names and
descriptions of the use cases?

Minder Chen, 1994-2004

Use Case - 41

Verify Use-Case Specifications

Is it clear who wishes to perform a use case?
Is the purpose of the use case also clear?
Does the brief description give a true picture of
the use case?
Is it clear how and when the use-case's flow of
events starts and ends?
Does the communication sequence between
actor and use case conform to the user's
expectations?
Are the actor interactions and exchanged
information clear?
Are any use cases overly complex?

Minder Chen, 1994-2004

Use Case - 42

Verify Glossary
Does each term have a clear and concise definition?
Is each glossary term included somewhere in the usecase descriptions?
Are terms used consistently in the brief descriptions of
actors and use cases?

Minder Chen, 1994-2004

Use Case - 43

Library System Use Case

A library contains books and journals. The task is to develop a
computer system for borrowing books. In order to borrow a book
the borrower must be a member of the library. There is a limit on the
number of books that can be borrowed by each member of the library.
The library may have several copies of a given book.
It is possible to reserve a book.
Some books are for short term loans only. Other books may be
borrowed for 3 weeks. Users can extend the loans.
1. Draw a use case diagram for a library system.
2. Give a use case description for two use cases:
Borrow a copy of a book
Extend the loan of a book
[Link]

Minder Chen, 1994-2004

Use Case - 44

Step Wise Refinement of Use Case Model

The eight basic steps to generate use cases model for each
business process area:
Step 1: Confirm actors and goals.
Have all actors and their goals been identified?
Which actors can be generalized (combined)?
Which goals are potential use cases?

Step 2: Develop an outline of the use case(s).

For the goals identified as potential use cases, what are the key pieces?
For each outline level, what are key data?
Outline all use cases.
Prioritize the use-case flows.
Decide on a final use-case list (for initial pass).

Step 3: Write a brief description of the use case(s).

What two or three sentences describe all actors and the basic flow?
Generate content first, and worry about wordsmithing it later.

Step 4: Detail the basic flow.

What event starts the use case?

How does the use case end?
How does the use case repeat some behavior?
What is the "happy" (best case) path?
There is one and only one basic flow.

Minder Chen, 1994-2004

Use Case - 45

Step Wise Refinement of Use Case Model

Step 5: Detail the alternate flows.

Are there optional situations for the use case?

What might go wrong?
What might not happen?
Which resources might be blocked?
Which alternate flows are special perhaps nonfunctional
requirements (i.e., they apply to this use case only)?

Step 6: Review the use case(s).

Are there more use cases?

Should some use cases be redefined?
Which ones can be combined?

Step 7: Record pre- and post-conditions.

What was the previous state before this use case comes into play?
What happens once the use case is complete?

Step 8: Develop generalizations for all use cases.

Determine shared content and process for the use cases.

What items have been noted for the glossary or as global business rules?
Who has the most recent and accurate source document?
Where is it located?

Minder Chen, 1994-2004

Use Case - 46

Reminders
Write something readable.

Casual, readable use cases are still useful whereas unreadable use
cases wont get read.

Work breadth-first, from lower precision to higher precision.

Precision Level 1: Primary actors name and goal

Precision Level 2: The use case brief; or the main success scenario
Precision Level 3: The extension conditions
Precision Level 4: The extension handling steps

For each step:

Show a goal succeeding.

Capture the actors intention, not the user interface details.

Have an actor pass information, validate a condition, or update state.

Write between-step commentary to indicate step sequencing (or lack
of).
Ask why to find a next-higher level goal

For data descriptions (only put Precision Level 1 into the use case
text):

Precision Level 1: Data nickname

Precision Level 2: Data fields associated with the nickname
Precision Level 3: Field types, lengths, and validations

Source: Writing Effective Use Cases by Alistair Cockburn, 2001, Addison-Wesley

Minder Chen, 1994-2004

Use Case - 47

The Writing Process

1. Name the system scope and boundaries.
Track changes to this initial context diagram with the in/out list.

2. Brainstorm and list the primary actors.

Find every human and non-human primary actor, over the life of the
system.

3. Brainstorm and exhaustively list user goals for the

system.
The initial Actor-Goal List is now available.

4. Capture the outermost summary use cases to see who

really cares.
Check for an outermost use case for each primary actor.

5. Reconsider and revise the summary use cases. Add,

subtract, or merge goals.
Double-check for time-based triggers and other events at the
system boundary.

6. Select one use case to expand.

Consider writing a narrative to learn the material.

Source: Writing Effective Use Cases by Alistair Cockburn, 2001, Addison-Wesley

Minder Chen, 1994-2004

Use Case - 48

Continued
7. Capture stakeholders and interests, preconditions and
guarantees.
The system will ensure the preconditions and guarantee the
interests.

8. Write the main success scenario (MSS).

Use 3 to 9 steps to meet all interests and guarantees.

9. Brainstorm and exhaustively list the extension

conditions.
Include all that the system can detect and must handle.

10. Write the extension-handling steps.

Each will end back in the MSS, at a separate success exit, or in
failure.

11. Extract complex flows to sub use cases; merge trivial

sub use cases.
Extracting a sub use case is easy, but it adds cost to the project.

12. Readjust the set: add, subtract, merge, as needed.

Check for readability, completeness, and meeting stakeholders
interests.
Minder Chen, 1994-2004

Use Case - 49

Review Questions

What are the main artifacts of requirements?

What are the requirements artifacts used for?
What is a use-case model?
What is an actor?
What is a use case?
What is the difference between a scenario and
a use case?

Minder Chen, 1994-2004

Use Case - 50

Exercise
Create a payroll system for restaurants and hotels. Make certain that
the usual deductions are taken into consideration. The payroll must
accommodate both salaried and hourly employees. The waiters are
salaried employees, but the busboys are hourly employees. The
payroll system must print checks weekly. The system will produce a
payroll register which will be turned over to auditors monthly.
Income and tax reports (such as W-2s* in the U.S.) must be prepared
according to legal requirements. Reports concerning voluntary
deductions will be prepared for various agencies on a quarterly basis.
? The payroll must treat part-time employees as hourly employees.
Full-time employees and salaried employees may take advantage of
the various company benefits, part-time employees may not.
Restaurant employees will be able to eat meals at their restaurant but
will have the cost of the meals deducted from their paycheck. Hotel
employees will have room costs deducted if they live in the hotel.
There are voluntary deductions and mandatory government
deductions that must be taken into account.
*W-2 = U.S. annual income statement

Continued

Minder Chen, 1994-2004

Use Case - 51

Exercise
Identify for the Payroll System
Actors
Use cases

Name the use cases

Produce the use-case model for the Payroll
System.
Provide:
Actor descriptions
Brief use-case descriptions

Compare your results to other groups.

Are there differences? Why? How would you
resolve these differences?
Minder Chen, 1994-2004

Use Case - 52

Use Case Diagram

Telephone Catalog
Check
status

Place
order

Salesperson

F ill o r d e r s
Shipping Clerk

Customer
Establish
credit

Supervisor

UML Notation Guide

Minder Chen, 1994-2004

Use Case - 53

Use Case Relationships

<<includes>> and <<extends>>
Supply
Customer Data

include

Order
Product

include

Arrange
Payment

include

Place Order
1

Extension points
additional requests :

after creation of the order

extend

the salesperson asks for

the catalog

Request
Catalog

Minder Chen, 1994-2004

Use Case - 54

Actor Relationships

Place
Order

Salesperson

Establish
Credit

Supervisor

Minder Chen, 1994-2004

Use Case - 55

Online HR System: Use Case Relationships

U p d a te M e d ic a l
P la n

< < in c lu d e > >

U p d a te D e n ta l
P la n

< < in c lu d e > >

U p d a te
In s u r a n c e P la n

< < in c lu d e > >

U p d a te B e n e fits

E m p lo y e e

______________
E x te n s io n p o in ts
b e n e fit o p tio n s :
a ft e r r e q u ir e d e n r o llm e n t s
< < e x te n d > >
e m p lo y e e r e q u e s t s
r e im b u r s e m e n t o p tio n
E le c t
R e im b u r s e m e n t
fo r H e a lth c a r e

Minder Chen, 1994-2004

e x t e n s io n p o in t
nam e and
lo c a tio n
< < e x te n d > >
e m p lo y e e r e q u e s t s
s t o c k p u r c h a s e o p t io n

E le c t S to c k
P u rc h a s e

e x t e n s io n
c o n d it io n

Use Case - 56

Online HR System: Update Benefits Use Case

Actors: employee, employee account db, healthcare

plan system, insurance plan system
Preconditions:
Employee has logged on to the system and selected
"update benefits" option
Basic course
System retrieves employee account from employee
account db
System asks employee to select medical plan type;
include Update Medical Plan.
System asks employee to select dental plan type;
include Update Dental Plan.

Alternative courses
If health plan is not available in the employees area
the employee is informed and asked to select

Minder Chen, 1994-2004

Use Case - 57

When to model use cases

Model user requirements with use cases.
Model test scenarios with use cases.
If you are using a use-case driven method
start with use cases and derive your structural and
behavioral models from it.

If you are not using a use-case driven method

make sure that your use cases are consistent with
your structural and behavioral models.

Minder Chen, 1994-2004

Use Case - 58

Use Case Modeling Tips

Make sure that each use case describes a significant
chunk of system usage that is understandable by both
domain experts and programmers
When defining use cases in text, use nouns and verbs
accurately and consistently to help derive objects and
messages for interaction diagrams
Factor out common usages that are required by multiple
use cases

If the usage is required use <<includes>> or

<<uses>>
If the base use case is complete and the
usage may be optional, consider use
<<extends>>
A use case diagram should

contain only use cases at the same level of abstraction

include only actors who are required

Large numbers of use cases should be organized into

packages
Minder Chen, 1994-2004

Use Case - 59

 Minder Chen, 1994-2004

Use Case - 60

 Minder Chen, 1994-2004

Use Case - 61

Set Display Options

Minder Chen, 1994-2004

Use Case - 62

A Use Case Diagram Created in Visio

Minder Chen, 1994-2004

Use Case - 63

Display Options for Communications

Minder Chen, 1994-2004

Use Case - 64

Model Explorer

Linking an Linking a
model element to
another diagram

Minder Chen, 1994-2004

Use Case - 65

Exercise: Automated Teller Machine (ATM)

Brief Statement of Purpose:
An ATM is an electronic device designed for automated
dispensing of money. A user can withdraw money quickly and
easily after authorization. The user interacts with the system
through a card reader and a numerical keypad. A small display
screen allows messages and information to be displayed to the
user. Bank members can access special functions such as
ordering a statement
Additional Notes:
Users shall be able to access the ATM by punching in their
account number and PIN. Once the system has verified that the
account is active and the PIN matches with the account number,
the system offers the users four choices. Users can withdraw
money, deposit money, check balance or quit the session.
The user must have a minimum of $100 in his / her account. At
the end of any transaction a printed copy of the transaction is
provided to the user. A transaction could be - withdraw money,
deposit money or check balance. Once the user has completed
a transaction, the system offers the user the same four choices,
until the user decides to quit.
Minder Chen, 1994-2004

Use Case - 66

Requirements
Brief Summary of Requirements:
The ATM is required:
1. To allow authorized card holders to make transactions
1. Card holders shall view and/or print account balances
2. Card holder shall make cash withdrawals
3. Card holder shall make cash or check deposits
4. Card holder shall quit session

2. To allow bank members to access additional, special services

1. A bank member shall be able to order a statement
2. A bank member shall be able to change security details (e.g. PIN number)

3. To allow access to authorized bank staff

1. Authorized staff can gain access to re-stock the machine
2. Authorized staff are able to carry out routine servicing and maintenance

4. To keep track of how much money it contains and alert bank staff
when stocks are getting low.

Minder Chen, 1994-2004

Use Case - 67

Exercise Requirements

Identify the actors

Identify the uses cases
Draw the top level Use-Case diagram
Develop a detailed Use-Case analysis for a use
case.
Your analysis should contain a brief description of
the use case, the basic and alternative flows, pre
and post conditions.

Minder Chen, 1994-2004

Use Case - 68

The authoring life cycle of Use Cases

Minder Chen, 1994-2004

Use Case - 69

Context of a System
The whole is more than the sum of the parts
The whole determines the sum of the parts
The parts cannot be understood if considered
in isolation from the whole
The parts are dynamically interrelated and
interdependent
-- Fredrick Hagel (1770-1831)

Minder Chen, 1994-2004

Use Case - 70