Introduction to Use Case Maps

(1)

s

e Maps

By: I Gede Made Karma

Introduction to

Use Case Maps

Use Ca

s

By: I Gede Made Karma

Taken from:

Daniel Amyot, Gunter Mussbacher

damyot@site.uottawa.ca

http://www.UseCaseMaps.org

Page 2

Table of Contents

Requirements & Software Engineering Issues

Introduction to Use Case Maps

UCM Usage

–

Requirements Capture

–

Architectural Evaluation

–

Transformations to Designs and Tests

Page 3

Requirements Engineering

Issues

Early focus on low-level abstractions

Requirements and high-level decisions buried

in the details

Evolution of functionalities difficult to handle

(feature interactions, adaptability to legacy

architectures...)

Delay introduction of new services

Page 4

Software Engineering Issues

Requirements/analysis models need to

support new types of dynamic systems

–

Run-time modification of system structure

R n time modification of beha io r

–

Run-time modification of behaviour

Need to go from a requirements/analysis

model to design models in a seemless way

We propose

Use Case Maps (UCMs)

!

Page 5

Table of Contents

Introduction to Use Case Maps

UCM Usage

g

–

Validation and Feature Interaction Detection

Page 6

Use Case Maps (UCMs)

The

Use Case Maps

notation allows

illustrating a scenario path relative to

optional

components involved in the scenario

(gray box view of system)

UCMs are a scenario-based software

engineering technique for describing

causal

relationships between responsibilities of one

or more use cases

UCMs show related use cases in a map-like

(2)

Page 7

UCM Notation - Basic

UCM Example: Commuting

home

transport

elevator

secure

home

X

commute

X

take

elevator

ready

to

leave

home

in

cubicle

Responsibility Point

Basic Path

(from circle to bar)

Component

(generic)

Page 8

Why Use Case Maps?

Bridge

the

modeling gap

between requirements

(use cases) and design

–

Link behavior and structure in an explicit and visual way

–

Provide a behavioral framework for making (evaluating)

architectural decisions at a high level of design

–

Characterize the behavior at the architecture level once the

architecture is decided

Convey a lot of information in a compact form

Use case maps

integrate many scenarios

- enables

reasoning about potential undesirable interactions of

scenarios

Page 9

Why Use Case Maps?

Provide ability to

model dynamic systems

where

scenarios and structures may change at run-time

–

E-commerce applications

–

Telecommunication systems based on agents

Simple, intuitive, low learning curve

Document while you design

Effective learning tool for people unfamiliar with the

domain

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

diagrams, performance models, test cases)

Page 10

The Development Pyramid

Requirements

NFR Use cases Problem modeling

Analysis/ High-level Design

Detailed design

Implementation

Use Case Maps

Sequence/collaboration diagrams, statechart diagrams, class/object diagrams, component/deployment diagrams (UML);

message sequence charts, SDL (ITU-T)

Code

Page 11

UCM Notation - Hierarchy

UCM Example: Commuting

home

transport

elevator

secure

t

take

ready

to

leave

home

in

cubicle

secure

home

X

commute

X

take

elevator

home

commute

elevator

Dynamic Stub

(selection policy)

Static Stub

stay

home

Page 12

UCM Notation - Simple Plug-in

UCM Example: Commute - Car (Plug-in)

transport

X

(3)

Page 13

UCM Notation - AND/OR

UCM Example: Commute - Bus (Plug-in)

person

read

Dilbert

X

take 182

AND Fork

OR Fork

OR Join

AND Join

transport

X

take 97

X

take 95

Page 14

UCM Notation

-Dynamic Structures

Generic UCM Example

start

slot A

+

create

Generic UCM Example

start

slot A

+

create

(component)

Slot

-end

Dynamic Responsibilities and Dynamic Components

pool A

pool B

slot B

copy

destroy

-destroy

+

move out

move into

end

pool A

pool B

move out

slot B

move into

copy

move into

destroy

-destroy

+

Pool

(component)

Page 15

Table of Contents

UCM Usage

g

–

Validation and Feature Interaction Detection

–

Transformations to Designs and Tests

Standardization

Research Issues

Page 16

User

Elevator Control System

in

elevator

above

below

add to list

no requests

[stationary]

[moving]

[not requested]

door close

motor up

motor down

moving

decide on

direction

motor

stop

[requested]

at requested

floor

Arrival Sensor

approaching

floor

door

closing-delay

[else]

no requests

stop

door

open

Select Destination

remove

from 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.

Page 17

Transformations to Designs and Tests

Standardization

Research Issues

Page 18

User

Arrival Sensor

Scheduler

Elevator

in

elevator

above

below

decide on

direction

[else]

door

close

moving

at floor

up

down

select

elevator

approaching

floor

[not requested]

[requested]

add to

list

[on list]

already

on list

Service Personnel

[else]

motor

up

motor

down

motor

stop

door open

at requested

floor

stationary-memory

switch on

door

closing-delay

remove from list

(4)

Page 19

User

Elevator Scheduler

Status&Plan Status&Plan

Elev. Control

Elev. Mgr

in elevator above

below

decide on direction

[else] door

close moving at floor

up down

select

elevator Arrival Sensor

approaching floor [not requested]

already on list

[on list]

[requested]

Service Personnel Status&Plan

motor up_motor

down

motor stop

door open

stationary-memory

switch on door

closing-delay add to

list

remove from list at requested

floor

Arch. Alternative (II)

Page 20

Table of Contents

UCM Usage

g

–

Transformations to Designs and Tests

Standardization

Research Issues

Page 21

Generic Problem with Scenarios

Given a set of scenarios capturing informal

(functional) requirements

Specify (formally) the integration of scenarios

–

Undesirable emergent behaviour may result…

Validate, i.e. look for logical errors and check

against informal requirements

Numerous tools and techniques can be

applied (e.g. functional testing)

Page 22

UCM Validation by Inspection

Several problems detectable by inspection

–

Non-determinism in selection policies and OR-forks

–

Erroneous UCMs

A bi

UCM

l

k f

t

–

Ambiguous UCMs, lack of comments

Many

feature interactions

(FI) solved while

integrating feature scenarios together

Remaining undesirable FI need to be detected!

–

Many are located in stubs and selection

policies

–

Need more formal analysis

Page 23

Feature Interaction

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

out

ORIG

TERM

Page 24

Feature Interaction

Unexpected behavior among different selected

plug-ins for different stubs (postconditions of plug-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

out

(5)

Page 25

Analysis Model Construction

Source scenario model

⇒

Target analysis model

Q1. What should the target language be?

–

Use Case Maps Specification

⇒

?

Q2 What should the construction strategy be?

Q2. What should the construction strategy be?

–

Analytic approach

build-and-test construction

–

Synthetic approach

scenarios "compiled" into new target model

interactive or automated

Several approaches studied (UCM to LOTOS, UCM to