Tutorial

on

Message

Sequence

Charts

Ekkart

Rudolpha

Peter

Graubmannb

and

Jens

Grabowskic

aTechnical

University

of

Munich

Institute

for

Informatics

Arcisstrasse

M?unchen

Germany

eMail

rudolphe@informatik.tu-muenchen.de

bSiemens

AG

ZFE

T

SE

Otto-Hahn-Ring

M?unchen

Germany

eMail

gr@zfe.siemens.de

cMedical

University

of

L?ubeck

Institute

for

Telematics

Ratzeburger

Allee

L?ubeck

Germany

eMail

jens@itm.mu-luebeck.de

An

introduction

to

the

ITU

standard

language

Message

Sequence

Chart

-LRB-

MSC

-RRB-

is

provided

It

is

pointed

out

that

MSC

in

many

respects

is

complementary

to

the

ITU

specification

and

design

language

SDL

MSC

in

combination

with

SDL

or

other

languages

now

plays

a

role

in

nearly

all

stages

of

the

system

development

process

Since

MSC

has

been

standardized

in

the

same

study

group

as

SDL

the

language

form

is

quite

analogous

e.g.

it

has

a

graphical

-LRB-

MSC/GR

-RRB-

and

a

textual

-LRB-

MSC/PR

-RRB-

syntax

form

The

MSC

language

in

the

present

recommendation

Z.

-LRB-

MSC

-RRB-

comprises

basic

language

elements

instance

message

environment

action

timer

process

creation

and

termination

condition

and

structural

language

elements

coregion

and

submsc

It

is

demonstrated

how

global

and

non-global

conditions

may

be

used

for

the

composition

of

MSCs

Whereas

in

MSC

main

emphasis

is

put

on

the

elaboration

of

basic

concepts

and

a

corresponding

formal

semanrics

in

the

new

MSC

version

-LRB-

MSC

-RRB-

structural

language

constructs

essentially

composition

and

object

oriented

concepts

will

play

a

dominant

role

With

these

new

concepts

the

power

of

MSC

is

enhanced

considerably

in

order

to

overcome

the

traditional

restriction

of

MSC

to

the

specification

of

few

selected

system

runs

Introduction

Message

Sequence

Charts

-LRB-

MSCs

-RRB-

are

a

widespread

means

for

the

visualization

of

selected

system

runs

-LRB-

traces

-RRB-

within

communication

systems

MSC

can

be

viewed

as

a

special

trace

language

which

mainly

concentrates

on

message

interchange

by

communicating

entities

-LRB-

such

as

SDL

services

processes

blocks

-RRB-

and

their

environment

A

main

advantage

of

an

MSC

is

its

clear

graphical

layout

which

immediately

gives

an

intuitive

understanding

of

the

described

system

behaviour

MSCs

have

been

used

informally

for

a

long

time

by

ITU

-LRB-

former

CCITT

-RRB-

Study

Groups

in

their

recommendations

and

in

industry

Their

standardization

was

suggested

at

the

th

SDL

Forum

October

in

Lisbon

-LSB-

-RSB-

and

agreed

upon

at

the

ITU-meeting

Helsinki

June

-LSB-

-RSB-

At

the

closing

session

of

the

ITU

study

period

in

Geneva

May

the

new

MSC

recommendation

Z.

-LSB-

-RSB-

was

approved

Within

the

present

study

period

as

a

major

achievement

a

formal

semantics

for

MSCs

based

on

process

algebra

has

been

standardized

-LSB-

-RSB-

A

standard

document

on

static

syntax

requirements

is

in

preparation

-LSB-

-RSB-

Besides

formal

semantics

main

emphasis

is

put

on

structural

concepts

-LSB-

-RSB-

The

reason

to

standardize

MSCs

was

to

allow

systematic

tool

support

to

facilitate

the

exchange

between

different

tools

and

to

ease

the

mapping

to

and

from

SDL

specifications

Due

to

the

standardization

the

importance

of

MSCs

for

system

engineering

has

increased

considerably

Accordingly

MSCs

are

used

ffl

for

requirement

definition

-LSB-

-RSB-

ffl

as

an

overview

specification

of

process

communication

-LSB-

-RSB-

ffl

as

an

interface

specification

-LSB-

-RSB-

ffl

as

a

basis

for

automatic

generation

of

skeleton

SDL

specifications

-LSB-

-RSB-

ffl

for

simulation

and

consistency

check

of

SDL

specifications

-LSB-

-RSB-

ffl

as

a

basis

for

selection

and

specification

of

test

cases

-LSB-

-RSB-

ffl

for

documentation

-LSB-

-RSB-

ffl

for

object

oriented

design

and

analysis

-LRB-

object

interaction

-RRB-

-LSB-

-RSB-

Why

yet

another

Specification

Language

One

way

to

understand

the

meaning

and

the

usefulness

of

MSCs

may

be

by

relating

them

to

other

specification

languages

like

SDL

LOTOS

or

Petri

Nets

In

practice

the

MSC

language

is

used

most

frequently

in

connection

with

SDL

and

indeed

in

addition

it

also

has

been

standardized

in

the

same

ITU-T

study

group

as

SDL

What

was

the

reason

for

the

introduction

of

yet

another

standard

language

besides

SDL

SDL

processes

and

MSCs

can

be

looked

at

as

two

different

kinds

of

system

representations

which

are

complementary

in

many

respects

SDL

provides

a

clear

and

comprehensive

behaviour

description

within

individual

SDL

processes

whereas

the

communication

between

several

processes

is

represented

in

a

fairly

indirect

manner

and

thus

the

description

of

the

communication

behaviour

in

SDL

for

many

purposes

is

not

sufficiently

transparent

Contrary

to

that

MSCs

focus

on

the

communication

behaviour

of

system

components

and

their

environment

by

means

of

message

exchange

MSCs

provide

a

clear

description

of

system

traces

in

form

of

message

flow

diagrams

In

contrast

to

SDL

the

set

of

specified

MSCs

usually

covers

a

partial

system

behaviour

only

since

each

MSC

represents

exactly

one

scenario

So

candidates

for

MSCs

are

primarily

the

standard

cases

These

standard

cases

may

be

supplemented

by

MSCs

describing

exceptional

behaviour

altogether

providing

a

use

case

like

representation

-LSB-

-RSB-

Recently

attempts

have

been

made

to

enhance

the

language

and

to

make

a

fairly

comprehensive

system

description

feasible

by

using

composition

and

object

oriented

techniques

Most

certainly

however

the

main

importance

of

MSCs

also

in

the

future

will

not

lie

in

complete

system

descriptions

but

rather

in

the

specification

of

special

system

properties

e.g.

of

certain

system

runs

which

should

be

allowed

or

the

other

way

round

which

should

be

disallowed

More

generally

MSCs

have

been

proposed

for

the

intuitive

representation

of

temporal

logics

expressions

Within

the

system

development

process

MSCs

play

a

role

in

nearly

all

stages

-LRB-

see

Chapter

-RRB-

complementing

SDL

in

many

respects

In

all

cases

the

strength

of

MSCs

lies

in

the

clear

and

intuitive

description

of

selected

system

runs

whereas

SDL

is

used

for

a

complete

system

specification

It

should

be

pointed

out

that

the

usual

incompleteness

of

MSCs

does

not

mean

that

they

have

only

informal

i.e.

illustrative

character

within

a

system

development

Their

role

may

very

well

be

formalized

e.g.

MSCs

may

represent

test

purposes

for

the

automatic

generation

of

test

cases

as

it

is

done

within

the

SAMSTAG

method

-LSB-

-RSB-

For

an

illustration

of

the

relation

between

SDL

and

MSC

in

the

following

we

use

the

Inres

service

specification

as

a

standard

example

-LSB-

-RSB-

Let

us

consider

the

MSC

conreq

in

Figure

which

describes

a

selected

trace

piece

of

the

connection

set-up

in

the

Inres

service

specification

An

Initiator-user

sends

a

connection

request

-LRB-

ICONreq

-RRB-

to

the

Initiator

The

Initiator

transmits

the

request

-LRB-

ICON

-RRB-

to

the

Responder

entity

which

afterwards

indicates

the

connection

request

-LRB-

ICONind

-RRB-

to

its

user

The

MSC

is

related

to

corresponding

paths

in

SDL

process

diagrams

-LRB-

Figure

-RRB-

where

the

path

corresponding

to

the

MSC

in

Figure

is

indicated

by

bold

arrows

Obviously

the

trace

described

by

the

MSC

can

be

represented

also

in

form

of

SDL

diagrams

The

correspondence

between

Figure

and

Figure

may

serve

to

give

a

good

intuitive

idea

about

the

meaning

but

also

the

usefulness

of

MSCs

It

also

demonstrates

that

an

MSC

describing

one

possible

scenario

can

be

viewed

as

an

SDL

skeleton

-LSB-

-RSB-

Obviously

the

MSC

in

Figure

is

far

more

transparent

than

Figure

since

it

concentrates

on

the

relevant

information

namely

the

instances

-LRB-

Initiator

Responder

-RRB-

and

the

messages

involved

in

the

selected

trace

piece

-LRB-

ICONreq

ICON

ICONind

-RRB-

The

MSC

Language

MSC/PR

and

MSC/GR

In

analogy

to

the

SDL

recommendation

Z.

-LSB-

-RSB-

the

new

MSC

recommendation

Z.

-LSB-

-RSB-

includes

two

syntactical

forms

MSC/PR

as

a

pure

textual

and

MSC/GR

as

a

graphical

representation

An

MSC

in

MSC/GR

representation

can

be

transformed

automatically

into

a

corresponding

MSC/PR

representation

The

other

way

round

the

same

problems

arise

as

in

SDL

since

MSC/PR

-LRB-

like

SDL/PR

-RRB-

does

not

include

graphical

information

such

as

height

width

or

alignment

of

symbols

and

texts

An

example

of

the

MSC/GR

and

the

corresponding

MSC/PR

representation

is

shown

in

Figure

The

MSC/PR

presently

contained

in

Z.

lists

message

sending

and

receiving

events

in

association

with

an

instance

Recently

a

better

readable

notation

was

requested

in

particular

in

cases

where

MSC/PRs

were

not

only

used

internally

by

tools

but

also

edited

by

humans

Thus

a

new

event

oriented

textual

representation

was

elaborated

-LSB-

-RSB-

where

events

are

listed

in

form

of

a

possible

execution

trace

and

not

ordered

with

respect

to

instances

The

event

oriented

textual

grammar

is

closer

to

the

graphical

grammar

than

the

instance

oriented

syntax

and

details

concerning

the

graphical

representation

are

expressible

contrary

to

the

present

instance

oriented

textual

syntax

This

is

particularly

important

for

applications

where

an

MSC

semantics

variant

is

preferred

describing

global

event

ordering

i.e.

a

global

time

scale

in

contrast

to

the

present

partial

ordering

interpretation

of

MSC

diagrams

Such

applications

arise

in

case

of

validation

tracing

debugging

ICONreq

ICON

Initiator

process

process

Responder

msc

conreq

ICONind

Figure

Connection

Request

DISCONNECTEDWAITDISCONNECTEDWAITDISCONNECTEDIDAT

-LRB-

D

-RRB-

IDISDISCONNECTEDICO

NreqICONICONIDISindSET

-LRB-

NOW

T

-RRB-

ICONindanyInitiatorResponder

Figure

SDL-diagram

corresponding

to

the

MSC

in

Figure

ICONind

ICONresp

process

Responder

Initiator

process

msc

ICONreq

ICON

ICONF

ICONconf

connection

msc

connection

inst

Initiator

Responder

instance

Initiator

process

ISAP

Manager

Ini

in

ICONreq

from

env

out

ICON

to

Responder

in

ICONF

from

Responder

out

ICONconf

to

env

endinstance

instance

Responder

process

ISAP

Manager

Resp

in

ICON

from

Initiator

out

ICONind

to

env

in

ICONresp

from

env

out

ICONF

to

Initiator

endinstance

endmsc

Figure

MSC

in

MSC/GR

and

in

the

corresponding

MSC/PR

simulation

and

test

case

specification

Consequently

a

PR-GR

transformation

is

easier

-LRB-

less

ambiguous

-RRB-

for

the

event

oriented

than

for

the

instance

oriented

textual

grammar

Furthermore

the

event

oriented

grammar

is

demanded

within

special

stages

of

system

development

it

is

particularly

applied

when

execution

sequences

from

e.g.

simulations

have

to

be

recorded

For

the

example

of

Figure

the

following

event

oriented

textual

syntax

description

is

obtained

msc

connection

inst

Initiator

Responder

Initiator

instancehead

process

ISAP

Manager

Ini

Responder

instancehead

process

ISAP

Manager

Resp

Initiator

in

ICONreq

from

env

Initiator

out

ICON

to

Responder

Responder

in

ICON

from

Initiator

Responder

out

ICONind

to

env

Responder

in

ICONresp

from

env

Responder

out

ICONF

to

Initiator

Initiator

in

ICONF

from

Responder

Initiator

out

ICONconf

to

env

Initiator

endinstance

Responder

endinstance

endmsc

In

order

to

be

able

to

combine

the

advantages

of

both

textual

syntax

forms

a

mixture

of

syntax

forms

is

allowed

Basic

Language

Elements

The

basic

language

of

MSCs

includes

all

constructs

which

are

necessary

in

order

to

specify

the

pure

message

flow

For

MSCs

these

language

constructs

are

instance

message

environment

action

timer

set

timer

reset

time-out

instance

creation

instance

stop

and

condition

Instances

and

Messages

The

most

fundamental

language

constructs

of

MSCs

are

instances

-LRB-

e.g.

entities

of

SDL

systems

blocks

processes

or

services

-RRB-

and

messages

describing

the

communication

events

In

the

graphical

representation

instances

are

shown

by

vertical

lines

or

alternatively

by

columns

-LRB-

Figure

-RRB-

Within

the

instance

heading

an

entity

name

e.g.

process

type

may

be

specified

in

addition

to

the

instance

name

The

message

flow

is

presented

by

arrows

which

may

be

horizontal

or

with

a

downward

slope

with

respect

to

the

direction

of

the

arrow

to

indicate

the

flow

of

time

In

addition

the

horizontal

arrow

lines

may

be

bended

to

admit

message

overtaking

or

crossing

-LRB-

Figure

-RRB-

The

head

of

the

message

arrow

denotes

the

event

message

consumption

the

opposite

end

the

event

message

sending

In

addition

to

the

message

name

message

parameters

in

parentheses

may

be

assigned

to

a

message

-LRB-

Figure

-RRB-

Along

each

instance

axis

a

total

ordering

of

the

described

communication

events

is

assumed

Events

of

different

instances

are

ordered

only

via

messages

since

a

message

must

be

sent

before

it

is

consumed

System

Environment

Within

an

MSC

the

system

environment

is

graphically

represented

by

the

frame

symbol

which

forms

the

boundary

of

an

MSC

diagram

In

contrast

to

instances

no

ordering

of

block

Medium

Initiator

block

Responder

block

ICONreq

msc

Counter

MDATreq

-LRB-

CR

-RRB-

ICONind

MDATind

-LRB-

CR

-RRB-

ICONresp

ICONconf

MDATind

-LRB-

CC

-RRB-

MDATreq

-LRB-

CC

-RRB-

Figure

Action

ICONreq

T

IDISind

Initiator

process

process

Responder

msc

ICON

ICONind

Time-out

-LRB-

a

-RRB-

Time-out

Initiator

process

process

Responder

msc

ICONind

IDISreq

Timer-Reset

IDIS

IDISind

T

ICONreq

ICON

-LRB-

b

-RRB-

Timer

Reset

Figure

MSC

timer

constructs

communication

events

is

assumed

within

the

environment

Actions

In

addition

to

message

exchange

actions

describing

an

internal

activity

of

an

instance

may

be

specified

An

action

is

graphically

represented

by

a

rectangle

containing

arbitrary

text

-LRB-

Figure

-RRB-

Timer

Timer

handling

in

MSCs

encloses

the

setting

of

a

timer

and

a

subsequent

time-out

-LRB-

timer

expiration

-RRB-

or

the

setting

of

a

timer

and

a

subsequent

timer

reset

-LRB-

time

supervision

-RRB-

The

corresponding

MSC/GR

constructs

are

shown

in

Figure

The

new

timer

symbols

differing

from

the

graphical

symbols

defined

in

Z.

have

been

requested

and

elaborated

within

the

present

study

period

They

will

be

part

of

MSC

-LSB-

-RSB-

The

individual

timer

constructs

-LRB-

timer

setting

reset/timeout

-RRB-

may

be

split

between

different

MSCs

in

cases

where

the

whole

scenario

is

obtained

from

the

composition

of

several

process

msc

Creation-termination

Controller

process

ICONind

Failure

-LRB-

failure

-RRB-

ALERT

-LRB-

failure

-RRB-

CONreq

DISind

-LRB-

failure

-RRB-

Figure

Instance

creation

and

termination

MSCs

-LRB-

cf.

Section

-RRB-

The

setting

of

a

timer

is

represented

by

an

hour-glass

connected

with

the

instance

axis

by

a

-LRB-

bended

-RRB-

line

symbol

The

reset

symbol

is

presented

by

a

cross

-LRB-

X

-RRB-

again

connected

with

the

instance

axis

by

a

-LRB-

bended

-RRB-

line

symbol

Time-out

is

described

by

an

arrow

which

is

connected

to

the

hour-glass

symbol

An

-LRB-

optional

-RRB-

timer

description

containing

name

and

duration

may

be

associated

with

each

timer

symbol

In

complete

system

descriptions

for

each

timer

setting

a

corresponding

time-out

or

timer

reset

respectively

has

to

be

specified

and

vice

versa

The

corresponding

symbols

however

do

not

necessarily

appear

within

the

same

MSC

Creation

and

Termination

of

Instances

Creation

and

termination

of

instances

within

communication

systems

are

quite

common

events

This

is

due

to

the

fact

that

most

communication

systems

are

dynamic

systems

where

instances

appear

and

disappear

during

system

run

time

Consequently

a

system

designer

needs

features

to

describe

such

events

The

corresponding

MSC

language

elements

are

shown

in

Figure

The

create

symbol

is

a

dashed

arrow

which

may

be

associated

with

textual

parameters

A

create

arrow

originates

from

a

parent

instance

and

points

at

the

instance

head

of

the

child

instance

Correspondingly

to

messages

a

create

event

may

be

labeled

with

a

parameter

list

An

instance

can

terminate

by

executing

a

process

stop

event

Execution

of

a

process

stop

is

allowed

only

as

last

event

in

the

description

of

an

instance

The

termination

of

an

instance

is

graphically

represented

by

a

stop

symbol

in

form

of

a

cross

at

the

end

of

the

instance

axis

-LRB-

Figure

-RRB-

Conditions

A

condition

describes

a

state

referring

to

a

non-empty

set

of

instances

specified

in

the

MSC

A

condition

either

describes

a

global

system

state

referring

to

all

instances

contained

in

the

MSC

in

the

following

called

global

condition

or

a

state

referring

to

a

subset

of

instances

also

called

non-global

condition

If

it

refers

to

one

instance

only

a

condition

is

called

local

Conditions

can

be

used

to

emphasize

important

states

within

an

MSC

or

for

the

composition

and

decomposition

of

MSCs

-LRB-

Section

-RRB-

In

the

MSC/GR

representation

local

global

and

non-global

conditions

are

represented

by

hexagons

covering

the

instances

involved

-LRB-

Figure

-RRB-

In

the

textual

representation

the

condition

has

to

be

defined

on

every

instance

it

refers

to

using

the

keyword

condition

together

with

the

condition

name

If

the

condition

refers

to

more

than

one

instance

the

keyword

shared

together

with

an

instance

list

denotes

the

set

of

instances

to

which

the

condition

is

attached

By

means

of

the

keyword

shared

all

a

condition

referring

to

all

instances

may

be

defined

Structural

Language

Elements

The

structural

language

elements

of

MSCs

include

all

constructs

which

can

be

used

to

specify

more

general

MSCs

or

to

refine

MSCs

The

current

MSC

recommendation

offers

the

coregion

and

the

submsc

constructs

Coregion

Along

an

MSC

instance

normally

a

total

ordering

of

message

events

is

assumed

This

may

not

be

appropriate

for

MSC

instances

referring

to

a

level

higher

than

SDL

processes

To

cope

with

this

a

coregion

is

introduced

A

coregion

is

graphically

represented

by

a

dashed

section

of

an

MSC

instance

Within

a

coregion

the

specified

communication

events

are

not

ordered

At

present

only

message

events

may

be

specified

within

a

coregion

however

a

coregion

may

contain

an

arbitrary

mixture

of

message

inputs

and

outputs

-LRB-

Figure

-RRB-

Submsc

Since

MSCs

can

be

rather

complex

there

is

a

need

for

a

refinement

of

one

instance

by

a

set

of

instances

defined

in

another

MSC

An

MSC

instance

can

be

refined

by

another

MSC

which

is

then

called

submsc

By

means

of

the

keyword

decomposed

a

submsc

with

the

same

name

is

attached

to

the

refined

instance

The

submsc

represents

a

decomposition

of

this

instance

without

affecting

its

observable

behaviour

The

messages

addressed

to

and

coming

from

the

exterior

of

the

submsc

are

characterized

by

the

messages

connected

with

the

submsc

border

-LRB-

frame

symbol

-RRB-

Their

connection

with

the

external

instances

is

provided

by

the

messages

sent

and

consumed

by

the

corresponding

decomposed

instance

using

message

name

identification

It

must

be

possible

to

map

the

external

behaviour

of

the

submsc

to

the

messages

of

the

decomposed

instance

The

ordering

of

message

events

specified

along

the

decomposed

instance

must

be

preserved

in

the

submsc

Actions

and

conditions

within

a

submsc

may

be

looked

at

as

a

refinement

of

actions

and

conditions

in

the

decomposed

instance

Contrary

to

messages

however

no

formal

mapping

to

the

decomposed

instance

is

assumed

i.e.

the

refinement

of

actions

and

conditions

needs

not

obey

formal

rules

Figure

shows

the

refinement

of

the

instance

Inres

service

by

a

submsc

Composition

of

MSCs

Since

one

MSC

only

describes

a

partial

system

behaviour

it

is

advantageous

to

have

a

number

of

simple

MSCs

that

can

be

combined

in

different

ways

To

determine

possible

combinations

the

already

introduced

-LRB-

global

and

non-global

-RRB-

conditions

may

be

used

employing

certain

composition

and

decomposition

rules

which

presently

are

part

of

the

methodology

guidelines

-LSB-

-RSB-

According

to

the

recent

ITU-T

work

this

composition

may

be

defined

within

roadmaps

-LRB-

cf.

Section

-RRB-

MSCs

can

be

composed

by

name

identification

of

final

and

initial

-LRB-

global

or

non-global

-RRB-

conditions

The

other

way

round

MSCs

can

be

decomposed

at

intermediate

-LRB-

global

msc

decomposed

ICONreq

IDISind

ICONind

-LRB-

a

-RRB-

MSC

with

coregion

ICONreq

T

IDISind

Initiator

process

process

Responder

ICON

ICONind

submsc

-LRB-

b

-RRB-

Refinement

of

Inres

service

in

-LRB-

a

-RRB-

Figure

Sample

application

of

structural

concepts

or

non-global

-RRB-

conditions

Initial

conditions

denote

the

starting

states

final

conditions

represent

end

states

and

intermediate

conditions

describe

arbitrary

states

within

MSCs

An

example

of

an

MSC

composition

by

means

of

non-global

conditions

is

shown

in

Figure

The

MSC

Connection

-LRB-

Figure

-RRB-

is

a

composition

of

the

MSCs

Connection

request

-LRB-

Figure

-RRB-

and

Connection

confirm

-LRB-

Figure

-RRB-

Composition

and

decomposition

of

MSCs

obey

the

rules

for

global

and

non-global

conditions

given

below

Here

global

conditions

refer

to

all

instances

involved

in

the

MSC

whereas

non-global

conditions

are

attached

to

a

subset

of

instances

Composition

by

Means

of

Global

Conditions

Two

MSCs

and

can

be

composed

sequentially

if

both

MSCs

contain

the

same

set

of

instances

and

if

the

initial

condition

of

corresponds

to

the

final

condition

of

according

to

name

identification

The

final

condition

of

and

the

initial

condition

of

become

an

intermediate

condition

within

the

composed

MSC

Composition

by

Means

of

Non-global

Conditions

Two

MSCs

and

can

be

composed

by

means

of

non-global

conditions

if

for

each

instance

which

both

MSCs

have

in

common

ends

with

a

non-global

condition

and

begins

with

a

corresponding

non-global

condition

Corresponding

to

the

MSC

composition

MSCs

can

be

decomposed

due

to

intermediate

conditions

Outlook

The

MSC

standardization

activities

during

the

ITU-T

study

period

have

concentrated

on

the

elaboration

of

the

syntax

and

informal

semantics

for

basic

MSCs

A

revised

version

of

Z.

containing

enhancements

and

modifications

is

planned

for

Enhancements

and

modifications

of

MSCs

can

be

classified

with

respect

to

basic

MSCs

and

structural

concepts

For

MSC

basic

concepts

the

elaboration

of

an

enhanced

textual

syntax

has

been

the

main

goal

of

the

standardization

activities

apart

from

the

search

for

new

more

intuitive

timer

symbols

-LRB-

Section

-RRB-

New

structural

concepts

mainly

concern

generalized

causal

ordering

MSC

composition

and

object-oriented

modeling

It

should

be

noted

that

these

language

constructs

are

still

under

discussion

in

the

Initiator

process

process

Responder

msc

ICONreq

ICON

ICONind

wait

wait

disconnected

disconnected

-LRB-

a

-RRB-

Connection

request

Initiator

process

process

Responder

msc

wait

wait

ICONresp

ICONF

ICONconf

connected

-LRB-

b

-RRB-

Connection

confirm

Initiator

process

process

Responder

msc

ICONreq

ICON

ICONind

disconnected

disconnected

Connection

wait

wait

ICONresp

ICONF

ICONconf

connected

-LRB-

c

-RRB-

MSC

composed

of

-LRB-

a

-RRB-

and

-LRB-

b

-RRB-

Connection

connected

wait

wait

disconnected

disconnected

-LRB-

d

-RRB-

Corresponding

MSC

road

map

Figure

Composition

and

decomposition

of

MSCs

ITU-T

Their

selection

and

presentation

within

this

tutorial

in

many

respects

reflect

the

standpoint

and

the

preferences

of

the

authors

Generalized

Coregion

The

present

Z.

is

restricted

to

total

event

ordering

on

MSC

instances

-LRB-

normal

case

-RRB-

and

coregions

which

denote

complete

unordering

of

the

contained

events

Since

MSC

instances

may

refer

to

higher

level

entities

like

e.g.

SDL

blocks

or

SDL

systems

language

constructs

for

the

specification

of

more

general

causal

orderings

within

one

instance

are

demanded

Obviously

language

constructs

concerning

generalized

causal

ordering

are

necessary

also

for

decomposed

instances

and

submscs

Accordingly

dependencies

-LRB-

or

lack

of

dependencies

-RRB-

between

events

as

a

generalization

of

the

coregion

construct

have

to

be

expressed

As

a

straightforward

generalization

the

coregion

is

enhanced

by

special

symbols

called

connections

denoting

the

causal

ordering

-LRB-

Figure

-RRB-

No

event

ordering

is

prescribed

by

the

vertical

dashed

borders

of

the

column

itself

The

connections

define

the

ordering

in

an

intuitive

manner

they

indicate

the

time

direction

from

top

to

bottom

-LRB-

which

is

a

generalization

of

the

time

ordering

concept

for

instances

in

the

present

Z.

-RRB-

Event

is

causally

ordered

with

respect

to

event

ICONreq

IDISind

ICONind

ICONresp

msc

ICONind

ICONresp

ICONreq

IDISind

Figure

Causal

relations

defined

by

connections

-LRB-

extension

of

coregion

-RRB-

decomposed

as

msc

msc

Figure

New

decomposition

clause

-LRB-

-RRB-

if

and

only

if

and

are

connected

and

can

be

reached

from

by

following

the

vertical

connections

in

the

direction

from

top

to

bottom

only

Accordingly

in

the

example

in

Figure

we

have

the

following

causal

ordering

ICONreq

ICONind

ICONresp

and

ICONreq

IDISind

Submsc

The

assignment

of

a

submsc

to

a

decomposed

instance

by

means

of

name

identification

in

general

is

too

narrow

There

are

cases

were

instances

with

the

same

name

in

different

MSCs

should

be

decomposed

into

different

submscs

The

decomposition

clause

may

be

extended

by

an

optional

term

which

names

the

MSC

that

defines

the

decomposition

-LRB-

Figure

-RRB-

At

the

same

time

the

term

submsc

becomes

superfluous

MSC

Composition

In

addition

to

the

sequential

composition

of

MSCs

based

on

conditions

real

world

telecom

examples

demand

further

composition

operators

such

as

parallel

composition

alternative

composition

iteration

and

interrupt

handling

As

a

main

representative

in

the

following

a

special

parallel

merge

operation

with

synchronization

the

environmental

merge

is

sketched

The

environmental

merge

may

be

understood

as

a

horizontal

merge

operation

A

special

application

could

be

the

horizontal

paging

Some

other

parallel

merge

operations

called

synchronization

merge

and

synchronization

condition

merge

are

under

consideration

but

not

discussed

here

-LRB-

cf.

-LSB-

-RSB-

-RRB-

The

environmental

merge

operator

kenv

-LRB-

Figure

-RRB-

identifies

every

message

sent

to

or

received

from

a

gate

in

the

environment

of

the

first

MSC

with

the

message

received

from

respectively

sent

to

the

equally

named

gate

in

the

environment

of

the

second

MSC

msc

kenv

msc

msc

Figure

Environmental

merge

The

explicit

definition

of

gates

may

be

omitted

for

messages

with

unambiguous

names

in

an

MSC

The

environmental

merge

operator

then

identifies

the

equally

named

messages

to

respective

from

the

environment

in

both

MSCs

Composition

techniques

demand

an

intuitive

means

for

the

description

of

composition

operations

and

the

most

obvious

description

technique

is

provided

by

MSC

overview

diagrams

or

road

maps

-LRB-

Figure

-RRB-

Road

maps

may

include

symbols

denoting

parallel

merge

alternative

merge

and

disruption

MSC

road

maps

may

be

used

to

represent

all

possible

MSC

compositions

in

a

compact

manner

the

rectangles

represent

MSCs

the

hexagons

the

initial

and

final

conditions

of

these

MSCs

There

are

three

interpretations

of

road

maps

which

are

under

discussion

The

road

map

only

serves

as

an

additional

auxiliary

diagram

in

order

to

provide

a

better

overview

about

the

MSCs

contained

in

the

MSC

document

The

road

map

does

not

contain

information

additional

to

the

set

of

MSCs

i.e.

the

road

map

can

be

derived

from

the

set

of

MSCs

without

additional

information

The

road

map

actually

defines

the

compositions

of

MSCs

The

prescribed

compositions

only

have

to

be

in

agreement

with

the

conditions

contained

in

the

MSCs

according

to

the

definition

of

allowed

combinations

The

compositions

of

MSCs

are

exclusively

defined

by

the

road

map

Conditions

have

no

meaning

for

composition

Object

oriented

techniques

Object

oriented

techniques

often

provide

a

graphically

more

intuitive

representation

than

pure

composition

techniques

In

practice

a

combination

of

pure

composition

techniques

and

object

oriented

techniques

has

proven

to

be

most

powerful

One

of

the

major

achievements

of

SDL

compared

with

SDL

was

the

introduction

of

a

more

powerful

scheme

for

handling

recurring

patterns

In

SDL

these

concepts

were

labeled

as

object

orientation

It

might

be

very

helpful

in

the

future

use

of

the

powerful

combination

of

MSC

and

SDL

to

have

a

corresponding

concept

for

MSC

The

main

reason

for

the

introduction

of

an

MSC

type

concept

again

is

to

have

a

means

for

handling

recurring

patterns

-LRB-

as

an

alternative

for

e.g.

a

macro

construct

-RRB-

MSC

type

instances

are

a

compact

way

to

express

MSC

composition

It

is

quite

evident

that

context

parameters

can

be

introduced

Typically

messages

i.e.

actually

message

types

can

be

used

as

parameters

Possibly

instances

-LRB-

instance

kind

-RRB-

can

also

be

parameterized

Each

MSC

can

be

seen

as

a

definition

of

an

MSC

type

MSC

types

can

be

used

in

other

MSC

types

MSC

types

may

be

defined

inside

of

an

MSC

or

separately

-LRB-

Figures

-RRB-

msc

a

b

a

b

msc

Figure

MSC

type

with

gates

msc

virtual

msc

MSCvirt

MSCwithVirtMSCinheritancemsc

inherits

MSCwithVirt

with

redefined

MSCvirt

MSCvirt

redefined

msc

Figure

Virtual

MSCs

and

redefinition

An

MSC

type

may

be

connected

to

its

environment

via

message-gates

In

the

example

in

Figure

the

MSC

type

is

used

within

the

MSC

type

the

letters

a

and

b

at

the

environment

of

and

within

the

reference

symbol

to

the

MSC

type

in

denote

message

gates

Gates

are

used

to

define

the

connection

points

when

an

MSC

type

is

used

in

another

type

It

is

obvious

that

when

the

type

concept

has

been

established

it

is

not

far

to

real

object

orientation

including

inheritance

and

virtuality

Inheritance

means

that

one

MSC

type

is

a

specialization

of

another

MSC

type

The

idea

behind

virtuality

is

that

virtual

types

enclosed

in

the

general

type

may

get

a

new

definition

in

the

specialization

Virtual

means

that

it

is

possible

to

adapt

an

MSC

to

special

configurations

or

situations

by

redefining

virtual

MSC

parts

E.g.

in

Figure

the

MSC

type

MSCwithVirt

includes

the

inline

definition

of

the

virtual

type

MSCvirt

MSCinheritance

inherits

MSCwithVirt

with

the

redefinition

of

MSCvirt

This

redefinition

means

that

MSCinheritance

is

obtained

replacing

MSCvirt

in

MSCwithVirt

by

the

inline

redefinition

of

MSCvirt

In

comparison

with

pure

composition

techniques

the

presented

object

oriented

techniques

have

the

advantage

that

MSCs

which

belong

together

are

integrated

within

a

larger

frame

from

the

very

beginning

Whereas

pure

composition

technique

may

easily

end

up

in

something

like

a

puzzle

object

oriented

techniques

could

be

compared

with

a

large

painting

where

all

parts

remain

integrated

within

the

context

In

practice

the

MSC

type

concept

has

turned

out

to

be

very

useful

particularly

in

combination

with

composition

techniques

On

the

other

hand

typical

object

oriented

techniques

i.e.

inheritance

and

virtuality

need

further

studies

before

they

may

be

integrated

into

the

MSC

language

REFERENCES

B.

Algayres

Y.

Lejeune

F.

Hugonnet

F.

Hantz

The

AVALON-Project

-LCB-

A

VAL

idatiON

Environment

for

SDL/MSC

Descriptions

In

SDL

Using

Objects

-LRB-

O.

Faergemand

and

A.

Sarma

editors

-RRB-

North-Holland

Oct.

A.

Ek

Verifying

Message

Sequence

Charts

with

the

SDT

Validator

In

SDL

Using

Objects

-LRB-

O.

Faergemand

and

A.

Sarma

editors

-RRB-

North-Holland

Oct.

A.

Ek

Event-Oriented

Textual

Syntax

-LRB-

Question

-RRB-

ITU-T

Study

Group

Meeting

in

Geneva

Oct.

J.

Grabowski

P.

Graubmann

E.

Rudolph

The

Standardization

of

Message

Sequence

Charts

In

Proceedings

of

the

IEEE

Software

Engineering

Standards

Symposium

Sept.

J.

Grabowski

D.

Hogrefe

R.

Nahm

A

Method

for

the

Generation

of

Test

Cases

Based

on

SDL

and

MSCs

Technical

Report

University

of

Berne

Institute

for

Informatics

April

J.

Grabowski

D.

Hogrefe

R.

Nahm

Test

Case

Generation

with

Test

Purpose

Specification

by

MSCs

In

SDL

Using

Objects

-LRB-

O.

Faergemand

and

A.

Sarma

editors

-RRB-

North-Holland

Oct.

J.

Grabowski

E.

Rudolph

Putting

Extended

Sequence

Charts

to

Practice

In

SDL

The

Language

at

Work

-LRB-

O.

Faergemand

and

M.

M.

Marques

editors

-RRB-

North-Holland

Oct.

O.

Haugen

Case

Studies

MSC

and

Structural

Concepts

-LRB-

Question

-RRB-

ITU-T

Study

Group

Meeting

in

Geneva

Oct.

O.

Haugen

Structural

Concepts

in

MSC

Report

from

Associate

Rapporteur

-LRB-

Question

-RRB-

ITU-T

Study

Group

Meeting

in

Geneva

Oct.

D.

Hogrefe

OSI

Formal

Specification

Case

Study

The

Inres

Protocol

and

Service

-LRB-

revised

-RRB-

Technical

Report

University

of

Berne

Institute

for

Informatics

May

Update

May

ITU-T

SG

Q.

-LRB-

Rapporteur

-RRB-

Correction

List

for

Z.

-LRB-

I

-RRB-

Extensions

and

Modifications

of

Basic

Concepts

-LRB-

Question

-RRB-

ITU-T

Study

Group

Meeting

in

Geneva

Oct.

I.

Jacobson

Object-Oriented

Software

Engineering

-LCB-

A

Use

Case

Driven

Approach

Addison-Wesley

F.

Kristoffersen

Message

Sequence

Chart

and

SDL

Specification

Consistency

Check

In

SDL

Evolving

Methods

-LRB-

O.

Faergemand

and

R.

Reed

editors

-RRB-

North-Holland

R.

Nahm

Consistency

Analysis

of

Message

Sequence

Charts

and

SDL-Systems

In

SDL

Evolving

Methods

-LRB-

O.

Faergemand

and

R.

Reed

editors

-RRB-

North-Holland

M.

A.

Reniers

Syntax

Requirements

of

Message

Sequence

Charts

-LRB-

Question

-RRB-

ITU-T

Study

Group

Meeting

in

Geneva

Oct.

E.

Rudolph

P.

Graubmann

J

Grabowski

Message

Sequence

Chart

Composition

Techniques

versus

OO-Techniques

Tema

con

Variazioni

In

SDL

Proceedings

of

the

th

SDL

Forum

in

Oslo

Norway

-LRB-

R.

Braek

and

A.

Sarma

editors

-RRB-

NorthHolland

Sep.

Z.

-LRB-

-RRB-

CCITT

Specification

and

Description

Language

-LRB-

SDL

-RRB-

ITU-T

June

Z.

I

-LRB-

-RRB-

SDL

Methodology

Guidelines

Appendix

I

to

Z.

ITU-T

July

Z.

-LRB-

-RRB-

Message

Sequence

Chart

-LRB-

MSC

-RRB-

ITU-T

Sep.

Z.

B

-LRB-

-RRB-

Message

Sequence

Chart

Algebraic

Semantics

ITU-T

Publ

sched.

May

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O B O B O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B B O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O B I O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O B O O O O O O B O O B O O O O O O O B O O O O O O O O O B O O O O O O O O O B O O O O O O O O B O O O O O O O O B O B O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

composition techniques
msc
sdl
system engineering

object oriented modelling
requirement specification