1 Rapid Prototyping of Specification Language Implementations

Rapid Prototyping

of Speci?cation Language Implementations

Martin Leucker and Thomas Noll

Lehrstuhl f¨u r Informatik II,Aachen University of Technology

Ahornstr.55,D–52056Aachen,Germany

e–mail:{leucker,noll}@informatik.rwth-aachen.de

Abstract—Speci?cation languages such as LOTOS and SDL play an important r?o le in the design and implementation of distributed systems.Their for-mal syntax and semantics supports the develop-ment of compilers and of veri?cation tools.

This paper introduces a generic and uniform ap-proach to support such languages in veri?cation tools.We present a compiler generator which, given the description of a speci?cation language, automatically generates a corresponding imple-mentation.More speci?cally,the syntax and se-mantics of the speci?cation language has to be de?ned using Meseguer’s Rewriting Logic formal-ism,a uni?ed semantic framework for concurrency. From this description a compiler is derived which parses a given system speci?cation and computes the corresponding semantic object,such as a la-belled transition system.The latter can be pro-cessed further in subsequent analysis and veri?ca-tion phases.

Thus we propose some kind of“meta–proto-typing”approach in the sense that new speci?c-ation formalisms for distributed systems can easily be tested without the need to develop an imple-mentation by hand.

I.Introduction

Formal methods are becoming more and more popular for the speci?cation,veri?cation,and pro-totyping of industrial critical systems.Several case studies have shown that corresponding tech-niques can help to?nd errors during the design process(see[1]for an overview).They are also gaining commercial success,e.g.,companies such as Intel,National Semiconductor or Texas Instru-ments are establishing new departments for formal methods(see for example the job adverts in[2]). The term formal methods usually denotes the application of rigorous mathematical methods for specifying and verifying complex hardware and software systems.The formal speci?cation of a system helps to understand the system under de-velopment.Furthermore,a common and formal basis for reasoning about the system is given. The application of formal methods requires the availability of supporting tools because formal methods are especially adequate for the design of large systems where an ad hoc or conventional software engineering approach is not reasonable. Generally speaking,large systems consist of dis-tributed processes working together concurrently. While the distribution of the processes usually does not involve any conceptual problems,the concurrent behaviour makes the system di?cult to understand.Therefore,we put our emphasis on analysing concurrent systems.During the last years several prototypes of corresponding tools have been developed, e.g.,CWB([3]),NCSU-CWB([4]),SPIN([5])and the symbolic model checker SMV([6]).Most of the tools are tailored for a speci?c syntactic and semantic setting,e.g., CCS with transition system semantics andμ–calculus model checking.

Our goal is to support rapid prototyping of dis-tributed systems by facilitating the employment of new speci?cation formalisms and semantic do-mains.To this aim we are developing a tool which, given the description of a speci?cation language, automatically generates a corresponding imple-mentation.More speci?cally,the syntax and se-mantics of the speci?cation language under con-sideration has to be de?ned using the Rewriting Logic formalism,which was proposed in[7]and [8]as a uni?ed semantic framework for concur-rency.From this description a compiler is derived which parses any given system speci?cation and

computes the corresponding semantic object. This compiler generator is part of our Truth veri?cation tool([9],[10])which can subsequently be used to visualise and analyse the derived se-mantics.In particular it can perform model check-ing,i.e.it is possible to verify that the system under consideration ful?ls certain conditions spe-ci?ed as formulae of some formal logic.

In the remainder of this paper we introduce our compiler generator in greater detail.Section II gives an overview of its formal basis,the Rewrit-ing Logic approach.Section III describes its im-plementation and the results obtained so far.Sec-tion IV concludes with some remarks.

II.Rewriting Logic

There are two main problems which limit the use of model checking techniques in practical situ-ations:

1.There is a huge amount of design formalisms (like SDL[11],ACP[12],LOTOS[13],B(P N)2 [14],etc.)and hence the support by tools is rather limited in the sense that not even each design no-tion is implemented.This fact is strengthened by the plurality of techniques for describing require-ments.Thus generic methods are desirable which increase the?exibility and adaptability of veri?c-ation tools towards the speci?cation language.

2.The state explosion problem:The usual se-mantic treatment of concurrent systems in current veri?cation tools,i.e.,the interleaving approach, leads to a huge number of states and limits the use of model checking to rather small components. With the?rst point in mind,the Process Algebra Compiler PAC([15])has been developed as a tool which,given the syntax and the operational rules of a process algebra,generates a compiler front–end which analyses programs and computes their meaning.However,since the semantics is speci?ed in terms of structural operational rules,the scope of this tool is restricted to(labelled)transition systems(henceforth called LTSs for short).

It is possible to add a further degree of freedom by allowing also the semantic domain to be spe-ci?ed.This goal can be achieved by employing the Rewriting Logic approach.It aims at a separate description of the static and of the dynamic as-pects of a distributed system.More exactly,it dis-tinguishes the laws describing the structure of the states of the system from the rules which specify its possible transitions.The two parts are respect-ively formalised as an equational theory and as a (conditional)term rewriting system.Both struc-tures operate on states,represented as(equival-ence classes of)terms built up from the operators of the speci?cation language under consideration. Since a single transition may comprise several in-dependent rewriting steps,concurrent behaviour can explicitly be modelled.

Rewriting Logic has been successfully applied to specify various languages and semantic domains; an overview can be found in[16].Among others, P.Viry gives very natural speci?cations of CCS ([17])and of theπ–calculus([18]).

We have therefore chosen Rewriting Logic as the formal basis of our compiler generator which, given the de?nition of a speci?cation language, automatically derives corresponding parsing and LTS–generating functions which can be used as a frontend for veri?cation tools such as Truth.The overall structure is depicted in Figure1.

Term rewriting

rules

Equations

Truth frontend

System

specification

in SL

SL Parser

LTS generating

functions

Compiler generator

Rewriting Logic

definition of SL

Grammar

Labelled

transition

system

Fig.1.Generic implementation of speci?cation languages (SL)using Rewriting Logic

As a simple example,we give a Rewriting Logic speci?cation of CCS([19])using the syntax ac-cepted by our compiler generator.The desription of a speci?cation language consists of three parts. First,the syntax of the language has to be given in terms of a context free grammar.Beside the grammar itself,the de?nition contains information on scanning(tokens section),on typing(sorts section),on operator priorities and associativities (priorities section),and on the representation of CCS terms as abstract syntax trees(this map-

ping is de?ned in the grammar section and uses the symbols declared in the cons section). ALGEBRA CCS

sorts

definition,process,action

cons

Def:string*process->definition

Par:process*process->process

Plus:process*process->process

Rest:process*(action list)->process Rel:process*action*action->process Pref:action*process->process

Nil:unit->process

Var:string->process

Act:string->action

NegAct:string->action

SYNTAX

tokens

"\\"=>REST

"/"=>SLASH

"."=>DOT

"\("=>OPENB

"\)"=>CLOSEB

"{"=>OPENCB

"}"=>CLOSECB

"\["=>OPENSB

"\]"=>CLOSESB

"\+"=>PLUS

"\|"=>PAR

"’"=>PRIME

"nil"=>NIL

"="=>EQUAL

"[A-Z][A-Za-z0-9]*"=>PROCVAR of String

"[a-z]+"=>ACTION of String

priorities

left20PAR

left30PLUS

right40DOT

nonterminals

specification:(definition list)

def:definition

proc:process

rest,acts:(action list)

act:action

grammar

specification=def+

def=PROCVAR EQUAL proc

(Def(PROCVAR,proc))

proc=NIL

(Nil())

|PROCVAR

(Var(PROCVAR))

|proc PAR proc

(Par(proc1,proc2))

|proc PLUS proc

(Plus(proc1,proc2))

|OPENB proc CLOSEB

(proc)

|act DOT proc

(Pref(act,proc))

|proc rest

(Rest(proc,rest))

|proc OPENSB act SLASH act CLOSESB

(Rel(proc,act1,act2))

rest=REST OPENCB acts CLOSECB(acts)

acts=act+

act=ACTION(Act(ACTION))

|PRIME ACTION(NegAct(ACTION))

The second part consists of a system of(con-ditional and labelled)rewrite rules R de?ning the operational semantics,that is,state transitions are regarded as rewrite steps.In the case of CCS it is of the following form:

SEMANTICS

vars

d:(definition list)

p,p’,q,q’,r:process

a,b,c:action

r:(action list)

v:string

transitions

(Pre)Pref(a,p)-(a)->p

p-(a)->p’

(Sum)--------------------

Plus(p,q)-(a)->p’

p-(a)->p’

(Int)---------------------------

Par(p,q)-(a)->Par(p’,q)

p-(a)->p’,q-(b)->q’,inverse(a,b) (Com)---------------------------------------Par(p,q)-(Act("tau"))->Par(p’,q’)

p-(a)->p’,notin(a,r)

(Res)-----------------------------

Rest(p,r)-(a)->Rest(p’,r)

p-(a)->p’

(Rel)---------------------------------

Rel(p,a,b)-(b)->Rel(p’,a,b)

p-(a)->p’,different(a,b)

(Pas)---------------------------------

Rel(p,b,c)-(a)->Rel(p’,b,c)

p=lookup(d,v),p-(a)->p’

(Var)-----------------------------

Var(v)-(a)->p’

The de?nition of auxiliary functions like inverse is omitted.

Finally,the description contains a set of equa-tions between process terms E,which identify cer-tain states of the respective system.In this way, we reduce the state space of the resulting system as well as the number of rewrite rules.Note that, for example,the symmetric counterparts of(Sum) and(Int)are not required above since both the plus and the parallel operator are declared com-mutative in the following equations.The special meaning of the arrow symbols will be explained later.

equations

Plus(p,q)=Plus(q,p)

Plus(p,Plus(q,r))=Plus(Plus(p,q),r) Plus(p,Nil())->p

Plus(p,p)->p

Par(p,q)=Par(q,p)

Par(p,Par(q,r))=Par(Par(p,q),r)

Par(p,Nil())->p

Obviously the introduction of equations has considerable consequences concerning the se-mantic treatment.States of the system are not longer represented as terms but as equivalence classes of terms.In other words,to compute the semantics of a speci?cation it is necessary to im-plement term rewriting modulo an equational the-ory:

[p]E?→R[p′]E?→R...

It is obvious that for reasons of e?ciency we have to?nd suitable representatives for each equi-valence class.Hence,given a process term p,we have to?nd a normal form?p for the congruence class[p]E.Our approach is(similar to[18])to re-write p repeatedly to a term?t using a(partly)ori-entated version of E.Since E may contain equa-tions which can not be orientated,we still have to deal with rewriting modulo these equations.For our needs,it is passable to restrict ourselves to rewriting modulo associativity and commutativ-ity(AC)which is well understood([20]).Hence, we assume E to be characterised by two sets AC and ER where AC contains the AC–equations, and where ER is a set of rewrite rules(the“ar-row equations”in the CCS example above)such that

E=AC∪{l=r|l→r∈ER}.

Note that ER must be terminating in order to guarantee the existence of normal forms. Although the equational rules in ER have a sim-ilar nature as the transition rules of R,we have to treat them completely di?erent since the rewrite steps entailed by R represent the actual computa-tion of the system while the rewrite steps induced by ER are considered to happen internally—they are just used to implement the equational theory e?ciently.Hence,we have the following situation:

[p]AC

↓?ER

[?p]AC?→R[p′]AC

↓?ER

..

.

This approach is obviously correct,i.e.,every derived term p′can also be derived in the full the-ory,that is by using R modulo E.However,ER and R have to match certain(strong)coherence properties to make this approach also complete, i.e.,to ensure that every term derivable via R modulo E can be obtained by rewriting wrt.R and ER modulo AC.A detailed account on this topic can be found in[21].

It should be noted that the overall structure of a system speci?ed in rewriting logic is that of an LTS.(Though,as stated above,a single trans-ition may represent concurrent activities in dif-ferent subcomponents.)Hence,we are able to re-use the e?cient implementation of LTSs in Truth even when dealing with true concurrency.

III.Implementation of the compiler generator and practical results At present we have a prototype implementation of the compiler generator to gain some experience with its usefulness concerning the state space re-duction in the case of CCS and its applicability to the broad range of speci?cation formalisms.Our compiler is written in the functional programming language Haskell([22]),which is well suited for

parsing,and in which the Truth system is also implemented.As can be seen in the previous sec-tion,the ?le format of the speci?cation language de?nition follows a YACC–similar syntax.Hence Happy ([23]),a YACC–compatible parser gener-ator,is employed to generate the parser for the de?nition ?le.Figure 2gives a schematic view on the compiler.According to Section II,the speci?c-ation language de?nition can be divided into two parts,the de?nition of the syntax and the de?ni-tion of the semantics.

Parser sources Compiler generator

Compiler sources

Happy

Haskell Compiler Definition file format

Fig.2.The structure of the compiler

In the syntactic part,the user must provide typing information and a context–free grammar.From the grammar two representations of a parser for the respective speci?cation language are con-structed.

?The ?rst one is given in Haskell source code.It is permanent in the sense that it is stored in a ?le and included later in the Truth sources.Thus we obtain a version of Truth which is tailored for the speci?c speci?cation formalism.

?The second one is kept in memory as a transient object.It is needed for parsing the semantic part of the de?nition where both the rewrite rules and the equations employ the syntax of the speci?ca-tion language.

Both parsers are implemented using the parser combinator library ([24])and the extensions for operator precedences and automatic elimination of left–linear rules proposed in [25].

Using the transient parser,the semantic rules and equations of the de?nition are parsed.In-stead of generating code for rewriting accord-ing to the given rules,we employ ELAN ([26])for our prototype implementation.ELAN is a general–purpose rewrite system which supports

AC–rewriting.Thus the compiler generator builds an ELAN input ?le according to the semantic rules as well as Haskell code for accessing ELAN.

The permanent parser and the ELAN interface are compiled together with the basic Truth code to obtain a Truth version tailored for the spe-ci?cation formalism.Figure 3gives an overview of the output of the compiler generator and its integration into Truth

.

Compiler generator

Fig.3.The structure of the resulting tool

The speci?c Truth version is now ready for use,i.e.to accept and to analyse speci?cations in the new formalism.If for example the user enters a system speci?cation,it is parsed according to the syntax de?nition and stored in an internal format.If an analysis (e.g.of deadlock freeness)is reques-ted by the user,the LTS representing the speci?ed system is computed in a demand–driven fashion as follows:The textual representation of the current state s is sent to the ELAN system together with a rewriting command,resulting in the list of suc-cessor states being returned.To detect cycles in the LTS,every successor state has to be matched against the set of states obtained so far.Since some of the operators of the speci?cation language may be declared associative or commutative and because ELAN does not compute an AC–normal form,we employ ELAN again to test whether two states are equivalent.If we encounter a new suc-cessor state,then it is linked into the LTS.

While the e?ort for developing the prototype

is reduced to a minimum in this way,the use of ELAN has huge drawbacks concerning the runtime e?ciency of the system,mainly for two reasons: the Haskell–ELAN interface is based on pipes, hence string–based and slow therefore,and ELAN is an interpreter system.

However,from the point of view of memory ef-?ciency,the prototype is quite successful regard-ing the state space reduction.We tried several examples:semaphore,bounded stack and altern-ating bit protocol(ABP,[19,p.141])to name a few.An n–ary semaphore is basically a counter bounded by n;one straightforward implementa-tion of it(cf.[19,p.33])being

Sem=S0|...|S0

S0=get.S1

S1=put.S0

where the right–hand side of the?rst equation con-sists of n S0factors.

For this example,there is a huge reduction.The reason is that every state is the parallel product of n unary semaphores whose ordering does not matter.Regarding the term modulo AC identi?es all states representing the same value,leading to an exponential gain.

The bounded stack is an example for a whole class of processes where our compiler achieves essential improvements,the fragment of well–terminating processes([19,p.173]).The idea is that a process has to indicate its termination via a ’done action.Well–terminating processes can be sequentially composed in a very natural way,as the following speci?cation demonstrates:a stack process is either the empty process(which can just perform the’done action)or a process accepting a pushed element,then behaving as a stack again, followed by popping the same element and then behaving as a stack again.This is expressed in the following equations which describe a stack over a single entry type a where a sequential process com-position operator*is used:

Stack=Done+a*Stack*’a*Stack Done=’done.nil

It is easy to reduce the sequential composi-tion of well–terminating processes to plain CCS. We give a corresponding speci?cation of an n–bounded stack:

Stack_n=((a.Stack_n-1)[done/d]|

d.’a.Stack_n)\{d}+Done

...

Stack_0=Done

However,the bounded stack is an in?nite state process in the original semantics,since every pair-wise occurrence of a push(a)and a pop action(’a) results in a“dead”nil process existing in parallel with the rest of the system.Due to our Par(p, Nil())->p reduction rule(see Section II),the LTS computed by our implementation is?nite. Since stacks play an important role in modeling hardware systems,the improvement is crucial.

In the case of the ABP,however,no reduction could be achieved at all.

We are still on the way testing the integration of di?erent speci?cation formalisms into our system Truth.First examples seem to be promising but it is to early to draw general results from them.

IV.Conclusion

In this paper we described the design and a?rst implementation of a speci?cation language com-piler generator.Given a speci?cation language de?nition by its syntax and operational semantics, it generates parsing and semantic functions which can be integrated in a veri?cation tool such as Truth to obtain a veri?cation tool tailored for the speci?cation formalism under consideration. Thus our approach supports rapid prototyping in the sense that new speci?cation formalisms for dis-tributed systems can easily be tested without the need to develop an implementation by hand.

By applying our compiler generator to the CCS process algebra we were able to show that consid-erable reductions of the state space are attainable. This gain is due to the possibility to provide equa-tional laws which decribe the structure of the sys-tem states,so that similar results can be expected for most speci?cation formalisms.

At present we employ our tool for a concrete programming language(Erlang[27])together with an abstracted operational semantics.The goal is to obtain an analyser for Erlang programs with a minimum of e?ort.In particular,di?erent types of abstract operational semantics can be tested easily in this way.

However,the main problem of our implement-ation with regard to its its practical usefulness is the bad runtime e?ciency,mainly due to the string–based interfacing and to the current inter-

preter implementation of ELAN.Future releases will hopefully overcome these drawbacks by com-piling the rewriting rules.

At the moment,we are testing several other re-write tools with compiling facilities to improve our prototype.For the full version of our system,we are planning to implement a Haskell library for re-writing modulo AC which can be used in our com-piler to obtain an e?cient version of a veri?cation tool for the corresponding speci?cation formalism.

References

[1] E.M.Clarke and J.M.Wing,“Formal methods:State of

the art and future directions,”Tech.Rep.CMU-CS-96-178, Carnegie Mellon University(CMU),Sept.1996.

[2]“The concurrency mailing list,”URL:http://www.cwi.

nl/~jfg/concurrency/concurrency.html.

[3] F.Moller,The Edinburgh Concurrency Workbench(Ver-

sion6.1),Department of Computer Science,University of Edinburgh,Oct.1992.

[4]R.Cleaveland and S.Sims,“The NCSU concurrency work-

bench,”Lecture Notes in Computer Science,vol.1102,pp.

394–397,1996.

[5]Jean-Charles Gr′e goire,Gerard J.Holzmann,and Doron A.

Peled,Eds.,The Spin Veri?cation System,vol.32of DIMACS series.American Mathematical Society,1997, ISBN0-8218-0680-7,203p.

[6]K.L.McMillan,“The SMV system,symbolic model check-

ing-an approach,”Tech.Rep.CMU-CS-92-131,Carnegie Mellon University,1992.

[7]Jos′e Meseguer,“Rewriting as a uni?ed model of concur-

rency,”in Proceedings Concur’90Conference,Amsterdam, Aug.1990,Lecture Notes in Computer Science,Volume 458,pp.384–400,Springer,Also,Report SRI-CSL-90-02R, Computer Science Lab,SRI International.

[8]J.Meseguer,“Conditional rewriting logic as a uni?ed

model of concurrency,”Theoretical Computer Science,vol.

96,no.1,pp.73–155,Apr.1992.

[9]Martin Leucker and Stephan Tobies,“Truth—a platform

for veri?cation of distributed systems,”Tech.Rep.98-05, RWTH Aachen,May1998.

[10]https://www.360docs.net/doc/d213233075.html,nge,M.Leucker,T.Noll,and S.Tobies,“Truth–

a veri?cation platform for concurrent systems,”in Pro-

ceedings of Tools’98.1998,Christian-Albrechts University of Kiel.

[11]J.Ellsberger, D.Hogrefe,and A.Sarma,SDL–A

Formal Object–Oriented Language for Communicating Sys-tems,Prentice Hall,1997.

[12]J.C.M.Baeten and C.Verhoef,“Concrete process al-

gebra,”in Handbook of Logic in Computer Science,Vol 4,S.Abramsky,D.Gabbay,and T.S.E.Maibaum,Eds., vol.4,pp.149–268.Oxford University Press,1994. [13]T.Bolognesi and E.Brinksma,“Introduction to the ISO

speci?cation language LOTOS,”in The Formal Descrip-tion Technique LOTOS,P.H.J.van Eijk,C.A.Vissers, and M.Diaz,Eds.,pp.23–73.Elsevier Science Publishers North-Holland,1989.

[14]Eike Best and Richard P.Hopkins,“B(PN)2—A basic

Petri net programming notation,”in PARLE’93Parallel Architectures and Languages Europe,Arndt Bode,Mike Reeve,and Gottfried Wolf,Eds.June1993,vol.694of Lecture Notes in Computer Science,pp.379–390,Springer-Verlag.

[15]R.Cleaveland,E.Madelaine,and S.Sims,“A front-end

generator for veri?cation tools,”Lecture Notes in Com-puter Science,vol.1019,pp.153–173,1995.

[16]Jos′e Meseguer,“Rewriting logic as a semantic framework

for concurrency:a progress report,”in Seventh Interna-tional Conference on Concurrency Theory(CONCUR’96).

Aug.1996,vol.1119of Lecture Notes in Computer Science, pp.331–372,Springer Verlag.

[17]Patrick Viry,“Rewriting:An e?ective model of concur-

rency,”in Proceedings of PARLE’94–Parallel Architec-tures and Languages Europe.1994,vol.817of Lecture Notes in Computer Science,pp.648–660,Springer-Verlag. [18]Patrick Viry,“A rewriting implementation of pi-calculus,”

Tech.Rep.TR-96-30,Dipartimento di Informatica,Mar.

261996.

[19]https://www.360docs.net/doc/d213233075.html,ner,Communication and Concurrency,International

Series in Computer Science.Prentice Hall,1989.

[20]Nachum Dershowitz and Jean-Pierre Jouannaud,“Rewrite

systems,”in Handbook of Theoretical Computer Science, J.van Leeuwen,Ed.,vol.B:Formal Methods and Se-mantics,chapter6,pp.243–320.North-Holland,Amster-dam,1990.

[21]Patrick Viry,“Rewriting modulo a rewrite system,”Tech.

Rep.TR-95-20,Dipartimento di Informatica,Dec.011995.

[22]John Peterson,Kevin Hammond,et al.,“Report on

the programming language haskell,a non-strict purely-functional programming language,version 1.3,”Tech.

Rep.,Yale University,May1996.

[23]“Happy,a parser generator for haskell,”URL:http://

https://www.360docs.net/doc/d213233075.html,/fp/software/happy/.

[24]Graham Hutton and Erik Meijer,“Monadic parsing in

haskell,”Journal of Functional Programming,vol.8,no.

4,1998.

[25]Steve Hill,“Combinators for parsing expressions,”Journal

of Functional Programming,vol.6,no.3,pp.445–463,May 1996.

[26]P.Borovansky,C.Kirchner,H.Kirchner,P.E.Moreau,and

M.Vittek,“Elan:A logical framework based on compu-tational systems,”in Proc.of the First Int.Workshop on Rewriting Logic.1996,vol.4of Electronic Notes in Theor-etical Computer Science,Elsevier.

[27]J.Armstrong,M.Williams,and R.Virding,Concurrent

Programming in Erlang,Prentice-Hall,Englewood Cli?s, NJ,1993.