North-Holland Microprocessing and Microprogramming 28 (1989) 3-8 3

E x p a n s i o n o f L O T O S B e h a v i o u r E x p r e s s i o n s as a n E x e r c i s e in T r a n s f o r m a t i o n a l Des ign

Carlos Delgado Kioos, Gregorio Gonz~lez Martfnez

Depto. Ingenier/a de Sistemas Telem~ticos, Esc. Tdc. Sup. Ingenieros de Telecomunicacidn Universidad Politdcnica de Madrid, Ciudad Universitaria E-28040 Madrid, Spain (E-mail: cdelgado@dit .upm.es)

The purpose of this paper is twofold: First, we want to present a language for formulating the transfor- mational development of specifications in the concurrent language LOTOS. Second, we want to show how to define a composite transformational rule for the expansion of behaviour expressions in this language. This example is relatively simple, but interesting enough to show the power of our transformational language.

1 I n t r o d u c t i o n

LOTOS is a concurrent language designed for the speci- fication of computer protocols, but any concurrent, dis- t r ibuted system can be modelled with it; this includes also digital circuits.

The process of building a complex specification by re- fining an initial one is a difficult task. In the case of LOTOS, several methodologies (e.g. the constraint ori- ented methodology) and different ways of refinement are being tested and validated against examples. Sev- eral approaches have been envisaged to support this activity within integrated environments by designing several tools. One of the promising approaches is to use a transformational methodology. Within this method- ology, successive versions of LOTOS specifications are obtained by applying transformation rules. The dif- ferent versions are formally related by some relation embodied in the rules. As an example of a transfor- mational system and the associated methodology, see e.g. [Bauer et al. 89] for the CIP approach. For our particular approach we refer to [LeSn, Delgado Kloos 89].

In the transformational methodology, we have LOTOS specifications as objects about which we reason. We transform specifications by applying rules to them. The rules might be semantics-preserving, or restrict the he- haviour w.r.t, some relation. In order to manipulate LOTOS specifications, another language, a metalan- guage, is needed. We have defined a language for this purpose, which we call TransLOtOS.

Although a transformational development may be in general an interactive activity, many developments can be fully automized in form of an algorithm that succe- sively applies transformation rules at specified places.

In this paper we give an example of such a transfor- mational algorithm, which is simple enough but also poses some requirements to the language for express- ing the development algorithm. The example consists of the expansion of behaviour expressions in LOTOS. For making it understandable, we first briefly review the behaviour part of LOTOS, then present the meta- language TransLOtOS , and give some examples of trans- formation rules. Then, we explain the expander of be- haviour expressions built as a transformation rule com- posed from simpler rules. Finally, we address some is- sues concerning the implementation of our transforma- tion system and some remarks putting this work into the context of other related fields.

2 B r i e f Survey of L O T O S

LOTOS (Language o_f Temporal Ordering Specification) is an FDT (Formal Description Technique) adopted as a s tandard by the ISO (International Standards Orga- nization) for the formal description of OSI (Open Sys- tem Interconnection) protocols and service definitions [ISO 87]. The main idea behind LOTOS is that systems can he described by the temporal relationship between events in their externally observable behaviour. The description of a system is done in LOTOS by means of processes. A whole system can be viewed as a sin- gle process, composed itself by several interacting pro- c e s s e s .

LOTOS consists of two parts. The first one is based on a modification of the Calculus of Communicating Sys- tems (CCS) [MUner 80], that includes elements from CSP (Communicating Sequential Processes) [Hoare 851, and describes the process behaviours and interactions.

4 C.D. Kloos, G.G. Martfnez / Expansion of LOTOS Behaviour Expressions

The second part deals with the description of data types and value expressions and is based on the ab-

stract data type language ACT ONE [Ehrig, Mahr 85].

In the behaviour part of LOTOS, one has events, which are the basic indivisible units of interaction. There is one particular event i, which is called the internal event

and represents an unobservable event. Distributed sys-

tems are described in terms of processes, stop repre- sents the completely inactive process and exit the suc-

cessful process. If we want to express that an event is previous to a behaviour, we use the operator ,,;,, (we

use the symbol v to indicate the places for the argu- ments). ,,[],, takes as arguments two processes, the composite process will behave nondeterministically as one of the subprocesses. If the choice is not resolved

in the interaction of the process with the environment, then the outcome is not determined. The four oper-

ators atop, exit, ;, and [] are the constructors that suffice for building any behaviour expression in LO-

TOS. The following operators can all be expressed in terms of these constructors.

To describe the interaction between processes, we have three kinds of parallel operators: u l[l,, for indepen- dent parallel composition or interleavhng, with no re- lation between events of one process and the another,

u l l u for parallel composition with synchronization on all common events of the two processes, and ,,l [u] [,,

for synchronization only on the specified events. One can also make an event unobservable from the outside

with hideuinu, guard a behaviour with a predicate us- ing [,,]->,,, compose processes in sequence with, ,>>, ,, or perform a disruption (interruption) with ,, [>,,. The semantics of the behaviour part is given operationally

by a labelled transition system. For more details, see

[ISO 871.

The data part is taken over from the abstract data type language ACT ONE. Like this language, the data part of LOTOS allows the user to employ a library of pre- defined data types, combine data types, rename them, parameterize data types, actualize them, and extend them with operations and sorts. In full LOTOS, the events allow the communication of data. In the sequel, we will nevertheless concentrate only on the behaviour part, i.e., on the so-called basic LOTOS, where events degenerate to simple actions or gates with no passing of data values.

An example of a simple behaviour expression is:

(a; c; s top) I [c][ (b; c; atop)

where a, b, c are actions. In this process, first the ac- tions a and b may occur in any order and then c occurs with the synchronization of the two subprocesses. An- other process that is equivalent to this one (in fact it

is bisimulation congruent) could be e.g.:

(a;exit)[ll(b;exit) >> (c;stop)

If we want to express these processes in terms of the constructors, we could write:

(a; b; c; s top [] b; a; c; stop)

3 The Transformational Language TransLOtOS

TransLOtOS is a language for reasoning about and trans- forming LOTOS specifications [Delgado Kloos 891. We have designed it to be an extension of LOTOS, i.e., it contains all operators of LOTOS and some additional objects and types for describing transformational de- velopments. In TransLOtOS , apart from being able to define LOTOS specifications, one can define transfor- mation rules, which are basically functions over LO- TOS specifications, and apply the rules to the specifi- cations or parts of them. One can also define param- eterized specifications, i.e., specification schemes with (meta)variables. These metavariables are denoted by identifiers that are preceded by an underscore.

We call a TransLOtOS program a development. Devel- opments can be organised hierarchically, i.e., one can import into a development the definitions of specifica- tions and rules of other developments. Special cases of developments are pure LOTOS specifications (if there are no definitions or applications of rules), or pure rule catalogues (for importing into other developments).

3.1 Simple Rules

A transformation rule can either be simple or composed from others. A simple transformation rule is given by a pair of schemes with free variables and a precondi- tion that must be fulfilled for application. The output scheme can be defined by a LOTOS specification with metavariables or as the result of the application of fur- ther transformation rules to schemes. This last pos- sibility gives the language a great power for defining complex rules.

When a rule is applied, the expression to which it is applied is matched against the input scheme. If the matching is successful, we obtain a substitution for the metavariables. We then apply this substitution to the applicability condition and check its truth. When it is true, the output scheme is instantiated and substituted for the initial expression. If the rule is non-applicable, the expression remains unchanged, i.e., the application of a non-applicable rule is equivalent to the identity.

C.D. Kloos, G.G. Martfnez / Expansion of LOTOS Behaviour Expressions 5

An example of a simple transformation rule is:

trafo HIDEprefH:ffi

forall _s: beh_expression, _a: gate,

_g: gate_llst in

hide _g in (_a; _s) {input scheme} ==

i; (hide _g in _s) {output scheme} when be longs (_a, _g) {applicabdity condition}

e n d t r a f o

Hiding a set of actions in a behaviour expression built by prefixing an action to another subexpression equiv- ales to prefixing the internal action i to the expression obtained by hiding the set of actions in the subexpres- sion, if the action belongs to the set. In the case that the action doesn't belong to the set, we have another rule:

t r a f o HIDEprefN:= forall _s: beh_expression, _a: gate,

_g: gate_list in

hide _g in (_a; _s) •ffi _a; (hide ~ in _s)

when not be longs(_a ,_g) e n d t r a f o

Analogously, we can write the rules relating hide to the other constructors s top , e x i t , and []:

trafo HIDEstop:=

forall _g: gate_list in

hide _g in stop == stop

endtrafo

trafo HIDEexit:=

forall _g: gate_llst in

hide _g in exit •ffi exit

endtrafo

trafo HIDEchoi:ffi

forall _s, _I;: beh_expression.

_g: gate_list in

hide _g in (_s [] _I;) ==

(hide _g in _s) [] (hide _g in _I;)

endtrafo

Finally, hiding an empty set equivales not hiding at all:

trafo HIDEempty:=

forall _s: beh_expression in

hide [ ] in _s == _s

endtrafo

use recursion and the following operators for defining them:

• .,THEN., for sequential composition: application of one rule after the other. The composite rule is applicable if both subrules are applicable, and otherwise non-applicable.

• uELSF.~ for alternative composition: successively testing the applicability of rules until one is ap- plicable. The composite rule is non-applicable if both subrules are non-applicable, and otherwise applicable.

• REPEATu for repetition: repeating the application of a rule until it is not applicable any more.

• UN,, for inversion: reversing the direction of a sim- ple rule defined by two schemes.

We can then define within a TransLOtOS development:

trafo HIDEpref :ffi

HIDEprefB ELSE HIDEprefN

endtrafo

trafo HIDE:ffi

HIDEstop ELSE HIDEexit ELSE

HIDEpref ELSE HIDEchoi

endtrafo

s p e c i f i c a t i o n S [a] behav iou r h ide a in s t op [] a; e x i t

endspec

Then, the application of the composite rule HIDE to specification S would yield

hide a in stop [] hide a in a; exit

For eliminating the h ide operator completely we would need a recursive rule that also deals with the subexpres- sions, as shown below.

3 . 3 R e c u r s i v e R u l e s

Let's suppose we have the following rule:

trafo ELIMi :ffi forall _x: beh_expression in

i; _x ---- _x

endtrafo

that eliminates i as a prefix, and the identity rule:

3 . 2 C o m p o s i t e R u l e s

It is also possible to define composite rules, i.e., rules which are defined in terms of other rules. We may

trafo I:=

forall _x: beh_expression in _ X = = _ X

e n d t r a f o

6 C.D. Kloos, G.G. Martinez / Expansion of LOTOS Behaviour Expressions

We can define a composite rule that eliminates a se- quence of i ' s , either by using the repetition operator:

trefo ELIMiREP := REPEAT ELIMi

end t r a fo

or by applying a rule in the output scheme (remember that applying a non-applicable rule leaves the input unchanged):

trafo ELIMiOUT:= forell _x: beh_expression in

i; _x == ELIMi0UT(_x) endtrafo

or by defining a recursive rule using THEN and ELSE:

trafo ELIMiREC :-- ELIMi THEN (ELIMiREC ELSE I)

endtrafo

It is useful to have all three ways of expressing com- posite rules. The repetition operator corresponds to one particular kind of recursion, namely tail recursion. ELIMi0UT is a simple transformation rule defined using behaviour expression schemes. This is quite a conve- nient way of defining rules. Nevertheless, one does not always want to go to the level of behaviour expressions to define rules, but define them in terms of other more

primitive rules, staying at the level of rules. In this case, the third possibility is useful.

4 Expansion of Behaviour Ex- pressions

The expansion of behaviour expressions (see e.g. [Mil-

net 80]) consists in expressing all constructs for build- ing them in terms of just the four constructors: stop, exit, ;, and []. Also recursive calls are permitted. The initial and the final behaviour expressions will sat- isfy the congruence by bisimulation.

Above we have defined how the hide operator relates to the four constructors. Applying these rules pushes the hide operator into the subexpressions or makes it disappear. Furthermore, we have defined a generic rule HIDE that is applicable to any expression having one of the four constructors as its outermost operator. Analogously, we have defined the corresponding rules for all the other operators (see [RodHguez et el. 89]). We don't give them here for lack of space.

To reach our goal, we have to descend recursively in a given behaviour expression to the subexpressions ap- plying all these rules. Concentrating just on the hide

operator, we achieve this by two mutually recursive rules:

t r a f o EXPAhide := forall _s: beh_expression, _g: gate_list in

hide _g in _8

(HIDE THEN EXPA)(hide _g in EXPA(_s)) endtrafo

trafo EXPA: = ... EXPAhide ELSE EXPAsync ELSE EXPAinte ..

endtrafo

EXPAhide expands expressions whose outermost oper- ator is hide. It proceeds by expanding the subexpres-

sion with EXPA, and by applying the composite rule HIDE THEN EXPA to the result. HIDE removes or in- terualises the operator, therefore a new application of EXPA is necessary.

EXPA is just the alternative composition of EXPAhide and the corresponding rules for the other constructs.

We now give a short example for a development. Here we first include a catalogue of transformation rules like

the above called Expander, then define a specification P, and finally apply the EXPA rule to it:

development demo : = include Expander

specification P [a.b.c] beheviour ((a; b; exit) [] (a; c; stop))

l[ (e; b; exit) endspec

EXPA P enddev

The result would be in this case

(a; b; exit [] a; stop).

5 Implementation of Trans Lotos

There are currently two prototypes of the transforma- tional system, one built with the functional language CAML and another based on CSG (Cornell Synthesizer

Generator) [Reps, Teitelbaum 85]. The first one was used as a way of fast prototyping for the needs of the final system, which is to be built on CSG.

CAML is the French version of the ML family of func- tional languages. The power of the language, thanks to

the higher-order polymorphic functions, and the pos- sibility to define concrete syntaxes with the aid of the yacc parser generator, allows one to prototype systems with great ease. This has helped in making design deci- sions that can be incorporated into the final prototype.

C.D. Kloos, G.G. Martinez / Expansion of LOTOS Behaviour Expressions 7

The expander as defined above has been implemented with the CAML prototype. Although the algorithm has a complicated recursive structure, the results are quite impressive in terms of efficiency.

For the implementation of the final prototype to sup- port the transformational approach with TransL°t°s, we have decided to use the Cornel] Synthesizer Gener- ator as a metatool which we can instantiate for our purposes. CSG's main use is for the generation of structure-oriented editors. But in essence it is a tool for building full-screen language-based environments from high level specifications. It manipulates the derivation tree of the input and has an efficient mechanism for the re-evaluation of attributes.

we transform a program, we are proving that it is cor- rect w.r.t, the initial version, and here lies the power of this methodology.

Acknowledgement s

This research was carried out within the project "En- t o m s de Disefio de Sistemas" in cooperation with A1- catel-Standard Eldctrica supported by the Spanish CI- CYT. We gratefully acknowledge the suggestion made

by A. Pdrez Riesco to look at this particular problem and useful remarks made by W. Dosch, G. Le6n, B. MSller, and M.A. Ruz.

6 Conclus ion

With the above approach we have performed a division of the expansion algorithm into two distinct parts:

• Object (language) dependent knowledge, expressed in the transformation rules (Semantics of LOTOS in the form of axioms)

• Meta (language) dependent knowledge, expressed in the definition of the composite rule EXPA (Strategy of the application of the axioms)

Modifications to the semantics of the language or to the expansion strategy can he performed (relatively) inde-

pendently of one another. Definition and application of rules are separate issues.

We can also look at our work from the viewpoint of other parts of Computer Science:

Viewed from Artificial Intelligence, our catalogue of transformation rules constitutes the domain specific declarative knowledge and the expansion algorithm is the strategic knowledge.

We can also view a transformational system from the point of view of programming environments as a "se- mantics-guided" editor. In the same way as a syntax- guided editor or structure editor knows the syntax of a language expressed in form of production rules and al- lows only changes in accordance with them, a "seman- tics-guided" editor or transformational system knows the semantics of a language expressed in form of trans- formation rules and allows only changes in accordance with them.

Finally, we may look at the transformation procedure from the point of view of proof theory and of theo- rem provers. From this point of view a transforma- tional development corresponds to a proof, whose in- ference rules are termed transformation rules. While

References

[Bauer et al . 89] F.L. Bauer, B. MSller, H. Partsch, P. Pepper: "Formal Program Construction by Transforma- tions -- Computer-Aided, Intuition-Guided Pro- gramming", IEEE Transactions on Software En- gineering 15:2, Feb. 1989, 165-180

[De lgado K l o o s 89] C. Delgado Kloos: "TransLOtOS: A transforma- tional language for LOTOS", STOP-Workshop on PT&S: Program Transformation & Specifica- tion - - Paradigms, Tactics & Strategies, Noord- wijkerhout, The Netherlands, 18-21 Apr. 1989

[Ehr ig , M a h r 85] H. Ehrig, B. Mahr: "Fundamentals of Algebraic Specification 1", Berlin: Springer 1985

[Hoare 85] C.A.R. Hoare: "Communicating Sequential Pro- ecsses", Englewood Cliffs: Prentice-Hall 1985

[ISO 87] ISO/TC 97/SC 21: "LOTOS. A Formal Descrip- tion Technique Based on the Temporal Ordering of Observational Behaviour", September 1987

[Le6n, D e l g a d o K l o o s 89] G. Le6n Serrano, C. Delgado Kloos: "Transfor- mational Generation of LOTOS Specifications", presented at the IFIP WG 2.4 workshop, Boston, 16-18 Jan. 1989

[Mi lne r 80] R. Miiner: ",4 Calculus of Communicating Sys- tems", Berlin: Springer 1980, LNCS 9 2

[Reps , T e i t e l b a u m 85] T.W. Reps, T. Teitelbaum: "The Synthesizer Gen- erator Reference Manual", Dept. of Computer Science, Cornell University, Ithaca, NY, 1985 (2nd ed. 1987)

8 C.D. Kloos, G.G. Martfnez / Expansion of LOTOS Behaviour Expressions

[Rodriguez et al. 89] J.F. Rodriguez L6pez, C. Delgado Kloos, G. Le6n Serrano: ~Axiomatie specification of LOTOS ori- ented towards the generation of transformation rules ~, Internal Report, DIT-UPM, Jan. 1989