PURPOSE OF USE CASE DIAGRAMS
■ Provide a high level view of the system
■ Document user requirements
■ Explore alternative scenarios
■ Provide a starting point for analysis of classes
■ Help to define the user interface
■ Support project management
■ Form a basis for testing
HIGH LEVE V EW OF SYSTEM
Ad mini &ration
■ Summarize the
functionality and provide a
Add new sensor
way of determining the
scope
■ Provide a tool for
communicating with users Homeowner
about the go,als of the
system
USER REQUIREME TS
:= · UseCase: Query devke a- d sensor status
■ U,s,e cases organize the S�nario:
Basic Path
requirem·ents from th,e Description Structur d Sp cification
users' point of vi,ew ... ✓•
■ A recipe - not a list of Step
1
ction
Th user selects the qu ry option fr.om th m nu
ingredients The system presents a list of all devices and sensors by
default in afphabetical order, dis_ laying the name,
location, pe and current status of each devi,ce or sens,or.
3 The user can choose to itte the ist by select'ng e, i her
just devic s or Just sensors, o· by select ing one or more
1
locations o on , or mor p s.
The system redispl1 ays the •ist, sho ing just thos devic s
and senso s that meet the se edion criteria.
EXPLORI G ALTE RNATIVE SCE ARIOS
:= UseCase : dd ne d vice
■ What can go wrong? S �nano:
De ice name already exists
■ What alternative ways Description S ructur Spe(fication
are there of workin:g
through the use case? 0
Step
,
ction
Th syst m displ-ys a arning to th us r
2 The user clic s 0
3 The sys em renames he e isting, device devicename -1
The syst m changes the name of the device b ing n er d
o devicename> -2
. . ·. . .
[" . s I
"····•.. •+•--·----· .. ··· ..·----· .. ······.............
_.. ... +.., ......................_.... . .... .� ................................_., ..... +. ... ....................... .............................
. ....................... . +................................... +... -., ...... .
STARTING POINT FOR CLASS ANALYSIS
• The use cases are the starting
point for working out what classes Home owner
are required in the system to AddDeviceUI Device
imp,lement the functionality
• This approach is known as
robustness analysis
AddDeviceControl ler
• Use cases d , escribe how the use s
will use the system
■ They are a starting point for user
interface or user experience design
Home User
• Architects and project managers Distribution ·Of Use Cases to
Iterations
use the use cases to plan the 4
Ar,ea of use case"' effort
project and manage risk 16
...............-----·
Value in use case"' risk
..---...------· ---............ --.......-----...-------......................... -· -.. ..
■ estimating,, costing and plann
1 1ing l�.._
■ organizing the
i incremental �
:�
Do the hard st
use cases fl r
development and del1ivery of the E
�
while balan cng
effort acr Iteration
system
• Use cases d , es,cribe how the
ice name alrea
exists
system will be used �
/
/
«trace»
■ Test c, as,es can be written for
each use case and each «trace» already in use
altern,ative or error path
'
through that use case «trace»
,
BASIC OTATION OF USE CASE DIAGRAMS
■ Subjects
Admi ni strati on
■ Use cases
■ Actors
• Associations
Homeowner
1'
0 __ 1
SUBJECTS
■ 'A subject of a UseCase could be Adm i ni srati on
a system or any other element
that may have behavior,, such as
a Component or Class'
■ Usually use cases are created
early in project
■ Informally subject represents a
subsystem
USE CASES
• Use cases represent some Admini&rati on
behaviour that a subject can Query device and
sensor status
perform in collaboration with
one or more actors
• Shown as an ellipse w·th the
name in or below the ,ellipse
■ Most of a use case is textual
and not defined by UML
ACTORS
• Roles played by people or Administration
external systems in relation
to the system
■ The actor interacts with the
use case, usually to achieve Home owner
some goal
• Primary and secondary Set up event triggers
actors
• Relationships that show Admi ni strati on
how actors are associated
to use cases
■ Associations can have
multiplicities, but these are Hane owner
1·
1 0 .. 1
rare y used 0 .. 1
SE CASE DIAGRAMS
■ Generalization/Specialization
■ Include
■ Extend
GENERALIZATION/SPECIALIZATIO
■ Use cases can have
Directly control a
inheritance re ationships device
with other use cases
■ One use case d , efines the
general case and othe use Directly control a
cases d,efine specializations ice via smartph
of that use c, ase
GENERALIZATION/SPECIALIZATIO
■ Actors can have
inheritance re ationships
with other actors Home User
■ The specialized acto,r
inherits all the associations
with use cases of the more,
general actor
Home Owner
■ The behaviour of one use
case includes the behaviour of ... - «include»
another use case at one poi, nt
Set up timed
schedule
■ Shown using a dashed arrow . "«include»
with the stereoty,pe <<·nclude>> Set up event
triggers
■ Arrow to included use case
■ The behav·our of one use
case is conditionally emove faulty
s or from netw
inc uded in another use
case at one or more points -
«extend» --_
- --
■ Shown using a dashed emove faulty
arrow with the stereotype ice from netw
<<extend>>
■ Arrow to extended us,e case
SPEC FYI G USE CASES
■ Use cases with no actors
■ Specifying behaviour
■ Activity diagrams
■ Use case descriptions
USE CASES WITH NO ACTORS
Running
• When the Home
Automation system '"s
Directly control a
device
Hom,eUser
running, it will perform
behaviours with no
human intervention Directly control a
device via browser
irectly control a
ce via smartpho
■ You could show a use Home Owner
case Perform device (from
Actors)
action with no actor
USE CASES WITH NO ACTORS
• Some pe, ople would add actors like Sensor or Time
■ Are these real y actol rs?
■ What observable result of value are they getting from the
system?
■ They are parts
of the system
itself Sensor lime
USE CASES WITH O ACTORS
Use Case Name:
• We need to distinguish actors Goal:
from triggers Scope:
Level:
■ Actors gain value from use Primary Actor:
Secondary Actors:
cases Triggers:
---
■ Triggers initiate use cas,es Pre-conditions:
Success Guarantees:
• Triggers are part of the Main Success Scenario:
specificatio,n of use cases
Alternative Scenarios:
SPEC FYING BEHAVIOUR
Use Case Name:
• If you think that use cases Goal:
Scope:
are just a visual notation, Level:
then you are missing the Primary Actor:
Secondary Actors:
point and failing to get value Triggers:
from them Pre-conditions:
Success Guarantees:
■ Additional information Main Success Scenario:
specifies the use case
Alternative Scenarios:
Start
ACTIVITY DIAGRAMS lhe user selects
Add Device from
the menu
• A use case can be , specified
graphically using one or
lhe system
presents the screen
allowing them to,
more activity diagrams o add a device
sequence diagrams lhe user enters the
name of the device
• Activity diagram shows the
steps in the use case and
[Device name already exists]
Exception1
alternative scenarios as lhe system displays
branches a w a ming to the
user
USE CASE DESCR TIO S
■ Textual descriptions of Use Case: Add a device
1. The user selects Add Device from
the steps in a use case the menu
■ Typically use a 2. The system presents the screen
allowing them to add a device
tem plate 3. The user enters the name of the
■ Document the main device
4. The user selects the type of the
scenario and device
alternative and 5. The user bro,wses to the location of
exception scenarios the device driver ...
