tdt 4242 inah omoronyia and tor stålhane advanced use cases tdt 4242 institutt for datateknikk og...
TRANSCRIPT
TDT 4242
Inah Omoronyia and Tor Stålhane
Advanced Use cases
TDT 4242
Institutt for datateknikk oginformasjonsvitenskap
TDT 4242
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
• http://www.usecases.org
TDT 4242
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
Advanced use cases vocabulary – 2Use 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
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
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
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
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
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
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 usersKey users
TDT 4242
Key points for use cases – 3
Define your use case Actor Goals
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.
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.
TDT 4242
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
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
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
Extend
Respond to emergency
Control centeroperator
communication down
<<extends>>
Request arrives through radio or phone
Generalize
Request (re)scheduling of maintenance
Already scheduled- reschedule
Proposed timenot acceptable
Maintenance worker
Ask for new suggestion
Changes in time consumption or personnel
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 Entity object Control object Boundary object
Adding details – example Input and output via boundary objects Validate input and output via control objects Save via entity objects
Web serverValidate Main page
Database Update Show Result page
Web serverValidate Main page
Database Update Show Result page
Web serverValidate Main page
Database Update Show Result page
From UC to SD – 1
From UC to SD – 2
From UC to SD – 3
TDT 4242
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.
Use case diagrams – pros and cons
Simple use case diagrams areEasy to understandEasy 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
TDT 4242
Textual use cases - 1Identify the key components of your use
case. The actual use case is a textual representation
TDT 4242
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>>
Textual use cases – 3 Most textual use cases fit the following
pattern:
Request with data
Respond with result
Validate
Change
Request with data
Respond with result
Validate
Change
Textual use case – example
Use case name Review treatment plan
Use case actor Doctor
User action System action
1. Request treatment plan for patient X
2. Check if patient X has this doctor3. Check if there is a treatment plan for
patient X
4. Return requested document
5. Doctor reviews treatment plan
Exceptional paths
2.1 This is not this doctor’s patient2.2 Give error messageThis ends the use case
3.1 No treatment plan exists for this patientThis ends the use case
Textual use case <<extend>>
Use case name Respond toSystememergency call
Use case actor Operator
User action System action
System OK => Receive system signal
System Down => Use radio
Receive systemmessage
Act on message
Send response
End REC – 1
Use case name Respond to radioemergency call
Use case actor Operator
User action System action
Receive radiomessage
Act on message
Send response
End REC – 2
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
Textual use cases – pros and cons
Complex textual use cases Are easier to understand than most
complex use case diagramsAre easy to transform into UML
sequence diagramsRequire more work to developShow the sequence of actions
TDT 4242
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
Mis-Use cases example – 1
Heater
Thermostat
220 Volt AC
Pressure relief valve to air
Empty tankto sewer
Fill tank
Temp
Pressure
Waterlevel
Set criticalpressure
Valve control
Aut. level Steam to process
Manual valve
Operator’s panel
Operator
Heater
Thermostat
220 Volt AC
Pressure relief valve to air
Empty tankto sewer
Fill tank
Temp
Pressure
Waterlevel
Set criticalpressure
Valve control
Aut. level Steam to process
Manual valve
Operator’s panel
Operator
TDT 4242
Mis-Use cases example – 2Mis-use cases are mostly used to capture security
and safety requirements
Textual misuse case U C name Respond to over-pressure
User actions Sys Response Threats Mitigations
Alarm operator ohigh 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
Operatorgivescommand toempty tank
Operator fails to react (e.g.,ill, unconscious)Operator gives wrongcommand, e.g., filling tank
Alarm backup operatorAutomatic sanity check, disallowfilling at high pressure
System opensValve to sewer
System fails to relaycommand to valve; Valve is stuck
Operatorreadspressure
Operator misreads andstops emptying too soon
Maintain alarm until situation isnormal
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.
Why misuse case – 2
Identify new tests – e.g. Disable one of the alarms Create an alarm condition Check if the other alarm is setThis is just the test strategy. How it is
realized cannot be decided before we have decided how we shall implement the requirement.
Misuse case – pros and cons
Misuse cases will help us toFocus on possible problemsHelps us to identify defenses and
mitigations
Misuse cases can get large and complex – especially the misuse case diagrams.
TDT 4242
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
Use-Case Maps – path StartPoint
EndPoint
Path
… …
… …Responsibility
Direction Arrow
… …Timestamp Point
Failure Point… …
Shared Responsibility… …
UCM Path Elements
TDT 4242
Use Case Maps example - path
Mainly consist of path elements and components
UCM Example: Commuting
securehome
X X
commute
X
takeelevator
readytoleavehome
incubicle
home transport elevator
Responsibility PointBasic Path(from circle to bar)
Component(generic)
Use-Case Maps – AND / OR
…
…
…
…
[C1]
[C2]
[C3]
OR-Fork& GuardingConditions
…
…
…
…
OR-Join
…
…
…
… …
…
…
…AND-JoinAND-Fork
UCM Forks and Joins
UCM example – AND / OR
UCM Example: Commute - Bus (Plug-in)
person
readDilbert
X
X
take 182
AND Fork OR JoinOR Fork AND Join
transport
Xtake 97
Xtake 95
Use-Case Maps – IN / OUT
UCM Stubs and Plug-ins
… …IN1 OUT1 Static Stub & Segments ID
Dynamic Stub
IN1 OUT1… …
S{IN1} E{OUT1}
Plug-in Map
UCM example – IN / OUT
UCM Example: Commuting
readyto
leavehome
incubicle
home transport elevator
commutetake
elevatorsecurehome
Dynamic Stub(selection policy)
Static Stub
stayhome
Use-Case Maps – coordination
Waiting Place
Trigger
Path (asynchronous)
Waiting
Path
Continuation
Path
Timer
Timer
Release
(synchronous)
Waiting
Path
Continuation
Path
Timeout Path
UCM Waiting Places and Timers
Use Case Map Dynamic Structures
-
Generic UCM Example
start
end
Dynamic Responsibilities and Dynamic Components
slot A
pool A
pool B
++
create create
slot B
copy
destroy
-
destroy
+
move out
move intomove into
Slot(component)
Pool(component)
TDT 4242
Use Case Maps – example 1
Example of Use Case map
path traces through a system of objects to explain a causal sequence, leaving behind a visual signature.
path traces through a system of objects to explain a causal sequence, leaving behind a visual signature.
Contains pre-conditions or triggering causes
Contains pre-conditions or triggering causes
• 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
• 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
bars representing post-conditions orresulting effects
bars representing post-conditions orresulting effects
• 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.
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 serviceArrival sensor – indicates when the
elevator arrives at the chosen floor.
User
inelevator
abovebelow
at requestedfloor
Arrival Sensor
approachingfloor
doorclosing-delay
add to list
[else]
no requests
[stationary]
[moving][not requested]
door closemotor up
motor down
moving
decide ondirection
motorstop
[requested]
dooropen
Select Destination
removefrom list
[more requests]
The elevator control system case study is adapted from Hassan Gomaa's Designing Concurrent, Distributed, And Real-Time Applications with UML (p459-462), copyright Hassan Gomaa 2001, published by Addison Wesley. Used with permission.
Use Case Maps – example
Model 1 – scheduler User Scheduler Arrival Sensor
Elevator
inelevator
above
at requestedfloor
below
at floor
updown
approachingfloor
moving
motorstop
door open
add tolist
remove from list
selectelevator
[not requested] [requested]
User
Arrival Sensor
Service Personnel
Scheduler
Elevator
inelevator
abovebelow
decide on direction
[else]
door close
motorupmotor
down
moving
at floor
updown
selectelevator
approachingfloor
[not requested]
motorstop
[requested]
door open
at requestedfloor
stationary-memory
switch on
doorclosing-delay
add tolist
[on list]
alreadyon list
remove from list
Arch. Alternative (I)
Model 1 – Use Case Map
Model 2 – scheduler and status & plan
User Scheduler
Status & Plan
Elev. Mgr
Service Personnel
Status & Plan
Elev. Control
Elevator
Arrival Sensor
at floor
updown
inelevator
abovebelow
at requestedfloor motor
stop
door openswitch on
add tolist
removefrom list
selectelevator [not requested] [requested]
User
Service Personnel
Elevator
Scheduler
Status & Plan
Status & Plan
Elev. Control
Elev. Mgr
inelevator
abovebelow
decide ondirection
[else] doorclose
motorupmotor
down
moving
at floor
updown
selectelevator Arrival Sensor
approachingfloor
[not requested]
motorstop
door open
stationary-memory
switch on
doorclosing-delay
add tolist
alreadyon list
[on list]
[requested]
removefrom list
at requestedfloor
Arch. Alternative (II)
Model 2 – Use Case Map
TDT 4242
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
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
55
Trondheim, Norway
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 [email protected]
http://www.UseCaseMaps.org
TDT 4242