Calculus Example - CiteSeerX

A Method to Combine any Process Algebra with an Algebraic Specification Language: the -Calculus Example Gwen Salaün, Michel Allemand, Christian Attiogbé {Gwen.Salaun,Michel.Allemand,Christian.Attiogbe}@irin.univ-nantes.fr

— Formal Specifications and Methods —

R ESEARCH R EPORT No 01.6 July 2001, revised in May 2002

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

Gwen Salaün, Michel Allemand, Christian Attiogbé A Method to Combine any Process Algebra with an Algebraic Specification Language: the  -Calculus Example 20 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 at the URL: http://www.sciences.univ-nantes.fr/irin/Vie/RR/indexGB.html

© May 2002 by Gwen Salaün, Michel Allemand, Christian Attiogbé rr016.tex – A Method to Combine any Process Algebra with an Algebraic Specification Language: the

-Calculus Example – 7/5/2002 – 16:47

A Method to Combine any Process Algebra with an Algebraic Specification Language: the  -Calculus Example Gwen Salaün, Michel Allemand, Christian Attiogbé

Abstract We introduce in [14] the formal foundations to make a generic combination of one process algebra and one algebraic specification language possible. Furthermore, to strengthen the contribution of this work, a concrete illustration about an orders invoicing case study is detailed in [13]. In this paper, we especially focus on the addition of other languages; indeed in the initial work, we only consider a restricted number of process algebras: CCS, CSP, ACP, basic LOTOS. Therefore, we aim at formalizing the way to extend the previous combination. To achieve this goal, we present a method to enhance the syntax and semantics of the formal kernel introduced in [14]. These guidelines are illustrated with the  -Calculus.

Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/Specifications; D.2.4 [Software Engineering]: Software/Program Verification; D.3.1 [Programming Languages]: Formal Definitions and Theory; D.3.3 [Programming Languages]: Language Constructs and Features General Terms: Design, Languages, Theory Additional Key Words and Phrases: Multi-formalism Specifications, Generic Combination, Method,  -Calculus

Contents 1

Introduction

6

2

Summary of the Initial Results

6

3

Method Guidelines

7

4

5

Illustration with the  -Calculus 4.1 The  -Calculus Study . . . . . . . . . . . . . . . . 4.2 Equivalences with Operators in the Existing Kernel 4.3 Enhancement of the Existing Kernel . . . . . . . . 4.4 Examples . . . . . . . . . . . . . . . . . . . . . . Conclusion and Future Work

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

8 9 10 12 16 16

6

1 Introduction Complex systems are made of several different parts, mainly one for data (or static) aspects, and one for behavioural (or dynamic) aspects. It is interesting to allow the developer to specify each part of the system with suitable formalisms. Algebraic specification languages and process algebras are respectively appropriate to specify the static part and the dynamic one. Several works have dealt with the combination of these languages; some wellknown results are LOTOS [2], PSF [7], and CRL [3]. In a similar direction, we have proposed a formalism which combines CCS with CASL [15]. We extend this kind of formal combination to enable the specifier to be free to choose his/her specification languages. Indeed, (s)he could prefer a formalism for different reasons: suitability with reference to the system requirements, existence of development tools, expertise of the specifier. The initial work is presented in [14] as a formal framework for a generic combination of two languages (one process algebra and one algebraic specification language). The framework enables us to use algebraic terms (written thanks to previously defined data types) as value passing for a given process algebra. The considered process algebras are CCS [8], CSP [4], ACP [1], and basic LOTOS [2]. The framework is described using a formal kernel with associated syntax and semantics. The global meaning is given in an operational way. An invoicing system is specified in [13] with our approach, and illustrates how to combine two precise formalisms (CCS and Larch). The main interest of this previous work is to have at one’s disposal a strong theoretical basis for our generic combination. Indeed, the formal kernel describes the meaning for all the possible combinations, and consequently for the specifications written with the corresponding formalisms. This formalization enables users to specify without worries about defining the global semantics. In this paper, we focus on the enhancement of the formal kernel to deal with other formalisms than ones we considered in the initial work. This extension especially affects the behavioural part of the combination. Concerning algebraic specification languages, we take into account languages with initial semantics (or restricted to their initial semantics). Accordingly, all the formalisms of this family are covered with a slight restriction. To extend the framework, we introduce a method to add a process algebra to the formal kernel. Roughly speaking, this goal is achieved following three main stages. Firstly, the developer have to study thoroughly the syntax and semantics of the new language, and particularly the possible links with data. Then, equivalences between some operators are expressed using the existing kernel. Finally, the other operators (which cannot be expressed in the basis) are added thanks to new abstract operators, and their operational semantics rules are formalized. For the dynamic part, we could enhance our initial framework with different process algebras. We are particularly interested in the timed extensions of CCS, CSP, and ACP. Another interesting example is the extension to mobility. The well-known formalism of this family is the  -Calculus [10, 11], and its numerous variants. In this work, we choose the  -Calculus to experiment in which way this formalism could be regarded in our generic combination. The paper is organized as follows. Section 2 recalls the main parts of the formal foundations for our generic combination. Section 3 introduces the different parts of our systematic process to consider other process algebras in our integration basis. In Section 4, we detail the method guidelines on a real example of language: the  -Calculus. Finally, in Section 5, we conclude and mention directions for future work.

2 Summary of the Initial Results In [14], we introduce a formal framework as a basis for a generic combination. Algebraic specification languages are used to express data types, whereas process algebras specify dynamic aspects such as concurrency. We consider process algebras extended to value passing in order to allow communications of complex data expressed by algebraic terms. The process algebra is called the main formalism because it gives the behaviour of the full specification. The framework is based on a formal kernel which is composed of an abstract syntax and an operational semantics. The syntax gathers the minimal and sufficient constructions appearing in the different process algebras under consideration (CCS, CSP, ACP and basic LOTOS) extended with algebraic value passing. It also takes into account algebraic specification data types.

7

From the different operators used by each considered language, we build a first minimal set of basic operators. In this first kernel, we put for instance the prefix, the choice, and the simple conditional operators. Then, we study the remaining operators, and either they can be expressed with other ones (already present in the kernel), or they must enrich the kernel although they did not appear essential during the construction of the minimal set. At this level, we are not far from the semantic preoccupations. Indeed, the conceptually common operators between process algebras have to possess the same semantics; whenever it is not the case, operators must be differentiated at the grammar level. The semantics of the combination is operational. For each dynamic construction of the abstract grammar, inference rules give its meaning. We distinguish two kinds of inference rules for the operational semantics. The first one corresponds to rules for the declaration of processes, and consequently enhances a memorization context. The second one represents rules giving the meaning for each construction of the kernel. For this second type, the main specification is seen as a Labelled Transitions System (LTS) which evolves by application of these rules. We give the semantics of the algebraic specification by closed terms rewriting. Axioms of the algebraic specification are oriented into rewrite rules. This could be done thanks to ordering algorithms like those introduced in [6], that guarantee termination. This choice is justified since it is suitable to an operational semantics. Nevertheless, it implies that algebraic specifications are restricted to positive conditional axioms with initial semantics. For the algebraic specification languages with loose semantics, we restrict them to their initial algebra. For the considered process algebras, equivalences are formalized between the concrete operators of the language and the abstract ones of the kernel. This ensures the correspondence between the used languages and the formal basis. The framework takes into account suitable tools too, particularly we focus on reuse of existing ones.

3 Method Guidelines An interest of the current work is that it makes the specification of the main aspects of complex systems possible, and it favours the genericity of integrated formalisms. Nonetheless, we remind that process algebras are only partially taken into account. As a consequence, it seems essential to offer the possibility to enhance our formal framework with other languages of this family in an easy way. Next, we accurately detail the guidelines to be followed so that other process algebras could be considered in the existing framework. Our method is made of three parts; each part is also composed of different steps. 1. Study of the language to be added. Above all, the language to be added have to be studied thoroughly. This first part in the method is important to know precisely its syntax and semantics, and to extend the initial formalism to manage data. The steps are: a. enumerating all the operators of the language; b. enumerating the corresponding operational semantic rules; c. recalling the communication model; care must be taken of the consequences of this model on the semantics of certain operators (e.g.: binary versus multi-way synchronization); d. explaining how to extend the syntax to take into account data management; e. formalizing inference rules extended with data features. 2. Equivalences with the existing kernel. The second part of the method consists of itemizing each construction of the formalism, and comparing the operator with those appearing in the existing kernel. At this level, the goal is to find an equivalent construction in the formal kernel expressed with one or several well composed operators so that the meaning of the initial operator is preserved. For each operator of the language to be added, the different steps are: a. comparing the extended semantics of concrete operators with the semantics of each abstract operator, and formalizing possible equivalences;

8

b. searching and formalizing equivalences between each operator and a combination of abstract constructions (only if failure of the previous step); c. justifying formally equivalences for each concrete operator for which an equivalent is found. We emphasize that we distinguish two cases of equivalences: the direct equivalence, and the equivalence described using several constructions of the kernel. Operators which have no equivalent in the kernel are treated in the next part. The previous study from which possible equivalences are formalized is not systematic (even though this could be partially automated in future work). Indeed, we do not compare the new operator with all the possibilities of combination of the existing kernel. Thus, it does not matter if a mistake is performed, and an operator is added to the kernel whereas it could be expressed with others already in the kernel. Yet, it is essential that each initial operator has an equivalent in the final kernel. Finally, the formal justification steps could be performed when the whole syntax is run over, instead of one after the other. Furthermore, this justification is quite automatic and could be obtained by syntactic rewriting application. 3. Enhancement of the existing kernel. The other constructions which possess no way to formalize equivalences must be added to the existing abstract grammar. In this case, names are chosen and syntactic rules are written. The final step is the definition of inference rules for these added abstract operators. This is done using the initial semantics (possibly extended) of the source language, and environments and notations recovered from the existing kernel. For the remaining operators, the steps are: a. giving names to the new abstract operators; b. formalizing the syntactic rules to be added to the grammar and their precise location in this one; c. stating (if necessary) additional notations and variables used to define semantic rules; d. formalizing semantic rules for the new abstract operators with possible informal explanations; e. summarizing the accurate correspondence between concrete and new abstract operators. While adding a new abstract operator to the grammar, care must be taken because if this construction is part of a precise family (for instance parallel compositions), but with different semantics, the same name basis could be chosen with another prefix. To define additional inference rules, the whole variables appearing in new rules could be reminded, and not only the new ones. About the semantic definitions of the added operators, we distinguish in the initial work the inference rules for processes declaration and the ones for the different operators of the main behaviour. For the first rules, there are never modifications since the processes definitions are defined in an identical way. Therefore, we focus on the second type of rules, and especially on the meaning of the new constructions. The justification for the added operators is straightforward (so not necessary) because the semantics defined in the d step of this part is built from the initial one (syntactically and semantically extended to manage data) of the source language as described in the first part of the method. Then, the behavioural rules of the extended initial language are exactly the same as those written in this part up to identifiers renaming.

4 Illustration with the  -Calculus Now, we exploit these guidelines with a concrete example: the  -Calculus. Each of the above key-points is detailed and formalized to illustrate on this mere example our systematic process.

9

4.1 The  -Calculus Study In the first part of our method, we want to be more exhaustive than the guidelines. Thus, we do not restrict ourself to the different steps of the first part, but we give more explanations about the treated language to make the understanding of the  -Calculus concepts easier. The language was suggested by Milner, Parrow and Walker in [10, 11]. The calculus is an extension of the process algebra CCS, which consists of adding mobility (name passing) to CCS. In this language, we can naturally express processes which have changing structure. It is achieved with processes interaction by sending communication links to each other. The different constructions of the language are gathered in Table 1 (step 1.a). We consider here the monadic (and declarative) version of the  -Calculus and not the polyadic one [9]. Construction Termination, inactive agent Prefixing Internal action Binary summation Parallel composition Restriction Agent call, recursion Conditional structure (match)

Syntax 0 .



+ |



P( : : : ) [cond] P

Table 1:  -Calculus operators The semantics of the language is given in an operational approach. The rules are defined in two ways, and are available in [11] for the early approach and in [12] for the late one (step 1.b). Both behavioural semantics are different, but they possess the same bisimulation properties. We choose the early semantics for our work. In this paper, for lack of space, we do not remind the whole rules. We just introduce the operational meaning of some constructions (binary summation and match).

 0 P! P  0 P + Q! P

 0 P! P  [x = x℄P ! P 0

The language uses synchronous communication (step 1.c). In addition, the communication is restricted to the exchanges between two agents, and is oriented. Concurrency is defined by interleaving (and non true concurrency), and time is only logical. This communication model only influences the semantics of the parallel composition since this operator expresses the communication between two behaviours. Aside, the website devoted to mobile processes1 presents existing tools among which the mobility workbench (MWB) [16]; this is a tool for manipulating and analyzing mobile concurrent systems described in the  -Calculus. The next step (1.d) is taking into account data. Then, we extend the name passing of the  -Calculus to the algebraic terms passing. Syntactic links between dynamic constructions and data are located at the following levels:

  

declaration and call of parameterized agents; input and output parameterized actions; condition of the match structure.

The hit operators are the prefixing, the parallel composition, the agent call, and the match. Now, we show how the semantic rules for these operators are modified to manage data (step 1.e). As illustration, the extended inference rules for the parallel composition, and the match operator are written. For the parallel composition, a rule is added to express the possible exchange of algebraic terms. The three other 1 http://lampwww.epfl.ch/mobility/

10

ones remain unchanged. Algebraic terms are evaluated thanks to the generic eval function (which is refined in the following); the rewriting is possible because we work with closed terms. The notation Exp[T/V] denotes the substitution of a variable V by a value T in an expression Exp. Note that we choose to type the input parameterised actions; the goal is to simplify the ulterior static verification steps possibly appearing in tool support.

P

a t(var:s)

! P0 ! Q0

Q P jQ ! P 0 [eval(t)=var℄jQ0

 0 P! P bn() \ fn(Q) = fg  0 P jQ P jQ !

x(z) P ! P0 Q xy! Q0  0 P jQ ! P [y=z ℄jQ0

P ! P0 x(w) Q ! Q0  P jQ ! w(P 0 jQ0 )



a t(t)

x(w)

For the match operator, rules are enhanced to consider that the condition could be an algebraic predicate (p below) evaluated thanks to the eval function. The rule treating the name passing is preserved.

 0 P! P eval(p) = true  [p℄P ! P 0

 0 P! P  [x = x℄P ! P 0

4.2 Equivalences with Operators in the Existing Kernel In the second part of the method, we study the semantics of each construction of the  -Calculus, and whenever the operator is similar to any construction appearing in the formal kernel, we give its equivalent (step 2.a). We recall that an equivalence is possible only if the semantics of the equivalent abstract operator is exactly the same as the initial language meaning. Direct equivalences are gathered in Table 2.

-Calculus operator 0



+ [cond] P

Abstract operator termination internal-action choice if-then-structure

Table 2: Direct equivalences Then, the study is continued for the remaining operators trying to express them using several constructions of the kernel (step 2.b). Here, we fail in expressing equivalences with a combination of abstract operators. Operators which have no equivalent in the kernel are treated in subsection 4.3. The next step (2.c) of this part is the justification of the previous equivalences by reminding the operational semantics of each side operator, either by comparing the rules, or by formally translating one to the other. For the constructions 0 and  , there are no semantic rules, because they do not allow composition of behaviours, but correspond respectively to the inactive agent, and to the hidden or internal action. Therefore, in an obvious way, we deduce both previous equivalences. For the summation, we precisely recall its rule in the  -Calculus language, and the meaning of the choice in our kernel. The equivalence is self-evident by renaming of variable identifiers representing the behaviours, and by substituting the concrete operator by the abstract one. The symmetric rule in which the right behaviour evolves is treated in a similar way.

11

 0 F! F 

hoi e F G ! F 0

 0 P! P  0 P P + Q!

Concerning the match operator ([cond] P), we recall the inference rule describing the semantics of this construction in the  -Calculus.

 0 P! P  [x = x℄P ! P 0 Our goal is to show that, from this rule and after extension with algebraic value passing, both semantic rules are equivalent. The extended semantics of this operator is described previously in this paper, and is reminded below.

 0 P! P eval(p) = true  [p℄P ! P 0

 0 P! P  [x = x℄P ! P 0

Then, the rule for the name passing is removed. Indeed, the condition is also a predicate expressing an equality between two identifiers. The idea is: x=x  p. Moreover, this type of structural equality is always defined in algebraic specifications. So, the single next rule is sufficient.

 0 P! P eval(p) = true  [p℄P ! P 0 The evaluation function is now clarified. R is a set of rewrite rules deduced from the algebraic specification part. This set was already used in the initial work. In our case, the evaluation corresponds to the rewriting of the R predicate (with closed terms) before comparison with true or false: eval  # . Moreover, it is not a problem for the name passing case, because the rewriting has no effect on this kind of predicate.

 0 P! P R # p = true  [p℄P ! P 0 After a step of identifiers renaming and substitution of the  -Calculus operator by the abstract one, we have:

 0 F! F R # p = true

if

then

stru ture p F

! F 0

Thus, from the  -Calculus rule for the match operator, the inference rule for the if-then-structure abstract operator is obtained.

12

4.3 Enhancement of the Existing Kernel In this part, we detail the additions which may be performed to the formal kernel in order to allow the use of the -Calculus in our generic combination framework. Four constructions of the formalism cannot be expressed with the basic kernel: the parallel composition, the prefixing, the restriction, and the call of process. Apart from the restriction, the three other constructions are parts of families of operators already appearing in the existing kernel. Accordingly, identical name bases are reused with new prefixes (step 3.a). The four constructions are respectively called mob-par-compo, mob-pre, restriction, and MOB-CALL. The next step (3.b) is to extend the abstract grammar detailed in [14]. The additional syntactic rules enrich the BEHAVIOUR part. We remind that terminal constructions are written in small letters, and nonterminal ones in capital letters. In Figure 1, the main parts of the abstract grammar are recalled, and we write the added grammar rules in bold font. SPEC

::=

ALGEBRAIC-SPEC PROCESS-ALGEBRA-SPEC

ALGEBRAIC-SPEC

::=

cf the used language abstract grammar

PROCESS-ALGEBRA-SPEC

::=

PROCESS+

PROCESS

::=

eq-def PROCESS-ID ACTION* VAR-DECL* BEHAVIOUR

BEHAVIOUR

::=

termination | choice BEHAVIOUR BEHAVIOUR | if-then-structure PREDICATE BEHAVIOUR |

:::

mob-par-compo BEHAVIOUR BEHAVIOUR | restriction ACTION BEHAVIOUR | MOB-PREFIXING | MOB-CALL |

:::

MOB-PREFIXING

::=

mob-pre internal-action BEHAVIOUR | mob-pre input ACTION VAR-DECL BEHAVIOUR | mob-pre input ACTION VAR BEHAVIOUR | mob-pre output ACTION APPLICATION BEHAVIOUR | mob-pre output ACTION VAR BEHAVIOUR

MOB-CALL

::=

PROCESS-ID APPLICATION*

VAR-DECL

::=

VAR SORT

APPLICATION

::=

OP-NAME EXPR* | VAR

PREDICATE

::=

PRED-NAME EXPR* | VAR

EXPR

::=

VAR | APPLICATION

Figure 1: Grammar of the kernel after extension Additional grammar rules are merely understandable except the MOB-PREFIXING rule which needs more explanations. Concerning the input, there are two rules: the first one corresponds to the algebraic terms communication case (with strong typing), and the second one is the name passing possibility. There is two rules too for the output expressing the sending of algebraic data terms or the name passing. Now, we focus on the semantic definitions of the added operators. We remind that the environment E is a context memorizing different informations used to define the inference rules. E is composed of the set of rewrite rules R deduced from the axioms of the algebraic part, and a set of tuples PAE containing informations about the processes (name identifier, behaviour, parameters). E

, < R,PAE >

Different new notations are used to define the rules (step 3.c). We use especially the bn and fn functions to extract the set of bound names and the set of free names from an action  or a process behaviour. These functions and their meanings are introduced in [11]. The function isterm checks if a value is an algebraic term. A conditional structure if _ then _ else _ makes the actuation of a behaviour under condition possible. All the variables used to define the following semantic rules are summarized in Table 3. We especially write the new ones in bold font.

13

Variable F, G



act, w, x, y, z var s t

Informal description Behaviour Action (input, output, internal) Action (name) Variable Sort Algebraic term

R PAE PI PP A vi

Set of rewrite rules Set of tuples for processes Process identifier List of process parameters List of actions Values (terms or actions)

Table 3: Variables description Inference rules corresponding to the added operators are now formalized (step 3.d). BEHAVIOUR

::=

mob-par-compo BEHAVIOUR BEHAVIOUR

 0 F! F bn() \ fn(G) = fg (1)  mob par ompo F G ! mob par ompo F 0 G If a behaviour F evolves into F 0 by , and the intersection between the bound names in  and the free names in the behaviour G is empty, then the parallel composition between F and G evolves by action  into the parallel composition between F 0 and G. The rule for the symmetric case, where the behaviour G evolves and not the F one, is omitted.

s 0 F input a t var! F output a t t G ! G0

mob par ompo F

G

R ! mob par ompo F 0 [ # t=var℄ G0

internal a tion

(2)

If a behaviour F becomes F 0 by executing an input parameterized action, and a behaviour G evolves into G0 after the firing of an output parameterized action, then the parallel composition between F and G evolves into the parallel composition between F 0 and G0 by the internal action. The input variable x is substituted in the behaviour F 0 by the term t received during the communication. This term is rewritten thanks to the rewrite rules R. The rule corresponding to the symmetric case, where F does the output action and G the input one, is omitted, and in the following too. Communication is only with one parameter because we work on the monadic  -Calculus.

!z F 0 output a t y ! G0 internal a tion

ompo F G ! mob F G

input a t

F G mob par ompo F

G

input a t

x 0 ! F ! G0

par ompo F 0

(3)

y=z ℄ G0 If F behaves as F 0 by an input parameterized action, and a behaviour G becomes G0 after the firing of an output parameterized action, then the parallel composition between F and G evolves into the parallel composition between F 0 and G0 by the internal action. All the actions of F 0 are substituted by the new action y . mob par

[

output a t x

! restri tion x mob

internal a tion

par ompo F 0

G0

(4)

14 If a behaviour F evolves into F 0 after the firing of an input parameterized action, and a behaviour G becomes 0 G by an output parameterized action (with the same parameter), then the parallel composition between F and G evolves by the internal action into the parallel composition between F 0 and G0 , where the exchanged parameter becomes private. BEHAVIOUR

::=

restriction ACTION BEHAVIOUR

 0 F! F x 62   restri tion x F ! restri tion x F 0

F

(5)

If a behaviour F behaves as F 0 after execution of , and an action x does not appear in , then the behaviour with private x evolves by  into F 0 , where x is private too.

F

output a t

x 0 ! F

a t 6= x output a t x restri tion x F ! F0

(6)

If a behaviour F evolves into F 0 by an output parameterized action a t, and a t is different from the parameter x, then the behaviour F with private x evolves by a t into F 0 , where x is no longer private. MOB-PREFIXING

::=

mob-pre internal-action BEHAVIOUR

mob pre internal

a tion F

!F

internal a tion

(7)

The current behaviour evolves into F by an internal action. MOB-PREFIXING

::=

mob-pre input ACTION VAR-DECL BEHAVIOUR

mob pre input a t x s F

input a t

xs

!F

(8)

The current behaviour evolves into F by an input parameterized action. MOB-PREFIXING

::=

mob-pre input ACTION VAR BEHAVIOUR

62 fn(restri tion z F ) input a t w ! F [w=z ℄ pre input a t z F w

mob

(9)

If an action w does not appear in the free names of a behaviour F where z is private, then the current behaviour evolves into F by an input parameterized action. The z occurrences are replaced by w in the behaviour F . MOB-PREFIXING

::=

mob-pre output ACTION APPLICATION BEHAVIOUR

15

mob pre output a t t F

output a t

!t F

(10)

The current behaviour behaves as F by an output action parameterized with an algebraic term t. MOB-PREFIXING

::=

mob-pre output ACTION VAR BEHAVIOUR

mob pre output a t y F The current behaviour behaves as

-Calculus.

MOB-CALL

::=

F

output

a t y

!F

(11)

by an output parameterized action. It is a rule that is characteristic of the

PROCESS-ID APPLICATION*

 0 F! F < P I; F; A; PP > 2 PAE  0 PI ! F If a behaviour F evolves into F 0 by , and the tuple < P I; F; A; PP terized process P I becomes F 0 by .

(12)

> is in the set PAE , then the unparame-

R

F [if isterm(v1 ) then # v1 =PP [1℄ else v1 =PP [1℄ ; : : : R  0 ; if isterm(vn ) then # vn =PP [n℄ else vn =PP [n℄℄ ! F < P I; F; A; PP > 2 PAE  0 F P I v1 : : : v n !

(13)

If a behaviour F , in which the parameters PP [i℄ are substituted by the real values vi corresponding to the parameters of the called process, becomes F 0 by , and the tuple < P I; F; A; PP > is in the set PAE , then the parameterized process P I becomes F 0 by . Two cases are distinguished in the substitutions; indeed, each value is either an algebraic term and consequently is rewritten using R, or a name of action. In a final step (3.e), we write in Table 4 equivalences between the concrete operators and the added abstract ones in order to get a comprehensive expression of the  -Calculus in the formal kernel.

-Calculus operator | .

 Recursion, agent call

Abstract operator mob-par-compo mob-pre restriction MOB-CALL

Table 4: Equivalences with new operators

16

4.4 Examples In this section, we present simple examples to show how the  -Calculus extended with algebraic terms as value passing could be used. We do not aim at introducing a full case study here, but we just describe pieces of behaviours with their possible evolutions, and an example of process definition. We recall that the specifications are written with the initial language, and the formal kernel is just the theoretical basis to give meaning to the full specification. Below, data types appear (for example, the sort s), but there are not detailed here, although we assume that they are previously defined. We just focus on dynamic parts. The first behaviour contains three parts composed in a parallel way. We emphasize that the a action has as parameter an algebraic term. ( a)(a(x:s).b(x).F | a(t).G) | c(z).0

To reinforce the correspondence between the concrete use of the combined language and its formal basis, we show the equivalent of the above example expressed into the formal abstract syntax of the enriched kernel. Its semantics is deduced directly from the previous equivalences and semantic definitions. We add brackets to favour readability. mob-par-compo restriction a (mob-par-compo (mob-pre input a x s (mob-pre output b x F)) (mob-pre output a t G) mob-pre input c z 0

The next piece of behaviour describes a possible step of evolution: the  synchronization on action a. The term t is received by the behaviour in the first part of the parallel composition. Accordingly, the variable x is substituted by the rewritten term t in the whole part of this behaviour. The semantic rule describing the evolution is the corresponding one (2) of the mob-par-compo operator. ( a)(b(

R

#

t).F | G) | c(z).0

Then, we just recall a classic example of name passing in the  -Calculus, so that the reader distinguish both types of value passing. a(x).x.F | a(y).G

 !

y.F | G

Finally, a comprehensive definition of a simple process is described below. We emphasize the extension of the

-Calculus to consider algebraic data in the declaration and call of process. The next behaviour corresponds to the management of a natural number counter with possible addition and subtraction of a natural. Count(x:Nat)

def =

inc(n:Nat).Count(x+n) + dec(n:Nat).Count(x-n)

5 Conclusion and Future Work In this paper, we aim at showing how the generic combination introduced in [14] could be enhanced to consider other languages, especially other process algebras. A method is presented as a comprehensive and rigorous process for the above extension. The different steps of our method are illustrated on a concrete example of language: the -Calculus. These steps are not obvious. However, following the given guidelines, this could be performed without too efforts. The main direction for future work is the thorough study of tools issues. Particularly, the embedding in the input language of higher-order logic tools, like PVS [5], is very promising. More precisely, our goal is to study in which manner the formal kernel could be formalized using these verification systems, in order to make proofs about the global specification in a homogeneous context.

17

References [1] J. C. M. Baeten and W. P. Weijand. Process Algebra, volume 18 of Cambridge Tracts in Theoretical Computer Science. Cambridge University Press, Cambridge, England, 1990. [2] T. Bolognesi and E. Brinksma. Introduction to the ISO Specification Language LOTOS. In P. H. J. van Eijk, C. A. Vissers, and M. Diaz, eds., The Formal Description Technique LOTOS, pages 23–73. Elsevier Science Publishers North-Holland, 1989. [3] J. F. Groote and A. Ponse. The Syntax and Semantics of CRL. In A. Ponse, C. Verhoef, and S. F. M. van Vlijmen, eds., Proceedings of the 1st Workshop on the Algebra of Communicating Processes (ACP’94), Workshops in Computing Series, pages 26–62. Springer-Verlag, 1995. [4] C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1984. [5] J. Crow, S. Owre, J. Rushby, N. Shankar, and M. Srivas. A Tutorial Introduction to PVS. In Proceedings of the Workshop on Industrial-Strength Formal Specification Techniques (WIFT’95), USA, 1995. [6] J. W. Klop. Term Rewriting Systems. In S. Abramsky, D. M. Gabbay, and T. S. E. Maibaum, eds., Handbook of Logic in Computer Science, volume 2, chapter 1, pages 1–117. Oxford University Press, Oxford, 1992. [7] S. Mauw and G. J. Veltink. A Process Specification Formalism. Fundamenta Informaticae, XIII:85–139, 1990. [8] R. Milner. Communication and Concurrency. International Series in Computer Science. Prentice Hall, 1989. [9] R. Milner. The Polyadic  -Calculus: A Tutorial. In F. L. Hamer, W. Brauer, and H. Schwichtenberg, eds., Logic and Algebra of Specification. Springer-Verlag, Heidelberg, 1993. [10] R. Milner, J. Parrow, and D. Walker. A Calculus of Mobile Processes, Part I. LFCS Report Series ECSLFCS-89-85, University of Edinburgh, 1989. [11] R. Milner, J. Parrow, and D. Walker. A Calculus of Mobile Processes, Part II. LFCS Report Series ECSLFCS-89-86, University of Edinburgh, 1989. [12] J. Parrow. An Introduction to the  -Calculus. In J.A. Bergstra, A. Ponse, and S.A. Smolka, eds., Handbook of Process Algebra, pages 479–543. Elsevier, 2001. [13] G. Salaün, M. Allemand, and C. Attiogbé. A Practical Combination of a Process Algebra with an Algebraic Specification Language. In H. R. Arabnia, ed., Proceedings of the International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA’01), CSREA Press, pages 73–79, USA, 2001. [14] G. Salaün, M. Allemand, and C. Attiogbé. Formal Framework for a Generic Combination of a Process Algebra with an Algebraic Specification Language: an Overview. In Proceedings of the 8th Asia-Pacific Software Engineering Conference (APSEC’01), IEEE Computer Society Press, pages 299–302, China, 2001. [15] G. Salaün, M. Allemand, and C. Attiogbé. Specification of an Access Control System with a Formalism Combining CCS and CASL. In Proceedings of the 7th International Workshop on Formal Methods for Parallel Programming: Theory and Applications (FMPPTA’02), IEEE Computer Society Press, USA, April 2002. To appear. [16] B. Victor and F. Moller. The Mobility Workbench — A Tool for the  -Calculus. In D. Dill, ed., Proceedings of the Conference on Computer-Aided Verification (CAV’94), volume 818 of LNCS, pages 428–440. SpringerVerlag, 1994.

A Method to Combine any Process Algebra with an Algebraic Specification Language: the  -Calculus Example Gwen Salaün, Michel Allemand, Christian Attiogbé Abstract We introduce in [14] the formal foundations to make a generic combination of one process algebra and one algebraic specification language possible. Furthermore, to strengthen the contribution of this work, a concrete illustration about an orders invoicing case study is detailed in [13]. In this paper, we especially focus on the addition of other languages; indeed in the initial work, we only consider a restricted number of process algebras: CCS, CSP, ACP, basic LOTOS. Therefore, we aim at formalizing the way to extend the previous combination. To achieve this goal, we present a method to enhance the syntax and semantics of the formal kernel introduced in [14]. These guidelines are illustrated with the  -Calculus.

Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/Specifications; D.2.4 [Software Engineering]: Software/Program Verification; D.3.1 [Programming Languages]: Formal Definitions and Theory; D.3.3 [Programming Languages]: Language Constructs and Features General Terms: Design, Languages, Theory Additional Key Words and Phrases: Multi-formalism Specifications, Generic Combination, Method,  -Calculus

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