Lei Bu

Message Sequence Chart

MSCs

Message sequence chart (MSC) is a graphical and textual language for the description and specification of the interactions between system components.

The main area of application for MSCs is as overview specification of the communication behavior of real-time systems, in particular telecommunication switching systems.

MSCs represent typical execution scenarios, providing examples of either normal or exceptional executions of the proposed system.

The MSC standard as defined by ITU-T in Recommendation Z.120 (International Telecommunication Union - Telecommunication Standardization) 

basic MSCs and High-Level MSCs.

Click

Click

Keyboard

Click(digit)

Retrieve(digit)

Call(number)

signal

signal not busy

Sent

number

Send Key

mobile_2base_1mobile_1 network base_2

msc call_set_up

up_call_requp_call_req

down_reqdown_req

up_call_respup_call_resp

call_ackcall_ack

down_respdown_resp

req req

ack nack

addr

val

CPU mem CPUMem

MSC 1 MSC 2

Concurrency modeling

Depicts concurrently executing processes (the vertical lines).

Processes communicate via a explicit message passing (instead of shared variables).

Realistic MSCs will also contain data attributes as part of the exchanged msg

Message Attributes

req

ack

Addr(a)

v := lookup(a)val(v)

CPU Mem

Internal Computations

req

ack

Addr(a)

v := lookup(a)val(v)

CPU Mem

Internal Action

Basic MSCs

A basic MSC describes exactly one scenario, which consists of a set of processes that run in parallel and exchange messages in a one to one, asynchronous fashion

MSC visual notation

P1 P3P2

M1

M2

M3

M4

M5

M6

MSC Textual form

msc MSC;

inst P1: process Root,

P2: process Root,

P3: process Root;

instance P1;

out M1 to P2;

in M5 from P2;

in M6 from P3;

endinstance;

instance P2;

in M1 from P1;

out M2 to P3;

out M3 to P3;

in M4 from P3;

out M5 to P1;

endinstance;

P1 P3P2M1

M2M3M4

M5M6

instance P3; in M2 from P2; in M3 from P2; out M4 to P2; out M6 to P1; endinstance;endmsc;

Visual order semantics

P1 P3P2M1

M2M3M4

M5M6

s s

s

s

s

r

r

r

r

r

r

s M1

M2

M3

M4

M5

M6

A bMSC is a tuple where P is a finite set of processes; E is a finite set of events corresponding to sending a message

and receiving a message. M is a finite set of messages. Each Message in M is of the form

where e, e’corresponds to sending and receiving the message respectively, and g is the message name which is a character string.

is a labeling function which maps each event eto a process L(e) V is a finite set whose elements are a pair (e,e’) where e, e’and

e precedes e’, which is corresponding to a visual order;

The semantics of a bMSC essentially consists of sequences (of traces) of messages that are sent and received among the concurrent processes in the bMSC.

The order of communication events (i.e.message sending or receiving) in a trace is deduced from the visual partial order determined by the flow of control within each process in the bMSC along with a causal dependency between the events of sending and receiving a message.

We use event sequences to represent the traces of bMSCs which are corresponding to the untimed behavior of bMSCs. Any event sequence is of the form …, which represents thattakes place after for any i ().

Let be a bMSC. An event sequence … is a trace of D if and only if the following conditions hold: All events in E occur in the sequence, and each

event occurs only once, i.e. {…}=E and for any i,j (); and

…satisfy the visual order defined by V, i.e. for any , if () .

Visual semantics

Sends before corresponding receives.

Events on the same process line execute in order of appearance, from top to bottom.

Visual order (wysiwyg)

If some event (send, receive) is higher on the line than another, it comes first.

Sends precede matching receives.

P1 P3P2M1

M2M3M4

M5M6

Visual order (wysiwyg)

P1 P3P2M1

M2M3M4

M5M6

s s

s

s

s

r

r

r

r

r

r

s M1

M2

M3

M4

M5

M6

Causal Order and Races

•Causality: Sends before matching receive.

•Controlability: Receive or sends before sends of same process.

•FIFO order: Two receives on the same process sent from the same process.

P1 P3P2M1

M2M3M4

M5M6

Races: check if every pair of events ordered by the visual order appears in the transitive closure of the causal order.

Races

P1 P3P2M1

M2M3M4

M5M6

P1 P3P2M1

M2M3M4

M5M6

P2P1 P3

M1M2

M3

M4M5

M6

M1

M2

M3

M4

M5

M6

P1 P2 P3Finding races:

Rules: order between

- receive and a later send.- two sends from same process.- send and corresponding receive.- fifo order.

Causal Order

P1 P3P2M1

M2M3M4

M5M6

s s

s

s

s

r

r

r

r

r

r

s M1

M2

M3

M4

M5

M6

Calculating the transitive closure

Structure (E, R). E – Events, R E E. R* The transitive closure. Defined as

follows:a R*b if there is a sequencex1 x2 … xn where a=x1, b=xn,and xi R xi+1 for 1i<n.

Combining MSCs

Models a single scenario and states its possible execution in the system implementation.

How could we use MSCs to model the behavior of a concurrent system ?

One attempt is to describe the system behavior as a graph of MSCs.

Each node of this graph is a MSC. We call such graphs as Message Sequence Graphs (MSG).

P1 P3P2 P1 P3P2

P1 P3P2P1 P3P2

connect approve

failreq_service

report

connect approve

fail

report Req_service

A

C D

B

Execution: ACACD

connect

connect

fail

fail

Req_service

report

report

MSG - Visually

req

ack

addr

val

nack

M1

M2M3

Choice and Concatenation

Choice of scenarios at a certain point in system execution modeled by several outgoing branches M1 M2 and M1 M3

Concatenation of MSCs (by following the edges in the MSG) produces infinite execution traces.

Client Server

More on concatenation

Synchronous concatenation All processes synchronize at the end of each MSC (a

node of the MSG) For any edge M1 M2

All events in M1 happen before all events in M2 Costly to implement since the natural control flow in a

process is disrupted by the termination of a MSC (requiring handshake with other processes).

Synchronous concatenation

s1

r1

s2r2

s1 < r1 < s2 < r2

An alternative concentation

Asynchronous concatenation If M1 M2 is an edge in the MSG, then concatenate M1

and M2 process by process If a process finishes its role in M1 ahead of others, it can

start executing M2 Amenable to efficient distributed implementation.

Asynchronous concatenation

s1

r1

s2r2

s1 < r1

s2 < r2

s1 < s2

Is r1 < s2 ??

Hierarchical MSC (HMSC)

Improves MSGs by incorporating hierarchy. A graph, each node of which is:

a Message Sequence Chart, or a HMSC

Clearly a MSG can appear as a node of HMSC. Different nodes in the graph can be labeled by the same

HMSC The HMSC is like a subprogram which is invoked in

various contexts.

HMSC example

Th1 CPU Th2

CPU-Mem MSG

data

Th1 CPUCPU-Mem MSG can be invoked in another context involving thread Th2.

MSG - Recap

req

ack

addr

val

nack

M1

M2M3

High-Level MSCsmsc call_blocking

initiate_call

call_refusedcall_set_up

terminate_call

call_proceeding

References can be to• basic MSCs or• high-level MSCs

• start point• end point• reference• branching• looping• parallel (not shown)• guards (not shown)

Single telecom. featuremay have >100 basic MSCsstructured through 3 levels

of high-level MSCs

Extended/Related Models

UML Sequence Diagram Live Sequence Chart Timed MSC

In-Line Expressions

In-line expressions: • alternative• parallel• optional• loop• exceptional

Operands:• non-deterministic choice• may be guarded• events interleaved with those outside expression

msc MyLife

mobile_1 mobile_2infra

req_refused

alt

call_req

t(5)

t

t

when idle

otherwise

call_ack

call_accept

Structuring event behaviour within an MSC

Time Constraints:• absolute (tracing)• relative

(specification)• single point, intervals• constrain regions

Time Constraints/Data

base managernetwork

set_up(time_out + 3)

terminateexpired(“z1”, _, x)

initiate

ready

msc call_expiration(time_out: time)

[5, 10]

@10:00

x := f(_, 5)

• Real-Time Constraints • Message Contents• Data Dependent Behaviour

Data:• static variables

- parameterises MSC- global to MSC- also instances, etc.

• dynamic variables- local to instance- assigned in actions- declared MSC Document

• underspecification- “don’t care” values

Instance Decomposition

base manager

initiate

ready

msc call

set_up

networkdecomposed as

network_call

base_handler manager_handler

initiate

msc network_call

set_up

ready

initiate_set_up

Splitting an Instance Into Constituent Processes

• Hierarchical view of processes

• Instance structure defined in enclosing MSC Document

• Internal messages hidden in upper view

Scenario-based Stories about the system

MSCs: (Message Sequence Charts)inter-object behavior(one story for all relevant objects)

LSC

may/must; can/always; fragmental and overlapping scenarios; anti-scenarios; etc.

But,… we need richer requirements

Live sequence charts (LSC’s)

“LSC’s: Breathing Life into Message Sequence

Charts” (Damm & Harel, ‘98 )

A natural extension of classical MSCs, with modalities (universal/existential, hot/cold, etc.) and structure (subcharts, conditionals, loops, etc.)

Basic form of an LSC

prechart (if)

main chart (then)

• Subcharts

• Loops

• Cold conditions enable control structures

• Hot conditions enable anti-scenarios:

MSG - Recap

req

ack

addr

val

nack

M1

M2M3

req

ack

addr

val

nack

M1

M2M3

Mem.busyMem.busy

MemCPU

MemCPUCPU Mem

A Universal chart

CPU Mem

nack

1. Mem.busy is the activation condition (AC)

2. If the AC holds, then this chart must be executed.

3. But the AC need not be true in every execution.

Mem.busy

Pre-charts

The trigger of a universal chart need simply be an activation condition.

Can be an activation message: when it is received the chart is required to be activated.

Can even be another full blown chart (a pre-chart). This chart can contain msg send/recv, conditions.

Once the pre-chart is executed, the universal chart is required to follow.

Example of Pre-chart

Mem.busy = true

reqCPU

Mem

nack

Pre-chart

Univ. chart

Concatenation

CPU Mem

Timed extension

Scenario-based specifications (SBSs) offer an intuitive and visual way of describing design requirements. Message sequence charts(MSCs) UML interaction models

For real-time systems, timing constraints are introduced into SBSs to describe timed behaviors.

SBSs

SBSs consist of UML sequence diagrams (SDs) and UML2.0 interaction overview diagrams (IODs).

We use the SD to describe exactly one scenario without alternatives and loops, and the IOD which combines references to SDs to describe sequential, iterating and non-deterministic executions of SDs.

Case Study

ATM

Motivation

Describing timing constraints related to the separation in time between two events. timers , interval delays, timing marks

To describe timing constraints which are about the relation among multiple separations in time between events.

Checking SBSs for timing consistency To check more properties

properties about the accumulated delays on the traces of systems

Timing Constraints

The timing constraints enforced on SDs describe the relations among multiple separations in time between events.

a ≤ c0(e0-e0’)+c1(e1-e1’)+…+cn(en-en’) ≤ b

separation separation separation

Timing Constraints

The timing constraints enforced on SDs describe the relations among multiple separations in time between events.

a ≤ c0(e0-e0’)+c1(e1-e1’)+…+cn(en-en’) ≤ b

The timing constraints enforced on IODs describe the timed relations between two events from different sequence diagrams.

a ≤ e-e’≤ b

Reachability analysis

To check if a given scenario of an SBS is reachable along a behavior of the SBS with regard to all the

timing constraints.

Constraint conformance analysis

To check if the given several scenarios, which occur consecutively in the behavior of an SBS, satisfy a given

timing constraint.

a ≤ c0(e0-e0’)+c1(e1-e1’)+…+cn(en-en’) ≤ b

Bounded delay analysis

To check if the separation in time between two given events, which may occur in different sequence diagrams, is not smaller or greater than a given real number in any behavior of an SBS.

Consistency Checking

Existency Checking

MSCs in the Lifecycle

SDL DesignSpecification and

Description Language

BoxTesting

System/IntegrationTesting

Code Generation

START

-

always takes too long

MEETING

PRESENT ARGUMENTS

COMPANY X OPINION

MOTOROLA OPINION

THROW OUT IDEA

COMPANY Y OPINION

AGREESUPERIOR ARGUMENT

COFFEE BREAK

where the real work is done

PROPOSE DECISION

MEETING AGREES

LUNCHwell deserved

MOTOROLAWITH

UK USA RMTR

air_intaxi_in

taxi_out

air_out

START

-

always takes too long

MEETING

PRESENT ARGUMENTS

COMPANY X OPINION

MOTOROLA OPINION

THROW OUT IDEA

COMPANY Y OPINION

AGREESUPERIOR ARGUMENT

COFFEE BREAK

where the real work is done

PROPOSE DECISION

MEETING AGREES

LUNCHwell deserved

MOTOROLAWITH

START

-

always takes too long

MEETING

PRESENT ARGUMENTS

COMPANY X OPINION

MOTOROLA OPINION

THROW OUT IDEA

COMPANY Y OPINION

AGREESUPERIOR ARGUMENT

COFFEE BREAK

where the real work is done

PROPOSE DECISION

MEETING AGREES

LUNCHwell deserved

MOTOROLAWITH

ITU, ETSI Standards

UK USA RMTR

air_intaxi_in

taxi_out

air_out

UK USA RMTR

air_intaxi_in

taxi_out

air_out

UK USA RMTR

air_intaxi_in

taxi_out

air_out

UK USA RMTR

air_intaxi_in

taxi_out

air_out

Code

TTCN

TTCN

Test Generation

Code Generation

Box Requirements

System Requirements

MSCs Used Formally Throughout Lifecycle

AutomationRequiresFormalLanguages

START

-

always takes too long

MEETING

PRESENT ARGUMENTS

COMPANY X OPINION

MOTOROLA OPINION

THROW OUT IDEA

COMPANY Y OPINION

AGREESUPERIOR ARGUMENT

COFFEE BREAK

where the real work is done

PROPOSE DECISION

MEETING AGREES

LUNCHwell deserved

MOTOROLAWITH

Test Generation

START

-

always takes too long

MEETING

PRESENT ARGUMENTS

COMPANY X OPINION

MOTOROLA OPINION

THROW OUT IDEA

COMPANY Y OPINION

AGREESUPERIOR ARGUMENT

COFFEE BREAK

where the real work is done

PROPOSE DECISION

MEETING AGREES

LUNCHwell deserved

MOTOROLAWITH

START

-

always takes too long

MEETING

PRESENT ARGUMENTS

COMPANY X OPINION

MOTOROLA OPINION

THROW OUT IDEA

COMPANY Y OPINION

AGREESUPERIOR ARGUMENT

COFFEE BREAK

where the real work is done

PROPOSE DECISION

MEETING AGREES

LUNCHwell deserved

MOTOROLAWITH

Verification & Validation:• feature interactions• race conditions• tracing

Tracing:• model validation• application code validation• test validation

Design Verification:• model checking• SDL upholds MSCs

Test Generation:• conformance testing• test purposes (one-2- many)• test specification (one-2-one)

MSC Uses

UK USA RMTR

air_intaxi_in

taxi_out

air_out

UK USA RMTR

air_intaxi_in

taxi_out

air_out

SDL Tracing

UK USA RMTR

air_intaxi_in

taxi_out

air_out

UK USA RMTR

air_intaxi_in

taxi_out

air_out

START

-

always takes too long

MEETING

PRESENT ARGUMENTS

COMPANY X OPINION

MOTOROLA OPINION

THROW OUT IDEA

COMPANY Y OPINION

AGREESUPERIOR ARGUMENT

COFFEE BREAK

where the real work is done

PROPOSE DECISION

MEETING AGREES

LUNCHwell deserved

MOTOROLAWITH

Requirements V&V

TTCN Generation

SDL Verification

Formality Enables Useful Tool Support

Summary

MSC is a rich language• suitable for requirements specification• many uses across lifecycle• ‘engineer friendly’ language• used in telecom standards

Good tool support• getting more sophisticated• industrial use• integrated with SDL, TTCN tools

Standardisation Continues• interesting problems to work on• good forum for insight, new ideas• learn latest methods/technology