This paper compiles the results of our investigation ... âstate machineâ specification of behaviour. ... tems, answering the question is even more difficult. ...... practical help, for its power is high. (O(n5)). The translation process is rather straight-.
1
Relating Live Sequence Charts and State Machines: a Guided Tour Yves Bontemps, Patrick Heymans and Pierre-Yves Schobbens
differently to the first or the second occurrence of the same stimulus. Transformational systems, on the other hand, are stateless: they always output the same data when fed in with the same inputs. We focus on reactive distributed systems because (1) they are pervasive in our society, (2) their number and complexity increases rapidly and (3) humans are more and more dependent on them. For example, a simple cell phone executes a tremendous number of processes concurrently. As another example, the automotive industry is embedding ever more software into modern cars. Automotive software counts many highly-critical, real-time systems eg, braking assistance systems. In this sector, distribution is a matter of fact, conceptually and physically: several processors execute code in I. I NTRODUCTION parallel and components that are conceptually seen In [1], Harel proposed a novel way to engineer as separate can end up being mapped onto the reactive distributed systems, starting from user- same processor, thus sharing a common resource. oriented scenarios and progressively transforming Conversely, the same component can be deployed them to the level of executable code. Our inves- to different physical architectures, eg in another tigation concerns the theoretical feasibility of this car model, thus executing in parallel. Correcting flaws in reactive distributed systems is often very approach. We focus on reactive distributed systems. A expensive, sometimes prohibitive, in the case of distributed computer system is made of several hardware-implemented systems. Additionally, some components, executing concurrently and interacting systems might even not tolerate bugs at all if human with each other to solve some problem or carry lives are at stake. In a way, the problem of engineering reactive out some task of interest [2]. A reactive system, as opposed to a transformational system, is a com- distributed systems is a simple task. It amounts to puter system that “keeps an ongoing relationship “write executable code fulfilling the requirements” with its environment” [3]. While the purpose of a as shown in Fig. 1. Problems arise when there are transformational system is essentially to transform many such requirements, when they change over input data into output data, reactive systems interact time, when they are conflicting, not clearly stated, continuously with their environment. In response to . . . But this is true of any realistic development environmental stimuli, reactive systems adapt their endeavour. And, in the end, the engineer is left state, perform some action and get ready to react with the question: “does my code behave as it is to the next stimulus occurrence. Such systems have intended to?”. In the case of distributed reactive systheir state and reactions change as a result of this tems, answering the question is even more difficult. continuous interaction, that is, they may respond Understanding and assessing the global emergent behaviour of all those concurrent pieces of software FNRS Research Fellow and hardware is a tremendously difficult task. Abstract— The problem of relating inter-agent (or, intraobject) behaviour descriptions with scenario-based interobject behaviour models has recently focused much interest. This paper compiles the results of our investigation of this problem. As specification, we consider a simple variant of Live Sequence Charts (LSC), which belong to the broad family of Sequence Charts Languages (MSC, UML 2.0 Interaction Diagrams, ...). As intra-object specification, we consider a game-theoretic foundation, looking at agents as “strategies”. This encompasses the popular “state machine” specification of behaviour. We consider two kinds of relationships: synthesis and verification. We present the theoretical stage, which highlights that these problems are intrinsically difficult and put these in perspective by presenting some practical approaches and an implementation.
2
models to executable code. Model-code associations should then be kept, to ensure that generated code can be traced back to its corresponding design element. Being an abstraction of the actual code, it is no wonder that a design model inherits many of its properties. Of course, implementation- and architecture-related parts have been forgotten but a design model is still component-centric and complete. For every component of the system, it has Fig. 1. One big leap to describe its entire behaviour (how it should act in every possible situation). We will thus say that Moreover, executable code is, by definition, pol- this model is intra-agent, as it considers every luted by implementation details. Those details are component separately. We use here the term agent not necessary to understand the logics behind it. under its Latin meaning, i.e. “an acting entity”. In Code is also component-centric: because compo- this document, we consider it a generalization of, nents are distributed, every component needs to have and therefore interchangeable with “component”, its own executable code, which fully describes its “sub-system”, “process” or “object”. Now, relying on this intra-agent abstract model, behaviour. Different parts of the system may also can we be sure that the actual system fulfills user be written in different languages or even be implemented as hardware. This is a further impediment to requirements? Not really. There is still a huge gap comprehension. Finally, the same “logical” system between user requirements and design models. Accan be mapped onto different physical architectures, tually, users do not spontaneously think in terms of intra-agent specifications. They cannot state, even as already mentioned above. in natural language, what the complete behaviour of the future system should be. Studies have shown that users feel more comfortable using scenarios, i.e. partial concrete stories of the future system [5]. It seems that users tend to express their requirements more naturally as examples. The entity that is meaningful to the user is the overall system, which, as we know, is composed of many parts. They give a few samples of execution that they consider are representative. Those executions are not focused on a single agent. When dealing with distributed Fig. 2. Introducing Design Models systems, a story will involve several agents and cross their borders. Such a story, or scenario, is thus In order to understand reactive distributed sys- said to be a inter-agent representation. For instance, tems, instead of using executable code, engineers the following user statement is, in our terminology, often resort to an abstraction of it. OMG’s Model- a scenario: “I engage cruise control by pressing the Driven Architecture (MDA) initiative calls such an SET button. A green light flashes on the dashboard abstraction a “platform-independent model” (PIM) for five seconds and remains lit. Then, when I push [4]. This abstraction is a design model, tailored on the brake pedal, cruise control is disengaged, for human understanding. It ignores implementa- the car brakes and the green light turns off.” This tion details and only presents the control logic of scenario involves several agents (SET button, cruise every component, preferrably in an architecture- control, green light, brake pedal, . . . ) and is partial, independent way. Taking away useless details, the as it does not tell about all the other situations system appears in a much simpler form that one can that may happen when cruise control is engaged. read and, hopefully, better understand. Furthermore, It also overlaps with other scenarios, eg scenarios tools exist to automatically translate these high-level talking about ABS or automatic door-locking sytem,
3
although those scenarios also share brake pedal interactions. To summarize, we observe that the gap to bridge between requirements and design models is caused by two paradigm shifts. First, engineers have to move from a partial and overlapping description of the system to a complete behavioural specification. Second, a transition from the inter-agent to the intraagent perspective must be done. When these two changes take place at once, mistakes are very likely to be introduced: some examples will be wrongly generalized and/or not correctly distributed among agents.
that inter-agent specifications should be tested for implementability: if the specification is inconsistent, i.e. imposes conflicting requirements on the system, those should be detected and no implementation must be synthesized. Third, both models are likely to evolve on their own. New requirements will be added to the specification and, in parallel, the design model will become more detailed. After some time, it is interesting to check whether the design model still complies with the specification, i.e. that the requirements are still met. This approach has been suggested by Harel [1] and is illustrated by Fig. 4.
Fig. 4. Fig. 3.
Inter-Agent Specification narrows the gap
In order to narrow this gap, we propose to apply the well-known “divide and conquer” strategy to proceed more progressively, see Fig. 3. First, we build a complete behavioural specification, using an inter-agent specification language. Second, this inter-agent specification is transformed into an intraagent design model. Of course, this does not remove all risks of building the wrong system (or building the system wrong), for no technique could ever fully remove this risk. But, it is meant to make the development more reliable by help engineer master a well-know source of errors. If one provides an automated translation from inter-agent specifications to intra-agent specifications, risk will be even more decreased. No mistake can be introduced by the transition from specification to design model, provided the translator software has been proven correct. This proof can be done once and for all, by experts, and remove the burden of verification from engineers. There are several links that need to be automated. First, the inter-agent specification should be tested, in order to check that it fulfills the users’ intent. Second, intra-agent design models should be derived from the inter-agent specifications. This implies
Full development
in order to support this approach, the following issues need to be addressed, : • A scenario-based inter-agent formal specification language needs to be defined. We propose to use Live Sequence Charts (LSCs) [6]. This language has been later substantially extended [7] but we focus on a simple part of the original version, named Constant LSCs in [7]. • The various links between specification and design models need to be formalised. In particular, what it means for an intra-agent to “correctly implement” an inter-agent specification needs to be clearly defined. • The feasibility of these links must be assessed. When feasible, algorithms supporting the links must be developed and implemented. This is basically what this paper has to offer. It compiles the results of an extensive investigation of these issues, which took place over the last three and a half years. Our object of study is a fully formalised scenario-based synthesis and verification framework, proposed to address the challenges discussed above. The framework is an attempt to incarnate David Harel’s initial vision of an ideal scenariobased software development approach [1]. This vision is the one that we have depicted throughout the introduction. In his paper, Harel gives intuitive
4
arguments towards the achievability of his “dream”, as we did so far. The results that will be presented in the sequel of this paper are mathematical evidence that some ways to make the dream real are simply impracticable. This, as will explain, is due to the high computational complexity or the undecidability of the problems to be solved. Indeed, a series of synthesis and verification problems have been studied, under various hypotheses, but the verdict, as we will show, has always turned out to be tough. Far from being a negative result, or questionning Harel’s vision, our contributions more accurately indicate what are the kinds of solutions that do not work and what are the kinds that are more likely to contribute to make the dream a reality. To emphasize this, this paper presents a lot of related work about LSCs and insists on approaches that have been sucessful. The paper is structured as follows. In Sec.II, we briefly introdude the formal notations used. Section III explains how the behaviour of reactive distributed systems can be specified using scenarios, first, considering MSCs (Sec.III-A) and then presenting the more expressive language of LSCs. In Section IV, we present the various models involved in the engineering process of Fig.4: the structural specification (Sec.IV-A), the inter-agent specification (Sec.IV-B), the intra-agent specification (Sec.IV-C). We also determine what it means for an intra-agent specification to be a correct implementation of an inter-agent specification (Sec.IVD). This sets the stage for our investigation of of Harel’s vision. Relying on these notions, we therefore analyze the various problems involved in the process of Fig.4 (Sec.V). For each problem, we provide an asymptotically optimal algorithm and survey the literature in relation to it. In Sec.VI, we discuss our results. In Sec.VII, we investigate the impact of extending our version of LSC with several elements, viz. conditions (Sec.VII-A), realtime (Sec.VII-B) and symbolic instances (Sec.VIIC). Section VIII presents our implementation of some algorithms related to Harel’s vision. Finally, we conclude and sketch several open problems in Sec.IX.
. The set of all finite words over Σ is denoted by Σ∗ . A language over Σ is a set L ⊆ Σ∗ . The concatenation of two words v and w will be denoted vw. We say that u is a prefix of w (u v w) if there is some word v such that uv = w. If v is non-empty, u is a strict prefix of w and we write it u < w. Projecting a word v ∈ Σ∗ over an alphabet A ⊆ Σ, written v|A discards from v all symbols not in A. Formally, it is the word obtained by applying the following recursive rule: |A = and, for e ∈ / A, ue|A = u|A e and, for e ∈ A, u|A . An infinite word over Σ is an infinite sequence of symbols from Σ. We denote by Σω the set of all infinite words over Σ. III. S CENARIO - BASED S PECIFICATION In this section, we look for an adequate interagent, formal, scenario-based specification language. We first consider Message Sequence Charts (MSC), on the grounds of their popularity but we underline some of their shortcomings that make them unsuitable for our purpose. We then present the language of Live Sequence Charts (LSC), an extension of MSC that precisely addresses these shortcomings.
A. Message Sequence Charts Message Sequence Charts (MSCs) are a popular formalism for describing scenarios. They have been standardized by the ITU [8] and are also found in the UML, where they are called Interaction Diagrams [9]. A Message Sequence Chart displays the various agents involved in the scenario as “lifelines”, i.e. vertical lines labeled by the agent name. For instance, the MSC of Fig.5, for a coffee dispensing machine, describes a scenario involving four agents: a customer, an interface, a controller and a cup dispenser. These agents interact by sending messages to each other, which are represented as arrows. The scenario of Fig.5 reads naturally as “when the customer inserts a coin and selects coffee, the interface tells the controller that coffee has been ordered and makes a light blink. The controller prepares coffee and notifies the interface when it is ready. The light is turned on and the customer II. N OTATIONS takes the cup from the dispenser.” In this section, we briefly introduce our notations. An MSC describes a partial order between events, A word over an alphabet Σ is a sequence of symbols according to the following rule: an event may occur e1 . . . en , with ei ∈ Σ. The empty word is denoted if all events higher up on the same lifeline already
5
happened. This introduces concurrency between • MSCs offer no syntactic means to distinguish events. For instance, in Fig.5, events “light blink” between universal rules and examples. and “prep coffee” are not ordered and may occur in We will now go through these points in detail. any order. A first precision we would like to make is that, by itself, the language is not bad. No language ever is. But, for our particular usage, namely specifying the behaviour of distributed reactive systems, they would not be the best choice. The ITU recommendation on MSCs states explicitly that they describe “partial behaviour”. Sensu stricto, MSCs can therefore specify sets of examples only. However, specifying the behaviour of a reactive system does not amount to listing a set of examples. A specification should draw a clear line between admissible and inadmissible behaviour. Non-toy systems embed an infinity of (virtual) executions. Fig. 5. Message Sequence Chart One cannot expect to describe this infinite set of executions as a finite set of examples. MSC features composition operators that make it possible to describe complex scenarios from basic ones. Typical control flow operators, such as concatenation, choice, unbounded loop (Kleene’s star) and interleaving are provided. There are two ways of using these operators: inline expressions and HighLevel Message Sequence Charts (hMSC). In the former, boxes containing MSCs are included in the MSC. In the latter, a graph whose nodes contain MSCs presents all possible sequences of MSCs. Fig. 6. Message Sequence Chart Despite its graphical appeal, confirmed by a wide popularity, the language has, in our opinion, five Of course, one could resort to hMSCs or inline major shortcomings that make it unsuitable for our loops for representing an infinite set of executions purpose: as a finite model. Thus, analysts would have to build •
•
•
•
The semantics of MSC is weak and aims at describing execution samples only. This is very different from specifying the expected behaviour of the future system. Composition of MSCs causes a enormous amount of extra work to be carried out by the engineer. This is because the semantics of MSCs is silent about the meaning of a set of scenarios, i.e. how the requirements they impose on the future system shall be composed. MSCs miss syntactic constructs to express the scope of a scenario, i.e. whether events not appearing in this scenario can occur at will or are forbidden by their mere absence. MSCs do not distinguish between events that trigger the scenario and events that occur in response to this activation, even though this is a usual implicit distinction in scenarios.
a single integrated behavioural model. We observe that it is simply impossible to use several hMSCs to model this behaviour, because the ITU definition is completely silent about the meaning of a set of hMSCs. Nothing is said about how several scenarios shall be composed. A likely attempt is through union (of execution sets), but this is not different from a single hMSC with a top-most choice node. Consider the scenarios of Fig. 5 and 6. The scenario of Fig. 6 details the procedure to be followed in order to prepare coffee. It reads as: “when the controller decides to prepare coffee, it shall ask the cup dispenser to prepare a cup and the tank to get water. It then asks the cup dispenser to add coffee to the cup and the water tank pours water in the cup. The tank notifies the controller when it is done.” Clearly, this procedure must be inserted between “prep coffee” and “ready”, in Fig. 5. If one resorts
6
to union, this is clearly not what is going to happen: the two scenarios will not overlap and compose as expected. Building an integrated model hence requires finding out all relationships between individual scenarios, factoring and merging them. But, in this case, hMSCs do not support a scenario-based approach to specification. A major interest of the scenariobased paradigm is, we think, to proceed from scenarios, i.e. (almost) independent, small and concrete requirements chunks, and get the most out of them through composition. This allows one to cope with the well-known problem of “requirements creep”: when customers come up with a fresh requirement, this new scenario is simply thrown in the “big bag of requirements”, extending the specification to cope with these new wishes. Of course, it is possible to refine by hand the large hMSC model but this requires considering the whole “specification” each time, to find all the places in which the new requirement must be inserted. Consequently, one is left with two alternatives: (1) either use sets of hMSCs or bMSCs to describe behaviour samples, benefit from a true scenariobased approach but lose the ability to specify the future system behaviour, or (2) use a global model, in the form of a hMSC to specify behaviour, but lose (nearly) all benefits of scenarios. Actually, the problem is even worse if one refers to the intent of analysts. Sometimes, they want to write down a possible behaviour of the future system, for the sake of explanation. Sometimes, they are more assertive and want to describe a reaction of the system to a certain stimulus. For example, the scenario of Fig.5 was drawn with the intent of describing a general rule about the coffee machine: whenever the customer inserts a coin and asks for coffee, the subsequent scenario shall take place. Some scenarios instead represent executions sample, as suggested by the ITU standard. When an MSC describes a universal rule, messages can have different statuses. Some of them activate the scenario while others are responses to these stimuli. For instance, in Fig.5, events “insert coin” and “select coffee” activate the scenario, while the other events are “responses”. We close this discussion by highlighting that MSCs are not syntactically equipped to express their scope. The scope of a scenario is the set of events that are relevant to this scenario. Consider fig.5 and
an event “money back”, meaning that the interface return the customer’s coin. Clearly, this event may not occur while the scenario is executing, as it would mean that the customer would get his coffee and his money back. This event is thus relevant to the scenario. However, some other events which do not appear may be allowed to occur. For instance, an event sent to notify that the water level is getting low (“low level”) may occur while the scenario is executing. This is orthogonal to what is described in Fig.5. Thus, one is unable to state whether events not appearing explicitly in a scenario may occur while the scenario is executing or whether they are forbidden by their mere absence. In an attempt to tackle these problems, the OMG has substantially extended the language of MSC in the UML 2.0 [9], where they are called Interaction Diagrams. The semantic domain of Interaction Diagram is a couple of sets of executions. When considering one of these couples, eg (G, B), G is the set of “good executions”, i.e. positive examples, and B is the set of “bad executions”, i.e. counter-examples. G and B must be disjoint but not necessarily cover the universe of executions. Therefore, there are some executions about which it is not known whether they are good or bad. Those are called inconclusive. Interaction Diagrams introduce new composition operators, named “restrict”, “ignore”, “assert” and “neg”. The first two operators specify the scope of a scenario, by adding/removing events from its scope. The “assert” operator means that only the traces described in the diagram are good; all other traces are bad. The “neg” operator means that the described traces are counter-examples. However, the UML standard is ambiguous about the meaning of these operators. The semantics of these operators is only defined with respect to good scenarios. The interpretation of negation is ambiguous as demonstrated in [10]. Furthermore, we showed that, under some reasonable assumptions, it is undecidable whether an Interaction Diagram is consistent, i.e. good and bad executions do not overlap [11]. Given all the above reasons, we conclude that MSCs are not suitable for the specification of reactive distributed systems. However, MSCs are nowadays the most popular scenario language. They are at the root of a whole family tree of languages, viz. sequence chart languages. To provide a realistic alternative to MSCs, we need to maintain the appeal of the language. Hence, the goal to be as con-
7
servative as possible concerning syntax. Semantics, on the other hand, needs to be more thoroughly reshaped. The adopted solution is now presented. B. Live Sequence Charts In order to address these shortcomings, Damm and Harel introduced Live Sequence Charts (LSC), an extension of Message Sequence Charts [6]. This language has been extended later on in [7]. In this paper, we focus on a simple version of LSC, named Constant LSC in [7]. 1) Basic Charts: LSCs are built from basic charts. MSCs, like those presented in Fig. 5 and 6, are basic charts. Like MSCs, Basic Charts can also be composed using inline expressions. As control flow operators, we allow strong concatenation, nondeterministic choice and interleaving, but we forbid unbounded loops. The semantics of a basic chart B is a set of executions L (B). Executions are generated by successively marking locations (arrows) in B. An arrow a involving lifelines l1 and l2 and labeled by e may be marked when all arrows touching l1 and all arrows touching l2 that are drawn higher up than a have already been marked. The fact of marking a produces its labeling event e. An execution is a sequence of events produced by successively marking all locations in B from the empty marking. The set of all executions of a basic chart B is called its “language” and is denoted L (B) ⊆ Σ∗ . 2) Existential and Universal Charts: Basic charts do not solve the problems of MSCs. In order to address these issues, we follow Damm and Harel [6] and add syntactic constructs. First, Live Sequence Charts (LSCs) are given a scope which consists of all events occurring in the chart, plus additional events that are listed in a special “restricts” clause. Events that are not in the LSC scope may occur at will. Second, LSCs are decorated with a modality. An LSC can be existential or universal. An existential LSC (ELSC) is a basic chart, surrounded by a dashed-line rectangle, that describes a possible execution of the future system (Fig.7). Abstractly, we represent an ELSC as ♦(B, ΣR ), where B is a basic chart and ΣR is the scope of the ELSC. A universal LSC (ULSC), as presented in Fig.8, is made of two superimposed basic charts. The upper one is surrounded by a dashed-line hexagon and named
prechart. The lower one is called main chart and is surrounded by a solid-line rectangle. This makes it possible to distinguish between activation events, i.e. the prechart, and response events, i.e. the main chart. The semantics of a universal LSC (ULSC) is “whenever the prechart occurs in an execution, the main chart shall follow”. We will write ULSCs as (P, M, ΣR ) with P and M being basic charts. P is the prechart, M , the main chart and ΣR is the scope of the LSC, i.e. all events appearing in P or M , plus additional events specified by the “restricts” clause.
Fig. 7.
Existential LSC
We are interested in reactive systems, which are not supposed to stop. Abstractly, we consider an execution of a reactive system as a sequence of observed events. Like linear temporal logics (LTL), LSC are thus interpreted against infinite words. We write γ |= L to denote that γ is a legal execution with respect to L and define this relation as follows Definition 1 (|= ⊂ Σω × LSC): An infinite word γ ∈ Σω satisfies an LSC L, written γ |= L iff one of the two following constraints holds: • L = (P, M, ΣR ) and for every decomposition upγ 0 of γ, if p|ΣR ∈ L (P ), then there is a decomposition mγ 00 of γ 0 such that m|ΣR ∈ L (M ). • L = ♦(B, ΣR ) and there is a decomposition uvγ 0 of γ such that v|ΣR ∈ L (B). An LSC L defines the language L (L) = {γ ∈ Σω |γ |= L}. A set of executions Γ ⊆ Σω satisfies an LSC L, which we denote Γ |= L, iff • L = (P, M, ΣR ) and Γ ⊆ L (L). • L = ♦(B, ΣR ) and Γ ∩ L (L) 6= ∅. ULSCs are a real specification formalism. They draw a clear border-line between legal and illegal
8
behaviours. An execution is illegal if, at some point set by every ULSC of which it consists: in it, the prechart is matched but is not followed by n \ the main chart. The set of all legal executions with L ({L1 , ..., Ln }) = L (Li ). respect to a ULSC L is L (L), the language defined i=1 by L. Composition is semantic. It is impossible to conjunct a ULSC-Spec into a single ULSC [12]. IV. M ODELS In this section, we present the abstract models that are used in Fig. 4. So far, we have only presented the language of LSCs, but we also need a language for describing the structure of the system to be built and the behaviour of these components.
Fig. 8.
Universal Live Sequence Chart
As said previously, in scenario-based software engineering, we are interested in gathering scenarios from several stakeholders and put them together in a “big bag of requirements”. This set is deemed a specification and the semantics of the language will take care of how these bits of requirements shall be composed.
Fig. 9.
ULSC “‘return money”
Definition 2 (ULSC-Spec): A ULSC specification (ULSC-Spec) is a finite set of ULSCs. Conjunction is our composition operator, hence providing ULSC-Spec with a semantics. A ULSCSpec is a set of ULSCs. Intuitively, every ULSC corresponds to one requirement about the future system. Every ULSC constrains the behaviour of the future system by obliging the main chart to be observed after every occurrence of the prechart. A specification, i.e. a set of ULSCs, obliges all executions of the future system to match the constraints
A. Structure The structural view of the system provides a static view of it. It lists the various agents and shows what events they trigger (send) or sense (receive). Definition 3 (System Structure): A system structure (in abstract syntax) is a tuple hAg, (Σsa )a∈Ag , (Σra )a∈Ag , Sysi , where • Ag is a finite set of agent names. s • Σa gives, for every agent, the events that it sends. These sets are disjoint, as two agents may not control the same event. r • Σa is the set of events received by agent a. Again, these sets must be disjoint. • Sys ⊆ Ag is the set of system agents. All agents 4 not in Sys are called environment agents: Env = Ag \ Sys. We let the set that S S of alls events be Σ and require r r s a∈Ag Σa = a∈Ag Σa = Σ. We let Σa = Σa ∪ Σa . In the rest of this section, we will refer to this structure and assume that it is fixed.
Fig. 10.
Structure Diagram
9
Concretely, a system structure is specified thanks to diagrams, as shown in Fig. 10. The notation we use here can be replaced by any other kinds of diagrams able to present all the information found in system structures, such as context diagrams [13], object diagrams or component diagrams [9]. We use our own notation for the sake of simplicity. Agents are drawn as boxes, in which their name is written. Ag is the set of all names appearing in boxes. System agents have their name underlined. Identifier i1
Events light blink, light on, light off, money insert coin, select coffee, claim money ready coffee ordered take cup prepare cup, add coffee get water pour water empty fill
Definition 4 (Inter-agent specification): An inter-agent specification is a couple hS, Ui , with S being a system structure and U a ULSCSpec, over alphabet Σ. It is required that only agents from Ag take part in U and that they respect their interfaces, i.e. an arrow from agent a1 to a2 may only be labeled by events from Σsa1 ∩ Σra2 . C. Intra-Agent Behaviour
The system structure specifies which agents belong to the system (Sys) and which agents are i2 part of their environment (Env). Engineers are only asked to build an implementation of Sys agents. i3 They will later be deployed among and interact i4 with Env agents. The system to be built is open: i5 engineers have no control on Env agent may do. The i6 system structure also tells what every agent can do. i7 These abilities should be rendered in the behavioural i8 specification of agents. i9 i10 We consider abstractly agents as “reactive (sub)systems”. A reactive system keeps an ongoing TABLE I relationship with its environment. It reacts to enviI NTERFACE DEFINITION ronment inputs (stimuli) by producing outputs (responses). This reaction may be history-dependent: In order to describe Σ, we use interfaces. An a system may provide different responses to the interface is a circle, with an identifier. In a separate same stimulus, because different events have been table, this identifier is expanded as a list of event observed in the past. Definition 5 (Strategy): Our abstract view of an names, see Tab. I. An arrow from agent a1 to agent ∗ Σs a2 , going through interface I, means that a1 may agent a is a strategy f : Σ → 2 a . A strategy f represents the behaviour of an agent. send all events in I to a2 . The events sent by a1 ∗ s (Σa1 ) are simply all the events sent by a1 to any For every possible history w ∈ Σ , f (w) is the set of all possible responses proposed by a. Conversely, other agent. after w, a decides to disable all events in Σsa \ f (w). This abstraction highlights that every agent has powers: it can make some events happen, because B. Inter-Agent Behaviour they are under its control. Other events, which are Inter-agent behaviour is specified thanks to Live beyond its control, cannot be handled or constrained Sequence Charts. Every piece of textual require- by this agent. Thus, a single agent cannot force ments gets translated and generalized to some to nor prevent its environment from performing an ULSC. These ULSCs are then gathered in a ULSC- action. A strategy for a therefore generates a set of Spec. As ULSCs come with a pre-built notion runs: all the executions in which events controlled of scenario integration, through conjunction, they by a only appear when they are enabled by fa . form a consistent whole, specifying the desirable Definition 6 (Outcome): The outcome of a stratbehaviours of the future system. egy fa is the set of all runs in which Σsa events Of course, there are syntactic requirements, in appear only according to the strategy: Out(f ) = order to be sure that an LSC specification complies {u0 e0 u1 e1 . . . |∀i ≥ 0 : ui ∈ (Σ \ Σsa )∗ and ei ∈ with a given structure. f (u0 e0 . . . ui )}.
10
Agents can be organized in societies. We have to explain how their behaviour can be composed. A society is a set of agents A ⊆ Ag. Its sent (resp. received) events are the union of all events sent (resp. received) by itsS composing agents: ΣsA = S s r r a∈A Σa and ΣA = a∈A Σa . The strategy of A is also the S union of the strategies of its agents: fA (w) = a∈A fa (w). Definition 7 (Intra-Agent Specification): An intra-agent specification is a couple hS, fSys i , where S is a system structure and fSys is a strategy for society Sys. Although this model is very appealing from a mathematical point of view, we will sometimes have to focus on strategies which are representable within computers. We use the notion of input/output automata for this purpose [14]. Our intra-agent specification formalism encompasses the popular state machine formalism. An input-output automaton for agent a ∈ Ag is a finite automaton, the alphabet of which is Σa . A distinction is made between input events (Σra ) and output events (Σsa ). Syntactically, an I/O automaton for agent a must be input-enabled: in every state q, agent a should have one transition labeled by every input event. In other words, a may never block incoming events. This fulfills our desire to model agents powers, as explained above. A finite state I/O automaton represents a finitememory strategy for agent a. Formally, a (nondeterministic) strategy for agent a is a function s f : Σ∗ → 2(Σa ) . It is of finite memory if there is an equivalence relation ' on Σ∗ such that (1) ∀w ' w0 : ∀a ∈ Σ : wa ' w0 a, (2) ' is of finite index and (3) ∀w ' w0 : f (w) = f (w0 ). The size of the memory is the index of the smallest such equivalence relation. Clearly, every finite memory strategy can be translated to an I/O automaton. Conversely, every I/O automaton can be turned into a strategy. D. Relating Inter-Agent and Intra-Agent Specifications In order to define the automated links between our artifacts, we must tell when an intra-agent specification is correct with respect to an inter-agent specification. As a first attempt, one could resort
to trace inclusion, i.e. require all the executions generated by the intra-agent specification to be legal behaviours, with respect to the LSC specification. Formally, given hS, Ui and hS, fSys i, Out(fSys ) ⊆ L (U). However, this definition causes a mismatch between powers and responsibilities. Since system agents only control some events, they shall not be responsible for errors due to the occurrence of events they do not control. We illustrate this situation with an example. Consider the ULSC of Fig.8 and the partial execution “insert coin, select coffee, coffee ordered, light blink”. This execution matches the prechart and partially matches the main chart. What happens if, at this point, “money” occurs? The specification is violated, since “money” is restricted but is not one of the next events. This error is attributable to the system, as it controls “money” and thus decided to give money back when it was not allowed. Now, in the same configuration, what happens if the customer takes his cup (take cup)? Again, the specification is violated, as “take cup” is not one of the next events. An intra-agent specification allowing such an execution would therefore be classified as incorrect, according to trace inclusion. However, this sounds rather unfair, as violation was not due to the system but to an inadequate action taken by the customer. Therefore, the system shall not be held responsible for this situation. We consider a last example. Assume that, still in the same configuration, “prep coffee, ready, light on” occur. The new configuration of the ULSC requires “take cup” to occur, in order to complete the main chart. What if the customer walks away and never takes his cup? The specification is violated, as the main chart will never be matched, but the system is not responsible for this situation. As a matter of fact, the two kinds of violations that have been introduced in this example suffice to capture the semantics of ULSC: if, along a run γ, every agent ensures that its controlled events do not occur when they are forbidden but that they eventually occur when they are required to, then γ will satisfy the ULSC [15]. This is good news, as it makes it possible to share responsibilities along with powers. For some set of events V ⊆ Σ, we will say that an execution is V -safe if no event in V occurs when it is forbidden. It is V -live if every event in V eventually occurs when it is required. We formalize these notions.
11
Definition 8 (Forbids - Safe): Consider a word w ∈ Σ∗ . We say that it forbids some event e ∈ ΣR iff there is a decomposition upv of w such that 1) p ∈ L (P ) 2) ∀m v v : m ∈ / L (M ), 3) @v 0 : vev 0 ∈ L (M ). An infinite run γ is e-safe iff, for every uv < γ, if v forbids e, then uve 6< γ. Definition 9 (Requires - Live): A word w ∈ Σ∗ requires an event e ∈ ΣR iff there is a decomposition upv of w such that 1) p ∈ L (P ), 2) ∀m v v : m ∈ / L (M ), 3) ∃v 00 : vev 00 ∈ L (M ). An infinite run γ is e-live iff, for every uv < γ, if v requires e, then there is w ∈ Σ∗ and e0 ∈ ΣR such that uvwe0 < γ. These constraints, which are given event-byevent, are equivalent to the semantics of ULSCs. Theorem 1 (ULSC = safe + live): For every γ ∈ ω Σ and every ULSC S = (P, M, ΣR ),
the tools implementing the development process of Fig.4 shall do and how they can do it. Tools supporting the development cycle of Fig.4 shall offer three functionalities: ELSC checking, synthesis and verification. In this section, we will study each of these functionalities. For each of them, we first specify precisely the functionality, then provide an algorithm implementing it and finally study its computational complexity. We also review existing work on LSCs related to each functionality. This provides a structured panorama of current research on Live Sequence Charts.
A. ELSC Checking ELSC checking will be used by engineers when they are deriving an inter-agent specification from user-provided samples of behaviour, here described as ELSCs. They constrain the future system’s behaviour by adding more and more rules. Every new universal LSC restricts a little bit more the set of possible executions of the future system. At some point, it makes sense to check that the specification γ |= S ⇐⇒ ∀e ∈ ΣR : γ is e-safe and e-live is not too restrictive, that original ELSCs from In the spirit of Jackson [16], [13], we can state which the specification has been derived are still that an intra-agent specification is correct if, for allowed by this specification. If it is not, engineers every well-behaving environment, the system also need to relax the behaviour. behaves correctly. Assumptions on the environment Definition 11 (ELSC Checking): The ELSC behaviour are made explicit and the correctness Checking decision problem is specified as of an implementation depends crucially on these • Input: assumptions. – An inter-agent specification hS, Ui Definition 10 (Correct Implementation): An – An ELSC ♦(M, ΣR ) intra-agent specification (S, fSys ) associated • Output: to a society of agents Sys is a correct – yes, if L (U) |= ♦(M, ΣR ), implementation of an inter-agent specification – no, otherwise (S, U) iff ∀γ ∈ Out(fSys ), these two constraints There is an automata-theoretic algorithm solving hold: this problem. The ULSC-Spec can be translated s s • γ is ΣEnv -live =⇒ γ is ΣSys -live. to a deterministic B¨uchi automaton AU such that s s • γ is ΣEnv -safe =⇒ γ is ΣSys -safe. L (AU ) = L (U) [12]. The ELSC can be turned into an LTL formula ϕ¬♦(M,ΣR ) which asserts that V. A NALYSIS P ROBLEMS M is never matched [17]. Then, a model checker The previous sections have set the stage for is used to verify that ϕ¬M does not hold in AU . the description of our round-trip automated ap- If a counter-example is found, it means that there proach described in Fig.4. We have described what is a run satisfying the ELSC and provides us with scenario-based inter-agent specification language such a witness. This algorithm can be implemented we have chosen, namely ULSC. We have precisely to perform an on-the-fly search, hence avoiding to defined what inter-agent and intra-agent specifica- build completely AU before searching for a satistions are. We also related them, through the concept fying path. One can show that this algorithm is in of “correct implementation”. Therefore, we can now PSPACE. In [18], we have shown that this problem turn to the last step: specifying precisely what is PSPACE-complete.
12
– no, if hS, Ui has no correct implementation. This problem is different from satisfiability. Satisfiability simply asks whether L (U) is nonempty, or, in other words, whether there is a benevolent environment in which some implementation can be deployed, in order to fulfill the specification. Synthesis asks whether there is an implementation that is correct, be it deployed in any malevolent environment. As an example, consider a ULSCSpec made of the ULSCs of Fig 8 and Fig.9. This specification is satisfiable. To see this, consider an implementation that always returns money to the customer and a customer that repeatedly inserts a coin and claims his money back. When put together, they clearly satisfy the specification, as they never activate the ULSC of Fig.8 but only activate and fulfill the ULSC of Fig.9. However, there is no correct implementation of this particular ULSC-Spec. It suffices to consider a customer that inserts a coin, asks for coffee and claims his money back. We remark that both precharts are matched. This sequence of events is unavoidable, as they are environment-controlled and thus cannot be prevented by an implementation. The main chart of Fig.8 obliges any implementation to serve coffee and ultimately perform a “coffee” event, but without returning money. The main chart B. Synthesis of Fig.9 does the reverse: it obliges any implemen1) Centralized Synthesis: When engineers are tation to return money and to not serve coffee. It is satisfied with their requirement specification, they therefore impossible to implement this ULSC-Spec, have to design an intra-agent specification of the because there exists one environment that can drive system. Currently, this is a manual operation: an- any implementation to a state in which it will have alysts have to consider the whole specification, to violate the specification. We somehow contributed to the confusion befocus on a single agent and write down a statemachine implementation for it. This tedious and tween these two problems in [20]. What we called error-prone process can be automated thanks to “consistency” in [20] was actually “satisfiability” synthesis. Synthesis is not a simple compilation and the problem we named “synthesis” corresponds problem; technically, it is a constructive proof that to “extracting a witness of satisfiability”. In comparthe specification is implementable, that it does not ison, in [21], Harel and Kugler solve the problem of “synthesis”, which they define as verifying that an contain any conflicting requirements. Definition 12 (Synthesis): The synthesis problem LSC specification is “consistent”. Their definition of “consistency” and “synthesis” correspond to the is more complicated and really interesting problem we • Input: are considering in this section. We will come back – An inter-agent specification hS, Ui, to their solution later on. • Output: Notice that the synthesis problem is very lenient – some intra-agent specification hS, fSys i regarding outputs. It does not put any constraints which is a correct implementation of on the form of the intra-agent specification that can hS, Ui, be output. It is simply a strategy, i.e. a function Theorem 2: ELSC checking is PSPACEcomplete. In principles, ELSC checking is thus intractable. This problem is actually closely related to the “smart play-out” approach, by Kugler, Harel, Marelly and Pnueli [19]. Play-out is an interactive technique for executing LSC specifications. It proceeds in turns: the user performs some action on a Graphical User Interface (GUI). This action may complete the prechart of some ULSCs, hence activating them. The play-out engine computes a superstep, i.e. a sequence of system events leading to a state in which system agents are not required to perform any event anymore. Due to nondeterminism in the ULSC specification, there may be several possible supersteps, but some of them can lead to deadlock or divergence (infinite supersteps). The basic play-out engine arbitrarily explores a single superstep, hence possibly running into problems. The smart play-out approach uses model checking to compute a valid superstep if it exists. Computing valid supersteps is reducible to use case checking of ULSC specifications. Hence, smart play-out is also a difficult problem. Practically, this process seems valuable and applicable, and preliminary results indicate that it scales up quite well.
13
fSys : Σ∗ → 2ΣSys . This function could even be noncomputable. However, there is a nice result in the field of infinite games, that we can reuse: in infinite games with an ω-regular winning condition, if there is a winning strategy, there is a finite-memory winning strategy. Since, as we will explain shortly, a correct implementation is a winning strategy in a two-player game, we can rephrase this result as: if there is a correct implementation, there is a correct implementation representable as an I/O automaton” In [15], we present a game-theoretic algorithm solving the synthesis problem. It reduces synthesis to solving a two-player game [22]. We sketch this solution. Two deterministic B¨uchi automata are built, ASys and AEnv . Aj recognizes all runs that are Σsj -safe and Σsj -live, for j ∈ {Env, Sys}. Intuitively, AEnv accepts all executions in which the environment is well-behaving, whereas ASys does the same for the system. Then, we define the following game, between two players, Env and Sys. The game starts in the initial state of both automata: player Env picks some sequence of environment-controlled events w ∈ (ΣsEnv )∗ from ΣEnv . Both automata read w synchronously, which leads to some state (q0 , q1 ). In that state, player Sys chooses one of its events e ∈ ΣsSys , which is read by both automata, leading to (q00 , q10 ). From this state, a new turn is played. If the game has to stop because some player chose a move for which there is no transition in his automaton, this player loses the game, as he violated its safety condition. If the game goes on forever, it is won by player 0 (the protagonist) if either it visits only finitely often an accepting state of AEnv , i.e. the environment did not behave properly in the run, or it visits infinitely often an accepting state of ASys , which means that the system behaved correctly. This winning condition is a Streett condition, consisting of only one pair. Such a game can be effectively solved using standard game-theoretic algorithms, see [22]. In [15], we reduced it to a three-colour parity game. This algorithm runs in time exponential in the size of the specification. The automata AEnv and ASys are both exponential in the size of the specification. So is their product. Solving the game is done in time quadratic in the size of these automata. We showed that this algorithm was asymptotically optimal [18]. Theorem 3: Synthesis is EXPTIME-complete. Another solution to this problem is provided by Harel and Kugler [21]. They deal with very sim-
ple LSCs: precharts contain only one environment message (∈ Ain ) and main charts contain only system messages (∈ Aout ). They choose the superstep approach of [23]: the environment provides one input and the system answers with a sequence of output messages: (Ain A∗out )ω . They show that realizability is equivalent to a consistency condition. This condition asserts the existence of a nonempty regular language L ⊆ (Ain A∗out )∗ such that 1) L contains one execution for every existential chart, 2) L satisfies all universal charts, 3) for every w ∈ L and every a ∈ Ain , there is some r ∈ A∗out such that war ∈ L. 4) for every xyz ∈ L such that y ∈ Ain , x ∈ L. They build a minimal deterministic automaton recognizing the intersection of universal LSCs and progressively prune it to remove “bad states”, i.e. states that do not satisfy condition (3). The resulting automaton can then be transformed to some strategy automaton. Our solution is an extension of their work. Firstly, we tackle the problem for more general LSCs, allowing choice constructs, complex precharts and environment messages in the main chart. The latter extension enabled us to use LSCs in assume/guarantee development of reactive systems. Secondly, instead of relying on an ad-hoc technique, we proposed a reduction to parity games, for which a range of results and algorithms is available. Currently, experimental results are negative. We are not able to synthesize systems from large interagent specifications. This is probably due to the fact that the prototype implemenation that we will present in Sec. VIII is poor. We could improve internal data structures and resort to techniques such as partial order reduction [24] or symbolic synthesis [25], [26]. This is still an important direction for future research and synthesis could “like verification, turn out to be theoretically difficult, but practically feasible”, to paraphrase [1]. 2) Distributed Synthesis: Notice that the synthesis problem is too general to match exactly the intuitive functionality named “synthesis” in Fig.4. The development process suggested in Sec.I suggests that a distributed intra-agent specification must be automatically built from a given inter-agent specification. The “synthesis” problem that we considered before simply asked whether a global implementation existed, with perfect information about its environment. We are more interested in distributed intra-
14
agent specifications, i.e. every system agent must have its own strategy determining its behaviour and this strategy may only look at events visible by this agent, as prescribed by the structural specification. Definition 13 (Distributed): An intra-agent specification hS, fSys i is distributed if fSys is the composition of a set of strategies {fa }a∈Sys , one for each system agent, such that for every fa s 1) fa : Σ∗ → 2Σa ; 2) ∀w, w0 ∈ Σ∗ : w|Σa = w0 |Σa =⇒ fa (w) = fa (w0 ), i.e. if w and w0 are the same, from a’s point of view, then a shall behave the same way after w or w0 ; Distributed synthesis is defined like synthesis, except that its outputs are restricted to distributed intra-agent specifications. Definition 14 (Distributed Synthesis): The Distributed Synthesis problem is • Input: – An inter-agent specification hS, Ui, • Output: – some distributed intra-agent specification hS, fSys i which is a correct implementation of hS, Ui, – no, if hS, Ui has no correct implementation. This problem is at the core of the software engineering process presented in Fig.4. It turns out that it is actually undecidable. There is thus no algorithm building a distributed implementation of an LSC specification if it exists, or refusing to do so if there is no such implementation. The “synthesis” arrow in Fig.4 is a broken link! Theorem 4: Distributed Synthesis is undecidable. Proof: We reduce Post’s Correspondence Problem (PCP) to Distributed Synthesis, following [27]. We first recall the definition of PCP. A PCP instance is a list of pairs of words (w1 , u1 ) , . . . , (wn , un ), such that, for all i, wi 6= ui and wi , ui ∈ Θ∗ (for some finite alphabet Θ). A solution to a PCP instance is a finite sequence of indexes i1 . . . im (m ≥ 1 and 1 ≤ ij ≤ n, for all j) such that wi1 wi2 . . . wim = ui1 ui2 . . . uim . The problem of telling whether any PCP instance admits a solution or not is undecidable. Let us fix an arbitrary PCP instance. We show how to reduce the problem of determining whether this PCP instance admits a solution to DOAD.
The alphabet of our LSC specification is Θ ∪ {k1 , . . . , kn } ∪ {$} ∪ {0, 1} ∪ {A0 , A1 }, plus an arbitrary finite number of events that can be exchanged between system agents, say {s0 , . . . , sq }. The system is made of two agents: a1 and a2 . The first agent may observe Θ ∪ {$}, whereas the second can observe {k1 , . . . , km , $}. All these events, but {A0 , A1 } and the additional system events {s0 , . . . sk } are controlled by the environment. A play proceeds as follows. First, the environment picks either 0 or 1. The former means that the environment chooses to read words in the first component of the pairs of words (viz. the wi ’s), the latter means that it will read ui ’s. Then, the environment must stick to that choice until the end of the play. Namely, the environment chooses a particular word in the list (say, wi or ui , depending on the “column” chosen) and indicates the index of this word to the system, by performing ki . The environment must then enumerate the letters in wi , which are thus published to agent a1 . The game goes on until the environment performs $. At this point, the system is required to output A0 or A1 , depending on what index (0 or 1) the environment had chosen in the first place. We claim that the PCP instance has a solution iff this specification is not implementable. Assume that PCP has a solution i1 . . . im but there is a winning strategy for the system. Then, upon 0i1 w1 . . . im wm $, the system answers with 0. Nevertheless, the strategy of the system shall also answer 0 to 1i1 ui . . . im um $, because the projection of the two words on agent’s alphabets are the same. Therefore, there is no winning strategy. If PCP has no solution, then, the two system agents can get together and compare the submitted run. Agent a2 sends the sequence of indexes that it has been presented with to a1 (using some protocol on which they agreed, based on {s0 , . . . , sp }). This agent can then build wi1 . . . wim and compare it with the word that he has received from the environment. Since PCP has no solution, either they are the same and a1 shall answer 0 or the two words differ and a1 replies with 1. Distributed synthesis is still liberal about its outputs, as it allows strategies with infinite memory. This fact was used in the proof above: if the PCP has no solution, system players use a strategy with infinite memory to win. However, restricting the problem to strategies representable as I/O automata
15
does not make it decidable. The finite-state case is undecidable, but requires a reduction from Turing machine halting. The infinite state case is highly undecidable [28]. By putting additional restrictions on the kinds of structural specification allowed, decidability can be reclaimed. Rosner and Pnueli showed this for pipeline architectures and special cases of connected architectures [29]. Kupferman and Vardi considered other styles of architectures such as cycles and also obtained decidability results [30]. Gastin et al. consider asynchronous games played over traces and obtain decidability results for recognizable trace languages, when allowing players to use causal memory [31]. However, these decision procedures are nonelementary. Madhusudan and Thiagarajan give sufficient conditions to obtain decidability of distributed synthesis [32]. In general, it seems that trace-closure of the specification is a crucial point, i.e. the inter-agent specification may not force two actions independently performed at two different points across the network to be ordered. ULSC-Spec are not trace-closed, because the fact of matching the prechart imposes a strong synchronization point between all instances. Another way to dodge undecidability is by devising incomplete algorithms. These are algorithms that sometimes find distributed implementations but that may fail to find one, even though it exists. The “compile-verify” has been followed by some researchers. The essential idea is to apply a predefined implementation scheme to the inter-agent specification, i.e. to compile it to a distributed intraagent specification, and then, to use model checking techniques to verify that this implementation is correct. We instantiated this generic technique in [33], [34] and we added an additional “refinement” step. This algorithm builds iteratively a local strategy for each system agent. First, ULSCs are projected onto the agent a that we want to synthesize. Then, a strategy is built according to the following rule: it proposes an action e if e is required by some scenario but not forbidden by any other scenario (according to the knowledge of a). The resulting implementation is certainly safe but may not be live. A model checker is used to verify its liveness, which then guarantees that the distributed implementation is correct. If it is not live, we use a game-based algorithm to look for a live refinement of this implementation. Harel, Kugler and Pnueli
also proposed a “compile-verify” algorithm [35]. They generate a statechart design from a ULSC specification and then model check it to ensure its correctness. The main advantage of their approach is that they use orthogonal regions in statecharts to encode the concurrent executions of the various ULSCs. This makes the generated statecharts more readable, as it avoids an exponential blow-up in the number of states. In order to cope with undecidability, one can also build a centralized intra-agent specification and then, try to distribute it. In [21], Harel and Kugler propose three strategies to distribute intraagent specifications, 1) build a central controller, driving the execution of the individual agents; 2) duplicate the central controller in every agent; 3) duplicate the central controller and remove states that are not relevant to the object in question. One can also add new broadcast messages to synchronize the various agents on prechart completion, etc. Using this technique, Sun and Dong build a CSP process from an LSC specification and use algebraic group laws to obtain a distributed implementation [36]. From what we understood of their article, it seems that they deal with closed systems and do not allow overlapping executions of the same chart. They are thus studying the problem of “satisfiability” instead of “synthesis”. Finally, one can add constraints to ensure implementability. Homme and Ramsland survey several techniques for implementing ULSCs: play-out, statechart synthesis following [21] and direct code generation [37]. They propose an algorithm for deriving Java code directly from ULSCs, but this algorithm only works under very strong assumptions on the given ULSC (no user input, messages invoking methods must refer precisely to the instance it is called on, all messages in the main chart must originate from the instance that received the prechart message, there may not be two scenarios with the same prechart). Under these assumptions, the ULSC-Spec is always implementable and the generated intra-agent specification is correct. C. Verification The design model, be it built automatically or manually, will often be modified by engineers. The
16
specification is likely to be updated after the design model has been built, too. This phenomenon is known in Requirements Engineering as “requirements creep”: during the life of a software project, new requirements are discovered and must be integrated to the software product [38]. As a matter of fact, the two artifacts, specification and design, will grow independently. Nevertheless, ultimately, the design model will have to comply with the requirements. Therefore, engineers need tools that will help them verify this compliance. Definition 15 (Verification): The verification problem is Input: – An inter-agent specification hS, Ui, – An intra-agent specification hS, fSys i, with fSys represented as I/O automata. • Output: – yes, if hS, fSys i is a correct implementation of hS, Ui. – no, otherwise. The verification problem is to check that an intra-agent specification is a correct implementation of an inter-agent specification. We will consider several variants of this problem. The most general case considers that the society Sys consists of at least one agent, and that there might be agents out of Sys interacting with them. We will investigate “degenerated” versions, along the following axes: •
1) Sys consists of a single agent or several agents (viz. centralized vs distributed agent verification); 2) Env is empty or not (viz. closed vs open agent verification). The complexity of these problems is summarized in Tab.II. All these problems can be solved using the classical automata-theoretic approach to model checking [39]. I/O automata representing fSys are conjoined into a single I/O automaton A. An automaton AU recognizing all counter-examples of the inter-agent specification, i.e. runs that are ΣsEnv safe but not ΣsSys -safe or ΣsEnv -live but not ΣsSys -live, can also be extracted, see [12]. This automaton is nondeterministic. It suffices to check that A × AU has some accepting run to decide whether the intraagent specification is correct or not. Notice that searching accepting runs can be done on-the-fly [40].
In the case of closed verification, the algorithm can be simplified. Since there is no environment agent, the correct implementation condition boils down to checking that all runs are Σ-safe and Σlive. By theorem 1, this is equivalent to verifying that the intra-agent specification respects the constraints of all scenarios. The algorithm can thus verify iteratively that the intra-agent satisfies each scenario. So, instead of building a big AU automaton, a series of small automata can be built and verified. This approach benefits from the fact that such automata are very simple and is reflected by the “lower” complexity of this problem in Tab.II. The automaton waits for some arbitrary time in its initial state and nondeterministically guesses to recognize a counter example. Then, it checks that the prechart is matched and is not followed by the main chart. Such counter-examples are short: they contain as many states as there are events in the ULSC. Besides the blow-up occurring when computing the product of I/O automata, the only problem in verification of closed system actually comes from the width of automata: because ULSC are based on partial orders, there can be exponentially many paths to explore, even though each of them is short. In practice, scenario-based specifications tend to be linearly ordered and hence, have relatively small automata, which makes them amenable to automated verification. The problem of LSC-based verification of closed systems has been considered in the literature. Klose et al. follow the approach outlined above and adapt it to LSC with time information: they turn each ULSC in the specification to a timed automaton recognizing all counter-examples [41], [42], [43]. Kugler et al. propose to translate USLC to temporal logic formulae that can readily be input to model checkers. Since ULSC can be translated to both CTL and LTL, a large number of existing model checkers can be reused [17]. In closed verification, the analyst must come up with an intra-agent model of every agent, including environment agents. In open verification, some agents belong to the environment, while others are system agents. Environment agents are not explicitly modeled. Then, we are presented with an intra-agent specification model of system agents only and the question becomes: “whenever environment agents do behave correctly, does this implementation behave appropriately?”.
17
This problem is “harder” than closed model checking because we cannot check the specification against each ULSC individually. Verification must be restricted to runs that are ΣEnv -live and ΣEnv -safe. This property is not local to a single scenario but involves all scenarios simultaneously. Klose studies open verification in his PhD thesis [44]. He remarks, as we do it here, that ULSCs can embed hypotheses about the environment as well as commitments about the future system behaviour. He gives an algorithm for extracting assumptions and dealing with them explicitly. Brill et al. use this technique and explain how LSCs and verification can be integrated in V-software development cycles [45]. The problem of model checking open systems has been considered by Vardi, Kupferman and Wolper, too. They name it module checking [46]. They show that, in the case of linear-time specification, the problem is not more difficult than model checking. Distributed No Yes No Yes
Open No No Yes Yes
Complete for coNP PSPACE PSPACE PSPACE
TABLE II V ERIFICATION C OMPLEXITY
Verification seems to be impractical, for its complexity is far above what is considered tractable. There are nevertheless many success stories in automated verification. Model checking has shown that, despite its high theoretical complexity, it could be applied to real-world cases [47]. This situation applies also to the more restricted field of LSCbased verification. Klose et al. report on the successful use of model-checkers to verify Statemate models against Live Sequence Charts [43], [42], [44]. In general, Damm and colleagues are accumulating positive results in LSC-based verification. Bunker and Gopalakrishnan have verified hardware bus protocols models [48]. Bontemps and Kugler checked a model of Ricart-Agrawala algorithm for mutual exclusion against LSCs [49]. Those preliminary results seem to indicate that, although intraagent are computationally hard to verify, modern verification techniques do scale up and there is some reasonable hope that this problem could be practically addressed.
VI. D ISCUSSION We have set up a completely formalized framework for the round-trip engineering process proposed by Harel in [1]. This obliged us to address several issues. We start the discussion of these results by sketching our approach. We believe our methodology is very clean and could be reused in other contexts related to transformational approaches to software engineering, such as the MDA. We certainly do not claim it to be especially original; the only original aspect is in applying sound and formal mathematical principles to the often too informal field of graphical modeling languages. First, an inter-agent scenario-based specification language has to be chosen and formally defined. We decided to base our work on the language of Live Sequence Charts, a simple extension of Message Sequence Charts that leverages the power of MSCs to specify real-world complex reactive distributed systems. As demonstrated in [12], LSCs are much less expressive than automata and temporal logics, but their expressiveness is sufficient to model realworld reactive systems, such as NASA’s Center TRACON Automation System. Second, the modeling languages used to specify inter- and intra-agent behaviour have to be formally defined. In order to provide models with a consistent “vocabulary”, a structure specification language is also defined. Inter-agent behaviour is specified thanks to LSC. Intra-agent behaviour is described using strategies. The formalism of strategies is adequate for describing reactive systems as it provides us with a simple representation of the choices made by agents. It also makes the distinction between the events controlled by an agent and the events controlled by its environment, therefore accounting for openness. Having modeling languages for describing behaviour, from inter-agent and intra-agent perspectives, one also need to tell precisely when an intra-agent specification correctly implements an inter-agent specification. We followed Jackson’s approach: the inter-agent specification describes assumptions on the environment and constraints on the future system. A correct implementation is an intra-agent specification that ensures that the interagent specification will be respected, provided environment agents behave as stated in the hypothesis of the specification. Third, relying on the relationship between mod-
18
els that was previously built, the transformational problems of Fig.4 must be defined. This definition of problems is abstract; it is a specification. Then, algorithms solving these problems can be given and proven correct. In our case, most of these algorithms rely on translations of ULSC to automata and temporal logic. The reader shall remark that we spent serious efforts defining and formalizing modeling languages and relationships between models. However, this effort paid off, as defining problems became straightforward. Essentially, synthesis amounts to asking whether a correct implementation of an interagent specification exists and verification whether an intra-agent model is a correct implementation of a specification. Then, the solution of these problems could also be presented and proven correct. The main benefit for the reader is that he can actually understand the essence of our algorithms without having to dwelve into the details of our automataand game-theoretic constructions. For short, he can grasp what the tools do without having to know how they do it. This goes beyond existing work on synthesis of scenarios from state machines. In most cases, authors present an algorithm “synthesizing state machines from scenarios”, without ever stating what relationship they expect to hold between the intraagent specification and the inter-agent specification. This does not make it possible to prove the correctness or optimality of their algorithms. This also obliges the reader to carefully study algorithms in order to understand what they are intended to do. In our cases, analysis problems are first-class citizens and objects of study. We can prove the correctness of algorithms, study their complexity and show them to be optimal. We can also criticize our problem definitions, providing relaxed definitions such as mercifulness [15] or partial algorithms [34]. In the literature, the term “synthesis” has been broadly used, to denote different kinds of problems. In the field of formal languages and temporal logics, the “synthesis” problem is well defined, since the late 80s. It is the same problem that we are considering here: building a implementation that will preserve a specification against any malevolent environment [50], [51], [30], [52], [53], [22], [54], [55]. Before this, some authors treated the problem of synthesis of closed systems, which is synonymous to satisfiability [56], [57].
In the realm of scenarios, the meaning of “synthesis” is somewhat vaguer, as the problem is always left undefined and only algorithms are discussed. Previous research on scenario-based “synthesis” extended in two directions: induction and compilation. These approaches find their justification, depending on the purpose of the scenarios and the phase of the software life cycle in which it is used [58], [5]. 1) Induction. Typically, scenarios are considered as a partial view on the behavior of the future system. A set of scenarios is thus a finite set of example computations. The problem is to induce, from these examples, a universal rule describing every acceptable behavior of the system. The user has some (regular) set of behaviors W in mind and gives a finite set of examples E ⊆ W . We are asked to build an automaton A recognizing W . [59] have used an algorithm, due to Biermann and Krishnaswamy [60], which computes the “best” deterministic AE . At the limit, the language of the synthesized automata converges to W . Practically, this automaton needs to be checked, in order to ensure that it does not contain inappropriate behaviors. It has been integrated to the CASE tool FUJABA (From UML to Java and Back Again) and validated on a case study from manufacturing industry [61]. Minimal Adequate Synthesizer (MAS) is an interactive approach to machine learning from synthesizer which is based on the Minimal Adequate Teacher paradigm. MAS finds missing scenarios in the set of scenarios and asks its operator whether such scenarios should be integrated in the specification or not. It has been implemented by Koskimies and Syst¨a [62] and validated on the “Paderborn NewRail Technology” Shuttle case study [63]. Hsia et al. use example scenarios, given as an execution tree, to build a grammar and analyze the specification, wrt consistency criteria, using automata analysis techniques [64]. By hand, they produce, from such a set of examples, a prototype of the future system. This prototype can then be used to validate the specification with the end-user. 2) Compilation. Scenarios can also be seen as a complete description of the future system.
19
Thus, the desired behavior W equals the given traces E. This is especially useful if the system to be built is closed. Then, state machines must be built from the various scenarios, projecting them onto every instance [65], [66], [67], [68], [69]. The main problem that arises then is that there might be some discrepancies between the global view of the behavior, induced by the scenario and the local view that every instance has of this behavior. When recomposing the full system from the individual state machines, yielding a set of behaviors C, it might be that C ⊃ W . These additional scenarios, C \ W , are called “implied scenarios” [68]. Techniques have been developed to detect such implied scenarios and report on them [70], [68]. In [71], the authors give syntactical restrictions, namely causality, which ensures that MSCs, with control flow constructs, such as iteration or choice, can be distributed, i.e. that the liveness/safety constraints imposed by lifelines match the global constraint stated by the considered MSC. One result, which is in spirit close to ours, is due to Desharnais et al. [72], except that their setting is state-oriented, whereas most researchers on scenarios, including us, focused on an event-based setting. In [72], the authors present a way to represent scenarios as a relation between states. This presentation can be graphical, thanks to relational transition systems. They make a distinction between environment moves and system moves, allowing moves “within” the environment and “within” the system, as we do it. A scenario is assumed to describe possible environment inputs and all legal system reactions. The authors propose an operator for integrating scenarios, based on the “demonic meet” operator. Like in our work, the integration of two scenarios relative to the same input obliges the system to answer as specified by both scenarios. VII. E XTENSIONS A. Conditions So far, we have considered our systems as being purely event-based. This can be the right abstraction
for designing interacting reactive systems. However, in some situations, it is natural to express behavioural constraints that depend on state-based conditions. For instance, in the coffee dispensing example, an additional scenario saying that “when there is no more coffee in the machine and the user selects coffee, his money is returned” uses a statebased condition. In LSCs, conditions can be used to refer to states. Thus, in addition to events, it is also possible to constrain the possible system behaviours thanks to conditions. The original language made a distinction between two modes of conditions: hot conditions and cold conditions. Hot conditions must be true in order to be traversed whereas a cold condition may be false, forcing the execution to abort prematurely but successfully. In [7], the authors discuss several possible design choices as to when conditions should be evaluated. When the execution reaches a condition, there are three possibilities: evaluate the condition immediately, wait for some “random” amount of time before evaluating it, or wait until the condition becomes true. They took the following decision, with respect to the operational semantics of LSCs, as implemented by the play-out engine: cold conditions are evaluated as soon as possible whereas the animator waits until hot conditions become true. The former decision is justified on the grounds of the fact that users find it more intuitive. The latter decision is simply considered “easy”. It is true that, in the framework of play-out, evaluating a hot condition to false leads to an irremediable error and execution must be halted abruptly. However, our interest is on the use of LSCs as a behaviour specification language. As such, it must be able to draw a hard line between allowed and forbidden behaviours. Having said that, bad executions are at least as interesting for us as good executions are. Thus, we do not want to rule out or try to avoid the possibility of hot conditions being evaluated to false. Therefore, in [12], we proposed to consider two types of conditions in addition to the usual hot/cold distinction: ASAP conditions and eventual conditions. The former are going to be evaluated as soon as possible and the latter will be eventually evaluated. We underline the fact that ASAP means “as soon as the location labeled by the considered condition is enabled, i.e. all its predecessors have
20
and events, against FSP (Finite State Processes) which are purely event-based [73]. Let F be a countable set of fluent names. A fluent formula is simply a propositional logic formula, defined over F. We denote this logic with B(F) (boolean combinations of fluents). ϕ ::= p (with p ∈ F) | ¬ϕ1 | ϕ1 ∨ ϕ2 Fig. 11.
ULSC with conditions
been reached” while, by eventual, we mean “as soon as (i) all the predecessors have been reached and (ii) the condition becomes true”. The latter definition will thus oblige the condition to be matched without delay, thus eliminating nondeterminism regarding conditions. We oblige cold conditions to be ASAP. We are still backwards-compatible with the decisions taken by Harel and Marelly in [7]. When adding conditions to our specification language, we need to have some way to relate observable sequences of events to variable values. We do this generically using state functions. Letting valuations be I, a state function is a function mapping every possible history to a valuation of variables: f : Σ∗ → I. In the play-out mechanism, the condition language is made of conjunctions of basic boolean functions over some primitive data type. Typically, comparisons between integers and equality between other data types is supported. These properties evolve because of the occurrence of events. The user defines what special events set the value of each property. We will follow a similar idea. Of course, in order to keep properties decidable, we will restrict ourselves to finite data type. Actually, we limit ourselves to propositional logic. The basic propositions will be fluents [73]. A fluent is a proposition which is associated to two sets of events: setting and unsetting events. When a setting event occurs, the fluent becomes true and remains true until an unsetting event happens. Then, it becomes and remains false until the next setting event occurs. Fluents have proved their value for adding statebased notions to event-based models. For instance, a model-checker has been developed for LTSA, which allows one to verify LTL formulae that mix fluents
An interpretation is a function i : F → {>, ⊥}, that assigns a truth value to every fluent. Thus, in the case of fluents, I = F → {>, ⊥}. Definition 16 (Fluent Specification): A fluent specification is a triple of functions hFluentin , Fluenton , Fluentoff i, with Fluentin : F → {>, ⊥}, Fluenton : F → 2Σ and Fluentoff : F → 2Σ . Given a fluent specification F S = hFluentin , Fluenton , Fluentoff i, we need to define a state function ζF S . It is defined recursively as ζF S () = Fluentin and ζF S (wa) = {x 7→ upd(x, ζF S (w)(x), a)|x ∈ F} where upd(x, t, a) returns • >, if t = > and a ∈ / Fluentoff (x); • ⊥, if t = ⊥ and a ∈ / Fluenton (x); • ¬t, otherwise. There are two things that are worth mentioning. First, introducing conditions alters only the lowest level of our definitions (basic charts). Once the semantics of basic charts is modified to take conditions into account, the semantics of LSC does not differ from what was presented in Sec.III-B. Second, the complexity of all analysis problems presented in Sec.V is not modified by adding conditions with fluents. Even further, the algorithms translating ULSC to temporal logic and synthesizing centralized intra-agent specifications are almost not altered by this extension. In summary, one can really include conditions for free in ULSCs. B. Real-Time Scenarios can also be used to describe the behaviour of timed systems. Graphically, a timed LSC is displayed in Fig. 12. It enforces that, if no answer is received from the database within 120 seconds (time units) the client informs the communication manager that its download failed. This LSC obliges the client to answer “no” after at least 120 seconds
21
but sets no upper limit on the time at which a “yes” answer will be sent. This form of LSC is the same as in [74], [7]. Note that, instead of clock resets, assignments are used to freeze time, i.e. store the current time in a real-valued variable. Atomic constraints are of the form x ∼ Time + k where x is a clock name, k is a rational number and ∼∈ {≤, t. One of the actions chosen to be performed at time t0 is nondeterministically picked and executed. Then, a new turn is played at time t0 [75], [76]. This scheme allows players to reconsider their choice at every turn. A correct implementation in this setting is one that makes the assumption that the environment can always preempt its move. In the untimed case, it corresponds exactly to our view of strategies presented in Sec.IV-C: the environment can input any finite sequence of events before the system may react. Third, the relationship between inter- and intraagent specifications, i.e. the notion of correct implementation, must be adapted. In this case, it is straightforward, as timing constraints only add new safety conditions. Therefore, a slight update of the safety/liveness theorem suffice. Fourth, we have to provide algorithms coping with real-time. We follow an automata-theoretic approach and rely on the usual reduction to region automata for solving timed problems [77], [76]. Details are provided in [12]. The complexity of these algorithms does not increase, except for closed verification, which becomes PSPACE-complete instead of coNP-complete. In summary, real-time can easily be added to ULSCs, regarding definitions as well as algorithms. C. Symbolic LSC
Fig. 12.
Real-Time ULSC
Adding real-time requires several modifications to our setting. First, we need to consider real-time inter-agent specifications. We resort to real-time ULSCs as presented in the previous paragraph. As explained above, basic charts are extended with realtime. As was the case for conditions, only the lowest
ULSCs, as we presented them here, are only suitable for specifying the behaviour of a finite, fixed population of agents. However, in practice, many systems contain an unbounded number of agents and we would like to specify them generically using ULSCs. The immediate solution to this problem is to replace concrete agent names in lifelines by variables, typed by an agent class. A lifeline can then stand for any agent of this class. Such a lifeline is called symbolic, as it symbolically represents a
22
set of instances. This solution was proposed by Klose and Westphal [78]. Independently, Harel and Marelly proposed a solution tailored for play-out and added quantifiers on symbolic instances [7], [79].
inter-agent specifications using a textual language. The tool supports the following functionalities, as illustrated by the screenshot of Fig.14. •
•
•
•
Fig. 13.
Symbolic LSC
Fig.13 shows an example of a symbolic ULSC, with instance quantifiers. Dotted lines represent existentially quantified instances, whereas solid-line rectangles represent universally quantified instances. Existentially quantified instances are bound to one actual instance at run-time while, for universally quantified symbolic instances, a new copy of the scenario is spawned for every actual instance. Binding constraints are added to symbolic instances, in order to restrict the instances that can be bound at run-time. We formalized this extension in [12] and showed that one of the most basic problem, viz. satisfiability, becomes undecidable. It thus breaks our previous results. However, it is still useful in practice. We modeled NASA’s CTAS system with symbolic ULSC. It turned out to be very intuittive [80]. Damm and Westphal discuss an algorithm for verifying object systems with an unbounded number of instances against symbolic ULSC [81]. Their algorithm makes use of symmetry reduction to cope with the potentially infinite state space. VIII. I MPLEMENTATION We have implemented a set of algorithms into a tool named REMoRDS (Requirements Engineering and Modeling of Reactive Distributed Systems). REMoRDS is written in Java. Analysts can describe
•
Syntax check: Checking that the specification is syntactically correct. This includes interface correctness: agents may only send/receive messages as specified in the structural part of the specification. Animation: Executes the specification, according to Marelly and Harel’s play-out algorithm. Centralized Synthesis: This follows the algorithm presented in Sec.V-B, without mercifulness. REMoRDS features an animator to provide feedback on the result. Incomplete Distributed Synthesis: This is the “compile-verify” algorithm of [34] that we briefly described in Section V-B.2 [33], [34]. If REMoRDS finds a distributed implementation for some agent, it generates an FSP (Finite State Process) description of this implementation that can be used in LTSA (Labeled Transition System Analyzer) [82], [73]. LTL formula generation: For every scenario in the specification, REMoRDS generates an LTL formula that can be inserted in an FSP model and model checked in LTSA.
In the remainder of this session, we go through a sample session of scenario-based distributed reactive system analysis with REMoRDS.
Fig. 14.
REMoRDS: Main functionalities
23
A. Model Edition Analysts first have to write a model of the reactive distributed system that they are planning to analyze. We did not provide a graphical editor for LSCs, hence, analysts must translate their LSCs manually to our input language, called LPO (Labeled Partial Order). This model is made of three parts: 1) A structural part that presents the various agent classes, what events they send, to what other agents, what classes belong to the system and the list of agents that will be involved in the behavioral part. Every agent is assigned a class. This part corresponds to the structural view described in Sec.IV-A. 2) A fluent specification that introduces the list of fluents used in the scenarios, with their initial values and their activating/deactivating events, see Sec.16. 3) An inter-Agent specification, which is made of a list of scenarios. A scenario is simply a labeled partial order, in which some distinguished locations constitute a prechart. A special event, start can be used in the prechart, to describe scenarios occurring only at the beginning of the run. start is an artificial event that is fired once, at the beginning of every execution. REMoRDS features a simple text editor to write models. This makes it possible to directly edit the model within the tool, save it and parse it. REMoRDS’s syntax checker is a standard compiler. It has been built using JavaCup [83] and JFLex [84]. B. Animation When the analyst’s model has been written, translated to LPO, loaded in REMoRDS and succesfully parsed, its structure is displayed in the left pane of the editor area, see Fig.14. Agents are grouped by classes. Scenarios and fluents are also displayed. The analyst can easily browse the model by clicking any node in the tree. When a scenario is selected in the browser, one can visualize it as a ULSC in the “Visualizer” tab of the editor area, as shown in Fig.15. Since there are scenarios in LPO without any equivalent ULSC, the visualizer may display incorrect ULSC. However, in most cases, the analyzer will first have modeled the system of interest with ULSCs on paper and afterwards, have translated it to LPO. In that case,
the displayed ULSC is correct, i.e. is equivalent to the one from which the LPO was derived. When the analyst is happy with his model, he can start analysing it. A first step in analysis is executing the model. We implemented Harel and Marelly’s play-out algorithm in REMoRDS. Our animator is pretty straightforward. Its user interface is illustrated in Fig.16. It is made of two main areas: a “history area” (Fig.16) and a “current state area” (Fig.17). The history area displays the current trace while the current state area shows the partial executions of all ULSCs. The history area displays the animation history in two modes. On the left-hand side, the execution tree is displayed. The nodes of this tree are labeled by the states through which the execution passed and the various branches that were followed. The current state is underlined. When a state that was already encountered is visited again, the execution “jumps up” in the tree to that state and all nodes that are labeled by this state are underlined. When a choice is made, a new branch of the tree is created, along which the execution goes on. On the right-hand side, the current trace, i.e. the path from the root of the tree to the current node, is shown as an MSC-like drawing. Two points are noteworthy. First, this MSC does not follow the usual semantics of MSC, as the vertical position of two events determine whether they should be ordered. Second, stuttering, i.e. “do nothing” events are removed, to avoid cluttering the figure. A lower pane also shows what events are required in the current state. It also lists events that must be delayed in the current state, i.e. those that are both required and forbidden. This simple diagnoser therefore hints at possibly conflicting scenarios. In order to exploit this information, the analyst can visualize all the cuts reached in the current state, by going to the “current state area” (Fig.17). There, all the cuts linearized by some suffix of the current execution are listed. When a cut is selected, the ULSC is drawn in the right-hand side panel and the events that belong to the cut, i.e. those that have already occurred in the current execution, are highlighted, as illustrated by Fig.17. If the analyst wants to explore alternative paths, he can double-click any node in the execution tree and jump to this node. The interaction loop is simple: at every step, REMoRDS lists all environment-controlled events
24
Fig. 15.
REMoRDS: Visualizer
Fig. 16.
REMoRDS: Animator (History area)
that are not forbidden in the current state. The analyst is then asked to choose from one of them and to tell whether he would like the system to answer immediately to this stimulus or to input another environment-controlled event beforehand. If the system is allowed to answer, he picks some event that is required and not forbidden, performs it and then waits for new input from the analyst. Clearly, our animator is very primitive. It lacks many features that can be found in the play-out
engine, such as linking the animator with a mockup GUI of the future system [7], or in the AlbertII animation engine, like cooperative animation [85]. However, it is already very helpful to explain counter-examples and experiment with specifications. C. Centralized Synthesis When the analyst has written a syntactically correct model and has played around with it to remove
25
Fig. 17.
REMoRDS: Animator (Current state area)
some possible flaws, he can use the “synthesis” algorithm to ensure that his specification is implementable. The “synthesis” functionality implements the algorithm presented in Section V-B. This algorithm works in two steps. First, it builds a one-pair Streett automaton from which a three-colour parity game graph is constructed. Second, the parity game is solved. We implemented the first part in Java. For the second part, we call a C implementation of V¨oge and Jurdzinski’s algorithm for solving parity games [86]. The result is then read back to extract a strategy. Since the strategy cannot be displayed, because it is too large to be readable, we have implemented an animator to provide the analyst with feedback. This relies on an important theorem of two-player infinite games: the two-player game underlying the problem of implementability is determined [87], [22]. Thus, either the system has a strategy implementing correctly the specification or its environment has a strategy, called here “sabotage plan”, against which the system will never be able to respect the specification. Thus, whatever the system does against a sabotage plan, the resulting execution will violate the condition of Def. 10. In the former case, the animator assumes the role of the system under development while the analyst plays the environment. The analyst can choose
Fig. 18.
REMoRDS: Inconsistent specification
among environment-controlled events and watch the system respond according to the synthesized strategy. If the specification is not implementable, a strategy for the environment is synthesized, see Fig.18. In the animation process, roles are now swapped: the analyst plays the future system and the animator assumes the role of its environment. Then, the animator demonstrates that the specification is not consistent by letting the analyst choose system
26
actions and providing answers driving the system to violate the specification. Our animator has been presented in Sec.VIIIB. We remark that the animation produces not a single trace of events but a tree. This is the essential difference between model checking of linear time properties and a game-based approach, like ours. A counter-example is not a single trace of events, but a tree, the branches of which correspond to choices of the human operator. To every choice, the animator replies in such a way that the specification will always be met (implementable specification) or that will force the operator to eventually violate it (sabotage plan). Our animator supports backtracking; by clicking on a tree node, the operator can go back to this choice node, make another choice and create another sub-tree. Identical nodes, which are roots of isomorphic sub-trees, are identified. This avoids generating very large execution trees. REMoRDS’ synthesizer also works in a progressive fashion. It does not attempt to build the whole game graph immediately but rather constructs an abstract version of it. It explores the game graph up to a user-specified depth and width. Then, all states on the frontier of this zone, which have thus not yet been expanded are considered correct for the system. If a sabotage plan can be found on this smaller graph, the whole implementation is not realizable. Furthermore, the sabotage plan is a correct counter-example. The synthesizer also tries the other combination, by letting the system lose on frontier states. Then, if an implementation can be synthesized on the abstract game graph, it is a correct implementation of the whole specification. In the case of CTAS, we were unable to synthesize an implementation on a pentium III 800Mhz computer with 256Mb RAM. REMoRDS ran out of memory after about 15 minutes and consuming more than 200 Mb of memory. In practice, we have found that REMoRDS can deal with specifications of less than nine scenarios, yielding Streett automata of around 10,000 states and 400,000 transitions. When faced with larger specifications, REMoRDS runs out of memory. D. Incomplete Distributed Synthesis The incomplete distributed synthesis algorithm has also been implemented in REMoRDS. The analyst needs to specify the name of the agent
to be synthesized, in addition to an intra-object specification. Remember that incomplete distributed synthesis resorts to game solving for checking that the SDI (Standard Distributed Implementation) is correct or can be refined to a correct implementation. Again, we use the algorithm of V¨oge and Jurdzinski as a toolbox. Analysts can also be provided with feedback using REMoRDS’ animator. If a correct distributed implementation is built, REMoRDS translates it to dot and FSP. The former allows one to visualize small implementations as an automaton graph, automatically layed out using Bell Labs’s Graphviz software [88]. The latter makes a process that can readily be inserted in an FSP model and analyzed in LTSA [82]. Thus, a synthesized model of a component can be taken and plugged in the design model of the system. E. LTL Formula Generation Once the analyst has obtained a satisfactory interagent specification, which is implementable, he can turn to the problem of designing an intra-agent model. In order to do so, we rely on the LTSA (Labeled Transition System Analyzer) that has been developed at Imperial College [82]. The analyst writes his intra-agent specification as an FSP (Finite State Process), with the additional constraint that communication events must be expressed as sender.event.receiver. Then, REMoRDS can be used to generate LTL formulae from the inter-agent specification. Those formulae can be input to LTSA and model checked, to ensure that the intra-agent model complies with the initial interagent specification. Fig.19 shows a window containing the LTL formula translated from the selected ULSC which pops up. Its content can then be copied-and-pasted to LTSA. Our translation takes advantage of the fact that conditions containing arbitrary boolean combinations of fluents can be used in ULSCs. Of course, one has to ensure that all fluents defined in the LPO file are also defined in the FSP model. REMoRDS uses the formula presented in [21], [49], [17], even though, in the worst case it can be exponentially larger than the ULSC. In [12], we provided a polynomial translation of ULSC to LTL, but we chose to resort to the theoretically inefficient formula because it gives very good practical results.
27
The polynomial translation is more intricate and is not of a great practical help, for its power is high (O(n5 )). The translation process is rather straightforward and relies on a depth-first traversal of the cut transition system. For performance matters, REMoRDS ensures that it never generates twice the same sub-formula in the same execution. The formula corresponding to a cut is cached and reused later if it needs to appear in another context.
Fig. 19.
REMoRDS: translating ULSC to LTL
It takes less than a second to generate the formula of every scenario of our CTAS case study. Of course, this is but the simplest job in the verification process: an external model checker needs to verify it afterwards, which is highly resource-consuming. IX. C ONCLUSION In this paper, we presented the result of our investigation of Harel’s novel way to engineer reactive distributed systems [1]. This approach relies heavily on automated processes to synthesize code all the way from user scenarios. This process is based on two essential artifacts: inter-agent specifications to express scenarios, because they are close to users requirements, and intra-agent specifications to describe the complete behaviour of every agent/object of the future system. Intra-agent specifications are closer to code and existing code generators can be reused from them. We formalized the framework in which this process can take place. On the one hand,
inter-agent specifications are given as Live Sequence Charts (LSCs), an expressive variant of MSCs. On the other hand, intra-agent specifications consist of strategies, an abstract model that encompasses the popular formalism of state machines. In this framework, we defined three problems of interest: 1) ELSC checking, i.e. verifying that the interagent specifications allows some user-given example; 2) Synthesis, i.e. checking that an inter-agent specification is implementable and building automatically a correct intra-agent specification, if it exists. 3) Verification, i.e. checking that a given intraagent specification is a correct implementation of a given inter-agent specification. We provided algorithms for each of these problems, except for synthesis which we proved was undecidable. We studied the complexity of these problems, and explored some variants as well. We showed our algorithms to be optimal. All these problems are intractable, with complexities ranging from coNPcomplete to EXPTIME-complete. We put this intractability in perspective by thoroughly reviewing the literature on LSCs. There are many positive results in verification and some synthesis algorithms trying to cope with undecidability are being developed. As a side-effect of our formalization, our framework acts as a roadmap, putting all papers and algorithms in relation with each other and explaining what role they play in Harel’s suggested development process. We extended our results to LSCs with conditions and real-time. These extensions can be obtained for free: definitions are only slightly altered and the computational complexity of analysis problems is left unchanged. We also studied the impact of adding symbolic instances to LSCs. Then, all analysis problems become undecidable. Finally, we presented an implementation of our algorithms, which allowed us to experiment with the process development cycle suggested by Harel. Our negative results regarding complexity should act as a guide for future research. There are several ways to live with intractability. First, problems may be relaxed, in order to work on subsets of LSCs for which efficient algorithms exist. Second, algorithms can be made efficient but imprecise. Third, precise algorithms can be devised with improvements that allow them to scale up very well but which, in
28
the worst case, have still a very high complexity. This trends is being witnessed, with success, in the field of model checking, with approaches such as symbolic model checking, SAT-based model checking, predicate abstraction or Craig interpolation. Theoretically, these techniques do not bring any improvement but practically, they make ever larger systems amenable to automated verification. Future research shall also consider the problem of inserting LSCs in existing computer systems. Our approach is greenfield; we start from scratch and generate a complete system. However, in practice, an existing implementation may already exist. We also marked a clear border-line between inter- and intra-agent specifications. However, in practice, both aspects shall be mixed, as some agents are easier to specify using state machines, even at the stage of requirements engineering. LSCs and existing implementations could be related through test suites generation, too. We also explained that existing scenario-based synthesis algorithms belong to two different categories: induction and compilation. It would be interesting to understand the interplay between induction, verification, compilation and synthesis. For instance, induction can be used in combination with verification to guess an intra-agent specification from examples and ensure that this system preserves safety-critical properties. Finally, one of the main appeal of scenario-based requirements engineering is the idea of starting from unrelated requirements chunk and composing them automatically. It is also the greatest obstacle to its practical use: our research has shown that the high complexity of LSCs precisely comes from this unstructured concurrent composition of scenarios. Efficiency could be improved by finding some trade off between an easy-to-analyze structured specification and an easy-to-manipulate loose specification. R EFERENCES [1] D. Harel, “From play-in scenarios to code: An achievable dream,” IEEE Computer, vol. 34, no. 1, pp. 53–60, January 2001. [2] L. Lamport and N. Lynch, Handbook of Theoretical Computer Science. Amsterdam, The Netherlands and Cambridge, Massachussets: Elsevier - MIT Press, 1990, vol. B, ch. 18, Distributed Computing: Models and Methods, pp. 1157–1199, iSBN 0-262-72015-9 (Second Priniting, 1998). [3] D. Harel and A. Pnueli, “On the development of reactive systems,” in NATO ASI Series, K. Apt, Ed., vol. F-13. NewYork: Springer, January 1985, pp. 477–498.
[4] J. Mukerji and J. Miller, “Mda guide v 1.0.1 (omg),” March 2003. [Online]. Available: http://www.omg.org/mda/ [5] K. Weidenhaupt, K. Pohl, M. Jarke, and P. Haumer, “Scenario Usage in System Development: A Report on Current practice,” IEEE Software, vol. 15, no. 2, pp. 34–45, March 1998. [6] W. Damm and D. Harel, “LSCs: Breathing life into message sequence charts,” Formal Methods in System Design, vol. 19, no. 1, pp. 45–80, 2001. [7] D. Harel and R. Marelly, Come, let’s play! Scenario-based programming using LSCs and the Play-engine. Springer, 2003, iSBN 3-540-00787-3. [8] I. T. Union, “MSC-2004: ITU-T Recommendation Z.120 : Message Sequence Chart (MSC),” International Telecommunication Union (prev. CCITT), Geneva, 2004, draft version. Still unapproved. [9] OMG UML Specification (2.0), Object Management Group (UML Revision Task Force), September 2003, http://www.omg. org/uml. [10] M. V. e. Cengarle and A. Knapp, “Uml 2.0 interactions: Semantics and refinement,” in Proc. of 3rd Int. Wsh. Critical Systems Development with UML (CSDUML’04, Proceedings), J. J¨urjens, E. B. Fernandez, R. France, and B. Rumpe, Eds., 2004, pp. 85–99. [11] Y. Bontemps, “On the semantics of uml 2.0 interaction diagram,” University of Namur, Institut d’Informatique, Tech. Rep., 2004. [12] ——, “Relating inter-agent and intra-agent specifications (the case of live sequence charts),” Ph.D. dissertation, Facult´es Universitaires Notre-Dame de la Paix, Institut d’Informatique (University of Namur, Computer Science Dept), April 2005. [13] M. Jackson, Software Requirements and Specifications: A Lexicon of Practice, Principles and Prejudices. Addison Wesley, 1995. [14] N. A. Lynch and M. R. Tuttle, “An introduction to input/output automata,” CWI Quarterly, vol. 2, no. 3, pp. 219–246, 1989. [15] Y. Bontemps, P.-Y. Schobbens, and C. L¨oding, “Synthesis of open reactive systems from scenario-based specifications,” Fundamenta Informaticae, vol. 62, no. 2, pp. 139–169, July 2004. [16] C. Gunter, A., E. Gunter, L., M. Jackson, and P. Zave, “A reference model for requirements and specification,” IEEE Software, vol. 17, no. 3, pp. 37–43, May/June 2000. [17] H. Kugler, D. Harel, A. Pnueli, L. Yuan, and Y. Bontemps, “Temporal logic for live sequence charts,” in Proc. of Tools and Algorithms for Construction and Analysis of Systems (TACAS’05), ser. Lect. Notes in Computer Science. Springer, April 2005, to appear. [18] Y. Bontemps and P.-Y. Schobbens, “The complexity of live sequence charts,” in Proc. of Foundations of Software Science and Computation Structure (FoSSACS’05), ser. Lecture Notes in Computer Science, V. Sassone, Ed., no. 3441. Edinburgh: Springer, April 2005, pp. 364–378. [19] D. Harel, H. Kugler, R. Marelly, and A. Pnueli, “Smart PlayOut of Behavioral Requirements,” in Proc. 4th Intl. Conference on Formal Methods in Computer-Aided Design (FMCAD’02), Portland, Oregon, 2002, To appear. Also available as Tech. Report MCS02-08, The Weizmann Institute of Science. [20] Y. Bontemps and P. Heymans, “Turning High-Level Live Sequence Charts into automata,” in Proc. of “Scenarios and StateMachines: models, algorithms and tools” (SCESM) workshop of the 24th Int. Conf. on Software Engineering (ICSE 2002). Orlando, FL: ACM, May 2002, http://www.cs.tut.fi/∼tsysta/ ICSE/papers/. [21] D. Harel and H. Kugler, “Synthesizing State-Based Object Systems from LSC Specifications,” International Journal of
29
[22]
[23]
[24]
[25] [26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
Foundations of Computer Science, vol. 13, no. 1, pp. 5–51, February 2002, (Preliminary version appeared in, Proc. Fifth Int. Conf. on Implementation and Application of Automata (CIAA 2000), LNCS 2088, July 2000.). E. Gr¨adel, W. Thomas, and T. Wilke, Eds., Automata Logics, and Infinite Games: A Guide to Current Research, ser. Lect. Notes in Computer Science. Springer, November 2002, vol. 2500. [Online]. Available: \url{http://link.springer.de/link/ service/series/0558/tocs/t2500.htm#to%c2500} D. Harel and M. Politi, Modeling Reactive Systems with Statecharts: the STATEMATE Approach. McGraw-Hill, 1998, iSBN 0-070-26205-5. P. Wolper and P. Godefroid, “Partial-order methods for temporal verification,” in Proc. of CONCUR’93, ser. Lect. Notes in Computer Science, vol. 715. Springer, 1993, pp. 233–246. K. McMillan, L., Symbolic Model Checking. Kluwer Academic Publiishers, 1993. N. Wallmeier, P. H¨utten, and W. Thomas, “Symbolic synthesis of finite-state controllers for request-response specifications,” in Proceedings of the 8th International Conference on the Implementation and Application of Automata (CIAA 2003), ser. Lect. Notes in Computer Science, O. H. Ibarra and Z. Dang, Eds., vol. 2759. Springer, 11–22. J. Tripakis, “Undecidable problems of decentralized observation and control on regular languages,” Information Processing Letters, vol. 90, 2004. R. Rosner, “Modular synthesis of reactive systems,” Ph.D. dissertation, The Weizmann Institute of Science, Rehovot, Israel, April 1992. A. Pnueli and R. Rosner, “On the synthesis of an asynchronous reactive module,” in Automata, Languages and Programming, 16th International Colloquium (ICALP), ser. Lect. Notes in Computer Science, G. Ausiello, M. Dezani-Ciancaglini, and S. R. D. Rocca, Eds., vol. 372. Stresa, Italy: Springer-Verlag, July 1989, pp. 652–671. O. Kupferman and M. Y. Vardi, “Synthesizing distributed systems,” in Proc. 16th IEEE Symp. on Logic in Computer Science, July 2001. P. Gastin, B. Lerman, and M. Zeitoun, “Distributed games and distributed control for asynchronous sytems,” in Proc. of Latin American Theoretical Informatics (LATIN’04), April 2004. [Online]. Available: ”http://www.liafa.jussieu.fr/∼versydis/data/ publications/GastinLermanZe%itoun-LATIN04.pdf” P. Madhusudhan and P. Thiagarajan, “A decidable class of asynchronous distributed controllers,” in Proc. of CONCUR’02, ser. Lect. Notes in Computer Science, vol. 2421. Brno, Czech Republic: Springer, 2002. [Online]. Available: \url{http: //www.cis.upenn.edu/∼madhusud/concur02.ps.gz} Y. Bontemps and P. Heymans, “As fast as sound (lightweight formal scenario synthesis and verification),” in Proc. of the 3rd Int. Workshop on “Scenarios and State Machines: Models, Algorithms and Tools” (SCESM’04), H. Giese and I. Kr¨uger, Eds. Edinburgh: IEE, May 2004, pp. 27–34, available at http://www.info.fundp.ac.be/∼ybo. Y. Bontemps, P. Heymans, and P.-Y. Schobbens, “Lightweight formal methods for scenario-based software engineering,” in Scenarios, ser. Lecture Notes in Computer Science, T. Systa and S. Leue, Eds. Springer, 2005, vol. 3466, pp. 174–192. D. Harel, H. Kugler, and A. Pnueli, “Synthesis revisited: Generating statechart models from scenario-based requirements,” in Formal Methods in Software and Systems Modeling, ser. Lecture Notes in Computer Science, H.-J. Kreowski, U. Montanari, F. Orejas, G. Rozenberg, and G. Taentzer, Eds., vol. 3393. Springer, 2005, pp. 309–324. J. Sun and J. S. Dong, “Synthesis of distributed processes from
[37]
[38] [39]
[40]
[41]
[42]
[43]
[44]
[45]
[46] [47]
[48]
[49]
[50]
[51]
scenario-based specifications,” in Formal Methods (FM 2005), 2005. T. Homme and J. E. Ramsland, “From live sequence charts to implementation (a study of the lsc specification, the execution of behavioral requirements and exploring the possibilities to use an lsc model to generate java code),” Master’s thesis, Agder University College, Agder, Norway, 2003. K. E. Wiegers, Software Requirements, 2nd ed. Microsoft Press, February 2003, iSBN 0735618798. M. Vardi, Y. and P. Wolper, “Automata-theoretic techniques for modal logics of programs,” Journal of Computer and System Science, vol. 32, no. 2, pp. 183–221, April 1986. S. Schwoon and J. Esparza, “A note on on-the-fly verification algorithms.” in Tools and Algorithms for Analysis and Construction of Systems (TACAS 2005), ser. Lecture Notes in Computer Science, N. Halbwachs and L. D. Zuck, Eds., vol. 3440. Springer, 2005, pp. 174–190. J. Klose and H. Wittke, “An Automata Based Interpretation of Live Sequence Charts,” in Proc. of TACAS (Tools and Algorithms for the Construction and Analysis of Systems) 2001, ser. LNCS, T. Margaria and W. Yi, Eds., vol. 2031. Genova, Italy: Springer-Verlag, April 2001, p. 512. J. Klose, T. Kropf, and J. Ruf, “A visual approach to validating system level designs,” in ISSS ’02: Proceedings of the 15th international symposium on System Synthesis. ACM Press, 2002, pp. 186–191. J. Bohn, W. Damm, J. Klose, A. Moik, and H. Wittke, “Modeling and validating train system applications using statemate and live sequence charts,” in Proceedings of the Conference on Integrated Design and Process Technology (IDPT2002), H. Ehrig, B. J. Kr¨amer, and A. Ertas, Eds. Society for Design and Process Science, 2002. [Online]. Available: http://ca.informatik.uni-oldenburg. de/cgi-bin/bibsearch?author=Wittke J. Klose, “Live sequence charts: A graphical formalism for the specification of communication behavior,” Ph.D. dissertation, Carl von Ossietzky Universit¨at, Oldenburg, 2003. M. Brill, R. Buscherm¨ohle, W. Damm, J. Klose, B. Westphal, and H. Wittke., “Formal verification of LSCs in the verification process,” in Integration of Software Specification Techniques for Applications in Engineering, ser. Lect. Notes in Computer Science, M. Grosse-Rhode, W. Reif, E. Schnieder, and E. Westk¨amper, Eds., vol. 3147. Springer, 2004. O. Kupferman, M. Y. Vardi, and P. Wolper, “Module checking,” Information and Computation, vol. 164, pp. 322–344, 2001. E. M. Clarke and J. M. Wing, “Formal methods: State of the art and future directions,” ACM Computing Surveys, vol. 28, no. 4, pp. 626–643, December 1996. A. Bunker and G. Gopalakrishnan, “Verifying a Virtual Component Interface-based PCI Bus Wrapper Using an LSC-Based Specification,” University of Utah, School of Computing, Tech. Rep. UUCS-02-004, 2002. Y. Bontemps, “Automated Verification of State-based Specifications Against Scenarios (A Step towards Relating Inter-Object to Intra-Object Specifications),” Master’s thesis, University of Namur, Namur, Belgium, June 2001. M. Abadi, L. Lamport, and P. Wolper, “Realizable and unrealizable specifications of reactive systems,” in Automata, Languages and Programming, 16th International Colloquium, ICALP89, Stresa, Italy, July 11-15, 1989, Proceedings, ser. Lect. Notes in Computer Science, G. Ausiello, M. DezaniCiancaglini, and S. R. D. Rocca, Eds., vol. 372. Springer, 1989. A. Pnueli and R. Rosner, “On the Synthesis of a Reactive Mod-
30
[52]
[53]
[54]
[55]
[56]
[57]
[58]
[59]
[60]
[61]
[62]
[63]
[64]
[65]
[66]
ule,” in Proceedings of the sixteenth annual ACM symposium on Principles of programming languages, 1989, pp. 179–190. O. Kupferman and M. Y. Vardi, “Synthesis with incomplete informatio,” in 2nd International Conference on Temporal Logic, Manchester, July 1997, pp. 91–106. M. Y. Vardi, “An automata-theoretic approach to fair realizability and synthesis,” in Proceedings of the 7th International Conference On Computer Aided Verification, P. Wolper, Ed., vol. 939. Liege, Belgium: Springer Verlag, 1995, pp. 267–278. [Online]. Available: citeseer.nj.nec.com/ article/vardi95automatatheoretic.html P. J. G. Ramadge and W. M. Wonham, “The control of discrete event systems,” Proceedings of the IEEE; Special issue on Dynamics of Discrete Event Systems, vol. 77, 1, pp. 81–98, 1989. H. Wong-Toi and D. L. Dill, “Synthesizing processes and schedulers from temporal specifications,” in Computer-Aided Verification ’90: Proceedings of a DIMACS Workshop, ser. DIMACS Series in Discrete Mathematics and Theoretical Computer Science, E. M. Clarke and R. P. Kurshan, Eds., vol. 3. American Mathematical Society, 1991, pp. 177–186. Z. Manna and P. Wolper, “Synthesis of communicating processes from temporal logic specifications,” ACM Transactions on Programming Languages and Systems (TOPLAS), vol. 6, no. 1, pp. 68–93, 1984. E. A. Emerson and E. M. Clarke, “Using branching time temporal logic to synthesize synchronization skeletons,” Science of Computer Programming, vol. 2, no. 3, pp. 241–266, December 1982. D. Amyot and A. Eberlein, “An Evaluation of Scenario Notations for Telecommunication Systems Development,” in Proc. of 9th Int. Conference on Telecommunication Systems (9ICTS), Dallas, USA, March 2001. K. Koskimies, T. M¨annist¨o, T. Syst¨a, and J. Tuomi, “SCED: A Tool for Dynamic Modelling of Object Systems,” Department of Computer Science, University of Tampere, University of Tampere, Department of Computer Science, P.O. Box 607, FIN33101 Tampere, Finland, Tech. Rep. Report A-1996-4, July 1996, iSBN 951-44-4003-X, ISSN 0783-6910. A. W. Biermann and R. Krishnaswamy, “Constructing Programs from Example Computations,” IEEE Transactions on Software Engineering (TSE), vol. SE-2, no. 3, pp. 141–153, September 1976. I. Diethelm, L. Geiger, T. Maier, and A. Z¨undorf, “Turning collaboration diagram strips into storycharts,” in Proc. of “Scenarios and State-Machines: models, algorithms and tools” (SCESM) workshop of the 24th Int. Conf. on Software Engineering (ICSE 2002). Orlando, FL: ACM, May 2002, http://www.cs.tut.fi/∼tsysta/ICSE/papers/. E. M¨akinen and T. Syst¨a, “Acta informatica,” Minimally Adequate Teacher Synthesizes Statechart Diagrams, vol. 38, pp. 235–259, 2002. J. Koskinen, E. M¨akinen, and T. Syst¨a, “Minimally adequate teacher synthesizes shuttles, too,” in Proc. of the 3rd Int. Workshop on “Scenarios and State Machines: Models, Algorithms and Tools” (SCESM’04), H. Giese and I. Kr¨uger, Eds. Edinburgh: IEE, May 2004. P. Hsia, J. Samuel, J. Gao, D. Kund, Y. Toyoshima, and C. Chen, “Formal approach to scenario analysis,” IEEE journal, pp. 33– 41, March 1994. I. Kr¨uger, R. Grosu, P. Scholz, and M. Broy, “From mscs to statecharts,” Kluwer Academic Publishers, 1999, franz J. Rammig (ed.). J. Whittle and J. Schumann, “Generating Statechart Designs from Scenarios,” in 22nd International Conference on Software
[67]
[68]
[69]
[70]
[71]
[72]
[73]
[74]
[75]
[76] [77] [78]
[79]
[80]
Engineering (ICSE 2000). Limerick, Ireland: ACM, June 2000, pp. 314–323. S. Uchitel and J. Kramer, “A Workbench for Synthesizing Behaviour Models from Scenarios,” in Proc. of the 23rd IEEE International Conference on Software Engineering (ICSE’01). ACM, 2001. R. Alur, K. Etessami, and M. Yannakakis, “Inference of Message Sequence Charts,” in Proceedings of 22nd International Conference on Software Engineering, 2000, pp. 304–313. T. Ziadi, L. H´elou¨et, and J.-M. J´ez´equel, “Revisiting statechart synthesis with an algebraic approach,” in Proc. of 26th International Conference on Software Engineering (ICSE). Edinburgh: IEEE Computer Society, May 2004, pp. 242–251, iSBN 0-76952163-0. S. Uchitel, J. Kramer, and J. Magee, “Detecting implied scenarios in message sequence chart specifications,” in Proceedings of the Joint 8th European Software Engeneering Conference and 9th ACM SIGSOFT Symposium on the Foundation of Software Engeneering (ESEC/FSE-01), ser. SOFTWARE ENGINEERING NOTES, V. Gruhn, Ed., vol. 26, 5. New York: ACM Press, Sept. 10–14 2001, pp. 74–82. B. Finkbeiner and I. H. Kr¨uger, “Using message sequence charts for component-based formal verification,” in Proc. of OOPSLA 2001 Workshop on Specification and Verification of ComponentBased Systems, Tampa Bay, FL, USA, October 2001. J. Desharnais, M. Frappier, R. Kh´edri, and A. Mili, “Integration of sequential scenarios,” IEEE Transactions on Software Engineering, vol. 24, no. 9, pp. 695–708, September 1998. D. Giannakopoulou and J. Magee, “Fluent model checking for event-based systems,” in Proc. of the 4th joint meeting of the European Software Engineering Conference and ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE 2003), Helsinki, Finland, September 2003. D. Harel and R. Marelly, “Playing with time: On the specification and execution of time-enriched LSCs,” in Proc. 10th IEEE/ACM International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems (MASCOTS’02), Fort Worth, TX, 2002. [Online]. Available: \url{http://citeseer.nj.nec.com/harel02playing.html} L. de Alfaro, T. A. Henzinger, and M. Stoelinga, “Timed interfaces,” in Proc. of EMSOFT 2002, Second International Workshop on Embedded Software, ser. Lect. Notes in Computer Science, A. Sangiovanni-Vincentelli and J. Sifakis, Eds., vol. 2491. Grenoble, France: Springer, October 2002, pp. 108– 122. S. La Torre, “Finite automata on timed ω-trees,” Theoretical Computer Science, vol. 293, no. 3, pp. 479–505, February 2003. R. Alur and D. L. Dill, “A theory of timed automata,” Theoretical Computer Science, vol. 126, pp. 183–235, 1994. J. Klose and B. Westphal, “Relating LSC specifications to UML models,” in International Workshop on Integration of Specification Techniques for Applications in Engineering (INT2002), H. Ehrig and M. Grosse-Rhode, Eds., 2002, p. 8. R. Marelly, D. Harel, and H. Kugler, “Multiple Instances and Symbolic Variables in Executable Sequence Charts,” in Proc. 17th Ann. ACM Conf. on Object-Oriented Programming, Systems, Languages and Applications (OOPSLA’02), Seattle, WA, 2002, pp. 83–100. Y. Bontemps, P. Heymans, and H. Kugler, “Applying LSCs to the specification of an air traffic control system,” in Proc. of the 2nd Int. Workshop on “Scenarios and State Machines: Models, Algorithms and Tools” (SCESM’03), at the 25th Int. Conf. on Soft. Eng. (ICSE’03), S. Uchitel and F. Bordeleau, Eds. Portland, OR, USA: IEEE, May 2003, available at http://www.info.fundp.ac.be/∼ybo.
31
[81] W. Damm and B. Westphal, “Live and let die: LSC based verification of UML models.” Sci. Comput. Program., vol. 55, no. 1-3, pp. 117–159, 2005. [82] J. Magee and J. Kramer, Concurrency: State Models and Java Programs. New-York: John Wiley & Sons Ltd., 1999. [83] S. Hudson, F. Flannery, and C. S. Ananian, “Java cup: Lalr parser generator for java(tm),” Software, September 1999, http: //www.cs.princeton.edu/∼appel/modern/java/CUP/. [84] G. Klein, “Jflex: The fast scanner generator for java,” Software, September 1999, http://jflex.de/. [85] P. Heymans, “Animating albert ii specifications,” Ph.D. dissertation, University of Namur, 2001. [86] J. V¨oge and M. Jurdzi´nski, “A discrete strategy improvement algorithm for solving parity games (Extended abstract),” in Computer Aided Verification, 12th International Conference, CAV 2000, Proceedings, ser. Lect. Notes in Computer Science, E. A. Emerson and A. P. Sistla, Eds., vol. 1855. Chicago, IL, USA: Springer, July 2000, pp. 202– 215. [Online]. Available: \url{http://www-cad.eecs.berkeley. edu/∼mju/Papers/JV00-BRICS-RS-00-48.p%s} [87] D. A. Martin, “Borel determinacy,” Annals of Mathematics, vol. 102, pp. 363–371, 1975. [88] J. Ellson, E. Gansner, Y. Koren, E. Koutsofios, J. Mocenigo, S. North, G. Woodhull, D. Dobkin, V. Alexiev, B. Lilly, J. Scheerder, D. R. G., and G. Low, “Graphviz - graph visualization software,” Software, http://www.graphviz.org.
