From Coloured Petri Nets to Object Petri Nets Charles Lakos, Computer Science Department, University of Tasmania, GPO Box 252C, Hobart, TAS, 7001, Australia. Email:
[email protected] Keywords: Theory of High-Level Petri Nets, Object-Orientation, Multiple Levels of Abstraction Abstract: This paper seeks to establish within a formal framework how Coloured Petri Nets can be enhanced to produce Object Petri Nets. It does so by defining a number of intermediate Petri Net formalisms and identifying the features introduced at each step of the development. Object Petri Nets support a complete integration of object-oriented concepts into Petri Nets, including inheritance and the associated polymorphism and dynamic binding. In particular, Object Petri Nets have a single class hierarchy which includes both token types and subnet types. Interaction between subnets can be either synchronous or asynchronous depending on whether the subnet is defined as a super place or a super transition. The single class hierarchy readily supports multiple levels of activity in the net and the generation and removal of tokens has been defined so that all subcomponents are simultaneously generated or removed, thus simplifying memory management. Despite this descriptive power, Object Petri Nets can be transformed into behaviourally equivalent Coloured Petri Nets, thus providing a basis for adapting existing analysis techniques.
1 Introduction In recent years there has been considerable interest in applying object-oriented technology to Petri Nets. In some cases, the primary concern seems to have been the provision of a formal basis for object-oriented languages [5, 13]. In other cases, the interest has focussed on the combination of abstract data types with Petri Nets [4, 7], while others have sought to use object-oriented techniques even more directly [12, 25, 37]. This paper is a contribution to the last category by proposing a complete integration of object-oriented concepts, such as inheritance, polymorphism and dynamic binding into the Petri Net formalism. It is intended that this integration will encourage software reuse and that the provision of a unified class hierarchy will allow the direct modelling of complex systems with multiple levels of activity. This is a similar motivation to that which led to the definition of Hierarchical Coloured Petri Nets (HCPNS), where it was noted that the absence of compositionality has been one of the main critiques raised against Petri Net models [17]. There are good reasons for going beyond HCPNs – Cherkasova has observed that genuine facilities for hierarchical models are required in modelling complex systems, and not just the textual substitution of HCPNs [9]; Fishwick has observed that the simulation of complex systems requires that they be represented at different levels of abstraction [14]; and Bever et. al. observe that specification techniques which are to be adequate for the future Distributed Computing Environments will need to support hierarchical decomposition and the dynamic reconfiguration of process networks [6]. There are certain application areas which would be particularly amenable to modelling with several levels of activity. Fishwick has observed the demands for simulating increasingly complex systems. A simple example of this might be a traffic intersection, where the cars which move through the intersection can be considered both as data objects and as objects with their own internal activities such as consumption of petrol, mechanical failure, etc. A second area of application is that of Object-Oriented Operating Systems, where the entities handled by the system encapsulate their own protocols. For example, an item of electronic mail may encapsulate the logic to control interaction with its contents – different parts of the document may be visible depending on the security clearance of the viewer, or the display of the message may vary depending on the screen technology available. Similar features are exhibited by Electronic Data Interchange (EDI), where a message encapsulates not only the original message but also related subdocuments. Thus, a bill of lading might incorporate a request for a letter of credit, a request for insurance cover,
etc. This problem is introduced in §2 and is used to illustrate the expressive comfort of the various Petri Net formalisms considered in this paper. A third appropriate application area is the production of prototypes from Object-Oriented Design methodologies. The designs produced by such methodologies include a set of objects, each of which encapsulates its own data and interactions. For example, the Shlaer-Mellor methodology produces objects which encapsulate their own life cycle, and which can be dynamically created and discarded [30]. Without the flexibility of intermixing data and control, the production of prototypes from such designs is rather awkward [27]. Object Petri Nets (OPNs) have therefore been proposed as a more appropriate Petri Net formalism for these kinds of application areas. OPNs embody a complete integration of object-oriented concepts with the result that they can directly model systems with arbitrary levels of activity, as well as having flexible facilities for clearly specifying object interfaces, whether synchronous or asynchronous. An earlier definition of OPNs proved that they are behaviourally equivalent to Coloured Petri Nets (CPNs) [24], thus providing a basis for adapting existing CPN analysis techniques to OPNs. The current paper attempts to present Object Petri Nets in a more accessible manner. It does so by developing a sequence of Petri Net formalisms starting with CPNs and culminating in OPNs, each formalism enhancing the expressive comfort of the previous one. In doing so, the intention is to demonstrate the continuity with the simpler models and also to indicate some of the ideas which lie behind the proof of behavioural equivalence with CPNs – the full details of that proof are beyond the scope of this paper. Each formalism is illustrated by presenting a solution to the EDI problem described in §2. The formalisms considered are Coloured Petri Nets (CPNs) in §3, Modular Coloured Petri Nets (MCPNs) in §4, Object-Based Petri Nets (OBPNs) in §5, Object-Oriented Petri Nets (OOPNs) in §6, and Object Petri Nets (OPNs) in §7. In §8, we compare the above models with other styles of object-oriented Petri Nets found in the literature, and the conclusions are presented in §9.
2 Example: Electronic Data Interchange In order to demonstrate the different Petri Net formalisms in this paper, an example is taken from the area of Electronic Data Interchange (EDI). This example has been adapted from the Z specification given by Swatman et. al. [33]. A document consists of some standard information (including the address of sender and receiver and the identifier of the associated parent or umbrella document) and a number of information fields. These fields are in the form of pairs, the first element of the pair being a field identifier and the second being the corresponding value, e.g. (cost, $125). The number of information fields varies during the lifetime of the document. For example, a bill of lading for some cargo may have a paper trail including a request for a letter of credit, a request for insurance cover, etc., each of which results in further information being added to the document. A document optionally has an associated reply. An umbrella document encapsulates a document together with its paper trail, which consists of related subdocuments. Umbrella documents have some standard information (including the unique umbrella identifier and the original document fields) together with some variable information. The variable information includes the subdocuments which are yet to be posted, the subdocuments which have already been posted, and the replies expected to subdocuments which have been posted. An EDI subscriber is identified by their address. Subscribers also have a number of mail folders – a spool area where documents which have been received are stored prior to examination, a mail box of documents which have been received and examined, and a folder of documents which have been posted (either originating with this subscriber or replies sent to received mail). The EDI system contains subscribers and documents, and provides the medium by which subscribers can generate documents, the documents are encapsulated in umbrellas, the subdocuments are transmitted as appropriate, and the subscribers can respond to the mail. It is important to note that the EDI system has a number of levels of activity and information containment. The system consists of a variable number of subscribers and umbrellas, each of which contains dynamically varying sets of documents. While not strictly necessary to do so, we wish to
reflect the multiple levels directly in our OPN model, as an indication of how we might model even more complex systems. Similarly, we choose to model synchronous interaction between the various components, not because it is necessary, but to demonstrate support for this less common style of interaction, which incidentally matches the style used in the original Z specification [33]. In our OPN solution (which also happens to be an OBPN), each umbrella and subscriber is defined by an appropriately named class or subnet as in fig 2.1. Each of these classes has arcs incident on the class frame, thus indicating that instances of these classes can act as places by offering tokens to and accepting tokens from their environment. This transfer of tokens needs to be synchronised with actions removing tokens from or depositing tokens into the place. In this way, OPNs support synchronous interaction with subnets. Umbrella
Subscriber umbID
thedoc d'
d
d+d'
1,d reply d
sd(d-d') r(d)
expect
recv
addr 0,d
send
0,d
d
sd(d) topost d post d 2,d
mbox
sent 1,r(d)
r(d)
d
d read
reply
d
d
2,d posted
recv
spool
Fig 2.1: Umbrellas and subscribers as OPN pages
In order to understand the details of these classes, the following functions are assumed to be defined: a(d): the address given in document d r(d): the reply expected to document d, if any sd(d): the subdocuments given by the information fields of document d (sd(d-u) is the subdocuments given by d but not already in u) The non-trivial guards for transitions are given below, with subscript s indicating subscribers: recv s : [a(d)=addr] read s : [r(d)=Ø] reply s : [r(d)≠Ø] Each new umbrella is initialised by receiving a document via the recv transition. This saves the document in place thedoc and stores the subdocuments for posting in place topost. Subsequently, any of the subdocuments for posting can be posted by firing transition post which transfers the subdocument to place posted, and saves the expected reply in place expect. If an expected reply is received with the firing of transition reply, its information fields are used to augment the saved document, and possibly generate further subdocuments for posting. Each subscriber can spontaneously generate a document for posting with the send transition. It may also receive a document at the recv transition, and save it in place spool for later reading. If the document requires a response, the transition reply is fired to read and respond. Otherwise the transition read is fired. Both of these transitions serve to transfer the document from the user's spool area to their mailbox (the place mbox). The EDI system, modelled as in fig 2.2, manages the umbrellas and subscribers. These components are dynamically allocated since new subscribers can be spontaneously generated and new umbrellas are generated for each new document sent by a subscriber. In order to interact with a subscriber or an umbrella, it is necessary to unpack some of the levels of information containment. For example, the transition reply selects a subscriber and then interacts with it. This is possible by extending the notion of port places from Hierarchical Coloured Petri Nets [18]. These port places, identified by the striped shading, can be dynamically fused with actual places. In this case, the port places umb and sub are fused to the corresponding umbrella u or subscriber s, by transition guards umb ~ u and sub ~ s. The dynamic allocation and deallocation of objects, together with the dynamic fusing of port places is
in line with the Actor model [1, 2], with its dynamic communication topology. It should also be noted that it would be a relatively simple matter to enhance the EDI system to include a number of sites for umbrella documents or subscribers, with the possibility of migrating between the sites. EDI System new s umbrellas
subscribers
send
s s
u
u u
0,d
0,d
1,d
s
1,d reply
umb 2,d
2,d
sub
recv
Fig 2.2: The EDI system as an OPN page
3 Coloured Petri Nets (CPNs) We commence with the definition of Coloured Petri Nets which is now a widely accepted Petri Net formalism. The definition here is modified slightly from the standard presentation [18], in the interests of demonstrating the continuity with the later formalisms. Definition 3.1: The following are assumed to be well-defined: (a) the set of elements of type T , which can be denoted by T. (b) the multiset of elements of type T, which is denoted by T*. (c) multiset addition, subtraction, scalar multiplication, comparison operations, denoted in the usual way. (The multiset difference m 1 – m2 is assumed to be defined analogously to set difference, even when m 1 ≥ m 2 does not hold.) (d) the type of a variable v, denoted Type(v). (e) the type of an expression expr, denoted Type(expr) (f) the set of variables in expression expr, denoted Var(expr). (g) the binding, b, of a set of variables V, where ∀v∈V: b(v) ∈ Type(v). (h) the value obtained by evaluating the expression expr in binding b, denoted expr. (Var(expr) must be a subset of the variables of b.) Definition 3.2: A Coloured Petri Net is a tuple CPN = (Σ, P, T, A, τ, G, E, I) where: (a) Σ is a finite set of non-empty types, called colour sets. (b) P is a finite set of places. (c) T is a finite set of transitions with P ∩ T = Ø (d) A is a finite set of arcs such that A ⊆ P × T ∪ T × P and A ∩ (P ∪ T) = Ø (e) τ is a colour function, τ: P → Σ where τ(p) = C* for p ∈ P and C* ∈ Σ (f) G is a guard function, G: T → expr where ∀t ∈T: [Type(G(t)) = bool ∧ Type(Var(G(t))) ⊆ Σ]. (g) E is an arc expression function, E: P × T ∪ T × P → expr where E(x1,x2) = Ø if (x1,x2) ∉ A and ∀a ∈A: [Type(E(a)) = τ(p(a)) ∧ Type(Var(E(a))) ⊆ Σ] where p(a) is the place of arc a. (h) I is an initialization function, I: P → expr where I(p) is a closed expression (i.e. it contains no free variables) and ∀p ∈P: [Type(I(p)) = τ(p)]. Notes: (a) If a place holds tokens of colour type C, then its multiset type C* ∈ Σ. (b) Places serve to hold tokens, with the distribution of tokens determining the state of the net.
(c) Transitions serve to effect changes of state, and hence are distinct from places. (d) Arcs have been restricted so that each transition has at most one input and one output arc to each place. This has been done merely to reduce the number of definitions and thereby simplify the presentation. (e) The colour or type function τ gives the (multiset) type of values associated with each place. (f) The guard associates a boolean expression with each transition, which must evaluate to true for the transition to be enabled. (g) The arc inscription is only non-empty for arcs and its expression must have a type matching the type of the place to which the arc is connected. (h) The initialisation of a data field must specify an appropriately typed value. Definition 3.3: A token element is a pair (p,c) where p∈P, c∈C, and τ(p)=C*. The set of all token elements is denoted TE. A marking M is a multiset over TE. A marking M can interchangeably be treated as a multiset and as a function on P with ∀p∈P: M(p) ∈ τ(p). The initial marking M 0 is the marking obtained by evaluating the initialization expressions, i.e. ∀p∈P: M 0(p) = I(p). The set of all markings is denoted by .
M
Definition 3.4: A binding b of transition t is a binding of the variables Var(t) satisfying G(t). B(t) is used to denote the set of all bindings for t. A binding element is a pair (t,b) where t ∈ T and b ∈ B(t). The set of all binding elements is denoted by BE. A step Y is a non-empty, finite multi-set over BE. A step Y can interchangeably be treated as a multiset and as a function on T, with Y(t) being the multiset of bindings of transition t in Y. The set of all steps is denoted .
Y
Definition 3.5: The multiset of tokens removed from (added to) places by step Y is denoted get Y (putY), and is defined by: getY = Σ Σ {p} × E(p,t) putY = Σ Σ {p} × E(t,p) (t,b) ∈ Y p ∈ P
(t,b) ∈ Y p ∈ P
Definition 3.6: A step Y is enabled in a marking M of net CPN iff: M ≥ get Y. Definition 3.7: When a step Y is enabled in a marking M of net CPN, it may occur, changing the marking M to another marking M', defined by: M' = M – get Y + putY. The above formalism is now illustrated by considering how the EDI system of §2 might be modelled as a CPN. Documents consist of some standard information and a variable number of information fields. The natural object-oriented solution would be to store each document as a place with the contained tokens being the information fields. However, the number of documents varies over the lifetime of the system whereas the CPN formalism does not support the dynamic generation or discarding of places. Further, concurrent access to the information fields is probably unnecessary and documents are components of other objects – both of umbrellas and subscribers. For these reasons, it is preferable to represent each document as a single token with a list component holding the variable number of information fields. Umbrellas are documents together with their associated paper trail of subdocuments – the subdocuments yet to be posted, those already posted, and the replies expected to documents already posted. These three sets of subdocuments vary during the lifetime of the umbrella. Concurrent access to these subdocuments is desirable since an umbrella could concurrently post one or more subdocuments and receive a reply to one or more subdocuments which have already been posted. This suggests that the three sets of subdocuments should be stored as places, with each token in the place being one subdocument. (Alternatively, an umbrella could be stored as a single token having a component list for each set of subdocuments, but this solution would exclude concurrent access.) Assuming that each set of subdocuments is stored as a separate place, and given that the number of umbrellas varies during the lifetime of the EDI system, it is necessary to fold the sets of subdocuments for the various umbrellas onto the one set of places, using a unique identifier to relate the components
for each umbrella. This leads to the following places for holding the umbrella information: umb: tokens are pairs (umbrella id, original document), i.e. type (umb_id × doc)* topost: tokens are pairs (umbrella id, subdocument to be posted), i.e. type (umb_id × doc)* posted: tokens are pairs (umbrella id, subdocument already posted), i.e. type (umb_id × doc)* expect: tokens are pairs (umbrella id, reply expected), i.e. type (umb_id × doc)* Subscribers are identified by their addresses and have associated sets of documents – those which have been received but not read, those which have been received and read, and those which have been sent. As with umbrellas, the sets of documents vary during the lifetime of the subscriber, concurrent access is appropriate since a subscriber may be receiving messages into the spool area at the same time as reading or posting others. Again, it is appropriate for each of these sets of documents to be represented as a place, and to fold the sets for the different subscribers onto the one set of places. This leads to the following places for holding the subscriber information: subs: tokens are subscriber ids (or addresses), i.e. type subs_id* spool: tokens are pairs (subscriber id, received document), i.e. type (subs_id × doc)* mbox: tokens are pairs (subscriber id, read document), i.e. type (subs_id × doc)* sent: tokens are pairs (subscriber id, posted document), i.e. type (subs_id × doc)* The EDI system consists of the above identified places together with transitions to generate new subscribers, to generate new mail, to send and receive subdocuments, as shown in fig 3.1. It is not easy to lay out this net, since most transitions synchronise activities of both an umbrella and a subscriber, together with their associated documents. s
subs s s
new u u
umb u
d sd(u)
d
r(d)
s sent
send
r(d)
sd(r(d)-u)
topost
s
d reply
mbox d d
d
expect
spool read r(d)
d
posted d recv
Fig 3.1: The EDI system as a CPN
The functions assumed by this model are defined as in §2. The transitions have the following guards (given in brackets) and corresponding effects: new [true]: generate a new subscriber send [u=d]: subscriber s sends document d which becomes umbrella u recv [a(d)=s]: umbrella u posts subdocument d to subscriber s read [r(d)=Ø]: subscriber s reads document d which requires no reply reply [r(d)≠Ø]: subscriber s sends reply r(d) for document d to umbrella u (the subdocuments of u are augmented by sd(d–u)). It should be noted that despite our stated intentions, the CPN for the EDI system does not allow for concurrent actions for the one umbrella or the one subscriber. This is because the umbrella token (u) and the subscriber token (s) are removed from the relevant place (umb and subs respectively) and reinstated by each transition. Concurrent actions could be supported if the access to the umbrella or subscriber token was via a test arc [22]. It should also be noted that further enhancement to the EDI system could lead to significant added complexity in the CPN. For example, one might wish to maintain a number of sites for umbrella documents or subscribers, with the possibility of umbrellas and subscribers migrating between the
sites. It would be possible to do this by having a distinct set of places for each site, provided the number of such sites were fixed, or it would be possible to add a site identification field to each document and subscriber. In both cases, it will not be possible to migrate an umbrella or a subscriber (together with their associated documents) between sites without the use of further CPN arc extensions such as the clear arc [22]. In other words, the technique of folding multiple place instances onto one set of places has definite limitations when extensions are considered.
4 Modular Coloured Petri Nets (MCPNs) The title for this section has been taken from a paper which considered invariant analysis in the context of modular nets incorporating both place and transition fusion [11]. Modular Coloured Petri Nets therefore extend Hierarchical Coloured Petri Nets (HCPNs) [18] by supporting the notion of substitution places as well as substitution transitions (as was the case in the original HCPN proposal [16]). In this paper, these constructs are referred to as super places and super transitions respectively, in order to avoid connotations of textual substitution. Our presentation differs from that in [11], since we wish to retain the notion of hierarchy rather than viewing the net as a flat collection of subnets with appropriate connections [18]. This hierarchy is then enhanced in the following section. Just as place fusion provides a mechanism for interfacing a subnet with its environment via places (and hence the term super transition), so transition fusion provides a mechanism for interfacing a subnet with its environment via transitions (and hence the term super place). Transition fusion is normally defined by specifying a pair or a set of transitions which can (or must) be synchronised in a step. The extension of CPNs with synchronous channels [10] provides a more flexible form of transition fusion, since it allows the synchronisation of a multiset of binding elements. Each such binding element specifies an input or an output to a named channel. The multiset of allowable binding elements in a step is constrained so that for each named channel the (multiset) sum of all inputs from the channel is identical to the (multiset) sum of all outputs to the channel, a condition referred to as communication enabling. In this presentation, synchronous channels are used to implement the interaction with super places. Transition t interacting with super place p can be represented as in fig 4.1. t
p e
External view
p
t' e'
Internal view
Fig 4.1: External and internal view of a super place
The external view shows transition t offering the multiset of tokens given by expression e to super place p. The internal view shows how super place p accepts the multiset of tokens given by expression e' from its environment by firing transition t'. The offer or acceptance of tokens by the super place is thus constrained by its internal logic. The matching of the external offer of tokens and the internal acceptance of those tokens is implemented using synchronous channels. This allows transitions t and t' to occur an arbitrary number of times in a step provided communication enabling is ensured. For example, the arc inscription e could specify a multiset of tokens, while the arc inscription e' could specify a single token, in which case a communication enabled step would have one occurrence of t and a multiset of occurrences of t' (with various bindings). The channels used for interacting with super places can be identified or named in a number of ways. The most obvious solution (based on the above presentation) is to associate two channels with each super place – one for input and one for output – and to identify them by the super place and the direction of token transfer, i.e. for super place p the channels could be p.in and p.out. This approach could be made more specific by extending the names to indicate the internal transition with which you wished to synchronise, thus supporting a set of distinct interfaces for each super place. However, this introduces a discontinuity between the interaction of a transition with a simple place and with a super place. Alternatively, the original proposal could be made more general by naming the channels with the type of place and the direction of token transfer. In order to specify communication with a
particular super place, the arc inscription will have tokens tagged by the instance identifier of the super place p. This approach is adopted because it supports a more flexible interaction with super places, including the dynamic communication topology advocated in the Actor model [1, 2]. The definitions below need to be read in conjunction with the associated notes which offer some explanatory comments. Definition 4.1: A Modular Coloured Petri Net page s, in the context of a set of pages S, is a tuple (OID, Σs , Ks, P s, PPs , Ts, A s, τs, σs, G s, E s, I s) with: (a) OID = { OIDs' | s' ∈ S } where each OIDs' is a set of distinct object identifiers associated with the instances of page s' in S (b) Σs is a finite set of colour sets with OID ⊆ Σs where ∀OIDs' ∈OID: ∀C ∈Σ s: C = OIDs' ∨ C ∩ OID s' = Ø (c) Ks is a finite set of constants (d) Ps is a finite set of places with K s ∩ P s = Ø (e) PPs is a finite set of port places PPs ⊆ Ps possibly with self ∈ PPs (f) Ts is a finite set of transitions with (K s ∪ P s) ∩ T s = Ø (g) As is a finite set of arcs such that A s ⊆ P s × Ts ∪ T s × P s and (K s ∪ Ps ∪ Ts) ∩ A s = Ø (h) τs is a colour function, τ s: K s ∪ P s ∪ Ts → Σs where ∀k ∈Ks: τ(k) ≠ Ø and ∀p ∈Ps: τ(p) = C* ∨ τ(p) = OIDs' for some s' and ∀t ∈T s: τ(t) = Ø ∨ τ(t) = OIDs' for some s' (i) σs is a token interface function, σs: Ps → Σs – OID where ∀p ∈Ps: σs (p) = C* (j) Gs is a guard function, Gs : Ts → expr where ∀t ∈T: [Type(G s (t)) = bool ∧ Type(Var(Gs (t))) ⊆ Σ s] (k) Es is an arc expression function, E s: Ps × Ts ∪ T s × P s → expr where Es(x 1,x2) = Ø if (x1,x2) ∉ A s and ∀a ∈As: [Type(E s(a)) = σs(p(a)) ∧ Type(Var(E s(a))) ⊆ Σs] where p(a) is the place of arc a. (l) Is is a partial initialization function, I s: K s ∪ P s ∪ Ts – PPs → expr where ∀x ∈Ks ∪ P s ∪ Ts – PPs: Is(x) is a closed expression and is defined if τ(x) ≠ Ø and ∀x ∈Ks ∪ P s ∪ Ts – PPs: [τ s(x) = Ø ∨ Type(I s(x)) = τs(x)] ∀s' ∈ S: Is(x) ≤ OIDs' and Σ x ∈ K s ∪ Ps ∪ Ts – PPs τ(x) ∈ OID
Notes: (a) The object identifiers in OID uniquely identify the instances of each page. (b) Each page has a set of colour sets including the sets of object identifiers in OID. The object identifiers do not occur otherwise in Σs. The empty set is now included in Σs (see part (h)). (c) For modular nets, it is desirable to allow constants to be associated with each page instance. Alternatively, this could be supported in the underlying expression language (see def 3.1). (d) Places are allowed as before, and are distinct from the constants. (e) Some places can be identified as port places. These places do not hold tokens in their own right, but are used as aliases (possibly indirect) to existing places. Port places are used to specify the interaction between a super transition and its environment, by fusing the internal port places with places in the super transition's environment. The reserved symbol self may be a port place and is used by a super place (see below) to pass tokens to its environment. (f) As is usual, the sets of places and transitions are disjoint. Since these sets include super places and super transitions (see below), this implies that pages or subnets normally interact with their environment in one of these two patterns. (g) As in definition 3.2, there is at most one arc from each place to a transition and from each transition to a place. As noted above, synchronous channels will be used to implement the interaction between a super place and its neighbouring transitions. (h) The colour function is extended to constants and transitions. This allows us to capture the type of page that a super transition instantiates. The empty type is then associated with simple transitions (which have no associated data).
(i)
The token interface function gives the colour or type of tokens which can be offered to or accepted from places. For MCPNs, this colour cannot include object identifiers. (j) The guard function is as before. (k) The arc expression function gives the arc inscriptions as in definition 3.2 but the type of the arc expressions is now given by the token interface function. This allows for consistency between simple and super places. (l) The initialisation function associates an initial value with every component having a non-empty type. Each super place and super transition (see below) must be assigned a unique object identifier. This can be done by supplying some function returning the next unused object identifier for each page. Definition 4.2: The places and transitions of a MCPN can be subdivided according to their type: (a) The simple places Ps˚ = { p ∈ P s | τs(p) = σs (p) } (b) The super places Ps' = { p ∈ Ps | τs(p) = OIDs' for some s' ∈ S } = Ps – P s˚. (c) The simple transitions Ts˚ = { t ∈ T s | τ s(t) = Ø } (d) The super transitions Ts' = { t ∈ Ts | τs(t) = OID s' for some s' ∈ S } = Ts – Ts˚. (e) The data fields Ds = Ks ∪ Ps ∪ Ts' – PPs . Note: (a) The set of places includes simple places, which are the traditional CPN places. These have a type identical to the token interface type. Hence, simple places cannot hold object identifiers. (b) The set of places also includes super places, which are instances of pages or subnets which offer and accept tokens via synchronous channels. (c) The set of transitions includes simple transitions, which are the traditional CPN transitions. (d) The set of transitions includes super transitions, which are instances of pages or subnets which interact with their environment through port places. (e) The data fields are all the net components which are assigned a value by the initialisation function, and therefore contribute to the marking of the net. It is important to observe that both places and token interfaces explicitly exclude object identifiers. This exclusion is removed in §5. Definition 4.3: A Modular Coloured Petri Net consisting of instances PIs of page s ∈ S is a tuple MCPN = (OID, S, F, s0, oid0) where the following conditions hold and the following collected components are defined: (a) each s ∈ S is an MCPN page (OID, Σs, K s, P s, PPs, T s, A s, τs, σs, G s, Es , I s) (b) Σ = ∪ Σs s∈S
(c) K = ∪ Ks × PIs and similarly for P, PP, T, A, P˚, P', T˚, T', D s∈S
(d) τ: K ∪ P ∪ T → Σ with τ ((x,oid)) = τ s(x) for x ∈ K s ∪ P s ∪ T s, oid ∈ PIs and similarly for σ, G. (e) E: P × T ∪ T × P → expr with E(x 1,x2) = Ø if (x 1,x2) ∉ A and E((x1,oid),(x 2,oid)) = Es(x 1,x2) if oid ∈ PI s (f) I: D → expr with I((d,oid)) = I s(d) for d ∈ D s, oid ∈ PI s ∀s' ∈ S: Σ I(d) ≤ OIDs' and d∈D τ(d) ∈ OID
(g) F is a place fusion function: F: PP → P with F(pp) = p provided τ(pp) = τ(p) ∧ σ(pp) = σ(p) and F((self,oid)) = p provided (self,oid) ∈ PP ∧ p ∈ P' ∧ I(p) = oid (h) s0 is the root page whose instance with object identifier oid 0 contains all other net components. Note: (b) The colour sets for the entire MCPN can be collected together. (c) The net components can be collected together into the sets K, P, PP, T, A, P˚, P', T˚, T', D. (d,e) The net functions τ, σ, G, E can be defined across the whole net. (f) The initialisation function I can be defined across the whole net. It is necessary to ensure that
the object identifiers uniquely identify page instances across the entire MCPN. (g) The place fusion function maps every port place to a place (possibly another port place) with a matching type and token interface. As in HCPNs, we expect that the port assignments for a page will normally be specified in the page which instantiates it. The special port place self is always fused to the super place containing it. Definition 4.4: A token element is a pair (d,c) where d∈D, c∈C, and τ(d)=C or τ(d)=C*. The set of all token elements is denoted TE. A marking M of an Modular Coloured Petri Net MCPN is a multiset over TE. A marking can interchangeably be treated as a multiset and as a function on D with ∀d∈D: M(d) ∈ τ(d). The initial marking M 0 is the marking obtained from the initialization expressions, i.e. ∀d∈D: M0(d) = I(d). The set of all markings is denoted by .
M
Definition 4.5: The instances of page s within multiset m in marking M is denoted ms,M where: ms,M =m if Type(m) ∈ {OIDs} ∪ {OIDs*} =Ø if Type(m) ∉ OID M((d,oid)) = Σ if Type(m) ∈ {OIDs'} ∪ {OID s'*} and s'≠s Σ s,M oid ∈ m
d ∈ D s'
Note: The above definition helps to identify the page instances nested arbitrarily deeply within a particular net component. Definition 4.6: The page instances PIs of page s are given by (a) PI s = (oid0)s,I where oid 0 is the object identifier for the instance of the root page s0 (b) The containers cont(x) of data field, port place, transition, or arc x = (xs,oid) are given by: cont(x) = d ∪ cont(d) where d ∈ P' ∪ T', I(d) = oid (c) Given a set of net components X, the components internal to y are denoted Xy, where: Xy = { x ∈ X | y ∈ cont(x) } (d) The derivations PD s of page s indicate the relationship of each instance with the root page s 0 and are given as lists: (i) PDs0 = { [ ] } (ii) PDs = { [d | id] | id ∈ PDs' ∧ d = (ds', oids') ∈ P' ∪ T' ∧ τ(d) = OIDs} Note: (a) The page instances can all be derived from the root page instance by the initialisation expressions. Hence, the number of instances of each page does not vary during the lifetime of the net. (b) The definition of a container implies that the components of the root page do not have a container. This is only relevant in definition 4.9 where the offer of tokens by a page to its environment is defined. (c) It is convenient to be able to identify the components nested within other components. (d) Derivations are not required in this presentation but are included because they correspond to the page instances defined for HCPNs [18]. The definitions of bindings, binding elements, and steps are identical to those for CPNs (def 3.4). Definition 4.7: The place fusion function F defines a fusion relationship p ~ p' over places (which is symmetric and transitive) by: (a) p ~ p' if p = p' ∨ F(p) = p' ∨ F(p') = p (b) p ~ p' if ∃p": p ~ p" ∧ p" ~ p' Definition 4.8: The multiset of token elements removed from (or added to) places P by transitions T in step Y is denoted get Y(P,T) (respectively putY(P,T)) where: (a) getY(P,T) = Σ Σ Σ Σ {p} × E(p',t) t ∈ T b ∈ Y(t) p ∈ P p' ~ p
(b)
putY(P,T) =
Σ Σ Σ Σ
t ∈ T b ∈ Y(t) p ∈ P p' ~ p
{p} × E(t,p')
Note: These definitions are essentially the same as those of definition 3.5 but extended to cater for the place fusion. They have been expanded in somewhat tedious detail so that it is possible to derive the effects of the step on a subset of places or transitions.
In the context of MCPNs, with super places and super transitions, we define the enabling of a step as the combination of a local or internal condition, together with an interfacing or external requirement. Definition 4.9: A step Y is enabled in a marking M of net MCPN iff: (a) ∀x∈P–PP: x.enabled Y(getY({x}, T˚– Txo ), putY({x}, T˚– Txo )) where: x.enabledY(g,p) = (M(x) ≥ g(x)) = (g = put Y({x}, Txo ) ∧ p = get Y({x}, Txo )) (b) ∀x∈T: x.enabledY(get Y(P–Px, {x}), put Y(P–P x, {x})) and x.enabledY(g,p) = true = (g = getY(P–Px, Txo ) ∧ p = putY(P–P x, Txo ))
if x ∈ P˚ if x ∈ P ' if x ∈ T˚ if x ∈ T '
Note: (a) For both simple and super places, the global enabling condition is that the place can accommodate the tokens extracted from or passed to it. A simple place does so from the existing marking, while a super place does so by matching the token requirements with internal transitions. The token requirements are determined by the functions get Y and putY restricted to the interaction of external transitions with the specified place. (b) For both simple and super transitions, the global enabling condition is that the transition can produce the effects of the incident arcs. In this case, the effects are given by the functions get Y and putY restricted to the particular transition and its external places. For a simple transition, there is no additional local requirement, while for a super transition its interaction with the external places must be matched by its internal effects via its port places. An important consequence of extending the enabling conditions to incorporate super transitions is that the annotation of super transitions with guards and arcs to neighbouring places is significant (cf [18]) and can be viewed as abstracting away from the inner details of the super transition. Definition 4.10: When a step Y is enabled in a marking M of net MCPN, it may occur, changing the marking M to another marking M', defined by: M' = M – get Y(P˚–PP, T˚) + putY(P˚–PP, T˚) The following observations can be made about the above definitions: (a) HCPNs allow for a multiset of prime pages while MCPNs are defined to have a single root page. This is less convenient, even if not restrictive, since the root page can instantiate as many pages as desired. The formalism of §5 allows any place to hold a multiset of pages. (b) As with HCPNs, the number of page instances and the place fusion relationship is statically determined in MCPNs. This is modified in §5 where both can be determined dynamically – by the marking and by the particular step under consideration. In presenting an MCPN solution to the EDI problem, the system could have asynchronous or synchronous interaction between subscribers and umbrella documents – a case could be made for either alternative, and the MCPN formalism directly supports both. For demonstrative purposes, we choose the synchronous interaction of the original Z specification [33]. Documents will be modelled as in the CPN solution. Subscribers and umbrellas will also be modelled as in the CPN solution, except that their logic will be encapsulated in super places. This results in the MCPN components of figs 4.2 and 4.3. Note that documents are transferred between the system environment by tagging them with an integer: 0 for a new document, 1 for a reply, 2 for sending a subdocument. It is assumed that the subscriber interface accepts a union type encompassing both documents and new subscribers. The types of places will be as before, with the addition of new places in the EDI system page: umbrellas: Umbrella page subscribers: Subscriber page The transitions which have non-trivial guards are given below, with subscripts u and s to differentiate umbrellas and subscribers: send u : [u=d] read s : [r(d)=Ø] recv s : [a(d)=s] reply s : [r(d)≠Ø]
subs
umb u u u
s 0,d
sd(u)
d
s
0,d
1,d
sd(d-u)
s
new
send
topost d
s
d send
reply
expect
1,r(d)
d reply
posted
r(d)
ss
sent
r(d) mbox d d
d
2,d
d
read
spool
recv d
2,d recv recv Umbrella
Subscriber
Fig 4.2: EDI umbrellas and subscribers as MCPN pages new s umbrellas i,d
send
i,d
subscribers i,d i,d
recv
Fig 4.3 : EDI system as a MCPN
Note that the above solution helps to encapsulate the logic pertinent to each of umbrellas and subscribers. The internal logic of each is clearly indicated while the interaction is specified by the root page. As with the CPN solution, it will be observed that there is limited concurrency in this solution. Again, this can be remedied with the use of test arcs. Similarly, there will be difficulties in extending this solution to cater for multiple sites and the migration of umbrellas and/or subscribers.
5 Object-Based Petri Nets (OBPNs) It has already been noted that complex systems have multiple levels of activity and therefore it is desirable to be able to model them at different levels of abstraction [6, 9, 14]. This motivates the definition of Petri Nets with multiple levels of activity, where tokens are no longer passive objects but are allowed to be subnets encapsulating their own activity and/or their own interaction strategy. It is worth noting that multiple levels of activity or information containment are often masked in CPN models with standard techniques such as folding [9]. In the CPN and MCPN solutions to the EDI system this can be seen in the encoding of the information fields in a token type (thus limiting the possible concurrency), and in the folding of multiple subscribers and umbrellas onto the one set of subscriber and umbrella places (thus making it difficult to move or discard these objects). It is considered preferable to include this form of folding in an implementation, rather than forcing it on the modeller. In general, an object in a multi-level Petri Net is an instance of a Petri Net page. Different instances of the same page are differentiated by object identifiers, just as subscriber and umbrella components were differentiated by subscriber addresses and umbrella identifiers in the EDI example of §3. In general, the marking of a (simple) place in such a page can be specified by the tokens resident in the place, plus the object identifier of the page instance. Furthermore, if tokens can be object identifiers, then they can represent nested page instances. In this way, it is possible to cater directly for multiple levels of activity or information containment in the Petri Net formalism, and to hide the above folding and encoding techniques in the implementation.
One might even argue that the exclusion of multiple levels of activity in Petri Net models has a parallel in the limitations on data types supported by FORTRAN 66, where it was not possible to declare an array of records, but rather a record of arrays. These limitations were removed in Pascal with its more regular system of data types [20, 29]. Object-Based Petri Nets (OBPNs) enhance MCPNs with multiple levels of activity, by allowing tokens to be object identifiers of pages. The title of this Petri Net formalism has been derived from the classification of programming languages into object-based and object-oriented by Wegner [38]. Object-based languages have encapsulation and instantiation of classes, but do not have inheritance nor the associated polymorphism and dynamic binding. Definition 5.1: An Object-Based Petri Net page s, in the context of a set of pages S, is a MCPN page (OID, Σs, K s, P s, PPs, T s, As, τ s, σs, G s, Es, I s) as in definition 4.1 with the following changes: (a) OID = { OIDs' | s' ∈ S } ∪ { OID s'* | s' ∈ S } where each OID s' is a set of distinct object identifiers associated with each page s' in S (i) σs is a token interface function, σs: Ps → Σs where σs(p) = C* for p ∈ Ps Note: (a) The set OID now includes multisets of object identifiers. (i) A token interface can now include object identifiers. As in definition 4.2, the places and transitions of an OBPN can be subdivided into simple places, super places, simple transitions, super transitions, and data fields. Since the token interface function can now include object identifiers, simple places may now also hold object identifiers. Definition 5.2: An Object-Based Petri Net, consisting of instances PIs,M of pages s ∈ S in marking M, is a tuple OBPN = (OID, S, F, s0, oid0) which satisfies the MCPN definition 4.3 except that: (a) each s ∈ S is an OBPN page (OID, Σs, K s, P s, PPs, T s, A s, τs, σs, G s, Es , I s) (c) K = ∪ Ks × PIs,M and similarly for P, PP, T, A, P˚, P', T˚, T', D. s∈S
(g) F is a place fusion function, F: PP → expr where ∀pp ∈ PP : [Type(F(pp)) = τ(pp)] Note: (g) Place fusion is now specified by an expression which will be determined by a particular binding element. It is important to note that the number of instances of any page varies during execution of the net. The identification of page instances and the marking of the net are now interrelated notions, as captured by the following definitions. The definition of a marking and the instances of page s within multiset m are identical to those for MCPNs (definitions 4.4, 4.5). Definition 5.3: The page instances PI s,M of page s in marking M, are given by: (a) PI s,M = (oid0)s,M (b) The containers cont(x) of data field, port place, transition, or arc x = (xs,oid) are given by: cont(x) = d ∪ cont(d) if τ(d) = OIDs ∧ oid = I(d) ∨ τ(d) = OIDs* ∧ oid ∈ I(d) (c) Given a set of net components X, the components within y are denoted X y: Xy = { x ∈ X | y ∈ cont(x) } (d) The derivations PD s of page s indicate the relationship of each instance with the root page s 0 and are given as lists: (i) PDs0 = { [ ] } (ii) PDs = { [d | id] | id ∈ PDs' ∧ d = (ds', oids') ∈ D ∧ (τ(d) = OIDs ∨ τ(d) = OIDs*) } Definition 5.4: A binding, binding element, and step are defined as in definition 3.4, except that a binding of a transition t ∈ T satisfies the additional requirement:
∀pp ∈ Port(t): F(pp) ∈ (Ps–PPs) × OIDs and F((self,oid)) = p provided (self,oid) ∈ PP ∧ p ∈ P' ∧ M(p) = oid where Port(t) = { pp ∈ PP | (pp,t) ∈ A ∨ (t,pp) ∈ A} Note: Port places are fused to existing or newly-generated places, and the special port place self is always fused to its containing super place. Definition 5.5: Given a binding b of transition t, the place fusion function F defines a fusion relationship p ~b p' over places by: (a) p ~b p' if p = p' ∨ F(p) = p' ∨ F(p') = p (b) p ~b p' if ∃p": p ~b p" ∧ p" ~ b p' The functions getY and putY, which determine the multisets of token elements removed from and added to places P by transitions T in step Y are defined as in definition 4.8, except that the fusion relationship p' ~ p is replaced by the fusion relationship defined above, i.e. p' ~b p. Definition 5.6: For step Y in marking M, we define the deleted and newly-generated object identifiers of page s, the augmented net components, and the augmented marking by: (a) del Y(s) = Σ Σ E(p,t)s,M – Σ E(t,p)s,M the deleted object identifiers (t,b) ∈ Y p ∈ P
(b) new Y(s) =
Σ Σ
(t,b) ∈ Y p ∈ P
p∈P
E(t,p)s,M –
Σ
p∈P
E(p,t)s,M
the generated object identifiers
(c) K = {(k s,oid) ∈ Ks × OIDs | s ∈ S ∧ oid ∈ new Y(s) } the augmented constants, and similar definitions can be made for P+ , PP+ , T+, A + , P˚+ , P' +, T˚+ , T'+ , D +. (d) The augmented marking M + is defined by: + ∀d∈D: M (d) = M(d) ∀d∈D+–D: M+(d) = I(d) +
Definition 5.7: A step Y is enabled in a marking M of net OBPN iff: (a) ∀s∈S: delY(s) ≤ PIs,M ∧ newY(s) ≤ OIDs – PIs,M (b) ∀x∈P+–PP +: x.enabled Y(getY({x}, T˚ +– Txo + ), putY({x}, T˚ +– Txo + )) x.enabledY(g,p) = (M (x) ≥ g(x)) + + = (g = put Y({x}, Txo ) ∧ p = getY({x}, Txo )) + + + + + (c) ∀x∈T : x.enabledY(get Y(P –Px , {x}), put Y(P –Px , {x})) and x.enabledY(g,p) = true + + + + = (g = getY(P +–P x+, Txo ) ∧ p = putY(P –P x , Txo )) where:
+
if x ∈ P˚ if x ∈ P' +
+
if x ∈ T˚ if x ∈ T'+
+
Note: Condition (a) maintains the uniqueness of the object identifiers of pages. Conditions (b) and (c) are the same as in definition 4.9. Definition 5.8: When a step Y is enabled in a marking M of net OBPN, it may occur, changing the marking M to another marking M', defined by: M' = M+ – getY(P˚ +–PP +, T˚ +) + putY(P˚ +–PP+ , T˚+ ) Note: The new marking is derived from the augmented marking. The above definitions imply that when an object identifier is discarded, then so is the associated page instance. This guarantees that there will be no dangling references of object identifiers. This does not preclude the possibility of having alternative techniques for referring to page instances, which are then controlled by the user and which may lead to dangling references. An OBPN solution to the EDI problem has already been presented in figs 2.1 and 2.2.
6 Object-Oriented Petri Nets (OOPNs) Object-Oriented Petri Nets are derived from Object-Based Petri Nets by including the notion of inheritance together with the associated polymorphism and dynamic binding. Previous experiments
have demonstrated the benefits of inheritance in building flexible and reusable Petri Net components [25, 26]. For OOPNs, pages are now referred to as classes, which can be related by inheritance. This is the distinguishing characteristic of OOPNs as opposed to OBPNs. There is considerable debate in the object-oriented community about the appropriate properties to be satisfied when one class inherits from another. Wegner outlines a number of possibilities [39]. The basic options are characterised by subtyping and subclassing. In the former, a subtype is compatible with its supertype, and subtype values can be substituted in any supertype context. This is classified as complete compatibility and leads to the contravariant style of function definition – a function in a subtype can override the definition in the supertype if its argument types are supertypes of the argument types in the supertype definition. Wegner observes that the principle of substitutability is too stringent for many practical applications. The alternative approach of subclassing emphasizes code reuse and follows the covariant style of function definition – a function in a subclass can override the definition in the superclass if its argument types are subclasses of the argument types in the superclass definition. From our own experience, the covariant style is more useful in practice and has been adopted in the following definitions. Definition 6.1: An OBPN page s 1 is a subclass of page s2, written s 1 ≤: s2 iff: (a) ∀d ∈ Ds2: d ∈ Ds1 ∧ τs1(d) ≤: τs2(d) ∧ σ s1(d) ≤: σ s2(d) ∧ Type(Is1(d)) ≤: Type(Is2(d)) (b) ∀a ∈ A s2: a ∈ A s1 ∧ Type(Es1(a)) ≤: Type(Es2(a)) Where page s is a subclass of page s', i.e. s ≤: s', we also write OID s ≤: OIDs' . The relationship ≤: can be extended to other colour sets in some meaningful way, or else we can simply assert that the relationship C 1 ≤: C 2 only holds when colour sets C 1 and C2 are identical. Definition 6.2: An Object-Oriented Petri Net class is an Object-Based Petri Net page as in definition 5.1 with the following changes: (k) Es is an arc expression function, E s: Ps × Ts ∪ T s × P s → expr where Es(x 1,x2) = Ø if (x1,x2) ∉ A s and ∀a ∈As: [Type(E s(a)) ≤: σs(p(a)) ∧ Type(Var(E s(a))) ⊆ Σs] where p(a) is the place of arc a. (l) Is is a partial initialization function, I s: K s ∪ P s ∪ Ts – PPs → expr where ∀x ∈Ks ∪ P s ∪ Ts – PPs: Is(x) is a closed expression and is defined if τ(x) ≠ Ø and ∀x ∈Ks ∪ P s ∪ Ts – PPs: [τ s(x) = Ø ∨ Type(I s(x)) ≤: τs(x)] ∀s' ∈ S: Is(x) ≤ OIDs' and Σ x ∈ K s ∪ Ps ∪ Ts – PPs τ(x) ∈ OID
Definition 6.3: An Object-Oriented Petri Net is an OBPN as in definition 5.2 except that: (g) F is a place fusion function, F: PP → expr where ∀pp ∈ PP : [Type(F(pp)) ≤: τ(pp)] The above definitions introduce inheritance or subclassing into the previous definitions for OBPNs. A subclass may inherit from a parent and augment the class components or override them within the constraints indicated. The modifications mean that an instance of a subclass can be used polymorphically in a superclass context. Thus tokens which are instances of a class occurring in the marking of a simple place or in an arc inscription may be a subclass of the declared class. This implies that arcs can select tokens according to their class. Similarly, the values associated with super places, super transitions or variables may be subclass instances. In summary, the covariant style of redefinition has been used because of its greater practical utility. No demands have been made on behavioural compatibility since there is no obvious choice between some form of bisimulation equivalence [7], some state correspondence [4], or perhaps some relationship between the declared invariants of each class [28]. We do not present an OOPN solution to the EDI problem since inheritance has not been used. Inheritance could be introduced by declaring umbrellas as subclasses of documents, provided documents were stored as objects containing a place with the variable number of information fields as tokens in that place.
7 Object Petri Nets (OPNs) Object Petri Nets are derived from Object-Oriented Petri Nets by the inclusion of test and inhibitor arcs. Just as for CPNs [22], these arcs facilitate the definition of access functions, which can supply information about the state of an object without changing it. The provision of such functions can significantly improve the modularity of Petri Net designs [26]. The definitions below are merely an adaptation of similar CPN arc extensions [22]. Definition 7.4: An Object Petri Net page s, is a tuple (OOPN, As˚, A s', E s˚, Es') where: (a) OOPN is an object-oriented Petri Net page as in definition 6.2. (b) As˚ is a finite set of inhibitor arcs As˚ ⊆ Ps ˚ × Ts ˚ (c) As' is a finite set of test arcs As' ⊆ Ps˚ × Ts ˚ (d) Es˚ is an inhibitor arc expression function, Es˚: A s˚ → expr where ∀a ∈As˚: [Type(E s˚(a)) = σs(p(a)) ∧ Type(Var(E s˚(a))) ⊆ Σ s] and p(a) is the place of arc a. (e) Es' is an test arc expression function, Es': As' → expr where ∀a ∈As': [Type(E s'(a)) = σs(p(a)) ∧ Type(Var(E s'(a))) ⊆ Σs] and p(a) is the place of arc a. Definition 7.5: An Object Petri Net is a tuple like an OOPN of definition 6.3 but extended to include the components A˚, A', E˚, E' in the usual way. Definition 7.6: A step Y of an Object Petri Net OPN is enabled in a marking M if the following conditions hold in addition to those of definition 5.7: (d) ∀(t,b) ∈Y: ∀a ∈A˚: E˚(a) ≥ M(d) + put Y({d}, T˚)(d) where d = p(a) (e) ∀(t,b) ∈Y: ∀a ∈A': E'(a) ≤ M(d) – get Y({d}, T˚)(d) where d = p(a) Note: (d) The inhibitor arc must be an upper bound for the place marking plus the output arc effects. (e) The test arc must be a lower bound for the place marking minus the input arc effects. This completes the derivation of OPNs from CPNs. The style of the definition adopted in this paper differs from the earlier presentation [24] in order to emphasise the continuity with CPNs. However, the essence of the two presentations is the same, and the proof that OPNs are behaviourally equivalent to CPNs will carry over with only minor changes. The only other significant difference between the definitions of OPNs above and those of [24] concerns the definition of transitions. In the earlier presentation, transitions were defined by classes having arcs as components. The effects of the component arcs are synchronised, thus giving the normal transition semantics. This has the interesting consequence that one such transition class may inherit from other transition classes, thereby synchronising all their component arcs. This approach to transition definition served to remove the irregularity where super transitions are data fields, but simple transitions aren't. The current presentation chose to maintain continuity with the CPN definitions, given that there were few semantic consequences to the earlier approach.
8 Other Styles of Object-Oriented Petri Nets Having covered a range of Petri Net formalisms, we are now in a position to compare them with some other approaches to object-oriented Petri Nets described in the literature. Though not object-oriented, Valk proposed a Petri Net model – the Task Flow EN systems – with two levels of activity [35]. These were used for tasks and functional units, with synchronisation constrained by a static labelling of transitions. This scheme was limited to two levels of activity, and it did not include coloured tokens which would normally be an essential part of an object-oriented system. An early proposal to integrate object-oriented ideas with Petri Nets was that of PROT nets [3], though the number of constraints and the absence of inheritance lead us to classify it as an object-based approach with little possibility of generating reusable components. Nets could be decomposed into subnets interfacing via places, as in HCPNs [18]. Token types and transition actions were defined in
a general-purpose programming language. Places were constrained to be FIFO queues, and transitions had a strict token-passing regime (limiting each transition to have at most one input and output place of the same type, except for the nul type). One group of approaches has enhanced token types to include objects. This is a further advance in expressive comfort [37] over the coloured tokens of CPNs and the colourless tokens of PT-nets. Thus, Vautherin used algebraic specifications to define the possible token types [36], with the result that the one net specification could be used for a range of specific models. Van Hee and Verkoulen [15, 37] proposed a two-level data model (the SimCon Object Model) more appropriate for (information) systems modelling, given that Petri Net formalisms do not support a real data-oriented view of systems, such as is provided by modern object-oriented data models. This data model includes simplexes or simple objects (with object identity, attributes, and relationships with other objects), and complexes or container objects (with object identity, location, time stamp, and a structured sets of simplexes accessed via a reference structure). The SimCon Net Model is a Petri Net formalism where places hold complexes and where transitions transfer, modify, delete and generate complexes, as specified in an object algebra (the SimCon Algebra). There are many attractive features to this system including a greater facility in information modelling, the ability to specify class-dependent methods and cardinality constraints, and the ability to verify some constraints automatically. However, contrary to standard object-oriented approaches, data and functions are not encapsulated together, and the life cycle of a complex is external to the complex. Researchers at the University of Aarhus, who have been intimately involved with the development of the CP-net formalism and the associated Design/CPN tool [18, 19], have also been experimenting with the integration of the object-oriented language BETA [21] into Design/CPN [12]. BETA is used to declare token types and to annotate the transitions with code segments. However, there are other contexts where BETA cannot be used and there is no current intention of departing from the traditional approach where the Petri Net is a global control structure. A precursor to the current work on Object Petri Nets was the textual language for object-oriented Petri Nets called LOOPN. LOOPN supported two class hierarchies – one for tokens and one for subnets or modules. Inheritance, overriding and polymorphism for token types led to some interesting results in the modelling of layered network protocols, with one protocol layer being able to transfer any kind of message token [25]. Inheritance, overriding and polymorphism of subnet or module types allowed the derivation of more complex modules from simpler ones, thereby encouraging software reuse [26]. An unusual feature (in the context of petri net work) was the provision of module access functions, which allowed access to the state of a subnet without modifying it. This proved to be extremely beneficial in the development of clean module interfaces [26]. Despite the extended range of token types provided by the above proposals, tokens are still passive data items. There is no sense in which the net consists of a collection of dynamically created objects, each encapsulating its own data and control structures, together with the ability to generate new instances of such objects. Yet this is precisely the form of structuring which is standard in object-oriented programming languages, is required for the direct modelling of systems with multiple levels of activity, and its absence from the compositional constructs for Petri Nets compromises the even-handed treatment of state and state-change within the Petri Net formalism [34]. Engelfriet et. al. considered the modelling of object-oriented systems as Petri Nets called POTs and POPs [13]. Objects are modelled by their identity, mode and memory. The lifecycle of an object is modelled by a finite state machine, with creation and destruction modelled by changing the mode – from unborn to alive, and from alive to dead. Object methods are modelled by the synchronous interaction between objects through transition fusion. The memory of an object can hold simple data values or references to other objects, which may be exchanged at transition firing. The references to an object are independent of the referenced object, and thus dangling references may eventuate. The modelling of inheritance was not considered. Another group of approaches has focussed on the enhancement of algebraic data types with concurrency and synchronisation derived from Petri Nets. Thus, OBJSA nets integrate the data model of OBJ with the synchronisation of Superposed Automata nets [5]. In this model, the lifecycle of each object is
represented by a state machine as in the POTs and POPs approach above. Distinct objects can operate concurrently, and are synchronised by transition fusion. OBJSA nets do not include the notion of inheritance, but this issue is addressed in the derivative language CLOWN [4] where inheritance is supported by adding attributes, by redefinition of methods, and by requiring an ST-preorder relationship between the corresponding state machine nets. This requirement is a very promising area of further work since it imposes some form of behavioural similarity between a class and its subclass based on the states of each. However, the user must define a new state automata net for each new class, which can then be automatically checked with regard to the ST-preorder property. CLOWN objects can refer to other objects and can therefore model multi-level objects, but dangling references are possible as in POTs and POPs. Buchs and Guelfi propose a formalism called CO-OPN which is similar to the approach above, but extends the use of algebraic data types to include the communication structures [7, 8]. Again, objects are defined by algebraic data types with the methods being associated with transitions. The net structure of an object is no longer restricted to a state machine but may have multiple internal transitions firing concurrently. The firing of internal transitions depends only on the internal state of the object, while the firing of external transitions requires synchronisation with the transitions of other objects. Synchronisation may be simultaneous or sequential. Objects can be parameterised, thus supporting generic object definitions. Refinement is supported, but this appears to be the instantiation of generic definitions rather than the use inheritance as in object-oriented languages. The separation of the CO-OPN net structure into local and interaction components reflects the modular net structure of §4, rather than a hierarchical structure with multiple levels of activity. Sibertin-Blanc and others have considered the use of coloured Petri Nets to build complex systems out of components based on the client-server paradigm [31]. Here, a request for a service is made by a client passing an appropriate token to a server and waiting for a response before continuing. In order to guarantee suitable behaviour, a server will not accept a request unless it can guarantee to fulfil it, and a client will not make a request unless it is prepared to wait for the response. This has been extended into a Petri Net formalism called Cooperative Nets [32], where each object has an object identity or name, and may store the names of other objects. Each object has a number of interface places where requests for services (from clients) are submitted as tokens. When a transition fires, it may generate such a request token for another object, by suitably identifying the object and its interface place. This is akin to the place fusion with dynamically chosen places in the OBPN model of §5. The interaction is always asynchronous. In summary, the above proposals have approached the inclusion of object-oriented concepts into the definition of Petri Nets in a variety of ways. Some have only addressed the definition of token types, in which case they have not addressed the encapsulation of data and functions, but have retained the traditional Petri Net style with the tokens as passive data items and their life cycles specified by the global control structure of the net. All of them have chosen to include either synchronous or asynchronous interaction between subnets but not both. We believe that it is appropriate to support both for the convenience of the modeller, even if both are mapped to the same underlying implementation. Similarly, none of the above approaches has attempted to include multiple levels of activity directly in their formalism. Systems with multiple levels of activity can be modelled indirectly, but again we argue that it is preferable to include this in the formalism and hide the standard folding techniques in the implementation. This will have the important benefit that discarding an instance of a page will simultaneously discard all its components, which will be important for invariant analysis of such nets.
9 Conclusions and Further Work In this paper, we have shown how the definition of Object Petri Nets can be derived from that of Coloured Petri Nets. Object Petri Nets support the encapsulation, inheritance, polymorphism and dynamic binding which are common in object-oriented languages. Both super places and super transitions can be defined, thereby making it is possible to model directly both synchronous and asynchronous interaction between objects. The flexibility of place fusion allows the partners of a communication to be dynamically chosen, rather than being determined statically by the net structure. This means that Object Petri Nets can
support the dynamic interaction topologies proposed for Actor systems [2]. OPNs directly support the modelling of complex systems with multiple levels of activity. As well as being desirable for the modeller, this will be important for synchronising the actions of an object and its components, whether creation, deletion or migration. This is particularly significant in the development of appropriate place invariants. The above properties should allow OPNs to reap the practical benefits of object-orientation including clean interfaces, reusable software components, and extensible component libraries [28]. While increasing the expressive comfort of Petri Nets, OPNs still retain the important property of being transformable into behaviourally equivalent CPNs [24], thus providing a basis for adapting CPN analysis techniques for use with OPNs. The work on object Petri Nets is an ongoing project. There is much to be done before approaching Jensen's stated ideal of a three-fold combination of formalism, practical tool, and experience with realistic applications [18]. A textual language based on OPNs has been proposed [23] and is in the process of being implemented. A graphical editor for an earlier style of object-oriented Petri Nets is being developed and will be modified to accommodate OPNs. There is obviously great scope for further work in tailoring analysis techniques to OPNs.
Acknowledgements The author is pleased to acknowledge the detailed and helpful discussions held with Alfredo Chizzoni, Søren Christensen, Fiorelli de Cindio, Anke Heinemeier, Kurt Jensen, Chris Keen, Daniel Moldt, Kjeld Mortensen, Paul Rambags, Rüdiger Valk, Kees van Hee, and the Networking Research Group of the University of Tasmania.
References [1]
[2] [3]
[4] [5]
[6]
[7] [8]
[9] [10]
[11] [12] [13]
[14]
G. Agha, S. Frølund, W.Y. Kim, R. Panwar, A. Patterson, and D. Sturman Abstraction and Modularity Mechanisms for Concurrent Computing Research Directions in Concurrent Object-Oriented Programming, G. Agha, P. Wegner, and A. Yonezawa (eds.), pp 3-21, MIT Press (1993). G.A. Agha Actors: A Model of Concurrent Computation in Distributed Systems The MIT Press series in artificial intelligence, MIT Press (1986). M. Baldassari and G. Bruno An Environment for Object-Oriented Conceptual Programming Based on PROT Nets Advances in Petri Nets 1988, G. Rozenberg (ed.), Lecture Notes in Computer Science 340, pp 1–19, Springer Verlag (1988). E. Battiston and F. de Cindio Class Orientation and Inheritance in Modular Algebraic Nets Proceedings of IEEE International Conference on Systems, Man and Cybernetics2, pp 717-723, Le Touquet, France, IEEE (1993). E. Battiston, F. de Cindio, and G. Mauri OBJSA Nets: A Class of High-level Nets having Objects as Domains Advances in Petri Nets 1988, G. Rozenberg (ed.), Lecture Notes in Computer Science 340, pp 20–43, Springer-Verlag (1988). M. Bever, K. Geihs, L. Heuser, M. Mühlhäuser, and A. Schill Distributed Systems, OSF DCE, and Beyond Proceedings of International DCE Workshop: DCE - the OSF distributed computing environment : Client/Server Model and Beyond, Lecture notes in computer science 731, Karlsruhe, Germany, Springer-Verlag (1993). D. Buchs and N. Guelfi CO-OPN: A Concurrent Object Oriented Petri Net Approach Proceedings of 12th International Conference on the Application and Theory of Petri Nets, Gjern, Denmark (1991). D. Buchs and N. Guelfi Open Distributed Programming Using the Object Oriented Specification Formalism CO-OPN Proceedings of 5th International Conference on Putting into Practice Methods and Tools for Information System Design, Nantes (1992). L. Cherkasova, V. Kotov, and T. Rokicki On Net Modelling of Industrial Size Concurrent Systems Proceedings of 15th International Conference on the Application and Theory of Petri Nets – Case Studies, Zaragoza (1994). S. Christensen and N.D. Hansen Coloured Petri Nets Extended with Channels for Synchronous Communication Proceedings of 15th International Conference on the Application and Theory of Petri Nets, Lecture Notes in Computer Science 815, pp 159-178, Zaragoza, Springer-Verlag (1994). S. Christensen and L. Petrucci Towards a Modular Analysis of Coloured Petri Nets Application and Theory of Petri Nets, K. Jensen (ed.), Lecture Notes in Computer Science 616, pp 113-133, Springer-Verlag (1992). S. Christensen and J. Toksvig DesignBeta V2.0.1 – BETA Code Segments in CP-nets Lecture Notes OO&CPN - nr 5, Computer Science Department, Aarhus University (1993). J. Engelfriet, G. Leih, and G. Rozenberg Net-Based Description of Parallel Object-Based Systems, or POTs and POPs Proceedings of 1990 REX Workshop on Foundations of Object-Oriented Languages, Lecture Notes in Computer Science 489, pp 229–273, Noordwijkerhout, Netherlands, Springer-Verlag (1991). P.A. Fishwick Computer Simulation: Growth Through Extension Proceedings of Modelling and Simulation (European Simulation Multiconference), pp 3-20, Barcelona, Society for Computer Simulation (1994).
[15] K.M.v. Hee and P.A.C. Verkoulen Integration of a Data Model and High-Level Petri Nets Proceedings of 12th International Conference on the Application and Theory of Petri Nets, Lecture Notes in Computer Science , Gjern, Denmark, Springer (1991). [16] P. Huber, K. Jensen, and R.M. Shapiro Hierarchies of Coloured Petri Nets Proceedings of 10th International Conference on Application and Theory of Petri Nets, Lecture Notes in Computer Science 483, pp 313-341, SpringerVerlag (1990). [17] K. Jensen Coloured Petri Nets: A High Level Language for System Design and Analysis Advances in Petri Nets 1990, G. Rozenberg (ed.), Lecture Notes in Computer Science 483, Springer-Verlag (1990). [18] K. Jensen Coloured Petri Nets: Basic Concepts, Analysis Methods and Practical Use – Volume 1: Basic Concepts EATCS Monographs in Computer Science, Vol. 26, Springer-Verlag (1992). [19] K. Jensen, S. Christensen, P. Huber, and M. Holla Design/CPN™: A Reference Manual MetaSoftware Corporation (1992). [20] K. Jensen and N. Wirth Pascal User Manual and Report Second edn., Springer-Verlag (1975). [21] B.B. Kristensen, O.L. Madsen, B. Møller-Pedersen, and K. Nygaard Object Oriented Programming in the BETA Programming Language (1991). [22] C. Lakos and S. Christensen A General Systematic Approach to Arc Extensions for Coloured Petri Nets Proceedings of 15th International Conference on the Application and Theory of Petri Nets, Lecture Notes in Computer Science 815, pp 338-357, Zaragoza, Springer-Verlag (1994). [23] C. Lakos and C. Keen LOOPN++: A New Language for Object-Oriented Petri Nets Proceedings of Modelling and Simulation (European Simulation Multiconference), pp 369-374, Barcelona, Society for Computer Simulation (1994). [24] C.A. Lakos Object Petri Nets – Definition and Relationship to Coloured Nets Technical Report TR94-3, Computer Science Department, University of Tasmania (1994). [25] C.A. Lakos and C.D. Keen Modelling Layered Protocols in LOOPN Proceedings of Fourth International Workshop on Petri Nets and Performance Models, Melbourne, Australia (1991). [26] C.A. Lakos and C.D. Keen Modelling a Door Controller Protocol in LOOPN Proceedings of 10th European Conference on the Technology of Object-oriented Languages and Systems, Versailles, Prentice-Hall (1993). [27] A. Martin and B. Santanach Introducing Object-Oriented Concepts into the Framework of Coloured Petri Nets Thesis , Institut D'Informatique D'Entreprise, Evry (1993). [28] B. Meyer Object-Oriented Software Construction Prentice Hall (1988). [29] SAA Programming Language FORTRAN Australian Standard, Vol. AS1486-1973, Standards Association of Australia (1973). [30] S. Shlaer and S.J. Mellor Object Lifecycles – Modeling the World in States Yourdon Press, Prentice Hall (1992). [31] C. Sibertin-Blanc A Client-Server Protocol for the Composition of Petri Nets Proceedings of 14th International Conference on the Application and Theory of Petri Nets, Lecture Notes in Computer Science 691, pp 377-396, Chicago, Springer-Verlag (1993). [32] C. Sibertin-Blanc Cooperative Nets Proceedings of 15th International Conference on the Application and Theory of Petri Nets, Lecture Notes in Computer Science 815, pp 471-490, Zaragoza, Spain, Springer-Verlag (1994). [33] P.A. Swatman, P.M.C. Swatman, and R. Duke Electronic Data Interchange: A High-level Formal Specification in Object-Z Proceedings of 6th Australian Software Engineering Conference, pp 341-354, Sydney, Australia, SpringerVerlag (1991). [34] P.S. Thiagarajan Elementary Net Systems Advances in Petri Nets 1986, Part I, W. Brauer, W. Reisig, and G. Rozenberg (eds.), Lecture Notes in Computer Science 254, pp 26–59, Springer-Verlag (1987). [35] R. Valk Modelling Concurrency by Task/Flow EN Systems 3rd Workshop on Concurrency and Compositionality, 1991, E. Best, et al. (ed.), GMD-Studien 191, pp 207–215 (1991). [36] J. Vautherin Parallel Systems Specifications with Coloured Petri Nets and Algebraic Specifications Advances in Petri Nets 1987, G. Rozenberg (ed.), Lecture Notes in Computer Science 266, pp 293–308, Springer Verlag (1987). [37] P.A.C. Verkoulen Integrated Information Systems Design: An Approach Based on Object-Oriented Concepts and Petri Nets PhD Thesis, Technical University of Eindhoven, the Netherlands (1993). [38] P. Wegner Dimensions of Object-Based Language Design Proceedings of OOPSLA 87, pp 168-182, Orlando, Florida, ACM (1987). [39] P. Wegner Inheritance as an Incremental Modification Mechanism, or What Like Is and Isn't Like Proceedings of ECOOP '88 - European Conference on Object Oriented Programming, Lecture Notes in Computer Science 322, pp 55-77, Oslo, Norway, Springer Verlag (1988).
