From Requirement to Prototyped Systems - CiteSeerX

MSC+: From Requirement to Prototyped Systems Mesfin Belachew and R.K. Shyamasundar Abstract— Message Sequence Charts (MSCs) have gained wide acceptance for scenario-based specification of component behaviors. MSCs are very useful during requirements capture phase of the software development process and reveal errors in requirement specifications when used in early stages. As MSCs have found widespread usage, there have been several extensions to overcome its’ shortcomings for a spectrum of applications keeping the rationale of MSCs invariant. In this paper, we propose a) An extension of hierarchical MSCs (hMSC for short), called MSC+ , keeping in view the need of complex reactive system specifications; it has new additional features such as watching (preemptive) construct, generalized coregions, and includes features for the specifications of live and forbidden scenarios. b) A formal translation of MSC + to the synchronous language E S TEREL is also provided. This feature enables validating requirement specifications and also to obtain a prototype for synchronous MSC+ specifications. Apart from obtaining a prototype, the translation of MSC+ to E S TEREL (that has clean and mathematical semantics) provides a clear semantic definition for the synchronous MSC + specifications. In the paper, we shall describe, the design and implementation of MSC+ followed by the translation of MSC+ to E STEREL leading to prototyping of systems. Examples will be used to highlight characteristic features of the language, system and applications. Keywords—MSCs, hMSCs, Requirement Specification, Preemption

I. INTRODUCTION MSCs can be viewed as a graphical language for traces emphasizing the exchange of messages among the service processes, user and the environment. It has both a graphical and a textual representation. The language is best known by its graphical representation. The main advantage of MSC is its clear graphical layout that immediately provides an intuitive understanding of the system behavior. MSCs are very useful in the early development of a system and are widely used in industry for requirement specification, overview specification of process communication, interface specification, design method for object interaction, etc. MSCs offer several advantages for the requirements and design modeling of reactive systems. One is the intuitive, graphical notation of MSCs, which helps a designer to visualize the system’s structure and interfaces. The other is the level of abstraction they offer by merely describing the message flow, which is the core of reactive systems and abstracting out process behavior. As a requirement language, MSCs offer the distinction between the system and its environment, between the action of the system and environment, and describe the flow of actions in the system. Reactive systems often consist of nonterminating and nondeterministic processes. To cater to specifications of such systems, recommendation Z.120 [10] suggests the use of hMSC to compose basic Message Sequence Charts (bMSC) to specify systems with recursive and nondeterministic behavior. R.K. Shyamasundar is with the Faculty of Technology and Computer Science, Tata Institute of Fundamental Research, Homi Bhabha Road, Mumbai 400 005, India, email: [email protected] Mesfin B. is with the Department of Computer Science, University of Mumbai, Kalina Campus, Mumbai 400 098, India, email: [email protected]

As the language has found widespread usage among engineers, and found to be extremely useful in capturing/validating reactive behavior of systems, several additional features have been introduced recently in [8]. Some of the unaddressed issues with respect to MSCs (cf. [8]) are: what aspects of the behavior are best captured by MSCs, what classes of scenarios can be captured (like forbidden, live scenarios etc), is it possible to transform or arrive at a system definition through the specification of scenarios etc. In this paper, to overcome some of the above limitations of MSCs, we have designed MSC+ , as a generalization of hMSCs, having the capability to specify preemptive features such as watchdogs, generalized coregions and scenarios. The language has been designed and a prototype implementation is under test. The main contributions of the paper are: i. A generalization of hMSC called MSC+ that has a. preemptive features, b. generalized coregions, and c. features for specifying scenarios. ii. Translation of MSC+ into E STEREL. This translation provides an executable system specification from requirement specification – thus establishing the existence of a model and a prototype. The prototype can be simulated/validated/verified against the specifications using the programming environment of E S TEREL. Rest of the paper is organized as follows: in section II, we introduce bMSCs and hMSCs. Our generalization of hMSCs called MSC+ is described in section III, highlighting the need and advantages of new features such as preemption, generalized coregions, and the discussion on syntactical representation and compositional operators of MSC+ ; a simple example of a microwave oven in MSC+ is illustrated. In section IV we discuss the semantics of MSC+ . An illustration of the specification of a lift system and an ATM using MSC+ is given in section V. In section VI, we discuss a translation of MSC+ into E STEREL followed by an overview of the programming environment being developed for MSC+ in section VII. The paper concludes with a discussion of the approach in section VIII. II. MSC: A N I NTRODUCTION Message Sequence Charts show the sequence of messages between objects. MSC can be expressed in graphical or textual form. The textual and the graphical languages are identical with respect to each other. However, the textual representation is instance oriented, whereas the graphical representation is event oriented. The graphical representation for timed MSC is shown in Figure 1. The vertical lines represent objects, with the name of the object written above or inside the box. The horizontal directed lines are messages. Each message line starts at the originator object and ends at the target object and has a message name on the line. This name might, in later phases, specify an operation



bmsc: TimedMsc Instance1 a

Instance2

Message1

b T1(3)

[1, 2] c

Message2

Instance3

d

[1, 2]

Message3

e

f T2(4)

[2, 3]

Splitting of an arrow denotes that the successors are alternatives.  A cycle connecting a number of hMSC references expresses a repetition. In this case, infinitary behavior can be described. Connectors (indicated by a circle) are also used for combining incoming and outgoing edges.

Action Message4

h j

Message5

[1, 3]

bmsc: M3 g

i

I

[1, 3]

J m

(b)

Fig. 1. Message Sequence Chart

with a parameter list and a return value. Time flows from top to bottom in the chart. The message has an optional identifier to the left or right of it (in the Figure we have used “a”-“j”). These are event identifiers, and are used when it is necessary to reference the event giving rise to the message. Additionally, they can be included in timing mark expressions to indicate relative time between events. A local action is indicated by a box at an instance as shown in “Instance2” by a box labeled ‘Action’. For further details readers are referred to [1], [3].

bmsc: M4

bmsc: M3

I

J

F

C

n

T bmsc: M4

(c)

bmsc: M5

bmsc: M5 J

I (a)

o

A. Syntactic Representation of MSC+ As compared to the graphical syntax, the textual syntax has its own advantages in denoting hierarchies, translations, prototypes, checking for consistency etc. Table III given in the appendix describes the textual syntax of MSC+ . We have used textual syntax in our translation process. A valid or a sound bMSC satisfies the following restrictions:  a message is sent before it is consumed (received)  there is no explicit order specified on message transitions from different instances and  there is no clash in the use of names (identifiers) The textual structures for the new features are explained in the respective sections. B. High-level Message Sequence Charts (hMSC) A hMSC [19] is a graphical overview of the relation among the MSCs contained in the system. It helps in keeping track of the control-flow. In a hMSC operators for alternative, sequential and parallel composition as well as recursion are captured in a graphical layout. A compound hMSC consists of a collection of components enclosed by a frame. The components are thought of as a complex MSC that operate concurrently. Every component consists of a number of nodes and the arrows imply an order on the nodes. The basic graphical representation as adapted in MSC+ is depicted in Figure 2. The main features of the graphical syntax are summarized in the following:  An hMSC references (a component) consists of a frame with rounded corners enclosing the name of the referenced hMSC.  Every component has exactly one start node, indicated by an upside-down triangle (5). Further, it may contain a number of end nodes depicted by a triangle (4) and several hMSC references.  Every node including the end-nodes within a component is reachable from the start node.  An arrow between two hMSC references implies that they are composed vertically (explained below).

(d)

Fig. 2. Basic Graphical Syntax of hMSC

The various compositional operators of hMSC are described below: a. Sequencing: Whenever two bMSCs are sequenced or concatenated, it is interpreted to be vertically composed (see Figure 3) – i.e., the bMSCs are placed one below the other such that the instance names of the two match; this keeps the time flow consistently. We have two variants of sequence operators: 1. Strong sequencing M1 and M2 is interpreted to mean that transfer to M2 is possible only after the termination of all events in M1; in hMSC the sequencing of blocks denotes such an operation. 2. Weak sequencing M1 and M2 denotes the parallel execution of M1 and M2 with the restriction that an action from M2 can be executed only if that is permitted by M1 as per the consistency requirements for the MSCs; such an operation is not used in MSC+ . b. Selection: The selection operator is shown in Figure 2(a). In this figure, the branch bMSC:M4 will be taken if the condition denoted by ‘C’ is true and branch bMSC:M5 will be taken otherwise. Note that the feature introduces the notion of variables into MSCs and is useful in representing scenarios. The vertical composition of the three bMSCs in Figure 2(b,c,d), is shown in Figure 3. Figure 3 depicts another explicit notation for the conditional where the two bMSCs (M4 and M5) are separated by a dashed horizontal line (cf. [14]) with the condition values shown explicitly for each arm. c. Loops: A “Loop” is used to represent the possible execution of a MSC an arbitrary number of times with the possibility of termination with the end of the stimulus. Loop body strictly follows the underlying sequence operation. Figure 9 illustrates the graphical representation of loops in a hMSC. In the textual representation, reserved words loop and endloop are used at the beginning and end of the events respectively to enclose the events

to be executed into the loop (for syntax see Table III). msc: M I

J

m alt C (TRUE) n

For purposes of denoting scenarios, conditions are classified as either provisional (cold) or mandatory (hot) type apart from normal types such as local, non-global or global. The words condition, cold, hot, shared, endcold, and all, are reserved keywords (for syntax see Table III). The conditions can be local, or shared among certain listed instances or shared among all instances of the MSC. It must however, be noted that since the “hot condition” is mandatory it must happen or else the system aborts.

C (FALSE) l

B. Need of Preemption in Specifying Scenarios Fig. 3. Vertical Composition in hMSC

III.

MSC+ : A GENERALIZED HMSC WITH PREEMPTION

In this section, we shall describe the structure of MSC+ and the rationale for the features chosen. MSC+ is based on hMSC and has reactive features such as generalized coregion, watchdogs and forbidden scenario constructs. It supports a hierarchical development and broadly consists of the following structures: i. bMSCs: These are the basic components from which a complex specification is built. ii. Composition operators for bMSCs: These operators enable a hierarchical (layered) specification of the system succinctly. The operators include preemptive operators, generalized operator for coregions, and operators for specifying scenarios. The main generalized concepts introduced/adapted in MSC+ are: – Introduction of watchdogs: Watchdog constructs have been used widely in the specification of reactive systems. We shall graft a notion of watchdog into MSC which will became clear in the sequel. Such a construct provides a good succinct description avoiding visual complexity. – Generalization of coregion: We extend the notion of coregion to specify parallelism among groups of actions rather than singleton actions. Such an extension provides a flexibility in the natural specification of reactive systems. – Specifying Scenarios: We have adapted the classical hot and cold condition described in the sequel Before discussing further technical details, we shall discuss the rationale for the inclusion of the above features. A. Need of Scenarios Specifying live scenarios and forbidden scenarios has been found to be very useful in the specification of complex systems (particularly reactive systems) [8]. The use of conditions leads to the specification of forbidden scenarios and some of the live scenarios. Two kinds of conditions (i) hot (mandatory), and (ii) cold (provisional) condition have been proposed in [8]. The hot condition if selected must follow through the mandatory selections and thus, depicts forbidden scenarios after selecting a hot condition. The authors show that the use of these conditions makes MSC more expressive and have illustrated its usefulness and viability in [8] using the example of a rail-car system. Seeing the power of these features, we have integrated these features in MSC+ .

Specifying, the control on the life and death of processes is very crucial in the specification of reactive behaviour. The notion of preemption is the basic operation used in synchronous languages for capturing such concepts. The orthogonality of preemption and concurrency in the context of reactive systems has been nicely argued by Gerard Berry [7] . We believe that a nice representation of an operator of preemption at a graphical level will make it possible to represent scenarios (allowed and forbidden) succinctly and will add to the power of MSCs in denoting the scenarios of systems. bmsc: Normal J

I

msc: Composed I

m

bmsc: Normal

J m

(b) watch: K

watch: K(I, J)

watch: K(I, J) I

J

n l

n

(a)

l

(d) (c)

Fig. 4. Watchdog in MSC

A watchdog in MSC+ is represented graphically by a dotted frame in hMSC as shown in the Figure 4(a). In the corresponding bMSC of the watchdog, a label indicating the name of the preemption message with its source and destination is shown (Figure 4(c)). Here it is indicated by ‘K(I, J)’ with a key word prefix ‘watch’ indicating a preemptive message ‘K’ from instance ‘I’ to ‘J’. The message to be watched has a provisional behavior (cold in temperature) as above. The watchdog-message can (not must) be sent at any time in the watchdog area. If the watchdog-message is sent, it must be received by the target instance (this is a must). The area where the watchdog-message is in action is shown in a separate bMSC (or MSC+ ) with a dotted frame that forms the boundary of the chart (see in Figure 4, 9 and 11). In the dotted frame, the watching event is active up to the end of the dotted frame.The concrete textual syntax is given in Table III. In the semantic interpretation of MSC+ , watching an event w on instance i is expressed by watched(i,w). The scope of the signal watched extends from this point to the lexical point indicated by the statement endwatched(w).

bmsc: Start

C. Need of Generalized Coregion

USER

The traditional coregion is used in MSC (cf. [9], [10], [12], [13]) to relax the strict ordering of events along the axis of an instance and introduce some limited notion of concurrency. Graphically, coregion is represented in a MSC with vertical dotted line covering the events to be executed simultaneously as shown in Figure 5(i). In other words, semantically it corresponds to in(env, J, a) jj out (J, env, c) jj out (J, env, b) where env is environment. In this notation, each arm of the parallel branch can have at most one statement or event and hence, it is not possible to depict the possible sequencing (or essential a statement list). In MSC+ , we have generalized the notation to specify the possibility of sequence of statements on each arm of the parallel branch in the following ways: Figure 5(iii), for example, shows a coregion representation where M and N are basic MSCs containing sequential events. This type of scenario is called generalized coregion. In generalized coregion, the relaxation of strict ordering of messages is limited. In Figure 5(ii) we have the combination of sequential events (a,b) and parallel events c and d. Both group events are executed in parallel. That is, Figure 5(ii) denotes (a,b)jjcjjd. bmsc: J

bmsc: I

J

I a

c

a

c

b

b

bmsc M bmsc N

d

bmsc: Start

OVEN

START

T(MINUTE)

watch: StopOrMinute

bmsc: TimeOut

bmsc: Stoped bmsc: TimeOut

USER

OVEN T(MINUTE)

bmsc: HeatLightOff BEEP

Fig. 6. Simple Microwave Oven



Synchronous: In the synchronous interpretation the message transmission is considered to be instantaneous and the concatenation of bMSCs M1 and M2 correspond to saying that the events in M2 happen after all the events in M1. The synchronous interpretation closely corresponds to the synchronous programming models which have found widespread use in the specification of reactive systems. Keeping this in view, we have chosen synchronous semantics for MSC+ . The semantics follows the synchronous style of E STERELand uses E STEREL-like rewrite notation which is briefed below. 0 E ;b A rewrite rule of the form X ! X 0 , denotes the translation E

(i)

(ii)

(iii)

Fig. 5. Graphical Representation of Generalized Coregion

The textual syntax follows through the use of parenthesis. Note that, the general parallel compositions S1 k S2 , where S1 ; S2 themselves may be hMSC references, can also represented in this way. D. A Simple Example To illustrate the features discussed above, we shall use the example of a simple Microwave Oven [11]. For lack of space, we shall consider a part of the microwave oven which is relevant to this section. The microwave oven is used for heating food for specific time duration. The oven does nothing until a START signal is received (e.g., pressing a start button on a panel); it turns on HEAT for the duration set on the timer until the expiration of the timer or the door is opened, or the STOP button is pressed. If the time duration expires, a BEEP sound is emitted and emission of HEAT is switched off. In Figure 6 the timer “T” with duration of “MINUTE“ is shown. The timer will be initialized when the microwave oven starts. The watchdog in Figure 6 will watch the signals STOP, DOOR-OPEN or the expiry of the timer to stop the microwave oven. IV. SEMANTICS OF

MSC+

As highlighted already MSC+ can be treated as a graph obtained by a finite application of the compositional operators on bMSCs. Naturally, we can have various interpretations such as  Asynchronous: In this interpretation, the concatenation corresponds to concatenating the underlying processes and the message transmission also takes time.

 of term X in to X’ where E is the environment of signals, E’ the set of output signals emitted and b is a boolean to denote termination/nontermination of the translation in the current instant; b=1, denotes that the term on the left hand side does not terminate in the current instant; b=0 denotes that the term on the left hand side terminates in the current instant. The rule for our constructs are shown in Table I. We treat TIMERs as external signals from clocks. The hard real time aspects are not treated in this paper for lack of space. This can be treated on the lines discussed in [18]. The rule for Basic-action denotes immediate termination with a possible emission of signal. The rule (Sequencing) denotes the classical sequencing operator whereas weak-sequencing denotes the synchronous-sequencing of E STEREL-like synchronous languages. The rule for coregions is the same as synchronous parallel composition. The rule for the loop-construct corresponds to unrolling the body. To avoid causality problems, it is assumed that the loop body takes at least one instance for completion (see Table II for details). The watchdog- construct rewrites in terms of present-rule (E STEREL-construct and the watchdog statement). Thus, if the watched signal or guard is present, then the statement is preempted; otherwise it is rewritten in terms of the do-watching statement. It may be noted that the scope rules follow on the same lines as preemptive statement of E STEREL. The present statement is not explicitly available; its semantics is given below for the sake of completeness.

V. ILLUSTRATIVE EXAMPLES A. Lift System We consider a part of the lift system [20] and show the main generalized concepts introduced/adapted in MSC+ . Figure 7

TABLE I

bmsc: LiftCall

O PERATIONAL S EMANTICS

Basic action a

!0 a

E

PASSENGER LIFTCONTROL

Sequencing X

! ! a

0

X

X:Y

a

Lift-Not-At-Call

Y

bmsc: NotAtCall

E

Coregion X

! a

b1

jjY

X ;Y

E

X

! 1^ 2 !

0

Loop Y

b

X0

X

;

! !b a

X

jjY 0

bmsc: AtCall

bmsc: NotAtCall PASSENGER LIFTCONTROL

0

E

fa; g;b E

b2

LIFT-CALL

bmsc: LiftCall

0

E

N il

LIFT

b X

0

E

loop X end

a

LIFT

MOVE

bmsc: OtherOp X0

E

;

ARRIVAL

loop X end

Selection

bmsc: OtherOp b if b then S1 else S2 end

! b

E

PASSENGER LIFTCONTROL

S1

LIFT

DOOR-OPEN

bmsc: AtCall

ENTER-PASSENGER

:b if b then S1 else S2 end

0

! A E

X:Y

0

B

fA;B E

b

! b !g

X ;Y

Y

0

DOOR-CLOSE FLOOR-REQ

S2

MOVE

!1 f !g

X

E

a

X

DOOR-OPEN

0

X:Y

X 0 :Y

E

Watchdog X

!

a;b

!

a;b

X

0

E

present s else do X 0 wat hing s end

E

s

2

EXIT-PASSENGER

E

A;B

Y0

do X wat hing s

E

LIFT

ARRIVAL

Weak Sequencing X

!

PASSENGER LIFTCONTROL

Fig. 7. hMSC and bMSC of Lift System

Interpret LIFT begin [

/* the events at the instan e PASSENGER are given here */ ℄

E

present s then S1 else S2 end

2

s = E present s then S1 else S2 end

jj

!0

S1

!0

S2

s

E

E

shows the scenario of interaction among a passenger, a lift controller and the lift. After a passenger calls a lift, there will be a condition to check whether the lift is at the call position or not. If the lift is not at call position, the lift have to move towards the call (bmsc:NotAtCall). Otherwise, the door has to open to let the passengers to the lift. In this example, we assumed that FLOOR-REQ can be entered any time before the lift reaches the next floor in the direction chosen by the passenger (see the implementation of the generalized coregion in Figure 7). The sequential operation of events “DOOR-CLOSE” and “MOVE” will be executed concurrently with the “FLOOR-REQ”. The interpretive module of the lift is shown in Figure 8. In the interpretive program shown, the statement on line 1 is equivalent to the event in bmsc:LiftCall in Figure 7. Statement on line 2 checks the condition whether the lift is at call or not. Between line 2 and 5, all events belonging to the bmsc:NotAtCall are listed (lift is not at a call). If the lift is at a call, lines 2-5 will not be executed and the statement on line 6 will be executed just after line 1. All events from bmsc:OtherOp are listed between 6 and 7 (only the structure is shown). B. Automatic Teller Machine The specification of an Automatic Teller Machine (ATM) system [6], [16], [17], [20] is shown as a hMSC in Figure 9 with component MSCs shown in Figure 11 and 12. The machine is

[

/* the events at the instan e LIFT-CONTROL */ 1: in(PASSENGER, LIFT-CONTROL, LIFT-CALL); 2: ondition- old(LIFT-CONTROL, 3: 4: 5: 6:

LIFT-NOT-AT-CALL); out(LIFT-CONTROL, LIFT, MOVE); in(LIFT, LIFT-CONTROL, ARRIVAL); end old; out(LIFT-CONTROLLER,LIFT, DOOR-OPEN);

... 7: out(LIFT-CONTROLLER,LIFT, DOOR-OPEN); ℄

jj

[

/* the events at the instan e LIFT are given here */ ℄ end.

Fig. 8. Interpretive Model of the Lift

assumed to be connected to another node, the bank, located at a different physical location. The machine reads a card, checks the card locally, asks for the amount of money to be withdrawn, accepts the amount, communicates with the bank to perform the actual transaction, delivers the money and sends a signal to the bank for debiting. During the whole process, except in the case of the money-deliver and debit events, the user can cancel the transaction by pressing a cancel button. The client card-code checking section is purely local and reactive. When the valid code is read, the machine does two things in parallel (see the semi relaxed coregion in Figure 11), waiting locally for the amount typed by the client and sending the card information to the bank. When both these independent operations are completed, the amount will be sent to the bank and waits for

the authorization. If the return is true, the machine delivers the money and sends the debit signal to the bank for transaction simultaneously (see the traditional coregion in Figure 12).

advantage for concrete implementation in asynchronous environment will be clear in the next section. watch: Cancel(USER, ATM)

bmsc: CardInsert

USER

USER

BANK

ATM

ATM

BANK

PASSWORD-REQ

bmsc: CardInsert

CARD-INSERTED

PASSWORD-ENTERED AMOUNT-REQ CARD-TO-BANK AMOUNT-ENTERED

watch: Cancel X

AMOUNT-TO-BANK

Authorization

bmsc: Authorized

Fig. 11. bMSCs of the ATM

bmsc: NotAuthorized

bmsc: Authorized

Fig. 9. High-level MSC of ATM

The MSC of the ATM is usually specified by partitioning the task into sub-MSCs (bmsc CardInsert, Cancel, etc.) as shown in Figure 11-12. Specification of the ATM shown in Figure 9 in the form of MSC+ is given below, using the syntax in Table III as well as that of coregion and watchdog described in section III-C. For lack of space, we have shown only the main structure. Interpret AUTO-T-M begin [

/* the events and a tions at the instan e USER are given here */ ℄

jj

[

/* this orresponds to instan e ATM */

loop l1 : l2 :

in(USER, ATM, CARD-INSERTED); wat hed(ATM, CANCEL);

/* the events of ATM to be wat hed are listed here */

out(ATM, USER, PASSWORD-REQ); ................. in (BANK, ATM, AUTHORIZATION); l3 : endwat hed(CANCEL); l4 : ondition- old(ATM,AUTHORIZATION);

... /* the events exe uted if Authorization is given */

l5 : end old; endloop; ℄ jj

[

/* the events and a tions at the instan e BANK given listed here */

℄ end.

Fig. 10. Interpretive Model of the ATM

In Figure 10, we have the loop - endloop corresponding to the loop of the hMSC shown in Figure 9. The statement on line l1 corresponds to bmsc:CardInsert (Figure 11), lines l2 l3 corresponds to the watching part of the MSC watch:Cancel shown in Figure 11; the actions in between l2 l3 correspond to the events received/sent on this instance and local actions. l4 l5 corresponds to the cold condition corresponding to the selection condition “Authorization” shown in Figure 9. It should be quite clear the translation follows from the graphical specification to a textual fashion in a natural way. This translation is achieved through the editor supported in the MSC+ environment. The

USER

bmsc: NotAuthorized ATM

BANK

USER

ATM

BANK

DEBIT DELIVER-MONEY

Fig. 12. bMSCs of the ATM

C. Relating Asynchrony and Atomicity in the Implementation It may be noted that the specification discussed above in the ATM example allows for the possibility of CANCEL at any point. However, as shown in [16], it is not possible to permit preemption at all points after the initiation of rendezvous communication with the bank due to the limitations of implementations of the notion of “simultaneity” and “nondeterminism” over a network of asynchronous processes. However, MSC+ specification can aid in specifying the range of preemption and thereby the underlying atomicity. If we now restrict the range of preemption of CANCEL (cf. Figure 11) up to point X, (i.e. the dotted line of the frame passes through this point rather than as shown in Figure 11) then we can assure that the bank will not debit the customer’s amount unless the cash is delivered to the customer and vice versa. Thus, through MSC+ it is possible to clearly specify the underlying atomicity/asynchrony relative to the implementation or the execution model. This is something very useful as it becomes necessary to use “freezing preemption” in the implementation of CRP [6], [16]. VI. TRANSLATION OF

MSC+

TO ESTEREL

In this section, we shall describe a translation of MSC+ to E STEREL [4], [5]. We assume the event transmission to be synchronous. We translate MSC+ to E STEREL using the following framework assuming that selection (choice) is deterministic. i. Every instant in bMSC is translated into a module. ii. The module will have the declaration part with input relations if needed and the program body. All signals of the outmessages in MSC+ are declared as output signals in E STEREL , and all signals of in- messages as input signals in E STEREL. The program body of E STEREL will correspond to the local actions in the instance and the interactions from this instant (module) to the other instances (including “user” and “environment”). iii. All the instances in a bMSC are translated as a set of E S TEREL modules.

iv. The hMSC is composed of bMSC, sequencing or weak sequencing and loop operation.

VII. PROGRAMMING ENVIRONMENT FOR

TABLE II

T RANSLATION OF MSC +

MSCs/hMSC. Further, we arrive at a state - based interpretation of the specification with a clean formal semantics.

TO

E STEREL

MSC+ language

E STEREL

out (U, A, C)

emit C

in (A, U, PR)

await immediate PR

loop endloop

loop

watched (A, C) endwatched

do stat watching immediate C

action (U, X=EXP)

X :=EXP

Condition-hot (U, HALT)

do ... watching immediate

[ [ stat℄

jj await tick ℄ end

HALT Timeout ERROR end Condition-cold (A, P) endcold

if P then

Condition-cold (A, PO) endcold

present PO then

out (U, A, C) jj in (A, U, PR)

emit C jj await immediate PR

out (U, A, C) ; in (A, U, PR)

emit C ; await immediate PR

U=User; A=ATM; C,PR,PO=Signals; P=boolean

module ATM: % signal de larations input CANCEL,CARD-INSERTED; input PASSWORD-ENTERED; input AUTHORIZATION; input AMOUNT-ENTERED; output PASSWORD-REQ,CARD-TO-BANK output AMOUNT-REQ,DELIVER-MONEY,DEBIT; output AMOUNT-TO-BANK; % program body, loop loop await CARD-INSERTED; % wat hing an el do emit PASSWORD-REQ; await immediate PASSWORD-ENTERED; [ emit AMOUNT-REQ; await immediate AMOUNT-ENTERED; ℄; jj

emit CARD-TO-BANK; emit AMOUNT-TO-BANK; await immediate AUTHORIZATION; wat hing CANCEL % end of wat hing present AUTHORIZATION then % if authorized emit DELIVER-MONEY; jj

emit DEBIT; end present; end loop end module Fig. 13. E STEREL code of the ATM

The basic translation is shown in Table II. Here [[stat℄℄ denotes the translation for MSC+ to E STEREL. As explained already, the execution of the loop body ensures the passing of one instant due to the “await tick” in parallel with [[stat℄℄. For lack of space, we shall not go into the details of the translation or correctness; (cf. [2]). In Figure 13 the translation of a fragment of the MSC+ for ATM in E STEREL is shown . It is very easy to see from the source and the translated program the correspondence between the textual semantics described earlier with the E STEREL program given above. Through a translation into E S TEREL, it is possible to check all the rules of consistency of

MSC+

The development of an environment for MSC+ is under advanced stages of completion. The following tools are part of the environment. +  Editor for specific MSC , +  Direct simulation of MSC , +  Translation of MSC to E STEREL, + and the simu Link between the direct simulation of MSC lation of the translated E STEREL program +  Analyzing the consistency features of MSC directly. We have designed a prototype GUI that supports the drawing, editing, saving loading, etc of components specified in MSC+ . The chart may be stored in graphical form or in the textual form standardized by ITU (Z.120). The tool supports the exporting and importing of graphical and/or textual files through built-in menu choices. We have used, in the graphical representation, the standard definition of bMSCs and hMSC. The resulting graphical representation of hMSCs provides operators to connect basic MSCs to describe sequential, iterative, parallel and non-deterministic execution of bMSCs. The tool works on two different levels in the graphic layout (using graphical symbols of hMSCs and basic MSCs). The first level is used to draw the specification of the hMSCs. It includes all the features of the hMSCs like the starting node, ending node, process flow, connectors and the frame. The second level constructs all graphical symbols of basic MSCs like instance, message, action, condition, timer, etc. The tool supports the syntactic analysis of MSC+ and the automated synthesis mechanism for translating MSC+ specification to E STEREL and making use of the E STEREL simulation and verification environment through integration. MSC+ tool is written entirely in Java. It provides a clever and easy-to-use modeling tool, with smooth and fast learning period. It supports a defined and repeatable development process which includes requirements specification, requirement analysis, system architectural design and code generation. It also includes two improvements over the standard process: it allows what is called reverse engineering: reading and analyzing existing source code of MSCs (textual representation) and creating graphical design diagrams (graphical representation) out of it, and it enables the simulation of models during the analysis and design stages. The MSC+ tool facilitates graphical simulation of systems. Users have the facility to simulate the designed model using the inbuilt simulator. It has the additional to use the E STEREL environment for simulating, validating and verifying the same model. VIII. DISCUSSION

The MSC+ - a generalization of hMSCs - has features such as watching, loop, coregion and conditions. We have illustrated that such extensions lead to natural specifications of reactive systems through the illustrative examples. It can also be seen that the generalized specification language is still simple and preserves the rationale of MSCs or hMSCs. Further, we have

provided a translation to E STEREL [2]. Such a translation has two advantages: it leads to a precise semantics and also leads to synthesis of prototype systems that can be simulated, validated and verified using the E STEREL environment. As highlighted already, MSC+ specification permits a clear specification of atomicity/asynchrony relative to the implementation model. Another distinct advantage of such a system has been in the checking of properties of the system as well as specifying the properties to be verified/validated (safety and bounded liveness properties). In this context, we have been using MSC+ for the specification of “observers” in the verification of E STEREL programs with interface to a model checker developed at TIFR [15]. The interface essentially transforms specification property in MSC+ into synchronous observer (which is another E S TEREL program). In our experience so far, we have found the tool to be extremely useful for the engineers in the development process. Since MSCs are the medium through which requirement specification in UML or SDL, we are working towards integration of MSC+ environments in the context of UML/SDL. R EFERENCES [1]

[2]

[3]

[4] [5] [6] [7] [8]

[9] [10] [11]

[12] [13] [14]

[15]

Mesfin Belachew, A. Gandhi, S. Gadhwala, and R. K. Shyamasundar. MSC+ : A Generalized Hierarchical Message Sequence Charts. The Third International Conference on Information Technology (CIT2000) Eds. R K Ghosh & Durgamadhab Misra, Tata McGraw-Hill Publishing Company Limited, pages 183–189, December 21-23, 2000. Bhubaneswar, India. Mesfin Belachew, Ashit Gandhi, Shabaz Gadhwala, and R. K. Shyamasundar. Message Sequence Charts Development Tool (MSC+ -Tool). Technical Project Report, School of Technology and Computer Science, Tata Institute of Fundamental Research, 1999. Mesfin Belachew, R.K. Shyamasundar, and V.N. Joshi. Designing of Reactive System using Extended Message Sequence Charts. Advances in Computational Engineering & Science, (Alturi, S.N and Brust, F.W. Eds), Tech Science Press, Vol. II:1574–1579, 2000. Proceeding ICES’2K, Los Angeles, CA, USA. G. Berry. A Quick Guide to Esterel Version 5.10, release 1.0. Technical Report, 1997. Ecole des Mines and INRIA. G. Berry and G. Gonthier. The Esterel Synchronous Programming Language: Design, Semantic, Implementation. Science of Computer Programming, 19(2):87–152, 1992. G. Berry, S. Ramesh, and R.K. Shyamasundar. Communicating Reactive Process. ACM, pages 85–99, 1993. In Proceding of 20th ACM Conference on Principles of Programming Language, Charleston, Virginia. Gerard Berry. Preemption in Concurrent Systems. LNCS 761, Proc. 20th FSTTCS, pages 72–93, 1993. Werner Damm and David Harel. LSCs : Breathing Life in to Message Sequence Charts. Proc. 3rd IFIP Int. Conf. on Formal Methods for Open Object-based Distributed System, P. Ciancarini, A. Fantechi and R. Gorrieri, eds., Kluwer Academic Publishers, pages 293–312, 1999. E. Rudolphand P. Graubmaann and J. Grabowiski. Tutorial on Message Sequence Charts. In computer Networks and ISDN system, SDL and MSC, 28, 1996. ITU-TS. Recommendation Z.120 : Message Sequence Chart. Geneva, 1996. Lalita J. Jagadeesan, Carlos Puchol, and James Von Olnhausen. A Formal Approach to Reactive System Software: A Telecommunications Application in Esterel. International Workshop on Industrial-Strength Formal Methods, Boca Raton, FL, April 1995. S. Maum. The Formalization of Message Sequence Charts. Computer Networks and ISDN system, Elsevier Science Publishers B.V., 28(12):1643–1657, 1996. S. Maum and M.A. Reniers. An algebraic semantic of message sequence charts. The computer journal, 37(4):269–277, 1994. S. Mauw and M.A. Reniers. Operational semantics for MSC’96. In A. Cavalli and D. Vincent, editors, SDL’97: Time for Testing - SDL, MSC and Trends, Tutorials of the Eighth SDL Forum, Evry, pages 135–152, September 1997. France. P. K. Pandya. DCVALID: A Tool for Modelchecking DC Formulae. Technical Report, TIFR. http://www.tcs.tifr.res.in/˜pandya/, 2000.

[16] B. Rajan and R.K. Shyamasundar. An Implementation of Communicating Reactive Process. Intl. Conf. on Parallel and Distributed Computing and Networks, Singapore, 1997. [17] C. Rolland, C. Souveyet, and C. Ben Achour. Guiding Goal Modeling Using Scenarios. IEEE Trans. on Software Engineering, 24(12):1055– 1071, 1998. [18] R.K. Shyamasundar. Programming Dynamic Real-Time Systems in CRP. CSA Jubilee 95, 1995. [19] S.Mauw and M.A.Reniers. High-level Message Sequence Charts. Proceding of the Eighth SDL Forum, pages 291–306, September, 1997. In A.Cavalli and A.Sarma, editors, SDL’97: Time for Testing-SDL, MSC and Trends, Evry, France. [20] A. van Lamsweerde and L. Willemet. Inferring Declarative Requirements Specifications from Operational Scenarios. IEEE Trans. on Software Engineering, 24(12):1089–1114, 1998.

APPENDIX TABLE III T EXTUAL S YNTAX FOR MSC +

mess seq chart msc body inst def inst body event

message send message receive message name timer

timer name time out timer reset create inst termin inst action coregion loop watching condition

condition name

shared inst list

1 IDENTIFIER 2 NUMBER

: MSC msc name1 ; msc body ENDMSC; : j inst def msc body : INSTANCE inst name1 ; inst body ENDINSTANCE; : j event inst body : message send j message receive j condition j create inst j termin inst j coregion j action j timer j loop j watching : OUT message name TO address1 ; : IN message name FROM address; : IDENTIFIER j IDENTIFIER [ param list ℄ : SET timer name; inst body timer out j SET timer name; inst body timer reset : IDENTIFIER j IDENTIFIER ( duration2) : TIMEOUT a timer name1 ; : RESET a timer name; : CREATE inst name; : STOP inst name; : ACTION action name1 ; : CONCURRENT inst body ENDCONCURRENT; : LOOP inst body ENDLOOP; : WATCHED signal name1 ; inst boday ENDWATCHED; : CONDITION COLD condition name inst body ENDCOLD; j CONDITION HOT condition name : IDENTIFIER; j IDENTIFIER SHARED shared inst list; j IDENTIFIER SHARED ALL; : inst name [ , inst name ℄