3. use cases

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


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


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


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


Use Case Modelling – terms & concepts

Name of System

An Actor A Use Case



 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



 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


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?


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


Use Case Modelling – types of relationships

Relationships between actors
generalization - specialization

Library User

Student Lecturer


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


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


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
>
d e>
in clu
Member of <<
Staff Extend loan


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


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


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

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

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


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)


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..


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


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


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


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


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


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)


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


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


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


Summary

In this chapter we have:
 Described use case modelling
 Introduced use cases and actors
 Discussed relationships between use cases
 Introduced use case descriptions


3. use cases

More Related Content

What's hot

Viewers also liked

Similar to 3. use cases

More from APU

3. use cases

Editor's Notes