Consistency Checking for LSC Specifications

Hai-Feng Guo, Wen Zheng, Mahadevan SubramaniamDepartment of Computer ScienceUniversity of Nebraska at OmahaOmaha, NE 68182-0500, USA

Emails: {haifengguo,wzheng, msubramaniam}@mail.unomaha.edu

Abstract

Live sequence charts (LSCs) have been proposed as aninter-object scenario-based specification and visual pro-gramming language. In this paper, we introduce a highlevel computational semantics of LSCs, in the form of aPLAY-tree, to show how a running LSC affects the systembehaviors in response to a set of external events. Given anonempty regular language of external events, the consis-tency of an LSC specification is defined as whether there ex-ists a corresponding PLAY-tree with all success branches;in case of inconsistency, failure traces can be obtainedthrough failure branches of the PLAY-tree. We also presentan algorithm using a memoized depth-first search strategyand an implementation framework in logic programmingfor consistency checking of LSCs.

1 Introduction

Live sequence charts (LSCs) [7, 11] have been in-troduced as an inter-object scenario-based specificationand visual programming language. The language extendstraditional sequence charts, typically sequence charts inUML [19] and message sequence charts (MSCs) [21], byenabling mandatory behaviors and forbidden behaviors ofreactive systems. With mandatory behaviors, LSCs are ableto specify necessary system behaviors in a more seman-tically precise manner instead of only posing weak par-tial order restriction on possible behaviors as in sequencecharts. Such a semantical precision is critical to upgrad-ing the LSCs from a formal specification tool to an achiev-able dream of becoming a scenario-based programming lan-guage [9], since mandatory behaviors exactly tell what toexpect at system runtime. In addition, a forbidden behaviorspecification further enriches the LSCs with self-containedconsistency checking capability; it allows the LSCs to spec-ify the failure scenarios and to locate failure traces at run-time by checking reachability instead of testing failure con-ditions explicitly and blindly at every running step. LSCs

have been successfully used in many real-life applicationssuch as hardware and software verification [3, 6], an air traf-fic control system [5], and a radio-based train system [2].The features of specifying mandatory and forbidden behav-iors have recently been incorporated into the UML 2.0 [20]to increase its expressive power.Consistency checking [10, 17, 16, 14, 15, 13] is one of

the major and formidable problems on LSCs. In a compli-cated system consisting of many LSCs, inconsistency maybe raised by inherent contradiction among multiple chartsor due to inappropriate environmental/external event se-quences. Previous work on consistency checking are mainlyfocused on automata-based strategies. In [10], the con-sistency of LSCs is shown as a necessary and sufficientcondition for the existence of an object system satisfyingit; the consistency checking is then reduced to a problemwhether a satisfying object system, in a form of automa-ton, can be synthesized from LSCs. Other automata-basedtransformation includes [4, 16, 15], which turn the LSCspecification into variants of buchi automata for verifica-tion. In [17], a semantic transformation from LSCs to com-municating sequential process (CSP) is presented, so thatthe consistency checking of LSCs can be done by reusingan existing tool for CSP. Additionally, there has been somework done in translating LSCs to temporal logic for modelchecking [14, 13]. All these automata-based consistencychecking strategies lacks the capabilities for LSCs users, atthe language level, to specify any user-preferred testing andsimulate running LSCs in any way. Therefore, they can onlybe served as a formal verification tool to support static anal-ysis on LSCs, and at the same time, may suffer the complex-ities caused by transformation itself, automata synthesis, orthe blowing size of transformed results [18, 12].In this paper, we present a new high-level computational

(operational) semantics of LSCs to show how a runningLSC affects the system behaviors in response to a contin-uous input of external events. The semantics is defined inthe form of a derivation tree, called PLAY-tree, where eachbranch from the root to a leaf corresponds to a possible LSC

2009 Third IEEE International Symposium on Theoretical Aspects of Software Engineering

978-0-7695-3757-3/09 $25.00 © 2009 IEEE

DOI 10.1109/TASE.2009.8

119

run on a sequence of external event inputs. The consistencyof an LSC specification L is defined as, given a nonemptyregular language I of external events, whether there existsa corresponding PLAY-tree with all successful branches. Ifsuch a PLAY-tree exists, then the LSC L is consistent onthe input language I; otherwise, a failure evidence will beshown in the PLAY-tree, and the corresponding input eventscan be obtained along the computing branch to construct afailure trace. As a result, the consistency checking of anLSC is basically an ordered traversal of the PLAY-tree. Wepresent a traversal algorithm using a memoized depth-firstsearch strategy for consistency checking of LSCs. In thispaper, we adopt assumptions similar to [11]. We assumeall messages in LSCs are synchronous and that no send-ing messages are lost during over communication channels;for running LSCs, we also assume that, using an input-enabled concurrency model, no two external events occurat the same time and that internal events are processed atreal-time, much faster than receiving a next external event.Our computational semantics using a PLAY-tree essen-

tially extends the operational semantics defined in [11] withthe consideration of system object states and continuous en-vironment reaction. This is closely aligned with the origi-nal objective of LSCs to become a scenario-based program-ming language [9], where the PLAY-tree can potentiallyserve as an automated simulation and debugging tool forrunning LSCs. An executable LSC specification as wellas automatic simulation, debugging and consistency check-ing capabilities are critical to system modeling and devel-opment, simplifying significantly the early designs of trust-worthy software and hardware development processes.The paper is structured as follows. Section 2 gives a brief

introduction of the syntax and semantics of LSCs througha simple intercommunication system. Section 3 presentsthe definition of PLAY-tree, illustrates how a running LSCreacts to the environment events using a PLAY-tree, andshows how the consistency of LSCs is defined on the PLAY-tree. Section 4 presents a memoized depth-first search strat-egy for consistency checking; and section 5 gives a brief in-troduction of our implementation framework. Finally, con-clusions are given in Section 6.

2 Live Sequence Charts (LSCs)

LSCs have two types of charts: universal and existentialcharts. A universal chart is used to specify a scenario-basedif-then rule, which applies to all possible system runs. Auniversal chart typically contains a prechart, denoted by atop dashed hexagon, and a main chart, denoted by a solidrectangle right below a prechart; if the prechart is satisfied,then the system is forced to satisfy the defined scenario inthe main chart. An existential chart is usually used to spec-ify a test scenario that can be satisfied by at least one pos-sible system run. In this paper, we will focus on universal

charts only, since achieving the consistency among univer-sal charts on all system runs is more interesting and difficult.Another main feature of LSCs is the assignment of tem-

peratures, hot or cold, to various elements in a chart includ-ing locations, messages, and conditions. Within a chart, ahot element signifies that things that must move on, whilea cold element signifies things that may occur. The combi-nation of universal charts and hot elements can be used tospecify forbidden scenarios.Figure 1 shows five universal charts for an intercom-

muncation system between two intercom devices, namedintercom1 and intercom2, each of which has a switchwith on/off states. All the locations and messages inmain charts are hot. Chart 1(a) says if agent1 sends a mes-sage to the intercom1 and its switch is on, then the de-vice will forward the message to the communication chan-nel. Chart 1(b) says if the intercom1 receives a messagefrom the channel and its switch state is off, the messagewill be played in its speaker. Charts 1(c) and 1(d) showhow a switch state is changed and how the communicationchannel works, respectively. Similar universal charts for theintercom2 are defined, but not shown here. Chart 1(e)defines a forbidden scenario under the assumption that nomessages are lost; if the intercom1 receives a messagefrom the channel but its switch is on, then the system willissue a violation because the message will not be playedin the speaker and thus lost in transition. Figure 1 containstwo external messages: msg1 and press1; similarly in theLSCs for the intercom2 device, there are two extra ex-ternal messages: msg2 and press2, which are not shownhere.Now we briefly introduce the semantics of LSCs, whose

detailed explanation can be found in [11]. Given an LSCL, a running copy of L is defined as 〈Lr,Mode, Cut〉,where Lr is a copy of the original chart, Cut is a legal tu-ple of L representing the runtime locations of the instancesof Lr, and Mode is either PreActive or Active denotingwhether the current Cut is in prechart or main chart respec-tively. Let E be a set of all system events including ex-ternal messages, internal messages among system objects,or hidden events defined in LSCs. Thus, the operationalsemantics of an LSC specification Ls with respect to a sys-tem model Sys can be defined as a state transition systemSem(Ls, Sys) = 〈S, s0,Δ〉. S is the set of possible states,A state s ∈ S is defined as 〈Q,RL, B〉, where Q is a setof system object states in Sys, RL is the set of currentlyrunning copies of LSCs, and B indicates by True or Falsewhether the state is a violating one; s0 = 〈Q0, ∅, False〉is the initial state, where Q0 is a set of initial system objectstates; and the functionΔ : S×E → S is the set of allowedtransitions. Given a current state s ∈ S and a system evente ∈ E, the transition Δ(s, e) returns an updated state afterprocessing one or more of the following actions: activating

120

(a) (b)

(d)

(c) (e)

Figure 1. An LSC specification for an intercom system

a universal chart copy toRL if applies, removing a runningLSC from RL if complete, advancing the cuts in each run-ning LSC inRL by processing e and updating object statesin Q accordingly if applies, or setting the flag B to True ifviolation. Note that the definitions of a state transition sys-tem Sem and its transition functionΔ are slightly differentfrom the ones defined in [11]. Here we include a systemmodel Sys and consider the changes of system object statesduring the transition.The Play-Engine in [11] provides an execution platform

for a given system model Sys and its LSC specification Ls

by implementing the operational semantics Sem(Ls, Sys).The LSCs can be executed in phases of step and super-step.The procedure for a step phase, given a transition systemstate s and a system event e, is essentially the application ofΔ(s, e). The super-step phase, given an external message e

at a super-step state, continuously executes the steps asso-ciated with enabled internal events until the system reachesa stable state where no further internal or hidden events canbe carried out. Let Ss denote a set of all super-step states. Asuper-step state is either the initial state s0 or a stable stateafter executing an external message.

3 PLAY-tree

In this section, we present a running LSC engine whichtakes as inputs a system model Sys, an LSC specification

Ls and a context-free grammar (CFG) G = (V,Σ, V0, P )denoting a language L(G) ⊆ Σ∗, and checks whether therunning Ls will react consistently to any external event se-quence w ∈ L(G). For a CFG G = (V,Σ, V0, P ), V isa set of variables, Σ is a set of external events, V0 ∈ V isthe main variable to represent L(G), and P is a set of CFGproduction rules. The computational semantics of our en-gine essentially extends the operational semantics definedin [11] with the consideration of system object states andcontinuous environment reaction.We first introduce a new notation ∇ : Ss × Σ → S+

sto

denote the state transition related to a super-step procedurein [11], which takes a super-step state (Q,RL, B) ∈ Ss andan external message a ∈ Σ as inputs and returns a set ofall possible next super-step states. Multiple next super-stepstates are possible because the enable events may containinterleaving events, which can be executed in a nondeter-ministic order.We then introduce another new succinct notation for de-

scribing the successive configurations of a running LSC en-gine given the input of a CFG denoting a set of an externalevent sequences. A four-tuple (Q,W,RL, B), where Q isa set of current object states defined in Sys, W is the un-processed part of the CFG in a sentential form, RL is aset of current running LSCs, and a boolean variable B indi-cates by True or Falsewhether the state is a violating one, iscalled an instantaneous description (ID) of the running en-

121

gine. The ID completely determines all the possible waysin which the running engine can proceed.

Definition 1 (Move) A move from one ID to another, de-noted by the symbol , could be one of the following cases:

• if a is an external/terminal event, that is, a ∈ Σ andW ∈ {Σ ∪ V}∗,

(Q1, aW,RL1, B1) (Q2,W,RL2, B2)

is possible if (Q2,RL2, B2) ∈ ∇((Q1,RL1, B1), a).Such a move is called a terminal move.

• if A is a nonterminal variable in V ,

(Q,AW,RL, B) (Q,D1 · · ·DnW,RL, B)

is possible if A → D1 · · ·Dn is a CFG production inP . Such a move is called a nonterminal move.

Different terminal moves from a same ID are possibledue to inherent nondeterminism which could be caused byinterleaving messages in an LSC; and different nontermi-nal moves from a same ID are also possible due to multipleCFG productions from the same variable to represent dif-ferent message sequences. Therefore, to show all possiblemoves systematically, we introduce a derivation tree, calleda PLAY-tree, to illustrate the running LSC engine.

Definition 2 (PLAY-tree) Let Sys be a system model, Ls

its LSC specification and G a context-free grammar. Thenthe PLAY-tree for (Sys, Ls,G) is defined as follows:

1. Each node of the tree is an ID.

2. The root node is (Q0, V0, ∅, False), where Q0 is a setof initial system object states, V0 is the start variablein the CFG G, and the empty set ∅ means no runningLSCs at the initial state.

3. Let (Q,W,R,B) be a node in the tree. This node hasan edge to a child (Q1,W1, R1, B1) for each possiblemove (Q,W,R,B) (Q1,W1, R1, B1).

4. The following nodes have no children:(Q,W,R, True), denoted as a violating leaf node,and (Q,λ,R, False), denoted as a success leaf node.

Each parent-child edge represents an ID move. For clar-ity, we add labels for each edge. For an edge of a terminalmove, the label is in form of [a], where a is the exter-nal event triggering the move; for an edge of a nontermi-nal move, the label is the production rule A → D1 · · ·Dn,which triggers the move. Each branch of the PLAY-tree is apath from the root to a leaf. A success branch correspondsto a branch ending at a success leaf, (Q,λ,R, False); a

failure branch corresponds to a branch ending at a violatingleaf, (Q,W,R, True); and a branch with infinite moves iscalled an infinite branch. For a finite branch, if we concate-nate all the labels (external events) of the terminal movesalong the path from root to leaf, we call it the event se-quence of the branch.

Example 1 Consider the intercom system example (as de-scribed in Fig. 1) with the external event input (press1 ·msg1∗ · press1 + press2 · msg2∗ · press2)∗. The regularexpression can be represented in a context-free grammar G

with the main variableW as follows:

W → λ | AW

A → press1 · M1 · press1 | press2 · M2 · press2

M1 → λ | msg1 · M1

M2 → λ | msg2 · M2

Figure 2 shows a PLAY-tree for the intercom system withthe above CFG input, where the round box and the boldrectangle denote an internal node and an leaf node, respec-tively. The object state of the intercom system is sim-ply represented as a set of properties {switch1.state,switch2.state}. Thus, the root node is the ID({off,off},W,∅,False), where both intercom de-vices initially have their switches off. Even though the in-put regular expression contains infinite sequences, for eachfinite sequence w ∈ L(G), there is a corresponding successbranch in the PLAY-tree, along which if we concatenate allthe labels of terminal moves from the root, the result will bethe finite message sequence w. The PLAY-tree in Figure 2is not complete due to the infinite branches.Note that in each node of the PLAY-tree, the set of cur-

rent running LSCs is always ∅. That is because in this in-tercom system example, (i) no LSCs are active initially; (ii)after receiving an external event and then processing all en-abled internal events, all the activated LSCs will be com-plete before receiving a next external event. This is consis-tent to the simulation results in the super-step mode usingthe Play-engine [11]. Also, we choose this example particu-larly to leave the details in [11] on how exactly the transitionfunction Δ works, due to the space limitation.It needs to be mentioned that for a finite sequence w ∈

L(G), there may exist multiple corresponding branches,each of which may be a success or violating branch. Therecould be two different reasons. One possibility is that thegrammar G for a regular language may be ambiguous, thuscausing two different derivations for the same sequence.However, such an ambiguity can be avoided since each reg-ular language can be represented by an unambiguous gram-mar. The other is due to the fact that for a terminal move

(Q1, aW,RL1, B1) (Q2,W,RL2, B2),

122

... ...

... ...

... ... ... ...

φ ,False)({off,off},W,

φ ,False)({off,off},AW,

λM1−>

φ ,False)({off,off},W,

W−> λ

φ ,False)({off,off}, ,

W−> λ

λM1−>

φ ,False)({off,off}, ,λ

W−>AW

[press1]

A−>press1.M1.press1

[press1]

λ

W−>AW

[msg1]

M1−>msg1.M1

A−>press2.M2.press2

M1−>msg1.M1

φ ,False)({off,off}, press1.M1.press1.W,

φ ,False)({on,off}, M1.press1.W,

φ ,False)({on,off}, press1.W, φ ,False)

φ ,False)

({on,off}, msg1.M1.press1.W,

({on,off}, M1.press1.W,

Figure 2. A PLAY-tree for the intercom system in Example 1

there could be multiple different (Q2,RL2, B2) ∈∇((Q1,RL1, B1), a) due to the nondeterministic nature ofthe LSC specification (e.g., two internal events could be ex-ecuted in different orders, but result in different next systemstates).

Definition 3 (Least Prefix of a failure trace) If there ex-ists a failure branch in the PLAY-tree, then its correspond-ing event sequence becomes a prefix of failure trace. A pre-fix ω is a least one if there is no strict prefix of ω leading toa failure leaf in the PLAY-tree.

Example 2 Consider the intercom system example againwith input (press1+msg1+press2+msg2)∗. The regularexpression can be transformed to a context-free grammarG1 as follows:

W → λ | press1 · W | msg1 · W |

press2 · W | msg2 · W

There exist failure branches in the PLAY-tree for the inter-com system andG1. We only show one failure branch fromthe root to the violating leaf as follows:

({off, off}, W, ∅, False)W → press1·W−−−−−−−−−−−−→

({off, off}, press1·W, ∅, False)[press1]−−−−−→

({on, off}, W, ∅, False)W → press2·W−−−−−−−−−−−−→

({on, off}, press2·W, ∅, False)[press2]−−−−−→

({on, on}, W, ∅, False)W → msg1·W−−−−−−−−−−−→

({on, on}, msg1·W, ∅, False)[msg1]−−−−→

({on, on}, W, ∅, T rue)

The violation is caused by the forbidden scenario, whichis activated by an incoming message from channel and thereceiving intercom state on. In this scenario, the incomingmessage will be lost in transition; and the message sequencepress1·press2·msg1 is a least prefix of failure trace.

Definition 4 (Consistency) A system model Sys is consis-tent to its LSC specification Ls on a language L(G), whereG is a CFG, simply to say that an LSC model (Sys, Ls,G)is consistent, if for each finite external event sequence w ∈L(G), every corresponding branch of w in the PLAY-tree of(Sys, Ls,G) is a success branch.

The consistency of an LSC model (Sys, Ls,G) is de-fined in terms of a PLAY-tree. It is consistent if all the finitebranches in the PLAY-tree are success branches; otherwise,the LSC model is inconsistent if there exists a failure branchin the PLAY-tree; and a prefix of failure trace can be easilylocated along the failure branch. Therefore, the intercomsystem with the CFG G in Example 1 is consistent becausefor each finite sequence w ∈ L(G), there is a correspond-ing success branch in the PLAY-tree shown in Fig. 2; whilethe intercom system with the CFGG1 is inconsistent due tothe existence of a failure branch, as shown in Example 2.

4 A Memoized Depth-first Search

Given an LSC model (Sys, Ls,G), the consistencychecking is basically a traversal of its PLAY-tree to seewhether there exists any failure branch. Due to the recursionnature of the context-free grammarG, there may exist many

123

... ...

φ ,False)({off,off},W,

λM1−>

W−> λ

φ ,False)({off,off}, ,λ

W−>AW

[press1]

A−>press1.M1.press1

[press1] [msg1]

M1−>msg1.M1

φ ,False)

φ ,False)({off,off},AW,

φ ,False)({off,off}, press1.M1.press1.W,

A−>press2.M2.press2

φ ,False)({on,off}, M1.press1.W,

φ ,False) φ ,False)({on,off}, press1.W, ({on,off}, msg1.M1.press1.W,

φ ,False) ({on,off}, M1.press1.W,({off,off},W,

Figure 3. A memoized PLAY-tree for the intercom system in Example 1

infinite branches in the PLAY-tree, or the finite branch couldbe any long. Therefore, neither depth-first nor breadth-firststrategy is good enough for the completion of consistencycheck over the PLAY-tree. Here we further assume that thereactive system Sys is defined over finite application do-mains.We then introduce a memoized depth-first search strat-

egy for traversing a PLAY-tree, such that any repeated IDsseen later during the traversal will not be explored again. Amemoized depth-first strategy is essentially an extension ofstandard depth-first search where visited IDs are recordedso that their later occurrences can be simply considered acycle of moves. Thus, we define a memoized PLAY-tree asfollow:

Definition 5 (Memoized PLAY-tree) A memoized PLAY-tree for (Sys, Ls,G) is a traversal of its PLAY-tree from theroot, in a depth-first and left-to-right order, with the follow-ing extra constraints:

1. The root node is an internal node, unless the CFG G

contains no production rules.

2. For each labeled edge from an internal node(Q,W,RL, B) to a child node (Q1,W1,RL1, B1),

• if the ID (Q1,W1,RL1, B1) is seen before dur-ing the traversal, then the child node is denotedas a memoized leaf node;

• otherwise, the child node is a leaf only if B1 =True (a violating leaf), or both W1 = λ andB1 = False (a success leaf).

A memoized PLAY-tree for Example 1 is shown inFigure 3, where we use a bold round box to denotea memoized leaf, and the dashed arrow to highlightthe repeated occurrences. The part under the labelA->press2.M2.press2 is similar to its sibling part,

thus omitted. The distinguished feature of a memoizedPLAY-tree is that the moves from each ID are only exploredonce, therefore significantly reducing the size of the PLAY-tree for consistency checking.Figure 4 shows a pseudo code algorithm for consistency

checking, where the recursive function mdft takes an ini-tial ID and an initially empty trace as input, and checks ina memoized depth-first order whether the LSC specifica-tion is consistent over all the input event sequences. Thefunction mdft returns a pair (B,Trace) consisting of aviolation indicator B and a failure trace Tr if violated. A

1. GT:global variable to record seen IDs2. (Bool, Σ∗) mdft((Q, W, R, B):ID, Tr:Σ∗)3. if (B is True)4. return (True,Tr); %% violation5. if (W is λ)6. return (False,Tr); %% success7. if ((Q, W, R, B) ∈ GT)8. return (False,Tr); %% memoized ID9. GT ← GT ∪ {(Q, W, R, B)};10.Let W = AW1; %% A is the first char11.if (A is an external event)12. Tr ← A + Tr; %% concatenation13. for each (Q1, R1, B1) ∈ ∇((Q, R, B), A)

14. (V, Tr1) ← mdft((Q1, W1, R1, B1), T r);15. if (V is True)16. return (V, Tr1);17.else %% if A is a nonterminal variable18. for each A → D1 · · ·Dn, where n ≥ 0

19. (V, Tr1) ← mdft((Q, D1 · · ·DnW1, R, B), T r);20. if (V is True)21. return (V, Tr1);22.return (False, Tr);

Figure 4. An algorithm for a memoized depth-first traversal of PLAY-tree

124

Simulation with A CompactSet of Success Traces

Simulation with aLeast Prefix Failure TraceModel in LSCs

Reactive Systemin regular expression

External Events

Production GrammarDefinite Clause

Logic Programs

TransformationSemantics−based

TransformationAutomatic

LSC Consistency Checker (L2C2)in Logic Programming

(Truth, Justification)

Logic ProgrammingEnvironment

input input output

Truth=true Truth=false

Play−Engine Environment

Figure 5. An architecture of Logic-based LSC Consistency Checker (L2C2)

global table, named GT, is introduced to record all the IDsin the visited internal nodes (line 9). If a new node hasan ID which has already been in the global table, then noexploration will be taken below this node (line 7-8); oth-erwise, appropriate moves will take place depending on theleftmost symbol in the sequence inputW (lines 10-22). Thelocal variable Trace is used to concatenate all the externalevents along the current branch from root to the current call-ing ID (line 12). Whenever a violation ID is found, it willimmediately return the failure Trace to the parent caller(lines 3-4, 15-16, 20-21); otherwise, the functionmdft willcheck all input event sequences to make it sure that the LSCsystem is consistent.Now we present as follows two important results related

to the our memoized depth-first algorithm mdft.

Theorem 1 An LSC specification (Sys, Ls,G) is consis-tent if the recursive function mdft((Q0, V0, ∅, False), λ)return (False, ) successfully, where Q0 and V0 are theinitial object states of Sys and the main nonterminal vari-able in G, respectively.

We ignore the the second return value of the functionmdft by an underscore . Note that the theorem claims theif relation only. The only if relation may not hold due toeither infinite domains or non-termination.

Theorem 2 An LSC model (Sys, Ls,G) is inconsistent ifthe recursive function mdft((Q0, V0, ∅, False), λ) return(True,Trace) successfully, and the returned Trace isa least prefix of a failure trace.

If an LSC model (Sys, Ls,G) is inconsistent, then thefailure trace returned from mdft must be a least prefix be-cause the failure branch does not involve any repeated in-ternal nodes due to the applied memoization scheme in thealgorithm.Different from the automaton-based strategies [10, 4, 16,

15] that the LSC system is transformed into an equiva-lent automaton, in which the language of the LSC modelis defined, our work here designs a computational scheme

and implements a logic-based simulator to show whether anLSC system is consistent to a given language defined overa set of external events.

5 Logic-based LSC Consistency Checker

We have implemented a logic-based LSC consistencychecking system, named L2C2, in Prolog. The architectureof our L2C2 tool, described in Figure 5, shows an overviewof the interaction between the scenario-based programmingtool, Play-Engine [11], and a logic-based reasoning engine.The L2C2 tool, given an LSC-based model of a reactivesystem and a set of event sequences in a form of regular ex-pression, verifies the consistency of the LSC specificationby simulating the running LSCs in logic programming en-vironment. The L2C2 reasoning engine returns a truth valueas well as its justification, which provides evidences so thatPLAY-engine users can easily follow the evidences to re-establish the simulation scenarios in an interactive way. Weadopted a logic programming system due to its declarativity,strong symbolic reasoning capability, and automatic back-tracking.The transformation from LSC specification to Prolog

clauses adopts a semantics-based approach [8]. The LSCsconstructed in the PLAY-engine are saved as XML files,which are processed by an XML parser written in defi-nite clause grammars (DCGs) [1] in Prolog. A semanticmapping function is then defined to transform the parsingtree recursively to logic clauses and maintain their seman-tic equivalence. Both the parser and the semantic mappingfunction are encoded in Horn logic, which results in an ex-ecutable transformer directly.The testing language on external events is given by users

in the form of regular expression, which is automaticallytransformed into an executable right recursive productiongrammars in definite clauses to generate all possible testingevent sequences.The L2C2 utilizes a memoized depth-first traversal al-

gorithm on PLAY-trees to check whether the LSC model isconsistent over the language input specified in production

125

grammar. If the consistency is false, it returns a least prefixfailure trace as an evidence; while if the result is true, thenit actually returns a compact set of prefix traces along all thetraversed paths. For the example 1, the positive justificationwould be the set {λ, press1.press1, press1.msg1,press2.press2, press2.msg2}. The PLAY-engineusers can easily construct the simulation scenarios using thejustification evidence in an interactive way.

6 Conclusion

We have presented a new computational (operational) se-mantics of LSCs to show how a running LSC affects thesystem behaviors in response to a given regular languageof external messages. The semantics is defined in a formof PLAY-tree, where each branch corresponds to a possi-ble LSC run for a sequence of external message definedin the language. The consistency of an LSC specification,(Sys, Ls,G), is defined as whether there exists a corre-sponding PLAY-tree with all success branches. If such aPLAY-tree exists, then the specification is consistent; oth-erwise, a failure branch will exist in the PLAY-tree, and theinput messages along the failure branch correspond to a pre-fix of failure trace.As a result, the consistency checking of LSCs is basi-

cally an ordered traversal of the PLAY-tree. We have furtherpresented an efficient traversal algorithm using a memoizeddepth-first search strategy. The algorithm provides a com-putational scheme to show whether an LSC specification isconsistent to a given language of external messages, whichpotentially serve as a debugging and simulation tool for thescenario-based programming language LSC. In case of in-consistency, the algorithm will return a least prefix of a fail-ure trace. We believe that an executable LSC specificationas well as automatic simulation, debugging and consistencychecking capabilities will play important roles on designingtrustworthy software and hardware processes.

References

[1] Harvey Abramson: Definite Clause Translation Grammars.International Symposium on Logic Programming, pp. 233-240., 1984.

[2] J. Bohn, W. Damm, J. Klose, A. Moik, and H. Wittke: Mod-eling and validating train system applications using statem-ate and live sequence charts. The 6th Biennial World Confer-ence on Integrated Design and Process Technology, 2002.

[3] A. Bunker, G. Gopalakrishnan, and K. Slind: Live SequenceCharts Applied to Hardware Requirements Specification andVerification: A VCI Bus Interface Model. Software Tools forTechnology Transfer, 7(4):341–350, 2005.

[4] Y. Bontemps, P. Heymans: Turning high-level live sequencecharts into automata. Proceedings of Scenarios and State-Machines: Models, Algorithms, and Tools, 2002.

[5] Y. Bontemps, P. Heymans, H. Kugler: Applying LSCs tothe specification of an air traffic control system. Workshopon Scenarios and State Machines: Models, Algorithms andTools, 2003.

[6] P. Combes, D. Harel, and H. Kugler: Modeling and Ver-ification of a Telecommunication Application using LiveSequence Charts and the Play-Engine Tool. The 3rd Int.Symp. on Automated Technology for Verification and Analy-sis, 2008.

[7] Werner Damm and David Harel: LSCs: Breathing Life intoMessage Sequence Charts. Proc. 3rd IFIP Int. Conf. on For-mal Methods for Open Object-based Distributed Systems,pp. 293–312, 1999.

[8] G. Gupta, H-F. Guo, E. Pontelli, and A.I. Karshmer:Semantics-based Filting: Logic Programming’s Killer Ap-plication. Fourth Int. Symp. on Practical Application ofDeclarative Languages, pp. 80-97, 2002.

[9] David Harel: From Play-In Scenarios to Code: An Achiev-able Dream. Proc. Fundamental Approaches to SoftwareEngineering (FASE), pp. 22–34, 2000.

[10] David Harel and Hillel Kugler: Synthesizing State-basedobject systems from LSC specifications. Int. Journal ofFoundations of Computer Science, 13(1): 5–51, 2002.

[11] David Harel and Rami Marelly: Come, Let’s Play:Scenario-Based Programming Using LSCs and the Play-Engine. Springer-Verlag, 2003.

[12] D. Harel, S. Maoz, and I Segall: Some results on the ex-pressive power and complexity of LSCs. LNCS 4800, pp.351-366, 2008.

[13] H. Kugler, D. Harel, A. Pnueli, Y. Lu, and Y. Bontemps:Temporal logic for scenario-based specifications. In TACAS2005, pp. 445–460.

[14] R. Kumar and E. Mercer: Improving translation of live se-quence charts to temporal logic. Int. conf. on automatedverification of critical systems, pp. 183–197, 2007.

[15] R. Kumar and E. Mercer: Improving live sequence chart toautomata translation for verification. Electronic Communi-cations of the EASST, 2008.

[16] J. Klose, T. Toben, B. Westphal, and H. Wittke: Check ItOut: On the Efficient Formal Verification of Live SequenceCharts. 18th International Conference on Computer AidedVerification (CAV), pp. 219–233, 2006.

[17] Jun Sun and Jin Song Dong: Model checking live sequencecharts. The 10th IEEE int. conf. on Engineering of complexcomputer systems, 2005.

[18] T. Toben and B. Westphal: On the expressive power ofLSCs. The 32nd Conf. on Current Trends in Theory andPractice of Computer Science, pp. 33–43, 2006.

[19] The Object Management Group (OMG): Documentation ofthe Unified Modeling Language. http://www.omg.org.

[20] UML: Unified Modeling Languages Superstructure Spec-ification, v2.0. http://www.uml.org/, OMG specification,2005.

[21] Z.120 ITU-T Recommendation: Message Sequence Chart(MSC). ITU-T, 1996.

126