PN-TOX: a Paradigm and Development Environment for Object ...

PN-TOX: a Paradigm and Development Environment for Object Concurrency Speci cations Tom Holvoet and Pierre Verbaeten Dept. of Computer Science, K.U.Leuven, Belgium e-mail: [email protected]

Abstract In the domain of concurrent object-oriented programming (COOP) there is a strong need for a formalism to describe concurrency. Such a formalism is oered by Petri nets, which however lack thorough modularisation techniques for coping with models for large systems. An appropriate combination of COOP and Petri nets is required in order to pro t from the strength of both methods. This paper gives an overview of ongoing research on PN-TOX, a paradigm and development environment for concurrent object-oriented programming based on Petri nets. First, we describe our object model. Each object has its own Petri net (encapsulated within the object) that models the concurrent behaviour of the object; these objects are called Petri net objects. Cooperation and synchronisation of Petri net objects can be modelled by separate objects describing their cooperation scenarios. Our ideas concerning (single and multiple) inheritance, as part of the integration of Petri nets within the object-oriented paradigm, are presented. A set of formal net transformations serve as guidelines for behaviour-oriented inheritance of classes of Petri net objects. The PN-TOX environment is also (shortly) described. It supports the design, simulation, rapid prototyping and implementation of Petri net objects.

1 Introduction Agent-oriented programming stands for concurrent object-oriented programming where an application is modelled as a set of concurrent, autonomous objects, called agents. In such an environment, two kinds of concurrency aspects are involved:  Research Assistant of the Belgian Fund for Scienti c Research



concurrent behaviour of individual objects : during

their life-time objects may autonomously execute multiple actions concurrently;  multiple concurrent object invocations : in an environment with multiple active objects, multiple operations may be invoked on one object at the same time. It is clear that complex situations may occur due to the autonomicity of multiple entities. There is a need for describing this concurrent behaviour in order to manage an application. Using a formal technique for that matter oers several advantages: it enables formal reasoning about the system being modelled in terms of behaviour, properties, equivalence notions between system models, and so on. We have chosen Petri nets as the formalism for modelling concurrency. Petri nets are widely used for modelling complex concurrent systems. They have the advantage of being simple and powerful, they have a visual representation (an aspect that should not be underestimated; it makes understanding and reasoning upon a speci cation a lot easier) and they have a substantial theoretical baggage, since they have been the subject of intensive research for many years. One major drawback of Petri nets is the lack of thorough modularisation techniques for net models. This results in huge, unmanageable nets even for mediumsized systems. In this paper we present PN-TOX (Petri Net Tools for Object Concurrency Speci cation) [13], which offers a paradigm for integrating Petri nets within COOP, and a conform development environment. The goal of PN-TOX is to provide a full integration of Petri nets in COOP: we want to maintain consistent notions of object-orientation features, such as polymorphism and inheritance. In section 2 we overview the PN-TOX application development paradigm. First, we introduce the notion of Petri net objects, objects that are provided

with a net describing their internal concurrent behaviour and their behaviour under multiple concurrent use by other objects. Then we tackle the issue of modelling object cooperation. PN-TOX oers three mechanisms for describing cooperation schemes: object interaction, composition objects and coordination objects. And nally we explain how inheritance is guided in a formal way. Formal transformations on nets (re nements, abstractions, and so on) constitute the formal basics for inheritance of Petri net objects. However, we feel that no one rule for de ning inheritance relations between Petri net objects should be imposed on an application designer. Such a rule would either be too stringent, in that it would prohibit inheritance relations that are desirable in a particular object-oriented design, or it would be so weak, as to allow more inheritance relations, that it would be of marginal use as a theoretical instrument. Instead, we intend to catalogue interesting transformations as to support an application designer in using inheritance in a formally justi ed way. The PN-TOX environment, presented in section 3, oers support for net design of Petri net objects (by a graphical tool), simulation, activation and visualisation of Petri net objects. Section 4 overviews other systems and languages that aim at combining Petri nets and objects.

2 The PN-TOX Paradigm The global idea of developing a PN-TOX application is to use object-oriented techniques for modelling the application domain and identifying concurrently active, autonomous objects (agent-oriented programming). This model is then enhanced by concurrency descriptions: objects are provided with a net describing their concurrency behaviour (Petri net objects), and object cooperation can explicitly be modelled by separate objects (composition and coordination objects). The third item of this section is inheritance. It is an essential topic of the integration of Petri nets in COOP. Finally, we tackle the issue of reusing cooperation descriptions in the presence of inheritance. Before going into the PN-TOX features, we want to stress that we do not wish (as is pursued in other approaches) that our nal model of an application is one overall Petri net. We want to maintain objects as individual entities, that are provided with a description of their concurrent behaviour. This enhances modularity of application development, and it enables component-based software development [23]. Not attaining one overall net of an application also implies

that we do not consider performing general analysis on the application speci cation. However, we tend to analyse an application at the level of objects and object cooperation schemes, enabling the construction of formally speci ed, reusable components.

2.1 The Petri Net Object Model Petri Net Objects A rst step in describing concurrency is to provide objects with a net1 (called the object net). The object nets model the concurrent behaviour that is inherent to the objects, i.e. their \intra-object concurrent behaviour". Each object net is encapsulated within an object, which is then called a Petri net object (PNO for short). Each PNO has a \traditional" interface, providing a set of services to other objects (there is no fusion of object operations and transitions2 ). Since the object interface is separated from the object net, a mechanism is provided for interconnecting these two parts of the object description. This mechanism consists of an extension of the object net, mostly a set of places that are connected to transitions in the object net. The interface net extension (INE) is the only part of the net that can be manipulated by the interface operations. By inserting and extracting tokens appropriately, certain transitions in the object net can be enabled and results from activities may be obtained. The INE is not part of the intrinsic behaviour description of the object. Instead, the object net together with the INE represents the actual behaviour of the object in the presence of operation invocations. Let us clarify this through an example. Consider the class Person, representing persons who sequentially eat and work. The object net for Person objects should describe the behaviour of a person as an autonomous entity in the real world, without considering its interface. This results in a simple state net (see Figure 1). Now, assume that we want one interface operation for Person objects: Work. After having worked a person will autonomously eat before possibly working again. In order to model this view, the net is extended with an INE. The INE consists of one place that will be manipulated (token insertion) by the execution of the operation Work. Note that the marking of the 1 2

This net may consist of one or more separate nets. This is the case in e.g. POTs, OBJSA, CLOWN.

Implementation of PNOs

PERSON Interface

I.N.E.

Person object net

Work do_work

eat

inherent behaviour actual behaviour

Figure 1: Petri Net Object: Person resulting net represents the (initial) state of a newly created object. The encapsulation of the object net has several advantages. First, it is a kind of information hiding. The internal activities of PNOs are irrelevant for some views of the application, e.g. if one is only interested in the reactive behaviour of objects. Moreover, the internal concurrency behaviour may be altered without aecting other objects that use the object's service operations. Another advantage is what we call the multi-model principle. Several sorts of net models exist: from basic Condition/Event nets, over Place/Transition nets to high-level nets, such as Coloured Petri nets and Predicate/Transition nets. We argue that each of these models has its domain where it may be preferred over others (according to the grain size of envisaged parallelism, the level of abstraction, and so on). Since object nets are encapsulated within PNOs, objects from dierent classes may have object nets of dierent net models. This enables exibility in designing an application, which is a necessity for developing large and complex systems.

Multi-Layer Activity Another property of object nets is that tokens represent more than just a token conform to the net model (an anonymous token, a structured or coloured token, and so on). Each token may represent an object. That object is possibly active itself, resulting in what is called multi-layer activity. The reason for attaching objects to tokens is to have a exible mechanism for specifying the transition ring: the tokens that are withdrawn upon transition ring serve as parameters for the transition ring execution.

Starting from an object interface, an object net and an associated INE, the implementation of a PNO consists of: 1) annotating transitions with (a) code segments that will be executed when the transitions re, and (b) possibly with object-speci c ring preconditions; 2) the implementation of the interface operations, realising the link to the object net. As an example, the implementation of the Person class is given below. The interface operation Work is implemented such that a token is inserted in the (only) place of the INE. An invocation of this operation therefore enables a person to work. The transition do work is annotated with code for implementing a person's working activity. The transition eat is annotated with an object speci c predicate and with code for implementing a person's eating activity. Interface operation Work: Work () { INEplaceWorkStart->AddToken(new Token()) } Transition do_work: WorkCodeAnnotation () { ... // performing actions for working } Transition eat: boolean EatObjectSpecificPredicate () { return (time_since_last_meal > 1 hour) } EatCodeAnnotation () { ... // performing actions for eating }

The object concurrency description (the object net) and the object implementation code (the transition annotations) are separated, which appears to be a conditio sine qua non for bypassing the inheritance anomalies ([18]). Moreover, it is quite easy to realise the samples of inheritance mentioned in that paper, without suering from inheritance anomalies [14].

2.2 Object Cooperation Thus far, we have presented the idea behind PNTOX for modelling individual objects. Next issue is: how do we model object cooperation? Before we elaborate on the mechanisms provided in PN-TOX, we will give an overview of dierent cases

of object cooperation: what situations of object cooperation can occur? We distinguish four object cooperation schemes (which are not necessarily disjoint):  object interaction : objects may use services that are oered by other objects; they perform actions on each other (they inter-act);  information exchange : objects may need to exchange information;  object synchronisation : an object may need to synchronise with other objects before initiating a particular activity;  object coordination : several objects may work together for some common goal by synchronising, interacting and exchanging information. PN-TOX oers three mechanisms for describing object cooperation schemes: operation invocations, composition objects and coordination objects.

Operation Invocation

A rst mechanism for object communication is operation invocation. Objects communicate as in a client/server situation using message passing: client objects use services of other objects by invoking their interface operations. This cooperation mechanism can be used for describing and implementing object cooperation, information exchange (through operation parameters and operation return values) and object synchronisation (through the interconnection of operations with the object net). As an example, consider a simple producer/consumer situation. A producer sequentially produces an item and delivers it to a consumer. A consumer accepts items and consumes them. The objects and their nets are graphically represented in Figure 2. The cooperation between a producer and a consumer is realised by annotating the transition send with an invocation of the consumer operation ConsIt. It is a way for realising synchronisation and information exchange.

Composition Objects

A set of techniques that have been proposed for constructing large nets consist of composing nets. Depending on the composition operator (such as place and/or transition merging [4], medium composition [20]), mechanisms are oered for modelling synchronous and asynchronous communication between

Producer Interface

Consumer INE

object net

Interface

INE

object net

ConsIt produce

send

get-item

consume

invoke ConsIt

Figure 2: Producer and consumer: client/server situation entities. The same principle can be applied for modelling object cooperation. We use a separate object, called composition object, for describing object cooperation through the composition of their object nets. It allows modelling multiple cooperation schemes for a set of cooperating objects by providing multiple composition objects. A composition object is not a Petri net object. Its responsibility is merely the description of the cooperation of objects by the composition of their object nets. Composition objects can be used for describing object synchronisation and information exchange. An instantiation of a composition object implies the realisation of the causality between the cooperating objects. If a programmer wants to pro t from the available results of composing nets, (s)he should ensure that the appropriate prerequisites are ful lled, since PN-TOX does not impose any particular net model. For example, if the object nets of the cooperating objects are 1-safe net systems, one can compose the object nets by superposing transitions, resulting in a Superposed Automata (SA-)net. Results on properties of SA-nets could then be applied to the composition objects. In the example shown in Figure 3, a simple transition fusion models synchronous communication between a producer and a consumer. The producer does not invoke an operation of the consumer, they communicate and synchronise through the shared transition. Figure 4 shows another composition object where a buer object is used between a producer and a consumer. It illustrates the advantage of using separate objects for modelling object cooperation: multiple cooperation schemes and mechanisms can be used for describing cooperating objects. It should be stressed, however, that having objects communicate through their object nets in stead of through message passing does not t the objectoriented paradigm of message passing. Communication is modelled and realised by sharing places and/or transitions in the object nets. Moreover, since object

nets are combined with other object nets, the object nets are no longer encapsulated within an object, and we have to tamper the advantages of the multi-model principle, since composing nets relies on the sort of the composite nets. If a programmer does not want to suer from these restrictions, another mechanism (coordination objects) can be used.

Composition Object Producer

Consumer

object net

produce

Coordination Objects

object net

send

get-item

consume

transition superposition

Figure 3: Producer and consumer cooperation: a composition object by transition superposition (only object nets)

Composition Object Producer

object net

object net put

produce

Consumer

Buffer

object net

send

get get-item

consume

transition superposition

Figure 4: Producer and consumer cooperation through a buer: a composition object by transition superposition (only object nets)

In situations where complex cooperation scenarios can occur, the previous mechanisms for modelling cooperation do not suce. Using client/server-like cooperation does not provide a method for modelling cooperation scenarios; composition objects are only advisable for small-scale, simple cooperation schemes. What we want is a method that enables higher-level description of cooperation. To that end, we present coordination objects. A coordination object is a Petri net object that models a cooperation scenario by its object net. This object net is independent of the object nets of the cooperating objects and can therefore be of any sort of net model. The advantages of this independence are that (1) the object net of the coordination object can be of any kind of net model (multi-model principle), and (2) the internal behaviour of the cooperating objects and the description of the cooperation may change without consequences for the other objects (encapsulation). A coordinator object is an object which responsibility is to coordinate object activities (interaction and synchronisation) and to manage complex information exchange. Let us present an illustration. Consider the problem of the dining philosophers. Designing an application that simulates this scene could result in identifying the class DiningPhilosopher. Using PN-TOX for realising the application in a concurrent environment, the coordination of the scene can be modelled by an object of an additional class, DinPhiSetting. The DiningPhilosopher class represents philosophers who sequentially think and eat, where eating has been modelled as to allow as much concurrency as possible (e.g. a philosopher can keep on chewing (i.e. ring the transition chew ) even when he has already started thinking again). The DiningPhilosopher object net is a simple C/E net (Figure 5). An object of the DinPhiSetting class is a coordination object that describes the scene of the philosophers at a table with a number of forks. The object net of a DinPhiSetting object (see Figure 5) is a Predi-

DINPHISETTING DinPhiSetting object net 0,1,2,...

tokens=DiningPhilosopher objects

0,1,2,...

{x,y}

{x}

y=(x+1)mod n

eat

{x} {x,y}

DININGPHILOSOPHER Interface

{x}

INE

DiningPhilosopher object net mouth-empty

StartToEat

pick-left-fork start-eating

{x} done_eating

y=(x+1)mod n

prepare

grab-food

put-in-mouth

Work

swallow pick-right-fork

think finish-eating

continue chew

enough put-down-left-fork forks-empty put-down-right-fork

Figure 5: Petri net objects: Person, DiningPhilosopher and DinPhiSetting cate/Transition net since it has been pointed out that this kind of net model is preferred over more basic net models for reasons of scalability of the number of philosophers at the scene. The philosophers that are to be coordinated are represented by tokens in the DinPhiSetting object net. The synchronisation between the coordination object and the philosopher objects can be realised by object invocations. The transition eat of the DinPhiSetting object net is to be annotated with the operation invocation StartToEat on the DiningPhilosopher object represented by x.

2.3 Inheritance of PNO Classes A third aspect of the PN-TOX paradigm concerns

inheritance. It is an essential part of the integration

of Petri nets within object-orientation. Other objectoriented features (polymorphism, dynamic binding) are easily adopted in the Petri net object model. We feel that the inheritance relations among classes should be conducted by a formalism for inheriting object nets, in order to bene t from the available results in theoretical research of Petri nets. However, we do not intend to impose one rule for de ning inheritance relations between Petri net objects. formal way. First, we will present formal net transformation techniques that are used as a basics for describing inheritance relations. Then we will show how the transformations can be used as formal guidelines for inheritance of Petri net objects.

2.3.1 Net Transformation Techniques Besides of composing nets, other techniques have been proposed for constructing manageable nets, such as net transformation techniques. These techniques offer a method for developing nets at dierent levels of detail. One can distinguish two categories of transformation techniques:

Local Transformations: these transformations em-

phasise on transforming isolated net elements (places, transitions), by replacing an element by a subnet. An example of a local transformation is a \behaviourpreserving re nement3 of a transition by a well-formed block in a P/T-net": a transition is replaced by a re nement net that is accordingly interconnected with the original net. This results in a more detailed, i.e. re ned net. Properties of the original net (such as liveness, safeness) and of the re nement net (e.g. being a well-formed block [6]) induce properties of the re ned net. Local transformations are a net design technique comparable to the ideas of structured programming (stepwise re nement, top-down development). They allow the introduction of new behaviour in terms of the three essential properties of Petri nets, concurrency, choice and causality.

Global Transformations: these transformations do not focus on particular transitions or places, instead

3 For an overview of behaviour-preserving net re nements, the reader is referred to [6].

they imply transforming the entire net. Examples are: abstractions [9] and vicinity respecting net morphisms [8]. These are both behaviour-oriented net morphisms, meaning that the respective morphisms aim to preserve structural properties. Actually, any net transformation can be considered a conjunction of a transformation of the net \Gestalt" (i.e. the underlying graph) and an appropriate transformation of net mappings (such as the marking and the labelling functions of transition and arrows). For local transformations, it is easy to identify both transformations. As for the mentioned global re nements, which oer a Gestalt transformation only, one can deduce intuitive net mapping transformations that are easily proven applicable in a context of behaviourpreserving global transformations. However, in order to provide a thorough formal basics for general net transformations, further research is required for behaviour-oriented transformations of net mappings. This generalised notion of net transformation will be the basics of the inheritance guidelines in PN-TOX.

2.3.2 Single Inheritance

Here, we clarify when and to what extend we can exploit the results of research in formal transformation techniques in a context of inheritance of PNOs. In [24], P. Wegner presents inheritance as a set of incremental modi cation mechanisms associated with three speci cation techniques:  behaviour  signatures  implementation Each of these inheritance relationships will now be tackled in the context of PNOs. Behavioural inheritance is a subtyping mechanism where the subtype speci cation may be constraint as to be behaviourally compatible with the parent type. In our situation, behaviour is speci ed by the object net. This implies that behavioural compatibility will be translated into Petri net compatibility. De ning net compatibility is an important topic, since our de nition of behavioural inheritance depends on it. Petri net compatibility intuitively refers to a strong relationship between nets. There are two categories for de ning net relationships. A rst category concerns equivalence relations on nets. A lot of equivalence notions have been proposed for several net

PERSON Interface

INE

Person object net

Work do_work

(behavioural inheritance)

eat

(refinement)

PHILOSOPHER Interface

INE

Philosopher object net mouth-empty pick-left-fork prepare

start-eating

grab-food

put-in-mouth

Work swallow pick-right-fork

think finish-eating

continue chew

enough put-down-left-fork forks-empty put-down-right-fork

Figure 6: Behavioural inheritance by net re nement models4, each proving their contribution in depicting relations between nets. They are based on de nitions of behaviour of nets in terms of ring sequences, traces, processes, occurrence nets, and so on (see e.g. [21] [22]). Generally, equivalence notions de ne stringent relations. Moreover, the huge variety of de nitions and the lack of one uni ed equivalence notion that covers the diversity of behavioural inheritance relations, make these rather unpopular as a exible formal basics. Another category of net relations is formal transformations, as discussed earlier in this section. We adopt transformation as the basics for our approach of Petri net compatibility. They oer a exible and powerful mechanism not only for describing net relation, but also for constructing nets. Let us illustrate this through an example. We illustrate the behavioural inheritance mechanism to de ne Philosophers (see Figure 6), a subtype of Persons, as previously presented. The transformation of the behaviour speci cation of the Person objects that is used to obtain the behaviour speci cation of Philosophers is the \behaviour-preserving transition re nement by a 1-well-behaved block" of the transition eat of the object net of persons. Using the results summarised in [6], we can conclude that the re ned net { i.e. the object net of the philosopher class { is bounded, safe and life. Incremental modi cation of signatures is a subclassing technique for interface extension of the 4

For a survey, the reader is referred to [19].

parent class, where demanding behavioural compatibility is in general not signi cant. However, if it is possible to apply a formal transformation on the parent class object net for capturing the extension yields the possibility of bene ting from the transformation properties (allowing the deduction of properties of the resulting net). Implementation modi cation is an inheritance mechanism for allowing the rede nition of the class implementation. Generally, the derived class is behaviourally and signature compatible to the parent class. One possible application of implementation modi cation for PNOs is to alter the annotated code of a transition. Another application is to replace (re ne) a place/transition by a re nement net, again exploiting the bene ts of (local) transformation techniques. This could be used for enhancing concurrency by the implementation. In most cases, it is possible to associate a formal transformation with the inheritance relation. The PNTOX paradigm does not impose any formal relationship between inheritance related objects, it merely encourages it. The main reason for this is that we want to prevent hampering the application designer by imposing strict restrictions on object relations. PN-TOX presents a set of guidelines for programmers that offer constructing techniques and enable them to bene t from available results on formal aspects of Petri nets.

2.3.3 Multiple Inheritance Besides of single inheritance, there is another technique for developing related classes: multiple inheritance. The need for multiple inheritance is still a topic of great debate. We consent to the phrase of G. Booch in [5]: \we nd multiple inheritance to be like a parachute: you don't always need it, but when you do, you are really happy to have it on hand". To our opinion, one can distinguish two situations in which the technique of multiple inheritance may be applied: 



conjunction of variations of multiple related ob-

jects: typically encountered in a diamond like inheritance hierarchy, this technique can be seen as the conjunction of earlier inheritance relations, in particular as the composition of earlier incremental modi cations. uni cation of objects: multiple inheritance can be

used to describe polyvalent entities, i.e. entities that incorporate multiple identities.

Buffer

Mutex Interface

INE

Interface

Mutex object net getlock

Lock

Unlock

INE

Buffer object net in

Put

out

Get

releaselock

LockableBUFFER Interface Lock

INE

LockableBuffer object net getlock in

Unlock releaselock

out

Put Get

Figure 8: Multiple inheritance (object uni cation) through the composition of object nets An example of a conjunction of variations is represented in Figure 7. Let the class Philosopher be a behavioural modi cation of the class Person, represented by a transition re nement. Let the class Slave be a signature modi cation of the class Person, introducing the interface operation Eat. The class DiningPhilosopher represents, by multiple inheritance, philosophers that do not autonomously start thinking after having eaten. Its behaviour is de ned as the composition of the incremental modi cations for attaining the Slave and Philosopher classes. Additionally, the object net might also have been re ned (e.g. by re ning the transition Work). In the case of multiple inheritance for the uni cation of objects, the speci cation of the object's uni ed behaviour (in PN-TOX) can be either the disjoint conjunction of the object nets of the parent classes, or the behaviour may be accomplished be applying a composition operation on the object nets of the parent classes. An example: a class Mutex, with operations Lock and Unlock, and a class Buer, with operations Put and Get. Multiple inheritance can be applied to model the class LockableBuer. The behaviour of instances of this class is speci ed by its object net, which is the result of the composition of the object nets of the Mutex and Buer class.

2.4 Interrelation of Cooperation and Inheritance Thus far, we have presented the PN-TOX ideas concerning cooperation modelling and inheritance relationships as separate topics of the programming

PERSON Interface

INE

Person object net

Work do_work

SLAVE Interface

eat

PHILOSOPHER INE

Slave object net

Interface

Philosopher object net

INE

mouth-empty

Work

pick-left-fork prepare

start-eating work

eat

grab-food

put-in-mouth

Work

Eat

swallow pick-right-fork

think finish-eating

continue chew

enough put-down-left-fork forks-empty put-down-right-fork

DININGPHILOSOPHER Interface

DiningPhilosopher object net

INE

mouth-empty

Eat

pick-left-fork prepare

start-eating

grab-food

put-in-mouth

Work swallow pick-right-fork

think finish-eating

continue chew

enough put-down-left-fork forks-empty put-down-right-fork

Figure 7: Multiple inheritance (conjunction of variations) as the composition of multiple incremental modi cations paradigm. However, another important issue suggests itself: how can cooperation schemes be reused in the presence of inheritance relation of the cooperation participants? In a concrete example: if we specialise the Producer class to obtain a speci c producer and/or we specialise the Consumer class, can we reuse the previous cooperation schemes? A cooperation scenario that is described by operation invocations needs no adjustment. This introduces no problems since we can rely on the polymorphism of the underlying object-oriented language (C++). E.g. the code annotation of a transition of a NewProducer object net should include the (equivalent of) ConsIt operation invocation on the respective (New)Consumer. The same argument can be expressed when coordination objects are used for modelling the cooperation, when the coordination is based on operation invocation of the cooperating objects. This is the case in the Philosopher example. Objects that inherit from Philosopher objects, e.g. specialising the thinking part, can cooperate according to the same DinPhiSetting description. Reusing composition objects needs some additional

attention. As for now, we will only identify the problem by elaborating on one particular situation and presenting a solution. Consider a composition object that is the result of a simple composition operator which merges transitions of the object nets of the cooperating objects, e.g. the composition object describing the synchronisation between a Producer and a Consumer, presented in Figure 3. Let the class NewProducer inherit from the Producer class through a local transformation, a transition re nement, on the object net. It models the activity of a producer where sending a produced item is described in more detail (see left-hand side of Figure 9). When we want to describe the cooperation between a NewProducer object and a Consumer object, we can not reuse the previous composition object, since there is no longer a single transition send in the NewProducer object net. The solution that we shortly present here is Petri charts. Petri charts, introduced in [15], are a hierarchical net construction technique that is based on the ideas of statecharts ([12]). It is basically a net re nement technique where the re ned places and/or tran-

NewProducer NewProducer object net

NewProducer NewProducer object net send

produce produce

Figure 9: Behavioural inheritance: plain re nement (left) vs. Petri chart re nement (right) (only object nets) sitions are retained. This introduces depth in nets. Petri charts easily enable reasoning on a model at different levels of abstraction. An important property of Petri charts is that local transformations, de ned for transforming Petri nets, can be adopted in the Petri chart technique. This enables the reuse of the available research results on local transformations. For more details, the reader is referred to [15]. One deliverable of using Petri charts in PN-TOX is that it enables the reuse of the composition objects in the presence of inheritance relations. In our example, this means that the Petri chart of the NewProducer objects retain a (however re ned) transition send. The composition object in Figure 3 can thus be reused to describe the cooperation between NewProducer objects and Consumer objects. In Figure 9 (right-hand side), the Petri chart for NewProducer objects is depicted. It is equivalent to the re ned net on the left-hand side of Figure 9.

3 The PN-TOX Development Environment The PN-TOX environment aims to support the development of PN-TOX applications by oering a set of tools for designing Petri net objects, and to support the execution of PN-TOX applications by providing a number of abstractions, language extensions as to realise the instantiation and activation of autonomous Petri net objects. It is subdivided into two components: PN-VIS, a graphical tool, and PN-OS, Petri Net Object Support. PN-VIS oers graphical support for:  the development of object nets for PNOs and the annotation of transitions with code segments and object-speci c preconditions. For now, there is

support for C/E-nets, P/T-nets and a variation of Coloured Petri nets.  simulation : PNOs can be simulated (prototyped) by simulating their object net, i.e. visually representing the object net and its activities (transition ring, token shifting). It can be used for analysing the behaviour of object net in an experimental way.  visualisation : PNOs that are instantiated to constitute a PN-TOX application can be visualised by their object net. The PN-VIS tool also embodies a code generator, conform to PN-OS. PN-OS oers a set of generic templates for instantiation and activation of PNOs. The basic underlying abstraction is active objects, i.e. objects that constitute their own threads of control, enabling autonomous operations. The autonomous operations of the PNO templates are the transitions of the object net, which constitute the activity of a Petri net. Basically, this means that PNOs will perform the activities according to their object net: enabled transitions will autonomously re, resulting in the execution of the code the transition is annotated with, and tokens will consequently be shifted through the net. Object-orientation is unmistakably an important pillar for attaining a exible object support in PNOS. The basic abstraction is a generic class template for Petri net objects. All sorts of PNOs, related to the dierent sorts of net models are specialisations of the generic class. This base class models objects with a generic object net, consisting of places, transitions and arrows with associated annotations. The specialisations de ne dierent PNOs associated with dierent net models by restricting the genericity of the base class model. Each class follows basically the same execution scheme, which is de ned by the activities of the transitions. As mentioned, each transition constitutes an autonomous operation of a PNO. Each transition follows the execution scheme given below: if (ImplicitPrecondition()) { // the implicit precondition includes // the presence of tokens needed by // the transition, indicated in the // label of the arrow between the // input-places and the transition if (Predicate()) { // an additional precondition // may be defined; it may be in // function of the present tokens

// in the input places RemoveInputTokens(); FiringExecution(); // execute the code with which // the transition is annotated ShiftOutputTokens(); // add appropriate tokens to the // output places; the tokens may be // influenced by the FiringExecution } }

For each kind of PetriNetObject, i.e. for each specialisation, we rede ne the features that are speci c to the respective net model, e.g. the ImplicitPrecondition for C/E-nets is dierent (and can be realised more eciently) from the one for CPNs. Subscribing to this exible and extendible approach in developing PN-OS is a necessity if we want to support the multi-model principle and enable an easy extension of the environment to support new net models.

The PN-TOX Language One of the main topics of future work will be the de nition of a language that conforms to the presented PN-TOX paradigm. Besides of syntactical and semantic rules, the language will also support the description of inheritance relations and composition objects in terms of formal transformations and composition operators. This is necessary for eectively bene ting from the research results available on these topics. The language could use PN-VIS as a graphical language interface and use the abstractions oered by PN-OS to realise the PNOs and their interconnections.

4 Related Work Recently, several systems and languages have been proposed for combining object-orientation with Petri nets. They are mostly quite dierent from our approach. Here is a short overview. A rst category of closely related approaches identi es objects as tokens circulating in a subnet of one overall net. POT systems (Parallel Object-based Transition, [10]) have been introduced as a modelling technique for object-based systems. One POT is used to model an entire application. The state of objects is represented by a number of places in the POT. Objects are considered sequential entities. POPs ([11]) are a high-level description of POTs. They constitute a

programming language. The lack of an object model and a class concept prohibits the integration within object-orientation. OBJSA nets ([3]) are a development technique using SA (Superposed Automata) nets that are extended with algebraic speci cations using the OBJ language. They form a design language and an environment for building executable speci cations. The idea is that classes are identi ed in the application domain, and each class is represented by a SA net. Tokens in the SA net of a class represent objects of that class. The SA nets of dierent classes are merged for modelling object cooperation. The resulting SA net is a model for the entire application. CLOWN (CLass Orientation With Nets [2]) elaborates on the notion of classes in OBJSA nets. Each class consists of a set attributes, methods and a net, representing a state machine, where each transition corresponds to an interface operation. Object cooperation is speci ed by denoting the object partners and (staticly) interconnecting the respective class nets. Its main deliverable is its \net-based notion of single inheritance". The ST-preorder relationship for comparing net systems is used as a formal rule for behaviour preservation between parent and descendant classes. CO-OPN ([7]) is a formal speci cation language for specifying data structures and communication between algebraic data types. Since it is not based on state nets, intra-object concurrency is allowed. However, inheritance is not considered. An environment, SANDS (Structured Algebraic Net Development System), can be used for algebraic and net speci cation development and simulation (by prototyping the algebraic speci cation of the objects using a PROLOG code generating tool). Multi-layer activity is not considered in any of these systems/languages. They provide a static way to describe object cooperation, namely by (staticly) interconnecting the nets of the application components. A dierent approach is taken in LOOPN [16], a textual language for object-oriented Petri nets. LOOPN supports two class hierarchies, one for tokens and one for subnets. Inheritance, overriding and polymorphism is allowed on both hierarchies. But still, one net is the overall control structure of the application, and tokens are passive data items. LOOPN++ ([17]) is being developed as the successor of LOOPN. It is a new object-oriented programming language that oers a set of basic constructs (a.o.

actions and transitions) that can be used for the object development. Its main goal is a full integration, in that objects and Petri nets are no longer distinguished. E.g. objects where certain input and output functions are de ned can be used as places; a transition is just another object consisting of actions only, and so on. Finally, there is Cooperative Objects [1], a concurrent, Petri net based, object-oriented language. Of all languages and systems, Cooperative Objects are probably most closely related to our approach. The behaviour of a class of objects is speci ed by one Object Control Structure (OBCS), de ning the inner control structure of objects. The OBCS consists of a high-level Petri net. Each interface operation is associated with a transition. Cooperation (which is identi ed with what we called \object interaction" in this paper) is speci ed by merging each transition that represents an operation invocation on another object with a transition, an interface operation, of the invokee. Behavioural inheritance is restrained by demanding language compatibility between the parent and inheritance class OBCS.

5 Conclusion This paper gives an overview of basic principles of the PN-TOX paradigm and a conform application development environment. The primary goal of the paradigm is to provide a formal concurrency speci cation mechanism and execution control structure for component-based development of object-oriented systems with autonomous objects (agents), and to achieve a proper integration of the concurrency speci cation within object-oriented software development. The basic notions of PN-TOX are the Petri net objects, objects with a Petri net based concurrency speci cation, and the composition and coordination objects, for modelling object cooperation. Our approach is dierent from others in that: 1) we allow multi-model development, i.e. each autonomous object may have a net, modelling its concurrency behaviour, of any kind of net model (C/E-net, P/Tnet, CP-net and so on); 2) we attempt to guide inheritance for classes of Petri net objects in a formal way by providing a programmer with a catalogue of behaviour-oriented net transformations and composition operators, in order to enable him/her to bene t from the available research in those areas, and to provide him/her with a set of guidelines on how to relate net mappings with the de nition of inheriting classes

of Petri net objects; 3) multi-layer activity (also in LOOPN++) is allowed. The PN-TOX environment oers a set of tools and programming abstractions for supporting the development of concurrent applications using Petri net objects. It is based on a exible design as to allow extendibility of supported net models.

References [1] R. Bastide, C. Sibertin-Blanc, and P. Palanque. Cooperative Objects: A Concurrent, Petri-Net Based, Object-Oriented Language. In Proceedings of the 1993 International Conference on Systems, Man and Cybernetics, pages 286{292, 1993. [2] E. Battiston and F. De Cindio. Class Orientation and Inheritance in Modular Algebraic Nets. In Proceedings of the 1993 International Conference on Systems, Man and Cybernetics, pages 717{723, 1993. [3] E. Battiston, F. De Cindio, and G. Mauri. OBJSA Nets: a class of high-level nets having objects as domains. In Advances in Petri Nets 1988, pages 20{43, 1988. [4] L. Bernardinello and F. De Cindio. A Survey of Basic Net models and Modular Net Classes. In Advances in Petri Nets 1992, pages 304{351, 1992. [5] G. Booch. Object-Oriented Design with Applications. Benjamin/Cummings, 1991. [6] W. Brauer, R. Gold, and W. Vogler. A Survey of Behaviour and Equivalence Preserving Re nements of Petri Nets. In Advances in Petri Nets '90, pages 1{46, 1990. [7] D. Buchs and N. Guel . CO-OPN: A Concurrent Object-Oriented Petri Net Approach for System Speci cation. In Proceedings of the 12th International Conference on Application and Theory of Petri Nets, pages 432{454, 1991. [8] J. Desel. Vicinity Respecting Net Morphisms. In Advances in Petri Nets '90, pages 165{185, 1990. [9] J. Desel. On Abstractions of Nets. In Advances in Petri Nets '91, pages 78{92, 1991. [10] J. Engelfriet, G. Leith, and G. Rozenberg. Formalizing the Behaviour of Parallel Object-based Systems by Petri Nets. In Semantics for Concurrency, Leicester 1990. Springer-Verlag, 1990. [11] J. Engelfriet, G. Leith, and G. Rozenberg. Netbased Description of Parallel object-based Systems, or POTs and POPs. In Proceedings of School/Workshop in Foundations of Object-Oriented Languages, LNCS 489. Springer-Verlag, 1990. [12] D. Harel. Statechart: a Visual Formalism For Complex Systems. Science of Computer Programming, 8:231{274, 1987.

[13] T. Holvoet, S. Bijnens, and P. Verbaeten. Using Petri Nets For Intra-Object Concurrency Control of Object-Oriented Concurrent Applications. Technical report, Dept. of Computer Science, KULeuven, Belgium, December 1994. [14] T. Holvoet and P. Verbaeten. Inheritance for Petri Net Objects. Technical report, Dept. of Computer Science, KULeuven, Belgium, February 1995. [15] T. Holvoet and P. Verbaeten. Petri Charts: an Alternative Technique For Hierarchical Net Construction. In IEEE Conference on Systems, Man and Cybernetics 1995, 1995. To Appear. [16] C.A. Lakos and C.D. Keen. LOOPN - Language for Object-Oriented Petri Nets. In Proceedings of the SCS Multiconference on Object-Oriented Simulation, 1991. [17] C.A. Lakos and C.D. Keen. LOOPN++: A New Language for Object-Oriented Petri Nets. Technical Report TR94-4, University of Tasmania, 1994. [18] S. Matsuoka and A. Yonezawa. Analysis of the Inheritance Anomaly in Object-Oriented Concurrent Programming. In Research Directions in Concurrent Object Oriented Programming. The MIT Press, 1993. [19] L. Pomello, G. Rozenberg, and C. Simone. A Survey of Equivalence Notions for Net Based Systems. In Advances in Petri Nets 1992, pages 410{472, 1992. [20] Y. Souissi and G. Memmi. Composition of Nets Via a Communication Medium. In Advances in Petri Nets 1990, LNCS 483, pages 457{470. Springer-Verlag, 1991. [21] P.S. Thiagarajan. Some Behavioural Aspects of Net Theory. In ICALP'88 (International Colloquium on Automata, Languages and Programming), Tampere, Finland, LNCS 317, pages 630{653. Springer-Verlag, 1988. [22] W. Vogler. Modular Construction and Partial Order Semantics of Petri Nets. LNCS 625. Springer-Verlag, 1992. [23] P. Wegner. Models and Paradigms of Interaction. In Tutorial Notes, ECOOP'94, Bologna, Italy, 1994. [24] P. Wegner and S.B.Zdonik. Inheritance as an Incremental Modi cation Mechanism or What Like Is and Isn't Like. In ECOOP'88 (European Conference on Object-Oriented Programming), Oslo, Norway, LNCS 322, pages 55{77. Springer-Verlag, 1988.