Message Sequence Chart
Lei Bu
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.
Keyboard
Send Key
Click
Click(digit)
Click
Sent
Retrieve(digit)
number
Call(number)
signal
signal not busy
msc call_set_up
mobile_1
base_1
up_call_req
network
up_call_req
base_2
down_req
call_ack
call_ack
down_resp
down_resp
up_call_resp
mobile_2
down_req
up_call_resp
CPU
mem
req
ack
CPU
Mem
req
nack
addr
val
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
Internal Action
ack
Addr(a)
val(v)
CPU
v := lookup(a)
Mem
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
P2
P3
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;
instance P3;
in M2 from P2;
in M3 from P2;
out M4 to P2;
out M6 to P1;
endinstance;
endmsc;
P1
M1
M5
P2
P3
M2
M3
M4
M6
Visual order semantics
s M1
r
s
M2
r
M3
r
r
P2
M1
s
M4 s
r
M5 s
r M6
P1
s
M5
P3
M2
M3
M4
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
e∈ 𝐸 to 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
𝑒0 ^𝑒1 …^𝑒𝑚 , which represents that 𝑒𝑖+1 takes place
after 𝑒𝑖 for any i (0 ≤ 𝑖 ≤ 𝑚 − 1).
Let 𝐷 =< 𝑃, 𝐸, 𝑀, 𝐿, 𝑉 > be a bMSC. An event
sequence 𝑒0 ^𝑒1 …^𝑒𝑚 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. {𝑒0 , 𝑒1 ,…, 𝑒𝑚 }=E and
𝑒𝑖 ≠ 𝑒𝑗 for any i,j (0 ≤ 𝑖 < 𝑗 ≤ 𝑚); and

𝑒1 , 𝑒2 ,…, 𝑒𝑚 satisfy the visual order defined by V,
i.e. for any 𝑒𝑖 and 𝑒𝑗 , if (𝑒𝑖 , 𝑒𝑗 )∈ 𝑉, then 0 ≤ 𝑖 <
𝑗 ≤ 𝑚.
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
P2
M1
M5
P3
M2
M3
M4
M6
Visual order (wysiwyg)
s M1
r
s
M2
r
M3
r
P1
r
M1
s
M4 s
r
M5 s
r M6
P2
s
M5
P3
M2
M3
M4
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
M1
M5
P2
P3
M2
M3
M4
M6
Races: check if every pair of events ordered by the visual order
appears in the transitive closure of the causal order.
Races
P1
M1
M5
P2
P3
M2
M3
M4
P1
P2
M1
M6
M5
P3
M2
M3
M4
M6
Finding races:
P1
P1
P2
P3
P2
P3
M1
M1
M2
M2
M3
M3
M4
M5
M4
M6
Rules: order between
- receive and a later send.
- two sends from same process.
- send and corresponding receive.
- fifo order.
M5
M6
Causal Order
s M1
r
s
M2
r
M3
r
r
r
M6
s
M1
s
M4 s
r
M5
P1
s
M5
P2
P3
M2
M3
M4
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 sequence
x1 x2 … xn where a=x1, b=xn,
and xi R xi+1 for 1i<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
P2
P3
P2
P3
P2
P3
approve
connect
P1
P1
P2
P3
fail
report
P1
req_service
A
B
Execution: ACACD
approve
connect
connect
fail
report
connect
fail
Req_service
report
fail
report
Req_service
C
D
MSG - Visually
req
M1
M3
M2
ack
addr
val
nack
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
r1
s1
s1 < r1 < s2 < r2
r2
s2
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
r1
s1
s1 < r1
s2 < r2
s1 < s2
Is r1 < s2 ??
r2
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
CPU-Mem MSG can be invoked in
another context involving thread Th2.
Th1
CPU
data
MSG - Recap
req
M1
M3
M2
ack
addr
val
nack
High-Level MSCs
msc call_blocking
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. feature
may have >100 basic MSCs
structured through 3 levels
of high-level MSCs
initiate_call
call_set_up
call_proceeding
terminate_call
call_refused
Extended/Related Models



UML Sequence Diagram
Live Sequence Chart
Timed MSC
In-Line Expressions
Structuring event behaviour within an MSC
msc MyLife
In-line expressions:
• alternative
• parallel
• optional
• loop
• exceptional
Operands:
• non-deterministic choice
• may be guarded
• events interleaved with
those outside expression
infra
call_req
mobile_1
t(5)
alt
when idle
call_ack
t
call_accept
otherwise
t
req_refused
mobile_2
Time Constraints/Data
• Real-Time Constraints • Message Contents
• Data Dependent Behaviour
Time Constraints:
• absolute (tracing)
• relative (specification)
• single point, intervals
• constrain regions
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
msc call_expiration(time_out: time)
base
network
manager
initiate
ready
@10:00
x := f(_, 5)
set_up(time_out + 3)
expired
(“z1”, _, x)
terminate
[5, 10]
Instance Decomposition
Splitting an Instance Into Constituent Processes
msc call
base
network
decomposed as
network_call
manager
initiate
ready
set_up
• Hierarchical view of processes
• Instance structure defined
in enclosing MSC Document
• Internal messages hidden in
upper view
msc network_call
base_handler
manager_handler
ready
initiate
initiate_set_up
set_up
LSC
Scenario-based
Stories about the system
MSCs:
(Message Sequence Charts)
inter-object behavior
(one story for all relevant
objects)
But,… we need richer
requirements
may/must;
can/always;
fragmental and
overlapping
scenarios;
anti-scenarios; etc.
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
M1
M3
M2
ack
addr
val
nack
M1
req
Mem.busy
Mem.busy
CPU
Mem
M3
M2
ack
nack
addr
val
CPU
Mem
CPU
Mem
A Universal chart
Mem.busy
1. Mem.busy is the activation condition
(AC)
2. If the AC holds, then this chart must be
executed.
nack
3. But the AC need not be true in every
execution.
CPU
Mem
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
CP
U
req
Mem
Mem.busy =
true
Pre-chart
Concatenation
CPU
Mem
nack
Univ. chart
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
UK
USA
RMTR
air_in
taxi_in
taxi_out
MSCs Used Formally Throughout Lifecycle
air_out
System/Integration
Testing
ITU, ETSI Standards
UK
USA
RMTR
UK
air_in
USA
RMTR
air_in
taxi_in
taxi_in
taxi_out
Test Generation
air_out
START
MEETING
always takes
too long
PRESENT
ARGUMENTS
taxi_out
COMPANY X
OPINION
air_out
COMPANY Y
OPINION
MOTOROLA OPINION
AGREE
WITH
MOTOROLA
SUPERIOR
ARGUMENT
THROW OUT
IDEA
where the real
work is done
COFFEE
BREAK
-
PROPOSE
DECISION
MEETING
AGREES
well
deserved
LUNCH
System Requirements
Automation
Requires
Formal
Languages
TTCN
UK
RMTR
taxi_in
always takes
too long
PRESENT
ARGUMENTS
UK
USA
air_in
START
MEETING
USA RMTR
COMPANY X
OPINION
air_in
THROW OUT
IDEA
START
MEETING
COMPANY Y
OPINION
MOTOROLA OPINION
taxi_in
AGREE
WITH
MOTOROLA
SUPERIOR
ARGUMENT
COFFEE
BREAK
-
where the real
work is done
taxi_out
PROPOSE
DECISION
air_out
Test Generation
always takes
too long
PRESENT
ARGUMENTS
COMPANY X
OPINION
COMPANY Y
OPINION
MOTOROLA OPINION
THROW OUT
IDEA
MEETING
AGREES
LUNCH
taxi_out
air_out
-
well
deserved
AGREE
WITH
MOTOROLA
SUPERIOR
ARGUMENT
COFFEE
BREAK
where the real
work is done
Box
Testing
PROPOSE
DECISION
MEETING
AGREES
LUNCH
Box Requirements
well
deserved
TTCN
Code Generation
START
MEETING
always takes
too long
PRESENT
ARGUMENTS
COMPANY X
OPINION
SDL Design
Specification and
Description Language
COMPANY Y
OPINION
MOTOROLA OPINION
THROW OUT
IDEA
-
AGREE
WITH
MOTOROLA
SUPERIOR
ARGUMENT
COFFEE
BREAK
where the real
work is done
PROPOSE
DECISION
MEETING
AGREES
LUNCH
well
deserved
Code Generation
Code
MSC Uses
Formality Enables Useful Tool Support
UK
USA
RMTR
air_in
taxi_in
Requirements V&V
taxi_out
air_out
UK
START
MEETING
COMPANY X
OPINION
COMPANY Y
OPINION
AGREE
WITH
MOTOROLA
SUPERIOR
ARGUMENT
COFFEE
BREAK
-
RMTR
taxi_in
MOTOROLA OPINION
THROW OUT
IDEA
USA
air_in
always takes
too long
PRESENT
ARGUMENTS
where the real
work is done
SDL Tracing
taxi_out
air_out
PROPOSE
DECISION
MEETING
AGREES
well
deserved
LUNCH
UK
USA
RMTR
START
MEETING
air_in
always takes
too long
PRESENT
ARGUMENTS
taxi_in
taxi_out
air_out
COMPANY X
OPINION
SDL Verification
COMPANY Y
OPINION
MOTOROLA OPINION
AGREE
WITH
MOTOROLA
SUPERIOR
ARGUMENT
THROW OUT
IDEA
where the real
work is done
COFFEE
BREAK
-
PROPOSE
DECISION
MEETING
AGREES
USA
RMTR
START
MEETING
air_in
taxi_out
air_out
always takes
too long
PRESENT
ARGUMENTS
taxi_in
COMPANY X
OPINION
TTCN Generation
COMPANY Y
OPINION
MOTOROLA OPINION
THROW OUT
IDEA
-
AGREE
WITH
MOTOROLA
SUPERIOR
ARGUMENT
COFFEE
BREAK
where the real
work is done
PROPOSE
DECISION
MEETING
AGREES
LUNCH
Tracing:
• model validation
• application code validation
• test validation
Design Verification:
• model checking
• SDL upholds MSCs
well
deserved
LUNCH
UK
Verification & Validation:
• feature interactions
• race conditions
• tracing
well
deserved
Test Generation:
• conformance testing
• test purposes (one-2- many)
• test specification (one-2-one)
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