Logical-Time Contracts for Reactive Embedded Components

Transcription

1 Logical-Time Contracts for Reactive Embedded Components Florence Maraninchi Lionel Morel VERIMAG, Centre Equation, 2 avenue de Vignate, F38610 GIERES (Florence.Maraninchi Lionel.Morel)@imag.fr Abstract The Design by contract principle has been applied successfully in the context of object-oriented designs, since it was first proposed by B. Meyer for Eiffel. We claim that a simple pre-post specification is not sufficient for reactive software. We introduce a model of reactive components suitable for reactive embedded software, and a notion of logical-time contract for the specification and use of these components in synchronous compositions. 1. Introduction Reactive systems and their environments Reactive systems, as defined in [1], are characterized by the interaction being the prominent aspect of their behavior. Software embedded in aircraft, nuclear plants and similar physical environments, is a typical example. Moreover, they interact with a non-collaborative environment, which may impose its own rhythm: it does not wait, nor re-issue events. But embedded systems have an advantage over interactive systems like man/machine interfaces: their environment is a partially known physical phenomenon, that can be modeled. The ability to model the environment is crucial when developing embedded control systems, because no control system is able to behave correctly in any environment. For instance, a heater controller always makes the hypothesis that, once it has turned the heater on (an output of the system), the temperature (an input) will start increasing, within a known range of slopes. The specifications of reactive embedded software have to take the intrinsic system/environment loop into account. The timing aspects make it even harder: we should be able to assume that the temperature input is increasing, when specifying what a reactive system guarantees. We need a notion of logical time defined by the sequence of reactions to the environment. It is logical because it needs not be directly related to a physical time scale. This notion of discrete and logical time is adequate for reasoning about cyclic-executive implementations of embedded systems, which are very common in industrial critical applications (nuclear plants, avionics, etc.). The behavior of the system is an infinite loop, in which it first reads the sensors, then computes the commands according to these inputs and to some internal memory, then updates the memory and sends the commands to the actuators. The Design-by-Contract principle For traditional sequential systems, the design-by-contract principle [2] has been very successful. A contract is a specification put in the form of an implication between an assumption clause (also called pre-condition), and a guarantee clause (also called post-condition). In the following, we prefer the words assumption and guarantee, because pre and post mean time, and we want to introduce another notion of time in the picture. If the inputs provided by the environment, together with the system state, satisfy the assumption, then the system changes state and provides outputs satisfying the guarantee clause. Development methodologies and even programming languages propose a support for the use of contracts. This means introducing a language of logical properties, which can talk about the variables of the associated programming language. In Eiffel [3], the contracts are parts of the program, and the compiler generates defensive code that may raise exceptions at runtime when the contracts are violated. IContract [4], among others, rewrites Java programs by adding defensive code corresponding to contracts, introduced as a special kind of comment. OCL [5] can be used in UML designs in order to specify global or local invariants, and pre-post specifications of methods. Time in contracts What does time mean in contracts? The assumption and guarantee clauses may talk about the current execution of a method, and express in the guarantee clause that x is equal to old x + 1, but old means just before this execution. However, we may have to talk about previous executions of the same method. For instance, consider a class C with methods m1 and m2, and a specification stating that method m1 should never be called before m2 has been called at least once. A usual way of expressing such contracts is to attach an explicit Boolean state Σ to each object of class C;

2 an execution of m2 guarantees that Σ is set to true; executing m1 assumes Σ is true. In some sense, this means that the potential memory hidden in the assume or guarantee clauses has been compiled by hand into explicit variables. For reactive systems, we need this notion of time: first, we need to talk about the successive executions of the piece of code that constitutes one reaction of the system to its environment; second, the assumption on the environment (e.g., the temperature is increasing supposes successive uses of the temperature; and, finally, when executing several components in parallel, a notion of logical time is needed to understand how their executions may interleave. Separation of concerns and expressivity of the contracts The assume (or the guarantee) clause often needs to store some memory of the execution (for instance, for expressing that an input is increasing), and the component body may also need the same memory, in order to compute the appropriate output (if the output depends on the slope of the input). In this type of case, should we write an assume clause that shares some variables with the body? Our answer is no. First, we may write the contract of a component before we get any idea of its implementation (and there are contexts in which we may use the contract alone, without the body, see section 4), which means that the set of variables needed for the memory of the assume clause is necessarily given in isolation. Second, even if we design the body and the contract together, the separation of concerns principle leads to a component structure in which several sets are clearly identified: the inputs I, the outputs O, the local variables L of the body, the local variables A of the assume clause, and the local variables G of the guarantee clause. The assume clause may use I and A. The guarantee clause may use I, O, G, and the body may use I, O, L. This notion of separate memory for the specification resembles the notion of specification variable mentioned in several papers, for instance [6], with the argument that these variables need not be implemented. This is also the case for us: the memory needed for the expression of the contract needs not exist at runtime, unless we implement systematic defensive code for the contracts. Another point we consider to be very important from a programmer s point of view, is the expressive power of the language used for the contracts. As soon as we need to talk about time, we need memory and the contract clauses may be potentially as complex as the program itself (at least in their structure, if not in their size). Using the programming language itself for the expression of the contracts is a solution, but even if a dedicated language is used, it should have the same expressive power. Reactive components and composition The last notion to be clarified before we can think of applying design-bycontract to reactive software, is how this type of software can be thought of as a set of well-defined components. We are faced with the problem of global or local time. What is the relationship between the time of the complete system, and the time of each of its components? In this paper, we choose to consider networks of reactive components, in a data-flow style. We look at the synchronous interpretation of such networks. It gives a straightforward answer to the previous question, since there is a notion of global step, in which all components perform one local step. The previous step has the same meaning for all components. Further work will be devoted to applying the ideas of [7], in order to model asynchronous compositions of contracts in the synchronous framework. Proposal We propose a general framework for the definition of reactive components equipped with functional contracts, that can be composed synchronously. We aim at demonstrating the actual use of contracts in such contexts, and the benefits one can find in using them systematically, from the very beginning of the design until the validation phases. In our proposal, contracts (and the memory they need) are clearly separated from the body of a component. We do not propose a specific language for the contract, and for the examples given in Java, the assume and guarantee clauses are ordinary methods. In the conclusion, we give some hints towards the use of a dedicated language for the contracts. In [8], we used such contracts in the language Lustre [9], together with arrays and iterators that help in structuring complex systems. Contents of the paper Section 2 is devoted to related work. Section 3 gives an example of a reactive component, together with a contract, and an example composition. Section 4 lists the benefits one can hope from their systematic use. Section 5 defines all the notions precisely, in a style which is independent of any programming language. Section 6 concludes. 2. Related work Compositional reasoning and proof-rules supporting automatic verification techniques have been studied a lot. They are based on specifications given as tuples (assume, guarantee), in formal frameworks. Parallelism and time are taken into account. See, for instance [10, 11]. However these methods are not developed from a programmer s point of view, and there is little support for writing assume and guarantee clauses in programs. Reactive modules [12] may seem very similar to what we propose: modules can be composed synchronously or asynchronously, and assume-guarantee reasoning is possible. There are some differences, however. First, asynchronous composition is introduced via stuttering, while we can adapt the method described in [7]; Second, the framework of reactive modules is designed for verification pur-

3 poses. Our main goal is to exploit contracts during the development phase, for instance as a support for the early execution of partially specified components. The notion of contract is part of our notion of component, while it is not part of the definition of a reactive module. In [13], the notion of interface is very similar to what we need (temporal assumptions on the environment, and temporal guarantee); but the notion of composition is less rich, and the assume and guarantee clauses are not separated (in some sense, an interface automaton is the product of our assume and guarantee clauses). For verification purposes it is irrelevant whether the assume and guarantee clauses are separated, but we think that, if the contracts are to be used in a real development, it is essential that the assume and guarantee clauses be clearly separated. In the quite different context of software engineering, the notion of contract has been adapted for a wide variety of languages and formalisms, but the notion of time we need for reactive systems is not always taken into account. Some extensions of OCL with linear or branching-time temporal logics have been proposed [14, 15]. They focus on the expressivity of the constraint language (the way constraints may talk about the internals of the classes and objects). They suppose that the sequence of states of the system is clear. However, as soon as one deals with parallel systems, this global sequence is some interleaving of the behaviors of the individual objects, which has to be defined. Moreover, the language used for expressing the timing aspects is a temporal logic; it might get quite difficult to understand, and it is not executable in the sense we mentioned in section 4. JASS [16] is closer to our motivations and solution: It proposes a notion of trace, and a language to talk about traces. However, it seems that it evolves mainly towards debugging and defensive execution. For embedded systems, we prefer to use contracts for validating the compositions, and we can hope to use formal tools if we use a dedicated language for contracts. The notion of sequential don t care in circuit design (see, for instance [17]) is very similar to our notion of an assume clause that cares about successive steps of the execution. 3. Example A contract First, let us look at a specification expressed as a contract, stating that: if there are no cases in which the Boolean input a is true during less than 2 instants, then there are no cases in which the Boolean output b is true during less than 3 instants. The contract is given as a tuple (A, G) of temporal properties. A expresses the assumption that the system has about its environment. G expresses the property guaranteed by the system whenever put in an environment satisfying A. A and G can (but not necessarily) be expressed by Mealy machines (i.e., finite state machines labeled with inputs and outputs): true/false true/false e4 b/false b/false e3 e1 e2 ā/false b/true e1 b/true b/true a/true a/true ā/true e0 e3 e0 e2 a/true b/true b/true ā/true b/true The sequence of inputs is said to satisfy the assumption if and only if the output of the machine A is always true. This machine is an observer [18]. A component body We consider a re-triggerable monostable flip-flop (rmff) with one input a and one output b. Whenever a is true at a given time t, b is true during the following 2 instants t+1 and t+2. Re-triggerable means that if a is true during several instants, the first occurrence of it is not the only one to be taken into account: the following occurrences do influence the output b, which is retriggered. This component is taken from a library of building blocks defined by Airbus for the programming of reactive systems in SCADE 1, a commercial programming environment based on the language Lustre [9]. A typical reactive system in this context needs confirmation on each input (inputs that are true only one instant should be ignored because they are considered not significant) and sustaining on each output (a command that is sent to the outside world should be true for several instants). We show below an example behavior and an automaton version of the program. The behavior can be expressed with a three-state memory: a/b e1 a a/ b ā/b ā/ b a/b b e ā/b e2 Comparing the body and the contract In the above example, the body described is indeed one possible implementation that satisfies the contract. It is easy to show with a model-checking tool. It has been performed by translating the three automata and their composition into Lustre and then using the model-checker Lesar [9] developed at Verimag. Another interesting question is whether the contract indeed admits one implementation (see 5.2 below). Implementation A reactive component can be encoded (here in Java) by a class that provides 3 step and 3 initialization methods (body, assumption and guarantee). It also gives access to the input/output variables of the component. For example, the rmff can be described by the class given 1 SCADE is a tool developed by Esterel Technologies.

4 on fig. 1. For clarity reasons, we choose to code the step methods as direct translations of the Mealy machines described earlier, even though these versions are not as elegant or efficient as possible. A defensive execution step of the component consists in checking whether the component s contract is satisfied and if it is, performing the computation of the outputs (see method step()). To execute one component of this kind, we write a main method, made of a single while loop: public static void main(){ RMFF rmff = new RMFF(); rmff.init() ; while (true) { if (fromuser().compareto("tt") == 0) { rmff.seta(true); else if (fromuser().compareto("ff") == 0) { rmff.seta(false); rmff.step() ; At each pass in the loop the program defines the values assigned to inputs of each component (here by calling the rmff.seta() method), and then asks the component to perform one step (rmff.step()). Before entering that infinite loop, the main program initializes each node by calling the corresponding rmff.init(). The notion of time is the same for the inputs and outputs of the components: outputs are computed in the exact same execution cycle where the inputs are available. In a defensive implementation, performing a step (resp. initialization) on one component means performing a step (resp. initialization) on its assume-guarantee contract and on its body. Besides, we apply the separation of concerns principle. We identify the local variables of the body (bodystate), the local variables of the assumption (assumestate and assumevalue) and the local variables of the guarantee (guaranteestate and guaranteevalue). Section 4 lists other ways contracts can be exploited. Example composition Let s consider another kind of flip flop component. Its contract is as follows: it assumes that its input c is never true more than one instant in a row and it guarantees that its output a is never true less than two instants in a row. This guarantee is exactly the assumption of the rmff component. The step functionalities for the assumption and the body are given below: c/a e1 c/true c/false c/ā c/a e1 c/true c/true c/ā e0 e2 e0 /false In order to compose the rmff component with this flip flop component, the output a of flip flop may be identified with the input a of rmff. We may check whether this composition makes sense, verifying that the property guaranteed by flip flop on its output a implies the assumption of rmff on its input a, i.e. flip flop.guarantee() = rmff.assume(), which is true. In this simple case, the composition component s init and step methods are: public init(){ flip flop.init(); rmdd.init(); public step(){ flip flop.step(); rmdd.step(); The general case is to arrange components in a dataflow network (see 5.2). 4. Exploiting contracts We advocate a development method mixing bottom-up and top-down approaches, in which entirely specified components may live together with partially specified ones, all of them being specified by contracts. This allows the intensive use of defensive code. It should not be used on the final version of an embedded system but can be worth using in a development and debugging phase. Contracts also help in checking whether the compositions make sense (the guarantee of a producer implies the assumption of the consumer, the body is compatible with the contract, etc). We may also require a quality criterion on contracts, stating that there is no assumption on the inputs hidden in the guarantee clause. Technically: the guarantee clause, considered as a constraint on the inputs only, should not be stronger than the assume clause. If we really want to separate the assume and the guarantee clauses, this is mandatory. The main use we have in mind is the early execution of non-deterministic components given by their contracts. Executable specifications have been advocated for a long time (see, for instance [19]), but it is usually hard to do or to define precisely when the specifications are non deterministic. One of the advantages of programs with contracts is that a complex network of components may be executed very early, before all the components have been programmed completely. A network made of some fully programmed deterministic components, and some components that are given only by their contract, can indeed be executed. For each component that is given by its contract only, the output cannot be computed deterministically from the inputs. We need to generate random outputs compatible with the contract, given the set of inputs. Since the contracts have memory, this random generation cannot be thought of as simple instant-by-instant process, and has to take traces into account. This automatic generation of outputs requires the assume and guarantee clauses to be exploited in a formally defined context. This is an argument in favor of a dedicated language for contracts. In our experiments with contracts for reactive software, we use the formally defined language Lustre for the expression of the contracts. In the context of the academic programming environment based on the Lus-

5 class RMFF{ RMFF(){ // inputs, outputs private bool a; public void seta(bool aval){ a = aval; private bool b; public bool getb(){return b; // the assumption private int assumestate; private bool assumevalue; public boolean initassume() { assumestate = 0; assumevalue = true; return assumevalue; public boolean stepassume() { switch (assumestate) { case 0: if(!a){assumestate = 0; else{assumestate = 1;break; case 1: if(!a){assumestate = 3; assumevalue = false; else {assumestate = 2;break; case 2: if(!a){assumestate = 0; else {assumestate = 2; break; case 3: assumestate = 3;break; return assumevalue; // the guarantee private int guaranteestate; private bool guaranteevalue; public void initguarantee() { guaranteestate = 0; guaranteevalue = true; return guaranteevalue; public boolean stepguarantee() { switch (guaranteestate){ case 0:if(!b){guaranteeState = 0; else{guaranteestate = 1;break; case 1:if(!b){guaranteeState = 4; guaranteevalue = false; else {guaranteestate = 2;break; case 2:if(!b){guaranteeState = 4; guaranteevalue = false; else {guaranteestate = 3;break; case 3:if(!b){guaranteeState = 0; else {guaranteestate = 3;break; case 4:guaranteeState = 4;break; return guaranteevalue; // the body private bool bodystate; public void initbody() { bodystate = 0; private void stepbody() { switch(bodystate){ case 0: if(!a){bodystate=0;b=false; else{bodystate=1;b=false; break; case 1: if(!a){bodystate=2;b=true; else{bodystate=1;b=true; break; case 2: if(!a){bodystate=0;b=true; else{bodystate=1;b=true; break; // main methods public void init() throws Exception{ if(initassume()){ initbody(); if(initguarantee()){ printa(); printb(); else{ throw new assumeexception(); else{ throw new guaranteeexception(); public void step() throws Exception{ if(stepassume()){ stepbody(); if(stepguarantee()){ printa(); printb(); else{ throw new assumeexception(); else{ throw new guaranteeexception(); Figure 1. The class defining the rmff component tre language, a tool called Lurette [20] has been developed, for black-box testing purposes. Lurette is able to generate sequences of realistic inputs for a reactive system, based on a formal model of its environment. In Lurette, the program is a deterministic black-box, and the environment is a non-deterministic white-box, expressed as constraints on traces. They are connected together in a loop. Exploiting contracts in a dataflow connection of components is the extension of this idea: we might have several deterministic black-boxes and also several non-deterministic white-boxes (given by their contracts only). 5. Formal definitions We give a language-independent formal definition of components and composition. We start with a set of variables V, taking their values in a domain D, intended to represent the state of a dynamical system. The semantics of a reactive system is given in terms of step-relations. Intuitively, a step-relation relates two valuations of V, that are intended to represent the valuations at two successive instants in time. Then we define components on top of step-relations, and the composition of components. Variables may be typed. However, we forget about the typing mechanism, which is necessarily particular to the language in which step-relations are described Step-Relations Definition 1 : Valuations and Step-Relations A valuation σ of V is a total function from V to D; Let us denote by Vals (V,D) the set of all such valuations. Then, a step-relation on V relates valuations, hence it is a subset of Vals (V,D) Vals (V,D). The set of all step-relations on V is Step-Rels (V,D) = P(Vals (V,D) Vals (V,D)). Definition 2 : Reactivity and Determinism A step-relation r Step-Rels (V,D) is said to be deterministic (resp. reactive) if and only if: σ Vals (V,D). {σ (σ, σ ) r 1 (resp. 1) A deterministic step-relation allows at most one move from a valuation to a next one; a reactive step-relation allows at least one move from a valuation to a next one. Combinational relations are used to describe the initialization of an execution: Definition 3 : Combinational Relations A combinational relation i is a set of valuations in Vals (V,D). The set of all combinational relations on V is Comb-Rels (V,D) = P(Vals (V,D)).

6 Example 1 Any constraint language may be used to describe steprelations, using twice as many variables as needed by the actual modeling of the dynamical system. The assumption and the guarantee of the rmff may be defined by step-relations as follows. The assumption Sa needs the set of variables A = {e0, e1, e2, e3, a (one variable per state) and the guarantee Sb needs the set of variables G = {e0, e1, e2, e3, e4, b: Sa : e0 = ((e0 not a) (e2 not a)) e1 = (e0 a) e2 = ((e1 a) (e2 a)) (e3 = ((e1 not a) e3)) not e3 Sg : e0 = ((e0 not b) (e3 not b)) e1 = (e0 b) e2 = (e1 b) e3 = ((e2 b) (e3 b)) (e4 = ((e1 not b) (e2 not b) e4)) not(e4) The semantics of a reactive step-relation r Step-Rels (V,D), is defined by the set T (r) of all infinite sequences of valuations on V that are consistent with r. The step-relation being reactive ensures that a trace can always be extended. Definition 4 : Traces of a reactive step-relation A trace is a sequence of valuations indexed by N, i.e., a total function from N to Vals (V,D). The set of traces of a step-relation r is: T (r) = {s : N Vals (V,D) n 0. (s(n), s(n + 1)) r Definition 5 : Synchronous composition Given r, r Step-Rels (V,D), we call synchronous composition of r and r the relation: r r. Parallel composition preserves determinism, but it does not necessarily preserve reactivity. Take, for instance : r1 defined by x = 3 and r2 defined by x = 42. In r1 r2 there is no possible value for x in σ. Definition 6 : Hiding variables of step-relations Given a step-relation r Step-Rels (V,D) and a subset Y V, we define the hiding of Y in r and we note r Y the relation r Y Step-Rels(V \ Y, D) = y 1,..., y k.r, where Y = {y 1,... y k. Identically, we define variable hiding for combinational relations. Definition 7 : Adding variables to step-relations Given a step-relation r Step-Rels (V,D) and a set Y such that Y V =, we can define a step-relation r +Y Step-Rels (V Y, D) by allowing additional variables to take arbitrary values. r +Y = {(v 1, v 2) Vals(V Y, D) Vals(V Y, D) (v 1, v 2 ) r. x V.v 1(x) = v 1 (x) v 2(x) = v 2 (x) Any constraint on x, y, z can be seen as a constraint on x, y, z, t which doesn t talk about t at all Components and their contracts Definition 8 : Component A component is a tuple (I, O, L, A, G, Sa, Ja, Sg, Jg, Sb, Jb) where: I and O are the sets of inputs and outputs of the component; L, A and G are the sets of variables respectively local to the body of the component, to its assumption and to its guarantee. I, O, L, A, G are pairwise disjoint; Sb is a step-relation and Jb is a combinational relation both on I O L, together defining the behavior of the body of the component; Sa and Sg are step-relations (and Ja, Jb are combinational relations) respectively on I A and I O G together defining the contract of the component. Definition 9 : Body satisfying a contract Given a component C = (I, O, L, A, G, Sa, Ja, Sg, Jg, Sb, Jb), we say that the body specified by Jb and Sb implements the contract specified by (Ja, Sa) and (Jg, Sg) iff for any input trace satisfying (Ja, Sa), all the output traces satisfying (Jb, Sb) also satisfy (Jg, Sg). In terms of step-relations, this writes: (Sa A ) +O Sb L Sg G. Similar conditions should hold for Ja, Jb and Jg. Example 2 We mentioned in sec.3 that, using Lesar [9], the body of rmff has been proven to satisfy its contract. Definition 10 : Implementable contract Given a component C = (I, O, L, A, G, Sa, Ja, Sg, Jg, Sb, Jb), we say that the contract specified by (Ja, Sa) and (Jg, Sg) is implementable (i.e., there exists at least one body satisfying it) if and only if: (Sa A ) +O Sg G. Similar conditions should hold for Ja and Jg. Example 3 Consider a contract given by the 2 step-relations (over V = {i, o) S a : i mod 2 = 0 and S g : (i + 2o) mod 2 = 1. Here, we know that (S a, S g ) is not implementable, since i can not be even and odd at the same time. Definition 11 : Consistency of the step-relations with the variable sets Given a component C = (I, O, L, A, G, Sa, Ja, Sg, Jg, Sb, Jb), we say that the step-relations of C are consistent with its variable sets (i.e., Sg does not constrain variables in I more than Sa does) if and only if the following condition holds: Sa A (Sg G ) O. Similar conditions should be satisfied for Ja and Jg. Example 4 Consider the following contract for a component with i as

7 input and o as output: Sa(i) : i 0 ; Sg(i, o) : (o 2 i) (o 100). Sg implies a constraint on i (i 50) which is stronger than Sa. This contract is implementable: we can build a component that takes an i in [0, 50] and outputs an o in [0, 100]. But it is not consistent with {i, o since Sa A (Sg G ) O, i.e. i 0 ( o. (o 2 i) (o 100)). consis- Consistency is stronger that implementability. tency is a quality criterion, see section 4. Synchronous composition of components Components are arranged in a dataflow network without cycles: outputs of one component can be connected to inputs of the other. In a synchronous composition, the producer and the consumer perform a step at the same time and may exchange a value: the wires of the dataflow network need no memory. For simplicity of presentation, we plug the components by identifying the variables that have the same name in both components. We can have non-combinational data-dependency cycles by using a shifting component called pre which memorizes its input for one execution step. Definition 12 : Synchronous composition Given two components C i = (I i, O i, L i, A i, G i, Sa i, Ja i, Sg i, Jg i, Sb i, Jb i ) (with i = 1, 2) satisfying: O 1 O 2 = (disjoint outputs); for each v 1 I 1 O 2 and each v 2 I 2 O 1, either v 1 does not depend on v 2 (in C 1 ), or v 2 does not depend on v 1 (in C 2 ) (no combinational data-dependency cycles); we define the synchronous (parallel) composition of C 1 and C 2 and we note C 1 C 2 the component (I, O, L, A, G, Sa, Ja, Sg, Jg, Sb, Jb) such that: I = (I 1 I 2 ) \ (O 1 O 2 ); O = (O 1 O 2 ); L = (L 1 L 2 ); A = A 1 A 2 ; G = G 1 G 2 ; Sa = Sa O2 1 Sa O1 2 ;Ja = Ja O2 1 Ja O1 2 ; Sg = Sg 1 Sg 2 ;Jg = Jg 1 Jg 2 ; Sb = Sb 1 Sb 2 ;Jb = Jb 1 Jb 2 ; The wires used to plug the C i s together are still visible as outputs of the new component. Thus it is still possible to talk about them in Sg. But these are not visible to the environment as inputs. So, the assumption of C should not constraint variables in I 1 O 2 or I 2 O 1. Thus, we hide these variables in Sa (by using Sa O2 1 and Sa O1 2 ). Using the contracts to validate composition Contracts may be used to validate the composition (as in [21]). We can check that (Sg I2 2 ) O2\I1 Sa I1\O2 1 and that (Sg I1 1 ) O1\I2 Sa I2\O1 2. Of course, this is a necessary condition, but it is not sufficient (we adopt the optimistic view presented in [13]). i 1 i 2 C j 1 pre o 1 A o 2 1 G 1 j 2 A 2 G 2 C 1 C 2 Figure 2. An example composition Example 5 Fig. 2 shows all the possible kinds of connections between 2 components C 1 and C 2 defined with the following sets of inputs, outputs and local variables: I 1 = {i 1, j 1, O 1 = {o 1, j 2, L 1, A 1, G 1 = and I 2 = {i 2, j 2, O 2 = {o 2, j 1, L 2, A 2, G 2 =. The contracts are given below (we omit initial relations Ja 1, Ja 2, Jg 1 and Jg 2 ): Sa 1(i1, j1) : j1 0 (j1 < 0 i1 < 0); Sg 1(i1, j1, o1, j2) : j2 > 0 o1 > 0. Sa 2(i2, j2) : j2 > 0 (j2 0 i2 < j2 ); Sg 2(i2, j2, o2, j1) : j1 > 0 o2 > j1. We assume that the body of each component satisfies the associated contract. Now we wish to build the composition described in fig. 2. First, as mentioned above, we check that Sg 1 Sa {i2 2 and Sg 2 Sa {i1 1. So we verify that (j1 > 0 o2 > j1 ) = ( i1.j1 0 (j1 < 0 i1 < 0)) and that (p1 > 0 o1 > 0) = (j2 > 0 o1 > 0). Then we compute Sa and Sg. By applying the rule we defined earlier, we get (after simplifications): Sa(i1, i2) : j1, j2.(j2 > 0 i2 < j2 ) (j1 0 i1 < 0) Sg(i1, i2, o1, o2, j1, j2) : j1 > 0 j2 > 0 o1 > 0 o2 > 0 6. Conclusion and Further Work We proposed a model of reactive components equipped with logical-time contracts. The implementation in Java shows how the requirements on the separation fo concerns between the contract and the code can be made practical. We described synchronous networks of such components, that may be executed even if some of them are given by their contracts only. We are now working on case-studies. A library of building blocks used in SCADE designs is being rewritten with contracts. In this context, the language used for the contracts is Lustre, and formal verification tools can be used to check compositions and to reason about them. We are also looking at the definition of a generic language for contracts, in programming languages like Java. The idea would be to introduce a single new construct called PRE, and to write contracts using the full programming language and this construct. PRE(x), where x is a parameter of a method M, would mean: the value of x last time M was called. One can then write expressions like PRE(PRE(x)). This language could serve for the extraction of proof obligations, to be sent to a formal verification tool, or for the automatic generation of defensive code. If an

8 expression like PRE(PRE(x)) is used, generating defensive code means introducing the variables needed to store the two previous values of x. It would be very interesting not to be obliged to introduce such variables by hand. Finally, applying the ideas of [7] is very simple in the formal framework we gave: the asynchronous composition of C1 and C2 can be described by equipping each component with an additional Boolean input acting as a clock. Then the body of components is rewritten, taking this input into account, and stating that the component moves only when the input is true. This yields C1 and C2. The synchronous composition of C1 and C2 models the asynchronous behavior of C1 and C2. Arbitrary constraints may be stated on the two clocks, thus enabling to model various schedulers. This is a very general and simple framework to reason about contracts in an asynchronous setting. References [1] Harel, D., Pnueli, A.: On the development of reactive systems. In Apt, K.R., ed.: Logics and Models of Concurrent Systems. Volume 13 of NATO, ASI Series. Springer-Verlag, New York (1985) [2] Meyer, B.: Applying design by contract. IEEE Computer (1992) [3] Meyer, B.: Eiffel: An Introduction. Interactive Software Eng. (1988) [4] Kramer, R.: icontract the Java design by contract tool. TOOLS 26: Technology of Object-Oriented Languages and Systems, Los Alamitos, California (1998) [5] Rational Software Corp. et al.: Object Constraint Language Specification, version 1.1. (1997) documentation/formats.jtmpl. [6] Hayes, I.J., Jones, C.B.: Specifications are not (necessarily) executable. Technical Report 148, St. Lucia, Queensland, Australia 4072 (1990) [7] Halbwachs, N., Baghdadi, S.: Synchronous modeling of asynchronous systems. In: EMSOFT 02, Grenoble, LNCS 2491, Springer Verlag (2002) [8] Maraninchi, F., Morel, L.: Arrays and contracts for the specification and analysis of regular systems. In: Fourth International Conference on Application of Concurrency to System Design, Hamilton, Ontario, Canada (2004) [9] Halbwachs, N., Lagnier, F., Ratel, C.: Programming and verifying critical systems by means of the synchronous data-flow programming language LUSTRE. IEEE Transactions on Software Engineering, Special Issue on the Specification and Analysis of Real-Time Systems (1992) [10] Jones, C.B.: Specification and design of (parallel) programs. In Manson, R.E.A., ed.: Proceedings of IFIP 83, IFIP, North-Holland (1983) [11] McMillan, K.L.: The SMV system, symbolic model checking - an approach. Technical Report CMU-CS , Carnegie Mellon University (1992) [12] Alur, R., Henzinger, T.: Reactive modules. In: Proceedings, 11 th Annual IEEE Symposium on Logic in Computer Science, New Brunswick, New Jersey, IEEE Computer Society Press (1996) [13] de Alfaro, L., Henzinger, T.A.: Interface automata. In: Proceedings of the Ninth Annual Symposium on Foundations of Software Engineering, ACM Press (2001) [14] Ziemann, P., Gogolla, M.: An extension of OCL with temporal logic. In: Critical Systems Development with UML Proceedings of the UML 02 workshop, Technische Universität München, Institut für Informatik (2002) [15] Flake, S., Mueller, W.: An OCL extension for realtime constraints. Lecture Notes in Computer Science 2263 (2001) [16] Bartetzko, D., Fischer, C., Möller, M., Wehrheim, H.: Jass Java with assertions. In Havelund, K., Roşu, G., eds.: Runtime Verification. Volume 55 of ENTCS., Elsevier (2001) [17] Devadas, S.: Optimizing interacting finite state machines using sequential don t cares. IEEE Transaction of Computer-Aided Design 10 (1991) [18] Halbwachs, N., Lagnier, F., Raymond, P.: Synchronous observers and the verification of reactive systems. In Nivat, M., Rattray, C., Rus, T., Scollo, G., eds.: Third Int. Conf. on Algebraic Methodology and Software Technology, AMAST 93, Twente, Workshops in Computing, Springer Verlag (1993) [19] Fuchs, N.E.: Specifications are (preferably) executable. IEE/BCS Software Engineering Journal 7 (1992) [20] Raymond, P., Weber, D., Nicollin, X., Halbwachs, N.: Automatic testing of reactive systems. In: 19th IEEE Real-Time Systems Symposium, Madrid, Spain (1998) [21] Uchitel, S., Yankelevich, D.: Enhancing architectural mismatch detection with assumptions. In: proceedings of the 7th IEEE International Conference on the Engineering of Computer Based Systems (ECBS 2000). (2000)