1. Inah Omoronyia and Tor Stålhane
Institutt for datateknikk og
informasjonsvitenskap
Inah Omoronyia and Tor Stålhane
Advanced Use cases
TDT 4242
TDT 4242

2. Advanced use cases Use cases: Based on work of Ivar Jacobson
Based on experience at Ericsson building telephony systems
Recommended refs:
Writing Effective Use Cases, by Alistair Cockburn, Addison-Wesley, 2001
TDT 4242

3. Advanced use cases vocabulary – 1
Actor – External parties that interact with the system
Roles are not job titles (roles cuts across job titles)
Actors are not individual persons (e.g. John) but stimulates the system to react (primary actor)
You normally don’t have control over primary actors
Roles responds to the system’s requests (secondary actor) normally used by the system to get the job done
An actor don’t have to be a person – it can also be e.g. another system or sub-system.
TDT 4242

4. Advanced use cases vocabulary – 2
Use Case – A sequence of actions that the system performs that yields an observable result of value to an actor.
Use Case Model contains: Actors list, packages, diagrams, use cases, views
A Use Case Model includes structured use case descriptions that are grounded in well-defined concepts constrained by requirements and scope
Use case
descriptions
Concepts
Constraints
and requirements
TDT 4242

5. Finding Actors – 1 Important questions Who uses the system?
Who gets information from the system?
Who provides information to the system?
What other systems use the system?
Who installs, starts up, or maintains the system?
TDT 4242

6. Finding Actors – 2 Focus initially on human and other primary actors
Group individuals according to their common tasks and system use
Name and define their common role
Identify systems that initiate interactions with the system
Identify other systems used to accomplish the system’s tasks
TDT 4242

7. Finding use cases
Describe the functions that the user wants from the system
Describe the operations that create, read, update, and delete information
Describe how actors are notified of changes to the internal state of the system
Describe how actors communicate information about events that the system must know about
TDT 4242

8. Key points for use cases - 1
Building use cases is an iterative process
You usually don’t get it right at the first time.
Developing use cases should be looked at as an iterative process where you work and refine.
Involve the stakeholders in each iteration
TDT 4242

9. Key points for use cases – 2
Define use case actors.
UML visual notations are commonly used.
Start by defining key actors:
An actor can be a system because the system plays another role in the context of your new system and also interact with other actors
Key users
TDT 4242

10. Key points for use cases – 3
Note:
Association relationships only show which actors interact with the system to perform a given use case.
Association relationship DO NOT model the flow of data between the actor and the system.
A directed association relationship only shows if the system or the actor initiates the connection.
Define your use case Actor Goals
TDT 4242

11. An alternative path to use cases
An approach from Siemens:
Start by filming the operations that shall be included in the use case.
Identify actors (system components) involved
Identify functions (actions), their sequence and the parts involved
By observing the driver we can also identify how the user moves between system states

15. Reuse opportunity for use cases – 1
There is duplicate behavior in both the buyer and seller which includes "create an account" and "search listings".
Extract a more general user that has the duplicate behavior and then the actors will "inherit" this behavior from the new user.
TDT 4242

16. Reuse opportunity for use cases – 2
Relationships between use cases:
Dependency – The behavior of one use case is affected by another. Being logged into the system is a pre-condition to performing online transactions. Make a Payment depends on Log In
Include – One use case incorporates the behavior of another at a specific point. Make a Payment includes Validate Funds Availability
TDT 4242

17. Reuse opportunity for use cases – 3
Relationships between use cases:
Extends – One use case extends the behavior of another at a specified point, e.g. Make a Recurring Payment and Make a Fixed Payment both extend the Make a Payment use case
Generalize – One use case inherits the behavior of another; it can be used interchangeably with its “parent” use case, e.g. Check Password and Retinal Scan generalize Validate User
TDT 4242

18. Extend Respond to emergency Control center operator
communication down
<<extends>>
Request arrives through radio or phone

19. Generalize Request (re)scheduling of maintenance Maintenance worker
Already scheduled - reschedule
Proposed time not acceptable
Maintenance worker
Ask for new suggestion
Changes in time consumption or personnel

20. Adding details
We can add details to a use case diagram by splitting uses cases into three types of objects.
Entity object
Control object
Boundary object

21. Adding details – example
Input and output via boundary objects
Validate input and output via control objects
Save via entity objects

22. From UC to SD – 1

23. From UC to SD – 2

24. From UC to SD – 3

25. Use case index Create a use case index
Every use case has several attributes relating to the use case itself and to the project
At the project level, these attributes include scope, complexity, status and priority.
TDT 4242

26. Use case diagrams – pros and cons
Simple use case diagrams are
Easy to understand
Easy to draw
Complex use case diagrams – diagrams containing <<include>>> and <<extend>> are difficult to understand for most stakeholders.
Use case diagrams do not show the sequence of actions

27. Textual use cases - 1
Identify the key components of your use case. The actual use case is a textual representation
TDT 4242

28. Textual use cases - 2 Examples of alternative flow are:
While a customer places an order, their credit card failed
While a customer places an order, their user session times out
While a customer uses an ATM machine, the machine runs out of receipts and needs to warn the customer
Alternative flow can also be handled by using <<extend>> and <<include>>
TDT 4242

29. Textual use cases – 3
Most textual use cases fit the following pattern:

30. Textual use case – example
Use case name
Review treatment plan
Use case actor
Doctor
User action
System action
Request treatment plan for patient X
Check if patient X has this doctor
Check if there is a treatment plan for patient X
Return requested document
Doctor reviews treatment plan
Exceptional paths
This is not this doctor’s patient
Give error message
This ends the use case
No treatment plan exists for this patient

31. Textual use case <<extend>>
Use case name
Respond to
System
emergency call
Use case actor
Operator
User action
System action
System OK => Receive system signal
System Down => Use radio
Receive system
message
Act on message
Send response
End REC – 1
Use case name
Respond to radio
emergency call
Use case actor
Operator
User action
System action
Receive radio
message
Act on message
Send response
End REC – 2

32. Textual use case <<include>>
Use case name
Controller
Use case actor NA
Start timer
Get data
Action necessary?
Yes => Set Actuator
Timer expired ?
No => BIT
Check error status
On => Error handling
End Controller
Use case name
BIT
Use case actor NA
Get test pattern A
Write test pattern
Read test pattern
Compare patterns
Difference => Set error status
End BIT

33. Textual use cases – pros and cons
Complex textual use cases
Are easier to understand than most complex use case diagrams
Are easy to transform into UML sequence diagrams
Require more work to develop
Show the sequence of actions

34. Mis-Use cases Aims to Identify possible misuse scenarios of the system
The concept was created in the 1990s by Guttorm Sindre, NTNU and Andreas L. Opdahl, UiB.
The basic concept describes the steps of performing a malicious act against a system
The process is the same as you would describe an act that the system is supposed to perform in a use case
TDT 4242

35. Mis-Use cases example – 1

36. Mis-Use cases example – 2
Mis-use cases are mostly used to capture security and safety requirements
TDT 4242

37. Textual misuse case U C name Respond to over-pressure User actions
User actions
Sys Response
Threats
Mitigations
Alarm operator o
high pressure
System fails to set alarm;
Operator fails to notice alarm
Have two independent alarms;
Test alarms regularly;
Use both audio and visual cues;
Alarm also outside control room
Operator
gives
command to
empty tank
Operator fails to react (e.g.,
ill, unconscious)
Operator gives wrong
command, e.g., filling tank
Alarm backup operator
Automatic sanity check, disallow
filling at high pressure
System opens
Valve to sewer
System fails to relay
command to valve;
Valve is stuck
reads
pressure
Operator misreads and
stops emptying too soon
Maintain alarm until situation is
normal

38. Why misuse case – 1 A misuse case is used in three ways:
Identify threats – e.g. “System fails to set alarm”. At this stage we do not care how this error can arise.
Identify new requirements – e.g. “System shall have two independent alarms”. This is a high level requirement. How it is realized is not discussed now.

39. Why misuse case – 2 Identify new tests – e.g.
Disable one of the alarms
Create an alarm condition
Check if the other alarm is set
This is just the test strategy. How it is realized cannot be decided before we have decided how we shall implement the requirement.

40. Misuse case – pros and cons
Misuse cases will help us to
Focus on possible problems
Helps us to identify defenses and mitigations
Misuse cases can get large and complex – especially the misuse case diagrams.

41. Use-Case Maps
Definition: A visual representation of the requirements of a system, using a precisely defined set of symbols for responsibilities, system components, and sequences.
Links behavior and structure in an explicit and visual way
UCM paths: Architectural entities that describe causal relationships between responsibilities, which are bound to underlying organizational structures of abstract components. UCM paths are intended to bridge the gap between requirements (use cases) and detailed design
TDT 4242

42. Use-Case Maps – path … UCM Path Elements Start Point End Point Path
Responsibility
Direction Arrow
Timestamp Point
Failure Point
Shared Responsibility
UCM Path Elements
TDT 4242

43. Use Case Maps example - path
Mainly consist of path elements and components
UCM Example: Commuting
secure
home X
commute
take
elevator
ready to
leave in
cubicle
transport
Responsibility Point
Basic Path
(from circle to bar)
Component
(generic)
TDT 4242 43

44. Use-Case Maps – AND / OR … UCM Forks and Joins [C1] [C2] [C3]
OR-Fork & Guarding Conditions
OR-Join
AND-Join
AND-Fork
UCM Forks and Joins

45. UCM Example: Commute - Bus (Plug-in)
UCM example – AND / OR
UCM Example: Commute - Bus (Plug-in)
person
read
Dilbert X
take 182
AND Fork
OR Join
OR Fork
AND Join
transport
take 97
take 95
[Am99]
An OR-join merges two (or more) overlapping paths while an OR-fork splits a path into two (or more) alternatives. Alternatives may be guarded by conditions represented as labels.
Concurrent and synchronized segments of routes are represented through the use of a vertical bar. An AND-join synchronizes two (or more) paths together while an AND-fork splits a path into two (or more) concurrent segments.
Note: the stub - plug-in map relationship is not purely hierarchical. The example shows the same “Transport” component on the plug-in map as is shown on the root map and, in addition, the “Person” component.

46. Use-Case Maps – IN / OUT … UCM Stubs and Plug-ins
Static Stub & Segments ID
Dynamic Stub
S{IN1}
E{OUT1}
Plug-in Map
UCM Stubs and Plug-ins

47. UCM Example: Commuting
UCM example – IN / OUT
UCM Example: Commuting
ready to
leave
home in
cubicle
transport
elevator
commute
take
secure
Dynamic Stub
(selection policy)
Static Stub
stay
[Am99]
When maps become too complex to be represented as one single UCM, containers called stubs may be used. Stubs link to sub-maps called plug-ins.
Static stubs contain only one plug-in and enable hierarchical decomposition of complex maps.
Dynamic stubs may contain several plug-ins, whose selection can be determined at run-time according to a selection policy (often described with pre-conditions). It is also possible to select multiple plug-ins at once (sequentially or in parallel). At the moment, the composition requires to be detailed outside the UCM diagram although some formalism in the form of global Boolean variables is provided.
Stubs are similar in concept to commonality/variability.
Stubs are similar in concept to polymorphism although more broadly applicable (e.g. selection policy may select more than one plug-in).

48. Use-Case Maps – coordination
Waiting Place
Trigger
Path (asynchronous)
Waiting
Path
Continuation
Timer
Release
(synchronous)
Timeout Path
UCM Waiting Places and Timers

49. Use Case Map Dynamic Structures-
Generic UCM Example
start
end
Dynamic Responsibilities and Dynamic Components
slot A
pool A
pool B +
create
slot B
copy
destroy
move out
move into
Slot
(component)
Pool
[Am99]
Dashed components are called slots and may be populated with different instances at different times. Slots are containers for dynamic components (DC) in execution.
Pools are containers for dynamic components that are not executing (they act as data). Dynamic responsibilities such as create, destroy, copy, move, and move-stay may be performed on dynamic components.
What’s the difference to a simple database. Data never does anything. A dynamic component stored in a pool, however, can be retrieved and placed in a slot where it can perform responsibilities.
[URN]
Move-stay: a reference to a dynamic component is moved instead of moving a copy of the dynamic component (as copy does)

50. Use Case Maps – example 1 Contains pre-conditions or triggering causes
bars representing post-conditions or
resulting effects
path traces through a system of objects to explain a causal sequence, leaving behind a visual signature.
causal chains of responsibilities (crosses, representing actions, tasks, or functions to be performed)
Responsibilities are normally bound to component when the cross is inside the component
Example of Use Case map
A component is responsible to perform the action, task, or function represented by the responsibility.
Start points may have preconditions attached, while responsibilities and end points can have post-conditions.
TDT 4242

51. The influence of chosen elements
The elements we choose to include in our model will decide the use case map but will not necessarily influence the actions needed. The following examples are meant to illustrate this.
Two elements are always needed:
User – requesting service
Arrival sensor – indicates when the elevator arrives at the chosen floor.

52. Use Case Maps – example Select Destination User [not requested]
[moving]
motor up
motor down
moving
door close
Arrival Sensor
approaching
floor
decide on
direction
below
motor
stop
[requested]
door
open
[stationary]
above
[more requests]
add to list in
elevator
[else]
no requests
door
closing-delay
remove
from list
at requested
floor
The elevator control system case study is adapted from Hassan Gomaa's Designing Concurrent, Distributed, And Real-Time Applications with UML (p ), copyright Hassan Gomaa 2001, published by Addison Wesley. Used with permission.
Select Destination

53. Model 1 – scheduler Scheduler User Arrival Sensor [not requested]
approaching
floor
down up
select
elevator
moving
at floor
Elevator
below
above
add to
list in
elevator
at requested
floor
remove from list
motor
stop
door open

54. Model 1 – Use Case Map Arch. Alternative (I) User Scheduler
[requested]
down
Arrival Sensor
[not requested] up
moving
approaching
floor
select
elevator
at floor
below
already
on list
Elevator
above
add to
list
decide on
direction
door
close in
elevator
[on list]
[else]
stationary-
memory
at requested
floor
motor up
motor
down
door
closing-delay
remove from list
Service Personnel
switch on
motor
stop
Arch. Alternative (I)
door open

55. Model 2 – scheduler and status & plan
User
Scheduler
Status & Plan
select
elevator
[not requested]
[requested]
Arrival Sensor
down up
Elev. Control
Elev. Mgr
at floor
Elevator
below
above
Status & Plan in
elevator
add to
list
at requested
floor
remove
from list
motor
stop
Service Personnel
switch on
door open

56. Model 2 – Use Case Map Arch. Alternative (II) User Status & Plan down
Scheduler
[not requested]
[requested] up
select
elevator
Arrival Sensor
Elev. Control
at floor
already
on list
approaching
floor
moving
below
Elev. Mgr
above
[on list]
Elevator
decide on
direction in
elevator
[else]
door
close
Status & Plan
stationary-
memory
add to
list
at requested
floor
door
closing-
delay
motor up
motor
down
remove
from list
Service Personnel
switch on
motor
stop
Arch. Alternative (II)
door open

57. Summary – 1 Use Cases benefits: Promote customer involvement
Use cases describe a system from an external usage perspective
They can be organized according to their relevance, frequency of use, and perceived value to the system’s users
System features can be correlated with how they are used within specific use cases
Impacts of adding and/or removing features on system usability can be analyzed
TDT 4242

58. Summary – 2 What Use Cases Cannot Do
Use Cases are best used to describe system functionality from a task-oriented perspective
They do not describe:
user interfaces
performance goals
application architecture
non-functional requirements
TDT 4242

59. Acknowledgement
Most of the slides on use case maps has been taken from a presentation written by D. Amyoty, University of Ottawa
Daniel Amyot, Gunter Mussbacher
TDT 4242