Bridging the Gap Between Requirements and Design with Use Case Maps Use Case...

Use

Cas

e M

aps

Daniel Amyot, [email protected]

http://www.UseCaseMaps.org

Carleton UniversityNovember 15, 2001

Bridging the Gap Between Requirements and Design

with Use Case Maps

© 2001

Page 2

Bridging the Gap Between Requirements and Design with Use Case Maps

Requirements Engineering Issues

u Early focus on low-level abstractions

u Requirements and high-level decisions buried in the details

u Evolution of functionalities difficult to handle (feature interactions, V&V, adaptability to legacy architectures...)

u Delay introduction of new services

© 2001

Page 3


Software Engineering Issues

u Requirements/analysis models need to support new types of dynamic systems– Run-time modification of system structure– Run-time modification of behaviour

u Need to go from a requirements/analysis model to design models in a seamless way

u We propose Use Case Maps (UCMs)!

© 2001

Page 4


Use Case Maps (UCMs)

u The Use Case Maps notation allows illustrating a scenario path relative to optional components involved in the scenario (gray box view of system)

u UCMs are a scenario-based software engineering technique for describing causalrelationships between responsibilities of one or more use cases

u UCMs show related use cases in a map-like diagram

© 2001

Page 5


UCM Notation - Basic

UCM Example: Commuting

securehome

X X

commute

X

takeelevator

readyto

leavehome

incubicle

home transport elevator

Responsibility PointBasic Path(from circle to bar)

Component(generic)

© 2001

Page 6


Why Use Case Maps?

u Bridge the modeling gap between requirements (use cases) and design

– Link behaviour and structure in an explicit and visual way– Provide a behavioural framework for making (evaluating)

architectural decisions at a high level of design– Characterize the behaviour at the architecture level once the

architecture is decided

u Convey a lot of information in a compact formu Use case maps integrate many scenarios - enables

reasoning about potential undesirable interactions of scenarios

© 2001

Page 7


Why Use Case Maps?

u Provide ability to model dynamic systems where scenarios and structures may change at run-time

– E-commerce applications– Telecommunication systems based on agents

u Simple, intuitive, low learning curve u Document while you designu Effective learning tool for people unfamiliar with the

domainu May be transformed (e.g. into MSC/sequence

diagrams, performance models, test cases)

© 2001

Page 8


The Development Pyramid

Requirements

Analysis/ High-level Design

Detailed design

Implementation

NFRUse cases

Problem modeling

Use Case Maps

Sequence/collaboration diagrams, statechartdiagrams, class/object diagrams,

component/deployment diagrams (UML);message sequence charts, SDL (ITU-T)

Code

© 2001

Page 9


UCM Notation - Hierarchy

UCM Example: Commuting

readyto

leavehome

incubicle

home transport elevator

securehome

X X

commute

X

takeelevator

securehome

commutetake

elevator

Dynamic Stub(selection policy)

Static Stub

stayhome

© 2001

Page 10


UCM Notation - Simple Plug-in

UCM Example: Commute - Car (Plug-in)

transport

X

drive car

© 2001

Page 11


UCM Notation - 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

© 2001

Page 12


-

UCM Notation -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

Generic UCM Example

start

end

slot A

pool A

pool B

++

create create

move outslot B

move intocopy

move into

destroy

-

-

destroy

+

Slot(component)

Pool(component)

© 2001

Page 13


User Elevator Control System

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.

© 2001

Page 14


User

Arrival Sensor

Service Personnel

Scheduler

Elevator

inelevator

abovebelow

decide on direction

[else]

door close

motorup

motordown

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)

© 2001

Page 15


User

Service Personnel

Elevator

Scheduler

Status&Plan

Status&Plan

Elev. Control

Elev. Mgr

inelevator

abovebelow

decide ondirection

[else] doorclose

motorup motor

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)

© 2001

Page 16


Generic Problem with Scenarios

u Given a set of scenarios capturing informal (functional) requirements

u Specify (formally) the integration of scenarios– Undesirable emergent behaviour may result…

u Validate, i.e. look for logical errors and check against informal requirements

u Numerous tools and techniques can be applied (e.g. functional testing)

© 2001

Page 17


UCM Validation by Inspection

u Several problems detectable by inspection– Non-determinism in selection policies and OR-forks– Erroneous UCMs– Ambiguous UCMs, lack of comments

u Many feature interactions (FI) solved while integrating feature scenarios together

u Remaining undesirable FI need to be detected!– Many are located in stubs and selection

policies– Need more formal analysis

© 2001

Page 18


Feature Interaction

u Conflict between candidate plug-ins for the same stub (preconditions of plug-ins are the same)

– Call waiting (CW) vs. automatic re-call (ARC)

busy out

CW

busy out

ARC

in outORIG TERM

© 2001

Page 19


Feature Interaction

u Unexpected behaviour among different selected plug-ins for different stubs (postconditions of plug-ins are not the same)

– Originating call screening (OCS) denies call whereas call forward (CF) redirects call to screened number

in deny

OCS

in redirect

CF

in outORIG TERM

© 2001

Page 20


Analysis Model Construction

u Source scenario model ⇒ Target analysis model

u Q1. What should the target language be?– Use Case Maps Specification ⇒ ?

u Q2. What should the construction strategy be?– Analytic approach

u build-and-test construction

– Synthetic approachu scenarios "compiled" into new target modelu interactive or automated

© 2001

Page 21


Specification-Validation Approach with LOTOS and UCMs

Results(Coverage)

Results(Coverage)

Test Suite(LOTOS)

Add tests ifnecessary


Test CasesGeneration


Testing FrameworkAnd Patterns

Requirements

Bound UCM

Prototype(LOTOS)

Prototype(LOTOS)

Results(Functional)

Results(Functional)

ConstructionConstruction

Modify ifnecessary

Modify ifnecessary

TestingTesting

AllocationAllocation

Scenarios(UCM)

ArchitectureArchitecture

ConstructionGuidelines

© 2001

Page 22


Complementary Yet Compatible!

Use Case MapsScenario notation, readable, abstract, scalable, loose, relatively effortless to learn

Use Case MapsScenario notation, readable, abstract, scalable, loose, relatively effortless to learn

LOTOSMature formal language, good theories and tools for V&V and completeness &consistency checking.

LOTOSMature formal language, good theories and tools for V&V and completeness &consistency checking.

BothFocus on ordering of actionsHave similar constructs à simpler mappingHandle specifications with or without componentsHave been used to describe dynamic systems in the pastHave been used to detect feature interactions in the past

BothFocus on ordering of actionsHave similar constructs à simpler mappingHandle specifications with or without componentsHave been used to describe dynamic systems in the pastHave been used to detect feature interactions in the past

© 2001

Page 23


RequirementsRequirements

Scenarios(UCM)

StructureStructure

UCMs onStructure

Prototype(LOTOS)

Prototype(LOTOS)

Results(Functions)

Results(Functions)

Results(Coverage)

Results(Coverage)

Test Suite(LOTOS)






Modify ifnecessary

Modify ifnecessary

TestingTesting


UCM-LOTOS Construction Guidelines

© 2001

Page 24


UCM-LOTOS Testing Framework


Scenarios(UCM)

StructureStructure

UCMs onStructure

Prototype(LOTOS)

Prototype(LOTOS)

Results(Functions)

Results(Functions)

Results(Coverage)

Results(Coverage)

Test Suite(LOTOS)






Modify ifnecessary

Modify ifnecessary

TestingTesting


© 2001

Page 25


Structural Coverage


Scenarios(UCM)

StructureStructure

UCMs onStructure

Prototype(LOTOS)

Prototype(LOTOS)

Results(Functions)

Results(Functions)

Results(Coverage)

Results(Coverage)

Test Suite(LOTOS)






Modify ifnecessary

Modify ifnecessary

TestingTesting


© 2001

Page 26


Scenario Definitions

u Enhances the behavioural modeling capability of UCM paths and path elements

u Requires a path data model (for conditions at various points along the path)– Currently, global and modifiable Boolean variables

u Values may be assigned to variables along a path

– In future, …u Variables may possibly have different typesu Variables may be scoped to paths or componentsu Scenarios may be structured into sub-scenarios

© 2001

Page 27


OnList

Up

Requested

ExampleUser

Arrival Sensor

Elevator Control System

abovebelow

decide ondirection

at floor

updown

selectelevator

approachingfloor

at requestedfloor

motorstop

doorclosing-delay

[requested]

dooropen

removefrom list

Service Personnelswitch on

stationary-memory

[not requested]

[else]

[on list]

already on list

inelevator

add to list

movingdoor close

motor up

motor down

BR: !OnList BL: OnListBR: !Up BL: UpBR: Requested BL: !Requested

© 2001

Page 28


Scenario Definitions

u Requires a more formal definition of some notational elements– Currently, logical expressions with global variables– Currently, OR forks, selection policies, start points,

waiting places, & timers covered (in future: loops)

u Scenario definitions consist of …– Name of scenario (scenarios may be grouped for

convenience)– Set of concurrent start points– Set of initial values assigned to global variables

© 2001

Page 29


UCM Path Traversal

u Starts at one or more parallel start points as defined by user

u Starts with initial values (true, false, or undetermined) for each path data variable as defined by the user

u Moves from path element A to path element B if continuation criteria are met for element A– Each UCM path element has specific criteria

u Issues a warning if path traversal is stuck

© 2001

Page 30


��

X7

A RX6

X5X

4

X2

X1

X3

UCM Path Traversal - Example I

X7

A RX6

X5X

4

X2

X1

X3

A,12

4,��5,��

��

35

A,12,P��3,��

A,1,P��,6,��

,7,R

© 2001

Page 31


7,��

UCM Path Traversal - Example II

3B

P��4,��3,R

��

A SX8

X5X

4

X2

X1

X3

��

RB X

6

X7

5

A,12

4,��5,��

3,RB,6,��

P��P��3,R

��

A SX8

X5X

4

X2

X1

X3

��

RB X

6

X7

,8,S

© 2001

Page 32


Applications of UCM Path Traversal

u Highlightingu Animation

– Requires sequence numbers

u MSC generation– Requires component information – Well-nestedness transformation and warning mechanism

u LQN generation– Requires arrival and device characteristics, device demands,

data access modes, response-time requirements

u Test case generation– Requires controllable and observable activities

© 2001

Page 33


down

ExampleUser

Arrival Sensor

Elevator Control System

abovebelow

decide ondirection

at floor

updown

selectelevator

approachingfloor

at requestedfloor

motorstop

doorclosing-delay

[requested]

dooropen

removefrom list

Service Personnel

stationary-memory

[not requested]

[else]

[on list]

already on list

inelevator

add to list

movingdoor close

motor up

motor down

at floor

down

selectelevator

[on list]

already on list

add to list

switch on

OnList

© 2001

Page 34


!OnList

!Requested

ExampleUser

at floor

d own

elevator

approachingfloor

s top

-delay

d oor

r emovefrom list

Service Personnel

memory

[ else]

already on list

i n

m ovingm otor up

[ else]

d eci de ondi r ec t ion

i n-

door closem ovingm oving

approachingfloor

d oorclosing-delay

s top

[requested]

o pen

stationary-

[off] e xit

switch onabove

a pp. floor

s witch off

! OffOff

switch on

s wit ch off

Selected Contributionsu Amyot, D., Andrade, R., Logrippo, L., Sincennes, J., and Yi, Z. (1999) Formal Methods for Mobility

’99, Richardson, USA, D. and Andrade, R. (1999) Description of Wireless Intelligent Network Services with Use Ca

M aps. SBRC’99, Rio de Janeiro, Brazil, D., Buhr Gray, T., and , L. (1999) Use Case Maps for the Capture and Validation of

. ISRE'99, Limerick, Ireland, D. and Logrippo Use Case Maps and LOTO Sfor the Prototyping and Validation of a

. Computer Communication, 23(12)., D., Charfi Gray, T., , L., Sincennes Stepien, B., and Ware, T. (2000)

Feature description and feature interaction analysis with Use Case Maps and LO TOS. FI W'0 0, Sc otland.u Amyot, D. (2000), Use Case Maps as a Feature Description Notation. In: L ang uag e C onstruct s f o r

Designing Features, Gl asg ow, Sc otl and .u Amyot, D., and Logrippo, L. (2000) Structural Coverage for Lotos—A Probe Insertion Technique.

T est Co m ’2 000, Ottawa, Canada., D. and Mussbacher On the Extension of UML with Use Case Maps Concepts.

Y ork, UKu Amyot, D. and Eberlein, A. (2001) An Evaluation of Scenario Notations for Telecommunication Systems

. ICTS'01, Dallas, USAu Am yot, D. (2001) Specification and Validation of Telecommunications Systems with Use Case Maps and

LOTOS. Ph.D. thesis, University of Ottawa, Canadau Cameron, D. et al. (2001) Draft Specification of the User Requirements Notation, C ana dia n con t rib uti on to

-Tu Miga, A ., Amy ot, D., B ord ele au, F . , C am e ron, D ., and Wo odside, M . ( 200 1) Der ivi ng Mes sage S equ enc e

C har ts fro m U se Cas e M aps Sc enario Sp ec i fic ati ons . 10th S DL Forum, Co pen hag en, De nmarku Mussbacher, G. and Amyot, D. (2001) A Collection of Patterns for Use Case Maps,

2001, Rio de Janeiro, Brazil

Bridging the Gap Between Requirements and Design with Use Case Maps Use Case...

Documents

Transcript of Bridging the Gap Between Requirements and Design with Use Case Maps Use Case...