Use Cases

Chapter 3

Object-Oriented Software Systems Engineering – Chapter 3 Slide 1

 Objectives

In this chapter we will:

 Describe use case modelling
 Introduce use cases and actors
 Discuss relationships between use cases
 Introduce use case descriptions

Object-Oriented Software Systems Engineering – Chapter 3 Slide 2

 Use Case Modelling

 The purpose of use case modelling

to decide and describe the functional
requirements of the system
to give clear and consistent description of what
the system should do
to provide a basis for performing tests that
verify the system
to provide the ability to trace functional
requirements into classes and operations
 Use case model
represents use-case view
is described by a use-case diagram

Object-Oriented Software Systems Engineering – Chapter 3 Slide 3

 Use Case Modelling

Use Cases are described using both text

documents and diagrams

Use-case modelling is primarily an act

of writing text NOT just drawing diagrams

Object-Oriented Software Systems Engineering – Chapter 3 Slide 4

 Use Case Modelling

 Definition of use case

 represents a complete functionality as perceived by an actor
 a set of sequences of actions a system performs that yield
an observable result of value to a particular actor
 Characteristics
 is always initiated by an actor
 provides tangible value to an actor (observable not
necessary salient)
 is complete - use case is not complete until an end value is
produced even if several communications occur along the
way
 Scenario’s are instances of use-cases
 A specific sequence of actions that illustrate behaviour
 You’ll find primary scenarios and secondary scenarios

Object-Oriented Software Systems Engineering – Chapter 3 Slide 5

 Use Case Modelling – terms & concepts

Name of System

An Actor A Use Case

Object-Oriented Software Systems Engineering – Chapter 3 Slide 6

 Use Case Modelling – terms & concepts

 The system boundary

 defines responsibility
 black box that provides use-cases
 within the system boundary
 what the system does but not how the system does

 Use-cases
 a description of a set of sequence of actions, including
variants that the system performs to yield an observable
value to an actor
 a set of scenarios

Object-Oriented Software Systems Engineering – Chapter 3 Slide 7

 Use Case Modelling – terms & concepts

 Actor
 representing a role that someone might play, rather than
a particular individual
 external entity that has interest in interacting with the
system
 Interaction
 a communication relation between an actor and a use
case

Object-Oriented Software Systems Engineering – Chapter 3 Slide 8

 Identifying Use Cases and Actors

 What functions does the actor require from the

system?
 Does the actor need to read, create, destroy,
modify or store some kind of data in the system?
 Does the actor have to be notified about events in
the system, or does the actor need to confirm with
the system for something?
 Could the actor’s daily work be simplified or made
more efficient via new functions in the system?
 What input/output does the system need?
 Can these requirements be handled by one actor
or someone else as well?

Object-Oriented Software Systems Engineering – Chapter 3 Slide 9

 Use Case Modelling – organising use cases
Communication Association
UML use-case diagram

An Actor A Use Case

Communication associations: UseCase 1

connect actors to use cases
User 1
UseCase 2
Manager

UseCase 3
User 2

Object-Oriented Software Systems Engineering – Chapter 3 Slide 10

 Use Case Modelling – types of relationships

Relationships between actors

generalization - specialization

Library User

Student Lecturer

Object-Oriented Software Systems Engineering – Chapter 3 Slide 11

 Use Case Modelling – types of relationships

Two stereotypes of dependency relationship in use cases

Include Extends
specifies that the source use case specifies that the target use case
(A) explicitly incorporates the (B) extends the behaviour of the
behaviour of the target (B) source (A)

A includes the behaviour of B A is extended from B by adding

some actions

<<include>> <<extends>>
Extension points

A B A B

Object-Oriented Software Systems Engineering – Chapter 3 Slide 12

 Use Case Relationships

Extend and Uses relationship - different forms of re-use

 Extend relationship - accounts for optional behaviour
 Include relationship -uses or include relationship
 one use case uses another use case
 (reuse by composition)

<<extends>> Place rush

(set priority) order

Check password
Place order <<uses>>
Extension points
set priority Vaildate user
Retinal scan

Object-Oriented Software Systems Engineering – Chapter 3 Slide 13

 part 1
A Simple Use Case Diagram of Library
Library System

Search for Update

book catalog

Library
Member <<extend>>
Borrow a
over limit Refuse
copy of book Librarian
loan

Reserve a book
Return a
e>>
copy of book <<includ
e>>
d
in clu
Member of <<
Staff Extend loan

Object-Oriented Software Systems Engineering – Chapter 3 Slide 14

 Use Case Diagram - order processing

Place order Customer

<<extend>> discount
extension points
<<i
set discount ncl

<<
ude
>>

inc

<<
Give product

lud

nci
information

e>

lu
Customer

>

de
Cancel order <<i

>>
ncl
ude
>>
<< Update
in
cl account
Return ud Inventory
product e> system
<<i >
nclu
de>
> Update product
quantities
Get status
on order
Accounting
Sales Rep
system
Run sales
report

Object-Oriented Software Systems Engineering – Chapter 3 Slide 15

 Use Case Diagram - course management
Course Management System

Select
Register for courses to
courses teach
Student

Request Lecturer
course roster
Billing system Create
course Maintain
catalogue course’s infor.

Maintain Maintain
information lecturer’s infor.
Registrar
Maintain
student’s infor

Object-Oriented Software Systems Engineering – Chapter 3 Slide 16

 UseCase 1
Use Case Actor 1
diagram UseCase 2
Manager

Actor 2 UseCase 3

Class 2 Class 1

Class State
diagram diagram
Class 3 Class 4

<<Actor>> state 1
User c2: object c3: object
Sequence
0: event state 2
diagram
1: operation 2: operation
Object-Oriented Software Systems Engineering – Chapter 3 Slide 17
 UseCase 1
Actor 1
Use Case UseCase 2
diagram Manager

Actor 2 UseCase 3

Class 2 Class 1

Class
diagram State
Class 3 Class 4 diagram

<<Actor>> state 1
User c2: object c3: object
Sequence
0: event state 2
diagram
1: operation 2: operation
Object-Oriented Software Systems Engineering – Chapter 3 Slide 18
 Use Case

 A use case is a starting point

 You may not know very much about a subject,
write down what you do know
 Then you need to find out the detail that you do
not know but that you need to know in order to
solve the problem
 When we have as much detail as we need, we can
produce Use Case Descriptions

Object-Oriented Software Systems Engineering – Chapter 3 Slide 19

 Use Case Descriptions

A use case description:

 The text to describe a particular use case
interaction - in the form of a 2-way dialogue
between the actor and the system
 Provides the supporting detail for the use case
diagram - not to be started until the diagram is
complete/nearly complete
 Also known as Use Case Scripts or Use Case
Scenarios (beware - the latter has another
meaning)

Object-Oriented Software Systems Engineering – Chapter 3 Slide 20

 What to describe

 Describe the most common/normal form of

interaction first - the basic course
 Describe possible variations separately - the
alternative courses
 The script should be in a conversational style:
 actor requests….
 System responds by….
 Actor does…..
 And so on..

Object-Oriented Software Systems Engineering – Chapter 3 Slide 21

 Example of a Use Case Description

 In the video rental shop, the interaction between

Counter Assistant and Rent Video use case may
be:
Actor Actions System Response
1. Customer tenders video(s) to be
rented and membership card
2. Counter assistant enters member 3. System provides member details and
no.into system status of loans and fines
4. Assistant enters identification of each
video to be rented 5. System accepts ids and gives fee payable
6. Assistant requests payment, takes
money and enters payment made 7. System logs payment details

Object-Oriented Software Systems Engineering – Chapter 3 Slide 22

 Guidelines

 Include a series of numbered sections or steps

which describe noteworthy events and possibly
related context, constraints and business rules
 Steps may alternate between actor and system, or
may be a series of consecutive steps taken by
either of them
 Written from the user’s point of view
 Written in the vocabulary of the user

Object-Oriented Software Systems Engineering – Chapter 3 Slide 23

 Conversational Style

 This conversational style script (as if for a theatre

play) is a good compromise between the
advantages and disadvantages of other methods:
 It is quick and easy to write (important for
capturing early, outline information)
 It is quick and easy to read and to understand
 It encourages concise-ness
 It identifies the required sequence of actions
 It highlights causes and effects

Object-Oriented Software Systems Engineering – Chapter 3 Slide 24

 Essential Use Cases

 These are used during the feasibility and analysis

stages of the project
 The aim is to be free of implementation detail to
show the essence of the business requirements
(the conceptual model)
 Enables analysts, developers, users and clients to
understand the scope of the problem and the
processes required

Object-Oriented Software Systems Engineering – Chapter 3 Slide 25

 Real Use Cases

 Now the Essential Use Cases will be used as the

basis for lateral, creative thinking with the
opportunity for new ideas on how to create the
system
 Real Use Cases are used to document the design
of the project
 how it will work in reality
 For a user interface it may include prototype
screen shots, print layouts, form layouts, menus
 For a system interface it may include file layouts

Object-Oriented Software Systems Engineering – Chapter 3 Slide 26

 Template Sections

The following sections are normally included:

 Use Case - its identifier/name

 Actors - list of actors involved. Show which one
initiates the use case
 Overview - short outline description summarising
the use case
 Type - category of the use case
 Cross References - use case relationships
(covered later)

Object-Oriented Software Systems Engineering – Chapter 3 Slide 27

 Categories of Use Cases

1. Primary - major common process

For example: Rent Video
2. Secondary - minor or rare processes
For example: Request to supply unstocked New Video
3. Optional - processes that may or may not be used

Object-Oriented Software Systems Engineering – Chapter 3 Slide 28

 Alternative Courses

 Alternative courses can describe alternative

events to the typical story
 These are the less common, the exceptional or
error cases
 Place all the alternatives after all the typical
course of events
 For example:
7. Customer pays clerk by cash or credit
Alternative Courses
7. Customer has unpaid late charges and will not pay them.
Collect payment or cancel rental transaction

Object-Oriented Software Systems Engineering – Chapter 3 Slide 29

 Use Case Descriptions

Review of use case descriptions:

 Use Case descriptions supply the detail of system

requirements
 Conversational scripts are used to describe the
interactions between actors and use cases
 The basic course may be followed by 1 or more
alternative courses
 Essential Use Cases are used during Analysis,
Real Use Cases are used during Design

Object-Oriented Software Systems Engineering – Chapter 3 Slide 30

 Summary

In this chapter we have:

 Described use case modelling
 Introduced use cases and actors
 Discussed relationships between use cases
 Introduced use case descriptions

Object-Oriented Software Systems Engineering – Chapter 3 Slide 31