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 Mussbacherdamyot@site.uottawa.ca

http://www.UseCaseMaps.org

TDT 4242