Object-based abstract state machines

Research Collection Working Paper Object-based abstract state machines Author(s): Janneck, Jörn Wilhelm; Kutter, Philipp W. Publication Date: 1998 Permanent Link: https://doi.org/10.3929/ethz-a-004289119 Rights / License: In Copyright - Non-Commercial Use Permitted This page was generated automatically upon download from the ETH Zurich Research Collection. For more information please consult the Terms of use. ETH Library TIK-Report Nr. 47 Object-based Abstract State Machines J
orn W. Janneck and Philipp W. Kutter Computer Engineering and Networks Laboratory (TIK) Swiss Federal Institute of Technology Zurich CH-8092 Zurich, Switzerland E-mail: fjanneck,[email protected] Abstract. When designing and implementing complex computer sys- tems, powerful description techniques are needed that allow the representation of hardware and software components at various abstraction levels and support re nement during the development process. These techniques should be formal in order to support mathematical reasoning about systems properties while at the same time they should be operational so as to facilitate comprehension and implementation of the system. In this paper we propose Object-based Abstract State Machines (ObASM), an extension of Abstract State Machines (ASM). ASM are an operational formalism that has been successfully applied to the description of hardware and software systems. ObASM are adding a notion of locality of state and the concept of communication between loosely coupled agents. These extensions are designed to be minimal additions to the traditional ASM formulation, preserving their simplicity while at the same time signi cantly enhancing their modeling power. We give a formal semantics for ObASMs and discuss the properties of the extended formalism. 1 Introduction Today's software and hardware systems are characterized by a composition of complex subsystems and complex interactions between them. An abstract specication of the whole system is needed to understand the behavior before expensive implementation is started. Research proposed many formalisms that are well suited for analysis or even verication. Unfortunately it turned out, that such descriptions are not always simple enough to be used in industrial system development, and even where the methods have been successfully applied 19], it was often not possible to rene the descriptions down to the implementation 18]. Gurevich's Abstract State Machines (ASMs) 13]14] are an operational formalism that can be used to model algorithms on dierent abstraction levels, from an abstract view down to the implementation details. ASMs have proven their applicability and usefulness to system specication and design through numerous extensive case studies in major domains as diverse as semantics and implementation of languages (C, C++, OCCAM, Oberon, Java, VHDL, SDL), hardware and software architectures (APE 100, ARM, pipelining in RISC architectures, PVM, Transputer), and embedded control systems (steam boiler control, production cell) 5]20]. Although ASMs are easily used to describe complex hard- and software systems, they lack support for combining the specied systems. One of the obstacle is, that the global state is always present, and side-eects of one subsystem may inuence another subsystem in an uncontrolled way. Another problem is, that in each of the mentioned case studies, the composition of simple systems to more complex ones is done in an ad hoc way. Distributed ASMs 17]12] have addressed the problem of composing subsystems by introducing a number of independently running agents, that communicate via shared memory. There is a priori no locality of states and message passing can be simulated 16], but is not a primitive concept. Montages 24]2] provide a generic version of the composition mechanisms used in the above mentioned case studies in programming languages semantics. The method concentrates on a visual formalism for initializing control data ow links among the components. Locality is used but due to the underlying ASMs not guaranteed, and message passing is coded as control pointers that move along the links. In this paper, we propose a variant of ASMs accounting for locality and communication. The main idea is to make the object oriented avor of ASMs more explicit, having both state and behavior attached to objects, that communicate by message passing only. The resulting Object based ASMs (ObASMs) guarantee compositionality in the sense, that algorithms based on the local state of an object cannot be disturbed by other system-components, since only local updates of the state are allowed. On the other hand, ObASMs are general allowing to model the full range from tightly coupled to loosely coupled, distributed systems. The appropriateness of the object based message passing paradigm to the former is evidenced by the growing body of distributed software component models (at least partly) based on this approach, like e.g. CORBA, DCOM, or JavaBeans, while its suitability for the latter is shown in, for instance 8]. In the next section we give an introduction to ASMs, and the denition and semantics of ObASMs. Our denition allows to see the system both operationally using ASMs and denotationally as x-points of general transition-systems evaluated non-deterministically along a partial ordering following only the causality of messages. The latter, large grain view of our system allows the use of other formal methods. As example we give two class denitions modeling the distributed behavior of places and transitions in Petri-nets. ObASMs are thought to be integrated with existing hardware and software systems and used not only for specication and analysis but the entire system engineering process including prototyping and testing. The requirements for this integration are given in section 5. 2 Abstract State Machines The fundamental concept in ASMs is the object, which we consider an atomic entity. We call the set of all objects the universe U 1 . The state
of the system is given as the mapping of a number of function symbols, the signature  , to actual functions. For short we write f
for the function interpreting the symbol f in state
. We write S( ) for the set of all  {states. A state transition changes these functions pointwise, by so-called updates. An update is a triple (f (o1  : : :  on ) o0 ) where f is an n-ary function symbol in  , and o0  : : :  on 2 U. Intuitively,
ring this update at a state
changes the function associated with f in
at the point (o1  : : :  on ) to the value o0 , leaving the rest of the function unchanged. In other words, given an update set  and a state
, ring  at
results in the successor state
= (
). We then have the following relation between f
and the new functions f
: 0 0 f
(o1  : : :  on ) 7;! 0 ( o0 if (f (o1  : : :  on ) o0 ) 2  f
(o1  : : :  on ) otherwise 0 (1) The update set for a given state is computed by the transition function. This function is the denotation of a rule, which is basically a syntactical object describing the updates to be performed in a given state. For instance, the rule f (2 x) := y would result in the update (f (2 6) 1) if x and y would be function symbols of arity 0 evaluating to the objects 6 and 1, respectively. The syntactical constructions allowed in rules and their denotations in terms of transition functions is given in the appendix. 3 Object-based Abstract State Machines An Object-based ASM (ObASM) describes the behavior of a system of objects that can be considered to have concurrent processing threads associated with them. Individual threads communicate via message passing. Computation is always initiated by an incoming message. 3.1 Terms and evaluation Each object x 2 U has an associated class  (x) from the set C of all classes in an ObASM. The class c of an object determines its behavior, given by transition functions, and its signature c. 1 In traditional ASM literature this set is called super-universe and sets are called universes. The vocabulary of the entire system is given as =  c (2) c C 2 Further an object x has associated with it its own local state
(x) 2 S(c ). The global state is given as a function
mapping each object to its local state:
: U ;!  S(c) c C such that
(x) 2 S( (x) ) (3) 2 In ObASM computation is always understood as processing of a message. A message consists of three parts, all of which are objects in U: its sender and receiver, and its content. These three objects are accessible with the constants snd, rcv , and cnt, respectively. Term evaluation is dened with respect to rcv , such that normal function applications are evaluated in the local state of rcv. In order to make the local state of other objects readable, the result x of a function application f (t1  : : :  tn ) may be used to evaluate a term g(t1  : : :  tm ) with respect to x in a so-called quali
ed term: 0 0 f (t1  : : :  tn ):g (t1  : : :  tm ) 0 0 This construction allows to access the local state associated with x in a readonly fashion. We will denote the evaluation of a term t w.r.t. the local state of an object x in state
by eval
x . Then the evaluation of this term w.r.t. the object x is dened as follows, writing f
(x) to denote the interpretation of function f in the f (t1  : : :  tn ) then local state of x. If T = eval
x (T ) = f
x (eval
rcv (t1 ) : : :  eval
rcv (tn )) In other words, evaluation with respect to an object x applies x's interpretation of f to the evaluation of the arguments w.t.r. rcv. Now we can dene the evaluation of a qualied term by evaluating the second term w.r.t. the result of the rst: t1 :t2 then If T = eval
x (T ) = (let y = eval
x (t1 ) in eval
y (t2 )) While the rule computing the updates to be performed may depend on the global state2 , it may only alter the assignment
(rcv), i.e. the local state of the object. In other words, terms can be evaluated with respect to other objects, but 2 In fact, at any given moment, it can depend only on a part of
, viz. those objects and their state which are reachable from x in a xed number of steps given statically by the nesting of the terms in its rules. only functions in the signature of rcv may be updated. Thus updates can only have the form f (t1  : : :  tn ) := g1 (: : : ): : : : :gm(: : : ) In such a context, the equation (1) relates
(rcv) with the local successor
(rcv) whereas the rest of the state remains unaltered. 0 As far as the rules are concerned, computing their denotation (i.e. the transition function the dene) is identical to the ASM case, except that we replace eval
with eval
rcv . If an object has to eect a state change in another object, the only way to do this is by passing it a message. A rule may produce an arbitrary number of messages, by using the send rule. The update-denotation of the send construct is the empty update set (cf. the appendix for a formal denition). 3.2 State transition Each class c has three transition functions associated with it: { The initialization function Ic describes the initialization behavior when an instance of the class is newly created, { The initial transition function Rc0 that denes the rst step in reaction of incoming messages. { The iterated transition function Rc that denes the subsequent iteration behavior3 In ObASMs, these transition functions, when applied to a state, do not only result in an update set, but they also produce a number of events that were sent. Correspondingly, rules do not only have an update-denotation (as in ASMs), but also a message-denotation. The formal denition of the message-denotation for the rules in our ObASM language is given in the appendix. In the system state at any given time, any number of messages may be pending, i.e. they have been sent but not yet received and acted upon. However, these messages do not form an unstructured set, because messages sent by the same object in consecutive steps are guaranteed to be processed in the order they were sent, i.e. the pending messages form a partial order (M <) (or M for short), where m1 < m2 i m1 has been sent by the same object strictly before m2 . Given such a system state S = (
 M ), we compute a successor state as follows: If M is empty, there is no event to be processed, and the system terminates. Otherwise, M contains an m such that there is no earlier m , i.e. m < m. Of course, there may be several such elements, in which case one is chosen 0 3 0 Of course, there will be many primitive classes with no behavior attached to them (empty rules/transition functions), i.e. integers, booleans, etc. This may have farreaching consequences, both in terms of the theoretical analysis of such systems as well as their implementations. nondeterministically. Given m, let us call the sender, the receiver and the content sndm , rcvm , and cntm , respectively. Now the computation of the successor state S is computed iteratively, and the iteration is initialized by applying the initial transition function R0 (rcvm) to the current global state, resulting in a rst update set  and some new events M : 0 0 0 R0 (rcvm) (
) = (  M ) 0 0 and then ( x 6= rcvm
0 : x 7;!
(x)  (
(x)) x = rcvm M0 = M  M 0 0 The update set is applied to the local state of rcvm (the rest of the global state remains unchanged), while the new events are appended to the existing events M M M M in M . The result (M <)  (M  < ) is a new event structure (M  M  < ) such that for all m m 2 M  M we have 0 0 0 0 M M M 0  0 0 M 0 m < m () (m < m ) _ (m < m ) _ (m 2 M ^ m 2 M ^ sndm = sndm )  0 0 0 0 0 0 i.e. events that were ordered in either M or M remain ordered, and additionally events originating from the same object at dierent times are ordered accordingly.4 Now assume that for each iteration step, R (rcvm) (
i ) = (i  Mi ). Then we dene 0 0 ( x 6= rcvm
i+1 : x 7;!
(x) i (
i (x)) x = rcvm Mi+1 = Mi  Mi (4) (5) 0 This process is repeated until a xed point is reached, i.e. we have a k such that
k+1 =
k and Mk+1 = Mk . Then the successor state S of S can be written as follows, removing the event just processed from the event structure: 0 S = (
k  Mk n fmg) 0 (6) Of course, if such a xed point is not reached, the computation does not terminate. 4 ) sndm Note that the resulting order is transitive, because by construction of the event structures, m<m 0 = sndm 0. 4 An Example: Petri Nets In the following we will describe a formal distributed ObASM specication for loop-free Petri nets. Petri nets are a very general formal model, dierent avors of which have been successfully applied to the modeling and analysis of a broad range of distributed and concurrent systems 3, 7, 22, 23, 25, 27]. They can be given an operational semantics, but writing interpreters for them can be cumbersome, in particular when these interpreters should execute them in a distributed fashion 11, 10, 21, 28, 29]. The distributed execution suggested in the following example parallels the transition ring protocol in 29]. Basically, each transition and each place have a process associated with them, and they communicate with each other about the availability of tokens and their movement. w1 pre1 w1 0 . . . . . . pre wn n Fig. 1. post1 wm 0 post m A transition with pre- and postplaces The presented model consists of two classes, one for places (PLACE) and one for transitions (TRANSITION). In Fig. 4 a place is visualized as a circle and a transition as a bar. The places 1 n form the preset of the depicted transition, and the places 1 m form the postset. Pre- and postset are modeled by their characteristic functions, e.g. unary functions in the signature of TRANSITION, being set to true for each member. Members of the preset are called preplaces and member of the postset are called postplaces. Another unary function in the signature of TRANSITION denotes the weight of the arrow between the transition and its preplaces ( 1 n in Fig. 4) and postplaces ( 1 m in Fig. 4). This three functions and the instances of PLACE and TRANSITION form the static part of our ObASM model. The state of a Petri-net is given by the number of tokens at each place, here modeled by a variable (0-ary function) marking in the signature of PLACE. Given a marking a transition can re if all preplaces have at least as many tokens as the weight of their arrows. If the transition res, it subtracts ( ) tokens from each preplace , and it adds ( ) tokens to each postplace . Each transition tries to re, whenever its pre- and postset have enough tokens. Two transitions might compete for the same tokens (hold by a common preplace) and a kind of hand-shaking is thus needed. The unary dynamic function reserved pre  : : : pre pre  : : : pre w :::w 0 w :::w 0 weight pre pre post weight post is used to keep track how many tokens are reserved by a transition. The following three kinds of messages can be sent by a transition t to a place p: Request(n) requests n tokens from p. If there are more then n tokens, p answers with a Provide message and reserves the requested tokens, otherwise it answers with a Reject message. Release releases the tokens that have been reserved by t. Put(n) sends n tokens to p. In response to that message, p adds n to the number of tokens marking. The complete rule for PLACE is: class PLACE is Put(n): marking := marking + n Request(n): Release: if marking n then marking := marking ; n reserved(snd ) := n Provide ! snd else Reject ! snd endif marking := marking + reserved(snd ) To keep track of the hand{shaking a transition uses a unary relation (function with co-domain Boolean) asked to remember those preplaces from which it requested tokens, and it uses a unary relation providing to remember those preplaces that provide the requested tokens. The transition is ready to re again, if none of its preplaces is asked: ready , 8p : preset(p) : :asked(i) We assume to start in a state where all functions are initialized and where the event structure contains one Fire message sent to each transition. If a transition receives a Fire message, it checks whether it is ready and whether the preplaces have currently enough tokens. If not, it resends the Fire message to itself. Otherwise, it sends to all preplaces a Request message, and it sets asked to true for all preplaces. The variable state is set to trying. class TRANSITION is Fire: if (ready ^ 8p : preset(p) : marking(p) weight(p)) then do forall p : preset(p) asked(p) := true Request(weight(p)) ! p enddo trying := true else Fire ! rcv endif Once the system is in state trying, it waits for a Provide or Reject message from each preplace. The function providing is set to true for each preplace that sent a Provide message. If providing is true for all preplaces, the ring was successful, a Put message is sent to all postplaces, providing is reset, and the transition sends a Fire message to itself. In the case a Reject message arrives, the state is set to failed, and a Release message is sent to all providing preplaces. Please note, that at this stage the transition might not yet be ready. In the failed-state, incoming Rejects and Provides are answered by setting asked to false, incoming Provides are additionally answered by sending a Release message. If non of the preplaces is asked anymore, the transition is ready to re again. The rules are as follows: Provide: if state = trying then p : preset(p) : p = snd do forall p : postset(p) Put(weight(p)) p 8 if ! enddo _ providing(p) then p : preset(p) providing (p) := f alse asked(p) := f alse do forall Fire ! rcv enddo else providing (snd ) := true endif state = f ailed then asked(snd ) := f alse elseif Release ! snd endif Reject: if state = trying then state := f ailed do forall p : providing (p) providing (p) := f alse asked(p) := f alse Release p ! Fire ! rcv enddo else asked(snd ) := f alse endif 5 Integration in System Engineering As mentioned in the introduction ASMs have been used to model both hardware and software systems. The case studies show, that ASMs are an implementation independent formalism, that can account for the peculiarities of both hard and software. In 9] it is shown how to analyze such mixed systems and we believe that ASMs are well suited for hardware/software codesign. ObASMs support the design process by allowing to compose the heterogeneous components horizontally. Due to the locality of the components, veried vertical renements from abstract ASMs to more concrete ones can still be applied 5 . Having a formalism suited to specify complex systems on dierent abstraction levels, the integration in system engineering poses the following additional requirements 1. It must be very easy to generate prototypes, both for abstract and more concrete models. 2. The ObASM components must run together with existing, non specied hardware and software components. Prototyping a single object can be done by compiling to executable code 1], or rening to an ASM that corresponds to a simple hardware model, as for instance the RT-formalization in 26], corresponding essentially to a simple form of ASMs. For the communication with other components only the message passing mechanism and the read access must be implemented. The implementation must support all dierent kinds of subsystem-prototypes and the surrounding existing system components. One scenario that we implemented in a prototype is the integration of ObASMs in a component software system, in our case JavaBeans, where subsystems can be written in a traditional programming language (Java), rather then specied with ASMs. In our prototype each ObASM class is translated into a Java class, making components specied as ObASMs and directly implemented software components completely interchangeable. Based on this integration, sophisticated test scenarios are possible, that can be applied whenever verication or model checking fail. One possibility is to have for critical software components both the ObASM specication and an implementation. The reliable, but slow formal model, could be run in parallel with the implementation until one has gained condence in the implementation. 6 Future Work In Aslan 1] the long present concept of hierarchical ASMs is implemented and used to structure single ASMs. Hierarchical ASMs allow to call other ASMs, which corresponds to synchronous message passing, in contrast to asynchronous message passing in ObASMs. Although synchronous message passing can be simulated with asynchronous, and vice versa, an integration of both may be useful. Another point is the introduction of object orientedness in ASMs. While Aslan proposes a simple, pure syntactical method mapping everything to the 5 See 4] for veri ed re nements from Occam code to Transputer code, and 6] for veri ed hardware re nements of RISC architectures. global state, the use of ObASMs may lead to a more natural model, accounting for distributed loading and linking of classes as well as for garbage collection. We mentioned Montages 24]2], a framework allowing to give semantics to a program by generating its control-/data-ow graph and giving the dynamic semantics of the single nodes by ASM-rules. As in ObASM, the nodes have a type, e.g. the syntactical category, a local state and a behavior. To use ObASM to formalize control ow in Montages might be convenient and fruitful, especially in the case of languages with distributed control ow. On the other hand, Montages might be useful to dene control-/data-ow structures for ObASMs in a generic way. Acknowledgments We would like to thank Matthias Anlau, Yuri Gurevich, and last but not least Alfonso Pierantonio for the long and insightful discussions about ASMs, Montages, and Aslan. Appendix: Denotational Semantics Semantics of ASM rules The formal semantics of a rule R in a state
is given by a deterministic denotation Upd(R,
) being a set of updates 15]. The interpretation of f in the successor state
is dened as follows: Update sets are dened by transition rules. The basic update denotes one update of a function at some point. The new values and the point are given by terms over the signature. Rules can be composed in a parallel fashion, such that all updates are executed at once. Conditional execution of a rule res only in certain cases. The do-forall rule allows to re the same rule for all objects satisfying some condition. Finally the extend-rule allows to introduce reserveobjects, that have not been used before. The last rule is typically used to create new objects of some class. Formally, a transition rule R is built up recursively by the following constructions. The corresponding denotations are given. Let eval
be the usual term evaluation over the state
. f (t1  : : :  tn ) := t0 (Upd 1: basic update) if R = where t0  : : :  tn are terms over  , then Upd (R
) = f(f (eval
(t1 ) : : :  eval
(tn )) eval
(t0 ))g 0 (Upd 2: parallel composition) if R = S Upd (R
) = i 1::: m Upd (Ri 
) then 2f (Upd 3: conditional rules) if R = then R 1 : : : Rm Upd (R
) = ( g if t then Rtrue else Rfalse endif Upd (Rtrue 
) if eval
(t) = true Upd (Rfalse 
) otherwise (Upd 4: do forall) if R = then do forall e : t R 0 enddo Upd (R
) = So:eval
e7!o (t) Upd (R
 e 7! o) ( ) extend E with e (Upd 5: extend) if R = R 0 endextend then Upd (R
) = Upd (R
 e 7! o), where o is a completely new allocated element 6 . Additional Semantics for ObASM ObASMs dene another atomic rule that sends a message to an object. This rule results in no updates: !t Upd (R
) = fg (Upd 0: send) if R = t1 then 2 The other denitions of Upd remain the same, except that for each x evalx must be replaced with evalxrcv and that in Upd 4 and 5 the extension
 e 7! o on the right-hand-side must be replaced by
e o ,

(rcv )=(
(rcv ) 7!  e 7! o)] The message denotation Mes (R
) denes a set of message triples (sender, receiver, content) as follows: ! tnewrcv Mes (R
) = f(rcv eval
rcv (tnewrcv ) eval
rcv (tnewcnt))g (Mes 0: send) if R = then tnewcnt (Mes 1: basic update) if R = f (t1  : : :  tn ) := t0 Mes (R
) = fg then (Mes 2: parallel composition) if R = then (Mes 3: conditional rules) if R = then 6 ( Mes (R
) = Si R 1 : : : Rm 1::: mg 2f Mes (Ri 
) if t then Rtrue else Rfalse endif (Rtrue 
) Mes (R
) = Mes Mes (Rfalse 
) See 15] for a formalization of \completely new" if eval
rcv (t) = true otherwise (Mes 4: do forall) if R = then (Mes 5: extend) Mes(R
) = if R = S do forall e:t R o:eval
e7!o rcv (t) extend E with e R 0 enddo Mes (R
e o) 7! 0 endextend then Mes(R
) = Mes (R
e o ), where o is a completely new allocated element, whose type is set to the class E. Using Upd and Mes, the denotation Den(R) of any rule R can be seen as a mapping from global states to pairs of update sets and message structures: 7! Den(R) :
7! (Upd (R)(
) Mes (R)(
)) References 1. M. Anlau. Aslan - programming in abstract state machines. A small stand{alone ASM interpreter written in C, ftp://ftp. rst.gmd.de/pub/gemmex/Aslan. 2. M. Anlau, P.W. Kutter, and A. Pierantonio. The montages project web page, 1998. http://www.tik.ee.ethz.ch/montages. 3. Bernard Berthomieu and Michel Diaz. Modeling and veri cation of time dependent systems using time Petri nets. IEEE Transactions on Software Engineering, 17(3):259{273, March 1991. 4. E. Borger and I. Durdanovic. Correctness of compiling Occam to Transputer code. Computer Journal, 39(1):52{92, 1996. 5. E. Borger and J. Huggins. Abstract state machines 1988 { 1998: Commented asm bibliography. In H. Ehrig, editor, EATCS Bulletin, Formal Specication Column, number 64, pages 105 { 127. EATCS, February 1998. 6. W. Borger and S. Mazzanti. A practical method for rigorously controllable hardware design. In J.P. Bowen, M.G. Hinchey, and D. Till, editors, ZUM'97: The Z Formal Speication Notation, number 1212 in LNCS, 1997. 7. Giacomo Bucci and Enrico Vicario. Compositional validation of time-critical systems using communicating time Petri nets. IEEE Transactions on Software Engineering, 21(12):969{992, December 1995. 8. R.S. Chin and S.T. Chanson. Distributed object based programming systems. ACM Computing Surveys, 23(1):91 { 124, March 1991. 9. G. Del Castillo and Wolfram Hardt. Fast dynamic analysis of complex hw/swsystems based on abstract state machine models. In Sixth International Workshop on Hardware/Software Codesign. IEEE, 1998. 10. Alois Ferscha. Concurrent execution of timed Petri nets. In Proceedings of the 1994 Winter Simulation Conference, pages 229{236, 1994. 11. Alois Ferscha and G. Haring. Forschungsauftrag: ACPC - Parallele PetrinetzSimulation (Endbericht). Technical report, University of Vienna, 1992. (text in English). 12. P. Glavan and D. Rosenzweig. Communicating evolving algebras. In Selected papers from CSL'92 (Computer Science Logic), number 702 in LNCS, pages 182 { 215. Springer, 1993. 13. Y. Gurevich. Logic and the chanllenge of computer science. In E. Borger, editor, Thrends in Theoretical Computer Science, pages 1 { 57. Computer Science Press, 1988. 14. Y. Gurevich. Evolving algebras 1993: Lipari guide. In E. Borger, editor, Specication and Validation Methods, pages 9 { 36. Oxford University Press, 1995. 15. Y. Gurevich. May 1997 draft of the asm guide. Technical Report CSE-TR-336-97, University of Michigan EECS Department Technical Report, 1997. 16. Y. Gurevich and R. Mani. Group membership protocol: Speci cation and veri cation. In E. Borger, editor, Specication and Validation Methods, pages 295 { 328. Oxford University Press, 1995. 17. Y. Gurevich and L.S. Moss. Algebraic operational semantics and occam. In CSL'89, 3rd Workshop on Computer Science Logic, number 440 in LNCS, pages 176 { 192. Springer, 1990. 18. A. Hall. Taking z seriously. In J.P. Bowen, M.G. Hinchey, and D. Till, editors, ZUM'97: The Z Formal Speication Notation, number 1212 in LNCS, 1997. 19. M. Hinchey and J. Bowen. Applications of Formal Methods. Prentice-Hall, 1995. 20. J. Huggins. Abstract State Machines Web Page. 21. Jorn W. Janneck. Behavioral prediction of time Petri nets with applications to distributed simulation. In Proceedings of the HPC '98, 1998. 22. Jorn W. Janneck and Martin Naedele. Modeling a die bonder with petri nets: A case study. IEEE Transactions on Semiconductor Manufacturing, August 1998. 23. Kurt Jensen. Coloured Petri Nets: Basic Concepts, Analysis Methods and Practical Use, volume 1: Basic Concepts, of EATCS Monographs in Computer Science. Springer-Verlag, 1992. 24. P.W. Kutter and A. Pierantonio. Montages: Speci cations of realistic programming languages. JUCS, 3(5):416 { 442, 1997. 25. Charles A. Lakos. From coloured Petri nets to object Petri nets. In Proceedings of the 15th International Conference on Applications and Theory of Petri Nets, Lecture Notes of Computer Science, 1995. 26. R. Leupers. Retargetable Code Generation for Digital Signal Processors. Kluwer Academic Publishers, 1997. 27. Tadao Murata. Petri nets: Properties, analysis, and applications. Proceedings of the IEEE, 77(4):541{580, April 1989. 28. David M. Nicol and S. Roy. Parallel simulation of timed Petri nets. In Proceeding of the 1991 Winter Simulation Conference, pages 574{583, December 1991. 29. Gregory Scott Thomas. Parallel simulation of Petri nets. Master's thesis, University of Washington, 1991.