1. Use Cases
Chapter 3
Object-Oriented Software Systems Engineering – Chapter 3 Slide 1
2. 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
3. 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
4. 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
5. 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
6. Use Case Modelling – terms & concepts
Name of System
An Actor A Use Case
Object-Oriented Software Systems Engineering – Chapter 3 Slide 6
7. 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
8. 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
9. 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
10. 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
11. Use Case Modelling – types of relationships
Relationships between actors
generalization - specialization
Library User
Student Lecturer
Object-Oriented Software Systems Engineering – Chapter 3 Slide 11
12. 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
13. 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
14. 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
Object-Oriented Software Systems Engineering – Chapter 3 Slide 14
15. 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
16. 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
17. 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
18. 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
19. 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
20. 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
21. 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
22. 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
23. 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
24. 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
25. 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
26. 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
27. 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
28. 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
29. 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
30. 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
31. 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
Notes de l'éditeur
1
A use case captures some user visible function A use case may be small or large A use case acheives a discrete goal for the user Techniques: Identifying use cases Based on the system scope model, we think of our system as a black box which Responds to envents ocurring along a chain of activities, representing a typical system cycle producing some response. We treat each use case as a self contained unit of interaction. It must be performed a single actor ina single place although it might result in output flows to other passive actors. The use case must also leave the system in a stable state; this may result in a some measurable value to it’s user.
The uses(include) occurs when you have a chunk of behaviour that is similar across more than one use case. Included use cases never stands alone- an example of delegation Use extend when you want to have one use case that is similar to antother use case but does a bit more-may extend to model optional behaviour – base use case may stand alone but under certain conditions e.g. plac an order might read: main flow of events: include (Validate user(set priority) – an extension point Similiarities imply factoring out common code Differeneces: in the case of extends actors have a relationship to the use case that is extended. It is assumed that a given actor willperform both the base use case and all of the extensions Different designers make use of use cases with varying degrees of granularity As uou perform modelling tasks you will come up with models that express how to do you use cases, there is more than one way these are called realisations.