Internal Talk, Oct 1 2002 Executable Specifications using Message Sequence Charts Abhik Roychoudhury School of Computing National University of Singapore.

Internal Talk, Oct 1 2002

Executable Specifications using Message Sequence Charts

Abhik RoychoudhurySchool of ComputingNational University of

Singapore


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.


MSC - Visually

req req

ack nack

addr

val

CPU mem CPU Mem

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


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.


MSC -formally P : set of processes M: set of messages A : set of internal actions E : set of events. Mapped to

<p ? q , m> P P M <p ! q, m> P P M <p, a> P A

<, a partial order on events. We will consider the “Visual Order” for these

purposes …


MSC order Intuitively, a “happens-before” relation

between events. e < e’ if the MSC requires e to happen before

e’ If e, e’ occur in the same process and e occurs above

e’ then e < e’ If e, e’ are the send and receive of the same

message then e < e’ These orderings constitute the visual order.

Think of our partial order as the transitive closure of the visual order.


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


MSG - Visually

req

ack

addr

val

nack

M1

M2 M3


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

s1r1

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

s1r1

s2r2

s1 < r1

s2 < r2

s1 < s2

Is r1 < s2 ??


Unboundedness of queues

p q

Message queue of q can grow unboundedly.

Model Checking will be applicable to only “Bounded MSGs”.


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 CPU

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


MSG - Recap

req

ack

addr

val

nack

M1

M2 M3


Need for Universal Charts

req

ack

addr

val

nack

M1

M2M3

Mem.busyMem.busy MemCPU

Mem

CPUCPU 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


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 I+1 …. 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.


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


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.


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 …


Distributed Activation Cond.

p q r

Reset(r.b)m1

m2

AC(M) = p.a r.b

r can start even when p has not started.

…


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 ?


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 !


Checking for inconsistencies

m1

m1Pre-chart

The two universal charts are inconsistent.

a

b

b

a


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/termination of pre-charts) local to a process ?


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.


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.


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.

Internal Talk, Oct 1 2002 Executable Specifications using Message Sequence Charts Abhik Roychoudhury School of Computing National University of Singapore.

Documents

lookupavalvcpumeminternal

clientserverinternal

e eif e

exchanged msginternal

system execution

internal actionse

msc formallyp

message queues