An Algebraic Approach to Heterogeneous

Download PDF
0 downloads 0 Views 268KB Size Report
Comment
Jun 7, 2000 - Expression. Receipt ::= ? Variable : Type. Behaviour. ::= | Variable.EntryPoint. ;; entry point call. | Predicat -> Behaviour, Behaviour. ;; if then else.
An Algebraic Approach to Heterogeneous Software Systems Pascal André 1, Jean-Claude Royer 2 1 LARIMA, Institut National Polytechnique

2 IRIN, Université de Nantes

BP 1083, Yamoussokro, Côte d’Ivoire [email protected]

2 rue de la Houssinière, B.P. 92208, F-44322 Nantes cedex 3, France [email protected]

— Génie Logiciel, Méthodes et Spécifications Formelles —

R ESEARCH R EPORT No 00.7 June 2000

IRIN, Université de Nantes 2, rue de la Houssinière B.P. 92208 — F-44322 NANTES CEDEX 3

Pascal André, Jean-Claude Royer This work was presented at WADT’99 in Bonas, France, September 1999. 29 p.

Les rapports de recherche de l’Institut de Recherche en Informatique de Nantes sont disponibles aux formats PostScript® et PDF® à l’URL : http://www.sciences.univ-nantes.fr/irin/Vie/RR/ Research reports from the Institut de Recherche en Informatique de Nantes are available in PostScript® and PDF® formats through the URL: http://www.sciences.univ-nantes.fr/irin/Vie/RR/indexGB.html

© June 2000 by Pascal André, Jean-Claude Royer

An Algebraic Approach to Heterogeneous Software Systems Pascal André, Jean-Claude Royer

Abstract This report outlines a practical use of algebraic specification for the development of heterogeneous software systems. This kind of software mixes static, functional and dynamic aspects as in realistic examples and in some object-oriented methods. Static aspects are for example, types and signatures, components and their relations and so on. Functional aspects describe some semantics for operations or explicit some conditions and invariants of a component in the system. Dynamic aspects are related to the so-called dynamic behaviour of a system, it is also related to concurrency and communications. Furthermore state and behaviour of the system evolve along the time and operations may be available under some conditions. We define a methodology to extract an algebraic specification consistent with these different aspects of a system. This approach is based on a symbolic transition system which mainly describes a dynamic behaviour of the system and expresses some static aspects. The extraction method applies some simple principles: the use of the finite transition system and a generator-derivation mechanism to compute conditional axioms. This approach is extended to concurrent and communicating systems by a notion of synchronized product. We also introduce different features (super state, structured process and viewpoint) that make the description of such systems easier to read and write.

Categories and Subject Descriptors: D.2.4 [Software/Program Verification]: Formal methods—Algebraic Specifications; F.3.1 [Specifying and Verifying and Reasoning about Programs]: Specification Technique General Terms: Design, Verification Additional Key Words and Phrases: dynamic behaviour, algebraic data type, symbolic transition system, synchronized product, concurrency, communications, GAT.

1 Introduction We consider mixed or heterogeneous systems: complex and realistic systems where several formalisms are required to describe them. This kind of software mixes static, functional and dynamic aspects as in realistic examples and in some object-oriented methods. Static aspects are for example, types and signatures, components and their relations and so on. Functional aspects describe a semantics for operations or explicit some conditions and invariants of a component in the system. Dynamic aspects are linked to the so-called dynamic behaviour of a system, it is also related to concurrency and communications. Furthermore the state and the behaviour of the system evolve along the time and operations may be available under some conditions. A first problem with such systems is to ensure the consistency between the different descriptions. Another is to provide a specifier assistance for modelling the system and proving the expected properties. UML [25] is a language which proposes nine formalisms (diagrams) for modelling heterogeneous object systems. Unfortunately, the semantics of UML is not formal and therefore makes some elements ambiguous and contradictory. Several approaches for heterogeneous systems have been studied in the area of algebraic specifications [11, 10, 17, 8, 15, 12]. Astesiano et al. [10] distinguish four kinds of approach: the definition and use of an algebraic language (CSP, CCS), the use of ADT for modelling the data only (LOTOS), the dynamic sorts, i.e. types for processes (LTL), and dynamic ADT, where types change along the time. The GAT approach can be store in that last category because the states of the STS denotes types. Dynamic data types [11] consist in a hierarchy of four levels (value specification, instant structure specification, dynamic operation specification, higher-level dynamic specification). This is a general approach which can be the basis for different kinds of specification languages. A new integration paradigm is presented in [12], it has also four levels: data type, data state and transformation, process, and system architecture. This leads to complex approaches where the number of levels increases the power but decreases the ability to use the language. More simple approaches (LOTOS, GAT) use two levels: one for data type and one for process and system architecture. Many proposals separate the process calculi from the data calculi (LOTOS, PSF, High-Level Algebraic Petri Nets). We have chosen an integrated approach using a single semantic framework (dynamic data types algebraic specifications). This is a strength for consistency checking and proofs. Based on partial algebra, our model describes a system by a finite symbolic transition system (STS) coupled with an algebraic specification. This model fits to sequential systems with a logical time. Concurrent systems are structured using a synchronized product of STSs, where communications are implemented in a simple algebraic style. Thus a STS and its algebraic specification are computed for the whole system. In both cases, the proofs of properties of the system are achieved through an algebraic support. We formalize a notion of compatibility between a STS and an algebraic specification. In order to provide assistance for non-expert specifiers, we involved in the following principles: to provide a graphical editing environment, a specification process and automation, to guide the modelling choices, to provide tools and help for proving the system properties, and for prototyping. Our approach includes several automatic steps in the specification process, which makes it usable by a non expert user. The user gets several properties (like consistency and completeness) without many difficulties. The report is organized as follows. Section 2 describes the Graphical Abstract data Type (GAT) approach and the case study. Section 3 presents our notion of STS and a proper notion of semantic compatibility between a STS and an algebraic specification. The application of these concepts to a sequential component is done in Section 4. Section 5 extends this approach to concurrent and communicating systems by the way of a synchronized product of STS. Section 6 looks at a glance to other facilities and sketches the definition of an abstract language for structuring concurrent systems.

2 The GAT Approach GAT stands for Graphical Abstract data Type. It is a formalism with dynamic, static and functional descriptions for components.

6

2

THE GAT APPROACH

2.1 Overview We distinguish two kinds of components: sequential components and concurrent components. For each component we consider two views: the dynamic view and the functional view. The dynamic view describes the static part (operation signature) and the dynamic part of the component. The dynamic uses a notion of finite and symbolic transition system (STS). GAT is said to be graphical because the STS is built from a visual representation (automaton). The functional description is an algebraic specification of a partial abstract data type [7, 27]. In this research report we focus on the notion of STS, the synchronized product, and the application to a case study. We also formalize a notion of compatibility between a STS and an algebraic specification. We consider that our starting point is a preliminary decomposition of the system through structured and interacting components. This decomposition can be obtained by some already known methods like UML [25], see also [13, 22] for a related discussion about LOTOS which is relevant here. Our approach of the specification of components is based on a first assumption. The first view of a component is its dynamic (control, communication and synchronization). Our methodology suggests to start by specifying the dynamic view of objects: the operations and the conditions under which they apply. After that, the specifier should usually give the algebraic semantics for the operations. Instead of writing this algebraic specification from scratch, an algorithm called AG-derivation, guides this construction. It provides an operational specification style (functional programming style or “executable” specifications) where axioms are transformed into left-to-right conditional rewriting rules. A detailed presentation of GAT sequential components with its semantics and properties exist in [3]. Application to an information system is presented in [2]. GAT has been used as a basis for the definition of a new method for LOTOS specifications [22]. A similar approach with object-oriented code generation is applied to SDL in [23].

2.2 The Control Light System To practically illustrate our approach we apply it to a control light system. This case study focuses on the requirement capture, documentation and validation of an embedded software. An informal requirement document is provided in [6]. It includes user and system needs, building architecture description with the position of electrical components (lights, sensors, actuators). This is a quite complete and mixed example since it includes hardware and software parts, and also because static (structural), dynamic (events, real time) and functional aspects (command) are handled. By a first UML analysis we extract several packages, see Figure 1. Each package describes several static components and their relationships. In the sequel we consider two components: the push-button and the dimmable

Ligths

Sensors

Office_Control

Figure 1: UML Packages of the Control Light System light controller of the Office_Control package, see Figure 10 for a UML class diagram. A push-button is a simple sensor which can be pushed or released. The dimmable light controller (DLC) is a component devoted to the control of the brightness of a light. It can be either in normal mode or in safe mode depending whether the control system sent or not a cia signal. If this signal is not received every minutes, the mode is switched to safe mode. The push signal allows to light on or off the light, but it also depends on the ambient level of brightness. The dimValue action sets the level of brightness, however a pulse signal must be sent to validate the value.

7

phase pushbutton (cia) control system active

ControlSystem

Dimmable status line Light lamp

Controller

pulse

(DLC)

dimValue

Figure 2: The Push-Button and the Dimmable Light Controller

3 Finite and Symbolic Transition System The finite state machine formalism is well-known by practitioners. It is well-suited to the description of interactions and control. One problem with such a formalism is the great number of state and transitions. Several solutions are possible. For instance, one can combine state into super states or aggregate states as in [17]. However when the system has not a finite number of state one must use more powerful concepts. It often happens if one has a mixed system with both control and data types. We define a finite and symbolic transition system. This concept is related to machines where states and transitions are not necessarily unique objects. A state may represent a set of finite or infinite objects and a transition collects several state changes. This notion arises also from the need of the full semantics for a language like LOTOS [26].

3.1 STS Definition We consider Spe an algebraic specification of sort T I and a variable self : T I . A model of the specification is a partial algebra satisfying the axioms. Here we consider the initial semantics. The T I predicates are a set of distinguished unary predicate symbols on T I . We also consider two special T I predicates: the invariant and the definedness predicate. Informally, the invariant expresses a common property of values while the definedness predicate denotes that a value belongs to a particular partial algebra. Definition 3.1 (Set of States) Let Spe and fPei g1in a set of T I predicates, DT I the definedness predicate and I N V TT I the invariant. The set fei ; 1  i  ng is the set of states if and only if the following properties hold in the initial model: 8self : T I ; 8ei; ej ; ei 6= ej ; :(Pei (self ) ^ Pej (self )) (1)

(

DT I self

) = I N V T (self ) ^ TI

_



1

i

(

Pei self

)

(2)

n

Let fPei g1in a finite set of exclusive and complementary (relatively to DT I ) predicates, we associate a partial equivalence relationship defined as follows:

( ) ^ D (v0 ) => (R(v; v0 )() 9 ! e ; su h that P (v) ^ P (v0 ))

DT I v

TI

i

ei

ei

For each value of type T I there is one and only one associated state. Each Pei defines an equivalence class of values of any partial algebra model of Spe . A Symbolic Transition System is a finite set of state E and a finite set of labelled transition T . Unlike classic finite transition systems, the transition labels are operation calls with variables and a state does not necessarily denote a unique value. The Figure 3 illustrates the general form of such

8

3 FINITE AND SYMBOLIC TRANSITION SYSTEM

transitions. G is a predicate symbol denoting the guard (a condition to trigger the transition), f is the term label and v1 :::vn is a tuple of variables. self in this figure denotes a variable associated to T I such that Pei (self ) is true. [G(self, v1 ... vn)] f(self, v1 ... vn)

si

sj

Figure 3: Edge of the STS Definition 3.2 (Symbolic Transition System) Giving a Spe and a set of predicate fPei g1in , we define the associated STS (E; I ; T ): • E

= fe ; 1  i  ng is a set of states, v : T I in e () P (v), i

i

ei

• the set of initial states is a subset of E , • the transitions T of the STS are defined by the following interpretation formulas: an edge, from state ei to state ej , is labelled by [G(self, v1 ... vn)] f(self, v1 ... vn) if and only if

8v : T I ; 8 u ; :::; u 1

n

[

; Pei self =v

℄ ^ G[self =v; v1:::v

n

=u1 :::un

℄ =)

( [

Pej f self =v; v1:::vn =u1 :::un

℄)

The transitions correspond to internal operations of TI with the interpretation formulas based on state predicates. The term f can be any algebraic term. Our notion is more general than the symbolic transition graph defined in [18]. We have more general states (not only tuples of conditions) and we have no restriction on variables occurring on transitions.

3.2 The DLC Dynamic View What we call a dynamic view is a STS with static informations. Below is the example of the dynamic view for the dimmable light controller. There are four states: on, and off for the normal mode, and onSafe and offSafe for the safe mode. From the previous description of Section 2.2 we get several operations (pulse, push, cia and dimValue), and we add the following one’s. The status operation is required to distinguish the state of the lamp. We choose to represent time by operations count and top. The lastValue operation gives the level of brightness chosen by the system in a given state. Operation requiredValue is the same as lastValue but it is validated after a pulse signal. The value operation provides the level of brightness effectively sent to the light. A transition labelled with an operation name represents an event occurring on the component. The conditional transitions have a guard as additional label. For example, operation pulse changes the state from on to off if lastValue is between 0 and 9. Guards are named for writing facilities. The internal operations has TI as resulting type, solid arrows denote internal operations (cia, pulse, push, top, dimValue). The basic internal operations have no parameter of type TI, they are depicted with a dashed arrows (newDLC). The external operations or observers do not have TI as resulting type, they are drawn with dotted arrows (count, value, status, requiredValue, lastValue). No particular invariant is needed for the DLC, it is set to true. A GAT must have some additional properties. An important one is compactness which expresses that each state has at least one finitely generated value. Providing that guards are not equivalent to false, this property is ensured if each state is reachable from one initial state. This implies the algebraic specification to have a sensible signature. Another property is the determinism of the STS: in a given state, transitions labelled with the same operation have exclusive guards. These two properties are ensured in the DLC example.

3.3 Three Levels of Compatibility

9

requiredValue lastValue count

cia [not G4] push [not G3] pulse dimValue(self, dv) [G1] top

cia [G3] pulse dimValue(self, dv) push [not G3] pulse

[G1] top

on

off

Invariant:

[G4] push [G3] pulse

newDLC

[G2] top

cia

true Guards:

value status

[G2] top

cia

G1: count(self) < 59 G2: count(self) = 59 G3: lastValue(self) in 0..9

offSafe

push

onSafe

G4: requiredValue(self) = 100

push Figure 4: The GAT Dynamic Behaviour of DLC

3.3 Three Levels of Compatibility A major difficulty with mixed formalism is to get the different parts consistent in some way. We define a notion of compatibility suitable to our context. In fact three increasing levels of compatibility between a dynamic view and a functional view exist, see Figure 5. Syntactic compatibility: it means that the signatures are the same (of course this may be extended by renaming or some kind of morphism). State predicate compatibility: in addition to the first point the properties 1 and 2 of definition 3.1 are satisfied by each model of Spe . Semantic compatibility: the interpretation formulas (definition 3.2) associated to the transitions of the STS are satisfied by each model of Spe . The dynamic behaviour expressed by a dynamic view can be seen as an abstract interpretation of the functional behaviour denoted by the algebraic specification. When you glue a STS and an algebraic specification these levels of compatibility express the strength of the glue. Then it gives a compatibility notion between a dynamic part and a functional part. Checking the previous levels of compatibility must be integrated in the specification process. To split the compatibility into three levels makes its checking more easy to process. In fact, there are two main processes associated to a functional view and a dynamic view. • Extracting the algebraic specification is of course the most useful; we will discuss it in the following section. • The opposite way is automatic as soon as the guards are axiomatic in the chosen framework: the G guard associated to a transition from ei to ej is the characteristic function of the set

f(v; v1:::vn) j

( ) =) P (f (v; v1:::vn))g

Pei v

ej

10

4

SEQUENTIAL GAT

extracting the specification SORT: Dlc USE: Nat, Bool, ... SIGNATURE: the DLC of Figure 4

Dynamic Behaviour

newDlc : -> Dlc cia : Dlc -> Dlc pulse : Dlc -> Dlc .... AXIOMS: .... Functional Behaviour

computing the STS

Figure 5: Processes Between Functional and Dynamic Descriptions

4 Sequential GAT We use the GAT approach to specify sequential components. From now on we consider the extracting process based on the DLC dynamic view. Extracting an algebraic specification from a dynamic view has been studied in [3]. We recall here the main principles and properties.

4.1 The Extracting Process Let self be a well-defined term of the T I type of interest. Under the assumptions of Section 3, one may say that this term corresponds to a particular state ei . Two ways are then possible to define operations on this term: Selection by case principle: if ei is a super state, then we can split the study of self in several cases corresponding to the sub-states of ei . This case needs the notion of super state which will be introduced later (see Section 6.1). At least it applies to ei = ALL, which is the super state that contains all the sates of the GAT. G-derivation principle: if self is of state ei , then self can be written as a sequence of constructors reaching state ei . This principle is close to earlier works about -derivation [5]. In the example of Figure 3, let self be of state sj , a G-derivation of self along f would be f(self’, v1, ... vn) if si (self’) ^ G(self’, v1, ... vn). These two principles are the core of our computing algorithm, which is called the AG-derivation algorithm. Every axiom is a positive conditional axiom: condition ==> op(self, v1, ..., vn) = r, where the right-hand term (r) is given by the specifier, v1, ..., vn is a tuple of variable, and self is a G-derived term. A G-derived term is a constructor term with variables. The signature of the specification is automatically computed from the dynamic view. Moreover the transition system gives help in the constructor choice. Each state must be reachable by the constructors, this is a necessary condition to get the compactness property. A depth-first search computes the minimal family of constructors, the maximal set being the set of internal operations. Sometimes the specifier must complete the minimal set. In the DLC example, the chosen constructors are: {newDLC, push, cia, dimValue, pulse, top}. From the AG-derivation principles the specifier has mainly to provide right-hand conclusion terms of axioms. To extract the axioms describing an operation op(self, v1, ..., vn), the states having an outgoing transition labelled by op is possible are searched together with the constructors reaching these states. This generates

4.2 Some Properties

11

the axioms premises and the equations left-hand sides too. The definedness of terms occurring in axioms is automatically ensured by the generating process which adds the required preconditions. For example, let a part of the extracting process for the lastValue operation. This operation has an outgoing transition in the states on and off. Let us consider the constructors reaching the state off. There are eight constructors edges reaching this state. Below are the generated axioms for these edges. lastValue(newDLC) = 0; off(self) ^ G1(self) => lastValue(top(self)) = lastValue(self); off(self) => lastValue(dimValue(self, dv)) = dv; off(self) ^ G3(self) => lastValue(pulse(self)) = lastValue(self); on(self) ^ G3(self) => lastValue(pulse(self)) = lastValue(self); on(Self) ^ G4(Self) => lastValue(push(Self)) = 0; off(Self) => lastValue(cia(Self)) = lastValue(Self); offSafe(Self) => lastValue(cia(Self)) = 0; Because they are total operations, the axioms of state predicates, operation preconditions and definedness predicate are automatically computed by a simpler version of the AG-derivation algorithm. For example, the axioms for the on state predicate are: on(newDlc) = false on(top(self)) = (G1(self) ^ on(self)) on(dimValue(self, dv)) = on(self) on(pulse(self)) = (:G3(self) ^ (off(self) _ on(self))) on(push(self)) = (off(self) _ (:G4(self) ^ on(self))) on(cia(self)) = (on(self) _ onSafe(self)) The complete algebraic specification can be found in Appendix 9.1.

4.2 Some Properties This process is partly automatic, it is a great advantage for non expert users. The resulting specification has also some interesting properties. We implement the specification orienting axioms into left-to-right rewriting rules. The termination property is generally ensured because such systems have many properties [1]. The generated system is hierarchical, conditional, overlay-confluent and with constructors. Results on modularity of termination are pertinent here [9]. However the following scheme is often successful. Firstly, we replace the definitions of guard appearing in conditions. Secondly we associate weight to constructors. Thirdly we use a decreasing ordering [20] which sum the constructor weight coping with their depth in the term. Because of our generating method, which is based on [5], once termination is ensured we get consistency and sufficient completeness [3]. The two main reasons are: we get an overlay-confluent rewriting system because the state machine is deterministic and generated axioms respect the principle of sufficient completeness. These properties ensure the existence of a partial initial algebra. Of course we get syntactic compatibility but also state predicate compatibility (see Section 3.3). Semantic compatibility is true in case of a specification with only constructors, but generally it must be checked by hand. We actually focus on the use of Larch Prover [14] and it seems possible to help the specifier in this task.

5 Concurrent and Communicating Component To specify more complex systems we need concurrency and communications. We use a notion of synchronized product. The CeilingLightGroup (CLG), Figure 6, is a component built from two concurrent components:

12

5 CONCURRENT AND COMMUNICATING COMPONENT

Source State (s1 ;

s2 )

Transition Expression newProduct(actL(left(self), x*), actR(right(self), y*))

Target State (t1 ; t2 )

Guard condition

Table 1: The Table of Transitions a DLC and a push-button. The synchronization list [(push, push)] gives the actions which are required to synchronize. There is only synchronization on the push actions. The semantics of synchronization is done via the synchronized product of STS in a similar way as the synchronized product of automata [4]. Firstly, we built the free product of the two STSs. Secondly, we get out the pair of transitions which are not allowed by the list of synchronizations. Last, communications may enrich the synchronizations.

5.1 Free Product and Synchronization Rule Let Lef t = (E1 ; I1 ; T1 ) and Right = (E2 ; I2 ; T2 ) two STSs and V a synchronization list. The type associated to the product is the product of the types associated to the components. The sorts associated to the components are S1 and S2 and Product is the sort associated to the product. The signature of the specification associated to the product contains: a newProduct : S1 , S2 -> Product constructor and the left and right corresponding selectors. A transition expression for the product has the general form: newProduct(actL(left(self), x*), actR(right(self), y*)), where actL (respectively actR) is a transition expression for the left (respectively right) component. Definition 5.1 (Synchronization Rule) The synchronization list gives the pair of synchronized actions and couple of actions not in this list are asynchronous. In our example, the list is [(push, push)], the complete list of actions of the product is: {(push, push), (cia, ), (pulse, ),(top, ), (dimValue, ), (, release)}. The  denotes no action on the corresponding component. This is a similar rule as in LOTOS, note that other rules are also possible.

5.2 Synchronized Product of STSs A table of the legal transitions is built coping with the synchronization list. A transition expression belongs to the table if it is consistent with the synchronization rule of definition 5.1. The resulting ST S is (E; I ; T ) where I = I1  I2 and E  E1  E2 , E is the subset of states of the free product reachable from I using only the sequences of transitions in the table. This binary product easily extends to a product with any number of components. We compute a table of the transitions of the product by a simple algorithm. This table has four columns and each line represents a source state, a possible transition, the target state and a condition to trigger the transition. The guard column collects the conjunction of the conditions associated to the component transitions and conditions arising from communications. To build the table, first we put initial states of the product in the source state column. Then, we add the transition expressions starting from a source state and consistent with the synchronization rule. We also add the target state and the condition of this transition in the corresponding columns. The complete table is given in Appendix (Table 2).

5.3 Communications Distinct actions may be synchronized and communication is synchronous. During a synchronization values may be emitted or received following the ?X : T, and the !expression notations. Communications are possible during synchronization in the way depicted by Figure 7. In the Figure 7, left(self) and right(self) are algebraic terms denoting states of the component processes, actL and actR are synchronous actions. A value is emitted by an observer and a reception by the mean of an argument. Following the case illustrated in Figure 7, the transition expression is:

5.3 Communications

13

DLC (DimmableLightController) requiredValue lastValue count

cia [not G4] push [not G3] pulse dimValue(self, dv) [G1] top

cia [G3] pulse dimValue(self, dv) [G1] top

push [not G3] pulse on

off

Invariant:

[G4] push [G3] pulse

newDLC

[G2] top

cia

true Guards:

value status

cia

[G2] top

G1: count(self) < 59 G2: count(self) = 59 G3: lastValue(self) in 0..9

offSafe

push

onSafe

G4: requiredValue(self) = 100

push

[(push, push)] status

new

Invariant: push released

release

pushed

true Guards:

PushButton Figure 6: Product for the CeilingLightGroup Component

14

5 CONCURRENT AND COMMUNICATING COMPONENT

emit

! emit : an observer

?X : a parameter

[Gl(self, v1 ... vn)] actL(left(self), v1 ... vn) left(Self)

right(Self)

[Gr(self, X, u1 ... un)] actR(right(self), X, u1 ... um)

Figure 7: Implementation of Communications

newProduct(actL(left(self), v1 ... the value emitted is emit(left(self), w1 ... Gl(self, v1 ...

vn ), actR(right(self), X, u1 ...

um ))

wl ) thus we have the condition:

vn ) ^ Gr(self, X, u1 ... um ) ^ equal(X, emit(left(self), w1 ...

wl ))

Hence both synchronization and communication are integrated in an algebraic style.

5.4 Algebraic Specification Associated to the Product The construction of the corresponding algebraic specification is completely automatic. The signature has the previous newProduct, left, and right operations, a set of predicates and a definedness predicate. To define the axioms we use a simplified AG-derivation, there is a single non recursive constructor. For each pair of state of the product (t1 ; t2 ) we define a predicate P(t1 ;t2 ) . Axioms for the predicate are computed in the following way. (s1 ; s2 ), trexp, (t1 ; t2 ), condition For each line: in the table we generate: P(t1 ;t2 ) (trexp) = condition ^ P(s1 ;s2 ) (self). For the transition expressions which do not appear in the table we generate: P(t1 ;t2 ) (trexp) = false. The definedness predicate is generated in the same manner except with the formula: DP rodu t (trexp) = P(s1 ;s2 ) (self) ^ condition ^ DP rodu t (self ). where D is assumed to be strict relatively to all of its arguments.

5.5 Properties Compactness and determinism properties are ensured because components have these properties. State predicate exclusivity comes from the exclusivity of the components. Complementarity of the state predicates comes from the definition of the definedness predicate. Semantic compatibility is ensured by the construction of the table of transitions. We get an algebraic specification which is a simple product of two types. The properties of overlay-confluence, termination, consistency and sufficient completeness are achieved with similar proofs as in the sequential case. The specification is of course too simple for specifying complex systems, but we can extend it. It is possible to define other operations (internal or external) in a functional style over the current specification. The STS associated to the product and the AG-derivation is also useful in this case. These extensions have to keep the global system consistent and sufficiently complete. For each extension we define a precondition, and a set of axioms. Because there are relations between the definedness predicate and the precondition we have a means to check if the definition is consistent with the definedness predicate.

15

count requiredValue lastValue

ALL

dimValue(self, dv) [G1] top cia

value status

NORMAL

[not G3] pulse

[G3] pulse

[not G4] push push off

[G2] top

newDLC

on

[G4] push

cia

[G2] top

push

offSafe

cia

onSafe

push

Figure 8: A Super State for the DLC

6 Extensions We consider here some useful extensions of the previous concepts.

6.1 Super State A main problem with finite state machine is the explosion of the number of state. By the means of guards and STS, we control the explosion number of states. It is enforced by the concept of super state. A super state groups several source states with similar transitions. Two transitions are similar if they have the same guard and the same target or if they are state loops. For example, in Figure 4, the following transitions are similar : 1. off 2. off

[not

G3℄

!

ia

!

pulse

on and on

off and on

!

ia

[not

G3℄

!

pulse

on

on

From (1) one can build a super state, called NORMAL that includes the states off and on. From (2), we get a loop transition onto (super) state NORMAL. (1) NORMAL

[not

G3℄

!

pulse

on

(2) NORMAL ! NORMAL. This defines an equivalence relation on transitions. For example with the DLC the NORMAL super state groups states on and off. There are three similar transitions dimValue, top, and cia from an inner state to itself. There are also similar transitions with the pulse action. The super states make clear the state machine and the AG-derivation algorithm takes advantage of it to generate a simpler specification. Our super states are more restricted than those of Statecharts. Overlapping is prohibited, we only consider hierarchies of super states. One advantage of this is to get automatic computation of the hierarchy. The notion of super state is also useful for the STS associated to a product of STS. The product of two similar transitions is not (generally) a pair of similar transitions for the product. The STS of the product is computed and then a computation of the hierarchy may be done.

ia

16

6

EXTENSIONS

ALL

dimValue(self, dv)

requiredValue lastValue NORMAL

[not G3] pulse

[G3] pulse

value status count

[not G4] push push off

[G4] push

on

[G1] top [G2] top

control

noControl

newDLC cia

SAFE

offSafe

push

onSafe

push

normal-safe Viewpoint

cia

top-cia-count Viewpoint

Figure 9: Two Viewpoints for the DLC

6.2 Viewpoint It is possible to associate several STSs to a specification, this is a notion related to viewpoint. Viewpoints allow one to focus on different aspects of a system. The DLC has two viewpoints: a mode (normal or safe) and a ciatop-count viewpoint. The difficulty is to define the composition of several non independent viewpoints. One way is to define a matching between the states of the two viewpoints (morphism) then to make the union of the two STS which respect to this matching. Viewpoints seems useful but actually limited to the case of sequential GAT.

6.3 Structured Processes Now we want to specify more complex components which can be structured as a tree of communicating components. These components are trees with concurrent components as internal nodes and sequential components as leaves. A GAT component is either a sequential GAT or a structured (concurrent) component. A structured component has internal components, a synchronization expression and a list of entry points. The internal components are named and they are synchronized. The synchronization expression is a list of couples of synchronized actions. The entry points have a behaviour defined in a process algebra style. In our case study there are different kind of rooms with controller. Figure 10 is an example of a structured component for RoomController. Only the visible operations are displayed in this diagram. This figure, has been the starting point of our structured processes. Some operations vary because the the dynamic semantics is quite different in our model. In this case study an office is a particular room with doors, a control panel, a motion detector, a desk light, and two CeilingLightgroup. Figure 11 is an abstract grammar for structured components. The structured specification of the RoomController GAT is given in Appendix 9.3. This is a textual structured process algebra language. As with GAT we aim at defining a graphical counterpart (at least on a part) of this language for readability and communication reasons. An entry point may have associated communications and it is interpreted as a function. The structure of a complex component is interpreted as the synchronized product of the specifications associated to the components. The entry point behaviour is done by an extension of the specification associated to the structure. This gives a simple and intuitive semantics. Some assumptions about the properties of the product and the synchronizations have to be set. Our synchronization operator is not associative but multi-way synchronization using n-ary operator is allowed.

6.3 Structured Processes

17

Figure 10: The RoomController UML Class Diagram

18

Component

7

RELATED WORK

::= name: Name SequentialGAT | StructuredComponent

StructuredComponent

::= structure: (Variable : Component)* synchro: [tuplesof OperationName] entry: (EntryPoint = Behaviour)*

Definition ::= Behaviour | EntryPoint = Behaviour Communication ::= (Emission | Receipt)* Emission ::= ! Expression Receipt ::= ? Variable : Type Behaviour

::= | | | | |

Variable.EntryPoint ;; entry point call Predicat -> Behaviour, Behaviour ;; if then else Behaviour ; Behaviour ;; sequence Behaviour [] Behaviour ;; choice Expression.EntryPoint Communication || Expression.EntryPoint Communication

Figure 11: An Abstract Grammar for Structured Processes

7 Related Work A full comparison with existing works would be to0 long. Our approach is mainly related to LOTOS and LTL [8]. We give here two of the more relevant references, complementary informations may be found in [10]. An important concern, in our approach, is to provide help to the specifier to write the algebraic specification. We defined guidelines and tools to the specifiers. Our approach includes several automatic steps in the specification process, which makes it usable by a non expert user. The user gets several properties (like consistency and completeness) without many difficulties. Our approach also improves the consistency/compatibility between the different descriptions. This concern is neither addressed in LOTOS nor in LTL and AD-DT.

7.1 Comparison with LOTOS As in LOTOS we focus on system with dynamic and functional parts. Our language, rather sketched here, is different on some syntactic aspects. We allow synchronization of different entry points, and we have default hiding. There are also differences about properties of the synchronization operator. These are not really important differences. The main difference is about the semantics which is uniform with partial abstract data types. However standard semantics of LOTOS does not take into account full data types but only ground expressions. Standard LOTOS semantics is restricted to finite state machines. Full LOTOS semantics is close to ours but it is twofold. Symbolic semantics for Full LOTOS is a way to overcome this limitation [19]. Dynamic properties are proved on the STS with the help of an oracle on data types. Proofs in our context use only one formalism and one environment.

7.2 Comparison with LTL We agree with the Reggio and Larosa point of view [24] about the real application of formal methods. We also aim at providing guidelines, friendly presentation and tools for non-academic people. The main difference between our approach and LTL is that their graphic notation is an exact representation of their axiomatic while in the GAT, graphic notation is a first step in specification (abstract model). A LTL transition is a conditional axiom while a GAT transition is a set of conditional axioms. Thus the source state and the target state of a transition in LTL is a term. A LTL macro-state groups states of the same kind (same shape for their term). A GAT state corresponds to a LTL macro-state, except that it has no special term representation. LTL graph structuration is done through specification structuration. LTL distinguishes simple systems (close to GAT) and concurrent systems. Extensions to concurrent GAT exists [2, 22].

7.3 Some Drawbacks

19

Our approach and abstract dynamic data types (AD-DT [8]), use partial abstract data type. In AD-DT the transition system is represented by a ternary predicate. Our approach is simpler because we have no need for labels and no need for special predicates. In AD-DT we have a transition system and an algebraic specification, in our approach we have a symbolic transition system inside an algebraic specification. Both approaches have the same expressive power. We have no temporal logic but we can reuse the [8] approach.

7.3 Some Drawbacks We already have found some limitations of our approach. This approach produces more complex specifications, because of the repetition of some parts of axioms. Simplifications are often possible as we can see in the lastValue example. We postpone them until the specification is valid, because when a mistake is detected we fix it by local modifications. To the contrary with a simplified specification, it implies a complete run of the specification process. Our generated specifications are operational, for some peoples it is a drawback but for other it is an advantage. One possible solution to overcome the need of non operational specification is to consider our generated specifications as a first refinement of a more abstract and non operational specification. There are other difficulties, for example some conditions are needed to specify some operations and they can emerged from AG-derivation on arguments. Sometimes hidden and auxiliary operations are needed, we cannot actually give a method to help the user in this task. We have no real time aspects, one possible way seems to introduce an ADT time as in [21]. In this work real time and concurrency are specified in a purely algebraic framework. This work overcomes some usual limitations of algebraic specifications. It allows to express true concurrency with no need of interleaving semantics.

8 Conclusion The GAT concept seems to be limited but it is a really useful. Our experiments have shown that the specifier concentrates its efforts on the design of the dynamic description. It simplifies the overall task. But this first specification is very important and must be well-designed. It is easy and quick to modify the STS and to produce the associated specification. We reuse this concept in methods to LOTOS and SDL [22, 23]. One of the main interest of this kind of approach is that most parts are automatic and do not require an expert specifier. Some tools can be implemented to assist users, in fact some already exist. We implemented a CASE Tool, called ASFO, for GAT sequential components. It includes editing facilities for the STS and an assistant for extracting the algebraic specification from the STS. The target language is a general algebraic language and the tool provides a translation into the Larch Prover language (LP) [14]. This case tool is implemented in the VisualWorks for Smalltalk-80 environment of ParcPlace systems. Another tool, CLAP, permits to define statetransition diagrams and their synchronized products. New developments will integrate CLAP into ASFO and will extend AG-derivation to the product of STSs. These tools are available at: http://www.sciences.univ-nantes.fr/info/recherche/mgl/FRANCAIS/ ThemesetProjets/ASFO/indexE.html ThemesetProjets/SHES/CLAP/ In our specifications we have two parts, dynamic and functional, with a strong compatibility between them. This compatibility is obtained by an extracting process which is simple and partly automatic. Important properties (termination, consistency, completeness) are got with only few difficulties. We give a uniform semantics to heterogeneous systems with algebraic specifications. This approach is related to semantics for Full LOTOS but we have a one part semantics. Our approach is rather pragmatic, but we already have formalized some parts. The notion of compatibility is formalized and the extracting algorithm. We have proved that the rewriting system is terminating and the consistency and the completeness of our generated specifications. Our semantics uses partial abstract data type, an approach based on first-order and partial structures (chapter 3 of [16]) seems more suitable. The concurrent approach must be improved both theoretically and practically. A last point to note is that the dynamic behaviour of a system is embedded in the algebraic specification. Thus proofs of dynamic properties may be successful using a theorem prover. We have done small experiments in this

20

REFERENCES

area using Larch Prover. This seems promising, but one may argue that it is not a good way to do that. Model checking is automatic and more efficient in this case. However usual model checking is not possible here because we have not a finite state machine.

References [1] Sylvère A BBAD. Terminaison pour les TAG. Rapport de DEA, IRIN, Septembre 1999. [2] Pascal A NDRÉ et Jean-Claude ROYER. The Invoicing System: Using GAT. In Michel A LLEMAND, Christian ATTIOGBÉ, et Henri H ABRIAS, éditeurs, Comparing Systems Specification Techniques: "What questions are prompted by ones particular method of specification?", ISBN: 2-906082-29-5, pages 381–395, Nantes, France, March 1998. [3] Pascal A NDRÉ et Jean-Claude ROYER. Building Executable namic Descriptions. Rapport de recherche, IRIN, June 1999. nantes.fr/info/perso/permanents/royer/papers/fac99.ps.gz.

Data Types from Dyhttp://www.sciences.univ-

[4] André A RNOLD. Systèmes de transitions finis et sémantique des processus communiquants. Collection Etudes et Recherches en Informatique. Masson, 1992. [5] Michel B IDOIT. Types abstraits algébriques : spécifications structurées et présentations gracieuses. Colloque de l’AFCET : les mathématiques de l’informatique Paris, pages 347–357, 1982. [6] E. B ÖRGER, B. H ÖRGER, D. PARNAS, et D. ROMBACH. Seminar No. 99241 - Requirements Capture, Documentation and Validation. Technical report, Schloss Dagstuhl, Wadern, Germany, Juin 1999. [7] Manfred B ROY, Martin W IRSING, et Claude PAIR. A Systematic Study of Models of Abstract Data Types. Theoretical Computer Science, 33:139–174, 1984. [8] Gerardo C OSTA et Gianna R EGGIO. Specification of abstract dynamic-data types: A temporal logic approach. Theoretical Computer Science, 173(2):513–554, 28 Février 1997. [9] Nachum D ERSHOWITZ. Hierarchical Termination. In Fourth International Workshop on Conditional (and Typed) Rewriting Systems, volume 968 of LNCS, pages 89–105, Amsterdam, 1995. Springer Verlag. [10] M. Broy E. A STESIANO et G. R EGGIO. IFIP WG 1.3 Book on Algebraic Foundations of System Specification, chapter Algebraic Specification of Concurrent Systems. Springer Verlag, 1999. [11] Hartmut E HRIG et Fernando O REJAS. Dynamic Abstract Data Types: An Informal Proposal. EATCS Bulletin, 53:162–169, Juin 1994. [12] Hartmut E HRIG et Fernando O REJAS. Integration and Classification of Dynamic Types and Process Specification Techniques. Rapport technique, Berlin, Juillet 1998. [13] Hubert G ARAVEL et Carlos RODRIGUEZ. An example of LOTOS Specification: The Matrix Switch Problem. Rapport SPECTRE C22, Laboratoire de Génie Informatique — Institut IMAG, Grenoble, June 1990. Available at http://www.inrialpes.fr/vasy/Publications/Garavel-Rodriguez-90.html. [14] Stephan G ARLAND et John G UTTAG. An overview of LP, the Larch Prover. In Proc. of the third International Conference on Rewriting Techniques and Applications, volume 355 of Lecture Notes in Computer Science. Springer-Verlag, 1989. [15] M.-C. G AUDEL, C. K HOURY, et A. Z AMULIN. Dynamic Systems with Implicit State. Lecture Notes in Computer Science, 1577:114–128, 1999. [16] IFIP Working G ROUP. Algebraic Foundations of System Specification. Springer Verlag, 1999.

21

[17] David H AREL. Statecharts: A visual formulation for complex systems. Science of Computer Programming, 8(3):231–274, June 1987. [18] M. H ENNESSY et H. L IN. Symbolic Bisimulations. Theoretical Computer Science, 138(2):353–389, 1995. [19] Carron K IRKWOOD et Muffy T HOMAS. Towards a Symbolic Modal Logic for LOTOS. In Northern Formal Methods Workshop NFM’96, eWIC, 1997. [20] J.W. K LOP. Term Rewriting Systems, chapter 1, pages 1–117. Handbook of Logic in Computer Science. Oxford University Press, Oxford, 1992. [21] Teodor K NAPIK. Concurrency and Real-Time Specifications with Many-Sorted Logic and Abstract Data Type: an Example. In Proceedings of the CARI Conference. INRIA, october 1994. Ouagadougou. [22] Pascal P OIZAT, Christine C HOPPY, et Jean-Claude ROYER. Concurrency and Data Types: a Specification Method. An Example with LOTOS. In J. F IADERO, éditeur, Recent Trends in Algebraic Development Techniques, Selected Papers of the 13th Workshop on Algebraic Development Techniques, WADT’98, volume 1589 of Lecture Notes in Computer Science, pages 276–291. Springer-Verlag, 1999. ISBN 3-540-66246-4. [23] Pascal P OIZAT, Christine C HOPPY, et Jean-Claude ROYER. From Informal Requirements to COOP: a Concurrent Automata Approach. In J.M. W ING AND J. W OODCOCK AND J. DAVIES, éditeur, FM’99 - Formal Methods, World Congress on Formal Methods in the Development of Computing Systems, volume 1709 of Lecture Notes in Computer Science, pages 939–962, Toulouse, France, 1999. Springer-Verlag. ISBN 3-54066588-9. [24] G. R EGGIO et M. L AROSA. A Graphic Notation for Formal Specifications of Dynamic Systems. In J. F ITZGERALD et C.B. J ONES, éditeurs, In Proceedings FME’97, volume 1313 of LNCS, pages 40–56. Springer Verlag, 1997. [25] James RUMBAUGH, Ivar JACOBSON, et Grady B OOCH. The Unified Modeling Language Reference Manual. Addison-Wesley, 1999. [26] Carron S HANKLAND, Muffy T HOMAS, et Ed B RINKSMA. Symbolic Bisimulation for Full LOTOS. In Algebraic Methodology and Software Technology AMAST’97, volume 1349 of Lecture Notes in Computer Science, pages 479–493. Springer-Verlag, 1997. [27] Martin W IRSING. Algebraic Specification, volume B of Handbook of Theoretical Computer Science, chapter 13, pages 675–788. Elsevier, 1990. Jan Van Leeuwen, Editor.

9 Appendix 9.1 The DLC Larch Prover Specification set name DLC declare sorts Dlc declare variables self : Dlc, dv : Nat declare operators newDlc : -> Dlc push : Dlc -> Dlc cia : Dlc -> Dlc dimValue : Dlc, Nat -> Dlc pulse : Dlc -> Dlc value : Dlc -> Nat requiredValue : Dlc -> Nat lastValue : Dlc -> Nat top : Dlc -> Dlc count : Dlc -> Nat

22

status off on offSafe onSafe G1 G2 G3 G4 ..

9

: : : : : : : : :

Dlc Dlc Dlc Dlc Dlc Dlc Dlc Dlc Dlc

-> Bool -> Bool -> Bool -> Bool -> Bool -> Bool -> Bool -> Bool -> Bool

assert sort Dlc generated by newDlc, push, cia, dimValue, pulse, top; %--------------% preconditions %--------------%precondition(newDLC) == true %precondition(push(self)) == true %precondition(pulse(self)) == off(self) \/ on(self) %precondition(top(self)) == off(self) \/ on(self) %precondition(count(self)) == off(self) \/ on(self) %precondition(dimValue(self, v)) == off(self) \/ on(self) %precondition(value(self)) == off(self) \/ on(self) %precondition(lastValue(self)) == off(self) \/ on(self) %precondition(requiredValue(self)) == off(self) \/ on(self) %precondition(cia(self)) == true %precondition(status(self)) == true %precondition(off(self)) == true %precondition(on(self)) == true %precondition(offSafe(self)) == true %precondition(onSafe(self)) == true %precondition(G1(self)) == true %precondition(G2(self)) == true %precondition(G3(self)) == true %precondition(G4(self)) == true %------------------------%predicats d’etat ~offSafe(newDlc); offSafe(top(self)) = (G2(self) /\ off(self)); ~offSafe(dimValue(self, dv)); ~offSafe(pulse(self)); offSafe(push(self)) = onSafe(self); ~offSafe(cia(self)); ~onSafe(newDlc); onSafe(top(self)) = (G2(self) /\ on(self)); ~onSafe(dimValue(self, dv)); ~onSafe(pulse(self)); onSafe(push(self)) = offSafe(self); ~onSafe(cia(self)); % count %off count(newDlc) = 0; off(self) /\ G1(self) => count(top(self)) = 1+count(self); off(self) => count(dimValue(self, dv)) = count(self); off(self) /\ G3(self) => count(pulse(self)) = count(self); on(self) /\ G3(self) => count(pulse(self)) = count(self); on(self) /\ G4(self) => count(push(self)) = count(self); off(self) => count(cia(self)) = 0; offSafe(self) => count(cia(self)) = 0; %on

APPENDIX

9.1 The DLC Larch Prover Specification

on(self) /\ G1(self) => count(top(self)) = 1+count(self); on(self) => count(dimValue(self, dv)) = count(self); on(self) /\ ~G3(self) => count(pulse(self)) = count(self); off(self) /\ ~G3(self) => count(pulse(self)) = count(self); on(self) /\ ~G4(self) => count(push(self)) = count(self); off(self) => count(push(self)) = count(self); on(self) => count(cia(self)) = 0; onSafe(self) => count(cia(self)) = 0; % requiredValue %off requiredValue(newDlc) = 0; off(self) /\ G1(self) => requiredValue(top(self)) = requiredValue(self); off(self) => requiredValue(dimValue(self, dv)) = requiredValue(self); off(self) /\ G3(self) => requiredValue(pulse(self)) = lastValue(self); on(self) /\ G3(self) => requiredValue(pulse(self)) = lastValue(self); on(self) /\ G4(self) => requiredValue(push(self)) = 0; off(self) => requiredValue(cia(self)) = requiredValue(self); offSafe(self) => requiredValue(cia(self)) = 0; %on on(self) /\ G1(self) => requiredValue(top(self)) = requiredValue(self); on(self) => requiredValue(dimValue(self, dv)) = requiredValue(self); on(self) /\ ~G3(self) => requiredValue(pulse(self)) = lastValue(self); off(self) /\ ~G3(self) => requiredValue(pulse(self)) = lastValue(self); on(self) /\ ~G4(self) => requiredValue(push(self)) = 100; off(self) => requiredValue(push(self)) = 100; on(self) => requiredValue(cia(self)) = requiredValue(self); onSafe(self) => requiredValue(cia(self)) = 100; %------% lastValue %off lastValue(newDlc) = 0; off(self) /\ G1(self) => lastValue(top(self)) = lastValue(self); off(self) => lastValue(dimValue(self, dv)) = dv; off(self) /\ G3(self) => lastValue(pulse(self)) = lastValue(self); on(self) /\ G3(self) => lastValue(pulse(self)) = lastValue(self); on(self) /\ G4(self) => lastValue(push(self)) = 0; off(self) => lastValue(cia(self)) = lastValue(self); offSafe(self) => lastValue(cia(self)) = 0; %on on(self) /\ G1(self) => lastValue(top(self)) = lastValue(self); on(self) => lastValue(dimValue(self, dv)) = dv; on(self) /\ ~G3(self) => lastValue(pulse(self)) = lastValue(self); off(self) /\ ~G3(self) => lastValue(pulse(self)) = lastValue(self); on(self) /\ ~G4(self) => lastValue(push(self)) = 100; off(self) => lastValue(push(self)) = 100; on(self) => lastValue(cia(self)) = lastValue(self); onSafe(self) => lastValue(cia(self)) = 100; %------% value off(self) => value(self) = 0; on(self) => value(self) = requiredValue(self); offSafe(self) => value(self) = 0; onSafe(self) => value(self) = 100; % status status(self) = (on(self) \/ onSafe(self)); % guads G1(self) = inf(count(self), 58); G2(self) = equal(count(self), 59);

23

24

9

APPENDIX

G3(self) = (inf(0, lastValue(self)) /\ inf(lastValue(self), 9)); G4(self) = equal(requiredValue(self), 100); ..

9.2 The Table for the CeilingLightGroup The table for the synchronized product of Figure 6 has eight states and thirty four transitions. This product can be automatically computed with the CLAP environnement, see http://www.sciences.univ-nantes.fr/info/perso/permanents/allemand/SHES.

9.3 Structured Process for the RoomController % AL = Ambient Light % LS = LightScene SeqGAT name: DLC public : newDLC push pulse dimValue(v) cia top value status hidden : lastValue requiredValue EndSeqGAT SeqGAT PushButton public : newPB push release EndSeqGAT strGAT name: CeilingLightGroup structure : dlc : DLC, pb : PushButton sync : (dlc.push,pb.push) entry : pulse = dlc.pulse, push = dlc.push || pb.push, cia = dlc.cia, top = dlc.top, dimValue(dv) = dlc.dimValue(dv), value(dv) = dlc.value(dv), status = dlc.status, release = pb.release EndStrGAT SeqGAT name: TaskLightState public : setOn setOff toggle value status EndSeqGAT

9.3 Structured Process for the RoomController

Source State (off,released) (off,released) (off,released) (off,released) (off,released) (off,released) (off,released) (offSafe,released) (offSafe,released) (onSafe,released) (onSafe,released) (offSafe,pushed) (onSafe,pushed) (on,released) (on,released) (on,released) (on,released) (on,released)

Transition Expression newCLG(top(left(self)), right(self))) newCLG(dimValue(left(self), dv), right(self))) newCLG(pulse(left(self)), right(self))) newCLG(cia(left(self)), right(self))) newCLG(push(left(self)), push(right(self)))) newCLG(pulse(left(self)), right(self))) newCLG(top(left(self)), right(self))) newCLG(cia(left(self)), right(self))) newCLG(push(left(self)), push(right(self)))) newCLG(push(left(self)), push(right(self)))) newCLG(cia(left(self)), right(self))) newCLG(cia(left(self)), right(self))) newCLG(cia(left(self)), right(self))) newCLG(top(left(self)), right(self))) newCLG(top(left(self)), right(self))) newCLG(dimValue(left(self), dv), right(self))) newCLG(pulse(left(self)), right(self))) newCLG(pulse(left(self)), right(self)))

Table 2: The Table of Transitions (Part 1)

25

Target State

Guard

(off,released)

G1

(off,released) (off,released)

G3

(off,released) (on,pushed) (on,released)

not G3

(offSafe,released)

G2

(off,released) (onSafe,pushed) (offSafe,pushed) (on,released) (off,pushed) (on,pushed) (on,released)

G1

(onSafe,released)

G2

(on,released) (on,released)

not G3

(off,released)

G3

26

9

Source State (on,released) (on,released) (on,released) (off,pushed) (off,pushed) (off,pushed) (off,pushed) (off,pushed) (off,pushed) (off,pushed) (on,pushed) (on,pushed) (on,pushed) (on,pushed) (on,pushed) (on,pushed)

Transition Expression newCLG(cia(left(self)), right(self))) newCLG(push(left(self)), push(right(self)))) newCLG(push(left(self)), push(right(self)))) newCLG(left(self), release(right(self)))) newCLG(top(left(self)), right(self))) newCLG(dimValue(left(self), dv), right(self))) newCLG(pulse(left(self)), right(self))) newCLG(cia(left(self)), right(self))) newCLG(pulse(left(self)), right(self))) newCLG(top(left(self)), right(self))) newCLG(top(left(self)), right(self))) newCLG(top(left(self)), right(self))) newCLG(dimValue(left(self), dv), right(self))) newCLG(pulse(left(self)), right(self))) newCLG(pulse(left(self)), right(self))) newCLG(cia(left(self)), right(self)))

Target State

APPENDIX

Guard

(on,released) (on,pushed)

not G4

(off,pushed)

G4

(off,realeased) (off,pushed)

G1

(off,pushed) (off,pushed)

G3

(off,pushed) (on,pushed)

not G3

(offSafe,pushed)

G2

(on,pushed)

G1

(onSafe,pushed)

G2

Table 3: The Table of Transitions (Part 2)

(on,pushed) (on,pushed)

not G3

(off,pushed)

G3

(on,pushed)

9.3 Structured Process for the RoomController

StrGAT name: TaskLight structure : tls : TaskLightState, pb : PushButton entry : push = OFF(tls) -> setOn , setOff release = pb.release value = tls.value status = tls.status EndStrGAT SeqGAT name: MotionDetector public : newMD detect delay failure repair value status EndSeqGAT SeqGAT name: OutdoorLightSensor public : setIlluminance (v) failure repair value status EndSeqGAT SeqGAT name: DoorContact public : open close value status EndSeqGAT SeqGAT name: Timer public : arm (delay : int) timeOut delay reset hidden : count EndSeqGAT SeqGAT name: LightScene public : offLS newLS (n : string, ai : int, di : int, ll : List [int]) name ambient_illuminance desk_illuminance lle1 lle2 dl EndSeqGAT SeqGAT name: ControlPanel public : newCP () switchTaskLight

27

28

9

APPENDIX

switchCeilingG1 switchCeilingG2 setALLevel (v : int) addLS (ls : LightScene) selectLS : LightScene lls display (msg) EndSeqGAT SeqGAT name: RoomControllerSettings public : newRCS (t1 : int; t3 : int; ls : LightScene, al : int) setT1(t : int) setT3 (t : int) set_default_LS (ls : LightScene) set_default_AL (al : int) set_current_LS (ls : LightScene) set_current_AL (al : int) computeLSfromAL (al : int) computeALfromLS (ls : LightScene) empty set_mem_LS restore_mem_LS default_LS default_AL current_LS current_AL EndSeqGAT StrGAT name: RoomController structure : lle1 : CeilingLightGroup, lle2 : CeilingLightGroup, imd : MotionDetector ols : OutdoorLightSensor t : Timer tl : TaskLight dcc : List [DoorContact] cp : ControlPanel rcs : RoomControllerSettings sync : (set_current_AL, update) (set_current_LS, update) (alarmT1, update) (alarmT3, update) (switchOff, update) (alarmT3, switchOff ) entry : switchOff = lle1.dimValue(0) || lle2.dimValue(0) || tl.push push = tl.push [] lle1.push [] lle2.push release = tl.release [] lle1.release [] lle2.release pulse = lle1.pulse || lle1.pulse cia = lle1.cia || lle2.cia top = lle1.top || lle2.top || t1.top || t2.top setT1(v) = rcs.setT1(v) || t1.arm(v) setT3(v) = rcs.setT3(v) || t3.arm(v) leaveRoom = (imd.status = 1 and imd.value = 0 and dcc.status = 0) --> t1.reset || t3.reset || rcs.set_mem_LS alarmT1 = t1.timeout || rcs.set_current_LS (rcs.default_LS) alarmT3 = t3.timeout || rcs.set_current_LS (offLS) move = imd.detect || empty(cts) -> cts.restore_mem_LS || t1.reset || t2.reset delay = imd.delay sensorEvent= (imd.status = 1 --> imd.failure, imd. repair) [] (ols.status = 1 --> ols.failure, ols.repair) || cp.display(msg) setIlluminance(v) = ols.setIlluminance(v)

9.3 Structured Process for the RoomController

29

doorEvent = oneOf(dcc).open [] oneOf(dcc).close swichTL = cp.switchTaskLight || tl.push swichCL1 = cp.switchCeilingG1|| lle1.push swichCL2 = cp.switchCeilingG1|| lle1.push set_current_LS ?ls : LightScene = rcs.set_current_LS !ls || cp.selectLS !currentLS set_current_AL(al) = rcs.set_current_AL(al)|| cp.setALLevel(al) addLS (ls) = cp.addLS(ls) update = rcs.idle !(rcs.currentLS).lle1 !(rcs.currentLS).lle2 !(rcs.currentLS).tl || lle1.dimValue ?d set_default_AL (al) = rcs.set_default_AL (al) EndStrGAT

An Algebraic Approach to Heterogeneous Software Systems Pascal André, Jean-Claude Royer

Abstract This report outlines a practical use of algebraic specification for the development of heterogeneous software systems. This kind of software mixes static, functional and dynamic aspects as in realistic examples and in some object-oriented methods. Static aspects are for example, types and signatures, components and their relations and so on. Functional aspects describe some semantics for operations or explicit some conditions and invariants of a component in the system. Dynamic aspects are related to the so-called dynamic behaviour of a system, it is also related to concurrency and communications. Furthermore state and behaviour of the system evolve along the time and operations may be available under some conditions. We define a methodology to extract an algebraic specification consistent with these different aspects of a system. This approach is based on a symbolic transition system which mainly describes a dynamic behaviour of the system and expresses some static aspects. The extraction method applies some simple principles: the use of the finite transition system and a generator-derivation mechanism to compute conditional axioms. This approach is extended to concurrent and communicating systems by a notion of synchronized product. We also introduce different features (super state, structured process and viewpoint) that make the description of such systems easier to read and write.

Categories and Subject Descriptors: D.2.4 [Software/Program Verification]: Formal methods—Algebraic Specifications; F.3.1 [Specifying and Verifying and Reasoning about Programs]: Specification Technique General Terms: Design, Verification Additional Key Words and Phrases: dynamic behaviour, algebraic data type, symbolic transition system, synchronized product, concurrency, communications, GAT.

IRIN, Université de Nantes 2, rue de la Houssinière B.P. 92208 — F-44322 NANTES CEDEX 3