Executable Specifications using Message Sequence Charts

1
Executable Specifications using Message Sequence
Charts

• Abhik Roychoudhury
• School of Computing
• National University of Singapore

2
MSCs What

• Depict scenarios in system exection.
• Used to specify requirements in early stages of
  system design.
• A MSC depicts only a possible scenario of system
  behavior.

3
MSC - Visually
Mem
CPU
mem
CPU
req
req
ack
nack
addr
val
MSC 2
MSC 1
4
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

5
Message Attributes
req
ack
Addr(a)
v lookup(a)
val(v)
CPU
Mem
6
Internal Computations
req
Internal Action
ack
Addr(a)
v lookup(a)
val(v)
CPU
Mem
7
MSC (Very) Basics

• Time flows from top to bottom in each process.
• Message exchange shown by horizontal lines.
• Each process in the MSC is assumed to contain
  message queues to store incoming messages.
• The message queues contribute to the global state
  of the system.
• If the data in messages come from a finite
  domain, then we identify a finite set of messages
  exchanged, called M.

8
MSC -formally

• P set of processes
• M set of messages
• A set of internal actions
• E set of events. Mapped to
• ? P ? P ? M
• ? P ? P ? M
• ? P ? A
• We will consider the Visual Order for these
  purposes

9
MSC order

• Intuitively, a happens-before relation between
  events.
• e
• If e, e occur in the same process and e occurs
  above e then e
• If e, e are the send and receive of the same
  message then e
• These orderings constitute the visual order.
• Think of our partial order as the transitive
  closure of the visual order.

10
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).

11
MSG - Visually
req
M1
M3
M2
ack
nack
addr
val
12
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
13
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).

14
Synchronous concatenation
r1
s1
s1 r2
s2
15
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.

16
Asynchronous concatenation
r1
s1
s1 r2
s2
17
Unboundedness of queues
q
p
Message queue of q can grow unboundedly. Model
Checking will be applicable to only Bounded
MSGs.
18
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.

19
HMSC example
Th1
CPU
Th2
CPU-Mem MSG
Th1
CPU-Mem MSG can be invoked in another context
involving thread Th2.
CPU
data
20
MSG - Recap
req
M1
M3
M2
ack
nack
addr
val
21
Need for Universal Charts
M1
req
Mem.busy
?Mem.busy
Mem
CPU
M3
M2
ack
nack
addr
val
CPU
Mem
Mem
CPU
22
A Universal chart
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
nack
Mem
CPU
23
Semantics of universal charts

• A chart only constrains events and variables
  appearing in the chart.
• A system execution trace ? s0 ?s1? satisfies
  a universal chart M iff
• ? positions I s I l AC(M) ? ? I M, that
  is
• ? I s I s I1 . contains a linearization of
  the events in M
• Events not in M may appear in ? I
• A system satisfies a universal chart M if all its
  execution traces satisfy M.

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

25
Example of Pre-chart
Mem
req
CPU
Mem.busy true
Pre-chart
Concatenation
CPU
Mem
Univ. chart
nack
26
What kind of Concatenation ?

• Live Sequence Charts (LSC) Damm and Harel
• Synchronous concatenation
• The pre-chart/activation condition must be
  completely executed before the universal chart
  can initiate.
• Still allows for several active copies of
  pre(M).M e.g. pre(M) may be activated while M is
  still executing.

27
What kind of Concatenation ?

• Cyclic Transaction Processes (CTP)
• Universal charts triggered by activation
  conditions.
• Activation condition may involve variables of
  diff. processes.
• A process can initiate its role in the chart once
  the condition on its variables is evaluated to
  true.
• Other important differences with LSC formalism

28
Distributed Activation Cond.
m1
Reset(r.b)
m2

p
q
r
AC(M) p.a ? r.b r can start even when p has
not started.
29
Requirements or Exec. spec ?

• A universal chart denotes a safety property that
  the actual system must satisfy.
• Can be seen as a requirement with must flavor.
• Possible to enforce it on system executions by
  monitoring for the occurrence of its pre-chart.
• LSC spec. used for monitoring/testing/simulating
  an executable model early in the design cycle.
• How do we obtain a high-level executable
  specification directly based on MSCs ?

30
LSC-like executable specifications

• A collection of universal charts M1, , Mk
• Each chart has activation condition AC( Mi )
• Mi becomes active when AC(Mi) becomes true.
• Several charts may be active simultaneously.
• At any point in execution, no event occurs unless
  it is required to occur by the .
• Can use this executable model to check for
  inconsistencies in the LSC spec. itself !

31
Checking for inconsistencies
Pre-chart
m1
m1
a
b
b
a
The two universal charts are inconsistent.
32
Control flow in LSC

• Intra-process control flow is completely implicit
  in an LSC based executable specification.
• Raises efficiency issues in implementation,
  since
• Processes need to handshake at the end of a
  pre-chart.
• Need a global watchdog which always monitors for
  pre-charts of any Univ. chart being initiated.
• Can we make these decisions (initiation/terminatio
  n of pre-charts) local to a process ?

33
Adding Per-process Control flow

• Describe the control flow in each process by
  giving the sequence of univ. charts it
  participates in
• Can start with a simple cyclic control flow (CTP)
• A process initiates a chart when its activation
  condition is true.
• A process leaves a chart when its role is
  finished.
• A transition in local control state sp ? sp
  in process p takes place by executing a universal
  chart.

34
Transaction scheme

• A transition sp ? sp in process p involves a
  non-trivial interaction of p with other processes
  q,r
• Depending on the local variable values in p,q,r
  the interaction may be different.
• Captured by a choice of universal charts
• Gp ? Gq ? Univ. Chart 1
• Gp ? Gq ? Univ. Chart 2
• This choice is not non-deterministic. Resolved at
  run-time by either of the guards being true.

35
References

• LSCs Breathing Life into Message Sequence Charts
  Damm and Harel, Formal Methods in System Design,
  Vol. 19, pages 45-80, 2001.
• Model Checking of Message Sequence Charts Alur
  and Yannakakis, Proceedings of CONCUR, 1999.
• Communicating Transaction Processes, Roychoudhury
  and Thiagarajan, International Conf. on
  Applications of Concurrency in System Design
  (ACSD) 2003.