Concurrent Object-Oriented Programming and Petri Nets Advances in Petri Nets (PDFDrive)
Concurrent Object-Oriented Programming and Petri Nets Advances in Petri Nets (PDFDrive)
Concurrent Object-Oriented Programming and Petri Nets Advances in Petri Nets (PDFDrive)
Concurrent
Object-Oriented Programming
and Petri Nets
13
Series Editors
Volume Editors
Gul A. Agha
University of Illinois at Urbana-Champaign
Department of Computer Science
1304 West Springfield Avenue, 61801-2987 Urbana, Illinois, USA
E-mail: agha@cs.uiuc.edu
Fiorella De Cindio
University of Milan, Computer Science Department
via Comelico 39/41, 20135 Milan, Italy
E-mail: fiorella.decindo@unimi.it
Grzegorz Rozenberg
Leiden University, Leiden Institute of Advanced Computer Science (LIACS)
Niels Bohrweg 1, 2333 CA, Leiden, The Netherlands
E-mail: rozenber@liacs.nl
Cataloging-in-Publication Data applied for
ISSN 0302-9743
ISBN 3-540-41942-X Springer-Verlag Berlin Heidelberg New York
This work is subject to copyright. All rights are reserved, whether the whole or part of the material is
concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting,
reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication
or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965,
in its current version, and permission for use must always be obtained from Springer-Verlag. Violations are
liable for prosecution under the German Copyright Law.
Springer-Verlag Berlin Heidelberg New York
a member of BertelsmannSpringer Science+Business Media GmbH
http://www.springer.de
The papers in this volume are organized into three sections. The first consists of
long papers, each of which presents a relatively detailed approach to integrating Petri
nets and object orientation – i.e. defining a syntax and its semantics, and illustrating it
with examples. Section II includes shorter papers where the emphasis is on concrete
examples to demonstrate an approach. Finally, Section III includes papers which
significantly build on the Actor model of computation.
We are grateful to the referees and to the authors for their patience in the
production of this volume. We would like to thank the organizers of the Petri Net
conference for their help in organizing the workshops. Finally, we are also very
grateful to Alfredo Chizzoni for his support in organizing the two workshops, and to
Nadeem Jamali and Patricia Denmark for their assistance in preparing the manuscript.
Section I
Using Petri Nets for Specifying Active Objects and Generative Communication....... 38
T. Holvoet, P. Verbaeten
Section II
Object Colored Petri Nets – A Formal Technique for Object Oriented Modeling .... 406
C. Maier, D. Moldt
Section III
Schedulability Analysis of Real Time Actor Systems Using Colored Petri Nets ...... 493
L. Nigro, F. Pupo
Charles Lakos
Abstract. This paper informally introduces Object Petri Nets (OPNs) with a
number of examples. OPNs support a thorough integration of object-oriented
concepts into Petri Nets, including inheritance and the associated polymorphism
and dynamic binding. They have a single class hierarchy which includes both
token types and subnet types, thereby allowing multiple levels of activity in the
net. The paper discusses some theoretical issues pertinent to the analysis of
OPNs, and compares the provisions of OPNs with those of other Concurrent
Object-Oriented Programming Languages.
The paper then considers a case study of using OPNs to model a cooperative
editor for hierarchical diagrams. This extended example demonstrates the
applicability of OPNs to the modelling of non-trivial concurrent systems. The
methodology for deriving a Petri Net model is to adapt an object-oriented
design methodology: the Object Model is prepared in Rumbaugh’s OMT
notation; the Dynamic Model is then prepared in the form of lifecycles,
following the Shlaer-Mellor methodology; and finally these models are mapped
into an OPN model. This approach has the advantage of guiding the
development with well-accepted methodologies, and demonstrates the
generality and flexibility of the OPN formalism.
1 Introduction
This paper informally introduces Object Petri Nets (OPNs) and considers their
application to object-oriented modelling. The goal of OPNs is to achieve a complete
integration of object-orientation into the Petri Net formalism, and thereby reap the
complementary benefits of these two paradigms. Petri Nets are used for the formal
specification of concurrent systems. They have a natural graphical representation,
which aids in the understanding of such formal specifications, together with a range
of automated and semi-automated analysis techniques. Object-oriented technology,
on the other hand, has become extremely popular because of its provision of powerful
structuring facilities, which stress encapsulation and promote software reuse. This
addresses a traditional weakness of Petri Net formalisms, namely the inadequate
support for compositionality.
The most distinctive feature of OPNs is the single unified class hierarchy. This has
not been evident in previous object-oriented Petri Net approaches (see the review
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 1–37, 2001.
ã Springer-Verlag Berlin Heidelberg 2001
2 C. Lakos
in [17]). Even our own Language for Object-Oriented Petri Nets (LOOPN) had
separate class hierarchies for token types and subnet types. This meant that there was
always a clean separation between tokens and subnets, resulting in the traditional style
of Petri Nets with the control aspects of the system being coded as a global net
structure. This is not the flexibility one is accustomed to in object-oriented
programming languages, where objects can contain attributes which are themselves
objects, and so on.
The provision of a single unified class hierarchy in OPNs means that both token
types and subnet types are classes, and these classes can be intermixed. A token can
thus encapsulate a subnet. This implies that OPNs support the possibility of multiple
levels of activity in the net and the modeller is free to choose how various activities
are to be composed, i.e. whether a particular object should be active, passive, or both
(depending on the focus of attention). This capability can address the increasing
demand to model complex hierarchical systems (as in [9], [11]).
This paper reports on the progress towards achieving the goal of integrating the
two technologies or paradigms. In doing so, the first part of the paper addresses the
various aspects which have been identified above. Firstly, OPNs are informally
introduced in §2, together with their graphical representation. This extends the usual
Petri Net conventions. The formal definition of OPNs has been published elsewhere
[17], [19], [22] and is not repeated here. Analysis capabilities for OPNs have not yet
been implemented, but §3 introduces some theoretical issues which impact on the
analysis of OPNs. In assessing the extent to which OPNs provide the flexible
structuring possibilities promised by object-orientation, §4 compares the capabilities
of OPNs with other concurrent object-oriented programming languages (COOPLs).
The suitability of a formalism is often determined by its applicability to non-trivial
problems. To this end, the second part of this paper presents the application of OPNs
to a non-trivial problem – the modelling of a cooperative editor for hierarchical
diagrams. The basic issues of object-oriented modelling and the benefits offered by an
integrated environment based on OPNs are introduced in §5. The (static) object
model for the case study is presented and discussed in §6, while the dynamic model is
considered in §7. The transformation of these models into an OPN model is
considered in §8. Finally, the conclusions and the directions for further work are
given in §9.
Traditionally, Petri Nets are drawn with ovals representing places (which hold
tokens), rectangles representing transitions (which change the distribution of the
tokens and hence the state of the net), and directed arcs (which indicate how
transitions affect neighbouring places). For Coloured Petri Nets (CPNs), tokens have
an associated data value. Places are then annotated to indicate what type of value
they hold, arcs indicate which values are consumed or generated (possibly with the
use of variables), and transitions can have a guard to further constrain their enabling.
Object Oriented Modelling with Object Petri Nets 3
For example, the traditional dining philosophers problem can be modelled as the
CPN of Fig. 1. All the places contain tokens with numeric values in the range 1..n.
i i i
i+1 i+1
1:n
retRight freeForks takeRight
i i i
i i
The inscription of arcs with variables shows how the token values are matched
from the various places. So, in order to fire the transition takeRight, for example, a
token for philosopher i must be present in the place hasLeft, a fork numbered i+1
must be available in the place freeForks (with addition modulo n assumed). On firing
this transition, a token for philosopher i is added to the place eating. In this example,
all the transition guards can have the default value of true.
Note that some of the annotations have been omitted from the diagram, such as the
type of each variable and the type of tokens for each place. This avoids cluttering the
diagram and such selective display of annotations is normally supported by a
graphical editor for Petri Nets.
OPNs extend CPNs in a number of significant ways, as considered in the following
subsections. The extensions are demonstrated in the development of a solution to the
Russian philosophers problem, an enhanced version of the dining philosophers
problem. The name is meant to conjure up the image of the Russian matrioshka dolls
which can be pulled apart to reveal other dolls inside. The Russian philosophers are
like the dining philosophers, except that each Russian philosopher is thinking about
the dining philosophers problem. Only when such an imagined dining philosophers
problem deadlocks, will the corresponding Russian philosopher stop thinking and try
to start eating. When such a Russian philosopher stops eating, he or she starts
thinking about a fresh dining philosophers problem. Naturally, this system can be
nested arbitrarily deeply. This problem is considered to be typical of a multi-level
system where one part is performing some task which is being monitored by another.
4 C. Lakos
The first significant extension of OPNs over CPNs is that each Petri Net (or subnet) is
defined by a class, which can then be instantiated in a number of different contexts.
Each class can contain data fields, functions, and transitions. The type of a data field
may be a simple type (such as integer, real, boolean, etc.), a class, or a multiset of the
above. Given in Fig. 2 is an OPN class definition for identifying each dining
philosopher.
DPhil
integer n = 5
integer id | id ≥ 0 and id ≤ n
integer left() = id
integer right() = id mod n + 1
boolean hungry() = true
Note that data fields generalise Petri Net places and are therefore drawn as ovals.
Their annotation indicates the type, the identifier, an optional initial value (preceded
by a character ‘=’) and an optional guard (preceded by a character ‘|’). The guard
must evaluate to true in a valid instance. It is therefore like a conjunct of a class
invariant [26], a database integrity constraint, or a fact of earlier Petri Net formalisms
[29]. Functions are drawn as rectangles to emphasise that they share transition
semantics – they have bindings of variables and are evaluated at a particular point in
time. The exporting of fields and functions is indicated by drawing them with a
double outline. A data field of multiset type (written type*) corresponds to a
traditional Petri Net place, and is called a simple place as opposed to a super place
(see §2.5).
Using the normal conventions, an OPN solution to the dining philosophers problem
would then appear as in Fig. 3. Note that places are annotated with their (multiset)
type, and optionally specify an initial value or marking. Thus, the place thinking
holds tokens of type DPhil, one of them being initialised with an id field of 1.
As with fields, the guard for a transition is indicated by a vertical bar followed by a
boolean expression. For the transition to be enabled, the guard must evaluate to true.
In Fig. 3, the transition takeLeft has a guard which requires that the function hungry
for the chosen philosopher should evaluate to true.
Object Oriented Modelling with Object Petri Nets 5
DTable
x.left() x DPhil x
x
x.left() x.right()
retRight takeRight DPhil* y
int* forks
= [1,...,5] x
x x.right()
x x
There is an attractive symmetry about the use of guards for class components and
for transitions. In fact, the formal definition for the binding of a transition (such as
takeLeft) is really an instance of a class, with fields for the variables (in this case x)
and a constraint to restrict the valid bindings [19]. It would be possible to define each
kind of binding with a separate class diagram, but this would be overly cumbersome.
Therefore, we allow the shorthand of annotating a transition (externally) with a guard,
and of graphically representing transition variables, such as x and y. A striped
shading is used for variables to highlight that they are really local to a transition, and
their value exists only for the duration of transition firing. (Note that the fact that
transition bindings can be defined by classes is exploited for super transitions in §2.6.)
In this example, unlike that of Fig. 2, we define a function dead() which is state-
dependent, i.e. it determines whether the table of dining philosophers is deadlocked.
This dependence of the function on the place hasLeft is explicitly shown with an
equal arc (which is a compound arc consisting of a test arc and an inhibitor arc, each
having the same inscription) [15]. This arc has the effect of binding the variable y to
the marking of the place hasLeft. The function then returns true if the place hasLeft
holds n tokens.
The ability to define functions with read-only access to the current state of a subnet
is another significant extension of OPNs over CPNs. While such access functions are
commonly supported by COOPLs, this is not the case for Petri Net formalisms, even
though such functions can significantly enhance the encapsulation of subnets [23].
2.3 Inheritance
In order to qualify for the title object-oriented [36], OPNs support the definition of
classes with inheritance. In order to demonstrate this, we consider the OPN class
definition used to instantiate each Russian philosopher (Fig. 4).
6 C. Lakos
RPhil : DPhil
integer n = 5
integer id | id ≥ 0 and id ≤ n
integer left() = id
integer right() = id mod n + 1
boolean hungry() = image.dead()
DTable image
The label of the class frame indicates that the class RPhil inherits the features or
components of the class DPhil. The grey shading identifies those features or
components which are inherited without change, while the black shading indicates
components which have been introduced by this class or which override inherited
components. Thus, class RPhil modifies class DPhil by augmenting it with image
(the image of the table of dining philosophers), and by overriding the function hungry,
so that Russian philosophers are hungry only when image deadlocks.
It is an open question as to the appropriate behavioural relationship between a
parent and a child subclass [18]. We have adopted the approach of the Eiffel
language [26], in requiring that the type of an overriding field must be a subclass of
the type of the overridden field (in the parent class), and that the guards in a subclass
should be stronger than those of the parent class. This ensures that an instance of the
subclass also qualifies as an instance of the parent. It is essentially a pragmatic
solution, but does have the benefit of being the foundation of a programming and
design methodology, namely programming by contract [35].
It is worth noting that we have adopted the convention that all inherited
components are displayed graphically (with the appropriate shading). Experience has
shown that if the inherited components are not displayed at all (analogous to the
conventions of object-oriented programming languages), then it is difficult to
determine the role of the subclass since many of the visual cues are now missing.
This is especially the case for Fig. 5. Nevertheless, we would expect a graphical
editor for OPNs to allow the display of inherited components to be toggled on and off.
class DPhil contains no actions, and therefore can be considered as a data structure
with no encapsulated activity. This kind of instantiation is already possible in CPNs
[12]. Similarly, the instantiation of the table of dining philosophers in the class RPhil
of Fig. 4 is akin to the instantiation of pages by substitution transitions in HCPNs
[12].
However, OPNs also allow tokens to be arbitrary subnets. This can be
demonstrated with the class for a table of Russian philosophers, as shown in Fig. 5.
Note that here the places holding RPhil tokens are holding tokens which have their
own encapsulated activity. The current state of one of these tokens can be
interrogated using the defined access function hungry().
RTable : DTable
x.left() x.right()
retRight takeRight DPhil* y
int* forks
= [1,...,5] x
x x.right()
x x
This example also demonstrates the use of polymorphism in OPNs since RPhil (or
subclass) instances may occur in DPhil (or superclass) contexts. Thus, the class
RTable needs to override the place thinking so that it can initialise it to hold RPhil
tokens. However, transitions which have been written to fetch and store DPhil tokens
will also work with RPhil tokens and hence do not need to be overridden. Similarly,
places defined to hold DPhil tokens can also store RPhil tokens. The only other
change required to the DTable class is to override the transition retRight, so as to
ensure that each Russian philosopher, on returning their right fork, starts thinking
about a fresh dining philosophers problem rather than the same deadlocked one which
led to eating.
The previous subsection has shown that OPN classes can be arbitrarily instantiated.
As well as implying that OPNs can directly model complex systems with multiple
levels of activity (like the Russian philosophers problem), it also gives freedom to the
8 C. Lakos
modeller to choose the encapsulation which best suits the problem at hand. For
example, the above solutions to the dining philosophers and Russian philosophers
problems are derived from a standard Petri Net solution (Fig. 1). However, it is not a
natural object-oriented solution because the philosophers are passive components
while the table is active. A preferred solution would be to model each philosopher as
an active component which interacts with the table setting (which contains the forks).
The table setting could also store the number of philosophers once, instead of
duplicating this for every philosopher and every table.
This leads naturally to the notion of a super place, which is another significant
extension provided by OPNs. OPNs generalise the notion of a place to include any
data field which can act as a source or sink of tokens. For simple places, the type is
some multiset type which determines both the tokens that can be held and the tokens
that can be extracted and deposited. A super place is defined by a class inheriting a
multiset type, which then defines the tokens which can be extracted and deposited.
The class may include extra net components. In other words, a super place is the
instantiation of a class which can act as a source or sink of tokens, but where the offer
or acceptance of the tokens may be constrained by the internal logic of the place.
The offer and acceptance of tokens by a superplace is depicted by arcs incident on
the class frame. The environment of a super place can remove tokens provided this
action can be synchronised with the offer of tokens from within the super place.
Thus, an alternative solution to the dining philosophers problem can start with a class
to act as the table setting (as in Fig. 6) which is instantiated as in Fig. 9. The table
setting holds the forks and is prepared to exchange them with the environment. This
class inherits from integer* which is the type for a place holding integer tokens. In
other words, this class can act as the source and sink of integer tokens. The
environment (of Fig. 9) can offer a token to the table setting by firing transition
putdown. The table setting (of Fig. 6) can accept a token by firing the ret transition
(and similarly for the pickup and get transitions). The class also supplies the unique
definition of n (the number of seats at the table) and the functions left and right.
Setting : integer*
integer left(id) = id
integer n = 5
integer right(id) = id mod n + 1
integer token
integer* forks = [1,...,5]
The above approach embodies the formal definitions of [17], [19] by matching the external
token interaction with the internal activity. These definitions do not constrain the annotations
of the arcs incident on the class boundary. However, if these arcs were allowed to be inscribed
by arbitrary multiset expressions, then there would be significant performance penalties in
matching the internal and external interaction. In practice, it seems reasonable to constrain
these arc inscriptions to specify a single token. Then each token specified by an external arc
(which may have an arbitrary multiset inscription) simply needs to be matched by the enabling
of one of the boundary transitions of the superplace. This clearly leads to an efficient
implementation and conceptually captures the notion that the tokens in a place or superplace
are essentially independent, i.e. they can be accessed individually.
The formal definitions also mean that the logic of the superplace can determine
when tokens are accepted or offered. This makes it easy, for example, to design a
superplace which acts as a capacity place, i.e. one that will not accept more than a
predetermined multiset of tokens. An alternative approach to the definition of super
places, based on the notion of net morphisms, is presented in [22]. This considers the
notion of abstract places and transitions in the context of CPNs, but it is equally
applicable to OPNs. In the simplest case, an abstract place is a place-bordered subnet,
as illustrated in Fig. 7.
In this case, the abstract place is largely passive, i.e. it cannot constrain when
tokens are deposited or extracted (provided that they are available in border places).
Thus, it is not possible to design an abstract place which acts as a capacity place.
Accordingly, we prefer the former approach (as in Fig. 6) for providing interaction
with the superplace.
The paper on abstraction [22] also argued that the notion of a place abstraction
should not be merely conceptual or structural (i.e. a place-bordered subnet), but
should include behavioural properties. Specifically, a place abstraction should
include the notion of an abstract marking which is a projection of the state of the
subnet, and which should be invariant over the firing of internal transitions but not
over the firing of interface transitions. (Fig. 6 only has interface transitions.) This
10 C. Lakos
notion of a marking can be provided in various ways. One possibility is to require the
modeller to supply a function called marking which returns the appropriate value.
Such a function is shown in Fig. 6. Alternatively, the implementation could associate
a redundant place with each super place, which could record the projected marking
and which would only be affected by the transfer of tokens to and from the super
place. Then the extraction of a token would require the token to be present in the
redundant place and also for one of the interface transitions to be enabled for that
token.
Using the table setting of Fig. 6, the active dining philosophers can be modelled by
the class of Fig. 8, where the state of the philosopher is indicated by the position of
the single null (or colourless) token. This class is also a superplace, which exchanges
fork requests (–1 for a left fork, +1 for a right fork) with its environment.
APhil : integer*
-1
null* thinking null* hasLeft integer id
= [[]]
x
boolean waiting() = true
x x
takeLeft
| hungry() x boolean hungry() = true
x
takeRight
1 retRight 1
x null x
x
retLeft
x x
Finally, the above components can be combined into the class of Fig. 9 for a table
of active dining philosophers. The class has a super place for the table setting and a
place holding the active philosophers. It has two transitions which allow the
philosophers to interact with the table setting. We have found that this pattern of
transitions is common to interaction across the multiple levels of containment in
OPNs (see §4.2). Here, the selection of token x (for an active philospher) from place
phils is synchronised with interaction with that token (by exchanging fork request j)
and with access to fork i.
Object Oriented Modelling with Object Petri Nets 11
ATable
Setting table
i i
APhil x putdown |
pickup | j = –1 and
j = –1 and j j
i = table.left(x.id)
i = table.left(x.id) or
or x x
j = +1 and
j = +1 and i = table.right(x.id)
i = table.right(x.id) APhil* phils =
integer i [[id:1], …]
y
APhil* y
The thoughtful reader will note that the transitions in class ATable mean that the
active philosophers do not encapsulate all the activity of the system. There are
difficulties in having philosophers refer directly to the table setting via pointers, for
example (see §3.1). Further, it is a convention of Petri Nets to constrain interaction to
neighbouring components. We consider that it is reasonable to show explicitly by a
net (as in Fig. 9) the environment in which active objects interact.
It is left as an exercise for the reader to derive a solution to the Russian
philosophers problem using active philosophers.
declared as port places). When the subnet substitutes a transition, the places p1 and
p2 would be fused with the neighbouring places of the transition. Then the transfer
of tokens into p1 and out of p2 would be determined solely by external transitions,
and the transfer of tokens from p1 and to p2 would be solely determined by the
internal transition xfer. There would be no guarantee (or requirement) that even if
tokens were deposited into place p1, that there would ever be tokens extracted from
place p2. In other words, there is no sense in which the actions associated with the
arcs incident on the substituted transition should be synchronised in any way.
Consequently, the semantics of such a substitution transition (in terms of its
interaction with its environment) can only be understood from the documentation or
by expanding out all the levels of the hierarchy. This is not helpful in practical
applications where an HCPN model may have three or more hierarchy levels.
Arising from this critique, it is proposed [22] that super transitions should support
the notion of firing, namely that all the effects of the incident arcs are synchronised in
some sense. Specifically, the firing of the super transition will normally correspond
to a multiset of internal actions, determined from the abstract firing mode. This set of
internal actions will determine the interaction of the super transition with its
environment, i.e. the effect of firing the super transition. However, The fact that it is
a set of actions will not be visible to the environment (in the same way that the details
of the state of a super place are not visible to its environment). In this sense, the arc
effects are synchronised (as far as the environment is concerned).
Supertrn : Trans, M*
M j
M* p1 M* p2
mode j j mode
xfer
The set of internal actions is governed by the transfer of tokens to and from the
subnet, as indicated in Fig. 10 (the dual of that for super places in Fig. 6). The class
inherits from the (pseudo) class Trans, thus indicating that it is a super transition. It
also inherits from M*, thus indicating that the firing modes of the transition are given
by class M. (Recall from §2.2 that the bindings or firing modes of a transition can be
defined by classes, just like tokens.) If the super transition fires with a particular
mode (or binding), then that mode must be transferred on every arc incident on the
class frame. In effect, this means that the start of firing of the super transition is
achieved by activating the arcs from the class boundary, and the end of firing is
achieved by activating the arcs to the class boundary. In our simple example, this
means that the firing of the super transition can commence with the mode as a token
being deposited in the place p1. This means that the transition xfer can then fire.
Finally, the firing of the super transition can be completed by extracting the mode as a
token from place p2.
Object Oriented Modelling with Object Petri Nets 13
The formal definition of OPNs [17], [19] does not support such a flexible form of
super transition. In fact, they require that the internal and external effects of a super
transition must match exactly and be exactly synchronised. This was recognised as
being too restrictive in practice and was one of the motivations for considering a
different form of abstraction [22]. Just as for place abstractions, it was argued that
transition abstractions should not be merely conceptual or structural (i.e. a transition-
bordered subnet), but should include behavioural properties. Specifically, a transition
abstraction should indicate which internal actions correspond to an abstract firing
mode. In our example, this is determined by the tokens deposited and extracted from
the subnet.
As already noted, the formal definition of OPNs has been published elsewhere [17],
[19] and is not reproduced here. Instead, we highlight certain aspects of the formal
definition which impact on the traditional Petri Net properties and analysis.
At the time of writing, the analysis capabilities discussed below have not been
implemented. However, it should be noted that foundation for the analysis of OPNs
is provided by the ability to map OPNs into behaviourally equivalent CPNs [16].
The formal definition of OPNs consistently uses object identifiers to refer to class
instances [19]. Thus, when a token is extracted from a place, it is the object identifier
which is specified, and not the whole object (with potentially many levels of nested
components). If such an object identifier is extracted from a place and not deposited
into another place, then the whole object (including the nested components) is
discarded.
This approach makes it possible for a transition to synchronise activity across
different levels of containment in an object. For example, transition pickup in Fig. 9
removes token x for an active philosopher from place phils and then returns it. At the
same time, a fork request j is added to the philosopher x. Thus, the token x returned to
place phils has the same object identifier, but modified contents. This is a common
requirement for such multi-level nets, and is clumsy to achieve without the use of
object identifiers.
The possibility of reachability analysis for OPNs is affected by the use of object
identifiers, since the number of these is potentially infinite. For this kind of analysis
to be feasible, the number of object identifiers will need to be finite (as is assumed in
[4], for example). Alternatively, some symmetry analysis will be required to
determine if two objects are identical apart from relabelling of object identifiers. We
anticipate that in practical cases, the number of objects will be finite.
Another aspect of the formal definition related to object identifiers is that tokens
are required to be self-contained — it is not possible for some components of a token
14 C. Lakos
It is possible to define place invariants directly for OPNs, in a similar manner to that
of [10]. For a monolithic, non-hierarchical CPN, this means that a weight function is
defined which, for each place, maps the (multiset) marking of that place to a common
multiset type. For a place invariant, this projection of the marking of the net will be
invariant for all possible firing sequences of the net. For a modular CPN, a family of
weight functions is defined, one for each module or page instance. The local weight
function for a module maps the marking of each module place to a multiset (or
weighted set) over some common colour set. For such a family of weight functions to
define a place flow (or a place invariant), each weight function has to be a local place
flow, and the weight functions for different modules must coincide on fused places.
Given the dynamic allocation and deallocation of subnets in OPNs, it is not
feasible to define a different weight function for each page instance (as for modular
CPNs). Instead, we define one weight function per class. The contribution of a class
instance to the weighted marking of the net is then given by the local weight function
for the class combined with a weight determined by the context of the instance within
the net.
Thus, if we wish to define a place invariant with range given by the colour set R
(which may not be a set of object identifiers), then for each class s, we define a local
weight function Ws, satisfying the following properties:
(a) Ws is a function mapping object identifiers of class s (and hence the instances
of the class) into weighted sets over R.
(b) Ws is defined by mapping the markings of the data fields in the class instance
into weighted sets over R.
Note that having defined the weight functions for individual object identifiers, they
can be uniquely extended to linear functions over the domain of sets (or multisets) of
object identifiers. The set of all local weight functions is called a family of weight
functions W = { Ws } .
Given a family of weight functions W and a marking M of the OPN, a weighted
marking is given by W(oid0), where oid0 is the object identifier of the instance of the
root class (which indirectly instantiates all other net components). The family of
weight functions applied to oid0 applies weight functions to the data field values in
the instance of the root class which, in turn, may apply other weight functions to the
component instances. In other words, the contribution of a class instance to the
weighted marking is given by the local weight function applied to the instance
together with the composition of weight functions for the component instances. The
Object Oriented Modelling with Object Petri Nets 15
composition of the the weight functions for the component instances is defined as a
context weight function W', and is defined by the derivation of each class instance
from the root class instance.
This can be illustrated by the Russian philosophers example of Fig. 5. Suppose we
wish to prove that for each Russian philosopher the forks in their dining philosophers
image are conserved. Consider Russian philosopher with identity i, as follows:
(a) define a local weight function for the root class RTable which determines the
result from the root class instance in terms of the object identifiers for the
appropriate Russian philosopher i:
WRTable (x) = WRPhil (W1 (M(thinkingx) + M(hasLeftx)+ M(eatingx)+
M(hasRightx)))
where px is the instance of place p in the class instance x and where
W1 (x) = if x.id = i then x else Ø
In other words, the contribution of instance x to the forks for Russian
philosopher i is determined by the markings of places thinking, hasLeft,
eating and hasRight for Russian philosopher i.
(b) define a local weight function for the class RPhil which determines the
contribution of its instances to the result, in this case the contribution from the
image of the dining philosophers:
WRPhil (x) = WDTable (M(imagex))
In other words, the contribution of Russian philosopher x to the forks is given
by the marking of image, the image of the table of dining philosophers.
(c) define a local weight function for the class DTable which returns the
weighted sum of forks according to the state of the various philosophers:
WDTable (x) = WDPhil (M(hasLeftx) + M(eatingx)) + M(forksx) +
W2 (WDPhil (M(eatingx) + M(hasRightx)))
where
W2 (x) = x+1
In other words, the contribution of a table of dining philosophers to the forks
is determined from the philosopher tokens in places hasLeft, hasRight and
eating (with philosopher tokens in place eating contributing both left and
right forks), together with the forks still unused in place forks.
(d) define a local weight function for the class DPhil which returns the identity of
the particular dining philosopher:
WDPhil (x) = x.id
Having introduced OPNs, we now compare the provisions of OPNs with key aspects
of other concurrent object-oriented programming languages (COOPLs).
The work on Actors has been a catalyst for many ideas related to COOPLs. In a
recent paper [1], Agha et.al. have noted that the transition from sequential to parallel
and distributed computing has been widely accepted as a major paradigm shift
occurring in Computer Science. They argue that the Actor paradigm with objects as
concurrent computational agents is much more natural than that found in sequential
object-oriented languages.
Fundamental to the notion of Actor systems is the notion of a computational agent
which is able to respond to the reception of a message by sending another message,
by creating a new actor with some specified behaviour, or by replacing the current
behaviour. Behaviour replacement gives actors a history-sensitive behaviour
necessary for shared mutable objects … in contrast to a purely functional model [1].
Under these criteria, OPNs qualify as a formal model for actor systems. OPNs
naturally model concurrent, distributed systems. Each instance of an OPN class can
be an independent computational agent, and message-passing between OPN objects is
captured by token passing. New actors can be created simply by creating new tokens
which are instances of the appropriate class. The ability of an actor to replace its
behaviour with another, is not directly supported, but is available indirectly, since
OPN class instances are mutable objects which can change state.
Agha et.al. [1] note that while asynchronous message sending is the most efficient
form of communication in a distributed system, and the form originally assumed by
the Actor model [2], they argue that concurrent languages should provide a number of
flexible communication abstractions to simplify the task of programming. They argue
for supporting call/return communication, pattern-directed communication, syn-
chronisation constraints, and synchronisers.
The standard form of message-passing in the Actor model is asynchronous. The
actor which initiates the message continues with its own computation rather than
waiting for a reply. Call/return communication has both synchronous and asyn-
chronous dimensions – it is synchronous in that the message originator waits for a
reply before continuing, but it is asynchronous in that the sending of the call is not
blocked. Call/return communication can be implemented by remote procedure call.
OPNs can model call/return communication directly by super transitions (as proposed
in §2.6).
Pattern-directed communication removes the constraint for an actor to specify its
communication partner explicitly. The usual point-to-point communication allows
Object Oriented Modelling with Object Petri Nets 17
x x
actor* s1 y actor* s2
actor x
Agha et.al. [1] also consider the provision of synchronisation constraints, i.e.
where a concurrent object can constrain the invocation of its methods. For example, a
bounded buffer object should not accept a put action unless there is space in its buffer.
It is argued that synchronisation constraints should be separated from the
representation of methods.
The OPN notion of a super place supports synchronous interaction (see §2.5). The
transition which deposits (or extracts) a token at a super place must synchronise with
an internal transition of the superplace which accepts (or produces) a matching token.
The internal transition (as well as the external transition) can constrain the interaction
with a suitable guard. This has been demonstrated in the table setting object for the
active dining philosophers (in Fig. 6) and the pattern-directed communication (of Fig.
11). The other activity of the superplace (corresponding to method bodies) can be
represented by other internal transitions. In other words, OPNs directly support the
notion of synchronisation constraints and the separation of synchronisation and
method bodies.
18 C. Lakos
4.3 Compositionality
There has been much work on the so-called inheritance anomaly which is the
interaction between inheritance and synchronisation policies in COOPLs [24].
Because of it, some COOPL designers have chosen not to support inheritance as a
fundamental language feature. It is our view (supported by [6]) that much of the
problem stems from the way that method definitions in traditional programming
languages tend to combine the synchronisation code with the internal state
transformation instead of separating these concerns, as recommended in the Actor
model.
In the same way, the inheritance anomaly can be signficantly reduced for OPNs
and for super places in particular, since it is easy to identify the internal transitions
Object Oriented Modelling with Object Petri Nets 19
which control the acceptance and supply of tokens, and hence which embody the
synchronisation constraints. Furthermore, OPNs naturally support synchronisation
constraints by method guards, which is the technique with the least problems as
considered by Matsuoka and Yonezawa [24]. Method guards are only deficient for
history-sensitive synchronisation, but we argue that it is unrealistic to demand history-
sensitive synchronisation without first storing the necessary history information in the
object.
A more difficult issue concerning inheritance is the extent to which the behaviour
of a parent class should be retained in a subclass. Some have advocated a bisimilarity
or labelled transition sequences, while others have proposed the maintenance of
labelled state sequences [4]. We have found that both of these appear to be too
restrictive in practice [18].
5 Object-Oriented Modelling
Having considered the elements of OPNs and compared their facilities with those of
other COOPLs, we now consider the application of OPNs to object-oriented
modelling.
Mellor and Shlaer [25] assert: „The ability to execute the application analysis
models is a sine qua non for any industrial-strength method, because analysts need to
be able to verify the behaviour of the model with both clients and domain experts.“
On the other hand, a recent assessment of CASE tools [28] has noted: „The biggest
mistake was to overestimate the ease with which the early CASE tools would evolve
into the kinds of truly integrated CASE systems that users want. It is a long way from
diagramming tools to generated code.“ Similarly, it has been observed [14]: „Tool
integration therefore is an important issue. Lack of integration is a major criticism
regarding CASE tools because it is detrimental to acceptance of CASE by the users.“
This paper now examines whether the above deficiencies can be addressed by
employing OPNs as the formal foundation for an integrated CASE environment.
OPNs are formally defined, allowing them to be used for software specifications; and
they are executable, thus allowing OPN software designs to be used as prototypes.
In order for OPNs (or any other proposal to integrate object orientation and Petri
Nets [3], [4], [5], [8], [32]) to qualify as a formalism suitable as the foundation for an
integrated CASE environment, it must be able to model realistic case studies. We
therefore consider such case study – an editor for hierarchical diagrams in some
cooperative working environment (see the appendix.)
In line with the problem specification, our solution concentrates on the locking
mechanisms required to allow cooperative editing. Hence the precise nature of the
diagrams – whether Petri Net diagrams, Circuit Diagrams, Object-Oriented Designs,
etc. – is irrelevant. It should be possible to refine the basic framework presented here
for any of these specific diagrams. The essential aspect of the diagrams is that they
are hierarchical, i.e. one graphic component may be an abstraction of a diagram which
can then be opened and edited.
20 C. Lakos
Again in line with the problem specification, our solution ignores display issues
such as windows, icons, menus, etc. We are interested in the underlying objects, not
their graphical representation, nor the way that the user communicates with the
system. (This is akin to the distinction made in the context of graphical user
interfaces (GUIs) between subjects, views and editors [34].) However, since the
underlying objects of our case study are diagrams, there will be some graphics-related
attributes which will need to be stored. For example, the position of a graphic in a
diagram is relevant to the underlying object since it is an attribute that may be
modified by the user via the GUI. This can be accommodated under the general
notion of editing an object’s attributes.
This paper derives a solution to the problem by preparing an object-oriented design
and then mapping it into an OPN. This has the significant advantage of building on
existing object-oriented methodologies which are widely used, admittedly with many
variations. It will also have the effect of constraining the possible solutions. An
advantage of this is that it will force us into a particular style of solution which will
therefore test the flexibility of OPNs. A disadvantage is that it may exclude natural
Petri Net solutions, especially those with enhanced concurrency. Another significant
advantage is that this approach can provide a formal semantics for informal design
methodologies.
The design methodology adopted in the subsequent section is a hybrid which uses
the Rumbaugh notation [30] to capture the static object model, and the Shlaer-Mellor
approach to capture the dynamic models [31]. This approach has been chosen
because the Rumbaugh notation is well-accepted but is vague about the integration of
static and dynamic models. On the other hand, the Shlaer-Mellor approach provides
clear guidelines on the integration of static and dynamic models, but has a somewhat
unconventional approach to inheritance. This hybrid approach is not completely
unusual since it is allowed by the Unified Method [7].
Because the problem specification is incomplete, it will be necessary to make
assumptions about the case study. We normally choose simplifying assumptions but
note the situations where these have significant ramifications.
From the problem description, we derive the Object Model of Fig. 12, given in the
OMT notation of Rumbaugh [30].
For those unfamiliar with the notation, the classes are denoted by labelled
rectangles, the associations by lines. Lines with no terminator indicate that the class
participates once in the association, a solid dot as terminator indicates that the class
may participate zero or more times, while a hollow dot as terminator indicates that the
class may participate zero or one times. The diamond terminator indicates an
aggregation relationship, while a triangle indicates an inheritance relationship.
Object Oriented Modelling with Object Petri Nets 21
Accesses
Graphic User
Participates
Involves
Diagram Session
Thus, in Fig. 12, each User participates in a number of editing Sessions, and each
Session has a number of participating Users. Similarly, each Graphic is accessed by a
number of Users, and each User accesses a number of Graphics. Each Session
involves one Diagram, and each Diagram may be the subject of an editing Session.
Note that while the identifier Graphic is used, it is not meant to imply that this
class holds information relevant to the graphical representation or display of the
component. It simply indicates the underlying object for a diagram component. (It is
a subject in the terminology of [34].) As already noted in §5, a Graphic may need to
store attributes which affect the graphical display, but these are treated uniformly as
editable attributes.
The problem specification suggests the use of some locking mechanism so that
certain kinds of accesses to a Graphic will preclude other accesses (by a different
User) to the same Graphic. This could be made explicit by introducing a class Lock
as in the alternative object model of Fig. 13.
Diagram Session
Fig. 13. Alternative Object Model for the Cooperative Editor, with explicit locks
Each instance of Lock would capture the interaction between a single Graphic and
a single User, with the kind of locking being an attribute of Lock. This approach has
not been followed since it would preclude other forms of interaction, such as version
control. By simply having an association between Graphic and User (as in Fig. 12), it
is possible to map the model into a solution with locking or version control, or some
other form of interaction. Certainly, locking is possible, with the kind of lock now
being an attribute of the association.
22 C. Lakos
There is a more complex relationship between the classes Diagram and Graphic in
Fig. 12 (and Fig. 13). The class Diagram is a subclass of (or inherits from) the class
Graphic. Further, a Diagram is an aggregation of zero or more Graphics, and each
Graphic is optionally a component of a Diagram. (Only root Diagrams are not
components of other Diagrams.)
This relationship between Graphic and Diagram represents an interesting design
choice. An alternative approach would be to treat both Graphic and Diagram as
subclasses of some abstract superclass called Lockable, i.e. the class of objects which
the user can access and lock. This would then be captured by the partial model of Fig.
14. Now, a Diagram may or may not be an expansion of a Graphic, depending on
whether it is a root diagram. Similarly, a Graphic may or may not have an expansion,
depending on whether it is a simple or a complex graphic. The original solution of
Fig. 12 was considered to be simpler and therefore preferable.
Another implication of the approach in Fig. 14 is that every Graphic belongs to a
Diagram, which is not required by the original solution. The original solution
therefore leaves open the option of a Graphic being accessible in some other context,
such as an icon on the workstation desktop.
Lockable
Expands
Graphic Diagram
Consists of
Fig. 14. Alternative relationship between Graphic and Diagram
Finally, the role of a Session is worthy of comment. This class is identified in the
problem description, but it is not clear whether it adds any information which cannot
be deduced from elsewhere. For example, if a User has access to a number of
Graphics which belong to a particular Diagram, then the user must have a Session
open for that Diagram. Of course, if the kind of access to a Diagram in a Session is
different to the kind of access to a Graphic, then it will be helpful to include the
notion of a Session. In order to cater for this possibility, we have chosen to include
this class.
In developing the object model, the attributes and operations pertinent to each class
have not been considered. The reasons for this are two-fold. Firstly, the choice of
these components is usually a simpler process than the choice of classes and
associations. (We introduce some attributes in specifying the OPN model in §8.)
Secondly, the Shlaer-Mellor methodology emphasises the design of the dynamic
model in terms of lifecycles, to the exclusion of the choice of operations.
Object Oriented Modelling with Object Petri Nets 23
In order to capture the dynamics of the case study, we adopt the Object Lifecycle
approach of Shlaer and Mellor [31]. This determines the lifecyles for each relevant
class in the form of a finite state machine (FSM). The choice of such an FSM model
has the advantage of building on a well-accepted methodology, but has the
disadvantage that it may exclude a range of Petri Net solutions, particularly those with
high levels of concurrency. Since each object lifecycle is a finite state machine,
concurrency within an object is not considered.
In a lifecycle, the states are drawn as labelled rectangles, while the transitions
between the states are drawn as directed arcs. Each arc is annotated by the event
which can cause the transition between the states. (The events may originate either
internally or externally to the object.) Each state can be annotated with an action
which occurs on entry to the state. That action may involve the generation of new
events and the modification of the local state. Where an action is non-trivial, it is
described by an Action Dataflow Diagram (ADFD).
Parts of the lifecycles for User and Graphic are given in Figs. 15 and 16. To avoid
intersecting lines, the state Idle has been duplicated in each case, a facility we would
expect to be supported by a graphical editor.
Thus, for User, the initial (and final) state is Dormant. A User, through the GUI,
may request the opening of a Diagram (event U3). The appropriate event (D6) is sent
to the chosen Diagram, which will respond in due course with acceptance (event U1)
or rejection (event U0). Once a diagram is open, the User will be in the Idle state.
From there, it is possible to respond to display updates (event U2) and to perform
various operations, as dictated by user actions in the GUI. One possibility is for the
User to select a Graphic for inspection (event U7), causing a change of state from
Idle to RQ inspect. On entry to the new state, an event (G3) is sent to the chosen
Graphic in order to convey the request. The Graphic may respond with rejection
(event U0) or acceptance (event U1). We have adopted the convention of using three
states for each such operation – one to indicate that a request has been made, one to
indicate that the operation is being performed, and one to indicate that it is completed.
Note that we have distinguished between an open and an expand operation. An
open event (D6) can only be sent to a Diagram while an expand event (G5) can be
sent to a Graphic or a Diagram. If an expand event is sent to a Graphic which is not
a Diagram, it requests the conversion from a simple Graphic to a Diagram. In both
cases an open event will eventually be processed.
In the lifecycle for a Graphic, the initial (and final) state is Idle. Again, we have
used three states for each operation. At the request state (after receiving the relevant
request event), a decision is made whether to accept or reject the request and the
corresponding event (U1 or U0) is sent to the User, and a similar event to the
Graphic. (Note that the logic for making the choice will need to be given by an
ADFD interacting with the current state of the object.) On returning to the Idle state,
a U2 event is sent to all relevant users to ensure that all views of the diagram are
updated.
24 C. Lakos
Dormant
U1: accept
U1: accept
U0: reject
U4: open done
U5: close diagram
Idle
U7: inspect graphic U0: reject U9: edit graphic U0: reject U11: expand graphic U0: reject
G3: inspec graphic G0: reject G4: edit graphic G0: reject G5: expand graphic G0: reject
G5: expand graphic D6: open diagram D0: reject D7: close diagram D0: reject
This question of the relationship between the lifecycle of a class and its subclass is
ignored by most object-oriented modelling schemes. It is considered by Shlaer and
Mellor [31], though in a somewhat confusing manner, possibly because the work
products of the methodology can be mapped into a non-object-oriented language. It
therefore does not speak of inheritance in the same way as traditional object-oriented
programming languages. Instead, a subclass is split up into two parts – one
containing the components of the superclass (called the supertype), and one
containing the components unique to the subclass (called the subtype). An instance of
the subclass thus involves an instance of both the supertype and the subtype. A
lifecycle can optionally be associated with each of the two parts. If a lifecycle is only
associated with the supertype, then all the subclass instances have the same
behaviour. If lifecycles are only associated with the subtypes, then the behaviour is
different for each subclass instance. Alternatively, both supertype and subtypes may
have lifecyles, in which case the lifecycle of a subclass instance is formed by splicing
together one of each to form a composite lifecycle. Shlaer and Mellor even allow for
an instance to migrate between different subtypes over its lifetime. We consider that
this approach is unfortunate since it muddies the water about the nature of inheritance.
Instead, we affirm that each object is an instance of a single class. Further, a subclass
will inherit both the data and the lifecycle(s) of its parent(s), and will have the option
of augmenting or overriding both. In other words, any lifecycle splicing will be done
explicitly by the modeller, as we have done in Fig. 17 – the states Idle and RQ expand
would override the same states of Fig. 16, while state RQ open would become a new
state, etc.
Similarly, Shlaer and Mellor speak of polymorphic events, but do not treat
polymorphism in the usual object-oriented way. In the above example, the event G5
is polymorphic since it can be received both by a Graphic and by a Diagram. The
labelling of events is the one suggested by Shlaer and Mellor, namely a letter for the
class together with a unique number. If one sticks rigidly to this convention, a table is
required to indicate how such a polymorphic event can be translated into other events,
e.g. event G5 for graphics may be translated into an (equivalent) event D5 for
diagrams. Again, we feel that this requirement is unfortunate, and propose that a
subclass (in this case Diagram) can respond to events defined for the superclass (in
this case Graphic).
With its complete integration of object-oriented structuring, OPNs support both the
augmentation and overriding of parts of a net. As a result, we can support a more
natural form of inheritance and polymorphism. Consequently, the augmentation and
overriding of lifecycle components (as in Fig. 17) can be mapped directly into the
corresponding OPNs.
As already noted, the Shlaer-Mellor methodology specifies that complex actions
(which occur on entry to states) are modelled by Action Dataflow Diagrams
(ADFDs). In Fig. 16, for example, a Graphic, on receiving a request for an edit
operation (event G4), needs to decide whether that operation will be allowed, and to
respond with acceptance or rejection (events U1 or U0). That choice will depend on
the current locks being held on the Graphic. The details of this decision-making
process would be represented as an ADFD.
Object Oriented Modelling with Object Petri Nets 27
GUI
U3 U5 U7 U9 U11
User entity
G3 G4 G5 U0 U1 U2 U0 U1 U2 G3 D6 D7
Graphic Diagram
Fig. 18. Part of the Object Communication Model for the Editor
The Object Model of §6 and the Dynamic Model of §7 are now integrated into an
Object Petri Net model. The semantics of OPNs means that the resulting model can
be simulated (as a prototype) or analysed (for erroneous situations). While the class
attributes were not considered in §6, the Object Model would determine the data for
each class as follows:
Attribute = Identifier × Value
Event = GraphicId × UserId × EventKind
EditEvent = Event × Attribute
Lock = GraphicId × UserId × Action
Graphic = GraphicId × GraphicId × Attribute* × Lock*
Diagram = Graphic × GraphicId*
User = UserId × Lock* × …
28 C. Lakos
Thus, a (graphic) Attribute consists of an Identifier and a Value (both of which are
treated as primitive values). Examples of an Attribute could be a description suitable
for a data dictionary, a name, the colour and location of the graphic, etc. An Event
consists of a GraphicId and a UserId (to identify the relevant Graphic and User) and
an EventKind (to identify the particular event). Further data can be attached to
Events. Thus, an EditEvent is a subclass of an Event, with the addition of a new
Attribute value.
GraphicId g GraphicId g
UserId u UserId u
EventKind e EventKind e
Attribute a
Fig. 19. OPN classes for the Event and Edit-Event classes
can hold a null token. (A null token has no attached attribute information.) The
current state is indicated by the presence of a single null token in the appropriate
place. The initial state (of 20) is given by a token in place Idle. Each state transition
is mapped into a Petri Net transition with input and output arc to the preceding and
following state, respectively.
Graphic : Event*
GraphicId own
Event* Incoming
null* Idle = [[]] GraphicId diag
G0/G1
Attribute* attrs
G4
U0/U1
Lock* locks
G2
G1
null* RQedit
U2
null* Editing
The transition also has an input arc indicating the event which causes the transition,
and output arcs indicating the resultant generated events. (An alternative approach
would be to map each state transition from the lifecycle into two Petri Net transitions
and an intermediate place, the first transition responding to the input event and the
second generating the output events. As we shall see below, this is not necessary
since the Petri Net transitions will commonly be refined into a subnet.)
Since each object interacts by exchanging events, the most natural representation
of the object as a whole is as an OPN superplace which can accept and offer tokens
which are event notices. Thus, 20 shows part of the net for a Graphic. It inherits
from Event* to indicate that it exchanges tokens of type Event. The state components
for Graphic are shown on the right hand side and the event interaction on the left
hand side. Incoming events are buffered in the place Incoming, in line with the
Shlaer-Mellor approach of handling events asynchronously [31]. (The OPN
formalism also supports synchronous interaction, which might be appropriate for the
Shlaer-Mellor Object Access Model, which we do not consider. In fact, an OPN
super place could be written to handle some events synchronously, and some
asynchronously.)
In this case of Graphic, the transition from state Idle to state RQedit is triggered by
the reception of event G4, and results in the generation of events U0 or U1 and G0 or
G1. Similarly, a transition from state RQedit to state Editing is enabled on reception
30 C. Lakos
of event G1 and coincides with the generation of events U2 and G2. The net of 20
indicates the possible transitions and should be a recognisable representation of part
of the lifecyle of Fig. 16. Clearly, it does not show all the interactions in order not to
clutter the diagram. For example, the transitions from state RQedit to Idle, and from
Editing to Idle, do not show the consumption and generation of events.
Furthermore, it does not show the interaction between the transitions and the state
components (such as the locks), nor does the lifecyle of Fig. 16. As already noted,
this form of interaction is modelled by Shlaer and Mellor with Action Dataflow
Diagrams (ADFDs). In order to represent this logic in an OPN, the transitions
between states are expanded into super transitions. For example, the transition
between the states Idle and RQedit could be expanded into the net of Fig. 21.
m m
U0 m
m Event*
Uresp G0 Event* end
m
Lock* locks
m
Event* G1 Event* Gresp
start U1 m
m m m
In this case, the response could be determined by a simple transition, without the
need for a computation sequence, but we have chosen to expand it into a subnet so as
to demonstrate the capabilities of supertransitions. While not necessary to specify
this, we anticipate that this supertransition will be instantiated with arcs incident on
places idle, RQedit and Incoming. The firing mode will be determined by the G4
event (which includes a specification of the user and the graphic). The firing of the
supertransition commences with the deposit of this mode in place start. Then
transition reject or eject fires depending on whether there is already a conflicting lock
or not. Then the relevant transition (send rej or send acc) fires to generate events U0
and G0, or U1 and G1 respectively. Note that we do allow the subnet to include
component places which are exported and thus can be fused to other places in the
environment. However, the set of transitions to be fired is determined by the abstract
firing mode (as already discussed in §2.6).
It is worth emphasising that the mapping of Shlaer-Mellor work products into
OPNs naturally requires both superplaces and supertransitions. It is common in Petri
Net formalisms to supply only one of these mechanisms, but it is obviously beneficial
to have both. It is also worth noting that the more relaxed requirements for the
synchronisation of super transition actions (as discussed in §2.6) is appropriate here.
Object Oriented Modelling with Object Petri Nets 31
Event x touser
g
Graphic* graphics x x u User* users
Graphic g User u
x x
g u
tographic
Fig. 22. Interaction between graphics and users
Other forms of interaction between graphics and users are shown in 23. These
forms of interaction are not shown in the Shlaer-Mellor Object Communication
Diagram since they do not reflect a simple exchange of events. It shows that a user
can create a graphic at any time with transition newgraphic, and that a user may
delete a graphic with transition delgraphic, provided that the graphic accepts the event
(i.e. the appropriate locks are already in place). It shows that a user can be generated
at any time by transition newuser or can be deleted by transition deluser, provided
that the user accepts the event (i.e. it holds no outstanding locks). Note that the
transitions delgraphic and deluser both require synchronous event interaction (as
considered in §8) in order to constrain the acceptance of the event by a Graphic and
User, respectively. Shlaer and Mellor assume that such creation and deletion events
are handled by the environment, but how that is accomplished is not shown in their
work products.
32 C. Lakos
Similarly, Shlaer and Mellor do not explicitly consider how an instance can be
converted from one subclass to another, even though they speak of subtype migration
in relation to subtype lifecycles. In 23, we show how the expansion of a graphic is
achieved with the expandgraphic transition. A graphic g is extracted from place
graphics and an expand event x is received from it. A new diagram object d is
created with state information copied from the graphic g (as indicated by the guard
d = g).
Event x delgraphic
deluser
u x
g
Graphic* graphics x x u
Graphic g User u
x User* users
g
u
d u
expandgraphic x g
|d=g newgraphic newuser
This paper has informally introduced Object Petri Nets (OPNs) and identified the key
extensions over Coloured Petri Nets. The most distinctive feature is the unified class
hierarchy which allows both tokens and subnets to be defined by classes and
arbitrarily intermixed. This provides direct support for models with multiple levels of
activity, and gives the modeller great flexibility in the choice of modelling
components as active or passive. OPNs support the abstraction of both places and
transitions, leading to the notions of super places and super transitions. While the
emphasis of this paper has been informal, some of the theoretical issues pertinent to
the analysis of OPNs were discussed, particularly the implications of using object
identifiers. These simplify access to class instances, but require special handling if
reachability analysis is to be feasible. The features of OPNs were compared with
those provided by other concurrent object-oriented programming languages, and the
general conclusion was that OPNs provide a natural representation for many of the
proposals introduced by the Actor model.
A more extensive examination of the modelling capabilities of OPNs was
conducted by applying them to the case study of a cooperative editor for hierarchical
diagrams. The OPN model was derived by adapting existing object-oriented
modelling techniques. Firstly, a static object model was built using OMT notation
[30], since this provides explicit support for inheritance (as traditionally understood in
object-oriented languages). Secondly, a dynamic model was built using the Shlaer-
Mellor approach [31], since this provides a clean integration of the static and dynamic
models – there is a clean separation of the activity within an object (captured by
Object Oriented Modelling with Object Petri Nets 33
Acknowledgements
References
[1] 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).
[2] G.A. Agha Actors: A Model of Concurrent Computation in Distributed
Systems The MIT Press series in artificial intelligence, MIT Press (1986).
[3] 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).
[4] E. Battiston, A. Chizzoni, and F. de Cindio Inheritance and Concurrency in
CLOWN Proceedings of Workshop on Object-Oriented Programming and
Models of Concurrency, Torino, Italy (1995).
[5] 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).
[6] M.Y. Ben-Gershon and S.J. Goldsack Using inheritance to build extendable
synchronisation policies for concurrent and distributed systems Proceedings
of TOOLS Pacific 1995, pp 109-122, Melbourne, Australia, Prentice-Hall
(1995).
[7] G. Booch and J. Rumbaugh Unified Method for Object-Oriented Development
Version 0.8, Rational Software Corporation (1995).
[8] 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).
[9] 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).
[10] 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).
[11] 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).
[12] 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).
[13] C.D. Keen and C.A. Lakos Information Systems Modelling using LOOPN++,
an Object Petri Net Scheme Proceedings of 4th International Working
Object Oriented Modelling with Object Petri Nets 35
Introduction
The aim of this case study is to serve as a common example for formal specification
approaches that combine a formal model of concurrency (such as Petri nets) and the
object-oriented approach. You are expected to exercise your formalism of choice on
this problem, in order to demonstrate how it may deal with the specification of a
software of reasonable size.
It is desirable to highlight or emphasize the way that the structure of the problem
can be modelled in your formalism, and the way that reuse of components can be
incorporated.
each user may have his own customized view of the diagram under design, viewing
different parts of the drawing or examining it at a different level of detail.
A second key aspect of this problem is that the editor should cater for hierarchical
diagrams, i.e. components of the diagram can be exploded to reveal subcomponents.
A simple coordination protocol is proposed to control the interactions between the
various users:
• Users may join or leave the editing session at will, and may join with
different levels of editing priveleges. For example, a user may join the session
merely to view the diagram, or perhaps to edit it as well. (See below.) The
current members of the editing session ought to be visible to all, together with
their editing privileges.
• Graphical elements may be free or owned by a user. Different levels of
ownership should be supported, including ownership for deletion, ownership
for encapsulation, ownership for modification, and ownership for inspection.
(The ownership must be compatible with the user's editing privileges.)
• Ownership for deletion requires that no-one else has any ownership of the
component - not even for inspection.
• Ownership for encapsulation requires that only the owner can view the
internal details of the component - all other users can only view the top level
or interface to the component.
• Ownership for modification allows the user to modify attributes, but not to
delete the component.
• Ownership for inspection only allows the user to view the attributes.
• Only ownership for encapsulation can persist between editing sessions. (Note
that this ownership is tied to a particular user, not a particular workstation.)
All other ownership must be surrendered between sessions.
• Ownership for inspection is achieved simply by selecting the component.
• Other forms of ownership (and release) are achieved by an appropriate
command, having first selected the component.
• The level of ownership of a component is visible to all other users, as is the
identity of the owner.
• The creator of an element owns it for deletion until it is explicitly released.
1 Introduction / Motivation
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 38–72, 2001.
c Springer-Verlag Berlin Heidelberg 2001
Petri Nets, Active Objects and Generative Communication 39
Since a few years, there has been a considerable shift on the concept of a
software system. Formerly, a software system was “just” a program, possibly
consisting of several modules, which runs on a computer, and sometimes on a
parallel or distributed system. In the latter case, the programs use some kind
of communication libraries in order to allow the distributed or parallel entities
to cooperate, such as PVM, TCP, and so on. Some advanced object-oriented
approaches provide “transparent remote object invocation”, a means to hide
distribution of objects for system designers.
However, a number of new factors make this static view of a program un-
tenable. First, future software systems are bound to run on top of a network
system (either local or wide-area networks). Besides practical issues, such as the
reliability of the communication media and computer failure, a software devel-
opment paradigm should allow systems to be open. The openness of systems is
the most essential characteristic of future software systems. These are the main
requirements for covering open systems:
Second, the development of new applications is still too often started from
(almost) scratch. Object-oriented techniques offer a number of concepts to en-
hance reusability (such as inheritance and polymorphism).
Petri Nets. Petri nets are undoubtedly the most attractive formalism for mod-
elling concurrent systems. They have a well-founded, mathematical foundation,
which has been studied for many years now. Petri nets are above all a visual for-
malism, which makes them accessible for constructing and understanding com-
plex concurrent system models. Their main drawback is their lack of thorough
modularization techniques. Several extensions to standard Petri nets have been
proposed in order to deal with this deficiency. Still, these approaches basically
offer what “step-wise refinement” offered to structured programming. Though
these are of practical use for particular closed systems, they certainly cannot be
applied to tackle the advanced software systems as mentioned above. This can
40 T. Holvoet and P. Verbaeten
easily be shown by pointing out that the result of any Petri net model is one
overall net, modelling the concurrent behaviour of a concurrent system. During
the execution of the modelled software system, the Petri net cannot cope with
the addition of new, previously unknown entities.
2 Generative Communication
– in (parameters): retrieves an item from the data space matching the actual
and/or formal parameters of the operation, and removes it;
– rd (parameters): retrieves an item from the data space matching the actual
and/or formal parameters of the operation, but does not remove it;
42 T. Holvoet and P. Verbaeten
producer consumer
insert(<item>) retrieve(<item>)
data space
...
– out (parameters): puts the item, given through the parameters, into the
data space.
Linda-like communication is a very powerful tool, allowing a large degree of
flexibility by enforcing as few restrictions on communicators as possible. The
weaknesses of Linda are that there is no support for modularization of the soft-
ware system built around the shared data space, and that dynamic process cre-
ation is not considered in its first introduction[1]. While the latter has soon
been resolved by an additional operation, eval (which creates a new active en-
tity which blocks its originator until it delivers its results), the former has been
a highly researched subject. Objective Linda, which is presented in the next
section, provides by far the most elegant and natural solution to this problem.
3 Objective Linda
In [5], Objective Linda is proposed. Objective Linda is designed to meet the
open system requirements of a coordination model. Its primary contribution is
the support for multiple blackboard abstractions in a structured way. The data
space is replaced by a hierarchy of object spaces.
Objective Linda aims at enhancing Linda mainly in three ways:
– object matching: contrary to Linda, where matching of objects is based on
the contents of variables denoting the object’s state, object matching in
Objective Linda is based on object types and the predicates defined by the
corresponding type interfaces; the items that entities (agents) can put and
retrieve from object spaces are (passive) objects;
– non-blocking multi-set operations on object spaces: the operations defined on
the object spaces (mainly insertion and retrieval of objects) are annotated
with a time-out value; this is necessary to cope with system failures, which
are not unlikely in open distributed systems; moreover, the operations are
extended such that multi-sets of matching objects can be inserted in or
retrieved from object spaces atomically.
– multiple object spaces: having only one object space is not feasible mainly
for two reasons: scalability (for a huge set of agents, one global shared
Petri Nets, Active Objects and Generative Communication 43
agent 4 agent 5
object space 2
...
object space 1
Fig. 2. Object spaces are the communication forum for closely related agents. Agents
can be related to more than one object space.
The notation is based on a binding to the C++ language, and thus the interface
of the class Object Space is shown. In order to simplify code, default values are
assigned to the min, max, and timeout parameters causing Objective Linda’s
operations to behave in the default case analogous to the corresponding Linda
operations.
bool out ( Multiset ∗m , double timeout = inf time)
Tries to move the objects contained in m into the object space. Returns true
if the operation completed successfully; returns false if the operation could
not be completed within timeout seconds.
Multiset ∗in ( OIL Object ∗o , min = 1 , max = 1 , double timeout = inf time )
Tries to remove multiple objects o1 . . . on matching the template object o
from the object space and returns a multiset containing them if at least min
matching objects could be found within timeout seconds. In this case, the
multiset contains at most max objects, even if the object space contained
more. If min matching objects could not be found within timeout seconds,
the result has a NULL value.
Multiset ∗rd ( OIL Object ∗o , min = 1 , max = 1 , double timeout = inf time )
Tries to return clones of multiple objects o1 . . . on matching the template ob-
ject o and returns a multiset containing them if at least min matching objects
could be found within timeout seconds. In this case, the multiset contains at
most max objects, even if the object space contained more. If min matching
objects could not be found within timeout seconds, the result has a NULL
value.
bool eval ( Multiset ∗m , double timeout = inf time )
Tries to move the objects contained in m into the object space and starts
their activities. Returns true if the operation could be completed successfully;
returns false if the operation could not be completed within timeout seconds.
Object Space ∗attach ( OS Logical ∗o , double timeout = inf time)
Tries to get attached to an object space for which an OS Logical matching
o can be found in the current object space. Returns a valid reference to
the newly attached object space if a matching object space logical could be
found within timeout seconds; otherwise the result has a NULL value.
int inf matches
Returns a constant value which is interpreted as infinite number of matching
objects when provided as min or max parameter to in and rd.
double inf time
Returns a constant value which is interpreted as infinite delay when provided
as timeout parameter to out, in, rd, eval, and attach.
producer consumer
<item> <item>
Fig. 3. The producer/consumer model using Petri nets for specifying individual object
behaviour, and representing object spaces as places for relating nets of communicating
objects.
46 T. Holvoet and P. Verbaeten
where
• labeli and operj are strings over some alphabet Σ ;
• Tk ∈ T ;
• n, m, nl ∈ IN
∀i, j, k, l ∈ IN .
The data and operations part of object type T are referred to as T.Data
and T.Operations respectively; the data items and operations are denoted by
T.Data.labeli and T.Operations.operj respectively.
Petri Nets, Active Objects and Generative Communication 47
The formalism we propose, which is called OPN (Object Petri Net), is based
on Coloured Petri Nets (CPNs) as defined in [4], and we adopt time annota-
tion syntax from Time Petri nets (TPNs) [6] for introducing timeout exception
handling.
In Sections 4.2 through 4.2, we informally overview all features of OPN. We
show how these features are merely “syntactic sugar” for CPNs, and how they
translate to CPN features. The choice of CPNs as the basic Petri net formalism
is motivated by the fact that (1) CPNs are a well-known class of Petri nets
which also serve as a reference for ongoing efforts for defining a standard high-
level Petri net formalism [9], and (2) we intend to exploit existing CPN formal
analysis techniques as well as tools for analyzing OPNs.
We provide a formal definition for OPN in Section 4.2.
P1 P2 P1 P2 P1 P2
P3 P4 P3 P4 P3 P4
a. b. c.
initial situation "normal" occur timeout occur
P1 P2
Pl-Tr1
Tr1-normal Tr1-timeout
[timeout;timeout]
P3 P4
Object types to records and functions. An object type for OPN objects
consists of (1) a record structure for data items, and (2) a record structure
of functional operations. A translation of object types into terms of CPN ML
colour sets and functions results in two separate parts: a record structure for
the data items of the object type, and a set of (“global”) functions that take
data record structures as parameters. E.g. the object type T as presented on
page 46 translates to a record colour set, denoted RecordT ype(T ), and func-
tions oper1 , . . . , operm . The complete translation, however, of a functional
specification of objects as in Section 4.1 into plain CPN ML record colour
sets and functions, comes down to a small parser, the details of which are not
relevant in this document. We therefore restrict ourselves to provide transla-
tion for the main aspects of object type definitions in order to convince the
reader that such is possible.
– RecordT ype(T ) = record
typename : String(T ) ∗
label1 : RecordT ype(T1 ) ∗
...
labeln : RecordT ype(Tn );
P1 Tr1 P2
{E}5
3
P1 Tr1 P2
m
p
(size(m) <= 5 ) and
(size(m) >= 3 ) and
(cf ( ext_col match(E,m) , true ) = size(m))
var m : Multiset(T);
Named Places. The last feature we introduce is named places. The idea
is the following. A named place in an OPN is a place which is parametrized
through a variable representing the places name. The content of this variable is
the identifier of the actual place that the named place represents. As a result
of transition occurrings, the content of these variables may be changed, which
allows another actual place to be represented by the named place.
The intention is to model object space places as named places. Since within
one agent an object space is represented by variables containing a “reference”
to an actual object space, which can be changed at run time (e.g. by an attach
operation), this kind of flexibility is necessary.
Graphically, named places are represented by a small oval, representing the
container for the place name, within an oval representing the named place itself.
Transitions that require to read or modify name variables of named places are
adjacent to the inner ovals, as shown in Figure 8.a.
Named places allow a hidden form of dynamicity in the net structure. Chang-
ing the content of a named place variable means changing the actual input or
output place for transitions that are adjacent to the named place. Hence, corre-
sponding arcs are no longer a relation between places and transitions, but rather
a relation between place variables and transitions.
Named places may seem to be a subversive feature, breaking the soundness
of the OPN formalism. Yet again there is a simple high-level net equivalent. The
54 T. Holvoet and P. Verbaeten
Pl1 Pl2
plid2
plid1
NamedPlaces
pl1 plid1 P1 plid1 P1
Tr1
Tr1
plid1
pl2
x < plid2 ; x >
P2 P2
a. b.
{new PlaceId} id
pl
anyid id
new
... ...
a. b.
ence to the named place as its value. Second, it is used to protect an agent
from inconsistencies due to concurrent (re)assignments to the named place
variables.
2. Then, each annotation of an arc that is connected to a named place is altered
such that each expression denoting a token x is replaced by an expression
denoting a token <place-id ;x>, where place-id is an expression yielding an
identifier of a place, e.g. the variable pl1 . Finally, each transition that is
adjacent to a named place and/or manipulates one or more place variables
is connected through a bidirectional arc with the new places representing
the place variables (such as Pl1 and Pl2 in the example).
Definition of OPNs. OPNs are formally defined as follows. Remark that for each
element (sets, mappings) of an OPN, we use the shorthand El instead of ElOP N
if no confusion is possible (i.e. P instead of POP N , G instead of GOP N , and so
on).
– E denotes the set of all expressions, E(T) the set of all expressions E ∈ E
such that T ype(E) = T ;
– Arc(E) the set of multiset expressions as presented in Section 4.2.
(i) (ii) (iii) The places, transitions and arcs are described by three sets,
P , T and F , which are demanded to be finite and pairwise disjoint. The set of
arcs, F , is subdivided into “normal” arcs (DF ) and non-deterministic arcs (N F ).
Petri Nets, Active Objects and Generative Communication 57
(iv) N P F represents the set of arcs adjacent to named places and modelling
place name related manipulations.
(v) T is the set of object types, i.e. T = PT ∪ OT , as previously defined
in Section 4.1.
(vi) The initialization function I maps each place p into an expression which
is a multiset of tokens. The expression is not allowed to contain any variables.
(vii) The guard function G maps each transition t into a predicate, i.e. an
expression yielding a boolean.
(viii) The code function C associates an expression with each transition.
The expression is a function representing the piece of code that is executed on
transition occurrence.
(ix) (x) The arc expression functions associate an expression to each arc
in an OPN.
(xi) The timeout function maps each transition into a natural number, de-
noting the timeout value for timeout exception.
Dynamic behaviour of OPNs. With the above definition of the static structure of
OPNs, we can now formally define their dynamic behaviour. However, we do not
consider time aspects in defining the dynamic behaviour since it adds substantial
complexity to the definitions without a equally useful return, especially as we
refrain from using timeout exception for any of the examples we propose further
in this work. The work presented in [10] includes definitions of a time-based Petri
net formalism which can be imitated for defining OPN dynamic behaviour with
timeouts.
We first define an auxiliary notation:
– ∀t ∈ T : V ar(t) = {v | v ∈ G(T ) or ∃ a ∈ F (t) : v ∈ V ar(E(a))}
When a step is enabled, it may occur. When a step occurs, tokens are removed
from the input places and added to the output places of the occurring transitions,
based on the arc expressions, evaluated for the occurrence bindings.
+ C(t)(AAE(t, p) < b >))
(t,b)∈Y
where C(t)(AAE(t, p) < b >) is the result of applying the transition code segment
to the input tokens in the token binding b.
Thus far, we have presented Objective Linda for modelling concurrent applica-
tions, a formal functional model for passive sequential objects, and a high-level
Petri net formalism with object-oriented extensions in Section 4.2. In the follow-
ing, we employ these formal models for providing a formal basics for Objective
Linda.
destroy : T → T
match This operation has a default implementation body, yielding the boole-
an value true. This operation can be redefined in order to specialize
matching between objects.
match : T → Boolean
Agents. Agent classes are formally represented by an OPN Petri net, called the
agent net. Similar to the early (informal) introduction of a Petri net specification
for internal agent behaviour, the Petri net describes internal concurrency, syn-
chronization and causality between internal computations. The computational
capacities of agents coincide with the expressiveness of functional expressions on
passive objects.
a. b. c.
d. e.
Similarly, templates for rd and out are presented in Figure 10.b and 10.c. The
rd transition is a timeout transition with a non-deterministic arc with multiset
annotation, and with a named input place, the object space place on which the
operation is invoked. If the transition is enabled, it can occur if appropriate
objects can be retrieved from the object space. If it occurs, such objects are
withdrawn from the object space place and replaced immediately.
The out transition is a timeout transition with an output arc with (explicitly
enumerated) multiset annotation, and with a named output place, the object
space place on which the operation is invoked. Since there is no non-deterministic
input arc, the possibility to occur coincides with enabledness for this operation:
if the transition is enabled, it either occurs normally, within timeout time, or the
timeout exception mechanism makes it occur if it has not occurred after being
enabled for timeout time.
The template for eval is presented in Fig. 10.d. If the transition occurs within
the time bound, a multiset m of agents is shifted towards the AgentSpace place,
representing the activation of new agents. In this case, every new agent A(o) ∈ m
is assigned o as its initial context object space. The bidirectional arc between
the transition and the name variable of objsp denotes that the PlaceId token of
the object space is used (withdrawn and replaced) for assigning a context object
space to the newly created agents.
The attach operation (Fig. 10.e) is a rd operation with a multiset containing a
single object o of a specific type, OS Logical. Additionally, there is an output arc
to the name variable of the object space to attach to where the value of attach(o)
is stored. The function attach ∈ [OS Logical → PlaceId], returns the PlaceId of
the object space to which the OS Logical matching o refers. Fig. 11 illustrates
Petri Nets, Active Objects and Generative Communication 61
objsp2 objsp1
Pi,1 Pi,n Pi,1 Pi,n
... ...
attach(o)
NamedPlaces
objsp1 objsp1
1 objsp2
{o}
1
attach <objsp1 ; attach
match(o)>
attach(o) [timeout]
objsp2 [timeout]
... ...
Po,1 Po,m Pto
Po,1 Po,m Pto
a. b.
Producer Consumer
Waiting Waiting
i i
Ready Ready
an object space. In the model this is represented by the transition Startup which
delivers two tokens to the AgentSpace when occurring.
The descriptions of the Producer and the Consumer agents yield no surprises.
A Producer agent repeatedly produces new items (an internal action, represented
by the transition produce) and outs them into its context object space. A Con-
sumer agent repeatedly retrieves items from its context object space and con-
sumes them (transition Consume). The time-out value of the Objective Linda
operations is set to infinity (∞), and therefore the corresponding time-out an-
notated arcs can be left out.
StartUp
Startup
os eval
context
{ Producer(os) ;
Consumer(os) }
InitNewAgent
<agent_id ; context>
Context
ObjectSpace
Waiting
<agent_id ; context>
<context ; i:Item>
<agent_id> <agent_id>
Ready
AgentSpace
Fig. 14. The net describing Producer agents; the result of the first phase.
AgentSpace
<CreationRequestStartUp ; cont>
IdSpace
StartUp
cont InitNewAgentStartUp
{ <CreationRequestConsumer ; context> ,
<CreationRequestProducer ; context> }
<agent_id>
<agent_id ; cont>
<agent_id> Startup
StartUpContext eval
<agent_id ; context>
a fork. The same holds for his right-hand side. When a philosopher holds a fork
e.g. at his left-hand side, and his left neighbour asks for a fork, he must give it.
The same holds for his right-hand side.
Philosophers may introduce a new philosopher. A new philosopher brings a
plate and has one fork in his left hand. A philosopher can only introduce another
philosopher at his left-hand side.
A philosopher may leave the table, either based on an autonomous decision,
or because one of his neighbours told him to do so. A philosopher can only leave
when he holds a fork in his left hand.
Philosopher
swallow chew
asked for right fork asked for left fork
mouth empty
get right fork mouth full get left fork
take a bite
Philosophers need to communicate: they need to ask each others forks, ex-
change forks, and so on. Hence, using the Objective Linda object model, we need
to describe what object spaces are needed. Since object spaces are the forums for
inter-object communication, and since each pair of neighbour philosophers com-
municate forks, we introduce one object space between two neighbours. This
results in a “LeftObjectSpace”, OS-LN , and a “RightObjectSpace”, OS-RN
(see Figure 17). Since in general, Objective Linda active objects know of two
default object spaces, the self and the context object spaces, we note that, in
this situation, OS-RN serves as the context, and OS-LN serves as the self object
space.
To illustrate how the object spaces are used as common space for communi-
cation, Figure 18 shows a configuration of philosophers.
Philosopher
swallow chew
asked for right fork asked for left fork
mouth empty
get right fork mouth full get left fork
take a bite
<RequestFork> <RequestFork>
<Fork> <Fork>
<Fork> <Fork>
OS-RN OS-LN
Fig. 17. Philosopher’s behaviour taking communication with other philosophers into
account.
Philo1
OS-RN OS-LN
OS-RN OS-LN
OS-LN OS-RN
Philo3
Fig. 18. A configuration of four philosophers with their respective object spaces.
68 T. Holvoet and P. Verbaeten
A philosopher can leave (either because one of his neighbours told him so, or
he decided to leave autonomously). The result is that a message is dropped into
the object space shared by the philosopher and his left neighbour, telling him
he is leaving, and sending along the name of the philosopher’s right neighbour’s
object space (which is to become the right neighbour object space of his left
neighbour).
A philosopher who notices that his right neighbour is leaving will modify
his right neighbour object space as soon as this right neighbour’s fork has been
retrieved from the right neighbour’s object space at this moment.
5.4 Evaluation
– local control: One of the basic characteristics of the Objective Linda ap-
proach is the autonomicity of the agents. This is not harmed by introducing
a Petri net as the specification of the agents behaviour and as the execution
control engine. Each agent controls its own transitions, and hence retains
the control over its actions and its decisions.
– dynamic instantiation: Agents may join and leave the system at run time.
A restriction of this sort can only induced by the application, by imposing
that only a finite set of forks be available to the table.
– dynamic binding, “the partner of communication is defined when the com-
munication occurs, not by the model”: Generative communication decouples
communicating objects. This and the fact that object spaces, the forums of
inter-object communication, can be passed on between objects allows dy-
namic partnership of communication.
– inheritance and polymorphism: This feature could not be demonstrated
with the application. However, both passive and active objects are considered
to have types, which can be related through inheritance or subtyping, and
polymorphism is possible of course. Ongoing research focuses on types of
<FoundYou>
B
eval
init-done (intro new phil) <Philosopher(OS-LN)>
init
tell right to leave <ReqRightLeave>
lacking right fork lacking left fork
C
give right fork give left fork right told to leave decide to leave
<OS-LN : OS-LOGICAL>
<FoundYou> if (log <> OS-LN) <Fork>
<Fork> OS-RN := log <Fork> <ReqRightLeave>
<Fork> <ReqLeftLeave>
<log : OS-LOGICAL>
<I_Left; OS_LN : OS_LOGICAL>
OS-RN OS-LN ForkHeap AgentSpace
70
Petri Nets, Active Objects and Generative Communication 71
active objects in the Objective Linda. The Petri net behaviour representation
plays a major role in defining types and subtypes.
6 Conclusion
This paper presents ongoing research in combining concurrent object-orientation,
coordination through generative communication and Petri nets. The advantages
of (in particular, concurrent) object-orientation are known (reusability, flexi-
bility, modular development, and so on). The coordination model of Objective
Linda is well suited for coordination problems in open systems. Petri nets pro-
vide a sound basics not only for visually representing complex entities, but also
for performing formal analysis on isolated objects, sets of communicating objects
and entire systems.
The combination of agents, generative communication and Petri nets results
in a high-level, visual, formal technique for designing, implementing and analyz-
ing complex and open systems. The ability to translate system models onto well
known net models is important. It allows to rephrase research results from the
Petri net community in terms of agents and agent configurations, reuse analysis
techniques and exploit existing tools.
In [2], the principles of PINOLI were introduced, however, without a thorough
formal basics. In this paper, we provide a formal definition of a high-level Petri
net formalism, called OPN which is used for providing semantics for Objective
Linda coordination operations.
Introducing nets into active objects also yields the possibility to tackle cer-
tain type-theoretical issues. A formal definition of types of agents and a related
formal notion of subtyping has been defined based on observable behaviour of
agents in [2]. Based on the same notion, we can define types of particular com-
ponents, namely configurations of cooperating agents. This allows us to define
“plug-compatibility” of components, meaning that we can formally define when a
component (a set of cooperating agents which become accessible to other compo-
nents to one of more public object spaces) may be replaced by another component
without affecting the behaviour of the overall system. This is an important step
in dealing with component-oriented development for software in open systems.
72 T. Holvoet and P. Verbaeten
References
1. D. Gelernter. Generative Communication in Linda. ACM Transactions on Pro-
gramming Languages and Systems, 7(1):80–112, 1985.
2. T. Holvoet and T. Kielmann. Behavior Specification of Active Objects in Open
Generative Communication Environments. In Proc. HICSS30, Sw Track, pages
349–358, Hawaii, 1997. IEEE Computer Society Press.
3. K. Jensen. Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical
Use. Springer, 1992.
4. Kurt Jensen. Coloured Petri Nets: A High Level Language for System Design and
Analysis. In G. Rozenberg, editor, Advances in Petri Nets, number 483 in Lecture
Notes in Computer Science, pages 342–416. Springer, 1990.
5. Thilo Kielmann. Designing a Coordination Model for Open Systems. In P. Cian-
carini and C. Hankin, editors, Coordination Languages and Models, number 1061 in
Lecture Notes in Computer Science, pages 267 – 284, Cesena, Italy, 1996. Springer.
Proc. COORDINATION’96.
6. P. Merlin. A Study of Recoverability of Computing Systems. PhD dissertation,
Dept. of Information and Computer Science, University of California, Irvine, Cal-
ifornia, 1974.
7. Y. Shoham. Agent-oriented Programming. Artificial Intelligence, pages 51–92,
1993.
8. C. Sibertin-Blanc. Cooperative Nets. In Proceedings of the 15th International
Conference on Application and Theory of Petri Nets, Zaragoza, Spain, LNCS 815,
June 1994.
9. SO/IEC JTC1/SC7/WG11. High-Level Petri Net Standard, August 1997. Working
draft.
10. W. M. P. van der Aalst, K. M. van Hee, and P. A. C. Verkoulen. Interval Timed
Coloured Petri Nets and their Analysis. In Advances in Petri Nets ’93, number
691 in Lecture Notes in Computer Science, pages 453–472. Springer-Verlag, Berlin,
1993.
11. P. Wegner and S.B.Zdonik. Inheritance as an Incremental Modification 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.
Object-Oriented Nets with
Algebraic Specifications:
The CO-OPN/2 Formalism
Abstract. This paper presents and formally defines the CO-OPN/2 for-
malism (Concurrent Object-Oriented Petri Net) which is devised for
the specification of large concurrent systems. We introduce the basic
principles of the formalism, and describe how some aspects of object-
orientation – such as the notions of class/object, object reference, inher-
itance and subtyping – are taken into account. In CO-OPN/2, classes
(considered as templates) are described by means of algebraic nets in
which places play the role of attributes, and methods are external pa-
rameterized transitions. A semantic extension for the management of
the object references is defined. Inheritance and subtyping are clearly
distinguished. Interaction between objects consists of synchronizations.
Synchronization expressions are provided which allow the designer to
select interaction policies between the partners. We also provide a step
semantics which expresses the true concurrency of the object behaviors.
Finally, in order to illustrate the modeling capabilities of our formal-
ism, we adopted a case study on groupware or, more specifically, on a
cooperative editor of hierarchical diagrams.
1 Introduction
The idea of modeling systems by combining Petri nets and data structures
emerged around 1985. Since then, several researches have introduced some no-
tions peculiar to object-orientation.
In line with these research works, the CO-OPN (Concurrent Object-Oriented
Petri Nets) [8] approach and its tools have been devised so as to offer an ad-
equate framework for the specification and design of large concurrent systems.
Recently, a new version of CO-OPN has been developed in order to enrich and
overcome some limitations of this object-based formalism. Notions of class, in-
heritance as well as subtyping have therefore been introduced. This version,
called CO-OPN/2 [4], is based upon two underlying formalisms: order-sorted
This work has been sponsored partially by the Esprit Long Term Research Project
20072 “Design for Validation” (DeVa) with the financial support of the OFES (Of-
fice Fédéral de l’Éducation et de la Science), and by the Swiss National Science
Foundation project 20.47030.96 “Formal Methods for Concurrent Systems”.
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 73–130, 2001.
c Springer-Verlag Berlin Heidelberg 2001
74 O. Biberstein, D. Buchs, and N. Guelfi
algebras [10], for data structure matters, and the algebraic nets [16], for the
operational and concurrent aspects.
In CO-OPN/2, classes are object templates described by a special kind of al-
gebraic nets, while objects are net instances of these classes. A specific aspect of
CO-OPN/2 is that it introduces subtyping and distinguishes it from inheritance.
Interaction between objects is realized by using “synchronization expressions”, a
concept more general than the classical transition fusion of Petri nets. At the se-
mantics level, transition systems are used to give a step semantics to CO-OPN/2
specifications which takes into account both inter- and intra-object concurrency.
The transition systems are partially defined using SOS like inference rules and
a semantic mechanism is introduced in order to manage the object identifiers.
Close to our work, let us mention [13,17,3], three approaches based on high
level Petri nets. The reader interested in a finer description of these formalisms
can either consult this book and the associated workshop proceedings or have a
look at the study we propose in [11]. The latter presents a set of classification
criteria and then situates each approach according to these criteria.
CO-OPN/2 is a specification formalism [7] designed for the development of
complex systems from a software engineering point of view. Our approach aims
at easing specification, design, implementation, and verification phases of system
development, rather than focus on analysis aspects.
The organization of this paper is the following. Section 2 presents an informal
introduction of the basic concepts of CO-OPN/2. Section 3 illustrates, by means
of a simple example, various notions of the formalism such as the notions of
object/class, object reference, inheritance, and subtyping. Then, Section 4 and 5
describe, respectively, the syntactic and the semantic aspects of the formalism.
Finally, Section 6 deals with a common case study on groupware, namely a
cooperative editor of hierarchical diagrams.
2 CO-OPN/2 Principles
In order to provide a progressive presentation of CO-OPN/2 and to allow the
reader to easily compare CO-OPN/2 with other approaches, we briefly give, in
this section, the most relevant characteristics of the formalism.
Object and Class. An object is considered as an independent entity composed
of an internal state and which provides some services to the exterior. The only
way to interact with an object is to ask one of its services; the internal state
is then protected against uncontrolled accesses. Our point of view is that this
protection mechanism, known as encapsulation, is an essential feature of object-
orientation and there should be no way of violating it.
CO-OPN/2 defines an object as being an encapsulated algebraic net in which
the places compose the internal state and the transitions model the concurrent
events of the object. A place consists of a multi-set of algebraic values. The
transitions are divided into two groups: the parameterized transitions, also called
the methods, and the internal transitions. The former correspond to the services
provided to the outside, while the latter compose the internal behaviors of an
The CO-OPN/2 Formalism 75
object. Contrary to the methods, the internal transitions are invisible to the
exterior world and may be considered as being spontaneous events.
An important characteristic of the systems we want to consider is their po-
tential dynamic evolution in terms of the number of objects they may include. In
order to describe similar dynamic evolving systems, the objects are grouped into
classes. A class describes all the components of a set of objects and is considered
as an object template. Thus, all the objects of one class have the same structure.
Object Interaction. In our approach, the interaction with an object is syn-
chronous, although asynchronous communications may be simulated. Thus,
when an object requires a service, it asks to be synchronized with the method
(parameterized transition) of the object provider. The synchronization policy is
expressed by means of a synchronization expression, which may involve many
partners joined by three synchronization operators (one for simultaneity, one for
sequence, and one for alternative or non-determinism). For example, an object
may simultaneously request two different services from two different partners,
followed by a service request from a third object.
Concurrency. Intuitively, each object possesses its own behavior and concur-
rently evolves with the others. The Petri net model naturally introduces both
inter-object and intra-object concurrency into CO-OPN/2 because the objects
are not restricted to sequential processes.
The step semantics of CO-OPN/2 allows for the expression of true concur-
rency, which is not the case of interleaving semantics. A set of method calls
can be concurrently performed on the same object. Nevertheless, the purpose
of CO-OPN/2 consists of capturing the abstract concurrent behavior of each
modeled entity, with the concurrency granularity not being found in the ob-
jects, but rather in the invocations of the methods. A set of method calls can be
concurrently performed on the same object.
Object Identity. Within the CO-OPN/2 framework, each class instance has
an identity, which is also called an object identifier, that may be used as a
reference. Moreover, a type is explicitly associated with each class. Thus, each
object identifier belongs to at least one type. An object identifier order-sorted
algebra is constructed in order to reflect the subtyping relation that is established
between the classes types, i.e. two carrier sets of object identifiers are related by
inclusion if, and only if, the two corresponding types are related by subtyping.
Since object identifiers are algebraic values, it is possible to define data struc-
tures that are built upon object identifiers, e.g. a stack or a queue of object
identifiers. Obviously, the places of algebraic nets may contain object identifiers.
Inheritance and Subtyping. We believe that inheritance and subtyping are
two different notions used for two different purposes. Inheritance is considered
as being a syntactic mechanism which frees the specifier from the necessity of
developing classes from scratch and mainly serves in the re-use of parts of existing
specifications. A class may inherit all the features of another and may also add
some services, or change the description of some already defined services.
Our subtyping relationship is based upon the strong version of the substi-
tutability principle [2,14]. This principle implies that, in any context, any class
76 O. Biberstein, D. Buchs, and N. Guelfi
instance of a type may be substituted for a class instance of its supertype, while
the behavior of the whole system remains unchanged. In other words, the in-
stances of the subtype have a strong semantic conformance relationship with
the supertype definition. This conformance relationship is based, in CO-OPN/2,
upon the bisimulation between the semantics of supertype and the semantics the
subtype restricted to the behavior of the supertype.
Both inheritance and subtyping relationships must be explicitly given, but
the respective hierarchies generated by these relationships do not necessarily
coincide. Identifying both inheritance and subtyping hierarchies leads to several
limitations as stated by Snyder [18] and America [1].
packaging packaging
producer unit
conveyor belt
Figure 2 depicts the two kinds of packagings produced by the factory. The
regular packagings have a given number of square holes filled with pralines, while
the deluxe packagings have some more round holes for truffles.
The decomposition of the example into abstract data types and classes is
quite straightforward. In the CO-OPN/2 approach based on the object-oriented
paradigm, it appears that the producer, the consumer, and the conveyor-belt
can be naturally considered as objects and not as data structures. The same
reasoning may be applied to the packagings. However, the chocolates are still
The CO-OPN/2 Formalism 77
store
filling
produce take
..
put get
full-praline full-praline
fill create-packaging fill
the-conveyor-belt
box box’
Note that Expr 1 and Expr 2 may not be of the same sort. An optional condition
Cond which determines the context in which an axiom holds true can be added.
Of course, variables are available whenever defined under the where field. Since
algebraic specifications are divided into modules, a module may need some com-
ponents from another module. This kind of dependency is expressed by the Use
field, followed by the list of all the required modules.
The ADT module in Specification 1 describes the two kinds of chocolate and
illustrates a simple use of subsorting. The chocolates are arranged according
three sorts in a subsorting relation. Thus, a value of the supersort chocolate
represents either a praline or a truffle.
Genericity is another way of making specifications more concise without sac-
rificing their legibility. Generic abstract data types are data structures that de-
pend on some formal parameter modules. The header of a generic data type must
begin with the Generic keyword, followed by the module name and the list of its
1
The Courier bold face words correspond to the reserved words of the language. These
reserved words are not case sensitive and some words can be singular or plural.
The CO-OPN/2 Formalism 79
✞
ADT Chocolate;
Interface
Sorts chocolate, praline, truffle;
Subsort
praline < chocolate, truffle < chocolate;
Generators
P : praline; T : truffle;
End Chocolate;
✝ ✆
Spec. 1. Both the Kinds of Chocolate.
formal parameter modules. The generic first-in-first-out data type which is used
by the conveyor belt is illustrated in Specification 2. Module Elem corresponds
to the formal parameter module, which is replaced by an actual module during
the instantiation process. It must be defined as a Parameter module.
One way of using partial operations, such as extract and first, consists
of partitioning the domains and associating a sort ne-fifo for the non-empty
fifos and a “larger” one fifo for the empty or non-empty fifos. In this way, both
operations are partial across the entire domain, but total on their subdomains.
✞
Generic ADT Fifo(Elem); Parameter ADT Elem;
Interface Interface
Use Natural; Sort elem;
Sorts ne-fifo, fifo; End Elem;
Subsort ne-fifo < fifo;
Generators
[] : -> fifo;
insert _ _ : elem fifo -> ne-fifo;
Operations
first _ : ne-fifo -> elem;
extract _ : ne-fifo -> fifo;
size _ : fifo -> natural;
Body
Axioms
first (insert e []) = e;
first (insert e f) = first f;
extract (insert e []) = [];
extract (insert e f) = insert (e extract f);
size [] = 0;
size (insert e f) = 1 + (size f);
where e : elem; f : ne-fifo;
End Fifo;
✝ ✆
Spec. 2. A Generic First-In-First-Out Data Type and its Formal Parameter.
3.2 Classes
the outside. The state and the behavioral aspects of the class lie in the Body
section.
The state of the class instances is represented by a collection of places that
contains multi-set of algebraic values described by order-sorted algebraic speci-
fications. The object state can be modified by means of two kinds of events: the
methods (which are parameterized and correspond to the external object stim-
uli) and the internal transitions (which are concealed in the body and represent
the spontaneous object reactions). Sometimes we call these two types of events:
the observable events (methods) and the invisible events (internal transitions).
Cooperation between objects is accomplished by a synchronization mecha-
nism. That is to say, any object event can request a synchronization with meth-
ods of one or a group of partners. Moreover, the synchronization policy can be
chosen by means of a synchronization expression for which three synchronization
operators are provided: ‘//’ for simultaneity, ‘..’ for sequence, and ‘+’ for alter-
native. The event’s effects, data-flow and synchronization requests, are described
by means of behavioral axioms which are established as follows:
Event [ with Sync ] :: [ Cond => ] Pre -> Post
in which
• Event is an internal transition or a method name along with its parameters;
• Sync is an optional synchronization expression describing which methods of
which partners are involved and how they interact with each other;
• Cond is an optional condition on the algebraic values of the formula which
must be satisfied so that the event can occur;
• Pre and Post correspond, respectively, to the pre- and post-conditions of
the common Petri nets, i.e. they represent what is consumed and what is
produced at the various places within the net.
An event that requires a synchronization with some partners can occur if and
only if the various methods involved in the synchronization can occur. In other
words, a synchronization request abstracts the behavior of all the methods of its
partners according to the synchronization operators. Note that a method is not
a function (no value is returned) and can be regarded as a predicate. Neverthe-
less, formal and effective parameters are unified during a synchronization and
informations can therefore be exchanged.
Packaging class. The places are drawn as circles and the data-flow corresponds
to the labeled plain arrows. Explanations about the right side of the figure and
the meaning of the arrows are given below.
full-praline
fill P 0
n
0
n-1
Packaging
full-praline full-truffle
#square-holes
fill P 0 0 fill T
n n
0 0
n-1 n-1
create-packaging DeluxePackaging
#square-holes #round-holes
create-packaging
Inheritance and Subtyping. The factory deals with two kinds of packagings,
regular, as detailed above, and deluxe. Deluxe packagings are very similar to
regular packagings, with the exception that they are bigger and contain both
kinds of chocolate. Since the deluxe packaging shares some ingredients with the
regular boxes, the new class associated with the deluxe packagings does not have
to be developed from scratch and inheritance may be used.
Remember that, on the one hand, a class is considered as a template and,
on the other hand, inheritance is viewed as a mechanism for design convenience.
Moreover, inheritance which can be used for three purposes is clearly separated
from the notion of subtyping.
CO-OPN/2 provides an Inherit section followed by the class modules that
the current class inherits. In this section three fields can be specified:
behaviors of the superclass Packaging are identical2 .This means that, in any
context, an instance of the DeluxePackaging class can be substituted for an
instance of the Packaging class. In other words, here, the subtype hierarchy
and the inheritance hierarchy are the same.
the carrier sets of the object identifier algebra reflects the subtyping relation
between the types; i.e. two types are in a subtyping relation if and only if the
corresponding carrier sets are related by inclusion. Thus, for example, saying that
a variable has a given type, means that the variable represents an object identifier
belonging to the carrier set (or any included carrier set) associated to the type
of the variable (or to any subtype). More informations about the structure and
the operations of the object identifier algebra are given in Section 5.1.
The modeling of the conveyor-belt based on the above data structure is given
in Specification 7. We observe that the conveyor-belt device is very similar to the
heap. However, now the belt place consists of a multi-set of fifos of packagings
initialized with an empty fifo denoted ‘[]’ (c.f. the Initial field). Consequently,
it has been necessary to define both the put and get methods differently.
The CO-OPN/2 Formalism 85
✞
Class ConveyorBelt;
Interface
Use Packaging;
Type conveyor-belt;
Object the-conveyor-belt;
Methods put _ , get _ : packaging; put box get (first f’)
Body f f’
Use FifoPackaging;
Place belt _ : fifo-packaging; insert box f extract f’
Initial belt [];
Axioms
belt
put box ::
belt f -> belt (insert box f);
get (first f’) :: ConveyorBelt
belt f’ -> belt (extract f’);
where f : fifo-packaging;
f’ : ne-fifo-packaging;
box : packaging;
End ConveyorBelt;
✝ ✆
Spec. 7. The Conveyor-Belt Modeling.
Consequently, the two types have identical behaviors when the differences
between the successive put and get operations are lower than the limit of the
conveyor. However, although inheritance has been used to specify the new lim-
ited conveyor-belt, the limited-conveyor-belt type is not a subtype of the
conveyor-belt type, because many behaviors of the previous conveyor-belt
cannot occur in the limited conveyor-belt. This example shows the typical con-
flict between inheritance and subtyping when enrichment inheritance modifies
the semantics of the original class.
Object Interaction. The two last classes of the example concern the packag-
ing producer and the packaging unit. Specification 9 provides the modeling of
the packaging producer. We observe that the axiom of the produce method in
the PackagingProducer class expresses the synchronization request in sequence
(synchronization operator ‘..’) with two methods of two distinct objects.
The term box.create-packaging asks for the synchronization with the dy-
namic creation and the initialization of a packaging object identified by the
free variable box, while the term the-conveyor-belt.put box asks for the
synchronization with the method put of the static conveyor-belt object. As a
result, a new packaging is created and initialized first, and then the packaging
is “transmitted” to the conveyor-belt. Since the box variable is free, the axiom
is satisfied for any value of box. This allows the dynamic creation of regular
packagings as well as deluxe packagings.
✞
Class PackagingProducer;
Interface
Use Packaging;
Type packaging-producer;
Object the-packaging-producer;
Method
produce;
Body
Axiom
produce with
box.create-packaging .. the-conveyor-belt.put box :: -> ;
where box : packaging;
End PackagingProducer;
✝ ✆
Spec. 9. Modeling of the Packaging Producer.
The packaging unit is the most complex device of our example. The textual
representation and an outline of packaging unit’s modeling are given in Specifi-
cation 10 and in Figure 5.
In the PackagingUnit class, three events ask for a synchronization. The
method take is quite simple: it removes a packaging from the conveyor-belt and
stores it on the work-bench. The purpose of the filling transition is to fill the
empty packagings which lies of the work-bench. The synchronization request of
this internal transition consists of filling one corresponding empty hole of the
current packaging. Note that the axiom which defines the filling event takes
The CO-OPN/2 Formalism 87
✞
Class PackagingUnit;
Interface
Type packaging-unit;
Method take;
Body
Use Chocolate, ConveyorBelt, Packaging, DeluxePackaging;
Transitions
filling,
store;
Place
work-bench _ : packaging;
Axioms
take with the-conveyor-belt.get box ::
-> work-bench box;
filling with box.fill choc;
store with box.full-praline ::
(sub-packaging-deluxe-packaging box) = box’ =>
work-bench box -> ;
store with box’.full-praline // box’.full-truffle ::
work-bench box’ -> ;
where box : packaging; box’ : deluxe-packaging;
choc : chocolate;
End PackagingUnit;
✝ ✆
Spec. 10. Modeling of the Packaging Unit
advantage, on the one hand, of subsorting for the chocolates (choc) and, on the
other hand, of subtyping for the packagings (box).
The store internal transition is a little bit more sophisticated. This event
merely removes the packagings that are full from the work-bench. For this, it
is mandatory to distinguish between the regular packagings and the deluxe
ones because we modeled the fullness of the regular packagings by means of
the full-praline method and the fullness of the deluxe packagings by means
of the full-praline and full-truffle methods. In fact, the two axioms for
the store event are mutually exclusive. However, the following condition requires
some explanations:
PackagingUnit
work-bench box’
box.full-praline //
box’.full-praline box’.full-truffle
the-conveyor-belt.get box
box.fill choc
The second axiom concerning the store event does not require such a condition
because the use of a variable box’ of type deluxe-packaging makes the selec-
tion of the packagings of type deluxe-packaging in a straightforward manner.
Finally, since both axioms of the store event are exclusive, as soon as
the packaging which lies on the work-bench is full, the appropriate methods
full-praline and full-truffle can occur and then the store internal tran-
sition is activated. Note the use of the simultaneous synchronization operator
‘//’ within both the full-praline and the full-truffle methods when the
packaging is of type deluxe-packaging. This implies that two chocolates are
put at the same time in a deluxe packaging.
4 CO-OPN/2 Syntax
The purpose of this section is to describe the abstract syntax of the CO-OPN/2
formalism. Recall that a CO-OPN/2 specification is composed of two kinds of
descriptions associated with two kinds of modules: Adt modules and Class mod-
ules. The Adt modules are used to describe the algebraic abstract data types
involved in a CO-OPN/2 specification, while the Class modules correspond to
the description of the objects that are obtained by instantiation. In this paper
we use, without presenting it, the approach of hierarchical order-sorted alge-
braic specifications in which operations are total on subsorts. It has been shown
that this approach is powerful enough to model partiality [10]. Nevertheless, a
more flexible approach is presented in [4] which combines the approach of partial
abstract data types with the approach of order-sorted algebras.
In this section, we first give some definitions in relation with the ADT and
class modules, and then we define what a CO-OPN/2 specification is in terms
of ADT and class modules. Since the modules are obviously not complete, we
finally introduce the notion of completeness and consistency of a CO-OPN/2
specification. The notion of consistency adds constraints on the structure of the
specification, as well as at the level of typing of the various elements.
Throughout this paper we consider a universe which includes the disjoint
sets: S, F, M, P, V. These sets correspond, respectively, to the sets of all sort,
The CO-OPN/2 Formalism 89
function, method, place, and variable names. In the context of CO-OPN/2, the
set of all sorts S is divided into two disjoint sets SA and SC , S = SA ∪ SC with
SA ∩ SC = ∅. The former is dedicated to the usual sort names involved in the
algebraic description part, whereas the latter consists in all the type names of
the classes. As already mentioned, each class defines a type, i.e. a sort of SC ,
and every class instance has an identity which is an algebraic value of that sort.
The “S-sorted” notation facilitates the subsequent development. Let S be a
set, a S-sorted set A is a family of sets indexed by S, we write A = (As )s∈S . A
S-sorted set of disjoint sets of variable is called a S-sorted variable set. Given two
S-sorted sets A and B, a S-sorted function µ : A → B is a family of functions
indexed by S denoted µ = (µs : As → Bs )s∈S . We frequently use the extension
of a partial order ≤ ⊆ S × S to strings in S ∗ of equal length, s1 · · · sn ≤ s1 · · · sn
iff si ≤ si (1 ≤ i ≤ n).
Let Σ =
S, ≤, F be a signature and X be a S-sorted variable set. The
S-sorted set TΣ,X is the set of all terms with variables.
In the context of CO-OPN/2 multi-sets are used for two purposes. The first
one is the need for representing the values of the places and the second one is
for the expression of concurrency in the semantics. The syntactic extension for
a set of sort S consists of adding for every sort s ∈ S the multiset sort [s], the
subsort relation related to the multi-sets and the operations empty, singleton
and union. Similarly we semantically extend the models of A of an algebraic
specification into [A] by adding carrier set [A]s and the multiset functions.
3
The A superscript indicates that the module and its components are in relation with
the abstract data type dimension.
90 O. Biberstein, D. Buchs, and N. Guelfi
Observe that, since the profile of the operations is built over S, some elements
of such profiles can obviously be of sort in SC . This suggests that ADT mod-
ules can describe data structures of object identifiers, stack or arrays of object
identifiers for example.
Similarly to the notion of ADT module signature, the elements of a class
module which can be used from the outside are grouped into a class module
interface. The class module interface of a class module includes: the type of
the class, a subtype relation with other classes, and the set of methods that
corresponds to the services provided by the class.
management of the objects identifiers, as well as one constant for each static
object. The semantics of these operations is detailed further in Section 5.1. These
operations are defined on the global subsort/subtype relation as follows:
FΩ C = {oc : → c | o : c ∈ O} ∪
{initc : → c, newc : c → c} ∪
{subc,c : c → c , superc,c : c → c | c ≤Σ,Ω c, c ≤Σ,Ω c }.
On these basis, we define a global signature written ΣΣ,Ω and a global interface
written ΩΩ . A global signature groups the sorts and types, the subsort and
subtype relations, as well as the operations of ADT signatures Σ and of the
ADT signatures derived from Ω. As for a global interface, it groups the types,
the subtype relations, and the methods of the set of class interfaces Ω.
4
Here the C superscript stresses the belonging to the class (algebraic net) dimension.
5
In general, we use s symbols for sorts of the abstract data type dimension and c
symbols for types (in fact sorts) of the classes,
The CO-OPN/2 Formalism 91
ADT modules describes abstract data types which may be used by other ADT or
class modules. An ADT module consists of an ADT signature, a set of formulas
also called axioms, and of course some variables. Remember that, in the context
of structured specification, an ADT module may obviously use elements not
locally defined, i.e. defined in other modules.
• Σ A is an ADT signature;
• X = (Xs )s∈S is a S-disjointly-sorted set of variables of V;
• Φ a set of formulas6 (axioms) over ΣΣ,Ω and X. ♦
Before defining a behavioral formula, let us recall that our formalism provides
two different categories of events: the invisible events, and the observable events.
Both of them can involve an optional synchronization expression. The invisible
events describe the spontaneous reactions of an object to some stimuli. They
correspond to the internal transitions which are denoted by τ and not by a
specific name, as in the concrete CO-OPN/2 language. The observable events
correspond to the methods that are accessible from the outside. A synchroniza-
tion expression offers an object the means of choosing how to be synchronized
with other partners (even itself). Three synchronization operators are provided:
‘ // ’ for simultaneity, ‘ . . ’ for sequence, and ‘⊕’ for alternative. In order to select
a particular method of a given object, the usual dot notation has been adopted.
We write EA,M,O,C for the set of all events over a set of parameter values A,
a set of methods M , a set of object identifiers O, and a set of types of classes C.
Because this set is used for various purposes, we give here a generic definition.
6
A formula is either a pair (t, t ), denoted t = t , or a set of pairs {(ti , ti ), (t, t ) | 1 ≤
i ≤ n}, denoted t1 = t1 , . . . , tn = tn =⇒ t = t , where ti , ti (1 ≤ i ≤ n) and t, t are
terms of T(ΣΣ,Ω ),X .
92 O. Biberstein, D. Buchs, and N. Guelfi
When Σ and Ω are, respectively, equal to the global signature and in the global
interface of the specification, the specification is considered complete. We denote
a CO-OPN/2 specification Spec Σ,Ω by Spec and the global subsort/subtype
relation ≤Σ,Ω by ≤. ♦
We consider in this paper, only acyclic specifications. That is, specifications,
where it is not possible for two different modules (algebraic or class) to use
themselves in their definition. Preliminary results can be found in [9] so as to
allow cycles between class modules.
7
The notion of coherence imposes conditions on the profile of the algebraic operations
of a signature as defined in [4].
94 O. Biberstein, D. Buchs, and N. Guelfi
5 CO-OPN/2 Semantics
This section presents the semantic aspects of the CO-OPN/2 formalism which
are based on two notions, the order-sorted algebras, and the transition systems.
First of all, we concentrate on order-sorted algebras as models of the data
structures of a CO-OPN/2 specification. Then, we introduce an essential ele-
ment of the CO-OPN/2 formalism, namely the order-sorted algebra of object
identifiers, which is organized in a very specific way.
Afterwards, we present how the notion of transition system is used so as to
describe a system composed of objects dynamically created. Then, we provide
all the inference rules which allow us to construct the transition system of a CO-
OPN/2 specification. Such a transition system is considered as the semantics of
the specification.
ΣΩ C , VΩ C , ΦΩ C in which ΣΩ C =
{c}, ≤ , FΩ C , and where
• FΩ C = {initc : → c, newc : c → c} ∪
{subc,c : c → c , superc,c : c → c | c ≤ c, c ≤ c }.
• VΩ C = {oc : c, oc : c | c ≤ c};
• ΦΩ C = {subc,c initc = initc ,
subc,c (newc oc ) = newc (subc,c oc ),
superc ,c initc = initc ,
superc ,c (newc oc ) = newc (superc ,c oc ) | c ≤ c}
The variables of VΩ C are chosen in a way such that they do not interfere with
other identifiers of the module signature. ♦
The CO-OPN/2 Formalism 95
Theorem 10.
Let Spec be a well-formed CO-OPN/2 specification and ≤ be its global relation.
For any types c, c such that c ≤ c the following properties hold:
i) superc ,c (subc,c oc ) = oc , where oc : c ;
ii) subc,c (superc ,c oc ) = oc , where oc : c .
any time, the last object identifier used, so as to be able to compute a new object
identifier. Consequently, throughout its evolution, the system retains a function
which returns the last object identifier used for a given class type. Moreover,
another information has to be retained throughout the evolution of the system.
This information consists of the objects that have been created and that are
still alive, i.e. the object identifiers assigned to some class instances involved in
the system at a given time. This second information is also retained by means
of a function the role of which is to return, for every class type, a set of object
identifiers which corresponds to the alive (or active) object identifiers.
For the subsequent development, let us consider a specification Spec, A =
Sem(Pres(Spec)), and the set of all types of the specification S C = Types(Spec).
The partial function which returns, for each class, the last object identifier
used, is a member of the set of partial functions:
| l(c) ∈ A
Loid Spec,A = {l : S C → A c or is not defined}
The second function retained by the system throughout the evolution of the
system returns the set of the alive objects of a given class. It is member of the
set of partial functions8 :
a(c) ∈ P(A
Aoid Spec,A = {a : S C → C | C ⊆ P(A), c )}.
The creation of an object implies the storage of its identity and the computation
of a new alive object identifiers function based on the old one. This is achieved by
→ Aoid Spec,A | c ∈ S C } (new
the family of functions {newaoid c : Aoid Spec,A × A
alive object identifiers) defined as:
Both of those families of functions newloid c and newaoid c are used in the infer-
ence rules concerning the creation of new instances, see Definition 14.
The set of functions {remaoid c : Aoid Spec,A × A → Aoid Spec,A | c ∈ S C } is
the dual version of the newaoid c family in the sense that, instead of adding
an object identifier, they remove a given object identifier and compute the new
alive object identifiers function as follows:
c )(∀a ∈ Aoid Spec,A ) remaoid c (a, o) = a such that
(∀c, c ∈ S C )(∀o ∈ A
a(c) \ {o} if c = c,
a (c ) =
a(c) otherwise.
: Loid Spec,A × Loid Spec,A × Loid Spec,A → Loid Spec,A such that
l (c) if l (c) = l(c) ∧ l (c) = l(c),
C
(∀c ∈ S ) (l l l )(c) = l (c) if l (c) = l(c) ∧ l (c) = l(c),
l(c) otherwise.
= : Loid Spec,A × Loid Spec,A × Loid Spec,A such that
(∀c ∈ S C ) (l =l l )(c) = ((l(c) = l (c) = l (c)) ∨ (l (c) = l (c)))
P : Aoid Spec,A × Aoid Spec,A × Aoid Spec,A × Aoid Spec,A such that
P (a1 , a1 , a2 , a2 ) ⇐⇒
(∀c ∈ S C ) (((a1 (c) ∩ ((a2 (c) \ a2 (c)) ∪ (a2 (c) \ a2 (c)))) = ∅)∧
((a1 (c) ∩ ((a2 (c) \ a2 (c)) ∪ (a2 (c) \ a2 (c)))) = ∅)∧
((a2 (c) ∩ ((a1 (c) \ a1 (c)) ∪ (a1 (c) \ a1 (c)))) = ∅)∧
((a2 (c) ∩ ((a1 (c) \ a1 (c)) ∪ (a1 (c) \ a1 (c)))) = ∅))
The CO-OPN/2 Formalism 99
In the algebraic nets community, the state of a system corresponds to the notion
of marking, that is to say a mapping which returns, for each place of the net,
a multi-sets of algebraic values. However, this current notion of marking is not
suitable in the CO-OPN/2 context. Remember that CO-OPN/2 is a structured
formalism which allows for the description of a system by means of a collection of
entities. Moreover, this collection can dynamically increase or decrease in terms
of number of entities. This implies that the system has to retain two additional
informations as explained above. In that case, the state of a system consists of
three elements. The first two ones manage the object identifiers, i.e. a partial
function to memorize the last identifiers used, and a second function to memorize
which identifiers are created and alive. The third element consists in a partial
function that associates a multi-set of algebraic values to an object identifier and
a place. Such a partial function is undefined when the object identifier is not
yet assigned to a created object. This is a more sophisticated notion of marking
than the one presented in usual algebraic nets. This new notion of marking is
necessary in the CO-OPN/2 context because, here, a net does not describe a
single instance but a class of objects which can be dynamically created and
destroyed.
Dom Spec,A (m) = {(o, p) | m(o, p) is defined, p ∈ P, o ∈ A}.
The set of all transitions systems over Spec and A is denoted TSSpec,A . A triple
Before introducing the set of inference rules designed for the construction
of the transition system associated to a given CO-OPN/2 specification, we now
introduce informally some basic operators on markings and for the management
of the object identifiers. These operators are intensively used in those inference
rules.
Informally, the sum of markings ‘+’ adds the multi-set values of two markings
and takes into account the fact that markings are partial functions. The common
markings predicate ‘&'’ determines if two markings are equal for their common
places. As for the fusion of markings ‘m1 ✂ m2 ’, it returns a marking whose the
values are those of m1 and those of m2 which do not appear in m1 .
for all Event, Event , Event ∈ E(TΣ,X ),M,(TΣ,X )s ,{c} with s ∈ S C , for all t ∈
(TΣ,X )s and for all methods m ∈ Ms,s1 ,...,sn with s ∈ S C and si ∈ S A , and
for all synchronization operators op ∈ { // , . . , ⊕}. Note that the evaluation of
any term t of (TΣ,X )s with s ∈ S C belong to A and then represents an object
identifier. The evaluation of such terms, in the previous definition, is essential
when data structures of object identifiers are considered.
Finally, the satisfaction of a condition of a behavioral formula is defined as:
• The Class rule generates the basic observable – as well as invisible – tran-
sitions that follow from the behavioral formulas of a class. For all the object
identifiers of the class, for all last object identifier function l, and for all alive
object identifier function a, a firable (or enabled ) transition is produced pro-
vided that:
1. there is a behavioral formula Event :: Cond ⇒ Pre → Post in the class;
2. there exists an assignment σ : X → A;
3. all the equations of the global condition are satisfied (A, σ |= Cond );
The CO-OPN/2 Formalism 103
for all l, l in Loid Spec,A , for all a, a in Aoid Spec,A , for all m, m , m in Mark Spec,A ,
for all o in A c , and for all e in E .
A,M,A,{c}
4. the object o has already been created and is still alive, i.e. it belongs to
the set of alive objects of the class (o ∈ a(c)).
The transition generated by the rule guarantees that there are enough values
in the respective places of the object. The firing of the transition consumes
and produces the values as established in the pre-set and post-set of the
behavioral formula.
• The Create rule generates the transitions aimed at the dynamic creation
of new objects provided that:
1. for any last object identifier function l and any alive object identifier
function a;
2. a new last object identifier function is computed (l = newloid c (l));
3. a new object identifier o is determined for the class (o = l (c));
4. this new object identifier must not correspond to any active object (o ∈
a(c)).
The new state of the transition generated by the rule is composed of the new
last object identifier function l , an updated function a in which the new
object identifier has been added to the set of created objects of the class,
σ
and the initial marking [[I]]o .
• The Destroy rule, aimed at the destruction of objects, is similar to the
Create rule. The Destroy rule merely takes an object identifier out of the
set of created objects, provided that the object is alive.
• The Mono rule (for monotonicity) generates all the firable transitions from
the transitions already generated.
Example 15.
Figure 7 illustrates the partial semantics of the ‘ConveyorBelt’ class of the Swiss
chocolate factory example given in Specification 7. For the sake of simplicity,
only few relevant events are depicted. Moreover, each state is represented by a
104 O. Biberstein, D. Buchs, and N. Guelfi
triple
o, O, m, where o is the last object identifier used for the creation of new
instances of the class, O is the set of the active objects of the class, and m is the
multi-set values of the ‘belt’ place. Brackets ‘[ ]’ denote multi-set values, while
vertical lines ‘| |’ denote fifo data structures of packagings. The abbreviation
‘tcb’ stands for ‘the-conveyor-belt’ object identifier; x, y are object identifiers of
type ‘packaging’ or ‘deluxe-packaging’. For instance the state
tcb, {tcb}, [|x, x|]
establishes that the ‘tcb’ object is alive and its ‘belt’ place is composed of one
fifo which contains twice the same packaging object identifier x.
Md Ci+1 (0 ≤ i < n), we introduce the partial semantics of all the modules Md Ci
(0 ≤ i ≤ n) of a specification from the bottom to the top.
transitions. This step is called the pre-stabilization. The second step produces
the intended transition system which contains only the relevant transitions, i.e.
all the transitions except the transitions which do not lead to a stable state. We
observe that the Stab-1 and Stab-2 involve a new kind of transitions denoted
with a double arrow (⇒-transitions). This kind of transitions is introduced in
order to distinguish between a transition system composed of stable states and
the one in which some invisible events have to be taken into account. Now, we
understand a little bit better why we defined a transition system as {✲, ⇒}-
disjointly-sorted, that is to say divided into two disjoint sub-transition systems.
e
e
= o.τ, e
= o.τ with e ,
l, a, m −→
l , a , m
Stab-1 e
l, a, m =⇒
l , a , m
e o.τ
m1 m2 ,
l, a, m1 =⇒
l , a , m1 ,
l , a , m2 −−−→
l , a , m2
Stab-2 e
l, a, m1 ✂ m2 =⇒
l , a , m2 ✂ m1
for all m, m , m1 , m1 , m2 , m2 in Mark Spec,A , for all l, l , l in Loid Spec,A , for all
and for all e, e in E
a, a , a in Aoid Spec,A , for all o in A, C.
A,M,A,S
• The Stab-1 rule generates all the observable events which will be merged
with invisible events if they lead to an unstable state; note that neither the
pure internal transitions nor the internal transitions asking to be synchro-
nized with some partners are considered by this rule;
• The Stab-2 rule merges an event leading to a non-stable state and the
invisible event which can occur “in sequence”. This rule is very similar the
Seq introduced further when the closure operation is presented. Thus, the
same comments regarding its functioning and the meaning of the operators
involved in the rule hold.
9
The application of the inference rules on TS obviously includes TS itself.
106 O. Biberstein, D. Buchs, and N. Guelfi
e1 e2
m1 m2 ,
l, a1 , m1 =⇒
l , a1 , m1 ,
l , a2 , m2 −−→
l , a2 , m2
Seq e1 . . e2
l, a, m1 ✂ m2 −−−−−−→
l , a2 , m2 ✂ m1
l =l l ,
e1 e2
P (a1 , a1 , a2 , a2 ),
l, a1 , m1 −−→
l , a1 , m1 ,
l, a2 , m2 −−→
l , a2 , m2
Sim
e // e2
l, a1 ∪ a2 , m1 + m2 −−1−−−−−
→
l l l , a1 ∪ a2 , m1 + m2
e1 e1
l, a, m −−→
l , a , m
l, a, m −−→
l , a , m
Alt-1 e ⊕e Alt-2 e ⊕e
l, a, m −−1−−−−2→
l , a , m
l, a, m −−2−−−−1→
l , a , m
l =l l ,
e with e e2
P (a1 , a1 , a2 , a2 ),
l, a1 , m1 −−3−−−−−−−2→
l , a1 , m1 ,
l, a2 , m2 =⇒
l , a2 , m2
Sync e3
l, a1 ∪ a2 , m1 + m2 −−→
l l l , a1 ∪ a2 , m1 + m2
for all m1 , m1 , m2 , m2 in Mark Spec,A , for all l, l , l in Loid Spec,A , and for all
a, a , a1 , a1 , a2 , a2 in Aoid Spec,A , for all e1 , e2 in EA,M,A,S
C which are not equal
to o.τ or to o.τ with e and for all e3 in EA,M,A,S C .
• The Seq rule infers the sequence of two transitions provided that the mark-
ings shared between m1 and m2 are equal. The double arrow under the e1
event forces that e1 leads to a stable state. This guarantees that all the invis-
ible events are taken into account before inferring the sequential behaviors.
The CO-OPN/2 Formalism 107
• The Sim rule infers the simultaneity of two transitions, provided that some
constraints on the l and a functions are satisfied. The purposes of these
constraints are:
1. to avoid that an event can use a given object being created by the other
event (i.e. which does not already exist);
2. to avoid that an event can use a given object being destroyed by the
other event (i.e. which does not exit any more).
Informally, the operators defined in Section 8 are used to:
1. l =l l avoids the conflicts when simultaneous creation is considered.
Remember that the assignment of a new object identifier is handled by
a different function for each type. Consequently, this characteristic does
not permit the simultaneous creation of two objects of the same type.
2. l l l combines the last object identifier functions according to the
creations involved in e1 and e2 ;
3. a ∪ a makes merely the union of the a and a for each type;
4. the predicate P (a1 , a1 , a2 , a2 ) guarantees that the objects created or de-
stroyed by the events e1 do not appear in the upper tree related to the
event e2 and vice versa; more precisely, for each type c the active objects
of a1 (c) (and a1 (c)) and the “difference” between a2 (c) and a2 (c) have
to be disjoint, as well as the active objects of a2 (c) (and a2 (c)) and the
“difference” between a1 (c) and a1 (c).
• The Alt-1 and Alt-2 rules provides all the alternative behaviors. Two rules
are necessary for representing both choices of the alternative operator ⊕.
• The Sync “solves” the synchronization requests. It generates the event which
behaves the same way as the event ‘e3 with e2 ’ asking to be synchronized
with the event e2 . The double arrow under the event e2 guarantees that the
synchronizations are performed with events leading to stable states. Note
that e3 can be an invisible event because internal transitions may ask for a
synchronization.
The similarities between the Sim and Sync are not surprising because of the
synchronous nature of CO-OPN/2.
Sem ❁
A (∅) = ∅
C C
Sem ❁ n
A ({Md 0 }) = lim (Closure ◦ Stab) (PSem(Md 0 ))
n→∞
C
Sem ❁
A (∪0≤j≤k {Md j }) =
C C
lim (Closure ◦ Stab)n (Sem ❁
A (∪0≤j≤k−1 {Md j }) ∪ PSem A (Md k ))
n→∞
for 1 ≤ k ≤ m. ♦
The above definition of the semantics is not independent of the total order
as demonstrated further by Example 21. Thus, we define the semantics of a
CO-OPN/2 specification only when it does not depend of such a total order.
Definition 19. Semantics of a specification
Let Spec be a specification, A = Sem(Pres(Spec)), ❁ be a total order over the
C
class modules DSpec . The semantics of Spec denoted Sem A (Spec) is defined as
the Sem A (Spec) = Sem ❁A (Spec) iff it is independent of the total order ❁ over
the class modules of Spec (i.e. the semantics are equal for different total orders),
otherwise it is undefined. ♦
This definition is implied by the fact that the stabilization needs a precise
hierarchy between modules in order to be deterministic for its behavior. Alter-
native definitions could consist in imposing, from the specifier, to fix the total
order of stabilization; or to reduce the stabilization domain to specific objects.
Finally, we define the step semantics of a CO-OPN/2 specification from the
above semantics in which we only retain the ⇒-transitions whose the events are
atomic or simultaneous. Moreover, we only consider the transitions from states
that are reachable from the initial state.
Definition 20. Step Semantics of a specification
Let Spec be a specification and A = Sem(Pres(Spec)). The step semantics of
Spec, denoted SSem A (Spec), is defined as the greatest set in TSSpec,A such that
e
SSem A (Spec) ⊆ Sem A (Spec) and for any transition st =⇒ st in SSem A (Spec)
the following properties holds10 :
10
The symbol ∗ corresponds to the reflexive transitive closure of the reachability
relation, however, is defined for the ⇒-transitions. The initial state is denoted
⊥, ∅, ⊥.
The CO-OPN/2 Formalism 109
C (1 ≤ i ≤ n).
where e, ei ∈ EA,M,A,S ♦
Example 21.
Let us consider the specification Spec composed of the three class modules A,
B, and C given in Specification 11, and A = Sem(Pres(Spec)). The graphical
representation of the three static objects defined in the classes is depicted on the
right side of the specification.
✞ a :ta c :tc
Class A; Class B; Class C;
Interface Interface Interface
Type ta; Type tb; Type tc;
t
Object a :ta; Object b :tb; Object c :tc; m
Method m; Methods p, g; Body
Body Body Use B; ..
Use B; Use BlackToken; Transition t;
Axiom Place Axiom p g
m with b.p..b.g; k_:blacktoken; t with b.g;
@ @
End A; Axioms End C;
p :: -> k @; k
g :: k @ ->;
End B;
✝ ✆ b :tb
B ❁1 A ❁1 C and B ❁2 C ❁2 A.
Thus, we demonstrate that these two total orders lead to different semantics;
in other words, the semantics of such a system is not independent of the total
order, Sem ❁ ❁2
A = Sem A .
1
Since this example depicts several transitions systems, we adopt, for the sake
of clarity, the following conventions:
1. we represent the state of the objects by the content of the places; natural
numbers denote the number of tokens, while ⊥ is used for object without
any place;
2. the events in relation with the creation of the objects are not represented;
3. black and gray arrows denote, respectively, ✲ - and ⇒-transitions;
4. only the synchronization events of the closure operation are depicted, the
numerous other events are omitted.
5. both the semantics Sem ❁ A (i = 1, 2) have an observational flavor; i.e. only
i
the ⇒-transitions from states which are reachable from the initial state are
drawn and the ✲ -transitions are omitted.
First, we provide the partial semantics of the three individual classes A, B,
and C in Figure 8. Note that, for the sake of clarity, only the relevant transitions
are shown in these figures, especially those in relation with the static objects.
Figure 9 depicts the incremental construction of the semantics of the specifi-
cation according the first total order ❁1 . As a result, the third transition system
110 O. Biberstein, D. Buchs, and N. Guelfi
✞
✝ ✆
Fig. 8. Partial Semantics of the Three Classes A, B, and C.
is due to the fact that the internal transition τ (which corresponds to the in-
ternal transition t) asks for a synchronization with the method g as soon as it
becomes firable. Therefore, the system cannot offer the service g to the outside
world once class C has been incorporated.
✞
b.p .. b.g b.p .. b.g b.p .. b.g b.p .. b.g
Sem ❁
A (B) :
1
b.p b.p b.p b.p
0 1 2 3
b.g b.g b.g b.g
Sem ❁
A ((B ∪ A) ∪ C) :
1
0 b.p
✝ ✆
Fig. 9. Semantics of the Specification According to ❁1 .
Sem ❁
A (B) :
2
b.p b.p b.p b.p
0 1 2 3
b.g b.g b.g b.g
Sem ❁
A (B ∪ C) : 0
2 b.p
Sem ❁
A ((B ∪ C) ∪ A) : 0
2 b.p
✝ ✆
Fig. 10. Semantics of the Specification According to ❁2 .
The CO-OPN/2 Formalism 111
5.5 Subtyping
As mentioned earlier, we believe, as some other researchers [2,14], that the sub-
typing relationship is related to the behavior of the objects and addresses a
semantic conformance between a subtype and its supertypes. Moreover, we are
convinced that, at the specification level, the strong form of the substitutability
rather than the weak form should be adopted.
The subtype relationship we are going to state is based on the strong bisim-
ulation equivalence between the semantics of the supertype and the semantics
of the subtype restricted to the behaviors of the supertype; i.e. between two
transition systems. Bisimulation, introduced in [15] is adequate in our context
because it is weaker than isomorphic equivalence and stronger than trace equiv-
alence. On the one hand, bisimulation disregards the internal state of the objects
and, on the other hand, takes into account the non-determinism of the transition
systems. The bisimulation equivalence establishes a relation between the states
of two transition systems: two states are related if and only if each transition in
the first system corresponds to another transition in the second one. As we will
only consider transition systems as model of a CO-OPN/2 specification, then all
the states will be reachable from a specific state, the initial state. Unicity of the
bisimulation relation is imposed by the relation of initial states. We denote, for
a transition system TS , an initial state by stinit .
In the CO-OPN/2 context, the usual definition of bisimulation is extended
for the subtyping. Thus, the subtyping definition we establish below compares
two semantics which clearly involves object identifiers of two different types
(in subtyping relation). These object identifiers are then obviously not equal.
The following definition takes into account the fact that the object identifier
belong to two types in subtyping relation by means of the operations between
the carriers of the object identifier algebra. Thus, it is necessary to define the
natural extension of a subtype relation ≤ on the object identifiers sorts according
to the event structure of Definition 4.
We say that a type c is a subtype of another type c when the step semantics
of the class Md Cc , in which c is declared, along with its dependencies restricted
to the behaviors of the class Md Cc , in which c is declared, is strongly subtype
bisimilar to the step semantics of Md Cc and its dependencies. Formally we have:
where Dep(Md C ) denotes the set of all the class modules used by Md C . The
notation SSem A (Spec)|Md Cc means that SSem A (Spec) is limited to the services
of the class module Md Cc . ♦
o’.create-packaging
semantics of the packagings, while Figure 12 depicts the step semantics of the
deluxe packagings. In Figure 13 shows the step semantics of the deluxe packag-
ings restricted to the packagings services, i.e. all the events added by the deluxe
packagings are ignored, moreover, only the states reachable from the initial state
are considered.
The CO-OPN/2 Formalism 113
o.create-packaging
o.create-packaging
Fig. 13. Step Semantics of the Deluxe Packagings Restricted to the Packagings
The following counter-example which also involves two classes of the Swiss
chocolate factory example is less obvious. Let us consider both the heap and the
conveyor-belt types defined, respectively, in Specification 5 and 7. Figure 14
depicts both these semantics. On the one hand, we observe, on the left side, the
step semantics of the heap, while the right side shows the step semantics of the
conveyor belt.
o.put a o’.put a
o.put a // o.put a
o.get a o’.get a
o’.put b
o.put a o.get b o’.put a
o’.get b
o.get a o.put b
o.create o.put a // o.put b o’.create o’.get a
o’.get b
o.get b o.put a
o’.get a
o.put b o.get a o.put b o’.put a
o.get b o’.get b
o.put b // o.put b
o.put b o’.put b
Fig. 14. Step Semantics of the Heap and the Conveyor Belt
114 O. Biberstein, D. Buchs, and N. Guelfi
We observe easily that both these transition systems are not strongly subtype
bisimilar. Thus the heap type is not a subtype of the conveyor-belt type and
vice versa.
The conveyor-belt type is not a subtype of the heap type, because the
conveyor-belt type does not allow any concurrent event, while the heap type
does. Moreover, the nature of the conveyor-belt (first-in-first-out) forces some
sequences of events. Consequently, the conveyor-belt type cannot give all the
services of the heap type.
On the other side, the heap type is not a subtype of the conveyor-belt
type because the heap type possesses some concurrent events. It means that if
we substitute an instance of type heap for an instance of type conveyor-belt
in a context that possibly uses some concurrent events of the heap type, the
behavior of the whole system will be probably not guaranteed.
Finally we are able to introduce the semantics of a specification which satisfies
the subtyping relation.
We have defined in this section a subtype relation for the classes of a spec-
ification as a semantic relation between behaviors. This approach follows the
principle of substitutivity and clearly distinguishes the subtype relation from
the inheritance relation. A last property which should be mentioned is that our
semantics of subtyping based on bisimulation ensures the substitutivity princi-
ple.
One key aspect of this problem is that the editor should cater for several users,
working at different workstations, and cooperating in the construction of the one dia-
gram. In the Computer Supported Cooperative Work (CSCW) vocabulary, such a tool
could be ranked amongst synchronous groupware (each user is informed in real time
of the actions of the others) allowing for relaxed WYSIWIS (What You See Is What
I See) : each user may have his own customized view of the diagram under design,
viewing different parts of the drawing, or examining it at a different level of detail.
3
A second key aspect of this problem is that the editor should cater for hierarchical
diagrams, i.e. components of the diagram can be exploded to reveal subcomponents.
4
A simple coordination protocol is proposed to control the interactions between
the various users:
1. (a) Users may join or leave the editing session at will, and may join with different
levels of editing privileges. For example, a user may join the session merely to
view the diagram, or perhaps to edit it as well (see below).
(b) The current members of the editing session ought to be visible to all, together
with their editing privileges.
2. (a) Graphical elements may be free or owned by a user.
(b) Different levels of ownership should be supported, including ownership for
deletion, encapsulation, modification, and inspection.
(c) The ownership must be compatible with the user’s editing privileges.
3. Ownership for deletion requires that no one else has any ownership of the compo-
nent – not even for inspection.
4. Ownership for encapsulation requires that only the owner can view the internal
5
details of the component – all other users can only view the top level or interface
to the component.
5. Ownership for modification allows the user to modify attributes, but not to delete
the component.
6
6. Ownership for inspection only allows the user to view the attributes .
7. Only ownership for encapsulation can persist between editing sessions. (Note that
this ownership is tied to a particular user, not to a particular workstation.) All
other ownerships must be surrendered between sessions.
8. Ownership for inspection is achieved simply by selecting the component.
9. Other forms of ownership (and release) are achieved by an appropriate command,
having first selected the component.
10. The level of ownership of a component is visible to all other users, as is the identity
of the owner.
11. The creator of an element owns it for deletion, until it is explicitly released.
,
1 2 We have decided to consider one kind of CDE: hierarchical Petri nets.
The hierarchical Petri nets editor is used as the basic case study and
116 O. Biberstein, D. Buchs, and N. Guelfi
Level 0
t
p1 p2
a1 a2
Nicolas, Olivier r
Level 1
t 1t
p 1t a t1 a t3 p 2t
r
a 2t a4t
t t2
Didier
server
document
Clientship. In Figure 17, for example, one may see, at the top level, that the
User class uses (as a client) the Viewport class because a user simply submits
some requests to the viewport, e.g. to select a component or add a new com-
ponent to the diagram, and no information is sent back from the viewport to
the user. A similar argument holds for the two other levels. Regarding the other
entities (viewports, servers and components), the clientship relationship is sym-
metric. In the case of a cooperative editor, if we consider, for example, the user’s
The CO-OPN/2 Formalism 119
Inheritance. We believe that inheritance and subtyping are two different no-
tions which are used for two different purposes. Inheritance is mainly considered
to be a syntactic mechanism for reusing a part of an existing class while subtyp-
ing pertains to the behavior of the instances and is a semantics concern.
In Figure 17, it clearly appears that the thick vertical arrows represent
inheritance relationships. The classes User, C-User, Server, Viewport, and
Component have been built from scratch while the C-Server, C-Viewport and
C-Component classes reuse or inherit from the initial classes and add what is
needed in order to allow for cooperative edition. In a similar manner, the classes
located at the lower level inherit from the higher level and add services required
by a cooperative editor of hierarchical Petri nets, e.g services which are mainly
related to the creation of new places, tokens, arcs or transitions.
PN-C-Component
PN-C-H-Component PN-C-A-Component
Users. The users involved in a CDE are modeled by means of the C-User class
described in Specification 12 and in Figure 19. This is a small and simple class,
built from scratch.
Missing algebraic modules may be found in [5]. Nevertheless, we mention that
the Coord ADT module defines the sort coord, which is a pair of naturals and
that the Privilege module defines both the view and edit user privileges as
required. The four ownerships required by the proposal are defined in the ADT
module Ownership. As for the Unique module, it only defines the generator ‘@’
of sort unique, which plays the role of a black token.
Every name within the Methods field models an action that a user would
like to accomplish by means of the viewport. Among these methods we may
mention the join and leave methods which correspond to the will of a user
to join or to leave an editing session. The select method is used to select a
component of the diagram at a given location, the go-down allows a hierarchical
component, previously selected, to be visited, and the go-back rises again within
in the hierarchy, delete removes a selected component. The move, resize,
and rotate methods are used to modify aspects of selected components. The
own-for method represents the user’s will to own a component for a given
ownership.
The instance variables (Places field) are involved in the behavioral axioms
which describe the properties of the methods. For instance, the behavioral axiom
join pr with v.(self join pr) :: idle @ -> active @, cur-vp v
The CO-OPN/2 Formalism 121
✞
Abstract Class C-User;
Interface
Use Coord, Size, Angle, Privilege, Ownership;
Type c-user;
Methods
join _ : privilege; leave;
select _ : coord; unselect;
go-down; go-back;
delete; move _ : coord;
resize _ : size; rotate _ : angle;
own-for _ : ownership;
Body
Use Unique, C-Viewport;
Places
idle _ , active _ : unique;
cur-vp _ : c-viewport;
Initial
idle @;
Axioms
join pr with v.(self join pr) :: idle @ -> active @,cur-vp v;
leave with v.leave :: active @,cur-vp v -> idle @;
select p with v.select p :: active @,cur-vp v -> active @,cur-vp v;
move p with v.move p :: active @,cur-vp v -> active @,cur-vp v;
own-for os with v.own-for os:: active @,cur-vp v -> active @,cur-vp v;
where p : coord; v : c-viewport; pr : privilege; os : ownership;
;; ... and more axioms ...
End C-User;
✝ ✆
Spec. 12. The Cooperative Users.
indicates that the join method is asking to be synchronized with the join
method for the privilege pr of an available existing viewport v. The user has to
be idle and will become active. Moreover, the free variable v will be unified with
an available existing viewport and memorized by the current viewport attribute
(cur-vp v). The self-reference self informs the viewport of the identity of the
user who wants to be connected to it. The viewport will store this object identifier
in order to know what connection has been established.
The role of the method select is the transmission of the user’s will to select
an existing component at a given position p to the current viewport v. The same
remark holds true for the other methods.
join pr leave
v
@
v @ @
@
select p own-for os
Figure 19 provides a partial graphic view of the C-User class. Note that for
the sake of clarity not all the methods have been represented.
122 O. Biberstein, D. Buchs, and N. Guelfi
u select p wth pr
u login v u own-for os
assoc broadcast-to
uvc
[]
uvc
u move p wth pr @ uvc
broadcast-flag finish-broadcast
@
start-broadcast
uvc+<u v c>
uvc
selected
broadcast v pic
..
c.move p
c.(u authorized-for? modification) c.component-pic pic
Finally, from the abstract C-Server class we derive the PN-C-Server which
describes the effective server involved in the hierarchical Petri net editor. The
PN-C-Server class is presented in [5] introduces the missing services related to
the creation of the effective Petri net components.
viewport 1 viewport 2
viewport 3
document
a t1 p 1t
server
t 1t t p1 p2
a t2 a1 a2
p t2
t 2t
a t3 r
a4t
7 Conclusion
The main benefit of this article is to provide a presentation of the latest evolution
of CO-OPN, in such a way that the abstract syntax and formal semantics are
complete and coherent, and that the specification capabilities of the formalism
can be compared with other approaches in the field of high level Petri nets.
The abstract syntax covers the full concrete syntax of our specification for-
malism which is illustrated in an introductory example dedicated to an intuitive
understanding of the CO-OPN/2 semantics. The main idea is that a CO-OPN/2
specification defines a set of modules which can be either algebraic Petri net
classes or abstract data types modules. Algebraic Petri nets are Petri nets with
parameterized transitions (methods) and internal spontaneous transitions. A
new synchronization mechanism is introduced for the composition of algebraic
Petri net classes that generalize mechanisms found in other Petri net approaches.
The abstract data type specifications are structured order-sorted algebraic spec-
ifications and are used not only for the specification of the data structures, but
also for the description of the class instances’ identifiers. On the one hand, alge-
braic specifications as well as the synchronization mechanism allow the specifier
to describe a system in an abstract way. On the other hand, the state/event based
modeling provided by the Petri nets allows an operational system description.
The formal semantics of CO-OPN/2 will be adapted to an operational se-
mantics for a further version of our development environment SANDS/2. The
semantics given here is a step semantics expressing the full inter and intra con-
current behaviors of the objects of a specification and it is built using SOS
The CO-OPN/2 Formalism 129
inference rules. The sub-typing relation needs quite a complex treatment at the
semantics level through observational semantics and is sketched here.
Lastly, a medium-sized case study is summarized to illustrate the specifica-
tion phase with CO-OPN/2 and to provide a way for evaluating our formalism
by comparison with the same exercise with other object-oriented Petri net for-
malisms.
Future work will be mainly devoted to provide a complete methodology for
the development of distributed systems. For this purpose we will include a coor-
dination layer [9], and introduce intermediate levels of sub-typing to provide the
specifier with more flexible specialization constraints. Refinements techniques are
also under study in order to have a framework for the development of concrete
application from abstract specifications.
Acknowledgments
We wish to thank Julie Vachon and Jarle Hulaas for their numerous and valuable
comments on this paper. We also thank anonymous referees for their comments
on an earlier version of this paper. We are also grateful to all members of the
ConForM group who contributed to this work.
References
1. Pierre America. Inheritance and subtyping in a parallel object-oriented language.
In J. Bézivin, J.-M. Hullot, P. Cointe, and H. Lieberman, editors, ECOOP’87: Eu-
ropean conference on object-oriented programming: proceedings, volume 276 of Lec-
ture Notes in Computer Science, pages 234–242, Paris, France, June 1987. Springer-
Verlag.
2. Pierre America. A behavioural approach to subtyping in object-oriented program-
ming languages. Technical Report 443, Philips Research Laboratories, Nederlandse
Philips Bedrijven B. V., April 1989. Revised from the January 1989 version.
3. E. Battiston, A. Chizzoni, and F. De Cindio. Inheritance and concurrency in
CLOWN. In Proceedings of the “Application and Theory of Petri Nets 1995”
workshop on “Object-Oriented Programming and Models of Concurrency”, Torino,
Italy, June 1995.
4. Olivier Biberstein. CO-OPN/2: An Object-Oriented Formalism for the Specifica-
tion of Concurrent Systems. PhD thesis, University of Geneva, July 1997.
5. Olivier Biberstein, Didier Buchs, and Nicolas Guelfi. CO-OPN/2 applied to the
modeling of cooperative structured editors. Tech. Report 96/184, Swiss Fed-
eral Institute of Technology (EPFL), Software Engineering Laboratory, Lausanne,
Switzerland, 1996.
6. Olivier Biberstein, Didier Buchs, and Nicolas Guelfi. Using the CO-OPN/2
formal method for groupware applications engineering. In Proceedings of the
IMACS-IEEE-SMC conference on Computational Engineering in Systems Appli-
cation (CESA’96), Lille, France, July 1996. Also available as Tech. Report (EPFL-
DI-LGL No 96/187).
7. Olivier Biberstein, Didier Buchs, and Nicolas Guelfi. CO-OPN/2: A concurrent
object-oriented formalism. In Proc. Second IFIP Conf. on Formal Methods for
Open Object-Based Distributed Systems (FMOODS), pages 57–72, Canterbury, UK,
March 1997. Chapman and Hall, London.
130 O. Biberstein, D. Buchs, and N. Guelfi
8. Didier Buchs and Nicolas Guelfi. CO-OPN: A concurrent object-oriented Petri nets
approach for system specification. In M. Silva, editor, 12th International Confer-
ence on Application and Theory of Petri Nets, pages 432–454, Aahrus, Denmark,
June 1991.
9. Mathieu Buffo. Contextual Coordination: a Coordination Model for Distributed
Object Systems. PhD thesis, University of Geneva, 1997.
10. Joseph A. Goguen and José Meseguer. Order-sorted algebra I: Equational de-
duction for multiple inheritance, overloading, exceptions, and partial operations.
TCS: Theoretical Computer Science, 105(2):217–273, 1992. (Also in technical re-
port SRI-CSL-89-10 (1989), SRI International, Computer Science Lab).
11. N. Guelfi, O. Biberstein, D. Buchs, E. Canver, M-C. Gaudel, F. von Henke, and
D. Schwier. Comparison of object-oriented formal methods. Technical Report
Technical Report of the Esprit Long Term Research Project 20072 “Design For
Validation”, University of Newcastle Upon Tyne, Department of Computing Sci-
ence, 1997.
12. Alain Karsenty. GroupDesign : un collectitiel synchrone pour l’édition partagée
de documents. PhD thesis, Université Paris XI Orsay, 1994. Also in Computing
System: “GroupDesign: Shared Editing in a Heterogeneous Environment”, vol. 6,
no. 2, pp. 167–192, 1993.
13. Charles Lakos. The consistent use of names and polymorphism in the definition
of object Petri nets. In Proceedings of the “Application and Theory of Petri Nets
1996”, volume 1091 of Lecture Notes in Computer Science, pages 380–399, Osaka,
Japan, June 1996. Springer.
14. Barbara Liskov and Jeanette M. Wing. A behavioral notion of subtyping. ACM
Transaction on Programming Languages and Systems, 16(6):1811–1841, November
1994.
15. David Park. Concurrency and automata on infinite sequences. In P. Deussen,
editor, Theoretical Computer Science: 5th GI-Conference, Karlsruhe, volume 104 of
Lecture Notes in Computer Science, pages 167–183. Springer-Verlag, March 1981.
16. Wolfgang Reisig. Petri nets and algebraic specifications. In Theoretical Computer
Science, volume 80, pages 1–34. Elsevier, 1991.
17. C. Sibertin-Blanc. Cooperative nets. In Robert Valette, editor, Application and
Theory of Petri Nets 1994, volume 815 of Lecture Notes in Computer Science, pages
471–490, 15th International Conference, Zaragoza, Spain, June 1994. Springer-
Verlag.
18. Alan Snyder. Encapsulation and inheritance in object-oriented programming lan-
guages. In Proceedings OOPSLA ’86, volume 21, 11 of ACM SIGPLAN Notices,
pages 38–45, November 1986.
CLOWN as a Testbed
for Concurrent Object-Oriented Concepts
Abstract. Petri nets have been considered among the variety of formalisms and
theories taken into account for giving a sound semantic basis to (concurrent)
object-oriented systems and languages. Pursuing this research direction, we
have defined a formalism called CLOWN (CLass Orientation With Nets) and
discussed on it many object-oriented concepts, with special regards to a net-
based notion of inheritance.
This paper presents the insights about the principles and the open problems of
object-orientation that we derived by modelling in CLOWN a number of small
to medium case studies.
The current results suggest, as promising future efforts, the tighter integration
with object-oriented analysis and design methodologies, especially aimed at the
Smalltalk language.
1. Introduction
The strong demand of robust distributed and network-based applications calls for
specification and programming languages provided with abstraction features to
manage their inherent complexity. Many efforts are aimed at the extensions of the
object-oriented paradigm, already employed in the development of a significant share
of business and industrial applications, with distributed and concurrent features.
Relevant research topics investigated in this thread includes:
• object-oriented principles, such as data specification, encapsulation, inheritance,
subtyping and polymorphism;
• concurrency and distribution issues, such as abstraction tools (e.g., modularity,
compositionality, observability), synchronous vs. asynchronous communication,
degree of concurrency (multithreading), qualitative and quantitative analysis
techniques for proving behavioural properties (e.g. liveness and safeness);
• and their interplay which is often source of difficulties, as the well known
"inheritance anomaly" problem shows [AWY93, McH94].
Our approach is based on Petri nets, considered also by the other research teams
working on these topics [Sib94, BB95, HV95, Lak96b, BP96, HD96, Lil96, Val96]
for giving a sound semantic basis to (concurrent) object-oriented systems and
languages. Pursuing this research direction, we have defined a formalism called
CLOWN (CLass Orientation With Nets) [Chi94] and formalised in it many object-
oriented concepts, with special regards to a net-based notion of inheritance. CLOWN
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 131–163, 2001.
Springer-Verlag Berlin Heidelberg 2001
132 E. Battiston, A. Chizzoni, and F. De Cindio
principles and syntax are briefly presented in Sect. 3. Section 4 discusses how
CLOWN faces with some of the above recalled major topics from the experimental
perspective obtained testing the formalism against several case studies. This emphasis
on practical experience is justified by our will to employ CLOWN as a testbed for
semantically sound object-oriented specifications. The conclusion summarises the
achievements, the major issues for further research and some promising development
toward a tighter integration of CLOWN with object-oriented analysis and design
methodologies, especially aimed at the Smalltalk language.
2. Foundations of CLOWN
The CLOWN main sources of inspiration are summarised in Fig. 1., where arrows
stand for an inheritance-like relation. In the following we sketch the insights that
brought us to conceive CLOWN, introducing concepts which are helpful in the sequel
of the paper.
Petri Nets
OOP
Algebraic SA nets
Specification
OBJ POTs
OBJSA
Algebraic
Nets
CLOWN
Fig. 1. CLOWN ancestors
In [ELR91] the authors point out that POTs essentially coincide with (1-safe)
Superposed Automata nets [DDPS82]; moreover they identify a strong similarity and
some differences between POPs and OBJSA nets [BDM88, BDM96], a class of
algebraic high-level nets, in the sense of [Rei91], enhanced with modularity features.
Their name reflects that they integrate Superposed Automata (SA) nets (see also
[BD92]) and the algebraic specification language OBJ [GW88]. OBJSA nets are
modular as they can be obtained by combining OBJSA (elementary) components by
transition fusion (we refer to [BDM96] for further details).
Starting from this intuition, first we realised that as a high-level formalism, OBJSA
nets have the same abstraction power as POPs, but in contrast to them, they provide a
natural representation of classes of objects. This turns out to be a good consequence
of the restrictions on the structure of the underlying net and of the tokens, which
characterise OBJSA nets among the other classes of algebraic nets. In fact these
features match with the constraints characterising POTs and also allow an easy
representation of an object's identity and data structure. In this way, the main idea
behind POTs and POPs is preserved and enriched with the possibility of modelling
classes of objects.
Once realised that OBJSA nets are well-suited to represent class-based systems,
the natural further step, according to the Wegner's classification, is to deal with
inheritance, exploiting net-based notions for dealing with behavioural aspects. The
outcome of this effort [BD93, Chi94, BCD95, BCD96] is a formal notation called
CLOWN, which includes a net-based notion of (multiple) inheritance, whose
semantics is given by an associated OBJSA net.
3. CLOWN Basics
In this section we first give a brief overview of the main clauses of CLOWN,
together with hints about its semantics in terms of OBJSA nets, and then we illustrate
them in more detail making use of the well known Dining Philosophers example. The
discussion on the main design choices and their consequences is postponed to Sect. 4.
The main building block of a CLOWN specification is the elementary class (just
class in the following). The template of a class consists of:
• a set of textual clauses that define the inheritance links, the instance data structure
and methods and the class interface (plus an additional clause concerning class
invariant properties);
• a labelled net that describes the causal relationships between methods execution; it
can be seen as the body (in the sense of Simula67 [BOMN79] and POOL) of the
class, i.e. its main method which rules the execution of the others on the basis of
the instance state.
the identity and/or the features of the communication partner(s), but imposes some
synchronisation constraints, which are specified in the class interface, to guarantee
that object synchronisation can perform correctly. The actual synchronisation is
specified by a different template: the compound class, whose semantics is an OBJSA
(non-elementary) component. An application consists of a compound class together
with the specification of a set of objects that initially exist, while other objects are
created dynamically.
Notice that each elementary class can thus be included in a variety of different
applications.
Each elementary class is specified by the following clauses (bracketed clauses are
optional):
class
The elementary class name.
[inherits]
The inheritance clause describes the relation between the class and all its parents,
and the adjustments needed to avoid inheritance conflicts. When omitted it is
assumed that the class inherits directly from the top class ROOT (Fig. 2.). This
implies that every CLOWN class inherits ROOT.
[const]
Constants are typed entities, whose type is defined by means of sorts in an algebraic
specification (ADT); their value is fixed at instance creation and never changes later
on. There is a special constant, called ID, whose value is the object name.
[var]
Variables are typed entities, whose type is defined by means of sorts in an algebraic
specification (ADT); their value can be modified at method execution (transition
occurrence).
[interface]
Each interface specifies a list of typed formal parameters detailing the incoming data
from partner objects and, optionally, a predicate pre, specifying further conditions
over the interacting partners and their formal parameter.
[places]
By means of this clause a predicate, i.e. a correctness condition, can be specified over
objects (tokens) when residing in the specified place.
[method]
The methods specify the actions that an object can execute. Their specification can
include:
[with]
This is the list of the interacting partners. When omitted the method cannot
read values from the interacting objects, but can be read from them.
[pre]
A boolean guard whose arguments can be the local variables or the
interface parameters. Whem omitted it’s assumed the default value true.
CLOWN as a Testbed for Concurrent Object-Oriented Concepts 135
[post]
The modification of the object variables value. When omitted the object
variables value doesn’t change by method execution.
net
The class net is a SA net. Each transition is labelled with a method name, which is
executed at transition occurrence, and, for readability purpose, with the interfaces
and the multiplicity of the interacting objects. Places with underlined names indicate
that objects (tokens) occurring in that place satisfy the associated predicate. Since
every CLOWN class inherits ROOT (Fig. 2.), every class net represents the objects
life-cycle (exploiting an intuition of POTs) beginning from the unborn place,
becoming alive by means of the transition create and later disappearing by moving to
dead through occurrence of the transition leave.
class ROOT
methods
create
leave
net
To illustrate these clauses, we now present the specification of the well known
Dining Philosophers problem with the slight variation of a meal counter attached to
each philosopher to show the data handling primitives.
Let us explain some features of the specification of Fig. 3. The algebraic
specification associated to this class, that we omit for space reason, consists of four
sorts: NAT are the standard natural numbers; PHNAME and FKNAME are countable
sets of names for philosophers and forks, whose generic element is denoted,
respectively, by pi and fi; FORKSNAME represents couples of forks and employs
some ad hoc algebraic operators, such as the straightforward left and right.
The interface FORK requires a parameter fid of sort FKNAME, i.e., the name of
the interacting fork. FORK appears in the with clauses as FORK (2) because each
philosopher interacts at the same time with two different forks: FORK(1) and
FORK(2) in the pre clauses identify the two forks.
136 E. Battiston, A. Chizzoni, and F. De Cindio
class PHIL
interface
FORK (fid: FKNAME);
methods
get forks
with FORK (2);
pre left(myforks) = FORK(1).fid and right(myforks) = FORK(2).fid;
release
with FORK (2);
pre left(myforks) = FORK(1).fid and right(myforks) = FORK(2).fid;
post meals <- meals + 1;
wake up
net
unborn dead
create leave
release
thinking eating
- FORK(2)
Note that not every method employs all the three subclauses; it’s also possible to
have a method without any clause, as e.g. wake up, that’s anyway significant in the
class specification to mark a step of the objects life-cycle.
The semantics of the above class is the OBJSA open elementary component of Fig.
4. It can be read as a standard SPEC-inscribed net [Rei91]. Note that output arc
labelling is omitted when it coincides with the labelling of the corresponding input
arc.
CLOWN as a Testbed for Concurrent Object-Oriented Concepts 137
HUNGRY
<FORK(1).fid; FORK(2).fid>
<n1;d1>
Get forks
Wakeup
EATING
<FORK(1).fid; FORK(2).fid>
<n2;d2>
Before introducing the compound class let us specify in Fig. 5. the partner of the
former philophers, i.e. the forks.
The desired Dining Philosophers behaviour comes from the synchronization
between a set of philosophers, instances of the elementary class PHIL, and a
corresponding set of forks, instances of the elementary class FORK.
The compound class clause specifies how a set of (elementary) classes mutually
interact. In particular it has to fix, for each formal parameter in the class interface, its
corresponding actual parameter. This is done by a view, strongly inspired by OBJ
views, as the interface is inspired by OBJ theories (the interested reader finds a
presentation of these OBJ features in [Gog84]).
138 E. Battiston, A. Chizzoni, and F. De Cindio
class FORK
inherit ROOT
interface PATRON;
methods
go with PATRON;
net
unborn dead
create leave
idle
go back
- PHIL - PHIL
busy
compound class
The compound class name.
component
The list of the elementary classes building the compound class.
view
The view is the set of all the possible instances of the interfaces formal parameters.
actions.
The actions define the method composition and list the methods of the elementary
classes involved.
The specification of the compound class DINING PHIL is given in Fig. 6. Let us
notice that in the view clause the left sides stand for a formal paremeter, while the
right sides are the corresponding actual parameters.
CLOWN as a Testbed for Concurrent Object-Oriented Concepts 139
component
PHIL;
FORK;
view
PHIL: FORK.fid = FORK.id;
FORK: PATRON = PHIL;
action
pick_forks is (PHIL.get_forks, FORK.go);
release_forks is (PHIL.release, FORK.back);
In less trivial examples, the specification of the compound class can be more
complex, essentially because the CLOWN inter-object communication scheme is a
multi-object synchronisation instead of a simple message call. To handle this feature
and preserve a fairly readable compound class clause, we rely upon interactive
syntax-driven commands in the CLOWN support environment [Con96], developed
on the top of the OBJSA Net Environment [BCCD96]. [DeR97] gives a
comprehensive mapping of the communication pattern behind the compound class
synchronization clause into Smalltalk code (see also section 5.4 below).
3.3. System
system
The name of the system (application).
model
The class (elementary or compound) to be instanced.
marking
The list of all alive objects (tokens) of a system.
The simulation of the application therefore follows the net occurrence rule: a
method associated with a transition is executable when all the input places contain at
least one token whose associated data structure (i.e., the object instance variables)
satisfies the pre clause; at the execution time, each object is moved from the input to
the output place and its data structure is modified according to the algebraic rewriting
rules of the methods.
application CONFERENCE
marking
PHIL.hungry:
(id=p1; myforks = [f1,f2]; meals = 0); (id=p2; myforks = [f2,f3]; meals = 0);
(id=p3; myforks = [f3,f4]; meals = 0); (id=p4; myforks = [f4,f5]; meals = 0);
(id=p5; myforks = [f5,f1]; meals = 0)
FORK.idle:
(id=f1); (id=f2); (id=f3); (id=f4); (id=f5)
Let us note that the system illustrated in this example generates objects only by
means of the initial marking. It’s also possible to generate new instances (and remove
active ones) dynamically at simulation time simply customising the create and leave
methods, specified in every class.
4. Theoretical Issues
In this following we present the most relevant outcomes and insights arising from our
experimentation with CLOWN, focusing on some general issues of relevance for
concurrent object-oriented systems and languages mentioned in the Introduction.
We begin with some remarks about relationships and differences between abstract
data types and objects in concurrent system specifications; then a major section about
the inheritance follows, including a discussion of the so-called inheritance anomaly
problem; finally, inter-object vs. intra-object concurrency is discussed.
As a way to specify data types, such as natural numbers, ADT are recognised to be
sound, effective and, by definition, independent from the implementation. Moreover,
the specific parameterization facilities offered by OBJ, namely the notion of theory
which supports the CLOWN interface clause, let the designer employ a very good
level of encapsulation: a component doesn’t have to know the data structure of the
partners, but just to ask for a term of a given sort.
When the system under specification includes a significant data structure, then in
CLOWN, as in other approaches (e.g. [BB95]) a choice arises to the designer:
whether to represent it as an ADT or as an object of a class. Think for example to a
stack object, to be used in a few instances in a system specification: the designer can
just reuse the elegant OBJ specification of a stack (cf. e.g. [Gog84]) instead of using a
more complex CLOWN class template enriched by a not too meaningful net. The
choice concerns the deep distinction between (abstract) data types and objects
([Coo91] is a good source of examples and discussions).
Our experience with CLOWN leads us to believe that if the entity to be specified -
the stack - behaves mostly as a private data of another object, then draw it as an ADT
of the owner; otherwise, i.e. if it’s a common and persistent component interacting
with various partners, the best choice is to build the class and instance it out. While
ADTs do not have an identifier, objects do have. This confirm the above guideline: a
variable name is sufficient to access a private/local data, while a persistent identifier
(a name) is necessary in communications, for instance for a Receiver to be sure that
gets an item from the same stack in which the Sender had stored it before.
4.2. Inheritance
that a heavy employment of inheritance as a code reuse technique collides with the
correctness of the subtyping hierarchy built among classes (cf. e.g. [Ame92, Mey93]).
Solutions to this problem have been already proposed both in the theoretical field,
by means of the creation of two different hierarchies, one for code reuse and one for
subtyping (examples are POOL-I [Ame92] and Sather [Omo93]) and in the industrial
framework, with the development of in-house mandatory reuse policies that help
designers to build consistent hierarchies. Developing CLOWN we have spent a major
effort to solve this dichotomy between conceptual rigour (strict subtyping) and
practical usefulness (code reuse).
The principle inspiring CLOWN inheritance is that each class can extend parents’
specifications and specialise them in a restricted domain. It is therefore very close to
the substitutability principle introduced and discussed in [WZ88, LW93a, LW93b].
Let A and B two objects, instances of homonymous class, being the latter subclass of
the former. Any object C, interacting with A by means of a sequence of messages m,
obtains the same answers and causes analogous internal modifications, sending the
messages m to B.
We have therefore thoroughly looked for a notion capable of supporting
substitutability when dealing with the behaviour of the CLOWN classes, represented
by the class net. Moreover we wanted to support multiple inheritance to allow
complete and straightforward representation of systems. The well-known technical
difficulties related to multiple inheritance (repeated inheritance, conflicting
hierarchies) are eased by the high level of abstraction of CLOWN specification and,
if necessary, can be unambiguously solved by the designer with a few directives.
1 ≅ 2 Š 3 Š 4 ≅ 5
ST ST ST ST
p1
p1 p1 p1 p1
p2
p2 p2 p2
p4
p4
p2 p3
p3
p3
CLASS ROOT
create leave
unbo rn 1 aliv e dea d
idle rea dy
p rin t
dea d leave 1 reset
dea d 1 1 resu me
leav e reset p rin t
Conditions over the class net and over the textual clauses are integrated as follows:
CLOWN as a Testbed for Concurrent Object-Oriented Concepts 145
Let A1…An and B n+1 CLOWN classes and let NA1…NAn and NB their
corresponding nets. Let ΣA1…ΣAn and ΣB the net systems obtained by
marking NA1…NAn and NB with a token in the place unborn. Let OAi and
OB the set of observble places of each class net, consisting of the places
belonging to the pre-set of an open transition.
However, this notion isn’t enough to completely solve the problems bound to the
semantics of inheritance, i.e., the above conditions are necessary but not sufficient.
For instance, condition (iv) does not exclude that an user defines a subclass whose
behaviour isn’t compatible with its parent.
To illustrate this unpleasant possibility, let's consider classes MonoPrinter and
Printer in Fig.10. The textual clauses of class Printer have to include an interface
attribute to get from the user the (natural) number of required copies to be printed: a
value, given by the user, is assigned to such attribute counter in the post-condition of
the load method. Count is then used in the method print, namely in the predicate
controlling the enabling of the corresponding transition, to produce the correct
number of copies. If the designer has defined count to be a natural number and the
user types "zero", no print is produced, but this would violate the ST-preorder
relation between the behaviours of classes MonoPrinter (which requires that one copy
is printed) and Printer. This odd behaviour can be easily avoided declaring count as a
positive natural number (the implementation will check that this constraint is
satisfied).
The example shows that the problems arises because of the interplay between the
class net and the textual clauses; the OBJSA net, which gives the semantics of the
class, integrates them, and therefore might be the right field for giving a sound
definition of inheritance between CLOWN classes. Unfortunately, neither ST-
equivalence and preorder, nor any other of the equivalence notions surveyed in
[PRS91] have been formulated for high-level nets.
A possible solution is to unfold the net (with some associated heuristics for dealing
with infinite domain, as discussed in [Rac94]) and define inheritance either over the
resulting Elementary Net system or over the associated Labelled Transition system
(as in [BB95]). This would formally solve the problem, but is practically unusable.
Another alternative, e.g. undertaken in [Lak96b], is to support inheritance, without
any constraints for guaranteeing behaviour compatibility, but this choice looks too
weak in a concurrent object-oriented framework.
146 E. Battiston, A. Chizzoni, and F. De Cindio
class ELEMENTARY_BOUNDED_BUFFER
inherits ROOT
var buf-store: B-BUF;
interface
SERVER (input: ITEM);
READER;
places ready: size (buf-store) • max-size;
methods
insert
with SERVER
pre size (buf-store) < max-size;
post buf-store ♦ put SERVER.input in buf-store;
remove
with READER
pre size (buf-store) > 0;
post buf-store ♦ tail (buf-store);
read
with READER
pre size (buf-store) > 0;
net
unborn
ne tail ne head
leave
dead
To capture in CLOWN this internal concurrency, the designer has to specify two
classes: Fig. 14. shows the TAIL of the buffer, receiving the new items, and Fig. 15.
presents the buffer HEAD, to read and remove items. These two (elementary, thus
sequential) classes are joint, by means of the compound class clause (Fig. 16.), in a
unique one, the COMPOUND_BOUNDED_BUFFER that exhibits the same
concurrency capabilities of Fig. 14. In fact, let us notice the strong similarity between
the net of Fig. 14. and the net associated with the compound class (cf. Fig.17.),
generated from the two class nets on the basis of the action clause. They are indeed
identical but for the shaded places of the former, due to the transition balancing
required in OBJSA nets. For sake of simplicity, the methods create and leave of both
nets are closed (internal), while in a complete specification they should be interaction
with the environment.
More in general, when a class of objects exhibits intra-object concurrency, this
means that it contains multiple threads of execution, i.e. it indeed consists of two or
more (sequential) components which mutually interact and relates themselves to the
environment as a whole. Therefore, an ad hoc language feature for intra-object
concurrency is not strictly necessary.
5. Applicative Issues
Among the case studies which have been considered for mutually compare the
various formalisms combining nets and object-orientation - sorts of common
benchmarks of the teams working in the field - the most relevant one, both in size and
inherent complexity is the specification of a cooperative editing environment, a
proposal suggested for the contribution to the "2nd International Workshop on
Object-Orientation and Models of Concurrency [OOMC95].
In the following, we first sketch this case study and then discuss a major issue,
namely polymorphism. It is worth discussing polymorphism as an applicative topics,
rather than a theoretical one, because CLOWN is not an object-oriented programming
language, but an object-oriented specification language.
CLOWN as a Testbed for Concurrent Object-Oriented Concepts 149
class TAIL
inherits
ROOT
redefine var id: BB-NAME;
var rear: B-BUF;
interface
SERVER (input: ITEM);
CLIENT;
place
empty_tail, ne_tail: size (rear) • max-size - 1;
methods
insert
with SERVER
pre size (rear) < max-size;
post rear <- put SERVER.input in rear;
put
with CLIENT
post rear <- tail (rear);
net
insert put
- SERVER - CLIENT
ne tail
insert put
- SERVER - CLIENT
The proposed case study [BLP96] concerns the architecture of a tool for synchronous
groupware, whose main functionality is the possibility to manage a hierarchical
graphical specifications, that can be accessed at the same time by many users with
different privileges.
Our solution specialises the case study proposal, quite generic in essence for sake
of flexibility, with the principles of a CASE tool already available for ONE
[BCCD96], the development environment for OBJSA nets. The existing tool that we
have considered is ONESyst [Ber95], the ONE module supporting the preliminary
phase of a system specification with OBJSA nets. It employs a hierarchical notation
inspired both by SADT diagrams [MM88] and by some object-oriented design
methodologies [CY91, DLF93].
150 E. Battiston, A. Chizzoni, and F. De Cindio
class HEAD
inherits
ROOT
redefine var id: BB-NAME;
var content: ITEM;
interface
STORE (input: ITEM);
READER;
methods
get
with STORE
post content <- STORE.input;
remove
with READER
post content <- null;
read
with READER
net
unborn create empty head leave dead
ne head
action
create is {HEAD.create, TAIL.create};
transfer1 is {TAIL.put, HEAD.get} synch size (TAIL.rear) == 1;
transfer2 is {TAIL.put, HEAD.get} synch size (TAIL.rear) • 2;
release is {HEAD.leave, TAIL.leave};
binding
HEAD:
STORE is TAIL with input = head (buf-store);
TAIL:
CLIENT is HEAD;
end
unborn unborn
create
empty tail empty head
transfer1
insert insert read remove
- SERVER - SERVER - READER - READER
transfer2
ne tail ne head
release
dead dead
ONESyst employs three kinds of graphical objects (to avoid confusion, said "shape"
or "items" in the following): boxes, components and pages. Boxes are abstract items
of which just some data and actions are known; they correspond to subsystems which
the designer is not interested to fully specify. Components are characterised by an
algebraic data structure completely specified; they are the candidates for a
corresponding OBJSA elementary components. Pages can be opened and filled with
further items, building the hierarchical structure of the diagram. Every item is
connected by one or more links to the other items of the diagram.
As boxes are the most generic items, the corresponding BOX class, presented in
Fig.18, describes the standard behaviour and the basic attributes shared by all the
ONESyst items.
152 E. Battiston, A. Chizzoni, and F. De Cindio
class BOX
var
appearence: GX;
actions: LIST-OF-ACTION;
data: LIST-OF-DATA;
links: LIST-OF-LINK;
owner: USER-NAME
delete: BOOL;
interface
IG (iid:ITEM-NAME; app: GX; acts: LIST-OF-ACTIONS;
data: LIST-OF-DATA; own:USER-NAME);
GUI (app: GX; acts: LIST-OF-ACTIONS; data: LIST-OF-DATA;
links: LIST-OF-LINK);
SM (uid: USER-NAME);
methods
create
with IG;
post id <- IG.iid; appearence <- IG.app; actions <- IG.acts;
data <- IG.data; links <- nil; owner <- IG.own; delete <- true;
add
with IG;
cancel
with IG;
delete
with SM;
lock
with SM;
post owner <- SM.uid;
unlock
with SM;
post owner <- none;
delete <- false;
link
with SM;
modify
with SM;
post appearence <- GUI.app;
actions <- GUI.acts;
data <- GUI.data;
links <- GUI.links;
info
with SM;
net
add delete
- IG - SM
Components are almost identical to boxes, but for the property that it’s data
structure is complete, so that the (redefined) method add can produce the algebraic
domain of the associated OBJSA component. The domain is [automatically] defined
by the algebraic operator choose, that browses the sorts associated to the component.
Note that the COMPONENT class, shown in Fig. 20, does not include the net, as it is
identical to the net of the parent class.
5.3. Polymorphism
class PAGE
inherits BOX;
interface
SM (current: ITEM-NAME)
IG (new: ITEM-NAME)
methods
open
with SM;
put item
with IG;
post inner <- put SM.current;
get item
with SM;
post inner <- get SM.current from inner;
net
create cancel
unborn ready dead
-IG -IG
add delete
-IG -SM
link modify
-SM -SM
Let us focus on the structure of the class net, namely on its two conflicts. The first
one corresponds to the user’s choice among one of the possible items: a box item
(BIT), a component item (CIT) and a page item (PIT). The user is then asked to
confirm or decline her/his choice.
CLOWN as a Testbed for Concurrent Object-Oriented Concepts 155
class COMPONENT
inherits BOX;
methods
add
with IG;
post domain <- choose (data)
var
appearence: GX;
actions: LIST-OF-ACTION;
data: LIST-OF-DATA;
token: DOMAIN
owner: USER-NAME;
interface
SM (box: ITEM-NAME);
GUI (app:GX; acts:LIST-OF-ACTION; data:LIST-OF-DATA; uid:USER-NAME);
OPAGE (outer: ITEM-NAME) pre OPAGE.outer == SM.box;
ITEM; BIT; PIT; CIT;
methods
create item
with GUI;
fill header
with GUI;
post iappearence <- GUI.app; actions <- GUI.acts;
data <- GUI.data; owner <- GUI.uid;
box item
with BIT;
page item
with PIT;
component item
with CIT;
add item
with ITEM, GUI, OPAGE;
cancel
with ITEM, GUI;
net unborn
create item
- GUI
- SM
empty
item
fill header
- GUI
choose
kind
fill
done
dead
The straightforward specification of this choice would consist (cf. Fig. 22) of a
couple of add+cancel methods for each possible shape (Boxes, Pages and
Components), each one with the appropriate interface specification: BIT, CIT, PIT,
respectively. However, a more effective solution can be adopted in CLOWN, and is
indeed employed in the class net of Fig.21. It consists in using a single couple of
add+cancel methods, whose interface is a generic ITEM that matches with all the
classes representing the graphical shapes (BOXES, PAGES and COMPONENTgiven
in Fig.19, 20 and 21). Through the specification of method composition in the action
CLOWN as a Testbed for Concurrent Object-Oriented Concepts 157
An issue that we recently tackled with CLOWN is code generation (cf. also [EK94]),
i.e. the automated production of object-oriented code starting from CLOWN
specifications. This topics introduces both theoretical and engineering difficulties. On
the theoretical side one has to deal with the translation of inherent concurrent
specification in sequential ones, while on the engineering side the effort is to produce
good code which can then be manipulated independently from the CLOWN
specification it comes from.
The target language that we chose is Smalltalk [GR89], the forefather of pure
object-oriented languages, now by a mature development environment. The whole
translation process of a CLOWN specification in Smalltalk code is given in [DeR97].
The first step is the translation of the net associated to each CLOWN class into a
textual format, called TCLOWN. The generation of a Smalltalk class corresponding
to a TCLOWN elementary class is then straightforward, but for the resolution of the
inheritance legacy clause whose technique is shown in [Chi94].
Compound classes are harder to translate for the reason why Smalltalk virtual
machine implements message passing by means of remote procedure calls and
doesn’t support real multitasking. To produce Smalltalk code reusable in real
applications, we did the choice to exclude the net simulation engine, underlying each
CLOWN specification. Instead, each class has the capability to check the firing rules
of its own superposed transitions. The events handling mechanism, native in the
Smalltalk kernel, has shown particularly apt to fulfill this task.
Smalltalk choice looks quite appropriate for handling algebraic specifications too.
In fact, most of the OBJ specification associated to CLOWN classes in the case
studies we developed, can be ported to Smalltalk with a little effort. This occurs for
the extreme dinamicity of the language and because Smalltalk is a pure object-
oriented language, i.e. all of its computational entities are homogeneously treated as
158 E. Battiston, A. Chizzoni, and F. De Cindio
objects. For handling the (few) remaining cases, [DeR97] gives the specifications
for emulating the OBJ interpreter in the Smalltalk environment.
A definite advantage in generating Smalltalk code starting from CLOWN
specification is the automatic production of the preconditions associated to the net
places and pre- clauses, allowing the production of a safe Smalltalk code from the
start. For safe Smalltalk code we mean an application whose method calling usually
depends upon the state of the receiver object. Smalltalk programmers are often forced
to use ad hoc attributes (instance variables) to include these constraints, while
Smalltalk code generated from a CLOWN spec's includes them by free.
6. Conclusions
First of all, inheritance deserve further investigation to understand if and how the
net based notion of state-observability, that we employ in CLOWN, can be merged
with action-observability, as suggested, e.g., in [Nie93, BB95, HV95]. Along this
thread, a worth suggestion comes from [Ame89], where the author claims: “we
propose … to make a clear distinction between inheritance and subtyping, where
inheritance deals with the internal structure of the objects, while subtyping, on the
other hand, deals with their externally observable behaviour” (i.e. the offered
services). State-observability looks appropriate for dealing with objects internal
structure, while action-observability naturally faces with the externally observable
behaviour.
Finally, our interest for non toy applications requires to complete and improve the
CLOWN support environment. The recent and very satisfactory implementation of a
code generator [DeR97] looks very promising and opens new opportunities in the
field of object-oriented analysis and design techniques, since CLOWN templates
seems to provide a guideline for producing well-formed classes, and look close to the
principles of the Smalltalk main role-driven design technique [WWW90]. This
suggests to reimplement in Smalltalk the tool supporting CLOWN classes definition,
which was previously impelmented on the top of the ONE tool [BCCD96].
Acknowledgements
This research has been carried on with the financial support of the Italian MURST,
40% on “Modelli della computazione e dei linguaggi di programmazione”. Moreover
the authors wish to thank Claudia Balzarotti, Stefano Beretta, Fabio Conca, Lorenzo
Capra and Piercarlo Della Rossa for the friendly collaboration and Olivier Biberstein,
Didier Buchs and Charles Lakos for the helpful discussions during all the CLOWN
development.
References
Rüdiger Valk
1 Introduction
With the emergence of object systems and object-oriented programming also a number
of papers have been published combining this modelling technique with Petri net
models [2], [6], [7], [11]. This appears to be quite natural since both, object-oriented
modelling as well as modelling by Petri nets, intend to support software development
by abstraction of objects from the real world and then using the model to build a
language-independent design organized around these objects. Both approaches promote
better understanding of requirements, clearer designs, and more maintainable systems.
Object-oriented modelling means that software is designed as the interaction of
discrete objects, incorporating both data structure and behaviour [10]. However, in
most contributions, if formal techniques for describing the behaviour of objects in an
object-oriented model are provided at all, these are usually equivalent to finite
automata. In particular if concurrent behaviour is important, system modellers have to
fall back on rather intuitive and informal methods. Here are the advantages of system
modelling by Petri nets. They combine intuitive approaches with a formal tratment of
systems and behavioural description. In addition they provide a deep and fundamental
theory of concurrency.
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 164-195, 2001.
Springer-Verlag Berlin Heidelberg 2001
Concurrency in Communicating Object Petri Nets 165
From a Petri net view objects appear in the form of tokens. During the last decade
tokens have been considered as more and more complex data objects. In this paper we
continue our previous work [13] by adding dynamical aspects to such token-objects.
To integrate this approach into the systematics of Petri net modelling, it is quite
natural to consider dynamical tokens as Petri nets themselves.
A: a1/M1 → a2/M2
B: b1/M1 → b2/M2
C: c1/M1 → c2/M3
approach in the sense that the task is to be modelled as an object that enters machine
M1 and leaves it after execution to be then transferred to machine M 2. Attached with
the object there is an „execution plan“ specifying the machines to be used and the
order for doing so. Also the current „status“ of the execution is noted.
Fig. 1.3. Follower marking of the object system from Fig. 1.2.
This situation is formalized by the Petri nets of Fig. 1.2., where the two modes of
machine M1 are modelled by two different transitions M 11 and M 12. Mutual exclusion
is obtained by the places p2, O1 and O2. Initially, all three tasks A, B and C are in the
place p1 (in the net on the right-hand side). By the „object -oriented“ approach they are
not represented by an unstructured token, but by their entire execution plan, as given
on the left-hand side, also as Petri nets. Note that by the marking in the nets A, B and
C also their „status“ description is given.
Labels at a subtask of the form <mach11> indicate that this subtask can be executed
by any machine with the same label, i.e. by M 11 in this case. Following this
convention, transition M11 of the „machine net“ on the right-hand side of Fig. 1.2. can
occur with respect to A in its input place p1. The whole „task net“ is then moved as a
token to the output place p 3, as shown in Fig. 1.3. The internal token of A is also
moved from s1A to s2A to update the current execution „status“ of the task.
To have a precise and unambiguous notation we will distinguish between a system
net and one or several object nets. In the example presented before, the „machine net“
is the system net whereas the „task nets“ A, B and C are the object nets. The relation
between transitions of the system net and transitions of the object net will be called
the interaction relation. This relation is represented by labels (enclosed sharp brackets)
in the graphical representation.
In the preceding example the executions of the tasks A, B and C are independently
performed. This type of concurrency is restricted only by resource limitations of the
system net. For instance, in the marking given in Fig. 1.3. task A can be executed on
machine M 2 while task B (or task C) is concurrently executable on M 12. A more
realistic application to flexible manufacturing systems is given in [19].
Concurrency in Communicating Object Petri Nets 167
Another type of concurrency is exemplified by the object system of Fig. 1.4. In its
object net, after termination of the subtask a1 (on machine M 1), there are two
successor tasks a2 and a3. They can be executed independently if there are suitable
functional units (machines) being able to perform the execution concurrently. The
system net in Fig. 1.4. (on the right-hand side) offers such a suitable system
architecture: after the occurrence of transition t1 two identical descriptions of the object
net (both with its current marking) are generated and placed in p 5 and p 7. With respect
to the instance of the object in p5 the subtask a2 is executable on M 2, while
concurrently the subtask a3 of the object net instance in p7 is executed by M 3. The
„results“ of the partial executions are then „brought together“ by transition t2 , which
outputs the combined and final result to the place p 4. Hence, from an intuitive point
of view, M2 and M3 produce partial results that are independent from each other. They
are „put together“ into a single task description by transition t2 . Here the precise
semantics of this action in terms of Petri nets will be left open. This will be one of
the results to be described in section 3. We will refer to this kind of concurrency as
intra-object concurrency, as opposed to concurrent behaviour of two different objects.
Using standard definitions of Petri net theory the preceding examples can be encoded
either as a „flat“ net by identifying corresponding transitions or as a coloured net with
appropriate data type definitions in the colour sets (compare with [8]). In this paper we
follow a different approach: object and system nets are defined (as simple as possible)
as Elementary Net Systems ("EN systems", formerly condition/event-systems),
including the occurrence rule of this net type. Using the individual occurrence rules of
the component nets, by combination of the individual EN-systems, Object Systems
will be introduced, which allow to model real systems directly in the style of object
oriented modelling. In doing this, we are led by the experience that has been made by
the development of higher Petri nets (Pr/T-nets, coloured nets) from "lower" Petri nets
(C/E-nets, P/T-nets), namely, that new features should be introduced in accordance
with basic principles of concurrency theory, as formulated by C.A. Petri.
168 R. Valk
For the first time, Petri nets as dynamical objects have been considered for
describing the execution of task systems in systems of functional units [4],[13],[14].
In [16] the formalism is extended in such a way that the objects are allowed to be
general EN systems not necessarily restricted to (non-cyclic) causal nets.
Object-oriented modelling and programming, as appearing in current literature, is
characterized by a specific object notion together with many features like generation
and deletion of objects, defining classes and subclasses, inheriting attributes and many
more. We do not incorporate all these features in our model as we are concentrated on
such properties that can be expressed on the level of EN systems. This is done to
master the complexity of the new approach. It is easier to define new models than to
derive formal results. However, working on formal theories gives important hints for
a suitable design of the model. Where the system net and all object nets are EN
systems object systems will be called Elementary Object Systems.
Section 2 is concentrated on the study of object systems having only a single
object net (Unary Elementary Object Systems). This class is introduced to investigate
the behaviour of concurrent task execution. Different notions of markings are
introduced. Finally a suitable formalism for the modelling of „fork/join“-concurrency
structures is proposed. Also a process-oriented semantics for unary elementary object
systems is given (section 3). One of the main formal results of this paper is a theorem
characterizing processes of unary elementary object systems by classical processes of
EN systems.
In section 4 Unary Elementary Object Systems are studied that allow for more than
a single object net. This class is restricted to system nets that essentially are state
machines. Therefore duplication of objects is not possible as well as intra-object
concurrency. This restriction is not necessary. It has only been made to allow for a
simpler occurrence rule and simpler semantical descriptions. On the other hand, a new
feature is introduced with this model: the direct interaction of different object nets.
Further complex examples using such an „inter-object communication“ are presented,
showing advantages of the object-oriented approach.
The main results of this contribution may be summarized as follows:
• A simple and clear notion of object Petri net is introduced such that most principles
of the elementary net theory are respected.
• A formal semantics of the behaviour is given for this net class.
• It was discovered that from the different choices for the definition of markings and
occurrence rules, not all of them allow a meaningful and consistent modelling of
object-oriented concurrency.
• Processes of Elementary Net systems are extended to the model in a natural way. A
low-level characterization of such higher-level processes is given and the
equivalence is formally proven.
• Unary object systems are consistently extended to multiple objects.
At the end of this introduction we now give a less artificial example of an unary
elementary object system with intra-object concurrency. In the example a workflow of
the Dutch Justice Department is modelled. It has been used for demonstration of
modelling and analysis of workflow applications using Petri nets [1].
Concurrency in Communicating Object Petri Nets 169
<verifying>
complete examine
<summ> <prosec> <ex>
summon dec1
<char> <prosec>
charge dec2
suspend dec3
<verifying>
<recording>
<ex> <printing> secretary <join1>
<summ>
<susp>
<char>
official3
tribunal
The example was introduced as follows. When a criminal offence happened and the
police has a suspect a record is made by an official. This is printed and sent to the
secretary of the Justice Department. Extra information about the history of the suspect
and some data from the local government are supplied and completed by a second
official. Meanwhile the information on the official record is verified by a secretary.
When these activities are completed, the first official examinates the case and a
prosecutor determines whether the suspect is summoned, charged or that the case is
suspended.
Originally the case was modelled by a single and „flat“ net for the workflow. A
slightly modified version is given as an object net in Fig. 1.5. Observe that, indeed,
verification and completion are concurrent subtasks. The labels in sharp brackets refer
to the corresponding functional units (in Fig. 1.6.) executing these subtasks. For
instance „printing“ is executed by a printer and „verifying“ is executed by the
secretary. Official1 is executing two subtasks (record and examine) for this object net.
As there are three possible outcomes of the decision of the prosecutor that are followed
by different actions, the decision is modelled by three transitions dec1, dec2 and dec3.
Though being more complex the advantage of this kind of modelling by object nets
lies in the direct representation of the functional units. The system net in Fig. 1.6.
reflects the organisational structure of the system while the object net (Fig. 1.5.)
represents a particular workflow. Obviously there may be different workflows (object
nets) for the same system of functional units (system net). The simultaneous
simulation of different such executions can be used to determine bottlenecks and
execution times.
Definition 2.1
An unary elementary object system is a tuple EOS = (SN,ON,ρ) where
SN= (P,T,W,Mo) is an EN system with |Mo| =1, called system net of EOS,
ON = (B,E,F,mo) is an EN system, called object net of EOS, and
ρ ⊆ T × E is the interaction relation.
An elementary object system is called simple if its system net SN is a state machine.
Fig. 2.1. gives an example of an elementary object system with the components of an
object net ON on the left-hand and a system net SN on the right-hand side. The
interaction relation ρ is given by labels <in> at t and e iff tρe ("in" stands for
interaction number n). A similar object net is used in Fig. 2.3. (i1 is removed to
illustrate autonomous transitions), but with a different system net. By this system net
the "parallel" transitions e2 and e3 perform in a serial way. Since the system net is a
state machine, the object system is simple.
Before coming to formalization we describe the intuition behind the occurrence rule
to be defined afterwards. The object net ON of Fig. 2.1. should be thought of lying in
place p1 of the system net SN. It is represented by a token in that place. The
occurrence of transition t1 of the system net SN should coincide with e1 in the object
net ON by the interaction i1. The object net ON is then removed from p1 and added to
p2 and p4 in two copies, both of them being in the marking {b2,b4}. Then we observe
some concurrent behaviour ending with a kind of „join“ operation by the interaction i4
of t7 and e4. Furthermore, there are transitions without interaction like the so-called
"autonomous" occurrences of t8 or e5
In the definitions of the occurrence rule we will use the following well-known
notions for a binary relation ρ. For t ∈ T and e ∈ E let tρ := {e ∈ E | (t,e) ∈ ρ } and
172 R. Valk
ρe: = {t ∈ T | (t,e) ∈ ρ}. Then tρ = Ø means that there is no element in the interaction
relation with t.
Definition 2.2
A bi-marking of an unary elementary object system EOS = (SN,ON,ρ) is a pair
(M,m) where M is a marking of the system net SN and m is a marking of the object
net ON.
a) A transition t ∈ T is enabled in a bi-marking (M,m) of EOS if tρ = Ø and t is
enabled in M. Then the successor bi-marking (M’,m‘) is defined by M→ tM' (w.r.t.
SN) and m‘=m. We write (M,m) →[t,λ] (M‘,m‘) in this case.
b) A pair [t,e] ∈ T × E is enabled in a bi-marking (M,m) of EOS if (t,e) ∈ ρ and t and
e are enabled in M and m, respectively. Then the successor bi-marking (M‘,m‘) is
defined by M →t M‘ (w.r.t. SN) and m →e m‘ (w.r.t. ON).
We write (M,m) →[t,e](M‘,m‘) in this case.
c) A transition e ∈ E is enabled in a bi-marking (M,m) of a EOS if ρe = Ø and e is
enabled in m. Then the successor bi-marking (M‘,m‘) is defined by m → e m‘ (w.r.t.
ON) and M‘ = M. We write (M,m) →[λ,e] (M‘,m‘) in this case.
In transition occurrences of type b) both the system and the object participate in the
same event. Such an occurrence will be called an interaction. By an occurrence of type
c), however, the object net changes its state without moving to another place of the
system net. It is therefore called object-autonomous or autonomous for short. The
symmetric case in a) is called system-autonomous or transport, since the object net is
transported to a different place without performing an action.
Concurrency in Communicating Object Petri Nets 173
By extending this notion to occurrence sequences for the EOS of 2.3., for example,
we obtain the following sequence: [λ,e1], [t1,λ], [t4,e3], [t5,e2], [t6,λ], [t7,e4], [λ,e5] .
After this sequence, the initial bi-marking is reached again. We call this the occurrence
sequence semantics. It is possible to characterize the set of all such occurrence
sequences of simple EOS by some kind of intersection of the individual occurrence
state of its execution. Such a state is now described by a process of the object net ON.
Hence a marking associates a process proc ∈ PROC(ON) to every place p ∈ P. In
order to distinguish this form of a marking from the one in the previous section, we
call it a "process-marking" or in short a "p-marking".
Definition 2.3
A process-marking (p-marking) M of an elementary object system EOS = (SN,ON,ρ)
is a mapping M: P → PROC(ON), associating to each place of the system net SN a
process proc of the object net ON (including the empty process). If in a p-marking M
of an EOS M(p) = Ø (the empty process), we say the place is empty, else occupied.
The set CM := {p ∈ P | M(p) ≠ Ø } of occupied places defines a case or marking of
EOS.
In this definition PROC(ON) denotes the set of all processes of ON. (For definitions
concerning processes see appendix.) For introducing the new occurrence rule, consider
the EOS of Fig. 2.1. In the initial marking the process consisting of b1 is in the place
p1 of the system net. Now consider a follower state after the occurrence of [t1,e1],
[t2,e2] and [t3,e3]. For the next step t7 is enabled since all its input places are non-
empty and (t7,e4) ∈ ρ. But in addition e4 should be enabled in ON. The preconditions
of e4 are satisfied if all copies of the object net processes lying in the input places in
p3 and p5 of t7 are taken into consideration (see 2.4.). The joint information is obtained
by the least upper bound „lub“ of these processes.
Definition 2.4
Let M be a p-marking of an unary elementary object system EOS, t∈T a transition of
the system net SN and e ∈ E a transition of the object net ON.
To enable t, it is necessary in any of the following cases a) and b) that all input places
p ∈ •t are occupied, the process LUB := lub({M(p) | p ∈ •t }) exists and all output
places p ∈ t• are empty in M.
In case a), where tρ=Ø, transition t is enabled and we write M→ [t,λ].
In case b), where tρe, the pair [t,e] is enabled (denoted M → [t,e]) if e is enabled for
LUB (cf. appendix).
For both cases a) and b) the follower p-marking M' is defined by M'(p) = Ø if p ∈ •t,
and for p ∈ t• we define M'(p) = LUB in case a) and M'(p) = LUB°e in case b) and
M'(p) = M(p) otherwise.
(Case a) is called a system-autonomous or a transport occurrence and is denoted by
M→ [t,λ] M‘ whereas case b) is called an interaction and is denoted by M → [t,e]M‘).
case c): If in some place p ∈ P an object net transition e ∈ E with ρe=Ø is enabled in
proc ∈ M(p), we write M→[λ,e] and define a follower marking M' by
M'(p) = proc°e and
M'(p') = M(p) for p'≠ p.
(Case c) is called an object-autonomous or an autonomous occurrence and is denoted
by M→ [λ,e] M‘).
In Fig. 2.5. all cases a), b) and c) of the occurrence rule are represented symbolically.
In this figure process inscriptions are not given. In general, however, it may depend
176 R. Valk
on these inscriptions whether the process LUB exists or does not exist. Next we
extend the definition to sequences of the form [λ,e1] [t1,λ] [t2,e2] [t3,e3] ∈ ((T∪{λ})×
(E∪{λ}))*.
Definition 2.5
For an elementary object system EOS = (SN,ON,ρ) we consider occurrence sequences
w∈ Q* where Q:=Tl× El and Tl:= T∪{λ}, El:= E∪{λ}. For such sequences and p-
markings M and M' the relation M → w M' is inductively defined by :
1. M → w M if w = [λ,λ]
2. M → wq M' if w ∈ Q*, q ∈ Q and M → w M'' , M''→ q M' for a p-marking M''.
Definition 2.6
The initial p-marking of EOS is defined using the initial markings M o and m o of SN
and ON, respectively: Mo(p):= if p∈Mo then mo else ∅. (Note that in this context mo
means the initial process of EOS, as defined in the appendix).
Definition 2.7
Given an elementary object system EOS = (SN,ON,ρ), then FS(EOS) := { w ∈ Q* |
∃ M: Mo → w M} is the set of occurrence sequences of EOS, and
R(EOS) := {M | ∃ w : Mo → w M } is the set of reachable p-markings, also called the
reachability set of EOS.
Lemma 3.1
Let EOS = (SN,ON) be an unary elementary object system and „t“ a system-
autonomous transition of SN and „e“ an object-autonomous transition of ON.
Concurrency in Communicating Object Petri Nets 177
Suppose •t= {p1} and |t•| = n ≥ 1 and M1(p1) = proc°e for some p-marking M1 (i.e. p1
contains a process where „e“ is „at the end“ (see appendix)). Then there are p-
markings M and M' such that
M → w M' where w=[λ,e][t,λ] and
M → v M' where v=[t,λ][λ,e]n.
Proof: Starting from M1 p-markings M and M' are constructed as follows in a), b):
a) Since M1(p1) has the form proc°e there is a predecessor marking M such that
M → [λ,e] M1 where M(p1) = proc and M(p) = M1(p) for p ≠ p1
b) Since t is enabled in M1 there is a follower marking M' of M1 (i.e. M1 → [t,λ] M’)
where proc°e is contained in all n output places of t. By a) and b) we have M → [λ,e] M1
→ [t,λ] M'.
To prove the second part of the lemma, we observe that [t,λ] is also enabled in M,
since the unique input place p1 of t contains the process proc i.e. M → [t,λ] M2 for some
p-marking M2. In M2 all n output places of t contain the process proc in each of which
the transition e is enabled. This leads to M → [t,λ] M2 → u M' with u = [λ,e]n.
q. e . d.
a)
t
e
e
b)
c)
[ e]
While object autonomous transition occurrences are not part of SN processes, they
should be visible in the object system process. For distinction we denote them by
178 R. Valk
small and solid (black) transitions as in Fig. 3.1. and 3.2. Furthermore it is straight
forward to introduce an equivalent step containing both transitions as in Fig. 3.1. c).
We will call this a reduced process equivalent.
Next we inductively define a process of an elementary object system, having a set
of places P π and a set of transitions Tπ, together with mappings φ and µ. For a place x
∈ P π or a transition y ∈ Tπ of this process φ(x) and φ(y) give the corresponding place
or transition of the system net, respectively. µ(x) will be the process of the object net
ON associated to a place x. Furthermore for each place x ∈ P π the interaction relation
ρ ⊆ T × E is extended to ρx ⊆ Tπ × Eπ, where Eπ is the set of places of the process
µ(x). These mappings are given by inscriptions in the example of Fig. 3.2. as
explained after the following definition.
Definition 3.2
For a given firing sequence w ∈ FS(EOS) of an unary elementary object system EOS
= (SN,ON,ρ), where SN = (P,T,W,Mo), ON = (B,E,F,mo), a process proc(w) =
(P π,Tπ,F π,φ,µ) is a structure consisting of a causal net (P π,Tπ,F π) and mappings
φ : P π∪Tπ → P∪T∪E and µ: P π → PROC(ON).
proc(w) is defined by induction over Q*. Furthermore for each object net process proc2
= (Bπ,Eπ,F2π,φ2) = µ(x), x ∈ P π an extended interaction relation ρx ⊆ Tπ×Eπ is defined.
I. If w = λ, then P π = {pπ | p ∈ Mo} with φ(pπ) = p and µ(pπ) = m o for all pπ ∈ P. ρx is
empty.
(Note: markings are interpreted here as processes in the form of an initial process (see
appendix).
II. Let Mo → w M → [u,v]M' and proc(w) = (P π,Tπ,F π,φ,µ) be the process of w. Then for
[u.v]∈Q we define proc(w[u,v]) = (P 'π,T'π,F 'π,φ',µ') for each of the cases a), b) and c) of
definition 2.4:
a) If [u,v] = [t,λ] and tρ=∅, then there is a subset P1⊆Pπ having no output transitions
(i.e. P 1• = ∅) such that φ(P 1) = •t. By the enabeling rule all places x in P 1 contain a
process µ(x)=proc1 such that their least upper bound LUB:=lub{µ(x)|x∈P 1} exists. To
obtain (P π‘,Tπ‘,F π‘,φ‘,µ‘) we have to do the following steps :
a1) Add a new set P2 of places to P π such that φ‘(P2)=t•, (i.e. P π‘ = P π ∪ P2).
a2) Add a new transition y with φ‘(y) = t to Tπ (i.e. Tπ‘ := Tπ ∪ {y}).
a3) Add arcs from P1 to y and from y to P2
(i.e.: F π‘ := F π ∪ { (x,y) | x ∈P1 } ∪ {(t‘,p)|p∈P2}).
a4) Define φ‘ = φ for all old places and transitions and for the new ones as defined
in a1) and a2).
a5) Define µ‘(x) = µ(x) for the old places x ∈ P π and for the new places x2 ∈ P2 with
φ(x2) ∈ t• we define µ‘(x2) := LUB (i.e. the output places of t contain the same process
LUB. ρx for x ∈ P2 remains as in the old places.
b) If [u,v] = [t,e] and tρe, then P1 exists as in case a). The steps b1) to b4) are defined
as a1) to a4), respectively.
Concurrency in Communicating Object Petri Nets 179
Fig. 3.2.: A process of the object system „Con-Task“ from Fig. 2.1.
180 R. Valk
b5). Define µ‘(x) = µ(x) for the old places x ∈ Pπ and for the new places x2 ∈ P 2 with
φ(x2) ∈ t• we define µ‘(x2) :=LUB°e (i.e. the output places of t contain the process
LUB extended by e ). (y,e2) is added to ρx for x ∈ P2 and the new e2 with φ2(e2) = e.
c) If [u,v] = [λ,e] and ρe = ∅, then there is a place x∈Pπ with x•=∅ such that "e" is
enabled in the process proc1=µ(x).
c1) Add a new place x2 to Pπ (i.e. P π‘ = P π ∪ {x2}).
c2) Add a new transition y with φ(t) = e to Tπ (i.e. Tπ‘ := Tπ ∪ {y}
c3) Add arcs from x to y and from y to x2 (i.e.: F π‘ := F π ∪ { (x,y), (y,x2)}).
c4) Define φ‘ = φ for all old places and φ'(x2) = φ(x1) .
c5) Define µ‘(x) = µ(x) for the old places x ∈ P π and for the new place x2 ∈ P2 we
define µ‘(x2) :=proc1°e (i.e. the output places of y contain the same processes as the
input places but extended by a new e2 with φ2(e2) = e). ρx is not modified.
Lemma 3.3
With the notation of def. 3.2 the following holds: for each place x ∈ P π , procx =
(Bπ,Eπ,Fxπ,φxπ) = µ(x), and e ∈ Eπ with ρπe ≠ ∅ there is some transition y with
y<proc(w)x (i.e. y "before" x) such that yρπe.
Proof: e is either introduced to procx in µ(x) in step II b) of definition 3.2 (then yρπe
for some y ∈ •x ) or e is created with a copy of proc2 from some x ∈ •y in one of the
other steps (in that case the statement holds by induction). q.e.d.
Definition 3.4
An autonomous transition y of an object system process as introduced in definition
3.2 c) has a unique input place x1 and a unique output place x2 with φ(x1) = φ(x2).
Therefore identifying x1 and x2 to a new place x and eliminating y gives a consistent
notion of a process. For the merged place x the contained process µ(x) is defined by
µ(x1) if x2• ≠ Ø and µ(x2) if x2• = Ø. The causal net (P π,Tπ,F π,φ,µ) obtained by
iterating this construction until all autonomous transitions are eliminated is said to be
"in reduced form".
Definition 3.5
Let EOS = (SN,ON,ρ) be an elementary object system with SN= (P,T,W,Mo) and ON
= (B,E,F,mo). Given a process proc = (P π,Tπ,F π,φ,µ) of EOS (def. 3.2) having a latest
place xω (see appendix for a definition) a cop-process (process in co-operating process
form) of EOS is defined as a triple
Θ = (proc1,proc2,ρπ) where
proc1= (Pπ,Tπ,F1π,φ1) ∈ PROC(SN),
proc2= (Bπ,Eπ,F2π,φ2) ∈ PROC(ON) and
ρ π ⊆ T π × E π.
where proc1 = (P π,Tπ,F π,φ) (i.e proc without µ), proc2 = µ(xω) and ρπ as defined in def.
3.2 w.r.t. proc2 and xω i.e. ρπ := ρxω.
For an example consider the process of Fig. 3.2. from the beginning x1 up to the
place x7 (and delete y 6, x 8, y 7, x9 and x10). With respect to this shorter process we
construct the reduced form (def. 3.4) by merging x 6 and x7 to a new place x with µ(x)
= µ(x7) (since x7• = Ø) and φ1(x) = φ1(x6) = φ1(x7) = p6. x is a latest place xω. Fig. 3.3.
gives the result of the construction: proc1 is drawn in the lower part and proc2 = µ(x7)
in the upper one. The definition can be extended to cover the case of the whole process
of Fig. 3.2. as well. Then the object net processes in the terminal cut (cf. appendix) of
proc(w) should have a least upper bound LUB. Note that a cop-process representation
of EOS-processes leads to a more consistent notion of concurrency. While Lemma
3.1 is describing concurrency properties int he style of interleaving semantics, cop-
processes represent independent actions by unrelated transition. To give an example, in
the cop-process form of a EOS-process in Fig. 3.3., the object autonomous transition
e5 and the system autonomous transition t8 are represented without causal dependence .
Lemma 3.6
a) Given a cop-process Θ = (proc1,proc2,ρπ) of an EOS = (SN,ON,ρ) then
∀ y1∈ Tπ ∀ e1, e2 ∈ Eπ : y1ρπe1 ∧ y1ρπe2 ⇒ e1 = e2 holds.
b) There is a cop-process Θ = (proc1,proc2,ρπ) of an EOS = (SN,ON,ρ) such that
∀ y1,y2 ∈ Tπ ∀ e1 ∈ Eπ : y1ρπe1 ∧ y2ρπe1 ⇒ y1 = y2 is not true in general.
Proof: In the construction of ρπ each transition y∈Tπ appears only once, whereas e∈Eπ
may appear in different copies. In Fig. 3.5. a cop-process of the EOS from Fig. 3.4.
is shown together with the relation ρπ. The cop-process fails to have property b).
q.e.d.
Definition 3.7
Let be Tint := {y ∈ Tπ | yρπ ≠ ∅ } and Eint := {e ∈ Eπ | ρπe ≠ ∅ } the set of interactive
transitions of proc1 and proc2, respectively. To simplify the following definitions and
proofs from now on we exclude object autonomous transitions, i.e. we assume
Eint=Eπ.
Then (by lemma 3.6 a)) ϕ : Tint → Eπ with (ϕ(y) = e ⇔ yρπe) is a mapping. ϕ may be
non-injective (by lemma 3.6b) but is surjective, however. Hence, a cop-process Θ =
(proc1,proc2,ρπ) can be represented by Θ = (proc1,proc2,ϕ). Using this notation lemma
3.3 can be rewritten as follows.
Concurrency in Communicating Object Petri Nets 183
Lemma 3.8
Given a cop-process Θ = (proc1,proc2,ϕ), then e1 <proc2ϕ(y) implies
∃y1: y1 <proc1 y ∧ ϕ(y1) = e1 .
Proof: By definition e=ϕ(y) iff yρπe in the corresponding EOS-process "proc". By
induction on the construction of proc transitions e1 and e are in µ(p) for any p∈y•. By
lemma 3.3 there is a transition y1<procp with y1ρπe. By lemma 3.6 (since yρπe) y1≠y,
hence y1 <proc y <proc p, and also y1 <proc1 y <proc1 p. q.e.d.
This lemma motivates a property, called extended process morphism property (EMP),
that generalizes the notion of process morphism.
Definition 3.9
Given an elementary object system EOS = (SN,ON,ρ) and processes
proc1 = (Pπ,Tπ,F1π,φ1) ∈ PROC(SN) , proc2 = (Bπ,Eπ,F2π,φ2) ∈ PROC(ON) and a
mapping ϕ: Tint → Eπ .
ϕ is called interaction true or true if
a) ϕ is surjective,
b) ∀ y ∈ Tint ∀ e ∈ Eπ : ϕ(y) = e ⇔ φ1(y)ρφ2(e)
c) ∀ y1,y2 ∈ Tπ : y1 <proc1 y2 ⇒ ϕ(y1) ≠ ϕ(y2)
The triple Θ = (proc1,proc2,ϕ) has the extended process morphism property (EMP) iff:
e1 <•proc2 e2 ∧ y2 ∈ ϕ-1(e2) ⇒ ∃ y1 <proc1 y2 : ϕ(y1) = e1
(<•proc2 ⊆ < proc2 denotes the immediate successor relation of < proc2 restricted to
transitions.)
By a) the whole object net process is reached by ϕ. b) relates the interaction relation of
the EOS to a corresponding relation on the processes. By c) causally dependent actions
are excluded to execute the same task. If ϕ is an injection, then ψ: Eπ → T int where
ψ:=ϕ-1 is a T-morphism (cf. appendix). There is a convincing interpretation of the
extended morphism property. Consider object net transitions as tasks being executed
by functional units, given here in the form of system net transitions. Then two
sequential tasks e1 and e2 with e1<e2 cannot be executed by concurrent system net
transitions (formally: e1<e2 implies ψ(e1) < ψ(e2)), as for the execution of the second
task e2 the "result" of the execution of e1 is required. Hence concurrent object net
transitions may be executed sequentially but not vice versa.
Theorem 3.10
Let be given an elementary object system EOS = (SN,ON,ρ) and a triple Θ =
(proc1,proc2,ϕ), where proc1 ∈ PROC(SN), having a latest place x ω, and proc2 ∈
PROC(ON) are processes and ϕ: Tint → Eπ is an interaction true mapping. Then Θ is a
cop-process of EOS if and only if ϕ has the extended morphism property.
Proof: The necessity of the condition follows from lemma 3.8.
184 R. Valk
To prove that the condition is also sufficient, assume that Θ = (proc1,proc2,ϕ), where
proc1= (Pπ,Tπ,Fπ,φ1) ∈ PROC(SN), proc2 = (Bπ,Eπ,F2π,φ2) ∈ PROC(ON) are processes
and ϕ: Tπ → Eπ is a true mapping satisfying the EMP.
First we have to find a mapping µ: P π → PROC(ON) such that proc =
(Pπ,Tπ,Fπ,φ1,µ) is an EOS-process. This is done by defining:
µ(x):= pastproc2({ϕ(y1)| y1 <proc1 x}) ∪ init(proc2)
(As defined in the appendix, pastproc2(A) is the subprocess „generated“ by the set A.)
Next it must be shown that proc is an EOS-process, i.e. that µ is consistent with the
occurrence of definition 3.2. This is done by induction on P π w.r.t. the partial order
<proc of proc.
a) If for x ∈ P π the condition (∃ y1 ∈ Tint:y1 < proc1 x) does not hold then µ(x) =
init(proc2) by definition.
Fig. 3.5. Cop-process of the more complex unary EOS from Fig. 3.4.
186 R. Valk
In Fig. 3.4. a more complex unary elementary object system is given to illustrate the
theorem by its cop-process as in Fig. 3.5. The mapping ϕ is obviously not injective.
Moreover there are system autonomous transitions (e.g. t7). Two concurrent
transitions, as t2 and t9 with ϕ(t2) = ϕ(t9) may execute the same „task“ ϕ(t2) = ϕ(t9) =
e3. This redundancy can be useful in the design of reliable systems. The extended
morphism property can be checked. When simplifying the system net SN by deleting
the subnet from p5 to p7 the corresponding process in Fig. 3.5. becomes sequential and
no concurrent task execution is possible any more. Then ψ := ϕ-1 is a T-morphism.
To see an example of this property the first occurrences of the transitions labelled e3
and e5. Then e3 < e5 implies ψ(e3) < ψ(e5) which holds, since ψ(e3) = t2 and ψ (e5) = t11
(the labels are taken in place of the names of the transitions which are not drawn in
the figure).
In this section unary elementary object systems are extended in such a way that
different object nets are moving around in a system net and interact with both, the
system net and with other object nets. As before, the model is kept as simple as
possible in order to have a clear formalism.
Concurrency in Communicating Object Petri Nets 187
Definition 4.1
An elementary object system is a tuple EOS = (SN,ON,Rho,type,M) where
• SN= (P,T,W) is a net (i.e. an EN system without initial marking), called system
net of EOS,
• ON = {ON1,...,ONn} (n≥1) is a finite set of EN systems, called object nets of
EOS, denoted by ONi = (Bi,Ei,Fi,moi),
• Rho = (ρ,σ) is the interaction relation, consisting of a system/object interaction
relation ρ ⊆ T×E where E := ∪{Ei|1≤i≤n} and a symmetric object/object
interaction relation σ ⊆ (E×E)\idE,
• type : W → 2{1,...,n}∪IN is the arc type function, and
• M is a marking as defined in definition 4.2.
Definition 4.2
The set Obj := {(ONi,mi) | 1≤i≤n, mi∈R(ONi)} is the set of objects of the EOS. An
object-marking (O-marking) is a mapping M: P → 2Obj ∪IN such that M(p) ∩ Obj
≠ ∅ ⇒ M(p) ∩ IN = ∅
Definition 4.3
Let EOS = (SN,ON,Rho,type,M) be an elementary object system as given in def. 4.1
but in some arbitrary marking M. Rho = (ρ,σ) is said to be separated, if iσj ⇒ ρi =
∅ = ρj. The i-component (1≤i≤n) of EOS is the EN system SN(i) = (P,T,W(i),M0i)
defined by W(i) = {(x,y)| i ∈ type(x,y)} and M0i(p) = 1 iff (Oni,mi) ∈ M(p). The
The EOS from Fig. 4.1 is simple since each SN(i) (1≤i≤3) is a state machine and
Rho is separated. The latter property is easily deduced from the depicted graph of ρ∪σ.
The 1-component is a simple and unary elementary object system (see Fig. 4.2).
Dropping the condition that SN(1..n) is a structural state machine would lead to
inconsistencies in the definition of the dynamical behaviour (def. 4.4).
By the introduction of i-components of EOS we are able to connect the models of
unary EOS to general EOS. For instance, the semantical formalization of the
behaviour of the more complex model of a simple elementary object system can profit
from the results obtained earlier in this paper for simple unary elementary object
systems. The property of separated interaction relation Rho allows to separate
system/object interactions from the new concept of object/object interaction. The
latter form of interaction is restricted to the case where the i-components perform
autonomous transitions in the same place of the system net. Therefore in the
following definition of transition occurrence of simple EOS system/object interactions
are defined using case b) of def. 2.2 whereas object/object interactions are associated
with case c) of this definition.
Definition 4.4
Let be EOS = (SN,ON,Rho,type,M) an elementary object system as in def. 4.1 and
M: P → 2Obj ∪IN an O-marking (def. 4.2) and t ∈ T, ei ∈ Ei, ej ∈ Ej, i≠j.
a) Transition t ∈ T is enabled in M (denoted M→t) if tρ = ∅ and the following holds:
a1) t is enabled in the zero-component of SN (def. 4.3) (i.e. in the P/T-net part)
a2) By the state machine property there is at most one type i∈{1,..,n} such that i ∈
type(p1,t) and i ∈ type(t,p2) for some p1 ∈ •t and p2 ∈ t•. In this case there must be
some object (ONi,mi) ∈ M(p1).(cf. Fig. 4.3.)
Fig. 4.7. Five Philosophers II: four object nets ph_i, shr_i, ph_k and shl_k
( k = (i+1) mod 5 )
192 R. Valk
If t is enabled, then t may occur (M → t M’) and the successor marking M’ is defined
as follows: with respect to the zero-components tokens are changed according to the
P/T-net occurrence rule. In case of a2) (ONi,mi) is removed from p1 and added to p2
(only if p1 ≠ p2).
b) A pair [t,e] ∈ T×Ei with tρe is enabled in M (denoted M→[t,e]) if in addition to case
a) e is also enabled for ONi in m i. Instead of (ONi,mi) the changed object (ONi,mi+1)
where mi →e mi+1 is added.
c) A pair [ei,ej] ∈ Ei×Ej with eiσej is enabled in M (denoted M→ [ei,ej]) if for some
place p ∈ P two objects (ONi,Mi) ∈ M(p) and (ONj,mj) ∈ M(p) are in the same
place p and mi→eimi+1 and mj→ejmj+1. In the successor marking M’ the objects
(ONi,mi) and (ONj,mj) in p are replaced by (ONi,mi+1) and (ONj,mj+1), respectively.
d) A transition e ∈ Ei with eσ = σe = ∅ is enabled in M (denoted M→ e) if for some
place p ∈ P we have (ONi,mi) ∈ M(p) and mi→emi+1. In the follower marking M’ the
object (ONi,mi) is replaced by (ONi,mi+1).
dining room. If both ph_i and ph_k are hungry at the same time, it can happen, that
they permanently exchange the fork without ever managing to eat. Such „after you -
after you“ effects are well known from ordinary Petri nets and can be excluded by
similar methods. Solutions for this problem are out of the scope of this paper. It
should be observed, however, that side conditions are used, which are not allowed by
standard EN systems. By simple constructions they can be eliminated, resulting in a
more complex net, however.
In a truly distributed environment the philosophers can only communicate by
sending messages. This is assumed for the system of „Five Philosophers II“. An
extract of the system net is given in Fig. 4.6. Each philosopher ph i can enter his own
place pi by an arc of type (i). In p i he finds a „fork shuttle right“ shr_i, that can be
used to send a request to his right neighbour ph_k by the interaction [ai] (see Fig.
4.7.).
The shuttle then moves to pk using interaction <xi> to take the fork of ph_i using
interaction [ek], provided philosopher ph_k is now at his place and the fork is free.
Then it goes back, delivering the fork to ph_i by [ci]. The type of this object net is
(si). In a symmetrical way ph_k uses shuttle shl_k („fork shuttle left“) to obtain the
fork back. Since the partners for communication are fixed in this example by merging
communicating transitions, an ordinary net (see Fig. 4.8.) can be constructed,
representing the behaviour of shuttle exchange. This net can be seen as a communica -
tion protocol for distributed mutual exclusion, being similar to the method of [15] and
[5].
Many different settings of the distributed philosophers problem could be realized, as
well. For instance, a fork shuttle could move around and distribute forks to arbitrary
participants. Also, different approaches for handling forks on leave of the dining room
could be realized (e.g.: a philosopher leaves with „his“ left fork, as he came in, or he
leaves without forks granting the resource to a neighbour.) Such variants of
specifications are out of the scope of this paper.
The semantical description techniques discussed in sections 2 and 3 can be extended
to the model of general EOS. In particular, the description of processes by (an
extended version of) co-operating processes has been applied to this case and has been
proved to be very useful [18]. Further research is necessary, in order to well understand
the behaviour of non-simple (general) Elementary Object Systems.
5 Conclusion
An intuitive notion of object system is introduced and then formalized. Unary object
systems are restricted to contain only a single object net, but allow for „intra-
concurrency“ to model concurrent task execution. Using net processes a suitable
definition of marking was found. Processes of unary object systems have been defined
and were represented as cop-processes. This representation was characterized by the
necessary and sufficient extended morphism property.
In the second part simple elementary object systems have been considered, where
intra-concurrency is excluded, but concurrent behaviour and interaction of different
194 R. Valk
object nets is possible. Such object systems are used to model two instances of
Philosophers, showing the usefulness of the approach for a simple and direct way to
model in the object paradigm on the level of classical Petri nets.
References
1. v. d. Aalst, W.: private communication, (1997)
2. Becker, U., Moldt, D.: Object-Oriented Concepts for Coloured Petri Nets, in Proc. IEEE
Int. Conf. on Systems, Man and Cybernetics, (1993) 279-286
Concurrency in Communicating Object Petri Nets 195
3. Brauer, W., Reisig, W., Rozenberg. G. (eds.): Petri Nets: Central Models and their
Properties, Lecture Notes in Computer Science No 254, 255, Springer, Berlin (1987)
4. Jessen, E., Valk, R.: Rechensysteme, Springer, Berlin (1987)
5. Kindler, E. Walter, R.: Message Passing Mutex, in J. Desel (Ed.): Structures i n
Concurrency Theory, Proceedings, Workshops in Computing, Springer, Berlin (1995)
6. Lakos, C.A.: Object Petri Nets, Technical Report TR94-3, Computer Science
Department, University of Tasmania (1994)
7. Lakos, C.A.: From Coloured Petri Nets to Object Petri Nets, in G. De Michelis and M.
Diaz (Eds): Application and Theory of Petri Nets 1995, LNCS No. 935, Springer, Berlin
(1995) 278-297
8. Moldt, D., Wienberg, F.: Multi-Agent-Systems Based on Coloured Petri Nets, in P.
Azema, G. Balbo (Eds): Application and Theory of Petri Nets 1997, LNCS Vol. 1248,
Springer, Berlin (1997) 82-101
9. Rozenberg, G.: Behaviour of Elementary Net Systems, in [3], part I, pp 60-94
10. Rumbaugh, J. et al.: Object-Oriented Modeling and Design, Prentice-Hall, London
(1991)
11. Sibertin-Blanc, C.: Cooperative Nets, in Valette, R (Ed): Application and Theory of
Petri Nets 1994, LNCS Vol. 815, Springer, Berlin (1994) 471-490
12. Thiagarajan, P.S.: Elementary Net Systems, in [3], part I, pp 26-59
13. Valk, R.: Nets in Computer Organisation, in [3], part II, pp 218-233.
14. Valk, R.: Modeling of Task Flow in Systems of Functional Units, report FBI-HH-B-
124/87, University Hamburg (1987)
15. Valk, R.: On Theory and Practice: an Exercise in Fairness, in: Petri Net Newsletter No.
26, pp. 4-11. Bonn, Germany: Gesellschaft für Informatik (GI), Special Interest Group
on Petri Nets and Related System Models, April (1987)
16. Valk, R.: Modeling Concurrency by Task/Flow EN Systems, Proceedings 3rd Workshop
on Concurrency and Compositionality, GMD-Studien Nr. 19, Gesellschaft f.
Mathematik und Datenverarbeitung, St. Augustin, Bonn (1991)
17. Valk, R.: Petri Nets as Dynamical Objects, Proc. Workshop on Object-Oriented
Programming and Models of Concurrency, Torino, June (1995)
18. Valk, R.: On Processes of Object Petri Nets, Report 185/96, Fachbereich Informatik,
University Hamburg (1996)
19. Valk, R.: Petri Nets as Token Objects - An Introduction to Elementary Object Nets, in J .
Desel and M. Silva (Eds.): Application and Theory of Petri Nets 1998, LNCS No. 1420,
Springer-Verlag, Berlin (1998) 1-25
196
1 Introduction
Recently there have been many research efforts in integrating object-oriented (OO in
the sequel) methods with Petri nets, which can be classified into two main paradigms:
(1) use OO or special algebraic specifications to define class relationships and use Petri
nets to define the dynamic semantics of objects and object interactions ([2], [3], [4],
[20]), and (2) make Petri nets OO by adapting OO concepts and features ([21], [22],
[23]).
In [2], Cooperative Objects were introduced, in which high-level Petri nets were
used to model the object behavior and communications (called service invocations) and
OO approach was used to define class structure and relationships. In [4], CLOWN
(Class Orientation With Nets) was presented, where class relationships were defined
using structured templates and high-level Petri nets were used to define object behavior
and synchronized object interactions. In [3], CO-OPN/2 (Concurrent Object-Oriented
Petri Nets) was proposed, in which algebraic specifications were used to define class
structure and relationships, and algebraic nets were used to define object behavior and
interactions. Although high-level Petri nets were used in all of the above research, they
do not have well-defined structural mechanism and thus are not capable to deal with
more general class relationships such as containment and inheritance.
In [23], some special structural mechanism was informally defined on high-level
Petri nets and thus class containment relationships and class use relationships could be
expressed. However no discussion of inheritance relationship and dynamic object
creation was given. In [21] and [22], OPNs (Object Petri Nets) were presented, which
extend hierarchical colored Petri nets [18] with various OO concepts (including
encapsulation, inheritance, polymorphism, and dynamic binding). Classes were defined
as subnets so that containment relationships could be easily defined. Furthermore, token
types could be classes as well, which means tokens could be subnets and be
instantiated. Polymorphism was realized based on token types (classes).
This paper presents an approach of using HPrTNs [14] for OO specification
without adding any new features. Specifically, we show how to realize various OO
features such as classes (data encapsulation), class instances (objects) and their creation
and destruction, class relations, class hierarchy and inheritance (subclasses), and
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 196-215, 2001.
Springer-Verlag Berlin Heidelberg 2001
Object Orientation in Hierarchical Predicate Transition Nets 197
The development of HPrTNs was motivated by the need to construct specifications for
large systems using Petri nets [25] and inspired by the development of modern high-
level programming languages and other hierarchical and graphical notations such as
data flow diagram [28] and statechart [11]. With the introduction of hierarchical
structures into predicate transition nets, the resulting net specifications are more
understandable and the specification construction process becomes more manageable.
HPrTNs were used in specifying several systems including an elevator system [15], a
library system [16], and a hurried dining philosophers system [12]. HPrTNs can be
analyzed directly by using a hybrid technique combining structural, behavioral, and
logical reasoning [13], and can be translated into program skeletons in a concurrent and
parallel object-oriented programming language CC++ [17] (an introduction to CC++
can be found in [7]). A complete formal definition of HPrTNs was given in [14]. In the
following sections, basic concepts and notation of HPrTNs are briefly introduced.
An HPrTN N consists of (1) a finite hierarchical net structure (P, T, F, ρ), (2) an
algebraic specification SPEC , and (3) a net inscription (ϕ, L, R, M0).
(P, T, F) is the essential net structure, where P ∪ T is the set of nodes satisfying
the condition P ∩ T = ∅. P is called the set of predicates and T is called the set of
transitions. There are two kinds of nodes for both predicates and transitions -
elementary nodes (represented by solid circles or boxes) and super nodes (represented
by dotted circles or boxes). Elementary nodes have the traditional meaning in flat Petri
net models. Super nodes are introduced to abstract and refine data and processing in
HPrTNs [15]. In particular, we identify two subsets IN ⊆ P ∪ T and OUT ⊆ P ∪ T
such that IN contains the heads of all incoming non-terminating arcs (an arc inside a
super node is a non-terminating arc if one of its end is connected to the boundary of the
super node) and OUT contains the tails of all outgoing non-terminating arcs. Nodes in
IN ∪ OUT are called interface nodes. We use •IN to denote the set of the pre-sets of all
elements in IN, i.e. •IN = {•n | n ∈ IN}; and OUT• to denote the set of the post-sets of
all elements in OUT. F is the set of arcs and is called the flow relation satisfying the
conditions: P ∩ F = ∅, F ∩ T = ∅, and F ⊆ (•IN × IN ∪ P × T ∪ T × P ∪ OUT ×
OUT•). An arc f can be uniquely identified by a pair of nodes (n1,n2) denoting its
source and sink, in which n1 (n2) may denote the pre-set (post-set) of n2 (n1) when f is
a non-terminating arc. An arc in an HPrTN may represent a cluster of flows due to the
198 X. He and Y. Ding
use of super nodes, and individual component flows are defined by the arc label to be
discussed below.
ρ: P ∪ T → ℘(P ∪ T) is a hierarchical mapping that defines the hierarchical
relationships among the nodes in P and T; and satisfies the constraint that the interface
nodes ∈ IN ∪ OUT be all predicates if their parent node is a predicate or all transitions
if their parent node is a transition. For any node n, ρ(n) defines the immediate
descendant nodes of n. The ancestor and descendants of any node can be easily
expressed by using well-known relations such as transitive closure on ρ. A node in an
HPrTN is local to its parent, and can be uniquely identified by prefixing its ancesters’
names separated with periods to its own name; however often its own name is referred
whenever there is no name clash occurs.
The underlying specification SPEC = (S, OP, Eq) consists of a signature S = (S,
OP) and a set Eq of S-equations. Signature S = (S, OP) includes a set of sorts S and a
family OP = (OPs1,...,sn, s ) of sorted operations for s1, ..., sn, s ∈ S. For each s ∈ S,
we use CONs to denote OP ,s (the 0-ary operation of sort s), i.e. the set of constant
symbols of sort s. The S-equations in Eq define the meanings and properties of
operations in OP. We often simply use familiar operations and their properties without
explicitly listing the relevant equations. SPEC is a meta-language to define the tokens,
labels, and constraints of an HPrTN. As a matter of fact, only one general SPEC is
needed for HPrTNs.
Tokens of an HPrTN are essentially constant symbols of the family OP. The tokens
of sort s are elements in CONs .
The set of labels, LabelS (X) (X is the set of sorted variables disjoint with OP), can
be simple labels (a simple label is a tuple with an identifer and a multi-set flow
expression), or compound labels involving label constructor + (non-deterministic flow
relation, in which not all component data are consumed or generated in a transition
firing) and × (concurrent flow relation, in which all component data are consumed or
generated in a transition firing). Label identifiers are used to connect non-terminating
arcs and normal arcs at different levels, and flow expressions define the flow capacity.
Constraints of an HPrTN are a subset of first order logic formulas (where the
domains of quantifiers are finite and any free variable in a constraint appears in the
label of some connecting arc of the transition), and thus are essentially propositional
logic formulas. The subset of first order logical formulas contains the S-terms of sort
bool over X , denoted as TermOP,bool(X).
The net inscription (ϕ, L, R, M0) associates each graphical symbol of the net
structure (P, T, F, ϕ) with an entity in the underlying SPEC, and thus defines the static
semantics of an HPrTN. Thus different HPrTNs have different net inscriptions.
Each predicate in an HPrTN is a data structure and a component of the overall
system state. The sort of each predicate defines its valid values, i.e. proper tokens. The
sorts of elementary predicates are members of S in SPEC. The sort of a super predicate
is defined as the union of sorts of its interface child predicates. Therefore, we associate
each predicate p in P with a subset of sorts in S, and give the following sort assignment:
ϕ : P → ℘(S).
L: F → LabelS (X) is a sort-respecting labeling of N. All simple labels of a
compound label must have distinct identifiers, and all simple labels of arcs connected to
the same node must have distinct identifiers. Since compound labels define data flows
Object Orientation in Hierarchical Predicate Transition Nets 199
as well as control flows. The following basic control flow patterns [15] must be
correctly labeled: (1) data flows into and out of an elementary transition must take place
concurrently, and (2) data flows into and out of an elementary predicate can occur at
different times. Furthermore, data flows between different levels of hierarchies must be
balanced, i.e. a simple label occurs in a non-terminating arc if and only if it also appears
in an arc with the same direction connected to the enclosing super node.
R: T → TermOP,bool(X) is a well-defined constraining mapping of N, which
associates each transition t in T with a first order logic formula defined in the
underlying algebraic specification. Furthermore, the constraint of an elementary
transition defines the meaning of the transition, and in general contains two parts - the
pre-condition part involving only label variables in incoming arcs and the post-
condition part specifying the relationships between the variables of the incoming arcs
and label variables of the outgoing arcs. The pre-condition specifies the required tokens
and the post-condition defines the values of generated token in terms of the selected
tokens. Therefore the pre-condition is essentially the guard of the functionality
(processing) defined by the post-condition. Therefore the canonical form of the
constraint R(t) of an elementary transition t can be written as Pre(t) ∧ Post(t). A super
transition is an abstraction of low-level actions and its meaning is thus completely
defined by the low-level refinement. Therefore the constraint of a super transition is
true by default (it is conceivable that a non-trivial constraint for a super transition might
be useful; however in general it is very difficult to define such a constraint and also
very difficult to interpret the constraint with regard to the operational (dynamic)
semantics of the super transition).
M0: P → MCONS is a sort-respecting initial marking of N, which assigns a multi-
set of tokens to each predicate p in P. The tokens of a super predicate is a sorted union
of the tokens of its interface child predicates since only those tokens are externally
accessible.
Phil Chop
f1
f2
f3 Relation
f4
f6 f10 f14
f7 f11 f15
f8 f12 f16
Eating Putdown Used
(2) a refinement
The above HPrTN specifies the well-known dining philosophers problem. The
high-level net structure abstraction Fig.1 (1) shows an elementary predicate Relation
(defining the association among each philosopher and his left and right chopsticks), and
two super nodes, super transition Phil and super predicate Chop, which are connected
through two arcs with labels f1 and f2 respectively. The low-level refinement Fig.1(2)
shows the internal structure of Phil with two states denoted by predicates Thinking and
Object Orientation in Hierarchical Predicate Transition Nets 201
Eating respectively and two transitions Pickup and Putdown, and the internal structure
of Chop with two predicates Avail and Used denoting the states of chopsticks.
In the underlying specification SPEC = (S, OP, Eq),
(1) S includes elementary sorts such as Integer and Boolean, and also sorts PHIL,
CHOP, and ORDER derived from Integer. S also includes structured sorts such as set
and tuple obtained from the Cartesian product of the elementary sorts;
(2) OP includes standard arithmetic and relational operations on Integer, logical
connectives on Boolean, set operations, and selection operation on tuples (we use A[i]
to denote the ith component of tuple A); and
(3) Eq includes known properties of the above operators.
The above specification allows concurrent executions such as multiple non-
conflicting (non-neighboring) philosophers picking up chopsticks simultaneously, and
some philosophers picking up chopsticks while others putting down chopsticks. The
constraints associated with transitions Pickup and Putdown also ensure that a
philosopher can only use two designated chopsticks defined by the tokens in predicate
Relation.
From this example, it can be seen that a hierarchical specification provides
different levels of abstraction, supports information encapsulation, and facilitates
specification composition and modification.
In the following sections, we show how to realize various OO concepts and features in
HPrTNs. To simplify the discussion, only necessary net components and thus
incomplete HPrTNs are used to illustrate relevant OO concepts and features.
Furthermore arcs are extended over super nodes boundaries to show particular
connections, which are instead defined through label expressions in the formal
definition of an HPrTN.
3.1 Classes
One of the central ideas of OO paradigm is data encapsulation captured by the class
concept. A class is essentially an abstract data type with a name, a set of related data
fields (or attributes), and a set of operations on the data fields. It is straightforward to
use a predicate to denote a data field (structure) and a transition to represent an
operation in Petri nets. The current value of a data field is determined by the tokens of
the denoting predicate under the current marking. The meaning or definition of an
operation is specified by the constraint associated with the denoting transition.
HPrTNs were originally developed for structured analysis, which provide separate
mechanisms for data abstraction and processing abstraction through super predicates
and super transitions respectively. Therefore we can use a super predicate and super
transition pair in an HPrTN to capture the notion of a class; although it is adequate to
define a class by using a super predicate when there is no externally visible operation or
using a super transition when there is no externally visible attribute. This view of class
is a major improvement over that in [12], where a class was represented by a super
predicate only. In this view, the interface of the class is defined by the super predicate
and the super transition. The super predicate defines data and internal operations of the
class while the super transition mainly defines the externally visible operations of the
202 X. He and Y. Ding
class. The corresponding subnets further define the internal structures of the data and
the operations and the net inscription defines the meanings of net components through
predicate types, token values, and transition constraints. When the resulting HPrTN is
simple enough, there is no need to separate the super nodes from their subnets, i.e. the
subnets are directly embedded inside the super nodes. An attribute or operation is
externally visible if the corresponding denoting predicate or transition is an interface
node (i.e. connected with a non-terminating arc). It should be noted however that not
every super predicate or transition needs to be considered as a class. A super predicate
or transition may simply denote a data abstraction or operation abstraction as originally
intended; for example a super predicate can be used to hide the internal states of an
attribute that is defined by several related predicates, and a super transition can be used
to define alternative implementations of an operation to realize operation overloading
or overriding. Thus our approach supports the co-existence of various modeling
paradigms.
Based on the above analysis, we use the following C++-like class schema to
document a class defined by the super node(s) in an HPrTN (it is worth noting that the
class schema is only used for understanding purpose, and does not add functionality to
the given HPrTN):
class Name [:superclass(es)]
{ public:
predicates and transitions
[private:
predicates and transitions]
}
where brackets […] denote optional items. Predicates and transitions listed in both
public and private sections are those contained in the super node(s). The name(s) of the
super node(s) are used to form the class name.
In the HPrTN shown in Fig. 1, both super transition Phil and super predicate Chop
can be viewed as classes. Thus the following class definitions can be obtained:
class Chop
{ public:
Avail, Used
},
class Phil
{ public:
Pickup, Putdown
private:
Thinking, Eating
}.
An instance or object of a class has its own copy of data while sharing operations with
other objects of the same class. To distinguish an object from other objects, a unique
identifier is needed for each object.
In an HPrTN, an object is essentially defined by a set of tokens related through the
same identifier, and thus the sort of any predicate p needs to contain a component sort
of relevant identifiers, i.e. ϕ(p) = ℘(ID × …). Different objects of a class share the
Object Orientation in Hierarchical Predicate Transition Nets 203
same class data structure, i.e. tokens with different identifiers can reside in a predicate
at the same time in an HPrTN, however in general objects of the same class cannot
interact with each other directly. The above problem is easily solved by defining a
subexpression comparing token identifiers in the constraint of each transition such that
only proper tokens are used in the transition firing. Movements of tokens and/or
changes of token values while maintaining the object identifier indicate state changes of
the object.
In the HPrTN shown in Fig. 1, there are k philosopher objects with identifiers of
sort PHIL; and there are k chopstick objects with identifiers of sort CHOP.
Objects of a class may be created statically (the resources for the objects are allocated
before the execution of the underlying system) or dynamically (the resources for the
objects are allocated during the execution of the underlying system.
HPrTNs support both static and dynamic object creation. Static object creation in
an HPrTN is achieved through the initial marking M0. Dynamic object creation in an
HPrTN is realized through (constructor) transition firings that produce new objects with
unique identifiers. Object constructors are system dependent and often create multiple
tokens belonging to the same object at once (i.e. such transitions have multiple output
arcs connected to the internal predicates denoting distinct class attributes). Unique
object identifiers can be defined through the initial marking M0 and/or are hidden in an
internal predicate within a constructor transition as shown in Fig.2. Often a function
with a prefix new_ is used in the constraint of a constructor transition to denote a new
unique identifier generated for each firing of the transition without explicitly defining
the net structure shown in Fig.2. Similarly, an object destructor can be represented by a
transition that consumes the last token belonging to an object. Multiple constructors and
/ or destructors may exist in a class defined by an HPrTN.
constructor
generator ids
The objects in the HPrTN shown in Fig. 1 are created statically through the initial
marking M0.
Classes work together to fulfill the functionality of the underlying system. A class can
use the operations and / or data provided by other classes.
In HPrTNs, the interface of a transition includes a box with a name and the labels
of relevant arcs (the label identifiers determining the calling context and the flow
expressions specifying parameters). The meaning of an elementary transition is defined
204 X. He and Y. Ding
by its constraint and the meaning of a super transition is defined through its
corresponding subnet.
It is easy to model a class reference by adding some arc when a class needs to
access some public attribute of another class. For example, Fig.3(1) illustrates simple
class reference relationships where some operation in class C1 (p1 & t1) uses some
public attributes defined in class C2 (p2 & t2) and some operation in class C2 uses
some public attributes defined in class C1. Fig.1 contains simple reference relationships
between classes Phil and Chop.
p1 t2
t1 p2
t1 t2
op1
p1
op2
p2
p
op1 op2
Many classes are conceptually related through a "whole-part" relationship [8] (or
aggregation relationship in [5]), which is modeled through a class containment
relationship, i.e. one class being a logical part of another class.
In HPrTNs, a class containment relationship can be easily defined through nested
super nodes denoting containing and contained classes. The super nodes representing
the contained class (i.e. the interface of the contained class) become data and /or
operations of the containing class, however the internal data and operations of the
contained class do not belong to the containing class. The containing and the contained
classes usually have different internal data and operations, which may be accessed by
both.
The general pattern of a containment relationship is shown in Fig.4. The following
class definitions are obtained from Fig.4:
class p1&t1
{ public:
p2, p3, t2, t3, ...
private:
...
};
class p3&t3
{ public:
...
private:
206 X. He and Y. Ding
...
}.
p1 t1
p2 t2
p3 t3
Class hierarchy structure can be explored using the abstraction and refinement
techniques of HPrTNs discussed in [15].
Another major feature of OO paradigm is class inheritance relation that captures the
"generalization-specialization" relationships in the real world [8]. A class inheritance
relationship exists between a superclass and a subclass such that the subclass inherits
data structures as well as operation definitions from the superclass without the need to
define them again. Thus class inheritance relation supports a flexible and managed way
to reuse existing data structures and operations.
A class inheritance relation is realized in HPrTNs through the reuse of the net
structures of inherited super nodes; and the net inscription of inherited elementary
nodes (the sorts of predicates, the label expressions of relevant arcs, and the constraints
of transitions) defined in an existing HPrTN denoting a class. However the inherited
predicates and transitions are explicitly represented or embedded in the subclass to
clearly define its role (the same convention was used in [22]). An inherited element in a
subclass has a name of the form: super_node.element_name, where super_node is the
partial name of the superclass and element_name is the internal name of the element
within the superclass. Renaming of relevant arcs are also necessary to reflect the current
context and to ensure flow balance. It is clear that inheritance does not reduce the size
of an HPrTN specification since inherited elements are embedded (an alternative way to
embedding is through delegation [1]), however the advantages are obvious since the
meaning or structure (the most difficult part in writing an HPrTN specification) of an
inherited element is already available and is obtained without any additional effort; and
furthermore many known properties of the inherited element might be maintained
through inheritance (structural properties are surely kept, but behavioral properties may
need additional validation). It is worth noting that (1) only public components of a
superclass can be inherited; (2) inheritance from multiple superclasses are supported
and an element can be inherited by multiple subclasses since no ambiguity will occur
Object Orientation in Hierarchical Predicate Transition Nets 207
due to the naming convention; and (3) a re-defined (overriding) operation is considered
as a new operation in a subclass and is distinguished from an inherited operation such
that an overriding operation in a subclass has the same name as the overriden operation
in the superclass (this distinction between inheritance and overriding was also made in
[1]). The above realization of class inheritance relation in HPrTNs is complete new and
is more general and useful than using nested super nodes in realizing inheritance
proposed in [12].
p1 t1
p2 t2 t3
p3
t4
p4 t6 p5
t1.t2 t3
p1.p2
3.7 Polymorphism
OO paradigm also supports polymorphism such that an operation’s name (with possibly
different signatures) may have different meanings or behaviors (implementations)
through inheritance or overriding.
Polymorphism can be achieved in HPrTNs in two different yet related ways. First,
polymorphism is a major feature of the underlying algebraic specification SPEC of an
HPrTN (detailed discussions of algebraic specifications and polymorphism can be
found in [9]). The same operation symbol in SPEC is used for many derived sorts. A
simple example is the overloaded equality "=" operator when an algebraic specification
SPEC contains two elementary data types (or classes) INT and CHAR with a single
208 X. He and Y. Ding
p
op1 op1*
3.8 Concurrency
HPrTNs maintain the distributed and concurrent features of elementary Petri nets.
Concurrency takes place not only at the object level but also at the finer object
component level (thus multiple threads can exist within an object’s behavior).
Furthermore, no inheritance anomaly discussed in [24] will occur in our approach for
the following main reasons: (1) HPrTNs are a specification method (not a concurrent
OO programming language that may cause inheritance anomaly), (2) the dynamic
semantics of HPrTNs ensure object access synchronization without using any explicit
synchronization mechanisms, and (3) HPrTNs naturally support the main solution
proposals to the anomaly problem [24] through transition constraints to achieve method
guards and necessary internal (hidden) predicates to realize history-sensitive
synchronization.
4 An OO HPrTN Example
In this section, an example of using HPrTNs to realize class inheritance relationship and
polymorphism is given.
Object Orientation in Hierarchical Predicate Transition Nets 209
Two classes are identified from the problem description, a class of hurried philosophers
with two distinct states: thinking and eating, and two operations: pickup and putdown;
and a class of chopsticks with two distinct states: available and being used. Thus classes
Phil and Chop in Fig.1 can be used as superclasses from which two subclasses HPhil
and HChop defining the hurried philosophers problem are derived. To fulfill
requirements (4) and (5), two new transitions Arrive (denoting the constructor) and
Leave (denoting the destructor) are added to HPhil class; and two new transitions Bring
(denoting the constructor) and Take (denoting the destructor) are added to HChop class.
Since these constructors and destructors are externally accessible to dynamically
change philosophers and chopsticks, HChop class now needs to be defined by using a
pair of super nodes - super predicate HChop_S for chopstick status and super transition
HChop_O for chopstick operations (the constructor and the destructor). Furthermore a
new arriving philosopher brings in a new chopstick (his right one) and changes the
neighborhood of two existing thinking philosophers. Similarly a leaving philosopher
takes away his right chopstick and changes the neighborhood of his left and right
philosophers. To define the above changes, a super transition Rush containing two
elementary transitions Add and Delete, and two reference predicates Pid and Cid are
used. Fig.7 shows an HPrTN specification of the hurried philosophers problem.
a1
HPhil HChop_S
a2
a3
a7 Relation
a4
Pid a5 a6
a9
a8
a10
Rush a11 a12 HChop_O
Cid
Fig.7(1) - The overall system structure
210 X. He and Y. Ding
HPhil
a19 a23
a14
a20 a24
Leave Phil.Eating Phil.Putdown
Chop.Avail Bring
a25 a29 a30
a26
a27
a28 a31
Chop.Used Take
Add Id
a32 a34
a33 a35
a36
a37
Delete
Remarks:
• HPHIL is the sort of hurried philosopher identifiers and is a subtype of integer
INT, and HCHOP is the sort of chopstick identifiers and is also a subtype of INT;
• The label expressions can be understood by following the same label identifier and
basic Petri net semantics. For example, the label expression of arc a1 indicates two
data flows from HChop_S to HPhil, specifically one from Chop.Avail to
Phil.Pickup with label identifier 1, and another from Chop.Used to Phil.Putdown
with label identifier 2;
• The constraints of transitions Phil.Pickup and Phil.Putdown are exactly the same as
those defined in the superclass shown in Fig.1;
• In the constraint of transition Add, the 1st line defines an identifier for an arriving
philosopher, the 2nd line uses the same identifier for the new chopstick, the 3rd
line selects two adjacent hurried philosophers (the object idenitifier of each hurried
philosopher is greater than k) hurried philosophersuch that the new philosopher sits
between them specified by the new neighborhood (the 4th and 5th lines);
• The subexpression (re1[1] ≥ k+1) in the constraints of transitions Add and Delete
can be omitted by restricting the domain of sort HPHIL to {k+1, k+2, ...};
Internal predicate Id holds a single token with an initial value k+m+1, which is
used to generate unique object identifiers.
The above HPrTN specification of the hurried philosophers problem has benefitted
significantly from inheriting partial net structure as well as relevant net inscription from
the HPrTN specification of the traditional dining philosophers problem given in Fig.1.
Furthermore, an HPrTN specification of a more general dining philosophers problem
combining the traditional dining philosophers problem and the hurried philosophers
problem can be easily obtained by merging the predicate Relation in both Fig.1 and
Fig.7. Polymorphism is realized through the net structure and inscription since the
firing of which Pickup transition (either in Phil or in HPhil) is determined by a specific
token relevant to either Phil or HPhil in predicate Relation.
Object Orientation in Hierarchical Predicate Transition Nets 213
Acknowledgements
We thank one anonymous referee for careful reading of the first draft of this paper
and for making helpful suggestions to improve the quality of the paper. The research of
Xudong He was supported in part by the National Science Foundation (NSF) of the
USA under grant CCR-9308003 and grant OSR-9452892, and the Office of Naval
Research of the USA under grant N00014-98-1-0591.
214 X. He and Y. Ding
References
[19] C. Kan and X. He, "A method for constructing algebraic Petri nets", Journal of
Systems and Software, vol. 35, 1996, 15-27.
[20] G. Kappel and M. Schrefl: "Using an object-oriented diagram technique for the
design of information systems", Dynamic Modeling of Information Systems,
Elsevier Science Publishers, 1991, 121-164.
[21] C. Lakos: "From colored Petri nets to object Petri nets", Proceedings of the 16th
International Conference on the Application and Theory of Petri Nets, Torino,
Italy, 1995.
[22] C. Lakos: "The Object Orientation of Object Petri Nets", Proc. of the 1st
Workshop on Object-Oriented Programming and Models of Concurrency, Torino,
Italy, 1995.
[23] Y.K. Lee and S.J. Park: "OPNets: An object-oriented high-level Petri net model for
real-time system modeling", Journal of Systems and Software, vol.20, 1993, 69-86.
[24] S. Matsuoka and A. Yonezawa: “Analysis of Inheritance Anomaly in Object-
Oriented Concurrent Programming Languages”, in Research Directions in
Concurrent Object-Oriented Programming (eds. G. Agha, P.Wegner, and A.
Yonezawa), MIT Press, 1993, 107-150.
[25] W. Reisig: "Petri nets in software engineering". Lecture Notes in Computer
Science, vol.255, Springer-Verlag, 1987, 63-96.
[26] M. Shaw and D. Garlan: Software Architecture, Prentice-Hall, 1996.
[27] B. Stroustrup: The C++ Programming Language, 2nd edition, Addison-Wesley,
1991.
[28] E. Yourdon, Modern Structured Analysis, Prentice Hall, 1989.
CoOperative Objects:
Principles, Use and Implementation
C. Sibertin-Blanc
1. Introduction
Petri nets (PNs) are one of the formal models of concurrency. They are successfully
used to deal with concurrent discrete event systems and in particular with distributed
systems such as operating or manufacturing systems, business or software
development processes. They are applied to existing or planned systems for
performing various tasks: requirements analysis, specification, design, test, simulation
and formal analysis of the behaviour [ISO 97]. Projects concerning such systems most
often lead to the development of software that either serves as a tool supporting the
system’s activities, or controls its behaviour, or constitutes its final implementation.
In such casees, Petri nets are used only during the early steps of the project and not
during the software implementation steps, because they are not a programming
language. This restriction causes a change in the conceptual framework used to
consider the system; this rupture is error prone, entailing additional works and making
the project’s traceabibity difficult.
G Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp 216-246, 2001.
ã Springer-Verlag Berlin Heidelberg 2001
CoOperative Objects: Principles, Use and Implementation 217
The second chapter of this paper surveys the expressive power of the COO
formalism. The third chapter details the definition of an Object and of a COO system,
and addresses the COO’s model of concurrency along with the dynamic creation and
deletion of Objects. The static case of the dining philosophers problem is used as an
example. The fourth chapter proposes a solution for the dynamic case of the dining
philosophers problem which turns out to be a quite complex one. The fifth chapter
presents the inheritance relationships among COO classes and the conditions for a
COO class to be a subtype of another class; thanks to this subtype relationship, the
COO formalism allows for polymorphism, which means that an instance of a subtype
may be safely substituted when an instance of a type is expected. The sixth chapter
indicates how various semantics of the COO formalism are defined and how the
analysis techniques founded on the PN theory may be applied.
The last chapter presents an environment for the development of COO systems.
SYROCO (an acronym for SYstËme RÈparti d’Objets CoOpÈratifs) is mainly a COO
compiler: it translates each COO class into a C++ class so that an instance of a COO
class is implemented as an instance of the corresponding C++ class. Each Object is
provided with an interpreter, a Token Game Player which executes the Petri net
defining its behaviour; thus an Object is actually implemented as an autonomous
process. Thanks to these features, SYROCO is efficient in space and time. The COO
formalism may be viewed either as a tool for the specification, the design and the
analysis of complex systems, or as a Concurrent Object-Oriented Programming
Language. Accordingly, SYROCO is intended to be used either as a simulation tool or
as a programming environment, and it provides users with a number of facilities for
both purposes. Some of these facilities are pragmatic and intended to ease the
development of complex COO systems. Other facilities allow a fine control of the
behaviour of each Object.
2. COOs: An Overview
This chapter gives a general presentation of the structure and the behaviour of a COO
system. The COO formalism views a system as a collection of active Objects, each
Object being an instance of its COO class. While a COO system is running, the set of
its member Objects may vary since Objects may be dynamically created and deleted.
The behaviour of a COO system results from the concurrent behaviour of its Objects,
each one processing its own activity. This activity involves communicating with other
Objects according to a request/reply protocol.
The structure of an Object has two parts - a Data Structure and a Control Structure
(Cf. Figure 1).
The Data Structure of an Object complies with the usual concept of an object. It
includes a set of attributes and a set of functions, referred to as operations. The public
elements of this Data Structure may be accessed in a synchronous way by other
Objects, namely by the body of their operations.
The Control Structure of an Object makes it active. It includes the declaration of a
set of services and a High-Level Petri Net referred to as its OBCS (for OBject Control
Structure). This net defines the Object’s behaviour. Its places serve as state variables
220 C. Sibertin-Blanc
of the Object; thus, the value of a place is a set of data objects. The transitions of the
OBCS correspond to actions that the Object is able to perform; thus the current state
of an Object determines the enabling of its actions, and the occurrence of an action
produces a change of state. In order to process the data objects staying in places, each
transition may include calls for operations or more generally a piece of code which
has access to the Data Structure of the Object and to the public elements of the Data
Structure of other Objects (Cf. transition t5). As for services, they allow
asynchronous request/reply communications among Objects. Each service is
supported by transitions, and is available only when (at least) one of these transitions
is enabled (Cf. transition t1 or t2); if this is not the case, a request for a service is
delayed until one of its associated transitions becomes available. In order to request a
service from another Object, the net includes a pair of transitions: the first of these
transitions issues the request, while the second one becomes enabled upon reception
of the result of the request (Cf. transitions t3 and t4).
Due to lack of space, we cannot discuss to what extent the COO formalism fulfils
the principles of Software Engineering mentioned above, although such a discussion
is essential to validating this formalism. Therefore, we leave it to the reader, and just
give a hint ! A formalism is mainly a cognitive tool allowing engineers to understand
the system which they are faced by developing a model, a description, or a design of
that system. For this purpose, a formalism has to provide high-level abstractions
which are as close as possible to the concepts used to discuss the structure and the
behaviour of systems, so that the model’s architecture mirrors the organisation of the
system as it is viewed by the designer.
In order to meet this requirement, the COO formalism relies upon the following
meta-model: a system is embedded in an environment with which it interacts through
an interface, and it may be viewed as being located in a four-dimensional space.
These dimensions concern the Entities processed by the system, the Operations
whose executions constitute the processing, the Actors which manage the entities and
perform the operations, and the Control Structure which defines the system
behaviour. Together, the current Entity instances, Operation occurrences and Actor
instances of a system define the state of the system. These three dimensions constitute
the static part of the system: as long as it is not provided with a Control Structure, a
system carries out no work and its state never changes. Indeed, a change in the
system’s state only results from the occurrence of an action, that is the actual
execution by an Actor of an Operation involving some Entities, and the role of the
Control Structure is just to determine under which state(s) an action may occur. Once
a system has been analysed according to this meta-model, it becomes easy to draw a
COO model of this system through using the following correspondences:
Entity/token, Operation/code associated to a transition, Actor/CoOperative Object,
Control Structure/OBCS.
222 C. Sibertin-Blanc
We shall now introduce the CoOperative Objects formalism using the static case of
the dining philosophers as an example: the philosophers are steadily seated around the
table. First, a centralised solution by means of a single Object of the class
PhiloTable will be presented, allowing the structure and the semantics of an
isolated Object to be introduced. Then, a decentralised solution modelling each
philosopher as an Object of the class SPhilo will be presented, allowing the
structure of a COO system and the interactions among Objects to be introduced.
class Any;
class philo: Any { //philo inherits Any
public: //items accessed by the net
philo* rn; //the right and left neighbours
philo* ln;
//counts how many times the philo eat
short nbeating;
void eat() {
nbeating = nbeating + 1;
};
void init(philo* l, philo* r){
ln = l; rn = r;
nbeating = 0;
}
};
typedef int fork;
const nbphil = 4;
Arg_grf
<Any*,philo*>
<cl,p> <cl,p>
<cl,f>
<cl,f>
grf
glf
Res_glf Res_grf
<Any*,fork>
<Any*,fork> starteating <p,f>
p
p <p, f>
<p,lf> <p,rf>
NoLFork •• NoRFork
<philo*>
•• <p,lf> + <p,rf>
<philo*>
••
LFork ••
Eating RFork
<philo*,fork> <philo*,fork> <philo*,fork> p
p
<p,lf> <p,rf>
p
p
p->eat()
wrf
wlf stopeating <philo*>
<philo*>
p <p,f> <p,f> p
<p,f>
end.
We shall now provide technical details on the structure and the semantics of an
OBCS.
The type of a Place (written in italic characters) is a list of types of the data
language, and its value, or its marking, is the (multi-)set of tokens it contains. At any
moment, the OBCS’s state (or its marking) is defined by the distribution of tokens
onto places.
According to the length of the type of the place, a token is either a raw-token with
no specific value if the place’s type is empty, a value belonging to the single data type
of the place, or a list of values. Such a value is either a constant (e. g. 2 or ‘Hello’), an
instance of a class of the data language, or a reference to such an instance. As an
CoOperative Objects: Principles, Use and Implementation 225
example, the place RFork contains tokens which are made up of a reference towards
a philo and an integer. One may wonder what the difference is between using an
object class or a reference to this class in the type of a place. In the former case, the
class instances are accessed ‘by value’, while in the latter case they are accessed ‘by
reference’. Thus, if an object appears among the values of a token, it makes no sense
for another copy of this object to appear in another token of the same marking
([Sibertin 85] provides a structural condition to avoid this kind of ubiquity of objects);
such a situation would go against an essential principle of the OO approach according
to which each object is unique. On the other hand, a reference towards the same
object may appear in several tokens of a marking; for instance, the transition grf is
enabled if the variable p is bound to an object reference which appears both in a token
lying in the place RFork and in a token lying in the place Arg_grf.
If the data language supports a subtyping relation, the type of a token lying in a
place may be a subtype of the place’s type.
A Transition is connected to places by directional arcs.
Each arc is labelled with a list of variables having the same length as the type of
the place to which the arc is connected. These variables serve as formal parameters
for the transition and define the flow of token values from input places to output
places. A transition may occur (or is enabled) if there exists a binding of its input
variables with values of tokens lying in its input places. The occurrence (or the firing)
of an enabled transition changes the marking of its surrounding places: tokens bound
to input variables are removed from input places, and tokens are created and put into
output places according to variables labelling output arcs. As is usual in High-Level
Petri nets, an arc may be labelled with a formal sum of lists of variables (cf. transition
starteating), and an expression may be found instead of an output variable (cf.
transition arf).
The type of variables labelling an arc is defined componentwise by the type of the
corresponding place. If the same variable appears in the labelling of several arcs
surrounding a transition, simple rules prevent the occurrence of a 'type mismatch
error’ [Sibertin 92, Syroco 95]. For instance, the variable p of the alf transition
occurs both on the arc from the place NoLFork and on the arc to the place
Arg_grf, providing respectively the types philo* and Any*. No type problem
occurs since philo is a sub-type of Any and NoLFork is an input place while
Arg_grf is an output place; thus the type of p is philo*.
A transition may be guarded by a Precondition, a side-effect free Boolean
expression involving the transition’s input variables and the Object’s attributes or
operations (Cf. transition leave in Fig. 7 below; syntactically, a transition of the
OBCS refers to an attribute or operation of the Data Structure using the prefix _S->).
In this case, the transition is enabled by a binding only if this binding evaluates the
Precondition to true.
A transition may also include an Action, which consists of a piece of code in which
the transition’s variables and the Object’s operations or attributes may take place (Cf.
transition stopeating). This Action is executed at each occurrence of the
transition and it allows the values of tokens to be processed. If an output variable of
the transition does not appear on any input arc, the Action must assign a value to this
variable in order to extend the binding which enables the transition; thus, if the type
of the variable is an object class, each occurrence of the transition causes the creation
226 C. Sibertin-Blanc
of a new data object. Conversely, if an input variable does not appear on any output
arc while its type is an object class, each occurrence of the transition entails the loss
of the data object bound to the variable.
Finally, a transition may include a set of Emission Rules, which are side-effect free
Boolean expressions involving its variables and the Object’s attributes or operations.
In this case, each output arc of the transition is connected to one of the Rules, and an
occurrence of the transition causes the depositing of a token into the connected output
place only if the Rule evaluates to true. For instance, an occurrence of the transition
leave in Figure 7 puts tokens into places p1 and p3 if the expression ok is true and
into places NoLFork and RFork if not. This trick makes the graphical
representation of the OBCS simpler since, if the Rules are contradictory, each Rule is
equivalent to one transition having this Rule as a Precondition. Conceptually,
providing a transition with Emission Rules makes explicit the fact that putting tokens
into some places is a choice resulting from the transition occurrence.
The activity of an isolated Object consists of executing its OBCS, i. e. repeatedly
firing transitions which are enabled under the current marking. When the marking of
an Object concurrently enables several transitions, the Object’s activity includes
several threads of control, or tasks, which can progress concurrently. Although PNOs
support semantics for the concurrent enabling and occurrence of transitions [Sibertin
92], the default semantics of an OBCS is the interleaving one: only one transition
occurs at once, so that the on going tasks progress in turn. Arguments for this choice
are developed in another paper [Sibertin 97a]. To summarise, from a conceptual point
of view these semantics relieve the designer of difficulties entailed by the sharing of
data (attributes and tokens referring to objects), and from an implementation point of
view there is no real improvement of performance when the system includes several
Objects.
The behaviour of a COO system results from the concurrent activity of its actual
Objects, and we shall now introduce cooperation among Objects through a
decentralised solution of the static dining philosophers problem. Each philosopher
will be viewed as an autonomous actor modelled by an instance of the COO class
SPhilo shown in Figure 4, and a table is a set of instances of this class.
In order to be able to set communications, an Object must store references to other
Objects. To this end, the types of attributes, places and parameters are allowed to be
COO class references in addition to the types of the data language. But COO classes
are not allowed in order to prevent the nesting of Objects. When an Object has a
reference towards another Object, it has access to the public elements of that Object.
The public elements provided by an Object - attributes, operations and services -
are defined in the specification of its class and they have different purposes.
Attributes and operations are called from pieces of code of the data language and they
are intended to support synchronous data flows between Objects. Services are called
from OBCSs and are intended to support asynchronous control flows between
Objects.
CoOperative Objects: Principles, Use and Implementation 227
end.
class SPhilo implementation;
attributes
rn: SPhilo*; //the right and left neighbours
ln: SPhilo*;
nbeating: short; //counts how many times the SPhilo eats
operations
eat() /// nbeating = nbeating + 1; ///;
OBCS
<> <>
GiveLFork GiveRFork
glf starteating f grf
<f> <f>
f
lf rf
lf + rf
NoLFork NoRFork
LFork Eating RFork
<fork> <fork>
<fork>
lf + rf
lf rf
_S->eat()
f
f
alf stopeating arf
<f>=_S->ln->GiveRFork() <f>=_S->rn->GiveLFork()
end.
Attributes and operations appearing in a specification are defined in the same way
as in an implementation. They may be called by Preconditions, Actions and Emission
Rules of other Objects. They may also be called by the code of operations, but this
may cause synchronisation problems due to the synchronous semantics of operation
calls. Indeed, an operation is assumed to always be available, and this property is not
guaranteed if an operation calls an operation of another Object which in turn calls ...
In fact, operation calls are synchronous because they are considered to be attributes
whose value is computed upon request. In any case, public attributes and operations
may always be removed from the interface and replaced by services. When the system
228 C. Sibertin-Blanc
under consideration is distributed and the Objects are intended to run on different
computers, it is much more safe that their specifications include only services.
Services support control flows between Objects, that is to say interactions which
have an effect upon the behaviour of the addressee and/or the applicant of the
communication. A service request is asynchronous since the server may need some
time to provide a result, either because its current state disables the service or because
processing the request requires a lot of work. Requesting or rendering a service
implies synchronisation constraints and relates to the behaviour of Objects; thus
service requests and service executions are defined within OBCSs, and the
specification of a class only contains the signatures of its services.
Each service provided by a COO class is implemented by a pair of places of its
OBCS: an argument-place intended to receive tokens which are requests for the
service, and a result-place in which the client retrieves the result of its request. (In
fact, result-places may be implemented on the client side, so that the server sends the
result-token to the client; but from a theoretical point of view, the contract of a server
is only to make a result available for each accepted request; for instance, it is of no
concern if the client disappears and leaves the result-token). Thus a service request is
treated by a sequence of transition occurrences: the first transition of this sequence
takes the request token from the argument-place, while the last transition puts a token
down in the result-place. Graphically, argument- and result-places do not appear in
the OBCS, but transitions connected to them (respectively referred to as accept- and
return-transitions) bear a dangling arc labelled with the respective parameters. Of
course, one transition may be both the accept- and return-transition of a service, as for
the services of the SPhilo class in Figure 4.
In order that the services of an Object may be requested with confidence, its OBCS
must be honest and discreet [Sibertin 93]. Honesty means that when an accept-
transition of a service occurs, then a result-transition of this service is quasi-live (in
other words: whatever transitions occur after the accept-transition, there is a reachable
marking which enables a return-transition). If this property is lacking, some requests
for this service may never receive an answer, resulting in a definitive blocking of the
requesting task. Discretion means that a service provides a result only if it has
previously been requested. If this property is lacking, some issued result-tokens would
never be consumed. Honesty and Discretion are equivalent to the fact that any
sequence of transitions rendering a service may be reduced to a single transition. In
Figure 5, OBCS1 is not honest, OBCS2 is not discreet, while OBCS3 is neither of
them. A third property that an OBCS must satisfy, reliability, will be introduced in
section 5.
A service request takes place only in the Action of a transition (Cf. transitions alf
and arf in Fig. 4). When such a request-transition occurs, a request-token grouping
together the in-parameters of the request is put into the argument-place of the server’s
service; when the result-token of this request is available, the transition retrieves it
from the corresponding result-place and completes its occurrence. Thus, it is possible
that the occurrence of a transition requesting a service lasts for some time, until the
server provides the result. However, other transitions may occur in the meantime so
that a client is not blocked by a service request. Indeed, the formal semantics of a
request-transition splits the transition into two: one transition for sending the request-
CoOperative Objects: Principles, Use and Implementation 229
token and another for retrieving the result-token, connected by a waiting place which
holds the request identifiers (as an illustration, compare the transition alf of a
SPhilo with the transitions alf and rlg of a PhiloTable).
<>
a
<>
b
<>
a <> a
<>
b
a b a a b
Fig. 5. OBCS1 is not honest, OBCS2 is not discreet, OBCS3 is neither honest nor discreet
The COO formalism supports the dynamic creation and deletion of Objects. This
feature is illustrated by the DPhilo class which models the dynamic dining
philosophers problem (Cf. Fig. 7): each occurrence of transition t7 brings about the
introduction of a new DPhilo around the table, and a DPhilo disappears when
firing its transition dead.
An Object of a system introduces a new Object into this system by creating a new
instance of a COO class and calling its Init operation. Then, the new Object
becomes active; more precisely, it starts the execution of its OBCS after the execution
of its Init operation. Since introducing a new Object into a system concerns the
behaviour of the whole system, it must take place in the Action of a transition.
The deletion of an Object is more problematic. An Object is considered as being
dead, and can thus be deleted, only when no other Object has a reference to it (so it
can no longer receive an operation or service call) and in addition it has reached a
dead marking (so it has nothing to do). A DPhilo satisfies this requirement, since
firing the transition dead produces a dead marking. An implementation of COOs
could include a Garbage Collector based on this principle. However, it is better if the
deletion of an Object explicitly occurs in the Action of a transition, since it greatly
concerns the behaviour of the whole system.
In any case, the deletion of an Object has to comply with the constraints of the
asynchronous request/reply protocol:
1. when an Object, as a server, has received a request-token which enables an accept-
transition, it cannot be deleted before it provides a result for this request. On the
other hand, if the request-token does not enable any accept-transition, it is possible
to consider that the Object has been misused by the issuer of the request.
2. when an Object, as a client, has issued a request for a service, it cannot be deleted
before it retrieved the result of this request.
Anomalies resulting from the breaking of these rules may be considered both from the
Petri Net and programming language points of view. From the PN point of view, in
the first case a token will be blocked in the waiting place of the client, and in the
second case a token will be blocked in the result-place of the server. Considering the
COO formalism as a programming language, a task of the client will be blocked for
ever in the first case, and in the second case an ‘‘invalid reference’’ run-time error
will occur when the server sends the result. SYROCO does not include a Garbage
Collector, but the function coodelete returns an error status and does not delete the
Object if the two rules mentioned above are not satisfied.
CoOperative Objects: Principles, Use and Implementation 231
end.
pl pr pl pr pl pr pl pr
CoOperative Objects: Principles, Use and Implementation 233
Several policies ensure that such cases never occur; among them, we choose the
following one:
(2) a Philosopher joins the table only if he is introduced by an already installed
colleague, and he sits down on his lefthand side (so c1 is avoided);
(3) a Philosopher does not concurrently introduce a new guest and leave (c4 avoided);
(4) when a philosopher intends to leave, he asks his right neighbour for the permission
to leave; this latter refuses if he himself is leaving or introducing, and when he
accepts, he is prevented from leaving and introducing until he knows his new left
neighbour (c2 and c3 avoided).
The OBCS of the class DPhilo implements this policy (among the elements
inherited from the OBCS of the class SPhilo, only places NoLFork and RFork
appear in Figure 7).
When joining, rule (1) is ensured by the initial marking produced by the operation
Init and the fact that a philosopher tries to introduce a new guest only when he has
no left fork; when leaving, (1) is ensured by the fact that places NoLFork and
RFork are input places of the transition leave.
Rule (2) is ensured by the Action of the transition t7.
The mutual exclusion of leaving and introducing (rule (3)) is enforced by place
NoLFork, since a DPhilo may introduce a new guest or leave the table only when
his place NoLFork contains a token.
As for rule (4), it is ensured by the fact that the service LNMayLeave is also in
mutual exclusion with introducing and leaving by means of place NoLFork. This
service is supported by transitions t4 and t5; thus it is permanently available and
this prevents the system from blocking when all philosophers simultaneously intend
to leave.
<>
LNMayLeave
<>
LNMayLeave p5
<phil>
NewLN introduce
t4 _S->ln=phil t6 _S->nbeating >
t5 _S->delayint
No Yes <> <pi,f>=_S->h->Give()
f==NoFork else
<pi,f>
p6
<int, fork>
<pi,f>
t7
NoLFork _S->nbeating = 0;
DPhilo* phil = new DPhilo;
<> = _S->ln->NewRN(phil);
phil->Init(pi,_S->ln,_S,f,_S->h);
_S->ln = phil;
leave <f>
RFork
(_S->nbeating >
_S->delayquit) && <fork> <phil>
NewRN
(_S->ln != _S->rn)
_S->rn=phil t8
<ok>=_S->rn->LNMayLeave()
ok !(ok) <>
<f>
f t3 p4 dead
<>+<>
f =_S->h->Take(f) _S->coodelete()
p3
<fork>
p1 t1 p2 t2
<>=_S->ln->NewRN(_S->rn) <>=_S->rn->NewLN(_S->ln)
end.
Fig. 7. (continued)
The Precondition of the transition leave guarantees that at least two philosophers
remain around the table.
objects. These two viewpoints are quite close when sequential OO languages are
considered, but there is no denying that they are far from each other when PNs are
taken under consideration.
The COO formalism supports three kinds of inheritance.
Specification inheritance is aimed at supporting the subtype relation. In this case,
the derived class includes the declaration of the public attributes of the inherited
classes, and the signature of their public operations and services. In addition, it is
possible to redefine (or override) the type of the arguments of operations and services
according to the contravariant rule, and the type of their result according to the
covariant rule. The contravariant rule specifies that the type of a parameter may be
replaced by a supertype, and the covariant rule says that the type of a parameter may
be replaced by a subtype. Thus, a class derived by specification inheritance offers an
interface which is compatible with those of the base classes, but it does not share their
code.
Implementation inheritance strengthens specification inheritance and enables the
derived class to share the code of operations. In this case, the derived class includes
the declaration of the attributes and services of the base classes, as well as the
definition of their public and private operations; but the OBCS is not inherited and the
derived class has its own one.
In the OBCS inheritance case, the derived class fully inherits another class; it
inherits its specification and its implementation, including the OBCS. Multiple
inheritance is not allowed, in order to prevent problems arising from the merging of
OBCSs.
Subtyping includes two aspects: when a call for an operation or a service is
addressed to an instance of the subtype instead of an instance of the supertype,
1. the type of the formal parameters of the subtype has to match the type of the actual
parameters of the call, and
2. the requested service has to be available at the subtype instance if it would have
been available at the supertype instance.
The first aspect warrants the safety of data types, while the second aspect warrants the
safety of the behaviour. For instance, the class DPhilo is not a subtype of the class
Sphilo, since a SPhilo provides its GiveLFork and GiveRFork services for
ever, while a DPhilo stops as soon as it leaves. Conversely, class SPhilo is not a
subtype of class DPhilo since this latter offers additional services.
Specification inheritance guarantees that the interface of the derived class offers
the same possibilities of interaction as the interface of the base class, and a class B
may be a subtype of a class A only if B inherits the specification of A. The authorised
redefinitions of signatures preserve this compatibility, and it is commonly agreed that
they maintain the type-safety of data exchanges [Liskov...93].
Figure 8 shows three classes which are in specification inheritance relationship but
which feature different behaviours: a client of an instance of class A will successfully
request the sequence of services "c b c b ...", while it will block if it attempts to do the
same with an instance of class B, and it will succeed if it does the same with an
instance of class C. Class C is a subtype of class A, while class B is not because it is
unable to simulate the behaviour of class A.
236 C. Sibertin-Blanc
In [Hameurlain...99], conditions upon the OBCS of two COO classes are given
ensuring that one of them is a subtype of the other. The first condition is that any
sequence of service requests which is accepted by the supertype is also accepted by
the subtype. The second condition, referred to as reliability, concerns only the OBCS
of the subtype; it requires that, whatever the marking reached by the Object, the set of
services which are available under this marking only depends on the sequence of
service requests which have been previously accepted. In other words, if two
markings are reached while accepting the same sequence of services then these
markings enable the same service requests. Figure 9 shows typical examples of
OBCSs which are not reliable, while all the COO classes presented within this paper
have a reliable OBCS. If the OBCS of a class does not satisfy this property, this class
is a subtype of no COO class. In fact, any COO class should have a reliable OBCS; if
not, the class has an unsafe behaviour, since a client has no means to know whether
its next request will be accepted or not. It is worth noting that it can be decided
whether a COO class is a subtype of another one [Hameurlain...99].
•
• •
d
<i>
c <i>
c <i>
c
• •
<> a
<>
a
<> a
<>
<> <>
•
<> b
<>
a <> b <> b
<>
<> <> <>
The semantics of an isolated Object formalises how the values of tokens and
attributes are taken into account by the Preconditions (the enabling rule) and
processed by the Actions (the occurrence rule) of transitions. This may be fully
achieved only if the data language has a formal semantics. For instance, [Sibertin 92]
gives a formal semantics for isolated Objects, using a formalism based upon Abstract
Data Types [Ehrig...85] as the data language.
Whatever the data language, it is possible to define a pure PN semantics which
accounts for the flow of tokens across the places of the OBCS but ignores their
structure, their value and how they are processed by the transition occurrences. For
this purpose, a COO class is modified in such a way that all the types of places are
references towards classes of data objects. Thus tokens become (lists of) references to
238 C. Sibertin-Blanc
objects and include neither scalar values nor objects. These new object classes remain
abstract; thus Preconditions and Actions become useless and disappear, as well as
attributes and operations, since tokens are pure identifiers referring to no value. After
some additional transformations accounting for the dynamic creation and deletion of
Objects, a COO class may be viewed as a Well Formed Coloured Petri Net
[Chiola...90], the set of identities of the instances of each object class being
considered as a Colour domain.
One may wonder whether applying these modifications to a COO system changes
its behaviour; in other words, to what extent a semantics of COOs, which is partial
because it is based only upon the PN theory, is an accurate semantics, and to what
extent the results obtained by the PN analysis techniques of a COO system really
describe the behavioural properties of this system? The answer depends on the use of
Preconditions. If they are used jointly with the net structure of the OBCSs to define
the Objects' behaviours -as for example a Precondition which evaluates to false
whatever the value of tokens- then the PN semantics is not accurate. On the other
hand, this semantics is accurate if Preconditions are used only as they are intended for
solving conflicts among transitions or tokens; in this case, for any run of an Object
stripped of its data part, there exists an initial value of this Object yielding this run
[Sibertin 85] (The converse clearly holds in any case). Thus, a designer may trust the
results obtained by the PN analysis techniques as far as he/she respects the ‘separation
of concern’ principle.
As for the cooperation among the Objects of a system, [Sibertin 94] gives formal
semantics which ignore the types of tokens. In fact, this paper provides two semantics
for the cooperation. The first one is straightforward and defines the change in a COO
system produced by a set of Objects which concurrently fire one transition. The
second semantics may be viewed as a global, or centralised one; it is defined by
means of an algorithm translating a COO system into a single Object which is isolated
(it provides or requests no service) and equivalent (more precisely: bisimilar) to the
whole system. As an example, this algorithm translates a system of four SPhilo
Objects (cf. Figure 4) into an Object which is quite close to an instance of the
PhiloTable class given in Figure 3 (the OBCS of the PhiloTable class
accounts for the sending of tokens caused by service requests, but it does not include
the elements for the dynamic creation and deletion of Objects, nor for the inheritance
relation among COO classes, nor for the identification of service requests which is
needed to distinguish requests concurrently issued or received for the same service).
7. SYROCO
SYROCO is an environment for designing COO classes and executing COO systems.
It is intended to be used either as a simulation tool or as a programming environment
[Syroco 96, Sibertin 97b].
A COO class is edited either using a tailored version of MACAO, the generic Petri
net graphic editor developed at the MASI [Mounier 94], or as a text file compliant
with a very simple syntax. In the former case, the MACAO file is translated into a
text file before applying the following main utilities:
• newproj, to create the working environment (required directories and files) for a new
system,
• gencode, to generate the C++ code associated with a COO class,
• gentest, to generate a main program for an instance of a COO class,
• genmake, to generate makefiles.
SYROCO is based on the language C++ in two ways. On the one hand, C++ is the
data language used to write the code of the files containing the external declarations
(as shown in Figure 2), and also to write the body of Object operations and the pieces
of code embedded in the transitions and places of OBCSs. On the other hand,
SYROCO generates C++ code for each COO class and implements any Object as an
instance of a C++ class. The choice of C++ is contingent, and COOs can be
implemented using another OO Programming Language. However, the crucial point
is to use the same programming language both as the data language and as the
implementation language. If two programming languages are used, the integration of
the data processing and behavioural dimensions of Objects is difficult and results in
poor performances, and in addition the designer-defined code embedded in an Object
can access neither the kernel of SYROCO nor the Object's implementation.
Although SYROCO is mainly a COO compiler, the OBCS of each Object is not
flattened into a static control structure. It is interpreted by a generic ìtoken game
playerî which repeatedly looks for transitions which are enabled under the current
marking and fires one of them. This feature allows the non deterministic nature of
Petri nets to be retained and provides each Object with a powerful symbolic debugger.
It also allows dynamic changes of the value of some parameters of the interpreter. In
this way, each Object may control how its OBCS is executed. In addition, interpreting
OBCSs avoids burdening each COO++ class with a large piece of code.
SYROCO provides users with a number of facilities both for the simulation and the
final implementation of complex systems. Some of these facilities are pragmatic and
intended to ease the development of COO systems, while others extend the expressive
power of the formalism and are intended to allow a fine control of the behaviour of
each Object. They will not be addressed here, but we shall discuss the main design
decision of an implementation of the COO formalism. Details about the structure and
the functionalities of SYROCO may be found in [SibertinÖ95a, 97b] and [Syroco 96].
Each COO class gives rise to the generation of a C++ class, referred to as its COO++
class, in such a way that each instance of a COO class is implemented as an instance
240 C. Sibertin-Blanc
of the corresponding COO++ class. First, the compiler provides a COO class with two
operations for each service, in charge of sending respectively request- and result-
tokens. The compiler also transforms the OBCS of a COO class in order to implement
the formal semantics of service requests (namely, argument- and result-places are
added, request-transitions are split, and the sending of tokens is added to the Action of
the appropriate transitions, cf. section III.2). After these modifications, the OBCS of
each Object fully implements the PN semantics of the communications protocol
through services.
Then, a COO class is compiled into a static data structure of the implementation
language, and this is one essential reason for the efficiency of SYROCO. Only the
tokens, which are implemented as instances of generated C++ classes, are stored in
dynamic linked data structures. The structure of a COO++ class is very similar to the
one of its COO class. A COO++ class has one member attribute for each attribute of
the COO class and one member function for each operation, and also one member
attribute for each place and transition of the OBCS. The class of a place attribute
inherits functions for the management of tokens and it also includes specifically
generated functions (the body of which is provided by the designer) to order the
tokens of the marking or to be triggered upon the arrival or the departing of tokens.
Similarly, the class of a transition attribute inherits general purpose functions, and it
includes specifically generated functions to test its Precondition and to execute its
Action. These classes of place and transition attributes are also equipped with
attributes which determine the policy of the ordering of tokens into places, the priority
of transitions, the delays associated with arcs, or even the hiding of tokens and
transitions; an Object may change the value of these attributes while it is running and
thus gains some reflexivity.
The implementation of the inheritance and subtyping relationships among COO
classes heavily depends on the possibilities of the implementation language. Indeed,
any reasonable means to implement the polymorphism among Objects has to be based
upon mechanisms of the implementation language. Thus, SYROCO relies on the C++
inheritance mechanisms for supporting the three inheritance relationships among
COO classes (Cf. chapter V). To achieve this, a COO class gives rise to the
generation of three C++ classes: one for its specification, a derived class for the
attributes and operations of its implementation, and a third derived class, the COO++
class, accounting for its OBCS. The specification, implementation and OBCS
inheritance relationships among COO classes are translated into inheritance
relationships among the corresponding C++ classes. When implementing the COO
formalism, inheritance is the only aspect which depends on the implementation
language, and SYROCO suffers from the limitations of C++ in this regard.
Each Object has its own OBCS interpreter; more precisely, it inherits a generic PNO
interpreter which locally executes its OBCS. Thus, each Object is actually
implemented as an autonomous process that encapsulates its behaviour. As a
consequence, the behaviour of a COO system features the same modularity as its
structure, and there is no difficulty in taking advantage of the resources of a multi-
CoOperative Objects: Principles, Use and Implementation 241
However, dealing with true parallelism entails implementation issues. One solution
is to develop a specific runtime system which provides the required functionalities.
The other solution is to rely upon the underlying operating system, using its capabili-
ties as much as possible, as does SYROCO. As a consequence, SYROCO has to
account for the actual services offered by operating systems, and thus it generates
COO++ classes for sequential computing environments, for environments supporting
threads (or lightweight processes), and also for COOL (the Chorus Object-Oriented
Layer [Chorus 94]), a distributed computing environment compliant with CORBA.
The sequential version: The sequential version of SYROCO implements the
interleaving semantics among Objects. Thus, the concurrency among Objects is only
virtual. To this end, SYROCO includes a scheduler which randomly selects one
Object of the system, and then activates this Object by calling its interpreter for a
given number of transition occurrences. In this version, an interpreter returns as soon
as no transition is enabled, since only the activation of another Object can enable a
transition.
The threaded version: SYROCO implements the true parallelism semantics by
delegating the actuation of Objects to the underlying operating system, according to
the computing resources. In the threaded version, all Objects run in the same system
process, but each one has its own thread of control. More precisely, making an Object
active consists of spawning a new thread and calling the Object interpreter inside this
thread, referred to as its main thread. As a consequence, each Object is accessed by
several threads of control:
(1) its main thread,
(2) the threads of client Objects calling public operations or reading the value of
public attributes,
(3) the threads of client Objects sending tokens into accept-places in order to request
services,
(4) the threads of server Objects sending tokens into result-places as replies for
previous service requests.
Each Object includes a mutual exclusion lock for ensuring that threads (1), (3) and
(4) do not concurrently access the marking of places. As for the Object’s attributes,
they are accessed by threads (1) and (2) and SYROCO sets a specific lock during the
execution of the Actions of transitions; thus, it is left to the designer to protect them
against concurrent accesses by including appropriate get and release statements in the
code of public operations, according to the logic of the system.
Contrary to the sequential version, an interpreter does not return when no transition
is enabled, instead it blocks until it receives a token from a thread (3) or (4).
The CORBA version: This version is based on the same principles as the threaded
version, and in addition it enables the Objects of a system to run on different nodes of
a network. Due to this fact, it is advisable that Objects do not communicate by
synchronous communications (i. e. public attributes and operations). This version
relies on COOL for the remote function calls.
From a software development point of view, every one of these three versions of
SYROCO is useful for finalising a COO system. The sequential version allows the
designer to test and validate the behaviour of each Object as well as the cooperation
among Objects; but issues related to concurrency among Objects are excluded. In the
threaded version, the execution of an Action may be interrupted by operations and
CoOperative Objects: Principles, Use and Implementation 243
vice versa, and tokens may arrive at any moment. Thus, this version allows the
designer to focus upon the concurrency among Objects. The issues related to the
distribution of Objects are accounted for only by the CORBA version.
COO++ classes include a lot of compilation conditions which may be selected by the
user according to his/her aims. The choice among the three versions above as well as
the actual use of the additional features of SYROCO (the delivery of traces and
statistics, local clocks, keeping the names of places and transitions, ...) depends on
these conditions. Thus, either a COO++ class is equipped with many facilities and
features, or it is an optimised implementation of a COO class.
With regard to size issues, the size of the code shared by the COO++ classes of a
system is around 60 K, whereas a class own code is mainly the embedded code
provided by the designer. The memory required to allocate a new instance is a few
Ks; for instance, the memory size required to allocate an instance of our DPhilo
example (including 11 places and 17 transitions) varies from 2,5 to 3,6 K according to
the number of compilation conditions. Thus, the PN-component of Objects is sparing
of memory.
With regard to performance issues, the OBCS interpreter is quite efficient, and the
overhead resulting from the concurrency is negligible with regard to the execution of
Actions (in as much as they need some amount of computation). The occurrence of
one million transitions of the DPhilo example takes about 4mn 30 on a Sun
SPARCclassic station and 1mn on a Pentium 120 Windows NT PC with Visual C++.
This speed does not depend on the size of the net, but it is likely to grow with the
number of tokens of the marking. Indeed, the number of bindings of the input
variables of a transition with tokens is equal to the product of the size of the markings
of the transition’s input places; so, the interpreter may have to build and test many
bindings before finding out one which enables the transition.
Conclusion
The COO formalism belongs to the family of High-Level Petri Nets which attempt to
overcome the inadequacy of PNs with regard to modularity and the data processing
dimension of systems. This formalism draws its inspiration from the OO approach,
and it introduces all the concepts of this approach into PNs while remaining within
this theoretical framework. As a result, it widens the field of use of PNs in several
directions:
• The modelling and analysis of systems where the data structure plays a crucial role,
such as Information Systems, Workflow or Business Procedures;
• The modelling and analysis of open distributed systems which include a varying
number of processes communicating in an asynchronous manner;
• The use of a single PN-based conceptual framework throughout the software
development process, from the system analysis and specification steps to the
implementation.
244 C. Sibertin-Blanc
Acknowledgement
SYROCO has been developed thanks to a grant awarded by CNET and the
contribution of many people: R. Bastide, W. Chainbi, L. Dourte, N. Hameurlain, H.
Kria, P. Palanque, A. Saint Upéry, P. Touzeau, J.-M. Volle. I am also grateful to C.
Hanachi for useful comments on a preliminary version of this paper.
References
Johan Lilius
1 Introduction
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 247–275, 2001.
c Springer-Verlag Berlin Heidelberg 2001
248 J. Lilius
The intended application area of the techniques presented in this paper is the
analysis and verification of programs for safety-critical embedded systems. It is
generally felt that direct analysis of programs is infeasible because of the state-
space explosion problem. For example the work on static analysis of ADA [19]
aims at abstracting away details of the program so that reachability graph gen-
eration becomes feasible. However we feel that recent advances in new analysis
techniques, like the stubborn set method [20] as implemented in PROD [12] or
the model-checking algorithms developed in [9] and implemented in the PEP-
tool [11], make the full analysis of programs possible. Also we think that the area
of safety-critical embedded systems, where the programs are usually relatively
small, provides an application area where the full and automated analysis of
programs will not only be practical but also cost-effective.
The presented formalism OB(PN)2 is based on B(PN)2 , a Basic Program-
ming Notation for Petri Nets [6], which was given a semantics in terms M-nets
in [5]. In [17] B(PN)2 was extended with procedures that allowed parameters
to pass by value. In this paper we extend B(PN)2 with objects and with refer-
ences. In B(PN)2 a variable is translated into a data-box. A data-box is a small
net that consists of a place, where the value is stored, and some transitions,
that are used to access the place. However for procedures this structure is no
longer adequate, because with recursive and/or parallel procedure calls, several
instances of the same variable need to be stored in the data-box. To accom-
modate this, the data-box was extended in [17] to store a frame-index together
with the value, that marks the owner of the value. The owner of the value is
one of possibly several concurrently and/or recursively active instances of the
procedure in which the variable is declared. When one introduces objects this
is no longer enough, because now we need to distinguish between instances of
member variables that belong to different objects. For this we introduce an ex-
tra identifier, the object-identifier, which can be assigned at compile-time. The
object-identifier, frame-index pair is called a scope-index. The scope-index is
sufficient to always unequivocally distinguish between different instances of a
variable. This means that we can store all the values of variables in one place,
1
Channels are not described in this paper.
OB(PN)2 : An Object Based Petri Net Programming Notation 249
and use the scope-index together with the identifier to access the value. Thus
we have in essence created references.
We make a distinction between objects and values like JAVA [1]. The built
in types (integers and booleans) are passed by value, while objects are passed
by reference. So like in JAVA we have an implicit notion of pointers that is
transparent to the user.
The semantics of OB(PN)2 differs substantially from the original B(PN)2
M-net semantics [5]. We have had to extend M-nets to be able to correctly treat
procedure call instances. Also the treatment of reference parameters requires
changes in the original translation of variables.
The current version of the language does not provide synchronization con-
straints on the methods of the object, nor does it provide inheritance, because
the combination of these two features may lead to problems, the “inheritance
anomaly” [18]. Essentially this means that in the presence of inheritance, con-
straints put on the concurrent behavior of a subclass may break encapsulation
and require redefinitions in the parent class. However a proposal for the transla-
tion of the language extended with inheritance and synchronisation constraints
has been presented in [16]. Also note, that some of the restrictions on the lan-
guage are done so that the translation can be done in a recursive descent fashion.
We will point out these restrictions at the appropriate point.
The paper is structure as follows. Section 2 describes the syntax of OB(PN)2 .
Section 3 gives a short introduction to M-nets, emphasizing the differences to
more traditional net formalisms. In Section 4 we give an introduction to the
basic ideas relevant for the translation. Section 5 gives the translation.
Acknowledgements
This research has been partially supported by the DAAD through the Konrad
Zuse Programm, while the author was at Institut für Informatik, Universität
Hildesheim, but most of it has been done while the author still was at Digital
Systems Laboratory, Helsinki University of Technology. An extended abstract of
this work has appeared as [15].
I would like to thank Eike Best, Elisabeth Pelz and Hanna Klaudel for helpful
discussions during the early stages of this work.
2 OB(PN)2
translated into transition guards and can thus be combined with the logical and
operator. Variables that are members of a class are distinguished from global or
procedure variables by the prefix this, however whenever the context is obvious
we will leave this prefix out.
We make a restriction to the language: class and procedure declarations may
not be nested, ie. they may only appear at the global scope.
3 M-Nets
This section gives the basic definitions of M-nets and tries to explain the basic
intuitions behind the composition operators for M-nets. For a deeper explanation
the reader is referred to [4].
High-level nets are nets where the places and transitions are annotated. The
choice of formalism for these annotations determines the firing-rule of the model.
Common to all these formalisms is, that they can also be unfolded into low-level
nets by substituting values for all the variables in the annotations [13]. M-nets [4]
extend the notion of high-level nets by introducing parameterized labels on tran-
sitions, and these labels are used to compose larger nets using composition oper-
ators. A CCS-like algebra for nets annotated with labels was already introduced
by [3]. In [4] this idea is extended to allow parameters (variables) in the labels.
This makes it possible to view the synchronization of complementary labels as
communication between subnets [14].
OB(PN)2 : An Object Based Petri Net Programming Notation 251
the universe of values. We shall assume that at least the normal operations on
integers and booleans are available. Our definition above differs from the one
given in [4] in that we allow arbitrary types for entry and exit places and tuples
of variables as arc annotations.
(a) N1 (b) N2
token x by 1 when fired. Synchronization and restriction are often done over the
same set of labels, and we abbreviate this as syr{var} = sy{var}rs{var}.
All the nets that we will apply our operations on will have single entry and
exit places. Thus the operations of sequential composition and choice are very
simple. The sequential composition of two nets Σ1 ; Σ2 is obtained by merging
the exit place of Σ1 with the entry place of Σ2 . For choice Σ1
Σ2 we merge the
entry places of Σ1 with those of Σ2 and the exit places of Σ1 with those of Σ2 .
will give boxes for all the basic objects of the language: classes, object, vari-
able, types, procedures, methods, etc., while the control of the program will be
translated as the operations of the box-calculus.
An object can be seen as an abstract data-type together with an internal
state and an identity. The object has a set of internal variables, and a set of
methods for manipulating its state. As the idea in the translation is to create
a M-Net (a box ) for each concept, we obtain one variable-box for each internal
variable, one procedure-box for each procedure and method, and a classid-box to
store the identity of the object. These boxes are then composed in parallel and
synchronized and restricted over all internal labels. The resulting net is called
a class-box. We will start the discussion by first introducing the ideas behind
the concept of a procedure-box. Then we will look at the class box and finally
introduce references.
The main problem in the translation of procedures is the need to distinguish
between the values of the local variables of different instances of the procedure.
A solution to this problem using frame-indices 2 was described in [17], and we
shall briefly recall the idea here.
Let us start by looking at the execution of a recursive procedure in a parallel
programming language. Assume that we have a program with some number of
parallel threads where in two threads we will call a recursive procedure P ()
with no parameters. In the case of a sequential language one would for each call
allocate a stack frame that contains the information identifying the instance,
but in a concurrent language each thread must have its own call stack. In terms
of high-level nets this would suggest that our formalism should support a stack
ADT. However if we fold the different instances of the procedure into one high-
level procedure box, and use colored tokens, in this case integers, as indices to
distinguish between the instances, it turns out that we can simulate the stacks
by simply using pairs of integers. Each procedure instance has an index and this
index stored by the caller. At the return of the callee the caller then knows which
index to expect, and so the right thread is continued.
An example will make this idea clear. As our example we will use the short
OB(PN)2 program 3(a). The program consists of a single procedure declaration
and a main program in which the procedure is called in parallel. The procedure
may either call itself recursively, or return by an empty (skip) statement. The
net N1 of figure 3(b) is the procedure box of the procedure P , while the net
N2 of figure 3(c) is the parallel composition of the two calls to P . We now
claim that the parallel composition of these nets N1 and N2 synchronized and
restricted over the call and return actions {Pc , Pr }, will achieve the wanted
behavior. To understand the idea it is easier to first consider the procedure
box in figure 3(b) alone, and think of the synchronizations and restrictions as
happening “on-the-fly” while the net is executed. Let us look at the structure of
the procedure box N1 . The box is initialized at the beginning of the program by
transition t0 labeled by init, which stores a token 0 in place p1 . This place always
2
In compilers the information needed by a single execution of a procedure is managed
by an activation record or frame
OB(PN)2 : An Object Based Petri Net Programming Notation 255
contains the next free frame-index. The box is now initialized and transition t1 ,
modeling procedure entry and labeled Pc (i), can synchronize with the either
of the transitions labelled Pc (x) in N2 . When this synchronization happens, t1
fires resulting in a marking {p1 → 1, p2 → 0}. The token 0 in p2 represents the
fact that instance 0 of P is now ready to execute. In this case the body of the
256 J. Lilius
The procedure-box of figure 3(b) can be used mostly as such, only the labeling
of the transitions has to be modified. The data-box of [5] has to be modified so
that we can distinguish between the different instances of the variables. This
is done by storing the frame-index along with the value of the variable. It is
also convenient to change the definition of the data-box slightly. In the original
version there is no distinction between the first use and the initialization of the
OB(PN)2 : An Object Based Petri Net Programming Notation 257
It is now easy to see, that when synchronizing and restricting the parallel com-
position of the procedure box with the data boxes, the parameters will be copied
and transfered.
Let us now turn to the translation of classes and objects. In [17] we only
needed frame-indices to distinguish between different instances of a variable.
When one introduces objects this is no longer enough, because now we need to
distinguish between instances of member variables that belong to different ob-
jects. To accommodate this we introduce an extra identifier, the object-identifier,
which can be assigned at compile-time. The object-identifier together with a
frame-index are sufficient to always unequivocally distinguish between different
instances of a variable. The object-identifier, frame-index pair is called a scope-
index. Since the frame-indices are generated dynamically it suffices to generate
all the object-identifiers at compile time.
The crucial point to notice now is that the scope-index together with the
identifier of the object or variable is a globally unique way to identify them.
This means that we can store all the values of variables in one place, and use
the scope-index together with the identifier to access the value. Thus we have in
258 J. Lilius
class A
var x : Int;
method inc()
d
< x = x + 1 >
fin
endc
and restriction. The places p0 , p1 and the transition t1 are generated by the
classid-box. The method inc generates t2 , p3 , t4 , p5 , t6 , p6 , and place p2 represents
the variable x, while p4 will store the values of x. We have left out those parts
OB(PN)2 : An Object Based Petri Net Programming Notation 259
of the translation that are only needed for the initialisation of the nets, togheter
with some labels that would have cluttered the presentation
Transition t2 , labeled A.inc(i, this, sc) is the method-call transitions. The
parameter i is the frame-index that is used to distinguish between different
instances of the method, while this and sc form a reference to the object. Assume
that somewhere in the program the object a is declared, and in the same scope
later on a call a.inc() is made. The initialisation of the object a is done by
transition t1 that store the object-identifier, scope-index pair for a in place p1 .
At the same time the local variable x is created. The variable x is stored in p2
while the initial value of x is stored in p4 . The call will be translated like a normal
procedure call, but an implicit extra parameter this will be added. A reference
to the object a will be passed as the parameters this and sc, and the call a.inc()
will synchronise with the transition t2 in the net N3 . Firing t2 results in a check
that the object has really been created, ie. the correct identifiers must exist in
p1 . At the same time the reference to a is copied into the local variable p6 of the
method. Transition t4 , which is the translation of the statement v = v + 1, then
retrieves the right reference to a from p6 , and then using the scope information
of a retrieves the reference to the variable x from the place p2 . This reference is
finally used to retrieve the value of x from p4 which is then incremented by one,
and stored back into p4 .
The translation will be given in terms of a function T [[]] from the syntactic entities
of OB(PN)2 to M-nets. The general structure of the translation function is given
in figure 7. Each syntactic construct in the grammar is given a translation into
either a M-Net, or a M-Net expression over the translation of the components of
the syntactic construct. Since the syntax is very simple, the translation function
essentially defines a recursive descent translator.
5.1 Declarations
The program declaration defines the global scope. The global scope is used to
restrict over the init and clear transitions of all declarations in the program.
Thus all the boxes are initialized and cleared synchronously at the same time.
is terminated when the block after the declaration ends. In practice this means
that a declaration is visible until the end of the program, procedure, class or
method, in which it is declared.
The creation and termination of scope takes care of two things:
1. The creation and deletion of local variables that have been declared at the
scope, and
2. the synchronization and the restriction over type, class, method and proce-
dure names that have been declared at the scope.
where,
OB(PN)2 : An Object Based Petri Net Programming Notation 261
Global variable: Since there exists only one global scope, that is instantiated
only once, we use the special pair < ∅, ∅ > to denote this.
Procedure variable: The scope-index is of the form < ∅, f id >, where ∅
denotes the fact that the procedure is declared in the global scope, while
f id ∈ N is the frame-index of the procedure instance.
Class member variable: The scope-index is of the form < oid, f id >, where
the oid ∈ N is the unique identifier of the object that the variable belongs
to, and f id ∈ N is the frame-index of the object.
Class member procedure variables: The scope-index < oid, f id > of vari-
ables declared in a class member procedure consists of the unique identifier
of the object that the method belongs to, together with the frame-index of
the instance of the method.
Thus the set of scope-indices (denoted scid in the figures below) is the set
(N ∪ {∅} × N ∪ {∅}). To simplify the translation we assume that all variables and
objects that have been declared in the program have been assigned a unique id,
and that this information is available at the beginning of the translation.
Type Declaration
Each type declaration is translated into a type-box (cf. figure 8). The type
box is used to map variables to values. Thus all variables of the same type are
stored in the same type box. More precisely, the type-box is used to store the id
of the variable, the scope-index of the scope in which it was created (remember
that we need the scope-index to correctly identify an instance of a variable), and
its value.
Fig. 8. The type box T (tname, type) for storing values of variables of type tname.
Variable Declaration
For each variable declaration we generate a variable box (see figure 9). The
variable box stores the unique id of the variable, the index to the scope that
created it, and the index of the current owner. The pair < varid , scid > concep-
tually is equivalent to a pointer in traditional programming languages like C.
One still needs a frame-index to distinguish between the different instances of
the variable.
The variable declaration must be treated differently depending on where in
the program it appears (ie. global and procedure scope, class scope, or method
scope), because the scopes of the variable are defined differently. We shall first
give the definition for the global and procedure scope, and then discuss the
creation and deletion for the other cases.
Global and procedure scope: When we declare a new variable we need to create a
scope-index for it. If the scope is the global or procedure scope, the first element
of the scope index is ∅. The second element is the frame-index i of the current
procedure frame (∅ again in the case of the global program). Remember that we
assumed that all variables in the program have been assigned unique identifiers.
The function uid (vname) returns returns this id. The initial value (initialvalue)
of the variable is true for booleans, 0 for integers, and l if the type is a range
{l, . . . , k}.
T [[var vname: tname]] = V (vname, tname)
γ I (var vname: tname) = ({new vname (id, sc, i), new tname (id, sc, v)} |
id = uid (vname), sc =< ∅, i >,
v = initialvalue)
γ T (var vname: tname) = ({delete vname (id, sc, i), delete tname (id, sc, i)}
| true)
δ(var vname: tname) = {new vname , delete vname , vname}
264 J. Lilius
Class scope: For a variable declared in a class, its creation and deletion must be
done at the same time as the object to which the variable belongs to is created.
Thus the handling of the scope index and the initial value is handled when the
class is translated. The translation function is simply:
T [[var vname: tname]] = V (vname, tname)
Object Declaration
objdecl −→ obj oname: cname
cobjdecl −→ obj oname: cname
mobjdecl −→ obj oname: cname
Class scope:
Method scope:
Procedure Declarations
where P (pname) denotes the net in figure 10. In the procedure box the transla-
tion of the procedure body is inserted for the transition Z.
The translation of the arguments is relatively straightforward: we create one
variable box for each argument and set up labels on the procedure creation
transition so, that correct variables and values are copied into these variable
boxes. The only thing we need to take care of is that the variable boxes are
initialised correctly. For value parameters a new variable is created, while for
reference parameters the reference is copied into the variable box. We only allow
objects to be passed by reference. We shall assume that this restriction is enforced
by some external means so that the translation becomes more manageable.
266 J. Lilius
vm
vm
vk = valk sck =< ∅, i >
k=1 k=1
m
β(t3 ) = nk = ak ,
k=1
The function V constructs a variable box for each reference variable that is
declared in the parameter list:
V (arglst) = k∈{1...m} V (tk , ak ) ,
while the function δ gives the initialization and termination labels of the variable
boxes defined by the procedure declaration:
δ (arglst) = {new ak , delete ak | k ∈ {1, . . . , m}}.
To ease the definition of the labelings in figure 10 we introduce an ordering
on the parameters, so that the value parameters come before the reference pa-
rameters. Let vm be the number of value parameters, and m the number of all
OB(PN)2 : An Object Based Petri Net Programming Notation 267
Class Declaration
classdecl −→ class cname cdecls endc
cdecls −→ cdecl ; cdecls | cdecl
cdecl −→ cvardecl | cobjdecl | methoddecl
cvardecl −→ var vname: tname
methoddecl −→ method mname( arglst ) pbody
λt1 = {newcname (id, sc)} newv (id, sc, i)}
v∈V ars(cname)
λt3 = {{deletecname (id, sc)} newv (id, sc, i)}
v∈V ars(cname)
Method Declaration
methoddecl −→ method mname( arglst ) pbody
OB(PN)2 : An Object Based Petri Net Programming Notation 269
However the functions V and δ must now be modified to cope with the extra
variable box for this.
We add a prefix cname. to the call and return transition labels, to allow for
overloading of names. The labels of the net are given in figure 12.
5.2 Commands
vm
vm
vk = valk sck =< oid, i >
k=1 k=1
m
β(t3 ) = nk = ak ,
k=1
Ins(const) = (φ/const/φ)
Ins(e1 op e2 ) = (AS1 ∪ AS2 /E1 op E2 /SC1 ∧ SC2 ) for
Ins(ei ) = (ASi /Ei /SCi )
Ins(op e) = (AS/op E/SC) for Ins(e) = (AS/E/SC)
This means that the action can only be executed if the value of x is 3 in which
case after execution of the atomic action the value of x will be 4.
There is one little refinement that has to be done to the above translation
rules. If the variable v is declared at the global scope, then we cannot use i as
the frame index, because the instance of v does not live in the frame i, but in
the global frame. In this case the we must substitute ∅, the frame index of the
global scope, for the index i in the translation above.
The Procedure Call. The standard form of a procedure call is the synchronous
call. The net given in figure 13 is inserted for each procedure call. The procedure
is called by transition t1 after which the caller waits “in place p1 ” until the
procedure returns, at which point t2 is fired. The pairs < x, i > stored in p2 are
used to secure that the thread i continues after the right procedure return. We
use the same numbering scheme for the parameters as defined for the procedure
call.
An asynchronous procedure call is a call where the caller doesn’t wait for the
callee to return before proceeding. Instead the caller signals explicitly at some
later point that it is ready to accept a return of the procedure. This semantics
can also be implemented by extending the syntax of OB(PN)2 with an accept P
statement. The semantics of this is basically the same, except that the statements
between the call and accept are inserted for p1 between t1 and t2 .
where
R (alt-set1
alt-set2 ) = R (alt-set1 )
R (alt-set2 )
E (alt-set1
alt-set2 ) = E (alt-set1 )
E (alt-set2 )
R (comlst ; repeat) = E (comlst ; exit) = T [[comlst]]
R (comlst ; exit) = E (comlst ; repeat) = Nstop ,
and
6 Conclusions
In the paper we presented OB(PN)2 and its semantics in terms of M-nets. The
semantics is interesting from two points of view:
1. it lays the foundations for the development of automatic verification methods
of concurrent programs written in object-oriented languages, and
2. it can be seen as a set of rules for the translation of object-oriented specifi-
cations written in an object-oriented specification formalism into Petri-nets.
However, the semantics as presented here poses a big challenge for traditional
verification tools. The problem stems from our use of the integers as the set of
frame-indices. As this set is infinite, tools that rely on the existence of a finite
unfolding of the high-level net model (eg. PEP) cannot be used. However in the
case of where it is feasible to restrict the number of concurrently active procedure
instances, it is possible to devise a refinement of the procedure box concept that
reuses frame-indices [10], which will suffice to keep the unfolding finite. On the
other hand a tool that does not necessarily rely on the unfolding (eg. PROD),
but on the symbolic firing rule, may still be able to generate the reachability
graph if for a given initial state the program does not have a non-terminating
recursive call.
Clearly some things remain to be done. First the special data-structures of
B(PN)2 (channels and stacks) should be incorporated in the framework. Secondly
and more importantly inheritance together with a mechanism for dynamic dis-
patch should be introduced. As mentioned in the introduction, a preliminary
proposal for these features exists [16]. A challenge would be to incorporate a re-
turn statement. But this means that we can pass reference not only down the call
hierarchy, but also up, which implies that we would need some form of garbage
collection. On the other hand it might be possible to harness the approach of [10]
for this.
A more intriguing avenue for research is the use of program analysis tech-
niques, as developed for compiler optimization, in the translation to reduce the
model, and in the model-checking phase to guide the model-checker.
274 J. Lilius
References
1. Ken Arnold and James Gosling. The Java Programming Language, Second Edition.
Addison-Wesley, 1998.
2. E. Battiston, A. Chizzoni, and F. De Cindio. Inheritance and concurrency in
CLOWN. In Proc. of the Workshop on Object-Oriented Programming and Models
of Concurrency, 1995.
3. E. Best, R. Devillers, and J. Hall. The box calculus: a new causal algebra with
multi-label communication. In Advances in Petri Nets 1992, volume 609 of Lecture
Notes in Computer Science, pages 21–69. Springer Verlag, Berlin, 1992.
4. E. Best, H. Fleischhack, W. Fraczak, R. P. Hopkins, H. Klaudel, and E. Pelz. A
class of composable high level Petri nets with and application to the semantics
of B(PN)2 . In G. De Michelis and M. Diaz, editors, Application and Theory of
Petri Nets 1995, volume 935 of Lecture Notes in Computer Science, pages 103–
120. Springer Verlag, 1995.
5. E. Best, H.Fleischhack, W.Fraczak, R.P. Hopkins, H. Klaudel, and E. Pelz. An
M-net semantics of B(PN)2 . In Jörg Desel, editor, Proceedings of STRICT’95,
Workshops in Computing, pages 85–100, Berlin, 1995. Springer Verlag.
6. E. Best and R. P. Hopkins. B(PN)2 - a Basic Petri Net Programming Notation.
In A. Bode, M. Reeve, and G. Wolf, editors, Proceedings of PARLE-93, volume
694 of Lecture Notes in Computer Science, pages 379–390, Berlin, 1993. Springer
Verlag.
7. D. Buchs and N. Guelfi. COOPN2: An object oriented specification language for
distributed system development. submitted article.
8. A. Chizzoni. CLOWN: Class orientation with nets. Master’s thesis, Dept. of
Computer Science, Univ. of Milano, 1994.
9. Javier Esparza. Model checking using net unfoldings. In TAPSOFT’93, volume
668 of Lecture Notes in Computer Science, pages 613–628, Berlin, 1993. Springer
Verlag.
10. Hans Fleischhack and Bernd Grahlmann. A Petri net semantics for B(PN)2 with
procedures. In Proceedings of PDSE’97 (Parallel and Distributed Software Engi-
neering), pages 15 – 27. IEEE Computer Society, May 1997.
11. Bernd Grahlmann. An introduction to the principles, the functionality and the
usage of the PEP-system. In Proceedings of PEP: Programming Environment
Based on Petri Nets Workshop, number 14/95 in Hildesheimer Informatik Berichte,
1995.
12. Peter Gr nberg, Mikko Tiusanen, and Kimmo Varpaaniemi. PROD - A Pr/T-
Net reachability analysis tool. Technical Report B11, Digital Systems Laboratory,
Berlin, 1993.
13. K. Jensen and G. Rozenberg, editors. High-Level Petri Nets. Springer Verlag,
Berlin, 1991.
14. Hanna Klaudel and Elisabeth Pelz. Communication as unification in the Petri Box
Calculus. In Proc.of FCT’95, volume 965 of Lecture Notes in Computer Science,
pages 303–312, 1995.
15. Johan Lilius. OB(PN)2 : An Object Based Petri Net Programming Notation. In Luc
Bougé, Pierre Fraigniaud, Anne Mignotte, and Yves Robert, editors, Proceedings of
Euro-Par’96, volume 1123 of Lecture Notes in Computer Science, pages 660–663,
Berlin, 1996. Springer Verlag.
16. Johan Lilius. OOB(PN)2 : An Object-Oriented Petri Net Programming Notation.
In Proceedings of the Second Workshop on Object-Oriented Programming and Mod-
els of Concurrency, 24 June 1996.
OB(PN)2 : An Object Based Petri Net Programming Notation 275
17. Johan Lilius and Elisabeth Pelz. An M-net semantics for B(PN)2 with procedures.
In V. Atalay, U. Halici, K. Inan, N. Yalabik, and A. Yazici, editors, Proceedings
of the Eleventh International Symposium on Computer and Information Sciences,
pages 365–374. Middle East Technical University, 1996.
18. S. Matsuoka, K. Wakita, and A. Yonezawa. Synchronisation constraints with in-
heritance: What is not possible. so what is? Internal report, Tokyo University,
1990.
19. R. N. Taylor. A general purpose algorithm for analyzing concurrent programs.
Communications of the ACM, 26(5):362–376, 1983.
20. Antti Valmari. Stubborn sets for reduced state space generation. In 10th Inter-
national Conference on Application and Theory of Petri Nets, Supplement to the
Proceedings, pages 1–22, 1989. On proceedingsit.
21. Akinori Yonezawa and Mario Tokoro. Object-Oriented Concurrent Programming.
Computer Systems Series. MIT Press, 1987.
On Formalizing UML with High-Level Petri Nets
1 Introduction
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 276–304, 2001.
c Springer-Verlag Berlin Heidelberg 2001
On Formalizing UML with High-Level Petri Nets 277
of failures deeply modify the cost-benefit tradeoff. Attempts to add formal se-
mantics to existing informal notations ([6,32]) barely modify end-user interfaces
and interaction modalities, thus overcoming one of the major obstacle for break-
ing into much larger industrial sectors. The most popular approaches consist in
defining translation algorithms that provide given specification notations with
fixed semantics. By applying these algorithms users define a formal model that
is equivalent to the original informal specification. Unfortunately, the results are
particular formalizations of some notations, which, even if well suited for some
application domains, cannot easily be generalized.
Recently, we investigated a new rule-based approach that allows users to
associate different semantics with the same notation. Such an approach, called
CR approach ([3], Customization Rules Approach), allows users to fit their in-
terpretations of an informal notation by defining particular set of rules. Users
do not only ascribe their semantics to the notation they are familiar with, but
they can exploit all the benefits of a formal engine (simulation, analysis) without
even knowing that it exists. This approach has been successfully validated by
ascribing formal semantics to several data flow-based notations, such as different
dialects of structured analysis ([2]) and to new special-purpose notations ([4,23]).
Object-oriented notations impose further requirements to the CR approach.
Specific features such as inheritance, polymorphism, multiple overlapping views
of the same features, and the emphasis on non-strictly operational aspects present
new challenges. The goal of this paper is to demonstrate the suitability of the
CR approach for the definition of the dynamic semantics of UML. The paper
does not present the set of rules that formally define UML. It illustrates rather
intuitively the automatic mapping of UML to high-level Petri nets through the
hurried philosophers problem. The paper also indicates how we can prove im-
portant properties of the problem by analyzing the high-level Petri net derived
from the UML specification.
This paper is organized as follows. Section 2 briefly sketches the CR approach.
Section 3 discusses a possible use of the CR approach for formalizing UML.
Section 4 shows the applicability of the approach to the hurried philosophers
problems. Finally, Section 5 concludes by indicating the ongoing work.
2 CR Approach
This section describes a flexible framework for defining the syntax of graphical
notations, for expressing their operational semantics through a mapping onto an
operational formal model, and for presenting the results of dynamic analysis of
the formal model in terms of the graphical notation.
A notation is defined by means of three sets of rules, that specify the abstract
syntax, the semantics, and the visualization of dynamic analysis results, respec-
tively. Abstract syntax rules define the elements of the graphical notation and
their connectivity. Semantic rules define the dynamic behavior of the notation
as a transformation in a formal operational model. Visualization rules describe
the presentation of the results of dynamic analysis on the formal model in terms
278 L. Baresi and M. Pezzè
of the chosen graphical notation. Concrete syntax – not considered here – can
easily be inherited from existing CASE technology.
Figure 1 illustrates the approach. The general framework comprises a graph-
ical (specification) notation and a formal model. Application specialists define
their models by using the graphical notation, for example UML. User models
are scanned to automatically build the formal representation that corresponds
to the graphical specification. The corresponding formal model gives semantics
to user models and provides dynamic analysis capabilities. Semantic properties
of the graphical specification can be checked on the formal model. Visualization
rules translate the analysis results in terms of the graphical notation. In this way,
domain experts exploit the benefits of formality without having to care about
it. They can execute and analyze their models without being proficient in the
formal model.
Visualization Rules
ments on which the rule applies; the bottom right part indicates the elements
introduced by the application of the rule; the top (embedding) indicates how the
new elements have to be connected to the graph. Graph grammar nodes corre-
spond to syntax elements of the specified notation, that is, either nodes or arcs.
For example, in the bottom right part of Figure 2(a) nodes 1 and 2 represent
nodes of type object, while node 3 represents an arc of type method invocation.
Graph grammar arcs indicate relations between the elements of the notation.
For example, the graph grammar arcs from node 1 to node 3 and from node 3
to node 2 represent relations connect between the nodes. Arcs belonging to the
bottom left part of a rule define the connections (relations) that must exist -
among selected nodes - to apply the rule. Arcs in the bottom right part of a rule
define the relations established by applying the rules. Arcs crossing the border
between the bottom left and top parts of a rule select the nodes in the existing
graph to which the newly created nodes (bottom right part) will be connected.
Arcs crossing the border between the top and the bottom right parts of a rule
set the connections between the added subgraph and the nodes identified so far.
10
P V
1 2
O O
1 1
3
P V
m P V 5 6
3 4
O O
2 2
1 and 2 of type O, in the bottom left part of the rule) and results in adding an
arc of type method invocation between them (node 3 of type m in the bottom
right part). The same numbers associated with the nodes in the bottom left and
bottom right parts indicate that the two objects are kept in the graph together
with their connections. The semantic rule (2(b)) applies to the two pairs of nodes
of type parameter and value that correspond to the two objects selected by the
abstract syntax rule (pairs 1, 2 and 3, 4, of nodes of type P and V ). The
four places are “fused” into two new places of type P and V , that represent the
actual invocation of the method. The “fusion” is modeled by removing the four
places and introducing two new ones. The connections with the embedding force
the new P node to be connected to the same arcs to which the two old P nodes
were formerly connected, and similarly for the new V node. Figure 3 shows a
sample application of the rule of Figure 2.
m2 m2
O1 O1
O2 O2
m3
O3 O3
m1 m1
P P
O1net m1 O2net O1net m1 O2net
V V
P V P V P V P V
m3o m2 m3 m2
V
m3i O3net O3net
P
the name of node 3 is supplied by users and its type is method invocation. In the
SGG production of Figure 2(b) the type of the new places 5 and 6 is equal to
the type of the removed places 1 and 2, respectively.
Visualization rules translate states and events of the semantic model in
proper representations of the graphical elements. A textual grammar describes
the mapping by referring to the types of the objects introduced by syntax and
semantic rules. Figure 4 shows the visualization rule that maps the firing of a
transition tId of type stateTransition to a set of (abstract) visualization events
on UML elements. Readers not familiar with C-like syntax can simply skim
through Figure 4: The rule, triggered by the firing of a transition tId of type
stateTransition, selects:
– All places of type P (parameter) in the preset of tId and associates them with
the readParameters visualization event to visualize all the actual parameters
of the invoked method.
– All places of type S (state) in the preset of tId and associates them with
the leaveState visualization event to visualize the current state of the finite
state machine and the fact that it is about to change.
– All places of type V (value) in the postset of tId and associates them with the
writeValues visualization event to visualize all values produced by executing
the method.
– All places of type S (state) in the postset of tId and associates them with
the enterState visualization event to visualize the new current state of the
finite state machine.
– mark UML elements corresponding to places of type P in the preset of tId with –
visualization event readParameters (the event uses the values associated with – such
elements)
– mark UML elements corresponding to places of type S in the preset of tId with – vi-
sualization event leaveState (the event causes the system to leave the state – represented
with such elements)
– mark UML elements corresponding to places of type V in the postset of tId with
– visualization event writeValues (the event defines the values associated with – such
elements)
– mark UML elements corresponding to places of type S in the postset of tId with –
visualization event enterState (the event causes the system to enter the state – repre-
sented with such elements)
3 Formalizing UML
Formalizing UML with the CR approach presents new challenges and problems.
Object-oriented features like inheritance, polymorphism, multiple overlapping
views, and emphasis on non-strictly operational aspects must carefully be stud-
ied. Possible incompletenesses and inconsistencies of UML specifications – due
to the possibility of defining different views of the model – complicate the task of
defining formal dynamic semantics. In UML, several non-homogeneous views can
capture different details of the same components and often overlap. For example,
Class Diagrams can describe only a subset of the classes defining the applica-
tion; Interaction Diagrams provide a snapshot of a group of objects cooperating
to achieve a common goal. Formalization must be able to capture different de-
tails from different sources, integrate them, and – if possible – identify and solve
inconsistencies.
This paper illustrates a possible use of the CR approach to ascribe seman-
tics to consistent UML specifications by means of high-level Petri nets ([14])1 .
We do not present all the details of the customization rules (graph-grammar
productions) that define the abstract syntax and the semantics of UML, but we
illustrate the semantic aspects by describing the underlying high-level Petri nets.
Due to space consideration, we show only a sample of the details (predicates and
actions) associated with the high-level Petri nets in the Appendix.
3.1 UML
This section briefly introduces UML. Readers proficient in the notation can
either skip or skim the section. An UML specification ([11]) comprises 7 kinds
of diagrams:
Use-Case Diagrams describe user scenarios. They define the possible interac-
tions between the system under development and the external actors.
Class Diagrams define the classes and/or packages (groups of classes) that
compose the system and the relations among them:
– associations (undirected arcs) represent conceptual relationships between
classes. The relationships can be clarified by defining the roles played by
each class in the relationship.
– aggregations (arcs with a white diamond head) represent part-of rela-
tionships. Objects of the class at the diamond head “contain” (references
to) objects of the class at the tail. Compositions (arcs with a black di-
amond head) are heavier aggregation relations. Composition restricts
aggregation by either requiring an object to be part of one other object
only, or by binding the life of the “contained” object to the life of the
“container” object.
– generalizations (arcs with a white arrow head) represent inheritance
relationships.
1
An introduction to high-level Petri net is presented in the Appendix.
284 L. Baresi and M. Pezzè
Figure 7 shows the class diagram for the case study. The diagram shows
associations, generalizations and aggregations.
Interaction Diagrams give snapshots of the interactions among objects. They
describe how groups of objects cooperate in some behavior. In UML, there
are two kinds of Interaction Diagrams:
Collaboration Diagrams: Objects are shown as icons, while messages
(method invocations) are represented with arrows. The sequence among
messages is indicated by numbering the messages. A sample collabora-
tion diagram is shown in Figure 14.
Sequence Diagrams: Objects are shown as boxes at the top of vertical
dashed lines and messages are drawn with (horizontal) arrows between
the dashed lines (objects). Messages are ordered from top to bottom.
State Diagrams describe the dynamics of each class as a Statechart [15].
Events and actions correspond to invocation of services (methods, from
an implementation-oriented perspective) that are exchanged among objects
(i.e., the arcs among entities in the Interaction Diagrams). Messages ex-
changed among objects are treated according to the defined communication
type: simple, synchronous, balking, timeout, and asynchronous. Sample state
diagrams can be found in Figures 8, 9, 10, and 11.
Activity Diagrams combine SDL [29] and Petri net features to provide a
means for specifying the behavior of tasks that present internal parallelism.
Package Diagrams describe the partitioning of the system into modules (UML
packages).
Deployment Diagrams describe how packages and objects are allocated on
processors (or on more general hardware components).
Class Diagrams. Class Diagrams indicate the classes that compose the sys-
tem, the (static) relations among them (associations, aggregations, and general-
izations), and the external interfaces of the classes, that is, the services provided
by the classes. From the semantic viewpoint, classes identify the subnets that
will define the whole model and the services provided by the classes. Services
are represented with pairs of high-level Petri net places, which indicate service
requests and returned values. The type of the first place models the types of the
formal parameters associated with the service invocation; the type of the receiv-
ing place models the types of returned values. Figure 5 presents an example: the
high-level Petri net of class Fork, which is discussed in detail in Section 4.
On Formalizing UML with High-Level Petri Nets 285
Fork
id Add Released
void add()
void remove()
boolean get() Release Fork Get
void release()
boolean required()
boolean released() Required Remove
State Diagrams. The behavior of each class is described with a State Diagram,
that is, a Statechart [15]. State Diagrams, modeling different classes, interact
through exchanging invocations of services (messages). States are annotated with
the identifier of the state and the action performed in the state. Transitions
are annotated with labels that indicate the event that trigger the transition
(above the line) and the actions produced by the triggered transition (below the
line). An empty event indicates that the transition can fire spontaneously, while
an empty action indicates that the transition produces no action. States are
modeled with high-level Petri net places, and transitions with high-level Petri
net transitions. Service invocations are modeled by connecting high-level Petri
net transitions to the places modeling the service in the class’s interface. Figure 6
illustrates the different translation schemas, corresponding to different kind of
interactions. Examples of translations of State Diagrams are given in the case
study in Section 4.
State
State
Event
Event
Action
State
State
State
State
Invocation
Action Answer InternalState
State
State
State
State
Invocation
Invocation Invocation Answer InternalState
InternalState
Answer Answer
Invocation
Answer InternalState
State
State
4 Hurried Philosophers
The Class Diagram of Figure 7 describes the main components of the hur-
ried philosophers model and their relations. Class Philosopher describes the
common features of all philosophers. They require interactions with forks and
their neighbors to be able to eat. Class ArrivingPhilosopher inherits from
InvitingPhilosopher, that inherits from Philosopher. Class InvitingPhilo-
sopher adds service introduceNewPhil to introduce a philosopher and service
removePhil to remove a philosopher; class ArrivingPhilosopher adds services
for joining and leaving the table. Class Butler prevents deadlocks by restricting
the number of philosophers that can concurrently compete for forks; it enforces
fairness by granting authorizations to enter the forks competition. Philosophers
ask the Butler before starting competing for forks. Class Dispatcher dispatches
plates and forks to invited philosophers, and collects plates and forks from leav-
ing philosophers. Since plates and forks are handled similarly, we explicitly model
forks only. Class Dispatcher uses class Fork to add new forks.
Dispatcher
Fork forks
id
fId provide()
void add() void collect(fId)
void remove()
boolean get()
void release() InvitingPhilosopher
boolean required()
boolean released() Philosopher void introduceNewPhil()
id void removePhil()
leftFork
rightFork
Butler
state
boolean askButler(pId)
pId addGuest() ArrivingPhilosopher
void delGuest(pId)
void notifyButler(pId) void leaveTable(pId)
void reset() void new(pId, fId)
soon as the fork is released (event return(true)), he acquires the fork (action
leftFork.get()) and moves to state HLF. Notice that the request for service
leftFork.get() from state Hungry to state AFLF could result in either a positive
or negative answer. The obtained response is the event that determines the next
step in the behavior of the philosopher. On the contrary, the invocation of the
same service (leftFork.get()) from state ANLF to HLF can result only in a
positive answer since the requested fork is in state Available (Figure 9). In fact,
the request for leftFork.get() is modeled with a synchronous invocation (see
Figure 14) and the fork answers only when it is actually available. Once acquired
the left fork, the philosopher checks whether the fork has been required by his
left neighbor (action leftFork.required()) and moves to state QLF (Querying
Left Fork). If there is a pending request, the philosopher releases the fork and
moves back to state Thinking. Otherwise he tries to acquire the right fork with
a process analogous to the one followed to get the left fork, and moves to state
Eating. When he finishes eating, after a given delay, he releases the forks and
goes back to state Thinking.
An InvitingPhilosopher can introduce a new philosopher upon finishing
eating and before releasing the forks (event introduceNewPhil()). The receipt
of this event causes the philosopher to move to state WFD (Waiting For Dis-
patcher)). In this case, he interacts with the Dispatcher, that provides a new
identifier for the fork to be put between the inviting and the arriving philoso-
phers, if any is still available. An InvitingPhilosopher can also remove a
On Formalizing UML with High-Level Petri Nets 289
new(pId, fId)
addGuest(this)
Thinking
askButler(this)
Hungry
return(true) return(ACK)
leftFork.release() leftFork.get()
return(false)
leftFork.released() AFLF
delay()
leftFork.release()
rightFork.release()
ANFLF return(true)
return(fId)
new(this, fId)
HLF leftFork.release()
rightFork.release()
return(true)
leftFork.get()
return(NULL)
leftFork.release()
rightFork.release() leftFork.required()
QLF
removePhil()
leftFork.release() return(false)
rightFork.release()
leaveTable(this) rightFork.get()
return(false)
AFRF
rightFork.released()
ANFRF return(true)
return(true)
Eating
rightFork.get()
leaveTable(pId) introduceNewPhil()
leftFork.release() provide()
collect(rightFork)
delGuest(this)
WFD
Fork. Figure 9 shows the State Diagram of class Fork. Forks can be in either
state Available, or state Used, or state Required. A new fork is added (cre-
ated) on demand by the Dispatcher, that provides the identifier of the new
fork. A first get() returns true to confirm the acquisition and it moves the
fork to state Used. A second get(), not interleaved with a release(), returns
false to notify the current unavailability of the fork and moves the fork to
state Required. A release() in either state Used or state Required moves
back to state Available. A required returns the current status of the fork.
A released() can be served only in state Available. In this way, we define a
synchronous communication with the asking object (philosopher), further illus-
trated by the Collaboration Diagram of Figure 14. Forks are removed (destroyed)
by the Dispatcher on demand.
add(fId)
return(fId)
Available
released()
return(true)
get
release()
return(NULL)
release() get()
return(NULL) return(true)
get()
Used Required required()
required() return(false)
return(false) return(true)
remove()
return(NULL)
2Fork
collect(fId) provide()
remove() add(fId)
1Fork
collect(fId) provide()
remove() add(fId)
Empty provide()
return(NULL)
Butler. The State Diagram of class Butler is presented in Figure 11. The
Butler keeps track of the identity of all the philosophers seated around the
table. Events addGuest() and delGuest(pId) are used to keep the list of “ac-
tive” philosopher up-to-date. Philosophers query the Butler by means of ser-
vice askButler(). This event generates no action directly, but when predicate
readyToEat evaluates to true, the Butler lets the Philosopher start eating.
To ensure fairness, this version of the Butler adopts a very simple policy:
each Philosopher can eat once, then he has to wait for the other philosophers
to eat. Thus predicate readyToEat is satisfied if the philosopher has not al-
ready eaten. When a philosopher finishes eating, he notifies the Butler (event
notifyButler()). When all the philosophers around the table have eaten once
(event readyToReset), the Butler resets (action reset()) his state, and all the
philosophers can start eating again. Other policies can be implemented without
impacting on the approach described in the paper.
addGuest()
return(pId)
Buttler
delGuest(pId) notifyButler() readyToReset
return(NULL) return(NULL) reset()
askButler(pId)
if (readyToEat) return(true)
External interfaces are derived from the Class Diagram of Figure 7 – together
with State Diagrams – and are modeled with pairs of Petri net places. Each pair
represents either an offered or a required service (method) and the corresponding
answer. In Figures 12, and 13, interfaces are highlighted with rounded squares.
States and transitions of the State Diagrams of Figures 9 and 10 are modeled
with Petri net places and transitions, respectively. Each state is modeled with
a Petri net place and each transition is modeled with a Petri net transition (see
Section 3.1) connected to the places that represent the input and output states
and to the places corresponding to the methods triggering the transition. For ex-
ample, transition get from state Available to state Used of the State Diagram
of Figure 9 is modeled with the Petri net transition getT1 from place Available
to place Used of the Petri net of Figure 12. Since the transition of the State Di-
agram is labeled with event get() and action return(true), the corresponding
Petri net transition “reads” from the P place of method get(), that represents
the service invocation, and “writes” true in the V place of method get(), that
represents the answer provided by the service.
New objects are instantiated by adding tokens, as done by the subnet corre-
sponding to methods add of class Fork and method new of class ArrivingPhi-
losopher. Newly created tokens contain the identity of the newly created ob-
jects and the class the created object belongs to. The inheritance of properties
is governed by the predicates of high-level Petri net transitions. Such predi-
cates forbid tokens corresponding to objects of a superclass to enable transitions
modeling services provided by a subclass. In the hurried philosophers problem,
classes Philosopher, InvitingPhilosopher and ArrivingPhilosopher share
the same subnet, as shown in Figure 15. However, tokens modeling Inviting-
Philosophers are prevented to enable transitions that model methods of class
ArrivingPhilosopher, for example, method leaveTable. The predicates of the
On Formalizing UML with High-Level Petri Nets 293
Add P P Released
addT releasedT
V V
Available
Release P releaseT1
P Get
getT1
V V
releaseT2
Used
Required P P Remove
removeT
requiredT1
V V
getT2
Required
requiredT2
2Fork
Collect Provide
V P
removeT2 provideT1
P V
collectT2 addT1
1Fork
provideT2
removeT1
Remove Add
P V
addT2
collectT1
V P
Empty
1: askButler(P) B : Butler
ACK
P : Philosopher
2: get()
false
3: released()
true
The result of merging the interface places of all the services used in all the
Collaboration Diagrams of the example are shown in Figure 15. The figure il-
lustrates the high-level Petri net produced by applying the customization rules,
that formalize UML, to the specification of the hurried philosophers problem
described in this paper. In Figure 15, subnets corresponding to the different
classes are highlighted with boxes; only interface places lie on two boxes that
correspond to the joined subnets. The Petri net is reported here to illustrate the
semantics, but it is not shown to domain experts, who analyze the Petri net by
interacting with the UML model as illustrated in the next section.
– Define the properties on the Petri net that are equivalent to the properties
of the UML specification that users would like to analyze.
– Analyze the Petri net with respect to the properties identified so far.
– Translate the analysis results on the Petri net in terms of UML.
DISPATCHER
BUTLER
FORK
ttttt
T
PHILOSOPHER
Fig. 15. The semantic high-level Petri net for the hurried philosophers problem pro-
duced with the CR approach illustrated in this paper.
On Formalizing UML with High-Level Petri Nets 297
predicates, net execution, and reachability analysis and model checking. Checks
on the structure of the net or on the syntax of the predicates can straightfor-
wardly be automated by means of widely available technology, for example, [8,1].
Execution of high-level Petri nets is currently provided by most CASE tools for
high-level Petri nets [8,26]. Reachability analysis and model checking can be per-
formed in many different ways. The reachability graph of the Place/Transition
net obtained by ignoring the predicates and actions of the high-level net can be
built fairly efficiently by using well-known algorithms. Model checking techniques
can be used to prove properties on the reachability graph. Since the reachability
graph of the Place/Transition net is only an approximation of the reachability
set of the high-level net, only few properties can be proven in this way. Complex
properties may require the construction of the reachability graph for the high-
level net, such as the occurrence graph illustrated in [17]2 . We studied many
of the properties discussed in this section by using execution and reachability
analysis capabilities provided by Cabernet [26].
Mutual exclusion of the states of forks. Mutual exclusion of the states of Forks
can be formulated by requiring each object of class Fork to be in one state of a
2
Occurrence graphs have been originally defined for Coloured Petri nets, that have
been shown equivalent to other classes of high-level nets [21].
298 L. Baresi and M. Pezzè
given set, or, similarly, we can require each token of type Fork to be in one Petri
net place of a given set. This can easily be checked statically on either the UML
specification or on the corresponding high-level Petri net. The validity of such a
property is a consequence of the operational style of both Statecharts, used to
model the internals of UML classes, and Petri nets.
Bounds on the states of the system. Bounds on the system states can be ex-
pressed by formulating properties on the states of UML objects (classes). Such
properties can be mapped to properties on the markings of the places of the type
corresponding to the bounded classes. They can be tested with execution and
proven with reachability analysis. For example, asking at least two philosophers
to be at the table, that is, asking at least two Philosopher object to be in one
of the states characterizing class Philosopher, can be formulated by requiring
at least two tokens of type Philosopher to belong to each reachable marking.
Bounds on the behavior of the system. Bounds on the behavior of the system
can be expressed by stating properties on the sequences of UML events, that
is, firing sequences of the corresponding Petri net transitions. Such properties
can be tested by executing the net and can be proven on the occurrence graph.
The reachability graph of the corresponding Place/Transition net can help in
identifying possible wrong sequences, whose feasibility can be checked by exe-
cuting the high-level Petri net. For example, the property that each philosopher
must eat at least once before leaving the table can be formulated by asking that,
between the invocation of methods addGuest and leaveTable, the philosopher
must be in state Eating. Similarly, place Eating must be marked between the
firing of transitions addGuest and leaveTable.
5 Conclusions
References
active philosophers (field active == true) ate after the last reset (field hungry
= false) and all non-active philosopher (field active == false) are hungry
(field hungry = true, the default value for non-active philosophers). The firing
of transition reset sets all philosophers to hungry, as stated by the associated
action.
eating
leaveTableP 0 1 2 3
delGuestP active
LeaveTable hungry
leaving DelGuest
butler Reset
TableLeft
delGuestV
true
false
leaveTableV
Classes
class philosopher { class philPhil {
string type; philosopher state;
integer id; philosopher param;
integer leftFork; };
integer rightFork;
}; class butlerState {
philInfo st[3];
class philInfo { }
boolean active;
boolean hungry; class philId {
}; integer id;
};
Places
philosopher leaveTableP, eating;
philId delGuestP, delGuestV, leaveTableV;
butlerState butler;
philPhil leaving;
Transitions
DelGuest
predicate
butler.st[delGuestP.id].active == true
On Formalizing UML with High-Level Petri Nets 303
action
delGuestV = delGuestP;
butler.st[delGuestP.id].active = false;
butler.st[delGuestP.id].hungry = true;
LeaveTable
predicate
(eating.rightFork == leaveTableP.leftFork) &&
(eating.type == ‘‘arrivingPhilosopher")
action
delGuestP.id = eating.id;
leaving.state = eating;
leaving.param = leaveTableP;
Reset
predicate
(butler.st[0].active == !(butler.st[0].hungry)) &&
(butler.st[1].active == !(butler.st[1].hungry)) &&
(butler.st[2].active == !(butler.st[2].hungry)) &&
(butler.st[3].active == !(butler.st[3].hungry))
action
butler.st[0].hungry = true;
butler.st[1].hungry = true;
butler.st[2].hungry = true;
butler.st[3].hungry = true;
TableLeft
predicate
leaving.state.id == delGuestV.id
action
leaveTableV = leaving.state.id;
Abstract. This paper contains a solution to the case study proposed for the 2nd
edition of the OO-MC workshop. In this paper, we merely recall the main
features of the Cooperative Objects formalism, which is an object-oriented
language, based on high-level Petri nets. We then include a Cooperative Object
model describing the groupware editing tool described in the case study.
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 305–318, 2001.
ã Springer-Verlag Berlin Heidelberg 2001
306 R. Bastide and P. Palanque
called PetShop [6], which is designed to comply with CORBA [10], the Object
Management Group’s standard for distributed object systems. The interface offered by
object classes is thus described in terms of the OMG’s Interface Definition Language
(IDL), and the details of the integration of CORBA IDL with the high-level Petri nets
dialect used by CO is described in [5].
The integration of Cooperative Objects with a language such as Java is performed
in the following way: ObCS are described by High-Level Petri nets, and the tokens
that constitute the marking of the net can hold information, instead of being
dimensionless entities like in conventional nets. In the PetShop tool (which is written
in Java), the value of a token is a n-tuple of typed values, those values representing
either:
• Any Java type (native type, or polymorphic class instance);
• A reference to another CO in the system.
Transitions in the net contain a precondition part and an action part, which are able
to manipulate the tokens involved in the firing according to their type. Two quite
different kinds of actions may be represented:
• A block of Java code, which is executed sequentially and in mutual exclusion with
other transitions in the ObCS. This code can make use of Java objects involved in
the firing, call their methods, dynamically create new Java objects, etc. This allows
for an easy integration of CO with existing class libraries, and insures that COs are
interoperable with more conventional approaches. For example we describe in [4]
how to integrate CO within a User Interface Management System (UIMS).
• An invocation of another CO, i.e. the call of a method it offers; This call is
executed in a concurrent and non-blocking way. The classical invocation strategies
described in [8] are available (synchronous rendezvous, asynchronous message
sending, time-out rendezvous), and each of these strategies is formally defined in
terms of HLPN. The fact that both the inner behavior of objects and their
communication primitives are modeled by HLPN allows providing a formal model
of a system of communicating CO in terms of HLPN only.
The interface of a CO class is given in CORBA IDL, and the behavior of the instances
is given by a HLPN. This behavior is related to the interface definition in the
following way:
• For each service given in the interface, the ObCS net contains one Service Input
Port (SIP) and one Service Output Port (SOP) that are special purpose places. The
service input port is meant to receive the service invocations and their input
parameters, while the service output port is the channel through which the service
results will be provided by the object. A service input port can only have output
arcs in the ObCS, and conversely a service output port can only have incoming
arcs.
Modeling a Groupware Editing Tool with Cooperative Objects 307
class aServer
specifies Example { // (excerpt)
ObCS
aService
Input Port
P1
<p>
aService
aService
Accept Transition <p>
End_aService
<r>
P3
aService
Output Port
}
The interface and ObCS together fully define the behavior of instances: A service
request will begin executing when one of its associated accept transitions is enabled
by the current marking of the ObCS. Conversely, the execution of a service is modeled
by the occurrence of the associated macro-transitions, which states the side effect of
the service execution on the object.
The net dialect used to describe the ObCS uses timing on the transition’s input arcs.
An arc may feature an enabling time interval, which states the moments when a given
token is available for the transition’s firing. The origin for this time interval is the time
when the token has initially entered the place.
Such a construct makes it easy to model „watchdogs“, or time guarded actions that
are frequent in distributed systems. Fig. 3 illustrates such a construct: Transition T1
represents the normal processing to be applied to tokens that enter place Waiting.
However, if such a processing does not occur before a given amount of time (Delay)
has elapsed, A default action, modeled by transition T2, will be triggered.
Waiting
T2 T1
Normal
Alarm
termination
The ObCS are meant to describe the „server“ behavior of objects (i.e. what their
synchronization constraints are) but also their „client“ behavior (i.e. how they request
services from other Cooperative Objects in the system).
The communication between Cooperative Objects is syntactically expressed using
the conventional dot notation, by actions in the ObCS transitions.
Modeling a Groupware Editing Tool with Cooperative Objects 309
Such as service invocation is illustrated in Fig. 4: The class described here acts as a
client of the aServer class described in Fig. 2. The ObCS descriptions includes the
definition of the places type: for example, place PB is defined to hold references to
instances of the aServer class, while the tokens contained in place PC will be 3-tuples
holding an integer, a reference to an instance of aServer and a string.
PA PB
<p> <s>
r = s.aService ( p );
<p,s, r>
PC
}
The variables on the arcs act as formal variables for the transition. The action of the
transition is to call the service aService on the object bound to variable s, providing as
a parameter the integer bound to variable p. A transition whose action is the
invocation of another Cooperative Object is called an invocation transition. The
default semantics for such a call is the synchronous rendezvous, whose operational
semantics is described in Fig. 5.
The semantics of the synchronous rendezvous is given within the framework of
high-level Petri nets, by enhancing the ObCS nets of both the client and the server of
the rendezvous. Although the designer of the net only sees the ObCS descriptions as
given in Fig. 2 and Fig. 4, the nets, before being actually executed in the running
system, are expanded in the following way:
Client-side semantics
The following transformations have to be applied to each invocation transition:
• The invocation transition is considered as a macro-transition extending from the
request transition to the complete transition. The request transition constructs a
parameter token, including the original parameters of the service, the identity of
the caller (variable this) and a globally unique call-identifier. This token is
deposited in the Invocation Parameter port.
310 R. Bastide and P. Palanque
• A waiting place is introduced between the request transition and the complete
transition. The presence of a token in this place indicates that a call is in progress.
• The results from the service call will be return to the client in its Invocation Return
Port. The arrival of a return token will enable the complete transition, and
terminate the service call on the client’s side. It is important to note that the
variable id is present on both input arcs of the complete transition: the transition is
only enabled if a substitution is possible between the token values held in the
Waiting and Return Port places, meaning that the same id is found in both tokens.
This construct is necessary to allow a client to issue concurrently several
invocations, and to enable the client to match the results it receives with the
parameters it has initially provided.
PA PB Request
Transition
<p> <s>
<p, s, id>
aService
Invocation
Parameter port <p, c, id>
Waiting Expanded aService
Invocation Transition Subnet
<r, c, id>
Invocation
<p,s, id> Return port
End_aService
Server-side semantics
On the server’s side, the structure of the net is not altered, but only the definition of
the places’ type and the inscriptions on the arcs. The only requirement for the server is
to keep both the client’s identity and the call-id within the service subnet, so that the
results of the service can be properly routed back to the caller. The synchronous
rendezvous is thus implemented as two unidirectional asynchronous message sending.
Only one primitive is required, and supposed to be provided by the implementation
environment: the ability to deposit a structured token in a place of a remote
Cooperative Object. This primitive is used to transport both the parameters and the
results of an invocation. In the current implementation, this primitive is provided by a
Modeling a Groupware Editing Tool with Cooperative Objects 311
CORBA compliant system, which takes care of the marshaling and unmarshaling of
call arguments, and of the routing of tokens. However, other implementations could be
easily substituted, such as Java RMI (Remote Method Invocation) or lower level
solutions based on sockets.
Other invocation strategies can be described in the same way: The time-out
rendezvous allows the client to specify the amount of time it accepts to wait for the
result of the call, and to take a corrective action if the result is not provided within this
delay.
The syntax of the time-out rendezvous and the associated semantics are described
in Fig. 6: the semantics of the inhibitor arc adjacent to transition discard must be
noted: the transition is enabled only if no substitution can be made on the variable id,
i.e. if the token holding the call-id has already left the Waiting place.
PA PB
<p> <s>
<p, this, id>
<p, s, id>
r = s.aService ( p ); Delay Operational semantics
TIMEOUT ELSE (client side)
Waiting <p,s, id> Discard
<p,s> <p,s, r>
Alarm PC
Sometimes, the client may chose to simply ignore the possible results of a service,
and to simply proceed as soon as the invocation has been issued, without any
acknowledgment. This strategy is called asynchronous invocation, and its syntax and
operational semantics are illustrated in Fig. 7.
It must be noted that whatever invocation strategy is chosen only impacts on the
structure of the client’s ObCS: the structure of the server’s ObCS is not modified, and
any service can thus be called with any invocation strategy.
312 R. Bastide and P. Palanque
PA PB PA PB
PC
PC
Invocation
Parameter port
We will now present how the Cooperative Objects formalism can be applied to model
the case study proposed as an exercise for the second edition of the OO-MC
workshop, held in Osaka during ATPN'96.
We present only a simplified solution to the initial requirements: the various styles
of ownership have not been retained, but we show how this could be modeled if
desired. Our solution focuses instead on the communication between the various users
of the system and on the resource-locking protocol that allows to consistently edit and
update the shared shapes.
Dispatcher
DispatchClient 0..*
Add (c : DispatchClient)
Refresh (o : DispatchObject, a : DispatchAction) Remove (c : DispatchClient)
Dispatch (o : DispatchObject, a : DispatchAction)
DispatchObject 1
Grab () : boolean
Release ()
GraphicEditor
2.2 Multicasting
The distributed and cooperative nature of the case study requires special
communication primitives between the software components. For example, each time
a user adds or updates a graphic shape, this action must be forwarded to the other
users. Likewise, each time a new user joins the editing session, he must be made
known to all the others.
This kind of "one to many" communication is often known as multicasting: the
same message is dispatched to a number of potential recipients, which will deal with it
in their own specialized way. The Cooperative Object formalism does not include a
special modeling construct to represent such communication. The formalism is strictly
based on the client-server approach, where a client must know a reference to the
server before calling a method, and where methods calls and answers are strictly one
to one.
To emulate multicasting in the formalism, we define an interface called Dispatcher,
and formally define its behavior through a CO class called Dispatch_spec. The
purpose of this class is to maintain a list of potential clients, and to allow forwarding a
same message to all the clients known by the dispatcher. The Cooperative Objects
class for the dispatcher is given in Fig. 9.
Basically, when a Dispatcher object receives an invocation for its Dispatch method,
it calls the method Refresh for each of the clients it holds, forwarding them an objet o,
and an action a to execute on that object. The methods Add and Remove are meant to
manage the list of clients.
The correct use of the Dispatcher class implies the use of polymorphic objects:
Any objet that is to be called by the Dispatcher class must be an instance of a class
that implements the DispatchClient interface (which features a Refresh method). This
will be the case, for example, of the GraphicEditor class. Likewise, the objects to be
dispatched must implement the DispatchObject interface, as this will be the case for
the Shape class.
314 R. Bastide and P. Palanque
interface Dispatcher {
void Add(in DispatchClient);
// Add a client to the list of dispatch clients
void Remove(in DispatchClient);
// Remove a previously added client
void Dispatch(in DispatchObject o, in DispatchAction a);
// Dispatch the object o to all known clients,
// to execute action a
}
class Dispatch_spec specifies Dispatch {
ObCS
// Definition of the places' type
Clients: <DispatchClient>
// The Clients place holds the list of clients
StillDispatching: <DispatchObject, DispatchAction>
AlreadyDispatched: <DispatchClient>
<c>
Add
<c>
<c>
<o,a>
<c>
Still
Dispatching <o,a>
<c>
c.Refresh(o,a)
<o,a>
<o,a> <c>
Dispatch
Already
<c> Reset clients
Dispatched
The behavior of the Dispatch_spec class can also be reused in other contexts:
instead of holding a list of clients and dispatching an object to each of them, the same
structure could be used to hold a list of shapes, and dispatch each of the shapes to one
client. This would be useful, for example, when a new user joins the group to let him
know of the current set of edited shapes.
The GraphicEditor class models the behavior of the editing tool. Each user of the
cooperative application will have a personal instance of GraphicEditor. The aim of
Modeling a Groupware Editing Tool with Cooperative Objects 315
this class is to allow users to create and manipulate shapes, while making sure that
their actions are conform to the cooperation protocol defined in the requirements for
the case study.
Several of the service input ports (for the services CreateShape, DeleteShape,
Select and Unselect) have a special „button-like“ representation: this is to distinguish
those services as being User Services, i.e. services that are not meant to be triggered
by other Cooperative Objects but directly by the user of the system, through some
user-interface mechanism. The Select service, for example, could be triggered by
clicking with the mouse on the on-screen representation of the shape. The
implementation of that kind of user-services has been discussed in [3].
The GraphicEditor class, as shown above, deviates in some ways from the initial
requirements, and makes some other requirements more precise, as shown in Fig. 10.
For example, at any moment an instance of the editor may own several shapes
(their references are stored in the OwnedShape place). After an editor creates a shape,
it initially owns it. Only owned shapes can be deleted. A free shape can become
owned by selecting it, and conversely an owned shape becomes free by unselecting it.
From the initial requirements, we have not retained the various styles of ownership,
but they could be included by adding other services with the same pattern as Select /
Unselect. For simplicity, we have not modeled the updating of the shapes by the
editor: this could be easily done by adding one or more updating services, with the
same activation precondition as the DeleteShape service.
The GraphicShape class essentially acts as a monitor, allowing to reliably lock and
unlock a shape before deleting (or otherwise updating) it. The ObCS of the
GraphicShape class is illustrated in Fig. 11 The shape is also responsible for
forwarding the actions triggered on it to all the other editors, so that they are informed
of the changing of the shape’s status. To this end, the shape uses an instance of the
Dispatcher class described above.
Two instances of the GraphicEditor class may concurrently try to select a shape, by
calling it’s Grab service; only one of them, however, will actually lock the shape (the
Grab service returning TRUE) while the other one will be informed that it’s locking
attempt has been refused.
This kind of synchronization protocol is sometimes called „pessimistic locking“,
but an „optimistic locking“ scheme such as the one described in [7] could be modeled
as well.
316 R. Bastide and P. Palanque
DeleteShape
CreateShape <c> OwnedShape <c>
delete c;
<c>
<c>
<c>
not OK OK
UnSelect
c.Release ( ); Select
<c> OK = c.Grab ( );
<c>
<c>
FreeShapes
<c> <c>
UsedShapes
<c> <c>
Refresh Refresh
Several of the requirements for the case study are not tackled in this presentation,
for example the connection and deconnection of editors, or the hierarchical nature of
the drawings. They could be handled by reusing the pattern of the Dispatcher class at
various levels, so that a shape could for example hold references to all of its
subshapes.
Modeling a Groupware Editing Tool with Cooperative Objects 317
Grab
<disp>
<FALSE>
Create Grab
disp.Dispatch(this, CREATE); <disp> disp.Dispatch(this, SEL);
<disp> <disp>
<TRUE>
Used Free
<disp> <disp>
Delete Release <disp>
disp.Dispatch(this, DEL); disp.Dispatch(this, UNSEL);
}
3 Conclusion
The language presented in this paper, aims at modeling concurrent and distributed
systems following the OO approach. Objects are defined in a rather classical way,
using most concepts of Object-Orientedness: class/object distinction, dynamic object
creation, use relationship between objects by service call, inheritance and
polymorphism. Each object may have a concurrent behavior, which is modeled by
means of a High-Level Petri Net. Moreover, all objects may be simultaneously active
and the service requests and the service results they send one to another synchronize
them. Several important topics are not addressed in this paper for space reasons:
• As the language allows for inheritance with specialization semantics, it is
necessary to ensure that a derived class is compatible with its ancestor, behavior-
wise.
• Cooperative Objects are executable in essence, and several techniques for
executing the models are devised in [1], at the system, the class or the object level.
References
4. Bastide, Rémi, and Palanque, Philippe. "A Petri-Net Based Environment for the Design of Event-
Driven Interfaces." 16th International Conference on Applications and Theory of Petri Nets,
ICATPN'95, Torino, Italy, June 1995. LNCS, no. 935. Springer (1995) 66-83.
5. Bastide, Rémi, Palanque, Philippe, Sy, Ousmane, Le, Duc-Hoa, and Navarre, David. "Petri-Net
Based Behavioural Specification of CORBA Systems." 20th International Conference on
Applications and Theory of Petri Nets, ICATPN'99, Williamsburg, VA, USA, June 21-25, 1999.
6. Bastide, Rémi, Sy, Ousmane, and Palanque, Philippe. "Formal Support for the Engineering of
CORBA-Based Distributed Object Systems." Distributed Objects and Applications (DOA'99),
Edinburgh, Scotland, September 5-6, 1999. IEEE (1999)
7. Beaudouin-Lafon, Michel, and Karsenty, Alain. "Transparency and Awareness in a Real-Time
Groupware System." ACM Symposium on User Interface Technology (UIST'92), Monterey, CA,
USA, November 1992. ACM Press (1992)
8. Booch, Grady. Object-Oriented Analysis and Design With Applications Benjamin/Cummings
(1994).
9. European Space Agency. HOOD Reference Manual. 3.0, WME/89-173/JB ed. (1989).
10. Object Management Group. The Common Object Request Broker: Architecture and Specification.
CORBA IIOP 2.2 /98-02-01, Framingham, MA (1998).
11. Rational Software Corporation. UML Notation Guide. 1.1 ed.1997.
12. Sibertin-Blanc, Christophe. "Cooperative Nets." 15th International Conference on Application
and Theory of Petri Nets, ICATPN'94, June 1994. LNCS, no. 815. Springer (1994) 471-90.
Modelling Constrained Geometric Objects with OBJSA
Nets
1 Introduction
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 319-337, 2001.
Springer-Verlag Berlin Heidelberg 2001
Modelling Constrained Geometric Objects with OBJSA Nets 319
OBJSA nets (OBJ Superposed Automata [2]), a class of high level Petri nets. OBJSA
nets formalise the geometric construction process, and moreover, allow to represent
and simulate the message propagation algorithm which is used to maintain constraints
when a point of the figure is interactively modified, in the simulation environment
ONE (OBJSA Net Environment). This work allows us to give a sound background to
the Eiffel based implementation, called GEObject [3], which has been used to explore
the approach and create a large variety of examples of constrained constructions.
Constraint-based specification is not limited to geometric modelling, but can be
extended to a variety of applicative areas; among them user interface design [4] [5],
animation, industrial design [6], window management [7]. One of the earliest
applications has been the constraint-based geometric modelling system developed by
Sutherland [8], who implemented numerical methods for constraint solving. Also
Nelson [9] adopted numerical methods (Newton-Raphson iteration technique) in the
Juno system. In these systems objects are declared in terms of geometric relations
between them and their definitions are subsequently translated into analytical
descriptions of graphical primitives. Many fundamental relations, such as lines being
congruent or parallel, lead to non-linear equations; moreover, it is often difficult to
find initial conditions which allows the numerical method to converge. These facts
imply that constraint solving by numerical techniques is not adequate for large
systems and too slow for interactivity. Always in the area of geometric modelling,
Fuller and Prusinkiewicz [10] implemented the L.E.G.O. system for 2D and 3D
objects specification based on constructive methods: the constraints maintenance is
assured by the same algorithms that express objects in geometric terms. Their
approach is similar to ours, but while we explore the object-oriented paradigm, they
exploit the Lisp system to express the imperative constraints. Constraints maintenance
by constructive methods has also been adopted by Bruderlin [11] and Sohrt [12], who,
using rewriting rules, discover and re-execute the construction steps. Van Emmerik
[13] presented the CSG (Constructive Solid Geometry) system, where geometric
relations are specified by constraints between local co-ordinate system and evaluated
real-time. More recently, LinkEdit [14], overcomes the limits of the local propagation
method SkyBlue [15] to solve cycles by calling a cycle avoidance subsystem, when a
new constraint is introduced. LinkEdit presents an interactive solution to constraints
declaration, as well. Our approach, by using the internal representation of a
construction, does not requires algorithms for cycle avoidance and for numerical
constraint solving. The construction becomes part of the system and keeps the
relationships among objects. The algorithm dealing with transformations on objects is
invoked when an object receives a transformation message. The transformation of a
figure is essentially its reconstruction, obtained by propagating the transformation
message to all descendants of an object, invoking the instance methods that have been
activated during the construction.
In this paper, in §2 we outline the work background, in §3 we introduce a
formalization of geometric constructions and transformations with a type of Petri nets,
the OBJSA nets [2] and the motivation why a formalization is needed. In §4 we
present how the construction and the transformation processes modelled by means of
OBJSA nets have been simulated in the environment ONE [16] [17]. In §5 we give an
outline of the object-oriented structure of GEObject system.
320 M.A. Alberti, P. Evi, and D. Marini
l
C l'
s
A B c2
c1
s'
D B'
Fig. 1. Axis l of segment s and their transformation l' and s' obtained by translation of point B
into B'
1
Mathematicians since long time have been questioning whether a compass and a ruler were
the minimum set of tools to solve geometric constructive problems and which problems
could be solved by this method. Felix Klein, using Galois theory results (18) has clearly
stated that the geometric figures that can be constructed using compass and ruler are those
and only those that can be expressed in terms of algebraic equations that can be solved by
applying a finite number of rational operations or second order radicals. These results
establish the theoretical bound of the kind of problems that one can face in a constructive
geometric system, like ours.
Modelling Constrained Geometric Objects with OBJSA Nets 321
preserve the internal relationships among entities. For example, if we translate point B
to position B', we obtain a new segment s' and a new axis l'.
In order to make explicit the process underlying a geometric construction and its
successive manipulations, a bipartite graph, that we will call GCG (Geometric
Construction Graph) [19] has been informally introduced and adopted. It describes
the sequence of steps that enables us to generate a figure and the relationships among
the constituent objects. GCG bare some resemblance to Petri nets, but it is definitely
not: e.g. GCG do not consumes resources. GCG is a representation of a class of
constructions, not of a single one: the uniqueness of a given figure derives from a
specific instantiation and evolution of the GCG.
GCG's nodes are interpreted as geometric objects, represented by circles whose
labels are the object names, and as constructive methods or actions, represented by
rectangles whose labels are the action names, that can be the same for different
classes of objects. In the graph input arrows to an action denote objects required as
parameters of the action whose output arrows link to the generated objects. Arrows
establish a partial temporal ordering among the operations that will lead to the figure.
The ordering is defined starting from nodes without input arrows (start nodes)
towards nodes without output arrows (final nodes). It is supposed to have a token in
any start nodes. An action can be executed only if all the input nodes connected to it
contain a token. Action execution does not consume input tokens and produces an
output token in all the corresponding output nodes. The construction process ends
when all the final nodes contain a token. In Fig. 2 we show the GCG describing the
construction of the segment axis: we start by instantiating two points, namely A and
B, then we instantiate the segment s and the two circles c1 and c2, by sending
appropriate action messages to the object points. We can select the derived object
circles and send them a message to perform an intersection action, in order to
generate new points C and D, that in turn will receive a message to build a line (see
Fig. 1). The semantic of GCG is given in [19]. The order of the parameters is
relevant: for example in Fig. 2 the do_circle method uses its first parameter as the
centre and the second to compute the radius, making the two circles c1 and c2
different.
GCG's are helpful in describing informally and intuitively a problem which is
sequentially solved by users but has intrinsic concurrent aspects. We observe, for
instance, that in Fig. 2 do_circle and do_segment actions are independent from
each other and the order of execution is not relevant, they can be executed
simultaneously or in whatever order. This independence produces concurrency
(actions can be executed simultaneously) and non-determinism (execution order is not
completely pre-defined).
During the construction process, GEObject users actually perform actions
sequentially, while concurrency can be exploited by the system, when it responds to
the users' action to transform the figure. More precisely, users can translate one of the
points involved in the figure and the system reacts by re-traversing concurrently the
graph that describes the construction. For example, in the simple case of translation of
a primitive point, as in Fig. 1 where point B is translated into B', the whole figure
must be drawn again. In order to achieve the desired result the system has to repeat
the operations specified by the GCG of Fig. 2, starting from the primitive objects,
represented by the nodes labelled A and B, following the arcs and executing the
specified actions do_segment, do_circle, intersect, do_line. The
two actions do_circle, and do_segment can be executed concurrently. The
322 M.A. Alberti, P. Evi, and D. Marini
action intersect can be executed only after the two do_circle actions, and the
action do_line after the intersect one. Indeed, each action produces new objects
that will in turn trigger other actions until the whole figure is re-drawn.
A B
c1 s c2
intersect
C D
do line
The GCG graph is the data model adopted in GEObject, on which the transformation
algorithm relies, but it is a rather informal tool to represent the relationships that are
established during a geometric construction. The lack of a formal characterisation of
this tool has moved us to a more formal model. Therefore we used OBJSA nets to
describe the geometric processes. Whereas GCG, even if informal, is simple and
straightforward to write and to understand, OBJSA nets have a precise semantics.
Among different types of Petri nets we chose OBJSA nets for the following
reasons:
• the need of high level Petri nets to represent the information associated to
geometrical entities (i.e. point co-ordinates, segment lengths, circle radius,
angles...);
• OBJSA nets are suitable to represent object-oriented system: in particular for
the data abstraction capabilities of the OBJ3 language;
• the availability of the simulation environment ONE (OBJSA Net
Environment [16]) to support model definition and validation.
OBJSA nets were defined in order to describe generic distributed systems. To this
extent they provide the notion of composition of the non deterministic components of
the system. OBJSA are based on Superposed Automata Nets described in [20] which
allow composition of subsystem models, and use OBJ3 language [21] to specify
tokens holding information.
An OBJSA component is made of places and open/close transitions connected by
oriented arcs: all elements are labelled. Open transition represents the interface of all
components towards the external world, i.e., other components. To compose two or
more open components (components with open transitions) one has to superpose the
corresponding open transition of each open component. An open transition has a set
of constraints (algebraically expressed by means of OBJ3 language) that must be
satisfied during superposition. Token domain definition is also based on OBJ3
language and is divided in two parts: token name and token data. The token name
represents the identity of the token and cannot be modified; the token data represents
the information associated to the token and can be modified by transitions according
to their label.
In order to model a system with OBJSA nets, one has to follow three steps:
1. identify logical independent entities in the system to model; each entity will
be modelled by an open OBJSA component
2. define, for each open component, the token domain specification using OBJ3
language
3. compound open OBJSA components by means of their open transitions in
order to obtain the complete system model.
We have defined an open OBJSA component for each class in GEObject.
Therefore we defined component Geopoint, Geoline, Geosegment, Geocircle and so
on (see § 5). Each of them is an OBJSA net with two places labelled respectively
UNBORN and ALIVE and a set of transitions. In each component the place labelled
UNBORN initially contains an infinite number of tokens whose token name is a unique
positive integer. Token data is undefined. No tokens are initially present in the
ALIVE place. Each transition corresponds to an action in the GCG, i.e., an operation
that can be performed on a generic geometric object represented by a token. When a
324 M.A. Alberti, P. Evi, and D. Marini
transition fires some required tokens are fetched from the ALIVE place, used,
modified in their data part as necessary and re-placed in the ALIVE place of the same
component, while other tokens are fetched from the UNBORN place, their data part is
initialised, and placed in the ALIVE place of the same component.
If a geometric operation involves two or more object classes, the corresponding
open components modelling those classes have an open transition. For example, to
model the creation of a segment given two points we define an open transition called
S-with-two-pts in any Geopoint and Geosegment component. Let us see how
superposing these open transitions we obtain a new OBJSA component that models
the creation of a segment by two points. In Fig. 3 it is shown a part of Geopoint
component and in the following Fig. 4 a part of Geosegment component. Finally, in
Fig. 5 we have composed Geopoint and Geosegment components by means of the
superposition of open transition S-with-two-pts.
x y x, y : ERAT
Geopoint UNBORN
NAMEPART prP-with-two-pts = true .
GEOPOINTDATA d*1 = [(x);(y)] .
<n1;d1> prS-with-two-pts = true .
d*2 = d2 .
d*3 = d3 .
P-with-x-y
Geopoint
NAMEPART
GEOPOINTDATA <n1;d*1>
ALIVE
The definition of sort NAMEPART is given by the following OBJ3 code, where P,
L, H, S, C, A, N stand for point, line, half-line, segment, circle, arc and angle
respectively, and NAT is the set of natural number:
x, y : GEOPOINT
x
Geopoint UNBORN y
NAMEPART
GEOSEGMENTDATA prS-with-two-pts = true .
<n1;d1> d*1 = ......
Geopoint S-with-two-pts
NAMEPART <n1;d*1>
GEOSEGMENTDATA
x* y*
ALIVE
Geopoint x
y UNBORN
NAMEPART
GEOPOINTDATA
<n1;d1> x, y : ERAT
Geopoint P-with-x-y
NAMEPART <n1;d*1>
GEOPOINTDATA UNBORN
Geopoint
ALIVE
NAMEPART
GEOSEGMENTDATA
<n4;d4>
<n2;d2> +
S-with-two-pts
<n4;d*4>
Geopoint
ALIVE NAMEPART
GEOSEGMENTDATA
op1*_to x(_),
op2*_to y(_) ) .
op imm: -> Point.
op undef: -> Point.
endo
obj 2POINT is dfn 2Point is 2TUPLE [POINT, POINT]*(
op <<_;_>> to [_;_],
op1*_to first(_),
op2*_to second(_) ) .
endo
obj GEOPOINTDATA is sort Geopointdata.
pr POINT.
subsorts Geopointdata < Point.
... operations omitted ...
endo
obj GEOLINEDATA is sort Geolinedata.
pr 2POINT.
subsorts Geolinedata < 2Point.
... operations omitted ...
endo
obj GEOHALFLINEDATA is sort Geohalflinedata.
pr GEOLINEDATA .
subsorts Geohalflinedata < Geolinedata.
... operations omitted ...
endo
obj GEOSEGMENTDATA is sort Geosegmentdata.
pr GEOHALFLINEDATA .
subsorts Geosegmentdata< Geohalflinedata.
... operations omitted ...
endo
The sort ERAT represents an extension of the set of rational numbers necessary to
define the square root operation rounded at 5 decimal digit (see [19]).
In Fig. 6 we show the OBJSA net modelling the construction of a segment axis. It
is completed by the following Boolean predicate associated to each transition:
y UNBORN
P-wit-x-y
<n3;d3> <n1;d*1> <n4;d4>
ALIVE
<n5;d5> + <n7;d7> +
L-with-two-pts <n6;d6> <n8;d8> C-with-center-pt
<n3;d*3> <n4;d*4>
ALIVE
ALIVE
UNBORN <n14;d14> +
<n15;d15>
<n11;d*11> <n9;d9> +
<n12;d*12> <n10;d10>
<n13;d13> +
<n11;d11> +
<n12;d12>
S-with-two-pts
Intersect-c-c
<n13;d*13>
Line Point
ALIVE NAMEPART NAMEPART
LINEDATA POINTDATA
d*1 = [(x);(y)] .
d*3 = [(d5);(d6)] . Segment Circle
d*4 = [(d7);(d8)] .
d*13 = [(d14);(d15)] . NAMEPART NAMEPART
d*11 = int-c-c-1(d9 , d10) . SEGMENTDATA CIRCLEDATA
d*12 = int-c-c-2(d9 , d10) .
represents the construction process of a figure, we get a GCG. The unfolding process
that we apply to the OBJSA model is only a partial one. In fact a geometric figure can
be seen as a couple: a construction process and a set of values to be associated to the
geometric instances. The GCG model captures the construction process whereas the
OBJSA model captures also the numeric value of geometric instances (i.e. points co-
ordinates). This partial unfolding from OBJSA to GCG involves loss of information,
whereas the reverse process requires addition of information. On the other hand GCG
represents a construction in a more abstract way, i.e. it represents the class of all
figures produced by that construction.
Geoline Geoline
L_with_two_pts
Geohalfline
UNBORN 1 2 1 ALIVE
UNBORN
Int_h_h
Int_h_l Int_l_l
1 2
2 1 1 1
1 1 1 1
H_with_two_pts
1
1 2
x y
ALIVE
Similar for:
Geopoint
Geocircle
Geohalfline UNBORN P_with_x_y ALIVE
Geoangle
Geoarc
Geopoint
1 1 1 1 1 1 Int_h_s
1 Int_l_s 1 1 1
2 Int_s_s
1 2
UNBORN 1 ALIVE
S_with_two_pts
Geosegment Geosegment
We have modelled with an OBJSA net the whole structure of GEObject, as well, see
Fig. 7. This net integrates all the OBJSA subnets which represent all objects and
functionalities in GEObject, assuming that all predicates are true. The transitions
model all basic creation methods and the places model elements of GEObject. All
Modelling Constrained Geometric Objects with OBJSA Nets 329
nodes labelled ALIVE initially have an infinite number of tokens, whereas those
labelled UNBORN initially have no tokens. A geometric construction is represented by
a specification of this general net, defining the necessary predicates of the transitions
involved in the construction.
OBJSA has proved to be very appropriate to describe an object-oriented system as
GEObject, where classes, that represent an abstraction of the geometric entities, are
modelled by OBJSA components. Each Eiffel class is described by an OBJSA
component and each creation method is modelled by a transition. The composition of
different components, by means of their open transitions, enables to describe a
generic constructive process of a geometric figure.
The move transition is always an open transition modelling interaction with users.
It requires two external parameters: dx and dy representing the translation
displacement. Its effect is to fetch the required token from the ALIVE place of the
OBJSA component and to enable other transitions in order to propagate the
transformation. The translation takes place if the object is not immaginary and it is
not anchored (in case of a point). In Fig. 8 we have drawn the P-move transition for
the Geopoint OBJSA component.
Geopoint
dx, dy : ERAT
NAMEPART
GEOPOINTDATA
dx dy
ALIVE
<n1;d1>
<n1;d*1>
P-move
We need a backward transition for each creation method involved in the geometric
figure. In the example of the transformation of the segment axis (the construction of
which is modelled by net in Fig. 6) we need a backward transition for the methods
S-with-two-pts, L-with-two-pts, C-with-center-pt and
Intersect-c-c. So, it is possible to link each object with all its ancestors,
Modelling Constrained Geometric Objects with OBJSA Nets 331
ALIVE Geopoint
NAMEPART
<n5;d5>+ GEOPOINTDATA
<n6;d6>
<n1;d1> + <n2;d2>
<n5;d*5> +
<n6;d*6>
<n1;d*1> + <n2;d*2>
Backward-S-with-two-pts Forward-S-with-two-pts
<n4;d*4> <n3;d*3>
<n4;d4>
<n3;d3>
Geosegment
NAMEPART
GESEGMENTDATA ALIVE
prBackward-S-with-two-points = movestate(lcomflag(d4)) ==
backward.
d*4 = lsetalreadymoved (lsetstandby(d4)).
d*5 = if not alreadymoved (pcomflag(d5))
then if isprimitive (pointflag(d5))
then if not isanchored (pointflag(d5))
then psetalreadymoved
(psetforward (psetcharpt
(d5,
[(x(pcharpt(d5))+(ldelta (d4)));
y(pcharpt(d5) +
y(ldelta(d4)))]
)))
else psetalreadymoved(psetforward(d5))
fi
else psetbackward(psetdelta(d5, ldelta(d4)))
fi
fi.
d*6 = same as d*5
332 M.A. Alberti, P. Evi, and D. Marini
prForward-S-with-two-points = (movestate(pcomflag(d1))
== forward
or movestate(pcomflag(d2)) ==
forward)
and (((isimmaginary(pcomflag(d1))
or
isimmaginary(pcomflag(d2)))
and not
isimmaginary(lcomflag(d3))))
or (lcharpt(d3) =/=
[(pcharpt(d1);(pcharpt(d2))])) and
lcharpt(d3)=/=[(pcharpt(d2))(pcharpt(d1))])).
d*3 = if isimmaginary(pcomflag(d1)) or
isimmaginary(pcomflag(d2))
then if not isimmaginary(lcomflag(d3))
then lsetimmaginary(lsetforward(d3))
else d3 fi
else if lcharpt(d3)
=/=[(pcharpt(d1));(pcharpt(d2))] or
lcharpt(d3) =/=
[(pcharpt(d2));(pcharpt(d1))]
then lsetforward(lsetcharpt(d3,
[(pcharpt(d1));(pcharpt(d2))]))
else d3 fi
fi.
d*1 = d1.
d*2 = d2.
Modelling Constrained Geometric Objects with OBJSA Nets 333
Geosegment
NAMEPART
GEOSEGMENTDATA dx
S-Move
dy
<n5,d*5>+<n6,d*6>
<n1,d*1>+<n2,d*2>
dy dx <n5,d5>+
<n6,d6>
<n1,d1>+
Back-S-with-two-pts <n2,d2> For-S-with-two-pts
L-Move
<n19,d*19>+
<n20,d*20>
<n23,d*23>+
<n24,d*24>
Geocircle <n35,d*35>
dx
NAMEPART
GEOCIRCLEDATA C-Move
dy
<n35,d35>
Fig. 10. Complete OBJSA net of segment axis construction and transformation
Eventually, the OBJSA net in Fig. 10 extends Fig. 6 modelling also components
translation. Initially only move transitions are enabled (S-Move, L-Move, C-
Move, P-Move).
In order to fire they need interaction: a user selects the object to move and activates
the firing of the corresponding transition. For example, to move point [P; 1], a user
has to select P-Move transition, chooses the point to move, and then specifies the
translation amount dx and dy. The OBJSA net evolves automatically by means of
successive firing of backward and forward transitions according to the algorithm
described above. The algebraic specification of the OBJSA net in Fig. 10 is omitted.
It can be derived from OBJSA nets in Fig. 8 and Fig. 9.
334 M.A. Alberti, P. Evi, and D. Marini
I level GeoNode
GeoHalfline GeoArc
III level
SegLength AngleWidth
GeoSegment
GEObject is an incremental geometric modelling system. Users can extend the set of
primitive classes and of methods, by editing new classes and methods interactively
while entering a construction. The construction is considered as a prototype, an
example of the new procedure. Users do not have to write code to extend the system.
Therefore this feature of GEObject is based on the programming by example
paradigm.
For example, let us suppose we want to define the new class of equilateral
triangles; we will have to construct an equilateral triangle starting from two vertexes
so that the system can "learn" the construction generating automatically the Eiffel
code corresponding to the new class GeoEquiTriangle. From now on users can
draw a generic equilateral triangle without repeating the whole construction, but
simply sending the creation method of the new class. To keep this new class in the
system for future running sessions, the user must recompile the extended code.
The new class inherits the interaction methods from its ancestor class. For instance
the class GeoTriangle can be defined as a specialisation of class Polygon and
could be specialised into two different classes GeoEquiTriangle and
GeoRectTriangle. If a user defines an interaction method called median for
triangles, this is inherited by the two subclasses. We recall that interaction methods
are constructive procedures producing geometric objects: in triangles medians and
heights are generally obtained with different procedures, that will generate the same
object in some special class, such as GeoEquiTriangle. Also it is important to
remind that users do not specify properties but constructions; in the system one can
verify properties, for instance by querying objects, but not prove theorems. There is
no multiple inheritance. All classes derive from class GenericObj.
In the same way the system can be augmented by adding new construction
methods: for instance, the segment-axis construction can be added to the system as a
construction method of class GeoSegment or a new construction method of an
existing class. Indeed, it is the user's responsibility to decide upon the hierarchy and
to be consistent in terms of the geometry taxonomy.
336 M.A. Alberti, P. Evi, and D. Marini
6 Conclusion
References
1. Alberti, M.A., Bastioli E., Marini, D.: Towards Object-Oriented Modelling of Euclidean
Geometry, The Visual Computer, vol. 11, (1995) 378-389
2. Battiston, E., De Cindio, F., Mauri, G.: OBJSA Nets: a class of high level nets having objects
as domains, in Advances in Petri Nets 1988, G.Rosenberg (ed.), LNCS 340, Springer-
Verlag, Berlin, (1988) 20-43
3. Alberti, M.A., Evi P., D. Marini http://www.dsi.unimi.it/~colos/GEOHT/rexecGEO.html
4. Borning, A.: The programming language aspects of ThingLab, A Constraint-Oriented
Simulation Laboratory, ACM Transactions on Programming Languages and Systems, 3(4),
(1981) 353-387
5. Borning, A., Duisberg, R.: Constrained-based tools for building user interfaces, ACM
Transactions on Graphics, 5(4), (1986) 245-374
6. Roth, J., Hashimshony, R.: Algorithms in graph theory and their use for solving problems in
architectural design, Computer-Aided Design, 20(7), (1988) 373-381
7. Cohen, E., Smith, E., Iverson L.: Constrained-based tiled windows, IEEE Computer
Graphics & Applications, (1986) 35-45
8. Sutherland, I.E.: SKETCHPAD: a man-machine graphical communication system.,
Proceedings Spring Joint Computer Conference, (1963) 329-346
9. Nelson, G.: Juno, a constraint-based graphics system, SIGGRAPH Computer Graphics,
19(3), (1985) 235-243
10. Fuller, N., Prusinkiewicz, P.: Applications of Euclidean constructions to computer graphics,
The Visual Computer, 5, (1989) 53-67
11. Bruderlin, B.: Constructing three dimensional geometric objects defined by constraints,
Workshop on Interactive 3D graphics, Vol. 23-24, October, (1986) 111-129
12. Sohrt W.: Interaction with constraints in three dimensional modeling, Master's Thesis,
Dept. Computer Science, The University of Utah, (1991)
13. van Emmerik, M.: A System for Interactive Graphical Modelling with Three-Dimensional
Constraints, Proceedings of Computer Graphics Interactive '90, (1990) 361-376
14. Kwaiter, G., Gaildrat, V., Caubet, R.: LinkEdit: an interactive graphical system for
modelling objects with constraints, Proceedings of Compugraphics 96, (1996) 211-219
15. Sannella, M.: The SkyBlue Constraint Solver, Technical Report 92-07-02, Dept. Comp.
Science and Eng. University of Washington, (1993)
Modelling Constrained Geometric Objects with OBJSA Nets 337
16. Battiston, E., De Cindio, F., Mauri, G.: A class of Modular Algebraic Nets and its support
Environment, CNR, Progetto Finalizzato "Sistemi Informatici e Calcolo Parallelo",
Rapporto n. 4/105, (1994)
17. Battiston, E., Tirloni, P.: Guida all'ambiente ONE (OBJSA Net Environment), CNR,
Progetto Finalizzato "Sistemi Informatici e Calcolo Parallelo", Rapporto n. 4, (1994)
18. Klein, F.: Famous problems of elementary geometry (1895), in: Klein et al. Famous
problems and other monographs. New-York: Chelsea Pub. Co., (1980)
19. Evi, P.: Euclidean Geometry Knowledge Representation with Object-Oriented Paradigm
and Petri Nets, Tesi di Laurea, A.A.. 1993-94, Università degli Studi di Milano,
Dipartimento di Scienze dell'Informazione (in Italian) (1994)
20. De Cindio, F., De Michelis, G., Pomello L., Simone, C.: Superposed Automata Nets,
Application and Theory of Petri Nets, C. Girault, W. Reisig (eds.), IFB 52, Springer-
Verlag, Berlin, (1982) 189-212
21. Goguen, J.A., Winkler, T.: Introducing OBJ3, Report SRI-CSL-88-9, SRI International,
Computer Science Lab., (1988)
22. Alberti M.A., Marini, D.: Knowledge Representation in a Learning Environment for
Euclidean Geometry, in The Design of Computational Media to Support Exploratory
Learning, C.Hoyles, A.DiSessa & L.Edwards (eds.), NATO ASI Series F, vol. 146,
Springer-Verlag, Berlin, (1995) 109-126
An Object-Based Modular CPN Approach:
Its Application to the Specification
of a Cooperative Editing Environment
1 Introduction
One important aspect that should be considered in the basic tasks of software
engineering, namely specification, design, project, coding, and testing is the pos-
sibility of providing environments supporting the concurrent cooperation among
different people (users) in a design team, that might be geographically dispersed
[9]. Another key aspect is the fact that the cooperative work contributes to
reduce the overall costs to develop a software project [12]. Environments sup-
porting a better interaction among members of a design team, and providing
means, by which the software engineering tasks can be executed concurrently in
a cooperative environment, may help in reducing development costs.
On the other hand, in the case of complex (parallel, concurrent, and dis-
tributed) system design, users need structuring tools allowing them to work with
selected parts of the model, abstracting low level details of the other parts. The
marriage between Petri nets [19] and the object-oriented software engineering
approach had emerged as a solution with formal foundation to attack this prob-
lem. Among other formalisms in this direction we may cite [1,3,4,5,11,16], for a
comprehensive discussion see [17]. G-Nets and G-Net systems were introduced
as a Petri-net-based object-oriented framework to the specification, design, and
The authors would like to thank CAPES/Brasil and CPNq/Brasil for the financial
support.
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 338–354, 2001.
c Springer-Verlag Berlin Heidelberg 2001
An Object-Based Modular CPN Approach 339
2 G-CPN
The interface, also called generic switching place (GSP), is the element respon-
sible for the communication between the IS and the rest of the system. To use a
G-CPN module is necessary to invoke one of its services. Only through the GSP,
other components of the system have access to methods and attributes encapsu-
lated inside modules. Moreover, only through the GSP, the IS is able to access
the services of other G-CPN modules in the system. The GSP is an abstract
view of the module, in which it is not possible to see any detailed description.
Although we consider that the methods and attributes are part of the interface
itself, we can interpret the GSP as having a descriptor for each method and at-
tribute. We can see it as a prototype of a function in a high-level programming
language.
To allow a G-CPN module to deal with multiple invocations concurrently
and because the CP-net definition does not provide any element for modeling
attributes and/or services invocation, it is necessary to give a new semantics to
some net elements. However, the IS is structurally identical to a CP-Net. So, a
designer familiar with CPN modeling will be able to work with G-CPN [13,14].
In a G-CPN module, each attribute declared in the GSP, is associated with a
place inside the IS. Thus, an instant value of any attribute is given by the marking
of an associated place. Since attributes model the state of an object, the places
associated with attributes keep their markings through different invocations.
Moreover, tokens inside an attribute place can only be used by one of the several
concurrent methods activation at a given time. The mutual exclusion needed to
access attributes may be modeled by the intrinsic dynamics of Petri Nets. The
type of any attribute is given by the color set associated with the attribute place.
As stated before, methods define the services provided by the module. There
are two places in the IS associated with each method declared in the GSP. The
first one, called the starting place, indicates the insertion point of values for the
method. The second, called the goal place, determines the termination for the
method activity, and tokens inside these places are seen as results of the methods.
Thus, each method has two associated color sets. The starting place color set
determines the type of the arguments, and the goal place color set specifies the
result type.
In order to allow multiple concurrent activations of a method in a G-CPN
module, we adopted the concept of contexts. Each activation of a method has
a different context and every token has a context associated with it. Thus, all
activations have their own sub-marking called the context marking, allowing to
distinguish tokens belonging to different activations. Therefore, it is possible to
keep the dynamic behavior to each one of them. It is important to notice that
to provide the concurrent access to the attributes, there is a special context
for attribute tokens. Thus, tokens in attribute places may be used in bindings
without taking into account the context of other tokens involved.
This way to define a G-CPN module allows to use CP-nets as the IS specifica-
tion, considering simple modification. In fact, only some restrictions are imposed
to the structural definition, and intuitively, the behavior is kept the same as in
An Object-Based Modular CPN Approach 341
Formal Definition. We assume that the reader is familiar with the syntax and
semantic of the language used to the net expressions, namely CPN-ML, although
it is perfectly possible to use both CP-Nets and G-CPN in association with other
language as well. Several auxiliary functions (such as Type()), and sets (as IB,
the boolean set) needed to the formal definition, are also assumed to be known.
342 D.S. Guerrero, J.C.A. de Figueiredo, and A. Perkusich
attribute1
The use and the meaning of such objects is very intuitive, hence, they will not
be described here as well. For a detailed information related to this topic see
[15].
Definition 1. A G-CPN module is a pair GSP, IS where GSP, also called
the interface of the module, is a tuple MT, AT, ISP, AP, GP, UP, LP, OBJ and
IS, the internal structure, is a tuple Σ, P, T, A, N, C, G, E, I, satisfying the
following:
5. UP : ISP → P and LP : ISP → P are the upper and lower place functions
for invokers, such that for any isp ∈ ISP
G-CPNn
G-CPN1 Activation
Invocation
G-CPNn
Return Termination
Interaction Envronment
ISP’s
Lower Place
Formal Definition. Semantic definitions will not be presented in this paper due
to lack of space, but they can be found in [14]. Nevertheless, from the previous
informal introduction and the behavior of a CP-net, the precise behavior of a
G-CPN module as well as of a G-CPN System can be very intuitively understood.
3. S is the set of services of the system, defined as the union of the methods of
all modules S = G1 .MT ∪ G2 .MT . . . ∪ Gn .MT. If Gi .OBJ(isp) = Gj .s, for
any isp ∈ Gi and any s ∈ Gj .MT then the color restriction must be satisfied:
3 Informal Specification
of the Cooperative Editing Environment
A cooperative editing tool for hierarchical diagrams provides the possibility to
integrate a development team to work over a network and allows the concurrent
and cooperative specification, design and analysis of complex systems. The avail-
ability of CSCW is a primary issue related with modern development environ-
ments. In this section we present the informal specification or the requirements
used as guidelines in the construction of the G-CPN specification of the system.
The requirements given below are derived from a case study proposed for the
2nd Workshop on Object-Oriented Programming and Models of Concurrency by
Bastide et al [2]:
all kind of objects in an editing session. The control layer performs the core of
the Computer Supported Cooperative Work. The intermediate layer used by the
manager is named manager layer. The lower layer is the communication layer,
and it is responsible for providing the correct message handling among the users,
by using the network and operating system services.
Network
This approach allows the use of a simple graphical editor over the cooper-
ative service stack. The graphical editor (the application) must guarantee that
the control layer will be asked/informed about any actions performed over the
graphical elements. Thus, if additional features are added to the editor, few
modifications, if any, will be needed in the control and communication layers.
Another advantage of this approach is that no locks over the objects are needed.
Basically, the system keeps track of “who is working on what”.
Hierarchical diagrams can be managed by distributed or centralised data base
systems or even by a simple file system service. However, in order to separate
the object management problem and the cooperative work support, in this paper
we are not discussing a specific choice of either approach. This allows the use
of traditional graphical editors as well as the specification of new cooperative-
oriented graphical editors.
manager, through the System Console, an application that accesses the services
offered by manager layer.
The Graphical Editor may be designed without any assumptions of locking
algorithms, all it needs to do before performing any action over graphical ele-
ments is to ask the control layer if the user has the correct ownership for that
element. If the user does not have the permission, the control layer itself tries
to get the ownership by executing an internal algorithm to guarantee that no-
body else in the system has done it before. Then the application layer receives
the answer: if the user has got the ownership, the graphical editor is allowed to
perform the required action and to continue on its job. On the other hand, if
the control layer did not succeed in granting the ownership, then the graphical
editor must stop the action it was asked to do.
Thus, no locks are really needed. The application layer guarantees that this
protocol will be used: no object is used without a previous authorisation of the
whole system.
The application layer in the manager agent is called the System Console.
It is primarily intended to be used to subscribe users in editing groups, and
removing users as well. But clearly, some additional features are needed, such as
creating/dropping editing groups, control of rules in editing sessions, definitions
of eventual hierarchical differences among users, etc. However, the system console
operator is not required to be logged during an editing session.
The manager layer also uses the communication layer primitives in order to
multicast information to all agents in the system. In the communication layer
there are some reserved primitives that can be only used by the manager layer.
Such primitives are representation of messages about the initialisation/deletion
of groups or users.
Because the manager is a special user, the manager layer functionalities are
simpler to work with. Thus, it is beyond the scope of this paper to detail these
functionalities.
Control Layer
Other services are provided in the control layer to allow the communica-
tion layer to pass messages from the rest of the system. These services can be
seen as the counterpart of those shown above, thus, if a given process receives a
Login call, all cooperative processes must receive a UserLogin invocation. Other
corresponding services offered to the communication layer are: UserLogout,
ObjectCreation, ObjectDeletion, GrantOwnership, and RevokeOwnership.
Two additional services, StartSession and EndSession, are provided to start
and end sessions.
These services operate over some information modeled as attributes. The
information kept by the control layer is about users, groups, sessions, objects
(belonging to hierarchical diagram) and ownership.
Some methods cope with the arriving messages from the net-
work. UpdateGroup, UpdateUser, RequestOwnership, ReleaseOwnership,
ObjectCreation and ObjectDeletion are used as the counterpart of the mul-
ticast methods explained before.
Thus, if some user logs in the system, the sequence of methods invocations
could be: the application layer invokes the method Login in the control layer;
the Login service would need to invoke the MC_UpdateUser method in order
to inform the cooperative processes that some user has passed from inactive to
active; each process receives an UpdateUser message (it is seen as a method
invocation); the UpdateUser message handler invokes the UserLogin method in
the control layer. Thus, if a user logs in, every process in the system will be
informed.
It is important to keep in mind that the Group Communication Services are
required to be reliable. If a message is multicasted, then every process must
receive it in the same order than any other process in the group. If d some
message is lost, than no process at all receives the message.
User
Login
User
(uid, gid) Group
Users Groups
(uid, ag) (gid, state, ul)
[Belongs(uid, ul)]
T1
Primitive
(uid,gid) MC_UpdateUser ok
T2 T3
Primitive
inside it. These attributes are located in their own modules, encapsulated with
their own methods. Furthermore, the actual module incorporates several meth-
ods inside the same Internal Structure.
In Fig. 7 we see the GetOwnership method. The method behaves as follows.
When it is invoked, the application specifies the object and the level it requires
(inspection, modification, encapsulation and deletion). If there is no ownership
for that object the communication layer is required to multicast a request of
ownership. This is done in order to guarantee that no other agent can get the
ownership first. The actual modification in the Ownership place is done just by
the activation of the GrantOwnership method meaning the arrival of a message
from the communication layer. After this, the GetOwnership method proceeds,
and it finishes by returning a confirmation or not to the application layer, de-
pending on the state of the object ownership.
Obj_Request
GetOwnership
User
Object
(obj, level) (obj, gid, state, owners)
LocalUser Ownership
T1
Request
Request Primitive
Wait
MC_RequestOwnership
Primitive
if Belongs(uid, owners)
(uid, gid, obj, level) ok then ok
else nok
T2
5 Conclusions
In this paper we have introduced a Coloured Petri Net object based class of Petri
net named G-CPN, that was derived from a previous introduced model named
G-Net. The new model introduces the use of CP-Nets as the internal notation
to the modules and also formalises the interaction model among the modules.
An Object-Based Modular CPN Approach 353
References
1 Introduction
This paper is devoted to illustrate the main features involved in KRON (Knowl-
edge Representation Oriented Nets). We starting creating KRON while we were
working in the development of knowledge based models for DESs. It became
clear in working with DESs the need to expand the power of our knowledge en-
gineering representation schema with the integration of an adequate formalism
to deal with discrete event system features.
A lot of integrations of Petri nets with different paradigms can be found in
technical literature. These may be split into three main groups: 1) Extension
of Petri nets with primitives to support methodological aspects (modularity,
top-down and bottom-up design, ...); 2) Integration of Petri nets with algebraic
specifications and 3) Integration of Petri nets with the frame/object paradigm.
Several workshops about the integration of Petri Nets and objects are held reg-
ularly as part of prestigious conferences (Int. Conf. of Application and Theory
This work was supported by the Spanish Interministerial Comission of Science and
Technology (CICYT) under projects TAP95-0574 and TIC98-0587.
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 355–374, 2001.
c Springer-Verlag Berlin Heidelberg 2001
356 J.A. Bañares et al.
of Petri Nets, IEEE Int. Conf. on Systems Man and Cybernetics, ...), this is a
proof of the growing interest in this topic.
A HLPN extension belonging to the first group is HCPN (Hierarchical Col-
ored Petri Net). HCPNs [21] provide a set of constructs to support modularity
aspects. The idea behind HCPNs is to allow the construction of a large model by
combining a number of small HLPNs into a larger net, and different structuring
tools are proposed with this purpose. Posterior proposals extending HLPNs with
structuring constructs can be found in [18] and [13]. Other works that propose
different object oriented interpretations of HCPN constructs can also be found
in [24] and [17].
The presentation of the most representative works on the PN integration
with algebraic specifications (second group) can be briefly summarized as fol-
lows: Algebraic Nets [34], Many-sorted High-level Nets [7] and Petri Nets with
structured tokens [29] are a result of the integration of HLPNs (used to describe
the control structure of the system) and algebraic specifications (used to describe
the data structure). These previous works have been the basis of many others,
most of them also considering some object oriented focus. OBJSA Nets [4] and
CO-OPN (Concurrent Object-Oriented Petri Nets) [10] are good examples. Its
goal is to allow data abstraction and introduce net modularity.
Finally, the third group are the approaches based on a frame/object ap-
proach. From an engineering point of view, we consider them closer to human
conceptual thinking than the ones based on algebraic specifications. What is
required here, is a conceptual model which will enable engineers and computer
scientists to describe domain concepts in a more intuitive way. Examples of this
group are:
– In [15] high level Petri nets are integrated with the Entity-Relationship model
to obtain the EER formalism. This model is revised in [16] incorporating ob-
ject oriented concepts to increase expressiveness in data modeling. However,
this approach is not extended to the process structure in order to provide an
overall modeling framework. Finally, a second revision is done in [6]. In this
last piece of work the internal behavior of each object is described by means
of a Petri net (O-net). To obtain the global process structure partial nets
are synchronized by another Petri net, the P-net. This P-net is not included
in the object structure.
– Object Petri nets (PNO), which have been widely referred to in technical
literature, were defined in [31] as High Level Petri Nets with Data Structures.
Their objective is to incorporate the data modeling and updating into the
net model by means of frame-like data structures. Starting from this seminal
work, in [28] HOOD/PNO is proposed as a software engineering methodology
that integrates PNO with the HOOD. In [32] two more extensions to PNO
were introduced: Communicative and Cooperative nets. They enable the
modeling of a system as a collection of nets that encapsulate their behavior
while interacting by means of message sending and the client/server protocol.
– [1] presents PROTOB, an object oriented language and methodology based
on PROT nets [9]. In this object oriented approach, objects communicate
KRON: Integration of CPNs with Objects 357
As the reader can see, there are a lot of integrated models. Most of the
previous approaches concentrate on providing structuring tools in compliance
with software engineering principles, by enforcing constraints that may result
in a loss of freedom and flexibility. Most of them also extend the formalism of
HLPNs. However, there is a great scope for further work in tailoring analysis
techniques to extended HLPNs.
KRON is based on the integration of Colored Petri nets (CPNs) with the
frame/object oriented paradigm. The integration model presented in this paper
provides a close integration of HLPNs and the object model, and it does not
extend the HLPN formalism. Frames and rules have been selected as a basis to
support the representation aspects due to its power for knowledge representa-
tion. Additionally, we improved programming discipline by following an object
oriented methodology obtaining important methodological advantages such as:
1) it supports conceptual models closer to human conceptualization and inde-
pendent from implementation, thus the models are easier to understand; 2) it
facilitates reusability and model extensibility based on encapsulation and inher-
itance characteristics.
The rest of the paper is organized as follows. Firstly, a brief presentation of
KRON constructs that support the CPN formalism is presented. In the follow-
ing sections, the case study of hurried philosophers is used to illustrate KRON.
Section 4 shows the definition of dynamic and no dynamic entities and their
relationships. Section 5 presents inheritance as a mechanism to share code. The
communication model is presented in section 6. The paper finishes with a con-
clusions section.
2 KRON Constructs
3 Relations to CPNs
The Petri net underlying a KRON model can be considered as a subset of a CPN
with a special syntax. However, there still exist restrictions that are introduced
to improve the modeling and simulation capabilities of CPNs to solve practical
tasks. The formal analysis of properties was not a crucial issue in the KRON
development. Our approach is closer to the work presented by Cherkasova et col.
in [12], which combines CPNs with modeling by direct programming, than to
works that extend the CPN formalism.
Following this pragmatic approach, the CPN formalism is not extended, but
really, it is constrained to use simpler expressions. A KRON net differs from
CPNs (as defined in [23]) in the following restriction: An Arc expression may
only denote a unique token, but not set of tokens.
Another important difference with CPNs is introduced by the integration
of CPNs with the object model. KRON tokens are entities, and their attribute
values and relationships are considered in order to describe the system behavior.
The nature of these tokens introduces a property called ubiquity [31]. Ubiquity
concerns the token ability to have several occurrences in a marking. Formally, a
KRON net with ubiquity is not a correct CPN because it produces the loss of
the transition scope. Ubiquity produces the following undesirable effects: 1) it
violates the partition and encapsulation of the state in dynamic objects. Moreover,
it hides the way transitions modify the state because they have unlimited writing
access to all token attributes. 2) Ubiquity is a property irreducible to algebraic
analysis. This problem is not exclusive of the integration of the object model
and Petri Nets. The problem arises in any representation language that allows
different references (object pointers) to the same object. This property, which is
known as dynamic aliasing, makes it difficult to prove the correctness of a system
representation theoretically [27]. KRON allows the modeller to decide whether to
avoid ubiquity in order to prove the correctness of the system representation, or
to model in a more flexible way without to worrying about the ubiquity problem.
4 A KRON Model
for the Hurried Philosophers Case Study
In order to illustrate the representation schema, let us focus on “The hurried
Philosophers” case study [32]. Since the proposal allowed free interpretation
of philosopher behaviors and it was originally though for a message passing
communication model, we state our interpretation first:
The case study is the very well known table of philosophers, with an ex-
tension: a philosopher may leave the table as he likes it, and new guests may
KRON: Integration of CPNs with Objects 361
Token Objects
In the problem description it can be identified the no dynamic entities Chair,
Fork and Philosopher. It can also be identified the dynamic relation Seat rep-
resenting the association between a chair and a philosopher, and the dynamic
362 J.A. Bañares et al.
{start-eating
Philosophy-world {Philosophy-world is-a: transition
is-a: dynamic-object pre-net-relations:
Out ; activities (Thinking
actions: start-eating, end-eating, (unit <philo>) ; philo
intro, leave )
start-eating: start-eating post-net-relations:
end-eating: end-eating (Eating
intro: intro (unit <philo>) ; philo
philo philo leave: leave )
; states assoc-data:<philo>
leave intro states: Eating, Thinking, Out predicate: T
Eating: action:
attributeclass: state }
philo philo valueclass: philosopher
Thinking:
attributeclass: state
Thinking valueclass: philosopher {end-eating
Out: is-a: transition
attributeclass: state ...
philo valueclass: philosopher
; other information
...
start-eating } {intro
is-a: transition
philo ...
end-eating
Dynamic Objects
It is possible to identify the following dynamic entities from the problem descrip-
tion. The dynamic-object philosophy-world represents the activities of philoso-
phers. They may enter and leave the world of philosophy, and may be thinking
and eating. Figure 3 shows the dynamic-object representing the philosophy-
world. It has a state slot for each CPN place. Each place in a CPN has an as-
sociated set of possible tokens. In the same way, each state slot has a constraint
(valueclass metaknowledge) associated to the class of objects (tokens) that it can
contain. In the philosophy-world all state slots hold philosopher instances.
We may consider the rules of politeness incrementally. Thus, first we define
the dynamic-object Chair-Politeness. It represents that a chair may be in-
troduced or removed from the table considering involved forks, but it does not
KRON: Integration of CPNs with Objects 363
{Chair-politeness {leave-politeness
is-a: dynamic-object is-a: transition
; activities pre-net-relations:
actions: leave-table, intro-table (Busy-chairs ; pre-leave
leave-table: leave-politeness (unit <leave-chair> right-fork <fj>
intro-table: intro-politeness left-fork <fk> philo <philo>))
; states (Busy-chairs ; pre-left
states: Free-chairs, Busy-chairs, (unit <left-chair> right-fork <fk>))
Free-forks (Free-forks ; pre-fork
Free-chairs:
attributeclass: state (unit <fk>))
valueclass: chair post-net-relations:
Busy-chairs: (Busy-chairs ; post-left
attributeclass: state (unit <left-chair> right-fork (NULL <fk>) <fj>))
valueclass: chair (Free-chairs ; post-leave
Free-forks: (unit <leave-chair> right-fork NULL))
attributeclass: state }
valueclass: fork
; other information
...
} Chair-Politeness Free-chairs
{intro-politeness
is-a: transition pre-guest post-leave
pre-net-relations:
(Free-chairs ; pre-guest <philo> intro-table <philo>
(unit <guest> left-fork <fk>)) leave-table
post-right-intro
(Busy-chairs ; pre-right-intro
pre-right-intro
post-left-intro
pre-left-intro
(unit <right-chair> left-fork <fj>))
post-guest
pre-leave
(Busy-chairs ; pre-left-intro
pre-fork
post-left
pre-left
(unit <left-chair> right-fork <fj>))
(Free-forks ; free-fork
(unit <fj>))
post-net-relations:
(Busy-chairs ; post-right-intro
(unit <right-chair>)) Busy-chairs
(Busy-chairs ; post-left-intro Free-forks
(unit <left-chair> right-fork NULL fk))
(Busy-chairs ; post-guest
(unit <guest> right-fork <fj>
philo <philo>))
(Free-forks ; fork
(unit <fk>)) fork
(Free-forks ; free-fork
(unit <fj>)) free-fork
}
consider that philosophers may be eating or thinking. Figure 4 shows the Chair-
Politeness dynamic object. The state slots Free-chairs and Busy-chairs hold
Chair instances, and the state slot Free-forks hold Fork instances. Transitions
intro-table and leave-table take into account the attributes right-fork and
left-fork of Chair instances, and modify the relations between chairs and forks
to introduce or remove a chair. The initial marking should, at least, hold two
busy chairs and an arbitrary number of free chairs with their corresponding left
fork. Transitions are parameterized with the <philo> variable, which represents
that the Chair-Politeness must be synchronized with another dynamic-object
to modify relations between chairs and philosophers.
Following, the Chair-Politeness may be specialized to consider that philoso-
phers may be thinking or eating. Figure 5 shows the Chair-Eating-Politeness,
which inherits state and activity slots from Chair-Politeness, and adds two new
activities start-eating and end-eating, and a new state slot Busy-forks. It
represents that a philosopher only may start eating if he has a free fork on his
left and another one on his right side. When a philosopher is eating the corre-
364 J.A. Bañares et al.
sponding forks are removed from the place Free-fork. In this way, his neighbors
can not start eating, and guests may not be introduced next to him.
{start-eating-politeness
is-a: transition
Chair-Eating-Politeness Free-chairs pre-net-relations:
(Free-forks ; fork1
pre-guest post-leave (unit <left-fork> right-chair <chair>) )
(Free-forks ; fork2
<philo> intro-table leave-table <philo> (unit <right-fork> left-chair
(unit <chair> philo <philo>)))
post-net-relations:
post-right-intro
pre-right-intro
post-left-intro
(Busy-forks ; chair
pre-left-intro
(unit <chair>))
post-guest
pre-leave
pre-fork
}
post-left
pre-left
{Chair-Eating-politeness
is-a: Chair-politennes
; activities
actions: start-eating, end-eating
Busy-chairs start-eating: start-eating-politeness
Free-forks end-eating: end-eating-politeness
; states
states: Busy-forks
Busy-forks:
attributeclass: state
fork valueclass: chair
fork1
fork2
; other information
free-fork ...
}
start-eating <philo>
{end-eating-politeness
Busy-forks chair is-a: transition
pre-net-relations:
(Busy-forks ; chair-philo
(unit <chair> right-fork <right-fork>
left-fork <left-fork> philo <philo>))
chair-philo post-net-relations:
(Free-forks ; left-fork
(unit <left-fork>))
end-eating <philo> (Free-forks ; right-fork
(unit <right-fork>))
}
left-fork
right-fork
Transitions
are clearly separated from the causal conditions on the right hand side (rhs).
Nevertheless, the execution of a transition implies removing the enabling tokens
from the input places and putting tokens in the output places according to the
post-net-relations.
Expressions labeling the arcs are represented in KRON as arc expressions
in pre and postconditions. An arc expression is a specification of restrictions on
objects. These restrictions are represented, in a rule style, by a list of component
pairs: the first component is the specification of a slot name or the string unit
denoting an object instance; the second component, composed by one or two
elements, is a partial pattern to match the slot value, it can be a variable, a
specific constant value, a function or expression or another arc expression.
Following with the behavior representation of the Philosophy-world, the
activity slots leave, intro, start-eating and end-eating, point to the corre-
sponding transitions that represent activities producing state changes. To illus-
trate the internal structure of a typical transition, let us focus on a transition
prototype from the philosophy-world, which is shown in figure 3 and called
start-eating. The value in its pre-net-relations slot is: (Thinking (unit
<philo>)). The first element identifies the state slot Thinking in the dynamic
object. The second one represents the arc expression (unit <philo>) which is
labeling the arc.
KRON variables are identified by angle brackets (e.g., <philo>). As it is
general in rule based systems, variables play a double role:
Some particular features may be used in arc expressions to increase its ex-
pressiveness:
– An arc expression may appear as the second component of another arc ex-
pression. This is a pattern to match with the objects that are stored in the
slot. For example, (see label fork2 in figure 5):
(unit <right-fork> left-chair (unit <chair> philo <philo>))
In this case <philo> is bound to the philosopher that is in the philo slot
366 J.A. Bañares et al.
of the chair stored in the left-chair slot of the fork instance bound to
<right-fork>.
– A function call may appear as the second component of an arc expression.
A function call is represented by a list whose first element is the symbol $,
the second element is the function name, and the rest are the arguments.
Functions may be used in postcondition for dynamic instantiation purposes.
For example, (unit ($ make-philosopher)) may down a new instance of
philosopher.
– To facilitate an incremental model design, KRON allows the use of incom-
plete transitions whose missing variables in preconditions must be provided
by transition synchronization (see section 6). These variables play the role
of parameters of the activities provided by the objects. For example, all ac-
tivities of Chair-Eating-Politeness constitute its interface, and they have
the parameter <philo>.
– The keyword NULL may appear in postconditions. NULL deletes all values
from the slot. For example, (unit <left-chair> right-fork NULL <fk>),
removes all values from slot right-fork before adding the new value bound
to <fk> (label post-left-intro in figure 4). Additionally, a slot value can be
replaced by another value using a list with NULL and the removed values. For
example, (unit <left-chair> right-fork (NULL <fk>) <fj>) removes
the value bound to <fk> from slot right-fork of object <left-chair>,
then it adds the value bound to <fj> to this slot (label post-left in figure
4).
The purpose of previous sections was to explain how the dynamic behavior of
different kinds of entities is described in KRON. In this section we will focus on
the use of inheritance as a mechanism to share code and representation. There-
fore, we have considered the inheritance as a subclassing relation. Subclassing
highlights redundancy within a system and the object-oriented decomposition
yields smaller models through the reuse of common mechanisms, thus providing
an important economy of expression. The subtyping relationship has not been
considered. (Different approaches to formalize the behavior preservation between
parent and descendant classes can be found in [10] and [3]).
KRON: Integration of CPNs with Objects 367
The overall dynamic model will be homogeneous if the dynamic interactions be-
tween dynamic objects are described in the same terms as the internal behavior
of objects. This means that if the interactions are described in terms of places,
transitions and arcs, the behavioral model of the system will be a CPN and the
advantages of using this formal view can be fully assumed. In KRON, the rep-
resentation of interactions between dynamic objects becomes the same problem
as the high level Petri net connections.
philo
philo Philosophy-world#1
Out
Chair-Eating-Politeness#1 Free-chairs
pre-guest post-leave philo
<philo> intro-table <philo> leave
leave-table
intro
post-right-intro
pre-right-intro
post-left-intro
pre-left-intro
post-guest
pre-leave
post-left
pre-fork
pre-left
philo
Busy-chairs
Free-forks
fork Thinking
fork2
fork1
free-fork philo
Eating
chair-philo philo
left-fork
right-fork
and its constraints. This interaction implies the synchronization of the internal
behavior of those objects.
To illustrate the possibilities for dynamic entity connections we will synchro-
nize the instances philosophy-world#1 and Chair-Eating-Politeness#1.(See
figure 6). When a philosopher enters or leaves from the philosopher world,
new relations between chairs, forks, and philosophers are defined. The action
intro-table of Chair-Eating-Politeness#1 implies that a philosopher must
occupy a chair, and the action intro of Philosophy-world must respect the
politeness rules. Therefore these actions must be synchronized. In fact, they
could be considered as partial views of the same activity. The result is a merging
transition that synchronizes the behavior of both dynamic entities. In the same
way, the activity leave of the Philosphy-world must be synchronized with
the activity leave-table of Chair-Eating-Politeness. On the other hand,
it is necessary to have two forks to start eating. Therefore, Philosophy-world
and Chair-Eating-Politenes must synchronize its respective activities start-
eating and end-eating.
To support this approach, the dynamic objects interface in KRON is a set of
activity slots. Thus, the transitions of a dynamic object can be internal or inter-
face transitions. Only the interface transitions can be externally synchronized.
Connections between dynamic objects are established by naming the activity slots
that must be related in some manner. The synchronization mechanism generates
a new merged transition by multiple inheritance of the originals (for a complete
transition merging, additional mechanisms are supported in KRON to specify
the relations between variables from different transitions whose names have local
scope). The transition generated by the merging replaces the originals in all activ-
ity slots involved in the synchronization. It allows the different dynamic objects
related by a synchronization to maintain the same view over a transition after
the merging.
Two types of synchronization (by transition merging) have been designed
for KRON. Normal synchronization substitutes synchronized transitions by a
unique transition with all pre and postconditions of the original ones. However,
a slightly different case arises when a single activity may be synchronized with
several alternative activities, and these other activities can not be synchronized
with one another. This is the place for a bilateral synchronization, which supposes
a replication process.
Some characteristics of the proposed approach for dynamic entity synchro-
nization are:
7 Conclusions
In this paper we have presented KRON (Knowledge Representation Oriented
Nets), a knowledge representation schema for discrete event systems (DESs).
KRON is based on the integration of CPNs with frame based representation
techniques and follows the object oriented paradigm. In addition to the features
generally supported by object oriented languages, a set of primitives implement-
ing the CPN formalism is included. CPNs provide the mechanism to describe
the internal behavior of dynamic entities and the interactions between them.
The Hurried Philosophers example has been adapted to highlight some relevant
KRON capabilities.
Most of the approaches integrating objects and HLPNs, extend the HLPN
formalism. The approach adopted here does not extend the CPN formalism.
The frame-based representation of KRON supports the data and methodological
aspects with no need to extend the CPN formalism. So, all the advantages of
the use of this formalism can be profited from working with KRON.
KRON may reuse models through inheritance and aggregation. On the one
hand, KRON uses inheritance as a mechanism to share code and representation.
On the other hand, aggregation is supported by CPN composition. CPNs may
be connected by merging transitions or places, and by new arcs. In KRON,
transition merging has been selected as the main mechanism to represent the
372 J.A. Bañares et al.
References
1. M. Baldassari and G. Bruno. PROTOB: An object oriented methodology for
developing discrete event dynamic systems. Computer Languages, 16(1):39–63,
1991.
2. J.A. Bañares, P.R. Muro-Medrano, and J.L. Villarroel. Application and Theory
of Petri Nets 1993, chapter Taking Advantages of Temporal Redundancy in High
Level Petri Nets Implementations, pages 32–48. Number 691 in Lecture Notes in
Computer Science. Springer Verlag, 1993.
3. E. Battiston and F. de Cindio. Class orientation and inheritance in modular al-
gebraic nets. In Proc. of IEEE International Conference on Systems, man and
Cybernetics, Le Touquet-France, pages 717–723, 1993.
4. E. Battiston, F. de Cindio, and G. Mauri. Advances in Petri Nets 1988, chapter
OBJSA Nets: a class of high-level Petri nets having objects as domains, pages
20–43. Number 340 in Lecture Notes in Computer Science. Springer Verlag, 1988.
5. B. Baumgarten. Advances in Petri Nets 1988, chapter On internal and external
characterization of PT-net building block behavior. Number 340 in Lecture Notes
in Computer Science. Springer Verlag, 1988.
6. G. Berio, A. Di Leva, P. Giolitto, and F. Vernadat. The m*-object methodology
for information system design in cim environments. IEEE Tran. on Systems, Man,
and Cybernetics, 25(1):68–85, January 1995.
7. J. Billington. Many-sorted high-level nets. In Proc. of Third International Work-
shop on Petri Nets and Performance Models, Kyoto, pages 166–179, 1989.
8. G. Bruno and A. Elia. Operational specification of process control systems: Exe-
cution of prot nets using ops5. In Proc. of IFIC’86, Dublin, 1986.
9. G. Bruno and G. Marchetto. Process-translatable petri nets for the rapid proto-
typing of process control systems. IEEE transaction on Sosftware Engineering,
12(2):346–357, 1986.
10. D. Buchs and N. Guelfi. CO-OPN: a concurrent object oriented petri net approach.
In Proc. of the 12th International Conference on Application and Theory of Petri
Nets, pages 432–454, Gjern (Denmark), June 1991.
11. N. Carriero and D. Gerlenter. Linda in context. Communications of the ACM,
32(4), April 1989.
12. L. Cherkasova, V. Kotov, and T. Rokicki. Applications and Theory of Petri Nets
1993, chapter Modeling of Industrial Size Concurrent Systems, pages 552–561.
Number 691 in Lecture Notes in Computer Science. Springer Verlag, 1993.
KRON: Integration of CPNs with Objects 373
13. S. Christense and N.D. Hansen. Application and Theory of Petri Nets 1994, chapter
Coloured Petri Nets Extended with Channels for Synchronous Communication,
pages 159–178. Number 815 in Lecture Notes in Computer Science. Springer Verlag,
1994.
14. S. Christensen and L. Petrucci. Applications and Theory of Petri Nets 1992, chap-
ter Towards a Modular Analysis of Coloured Petri Nets, pages 113–133. Number
616 in Lecture Notes in Computer Science. Springer Verlag, 1992.
15. A. Dileva and P. Giolito. High-level petri nets for production system modelling.
In Proc. of the 8th European Workshop on Application and Theory of Petri Nets,
pages 381–396, Zaragoza (Spain), June 1987.
16. A. Dileva, P. Giolito, and F. Vernadat. Executable models for the representation
of production systems. In Proc. of the IMACS-IFAC Symposium on Modelling and
Control of Technological Systems, IMACS MCTS 91, pages 561–566, Lille (France),
June 1991.
17. S. English. Coloured Petri Nets for object-oriented modelling. PhD thesis, Univer-
sity of Brighton, 1993.
18. R. Fehling. A concept for hierarchical petri nets with buiding blocks. In Proc. of
the 12th International Conference on Application and Theory of Petri Nets, pages
370–389, Aarhus, 1991.
19. R. Fikes and T. Kehler. The role of frame-based representation in reasoning.
Communications of the ACM, 28(9):904–920, September 1985.
20. T. Holvoet and P. Verbaeten. Using petri nets for specifying active objects and
generative communication. In Object-Oriented Programming and Models of Con-
currency. A workshop within the 17th International Conference on Application and
Theory of Petri Nets, 1996.
21. P. Huber, K. Jensen, and M. Shapiro. Hierarchies in coloured petri nets. In Proc.
of the 10th European Workshop on Application and Theory of Petri Nets, pages
192–209, Bonn, June 1989.
22. Intellicorp. KEE User Guide. Intellicorp, 1989.
23. K. Jensen. Coloured Petri Nets: Basic Concepts, Analysis Methods and Practi-
cal Use. EATCS Monographs on theoretical Computer Science, Springer-Verlag.
Edited by W. Brauer, G. Rozenberg and A. Salomaa, Berlin Heidelberg, 1992.
24. C.A. Lakos. The role of substitution places in hierarchical coloured petri nets, thec-
nical report tr93-7. Technical report, Computer Science Department, University
of Tasmania, August 1993.
25. C.A. Lakos and C.D. Keen. LOOPN++: A new language for object-oriented petri
nets, thecnical report tr94-4. Technical report, Computer Science Department,
University of Tasmania, 1994.
26. S. Matsuoka, K. Wakita, and A. Yonezawa. Research Directions in Object-Based
Concurrency, chapter Inheritance anomaly in object-oriented concurrent program-
ming languages. MIT Press, 1993.
27. B. Meyer. Object-Oriented Software Construction. Computer Science. Prentice
Hall, Englewood Cliffs, N.J., 1988.
28. M. Paludetto and S. Raymond. A methodology based on objects and petri nets
for development of real-time software. In Proc. of IEEE International Conference
on Systems, man and Cybernetics, Le Touquet-France, pages 717–723, 1993.
29. W. Reisig. Theoretical Computer Science 80, chapter Petri Nets and Algebraic
Specifications, pages 1–34. Elsevier Science Publishers B.V., 1991.
30. J. Rumbaugh. Relations as semantic contructs in an object-orientated language.
In Proc. of the ACM Object-Oriented Programming Systems, Languages and Ap-
plications, OOPSLA’87, pages 466–481, October 1987.
374 J.A. Bañares et al.
31. C. Sibertin-Blanc. High-level petri nets with data structures. In Proc. of Workshop
on Applications and Theory of Petri Nets. Finland, June 1985.
32. C. Sibertin-Blanc. Advances in Petri Nets 1994, chapter Cooperative Nets, pages
377–396. Number 815 in Lecture Notes in Computer Science. Springer Verlag,
1994.
33. R. Valette and B. Bako. Software implementation of petri nets and compilation of
rule-based systems. In 11th International Conference on Application and Theory
of Petri Nets, Paris, 1990.
34. J. Vautherin. Advances in Petri Nets 1987, chapter Parallel Systems Specifications
with Coloured Petri Nets and Algebraic Specifications., pages 293–308. Number
266 in Lecture Notes in Computer Science. Springer Verlag, 1987.
Modeling of a Library with THORNs
2
Software Design & Management (SD&M)
Region West · Am Schimmersfeld 7a · D–40880 Ratingen (Germany).
3
Media Service AG (MSG)
Cloppenburger Straße 300 · D–26133 Oldenburg (Germany).
{koester,sonnenschein}@offis.uni-oldenburg.de
1 Introduction
Petri nets allow to model concurrency and conflicts in a simple manner. Modeling
with objects allows the integrated view of values together with operations on it
following the idea of abstract data types resp. data encapsulation; concepts of
inheritance and polymorphism have to be added to this approach to get a fully
object-oriented modeling technique. So it is an obvious idea to model complex
distributed systems by combining the object-oriented approach with Petri nets.
There are three different levels of combining these approaches:
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 375–390, 2001.
c Springer-Verlag Berlin Heidelberg 2001
376 F. Köster et al.
– Objects are modeled by nets, methods and attributes are modeled by sub-
nets. The net for a method models the internal state of an object together
with the control flow of the method. So concurrent data streams within the
execution of a method may be modeled, too. A member of this class of
modeling techniques is GINA [Son93].
In Thorns we distinguish several kinds of places and arcs. Figure 1 shows the
different place structures and arc types together with their graphical represen-
tation.
multiset place 2x standard arc
3z
stack place enabling arc
A place has a name, a type, a capacity, and a structure. The type specifies
the type of objects allowed on the place: all objects have to be of that type or
a type derived (by inheritance) thereof. The capacity specifies an upper bound
for the number of objects the place may hold in a state of the net (an infinite
capacity is possible as well). Finally, the structure (cf. Fig. 1) determines how the
objects on a place are organized, e.g. a queue place stores the objects according
to FIFO principle.
An arc has a name and a type (cf. Fig. 1). Besides standard arcs three
other arc types are provided to connect places and transitions. Enabling arcs
influence the activation of the incident transition equally as standard arcs, but
no object will be consumed at the firing of the transition. Inhibitor arcs disable
the transition if objects reside on the incident place, and consuming arcs do not
affect the activation of a transition, but all objects on the incident place are
removed if the transition fires. Enabling and standard arcs may be labeled with
variable names and arc weights in addition. A variable name is used to reference
objects from the transition’s code (see below). An arc weight models the number
of objects consumed or produced on the incident place by firing of the transition.
Arc weights are allowed only for arcs incident to multiset places.
A further kind of arcs called hyper arcs will be explained in this paper to-
gether with the concept of hierarchy in Thorns.
2.3 Transitions
The transitions of a Thor net play the most important role because they rep-
resent active parts of a model, like processes in a data flow model. Therefore,
each transition is labeled with a name, an activation condition, an action block ,
a delay time function, a firing time function, and a firing capacity.
The activation condition is specified as a boolean expression over variables of
incoming arcs. It has to be fulfilled by preset objects bound to the variables in
order to enable the transition. Activation conditions must not have side effects.
To avoid name conflicts, all variable names of arcs incident to the transition have
to be different.
378 F. Köster et al.
the transitions firing capacity is decremented by one and the required place ca-
pacity on postset places is reserved. Firing of a transition can not be interrupted
or cancelled by other events.
At each moment of a net’s execution one enabled occurrence element starts
firing after another as long as enabled occurrence elements exist, and then in the
same way all occurence elements finish firing one after another. After that time
skips to the next event, which may be the end of a firing or delay time period.
This strategy is called maximum direct firing rule.
The state of a Thorn is defined at each moment of its execution by the set
of stored and reserved tokens on all places, and the current remaining delay time
and firing time of all occurence elements.
2.5 Hierarchy
Thorns combine the two well-known hierarchy concepts of transition refinement
and subnet invocation [Jen92,CK81] and fusion of places that are discussed for
coloured Petri nets in [HJS90]. So Thorns offer a general-purpose mechanism
for dynamic hierarchical structuring of nets. We illustrate this concept on a small
example. Figure 2 shows a calling transition with some border places and the
invoked subnet. The border places are divided into input, output, and share
places connected to the transition by ingoing standard arcs, outgoing arcs, and
undirected hyper arcs (represented by dotted lines), respectively. They are corre-
sponding to places (of equal types) in the called subnet in a one-by-one manner.
Border places of the subnet have a special graphical representation. Enabling,
inhibitor, and consuming arcs have the same effect to calling transitions as to
standard transitions but do not affect the subnet, and their incident places do
not correspond to places in the called subnet.
In this section we discuss techniques for modeling complex systems with Thorns.
First in general, the level of detail/abstraction of a model should be chosen with
respect to its use. Then a more object-oriented or a more functional style of
modeling can be applied.
The more object-oriented modeling approach can follow four steps:
1. Identify the basic kind of objects of the considered system and define accord-
ing C++ classes with appropriate attributes and methods for them. Make use
of object-oriented concepts like encapsulation, inheritance, or polymorphism
in order to achieve reusable, maintainable, and understandable object de-
scriptions.
2. Use places for the storage of objects. Places should represent passive parts
of a model.
3. Describe processes or activities with transitions. Transitions should represent
the dynamic part of model. Hence, they should be used for object manipula-
tion, generation, or deletion by calling their methods in the transition code.
Furthermore, the timing behaviour of a system should be expressed with the
time labels of a transition.
Modeling of a Library with Thorns 381
This attempt starts with identifying classes and objects of the system as
usual for object-oriented analysis (see e.g. [CY91]). If it is a major design goal
to analyse the communication structures within a system, these structures have
to be modeled explicitly. This can also be done by identifying first functional
units that communicate by object exchange. Such a model is a combination of
a data flow model [De 79] with an object oriented method for modeling data.
Within the Thorn model of a library (see next section) we model commu-
nication structures of the system explicitly by the net structure. To do this, it
is necessary to examine the system with respect to the following items:
With this information we are able to reproduce the structure of the system
by using places (passive object holders), transitions (active object manipulators
resp. processes), and edges (for exchanging objects). The temporal behaviour
of the system can be modeled by the delay time and firing time of transitions.
Realization of objects is supported by using C++ to label transitions and to
describe objects. Inheritance and polymorphism are useful to describe objects
and types in a maintainable and understandable manner.
In this section, a fictitious library is used to show how the behaviour of complex
distributed systems can be modeled with Thorns. We discuss only a part of the
complete model extracted from [Kös96]. The part of the model is chosen in a
way that all modeling features of Thorns can be demonstrated.
The library is modeled as a building with floors, a staircase, an information
desk, and an archive. Books in the main library or in one of four external libraries
can be ordered, borrowed and returned by visitors asking clerks for service. One
possible purpose of the model is to identify whether the number of clerks suffices
or if visitors must wait too long for their requests to be granted. The model
description begins with a short overview of the structure and services of the
library. Thereafter, well-chosen subnets and C++ objects are described in more
detail.
The basic structure of the library is determined by one main and four external
libraries (cf. Fig. 3). Within the main library corridors and a staircase connect
382 F. Köster et al.
Main Library External Libraries
External Library
1st Floor
Info. Service
External Library
Staircase
Entrance 2nd Floor
External Library
Book Service 3rd Floor
External Library
three floors and the entrance. The library users may only contact the main
library. Books available at the main library may be borrowed by users. Books
belonging to an external library must be called for by the main library before
they are available there. Library clerks are engaged with lending books, giving
information about books, and rearranging returned books into the shelves of the
library.
After having given a coarse overview of the library, we now describe its mod-
eling as a Thorn. Figure 4 shows the so-called design graph, which is useful
to represent the hierarchical dependencies within a Thorn and which assists in
browsing the net hierarchy within the Thorn editor. The nodes of this graph
represent the different subnets and the edges show dependencies (by transition
refinement) between them.
The subnet LibraryMain represents the whole library. It uses the subnets
Library and ExtLibrary for the main and external libraries. The latter calls
two other subnets to exchange books and information with the main library.
The main library uses subnets for the staircase and the floors, which on their
part use a subnet Go for moving clerks between different floors. In addition the
net Library uses two subnets for providing its services. These two subnets call
Modeling of a Library with Thorns 383
various other subnets to assist them. Especially note that subnet Break is used
from two different subnets.
Only the subnets represented by black nodes will be discussed in in this
paper.
4.1 LibraryMain
Figure 5 represents the main net, which is directly related to the system’s struc-
ture (Fig. 3). The subnet called by Library models the main library while
the subnets called by ExtLibrayi model the external libraries. The transitions
ArriveAt and GoAway model how visitors enter and leave the entrance hall of
the main library. The place Profile contains prototype data used to generate
visitors. Counter is used to save the number of people who left the library. All
other places and the transition File are used to model exchange of books and
requests for information between the main library and external libraries.
All transitions ExternalLibraryi call the same subnet, but the value on Ni
is used as a parameter to the subnet instantiation to distinguish the external
libraries. The places Requi are used for exchange of book and information re-
quests. These places are structured as queues because the requests should be
handled according to a FCFS order. If a request can’t be handled correctly by
any external library it will be put on InfoFail. The places Booki are used to
handle exchange of books. If a book doesn’t belong to any external library it will
be put to place Book and finally, by firing of transition File, to the Archive. If
a book/information request is treated successfully the book/information is put
on DeliveredBooks/Info.
384 F. Köster et al.
In this subnet there are places capable of storing different kinds of objects;
for instance Booki and Book have the type LIB BOOK INF. It is used to store
information on books and is derived from a base class STD BOOK INF, which
contains some standard attributes of books (e.g. title, author, and ISBN). This
information is completed by LIB BOOK INF with information specific to books
inside a library, e.g. the shelf a book belongs to. The places Requi have the
type REQUEST, which is used for book queries and is derived from LIB BOOK INF.
Request specific information is added here.
In the same way classes for visitors (VISITOR) and clerks (CLERK) are im-
plemented. They are derived from a common base class PERSON, which contains
several attributes for a person (e.g. his name). VISITOR and CLERK define addi-
tional attributes and redefine some virtual methods of PERSON in a visitor/clerk
specific way. These classes will be discussed in more detail below.
4.2 Library
In Fig. 6 the subnet called by transition Library in Fig. 5 is shown. It models
the main library. There is a direct mapping from the system’s structure to net
elements (cf. Fig. 3).
Within this subnet there are six refined transitions. The subnets called by
transitions InformationService and BookService model how visitors are sup-
ported by staff in getting books or information, respectively — below we will
discuss BookService in detail. The refined transition Staircase calls a subnet
which models a staircase. This subnet enables clerks to change their location
between entrance (Entrance) and the three floors (Ei, TheistFloor). This part
of the model can be used for describing path length of clerks walking through
the library, but this will not be discussed in this paper.
Modeling of a Library with Thorns 385
4.3 BookService
In Fig. 7 the subnet called by BookService in Fig. 6 is presented, which models
interactions between visitors of the library and clerks.
The share places Entrance, BookList, DeliveredBooks, and Booki have
already been described above (cf. Fig. 6). The transition 96hrs is a transition
with a delay time of 96 hours, which fires if a book isn’t fetched by a visitor within
96 hours after its delivery from an external library. In this case the book is sent
386 F. Köster et al.
class PERSON {
public:
virtual double Velocity() { return Normal(6 − 0.2 * NumberOfBooks, 1) };
// in m/s; person is the slower the more books he carries
private:
int NumberOfBooks;
void PutOnTrolley(LIB_BOOK_INF*);
// put books (class LIB_BOOK_INF) on trolley
private:
bool TrolleyAttr;
// true if clerk has trolley
Transition StaffEntry models a clerk’s way behind the counter. It uses the
condition code {typeid(in).name() == ‘‘CLERK"} to determine that only peo-
ple may go to place Behind Counter, which have type CLERK. Here the run-time
type information of an object is used explicitly to maintain compatibility of ob-
ject and place types. Transition LoadTrolley will omitted here for reasons of
simplicity.
4.4 SortBooks
The transition SortBooks in Fig. 7 is an example of a calling transition with
only a partial production of objects on postset places. The corresponding subnet
is shown in Fig. 10. Border places Behind Counter, ReturnedBooks, Booki, and
MainLibrary already were described above. Transition IsBack modifies some
attributes of a book to mark this book as returned. After this, the book is put
on place Sort though transitions Toi and ToMain get enabled. One of these
transitions fires dependently on the attributes of the books. Firing of one of
these transitions yields the production of a token on place Okay, which causes
firing of the stop transition and hence termination of the net (cf. Sect. 2).
5 Conclusion
Thorns have been shown to be an appropriate object-oriented modeling ap-
proach for distributed systems. They combine the object-oriented features of
C++ to model data with various features of Petri nets for modeling hierarchy,
concurrency and time for processes. Thorns can be compiled to C++ code that
can be executed by a sequential or distributed simulator. All features (except
388 F. Köster et al.
References
1 Introduction
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 391–405, 2001.
c Springer-Verlag Berlin Heidelberg 2001
392 T. Basten and W.M.P van der Aalst
object and the method calls that cause a transition from one state to another.
Looking at the definition of inheritance in, for example, OOD and its informal
explanation, a subclass that inherits features of some other class extends the
static structure as well as the dynamic behavior of its parent class. However,
in the further treatment of inheritance, OOD only defines inheritance of static
features. It does not specify the meaning of inheritance of dynamic behavior. It is
implicitly assumed that the behavior of a subclass is an extension of the behavior
of its superclass. OOD does not further elaborate on the precise meaning of
“extension.”
In this paper, we use Petri nets (See for example [11]) for specifying the dy-
namics of an object class. There are several reasons for using Petri nets. First of
all, Petri nets provide a graphical description technique which is easy to under-
stand and close to state-transition diagrams. Second, concurrency and synchro-
nization are easy to model in terms of a Petri net. Third, many techniques and
software tools are available for the analysis of Petri nets. Finally, Petri nets have
been extended with data (color), time and hierarchy [8,9]. The extension with
data allows for the modeling of attributes and methods. The extension with time
allows for the quantification of the dynamic behavior of an object. The hierarchy
concept can be used to structure the dynamics of an object class.
In the Petri-net framework, we formalize what it means for an object life
cycle to extend another life cycle. The results presented here are based on two
earlier papers. In [3], inheritance of dynamic behavior is studied in terms of a
simple process algebra. We believe that the essence of inheritance of dynamic
behavior consists of blocking and hiding method calls, two notions which are well
investigated in process algebra. In [1], the results from [3] are translated to Petri
nets. In the current paper, we do not repeat all the obtained results. We restrict
ourselves to the basic definitions concerning life-cycle inheritance and an informal
explanation of some important results, being four transformation rules that allow
designers to construct subclasses from some given superclass in a straightforward
way. The main contribution of this paper is that it shows the validity of our
approach by means of a small case study. The concepts as defined in this paper
are applied to the development of a groupware editor. The results show that
life-cycle inheritance stimulates the reuse of life-cycle specifications. A detailed
study of the notion of inheritance of dynamic behavior, further elaborating on
the results of [1,3] and the current paper, has appeared in [2].
The remainder of this paper is organized as follows. Section 2 introduces the
notions of an object life cycle and inheritance of life cycles. Section 3 presents
several inheritance-preserving transformation rules on object life cycles. In Sec-
tion 4, the results are applied to the development of a groupware editor. Finally,
Section 5 ends with some concluding remarks.
Place/Transition nets. In this paper, we use a specific class of Petri nets known
as Place/Transition nets or simply P/T nets. Let A be some universe of action
Inheritance of Dynamic Behavior 393
Some place p is called an input place of a transition t if and only if there exists a
directed arc from p to t. Place p is called an output place of t if and only if there
exists a directed arc from t to p. We use •t to denote the set of input places for
a transition t. The notations t• , •p, and p• have similar meanings.
The following definition introduces a property of P/T nets that is useful
in the definition of object life cycles. The reflexive and transitive closure of a
relation R is denoted R∗ ; the inverse of R is denoted R−1 .
Places of a P/T net may contain zero or more tokens. The state or marking of a
net is the distribution of tokens over the places. A marking is represented by a
finite multi-set, or bag, of places. The following notations are used for bags. For
the explicit enumeration of a bag, a notation similar to the notation for sets is
used, but using square brackets instead of curly brackets and using superscripts
to denote the cardinality of the elements. To denote individual elements of a
bag, the same symbol “∈” is used as for sets. The sum of two bags X and Y is
denoted X + Y ; the difference of X and Y is denoted X − Y .
Definition 3 (Marked P/T net). A marked P/T net is a pair (N, s), where
N is a labeled P/T net (P, T, F, ) and where s is a bag over P denoting the state
of the net.
Marked P/T nets have a dynamic behavior which is defined as follows. A transi-
tion is enabled if and only if each of its input places contains at least one token.
An enabled transition can fire. If a transition fires, then it consumes one token
from each of its input places; it produces one token for each of its output places.
The visible effect of a firing is the label of the transition.
Definition 4 (Firing rule). Let (N, s) be a marked P/T net with N equal
to (P, T, F, ). For any enabled transition t ∈ T , the firing of t is denoted
(N, s) [(t) (N, s − •t + t• ).
Since we are interested in comparing object life cycles, which are specified by
P/T nets, it is necessary to have an equivalence for P/T nets. Nets with the same
external behavior, but with possibly different silent behavior must be considered
equal. For this purpose, branching bisimilarity is a suitable equivalence [7]. In this
paper, the details of the definition of branching bisimilarity are not important
and, hence, omitted. The reader is referred to [1].
Object life cycles. Using P/T nets for specifying object life cycles allows us to
specify a partial ordering of method calls. However, not every labeled P/T net
specifies a life cycle. A life cycle is a net having exactly one initial or input place
i. It also has a unique initial transition tcr which corresponds to the creation of
an object. A life cycle refers to a single object. It suffices to consider just one
object because multiple objects of the same class interact via the execution of
methods and not directly via the life cycle. Since we focus on one object at a
time, initially, place i contains a single token.
An object life cycle must also have a unique final or output place o. An object
terminates when, and only when, it reaches the marking consisting of a single
token in o. In addition, if a marking has a token in o, it must be the only token
in the marking. This means that upon termination of an object, all information
about the object is removed. Furthermore, we assume that it is always possible
to terminate. However, this does not mean that an object is forced to terminate.
A final requirement of a life cycle is that it is connected. Given the other
requirements, it simply makes no sense to add unconnected parts to a life cycle.
The following definition formalizes the notion of an object life cycle.
Definition 6 (Object life cycle). Let (N, s) be a marked Aτ -labeled P/T net,
where N equals (P, T, F, ). Let s be any marking reachable from s. (N, s) is an
object life cycle if and only if the following conditions are satisfied.
i) Object creation: P contains a place i and T a transition tcr such that •i = ∅,
i• = {tcr }, and •tcr = {i};
ii) Single-object requirement: s = [i];
iii) Object termination: P contains a place o such that o• = ∅; furthermore, if
o ∈ s , then s = [o];
iv) Termination option: (N, s ) [∗ (N, [o]);
v) Connectedness: N is connected.
Figure 1 shows the, very simple, life cycle of a class person. A person comes
into existence when he or she is born. While alive, a person may celebrate his or
her birthday. Eventually, a person dies.
Inheritance of Dynamic Behavior 395
birth
birthday
death
person
o
In other words, (N1 , [i]) is a subclass of (N0 , [i]) if the observable behaviors of
(N1 , [i]) and (N0 , [i]) are equivalent when methods of N1 which are not present
in N0 are blocked.
The second basic concept is the concept of hiding method calls. Hiding a
method call means that it is no longer observable. The notion of hiding inspires
another definition of inheritance.
If it is not possible to distinguish the external behavior of (N0 , [i]) and (N1 , [i])
when arbitrary methods of N1 are executed, but when only the effects of
methods that are also present in N0 are considered, then (N1 , [i]) is a subclass
of (N0 , [i]).
This means that (N1 , [i]) is a subclass of (N0 , [i]) if the observable behaviors of
(N1 , [i]) and (N0 , [i]) are equivalent when hiding methods of N1 which are not
present in N0 .
The subtle difference between the two forms of inheritance is that in the
second definition methods new in N1 are executed without taking into account
their effect, whereas in the first definition they are not executed at all. Below,
we give an example to illustrate this difference.
To formalize inheritance of life cycles, the notions of blocking and hiding
method calls must be translated to P/T nets. The technical terms for blocking
and hiding actions are borrowed from process algebra, where they are called
encapsulation and abstraction, respectively (see also [3]). Note that, in this paper,
these two terms have a more specific meaning than usual in object-oriented
design.
396 T. Basten and W.M.P van der Aalst
Definition 8 (Life-cycle inheritance). Let (N0 , [i]) and (N1 , [i]) be two object
life cycles; let A be the set of observable method identifiers. Life cycle (N1 , [i]) is
a subclass of life cycle (N0 , [i]) under life-cycle inheritance if and only if there
exist disjoint H ⊆ A and I ⊆ A such that τI ◦ ∂H (N1 , [i]) is branching bisimilar
to (N0 , [i]).
divorce
death death divorce
o o
person1 person2
death death
o o
person3 person4
Class person4 extends class person1 with both methods stay single and
divorce. In this example, the combination of encapsulation and abstraction is
needed to show that person4 is a subclass of person1.
It is possible to show that object life cycles can only have finitely many states. In
Petri-net terminology, they are bounded [1]. This implies that checking branching
bisimilarity between life cycles is decidable. However, in practical applications,
it can be a complex and tedious task. Therefore, this section presents several
inheritance-preserving transformation rules. These rules can be used to design
subclasses of some given class, thus, supporting reuse of life-cycle specifications.
Moreover, they show the essence of life-cycle inheritance. In this paper, we only
give an informal explanation of the transformation rules. Formal definitions can
be found in [1]. In [2], inheritance-preserving transformation rules are studied in
more detail. In particular, attention is paid to developing a set of transformation
rules that is effective in practical design situations.
Let Nq be a P/T net such that (Nq , [i]) is an object life cycle. Figure 3 shows
four inheritance-preserving transformation rules transforming Nq into a subclass.
For the sake of simplicity, we require that the result of each transformation is
again an object life cycle.
The first transformation rule, for reasons explained in [3] called P T , can be
formulated as follows. The alphabet of a P/T net denotes the set of all transition
labels occurring in the net which are not equal to τ .
i i
b0
b1
Nq Nq
Np Nr
PT o PP o
i i
Nq Nq
p
Nr
Nr
P J3 o P J1 o
not appear in the alphabet of Nq and is not equal to τ , then the union of Np
and Nq is a subclass of Nq .
The above transformation rule means that it is allowed to add a choice, or a new
branch of behavior, to an existing object life cycle. In the example of Figure 3,
it is crucial that methods b0 and b1 do not occur in the alphabet of Nq . It is not
difficult to see that blocking b0 and b1 leads to a net whose behavior is equivalent
to the behavior of Nq . Methods b0 and b1 act as so-called guards, separating the
subclass extension from the original life cycle. In the example of Figure 2, the
extension of class person1 with method stay single resulting in class person2
is captured by transformation rule P T .
The second rule shown in Figure 3, called P P , is a special case of P T showing
that P T captures a simple form of recursion. Rule P P states that it is possible
to extend an existing class with an iteration. Under certain assumptions about
the net Nr , it preserves a more restricted form of inheritance than P T does
(see [1,2] for details).
The third transformation rule, called P J3 shows that it is possible to add
parallel behavior to an object life cycle.
If Nr is a P/T net such that i) no places are shared between Nq and Nr , ii) all
transitions of Nr have a label which does not appear in the alphabet of Nq and
iii) transitions in Nq with input places in Nr obey the free-choice property,
then the union of Nr and Nq is a subclass of Nq .
The second requirement means that only new methods are used in the extension
of the original life cycle. This means that hiding the new methods yields a
Inheritance of Dynamic Behavior 399
behavior equivalent to that of the original life cycle. The third requirement is
needed for the correctness of the transformation rule. In most practical examples,
such as the examples in the next section, it is satisfied. An introduction to the
free-choice property and the class of free-choice Petri nets can be found in [5].
The fourth and final transformation rule, P J1, shows that it is possible to
insert behavior in between two parts of the original life cycle.
If Nr is a net such that i) Nq and Nr share exactly one place p and one
transition t with (t, p) in the flow relation of Nq , ii) all transitions of Nr other
than t have a label which does not occur in the alphabet of Nq , and iii) Nr
satisfies certain requirements with respect to liveness, boundedness, and the
free-choice property, then the union of Nq and Nr without the arc (t, p) is a
subclass of Nq .
Introduction. In this section, the concepts developed in the previous sections are
applied to the development of a groupware editor. We do not give full specifi-
cations of the classes involved, but focus on the object life cycles. This means
that we do not specify data types, class attributes, or method implementations.
If necessary, an informal explanation is given.
The requirements for the groupware editor are as follows. The editor is meant
to edit some kind of diagrams. Multiple users, possibly situated at different
workstations, may be editing a single diagram in a joint editing session. Users
may choose to either view or edit a diagram. They may join or leave a session at
will. It must be clear to all users who is currently editing some given diagram. The
diagrams under consideration may be complex, possibly consisting of multiple
components. Components may introduce hierarchy in a diagram. It is possible
to open or close a component revealing or hiding its details. Not just any user
400 T. Basten and W.M.P van der Aalst
may view or edit any component in a diagram. Users must have permission to
do so. Permissions are not fixed; to get permission, a user can simply select
a component and then try the desired command. If there are no conflicting
permissions, the command succeeds; otherwise, it fails and the user is notified.
Users may explicitly surrender permissions. Most permissions are automatically
reset if the user leaves the editing session; a few permissions may persist between
sessions.
In the next paragraphs, life-cycle inheritance is used to design a groupware
editor satisfying the abovementioned requirements. The development is split into
three steps. First, a groupware viewer is designed. The design is fairly simple
and the resulting system allows multiple users to view existing diagrams. Second,
the viewer is transformed into a multi-user editor by adding editing functions
to classes in the viewer design. Third, the multi-user editor is specialized to
a groupware editor by adding permissions. The example shows how life-cycle
inheritance can be used to structure an object-oriented design process. It also
shows how object life cycles can be reused in a design.
The multi-user viewer. In the design of the viewer, four classes can be distin-
guished: user, diagram, user session, and edit session. The first two classes
have straightforward interpretations. The third and fourth class are intended
to structure viewing sessions. An edit session object keeps track of all users
viewing a particular diagram; an object of class user session maintains all data
involved in a particular session of a particular user. Figure 4 shows the life cycles
for objects of the above four classes.
i o
cru delu i
crd
join leave
view
i i
join
join
join brdcst
view
Users can be created (cru) or deleted (delu). This means that they are added
to or removed from the list of users of the viewer. Once a user exists, (s)he may
join and leave editing sessions. If the user participates in at least one edit session,
(s)he may issue view commands in order to view diagrams. It is not difficult to
see that user satisfies the requirements of an object life cycle (Definition 6).
Class diagram has a straightforward life cycle. Diagrams can be created (crd),
viewed (view), and deleted (deld). A user interacts with a diagram through a
user session object. Upon joining an editing session, a new object of class
user session is created. The only possible command a user can execute is the
view command. If the user leaves the editing session, the user session object
is terminated.
Objects of class edit session keep track of all users involved in a single
session. The first user that “joins” an editing session for some diagram, actually
creates a new edit session object. If other users join a running session, this
does not lead to the creation of a new object. The information is simply stored
in the existing object. To fulfill the requirement that all users must know who
is participating in the session, we assume that the implementation of join is
such that the new user gets a list of users already present. Furthermore, the
information about a new user is broadcast (brdcst) to all other users participating
in the session. When a user leaves, this information is broadcast to all remaining
users. The last user leaving the session terminates the edit session object.
In a complete implementation of a system, it is clear from the code which
methods interact with each other. Since we do not give method implementations,
we make a few assumptions. First, user methods invoke methods with the same
label in user session, which, in turn, invoke methods of the same name in
edit session and diagram. Second, methods which do not have counterparts in
one of the other classes are assumed to interact with (objects in) the environment.
Examples are cru, delu, crd, deld, and brdcst.
i o
cru delu
p0 i
crd
crd join leave
view mod
p1
deld join leave
deld
user e
mod chmd diagram e
view o
i
chmd
join
q0 q1
view view mod
leave
user session e chmd
o
leave
Class user has been extended to class user e. Since we are developing an
editor, users of the system are now responsible for creating and deleting dia-
grams. Creation and deletion of diagrams can be done independently of editing
(other) diagrams. This means that we added parallel behavior to the life-cycle of
user objects. It follows from rule P J3 that the addition of place p0 and methods
crd and deld yields a subclass of user. A second addition is that users can now
modify diagrams. For this purpose, method mod has been added. Users have
to choose whether they want to modify a diagram or whether they are satisfied
with just the option to view it. Method chmd (change mode) can be used to tog-
gle between viewing and editing mode. The implementation of mod and chmd
can be such that only a subset of the users is allowed to enter editing mode. It
simply follows from applying transformation rule P P that the addition of meth-
ods mod and chmd to class user leads to a subclass. Therefore, the subsequent
application of rule P J3 and rule P P yields that user e is a subclass of user.
For each editing session a user joins, a user session e object is created. This
object keeps track of the mode in which the user is for this particular diagram.
Initially, the user is in viewing mode. By invoking method chmd the user can
change to editing mode. This means that we have extended the life cycle of
user session objects with a choice. Transformation rule P T can be applied to
show that user session e is a subclass of user session. Method chmd acts as
the guard.
Summarizing, in this paragraph, we have applied three of the four transfor-
mation rules given in Section 3 to extend the viewer of the previous paragraph
Inheritance of Dynamic Behavior 403
to an editor. What is important is that we have reused the specifications for the
object life cycles of the viewer in the design process.
cmmt cmmt
rstp rllbck brdcst
deld leave
leave
o o
It remains to be shown that the new classes are subclasses of the correspond-
ing classes in the earlier designs. The addition of method rstp to classes user e
and user session e is captured by transformation rule P P . Hence, user p and
user session p are subclasses of classes user e and user session e, respec-
tively.
The addition of rstp to diagram e is also captured by rule P P . Applying
rule P J1 three times shows that the addition of cmmt to diagram e preserves
life-cycle inheritance. To show that the addition of rllbck preserves inheritance,
consider the intermediate result obtained after the previous additions. The de-
sired result now follows easily from transformation rule P T . Hence, diagram p
is a subclass of diagram e and, therefore, also of diagram.
To show that edit session p is a subclass of edit session, we have to
apply rule P J1 twice simultaneously.
5 Concluding Remarks
References
2. T. Basten. In Terms of Nets: System Design with Petri Nets and Process Algebra.
PhD thesis, Eindhoven University of Technology, Department of Mathematics and
Computing Science, Eindhoven, The Netherlands, December 1998.
3. T. Basten and W.M.P. van der Aalst. A Process-Algebraic Approach to Life-
Cycle Inheritance: Inheritance = Encapsulation + Abstraction. Computing Science
Report 96/05, Eindhoven University of Technology, Department of Mathematics
and Computing Science, Eindhoven, The Netherlands, March 1996.
4. G. Booch. Object-Oriented Analysis and Design: With Applications. Ben-
jamin/Cummings, Redwood City, CA, USA, 1994.
5. J. Desel and J. Esparza. Free Choice Petri Nets, volume 40 of Cambridge Tracts
in Theoretical Computer Science. Cambridge University Press, Cambridge, UK,
1995.
6. M. Fowler and K. Scott. UML Distilled: Applying the Standard Object Modeling
Language. Addison-Wesley, Reading, Massachusetts, USA, 1997.
7. R.J. van Glabbeek and W.P. Weijland. Branching Time and Abstraction in Bisim-
ulation Semantics (extended abstract). In G.X. Ritter, editor, Information Process-
ing 89: Proceedings of the IFIP 11th. World Computer Congress, pages 613–618,
San Fransisco, California, USA, August/September 1989. Elsevier Science Publish-
ers B.V., North-Holland, 1989.
8. K.M. van Hee. Information Systems Engineering: A Formal Approach. Cambridge
University Press, Cambridge, UK, 1994.
9. K. Jensen. Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical
Use, volume 1, Basic Concepts. EATCS monographs on Theoretical Computer
Science. Springer, Berlin, Germany, 1992.
10. C. Lakos. From Coloured Petri Nets to Object Petri Nets. In G. De Michelis and
M. Diaz, editors, Application and Theory of Petri Nets 1995, 16th. International
Conference, Proceedings, volume 935 of Lecture Notes in Computer Science, pages
278–297, Torino, Italy, June 1995. Springer, Berlin, Germany, 1995.
11. W. Reisig. Petri Nets: An Introduction, volume 4 of EATCS monographs on The-
oretical Computer Science. Springer, Berlin, Germany, 1985.
12. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-
Oriented Modeling and Design. Prentice-Hall, Englewood Cliffs, NJ, USA, 1991.
Object Coloured Petri Nets –
A Formal Technique
for Object Oriented Modelling
1 Introduction
Object Oriented Modelling can be divided into two parts: modelling the static
structure and modelling the dynamic aspects of a system. Class diagrams are
the main technique to describe the structure of a system, i.e. the classes and
their relationships. The dynamic aspects are mode-led with techniques like State
Charts, Message Trace Diagrams or Object Interaction Diagrams (see for exam-
ple [13,4,15,18]).
But while class diagrams are well understood, the techniques for dynamic
aspects have two disadvantages. First, they lack a formal semantics like that of
Petri nets. This often leads to ambiguous models and thus problems with the
transition from analysis to design and implementation. The second major draw-
back of these techniques is their lack of appropriate means to model concurrency.
Consider for instance the Concurrent Object Interaction Diagram technique, pro-
posed by Rumbaugh in [14], which falls far short from the expressive power of
Petri nets.
We propose Object Coloured Petri Nets (OCP-Nets) to supersede the afore-
mentioned techniques. OCP-Nets are an object oriented Petri net formalism,
based on Coloured Petri Nets (CPN) [9] enhanced by the fusion place concept of
Hierarchical Coloured Petri Nets (HCPN).1 OCP-Nets have a formal semantics
1
In the rest of the paper, the signature of CPN as defined by Jensen in [9] is used. If
not otherwise stated, the meaning is equal or similar to that in [9].
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 406–427, 2001.
c Springer-Verlag Berlin Heidelberg 2001
OCP-Nets – A Formal Technique for Object Oriented Modelling 407
x tok
push
elem pushOK
INT UNIT
xs x::xs
stack
INT LIST
completing the service, the token tok is sent to the calling class net via the OUT-
transition push(). The parameters are listed inside the brackets. The shortcut
push() is used instead of push(tok).
x x tok tok
push(x) push push()
IN OUT
elem pushOK
INT UNIT
xs x::xs
stack
INT LIST
The next example illustrates the two other types of communication transi-
tions: INV- and REC-transitions. Fig. 3 shows a piece of a class net that calls
the service push. An INV-transition (invoke) calls a service in a class net by
sending it one or more tokens as parameters. In contrast, the result of a call
is received via a REC-transition (receive). Since there may be more than one
instance of the class net stack, an unique identifier is assigned to each object
net. The type of the identifiers is OID. The class net shown stores the identifier
of its stack in the place myStack and uses this identifier to call the service with
the INV-transition id.push(y). After the call, the net may perform some actions,
depicted by a dotted line, until the service is completed.
3 Static Structure
We will now present the formal definition of the static structure of an OCP-Net.
An OCP-Net is a set of class nets together with global fusion places and channel
definitions for communication. First, the definition of a class net is given and
after this the definition of an OCP-Net.
OCP-Nets – A Formal Technique for Object Oriented Modelling 409
elem y
id.push(y)
INT
INV
id
myStack
OID
id
pushOK tok
id.push(y)
UNIT
REC
(c) Normal places are differentiated from communication places and must
all be pairwise disjoint. In addition, a communication place of type IN
must not have an incoming arc and must be connected with exactly
one transition of type IN. Similar restrictions are given for the other
communication places.
(d) The node, colour, guard and expression functions are defined as for CP-
Nets.
(e) The initialisation function is defined as for CP-Nets. Communication
places must not have an initial marking.
(ii) T N assigns a service name to every communication transition of type IN
and OUT. The set of service names is denoted by M ID.
(iii) T T assigns a type to every communication transition of type IN and OUT.
This is the type of the parameters of an IN transition and of the result of
an OUT transition.
(iv) The instance fusion sets correspond to attributes of a class.
The set of global fusion places used for asynchronous communication is called
Pcom . It is defined as follows for an OCP-Net consisting of n class nets:
n
n
n
n
Pcom = ( Pini ) ∪ ( Pouti ) ∪ ( Pinvi ) ∪ ( Preci )
i=1 i=1 i=1 i=1
The set of all communication transitions is named Tcom and defined as follows:
n
n
n
n
Tcom = ( Tini ) ∪ ( Touti ) ∪ ( Tinvi ) ∪ ( Treci )
i=1 i=1 i=1 i=1
Definition 2. OCP-Net
An OCP-Net is a tuple OCP N = (CN S, CS, CF, CLN, root) with
(i) CN S being a set of class nets CNi , 1 ≤ i ≤ n. ∀CNi , CNj ∈ CN S :
CNi = CNj ⇒ (PCNi ∪ TCNi ∪ ACNi ) ∩ (PCNj ∪ TCNj ∪ ACNj ) = ∅.
continued
OCP-Nets – A Formal Technique for Object Oriented Modelling 411
(iii) The global fusion places are used for asynchronous communication. Only
communication places may be included in CF . All communication places
are a member of a global fusion set.
(iv) CLN assigns every class net a unique name that is used by the function new
to instantiate an object net.
(v) root denotes the class nets from which an object net is instantiated at the
start of an execution.
Expr(t, #, ch) = {(expr, (s, r)) | (expr, (s, r), #, ch) ∈ CE(t)} (2)
In this section the differences between the static and dynamic structure of OCP-
Nets are explained. In addition, the asynchronous and synchronous way of com-
munication are described including the extensions to the enabling rule of CP-
Nets necessary for channel expressions.
as2 bs2
at1 bt1
UNIT UNIT
to add new instances while executing an OCP-Net. The execution starts with
creating an instance of a specific class net, called the root net. The creation of
an object net is now illustrated using the two class nets in figure 4. It shows
two class nets, A and B. Net A always creates a new instance of B when tran-
sition at2 occurs. The function new evaluates to the identifier of the created
object net. The initial marking of both nets is given inside the places. Net A
is the root net. The static net structure, omitting the complete arc definitions,
colours etc., is given by P = {as1, as2, as3, bs1, bs2}, T = {at1, at2, bt1, bt2} and
A = {as1T Oat2, . . .}. Now to execute the system, an instance of the root net A
is created with identifier 13 leading to the following simulation structure with P I
denoting the place instances, T I the transition instances, AI the arc instances
and M the current marking.
(i) P I = {(as1, 1), (as2, 1), (as3, 1)}
(ii) T I = {(at1, 1), (at2, 1)}
(iii) AI = {(as1T Oat2, 1), . . .}
(iv) M = 1‘((as1, 1), tok)
The elements of the simulation structure are tuples which consist of the name
of the element and the object net identifiers. After instantiating root net A the
execution can begin with the occurrence of transition at2 creating an instance
of B with identifier 2. This leads to the following simulation structure.
(i) P I = {(as1, 1), (as2, 1), (as3, 1), (bs1, 2), (bs2, 2)}
(ii) T I = {(at1, 1), (at2, 1), (bt1, 2), (bt2, 2)}
(iii) AI = {(as1T Oat2, 1), . . . , (bs1T Obt2, 2), . . .}
(iv) M = 1‘((as2, 1), tok) + 1‘((as3, 1), 2) + 1‘((bs1, 2), tok)
The identifier 2 can now be used by the instance of A to access the new in-
stance of B. An existing object net may be deleted from the simulation structure
by the function del which removes all elements of the corresponding identifier.
Note, new and del are not methods of a class net but defined globally.
3
Instead of the global identifier 1 a tuple consisting of the class name and a local
counter could be used (see [12]).
414 Ch. Maier and D. Moldt
CF CF
pushIN pushOUT
OIDS*INT c c OIDS*UNIT
sender
((c,self),x) OID ((self,c),tok)
x x tok tok
push(x) push push()
IN OUT
elem pushOK
INT UNIT
xs x::xs
stack
INT LIST
Note that the service push as shown in figure 5 may be used by more than
one calling net at the same time. This point will be addressed in section 7.1.
The calling net from figure 3 is extended in the same way as shown in figure
6. The rest of the calling net is indicated by dotted lines. The calling net may
invoke the service push by placing a token on place pushIN consisting of its own
identifier sel f, the identifier of the called net id and the parameter y. Only the
called net with identifier id may withdraw this token from pushIN and perform
OCP-Nets – A Formal Technique for Object Oriented Modelling 415
the service, placing the result on its place pushOUT. The net that has invoked
the service may then withdraw the resulting token from pushOUT. Again, the
arc inscription ((c,sel f ),tok) of the calling net ensures that only this net can
withdraw the result token. Note that sel f in figure 5 indicates the identifier of
the called net while in figure 6 it indicates the identifier of the calling net.
CF
elem y ((self,id),y) pushIN
id.push(y)
INT OIDS*INT
INV
id
myStack
OID
id
CF
pushOK tok ((id,self),tok) pushOUT
id.push(y)
UNIT OIDS*UNIT
REC
c c
sender
OID
x x tok tok
push(x) push push(tok)
IN OUT
elem pushOK
(x, (c,self), IN, push) INT UNIT (tok, (self,c), OUT, push)
xs x::xs
stack
INT LIST
The according extensions to the calling net for synchronous communication are
shown in figure 8.
myStack
OID
id
(tok, (id,self), REC, push)
pushOK tok
id.push(y)
UNIT
REC
The first part of Def. 3 is the same as for Hierarchical CP-Nets to incorpo-
rate the fusion places. The second part is the extension used for synchronous
communication. This will be illustrated by an example using the nets shown in
figure 7 and figure 8. Let us assume that the identifier of the net offering the
service push is idRec and the identifier of the calling net is idSend. The calling
net wants to send a token on place elem with value 100 to its stack. The stack
itself is empty so far. Thus, the current marking is given by
OCP-Nets – A Formal Technique for Object Oriented Modelling 417
5.1 Inheritance
Inheritance is an important mechanism of object oriented programming as it
allows for reuse and polymorphism. Wegner distinguishes two basic ways of in-
heritance: subtyping and subclassing (see [17]). Using subtyping the subtype is
compatible with its supertype which means it can be used in every context the
supertype is used. This leads to the contravariant style of function declaration. A
subtype may override a function of its supertype if its arguments are supertypes
of the arguments of the supertypes function. Subclassing leads to the covariant
style of function declaration. A subclass may override a function of its superclass
if its arguments are subclasses of the arguments of the superclass. Both options
have their advantages. Subclassing allows for a more extensive reuse of existing
code while subtyping is somehow safer because a subtype may be used in every
context the supertype is used.
OCP-Nets use subtyping because it allows for a more secure and thus ro-
bust computing. The subtype relation can be described using the notion of an
interface. In [6] an interface is described in the following way.
Every operation declared by an object specifies the operations name, the
objects it takes as parameters, and the operations return value. This is
known as the operations signature. The set of all signatures defined by
an object’s operations is called the interface of the object. [6, S.13]
418 Ch. Maier and D. Moldt
The interface of an object therefore specifies all operations an object can perform.
The relation between the interface of an object and its type is characterised as
follows:
A type is a name used to denote a particular interface. We speak of
an object as having the type “Window” if it accepts all requests for the
operations defined in the interface named “Window”. An object may
have many types, and widely different objects can share a type. . . . We
say that a type is a subtype of another if its interface contains the
interface of its supertype. Often we speak of a subtype inheriting the
interface of its supertype.
[6, S.13]
The signature of a service of a class net is defined by the service name, the pa-
rameter type of the IN transition and the resulting type of the OUT transition
(see functions T N an T T in Def. 1). For example, the push service in figure 2
has the signature (push, INT, UNIT). If a service has only an IN and no OUT
communication transition the result type is EM P T Y . For example, a push ser-
vice without confirmation would have the signature (push, INT, EMPTY). The
interface of a class net is then defined as the set of all signatures of its services.
This leads to the following subtype definition with SIG denoting the signature
of a service and ITC denoting the interface of a class net.
Definition 4. Subtype-Relation
A class net CNA is a subtype of a class net CNB , denoted by CNA <:CNB , if:
∀SIGsuper ∈ IT CB : ∃SIGsub ∈ IT CA ,
SIGsuper = (namesuper , argsuper , resultsuper ),
SIGsub = (namesub , argsub , resultsub ) thus that:
(i) namesuper = namesub .
(ii) argsuper ⊆ argsub .
(iii) resultsuper = resultsub .
This definition states that for every signature in the supertype there must be
one in the subtype with the following conditions: the name of both services must
be the same, the arguments of the supertype service must be a subtype of the
arguments of the subtype service and the result type must be the same. Then a
class net is called a subtype of another class net. Note that this definition allows
a class net to be the subtype of more than one supertype.
5.2 Encapsulation
OCP-Nets already provide for encapsulation because places of a net can only
be accessed via services provided by the net. In addition, a private service, used
by the net for internal computation, can also be protected from improper ac-
cess in an easy way (see Figure 9). This net offers a public service mthPublic
which in turn uses a private service mthPrivate. This private service is protected
OCP-Nets – A Formal Technique for Object Oriented Modelling 419
from outside access by using sel f instead of a variable for the sender in the
channel expression. Therefore, only the net itself may access this service. An
asynchronous service is protected in the same way by using the tuple (sel f,sel f )
in the according arc expression.
mthPublic
IN (par,(self,self),IN,mthPrivate)
mthPrivate
IN
mthPrivate
I/R
mthPrivate
OUT
mthPublic
OUT
OCP-Nets have three aspects that distinguishes them from Coloured Petri Nets
(CP-Nets) as described in [9]: fusion places, synchronous channels and a dy-
namic structure. The corresponding CP-Nets for nets with fusion places have
been described in [9] and the ones for synchronous channels in [5]. Therefore,
this section only describes the corresponding static structure for the dynamic
structure of OCP-Nets. The basic idea is to enhance the class nets in a way that
they behave like a set of object nets. This enhancement corresponds to folding
the object nets into a class net as proposed in [3] and [12]. The colours of the
places are enhanced with the type OID denoting the object identifier. This way
a place in the class net can contain all tokens of the different object nets. The
resulting net is shown in figure 10 for the asynchronous case. Corresponding to
this the arc inscriptions are all extended with a variable for the identifier (id ).
This ensures that a transition does not mix tokens of different objects while
firing. In addition the class net is extended with a place holding all currently
valid object identifiers (allIDs). It is denoted in the figure as a page fusion place.
This place is used as a side condition for communication transitions instead of
the reserved identifier sel f to ensure that only valid instances are called. The
last extension of the class net is adding the services new and del to enable the
420 Ch. Maier and D. Moldt
creation and deletion of new objects (not shown in the figure). New creates all
tokens needed for an object according to the given initial marking. The service
del removes all tokens belonging to a given object identifier. This construction
corresponds to the one described in [3] and [10] and is described there in more
detail.
It is therefore possible to convert an OCP-Net in a Hierarchical CP-Net
which itself can be converted into a CP-Nets. The existing analysis techniques
can therefore be used for OCP-Nets.
CF CF
pushIN (id,c) (id,c) pushOUT
OIDS*INT OIDS*UNIT
sender
((c,id),x) OID*OID ((id,c),tok)
(id,x) (id,x) (id,tok) (id,tok)
push(x) push push()
IN OUT
elem pushOK
OID*INT OID*UNIT
id id
(id,xs) (id,x::xs)
PF PF
allIDs stack allIDs
OID OID*INT LIST OID
the service is performed. Thus, a shortcut is used to simplify the net representa-
tion. This shortcut is shown in figure 11. The INV- and REC-transitions are com-
bined to one transition. This transition is called I/R-transition (invoke/receive).
Note, this is not a new type of communication transition. It is just an abbrevi-
ation for the INV- and REC-transition and the place wait.
elem y
id.push(y) elem
INT
id
INV INT
y
myStack wait
OID UNIT myStack id
erg=id.push(y)
OID
id I/R
erg
pushOK tok
id.push(y) pushOK
UNIT
REC UNIT
In addition to this shortcut, two more conventions will be used in the rest
of this paper. First, the arc expression tok may be omitted. Second, an arc
expression denoting a variable may be omitted. Instead the name of the place
may be used in guards and method calls. Figure 12 gives an example.
x
[x=true] [ok=true]
ok ok
BOOL BOOL
7.2 Example
Use case modelling is a good way to get a feeling for an application area and to
determine the requirements. They were introduced by Jacobson ([7]) and have
been integrated in the Unified Modeling Language UML ([13]). A use case de-
scribes a way in which the user, called actor in [7], can use a system. This is
similar to a scenario. But while a scenario describes only one possible flow use
cases can have several flows of control. One can therefore think of an use case
as a set of scenarios. A system is then described by the different use cases it
422 Ch. Maier and D. Moldt
offers. A use case consists of three parts; a natural language description with
possible alternative flows of control, a diagram, showing its objects and optional
an Interaction Diagram to model its dynamic behaviour. An Interaction Dia-
gram, called Sequence Diagram in [13], has two drawbacks in that it is only a
semi-formal technique and lacks adequate means to model concurrency. In this
section we will show how to use OCPN to replace Interaction Diagrams.
A simplified version of the use case description for an automatic teller ma-
chine (ATM) that Jacobson uses in [8, pp. 254] will be used below to illustrate
use case modelling with OCP-Nets. It describes the basic flow of control when
a card is inserted into an ATM.
The use case starts when a bank card has been inserted. The Transaction
Handler is invoked which reads the code of the card and checks whether
the card is valid.
If the card is not valid, the session is ended according to the Final Flow. If
the card is valid, the Graphical User Interface is asked to request the actor
to type in his/her PIN. When this has been done, the Card Transaction
Handler reads the code and compares it with the code it received when the
card was inserted. If the PIN is not correct the session is ended according
to the Final Flow. If the PIN is valid the Card Transaction Handler asks
the Graphical User Interface to present the options withdrawal, balance,
transfer and deposit to the actor. Card Transaction Handler gets the
customer’s choice in return and starts the according use case.
Final Flow: The bank card is ejected by the Card Input object; the use
case is then terminated.”
The example is quite simple but sufficient to demonstrate the basic concepts of
modelling with OCP-Nets in an object oriented way. The control flow is modelled
as an OCP-Net in figure 13. The Card Input object is denoted by ci and the
Graphical User Interface by dis in the transition inscriptions. The transaction
starts with IN transition trans(). The card code is then read by cd=readCode()
trans()
IN
valid valid
BOOL PIN BOOL
cd
cd=readCode() checkCode dis.getPIN() checkPIN dis.getOpt() ci.eject()
I/R [valid] I/R [valid] I/R I/R
ci.eject()
[not valid] I/R
ci.eject()
[not valid] I/R
trans()
OUT
and after it the code is checked by an internal service.4 If the code is valid, the
PIN is requested from the display by transition dis.getPIN(). It is checked in
turn and if the PIN is valid the user is asked for an option by dis.getOpt(). The
chosen option is then performed (indicated by a dotted line) and after it the
card is ejected by ci.eject(). If the code or PIN is not valid the card is ejected,
too.
eject()
idle
idle OUT
UNIT
cardInserted
eject()
cardInserted IN
UNIT
readCode()
/return readCdCode()
The figure gives a clear and precise description of the flow of control and can
also show possible concurrency, even if it is not the case in the example given.
In addition, one can go one step further with OCP-Nets. The use case uses
the two objects card input and display. The behaviour of these objects can be
modelled with OCP-Nets in a way similar to Statechart Diagrams used in UML.
Figure 14 shows the Statechart for the card input object and the corresponding
OCP-Net. After receiving event cardIns() the card input object changes its state
to cardInserted and is then ready to read the card code (readCode()). If it receives
event eject() in state cardInserted it ejects the card by some internal action and
confirms this action by the corresponding OUT transition.
The model for the use case and the one for card input can now be combined
as shown in figure 15. This allows to check the consistency between the models
and to simulate them together. The model assumes that a device that detects an
inserted card sends event cardIns() to the card input object and activates then
the transaction by invoking the service trans(). The figure shows a simulation
where the card code is not valid. The events that are exchanged during simulation
4
It is also possible to use code segments as in Design/CPN and attach the code
directly to the transition. Of course, this only makes sense if the code is used only
once.
424 Ch. Maier and D. Moldt
are depicted by dotted lines and numbered. By adding a behavioural model for
the display one can simulate the whole configuration using only one formalism.
The principal structure behind figure 13 - 15 is shown in figure 16. In the upper
part it shows a process layer, depicted by a Petri net and in the lower part an
object model layer, depicted by state machine like symbols. The system consists
of a set of objects and processes that are supposed to run on these objects. This
structure is also found in workflow systems. A workflow is a part of a business
process that is executed in a workflow system using different services of the
underlying computer system (see also [1] and [2]). As this is the same structure
as used here, OCP-Nets are also well suited for workflow modelling, especially
when these workflows are executed on an object oriented system.
8 Conclusion
In this paper an informal introduction to OCP-Nets has been given together
with a complete formal definition of their static structure. An OCP-Net is a
set of class nets. A class net offers one or more services to other class nets by
encapsulating it within an IN- and OUT-transition. This corresponds to methods
in object oriented programming languages. Another class net calls a service via
an INV-transition and receives the result via a REC-transition. This is the only
way for class nets to communicate. Thus, OCP-Nets resemble the structures
known from object oriented programming. In addition, an inheritance relation
has been defined between class nets. Therefore, OCP-Nets can be classified as
truly object oriented nets.
The dynamic structure and behaviour of OCP-Nets have been described to-
gether with a few formal definitions. More about the definitions and their ap-
426 Ch. Maier and D. Moldt
References
1. W.M.P. van der Aalst. Verification of Workflow Nets. In P. Azema and G. Balbo,
editors, Application and Theory of Petri Nets 1997, volume 1248 of Lecture Notes
in Computer Science, pages 407–426. Springer-Verlag, Berlin, 1997.
2. W.M.P. van der Aalst, H.M.W. Verbeek, and D. Hauschildt. A Petri-net-based
Tool to Analyze Workflows. In Petri Nets in System Engineering (PNSE’97) –
Modelling, Verification and Validation, pages 78–89. University of Hamburg (FBI-
HH-B-205/97), 1997.
3. Ulrich Becker and Daniel Moldt. Objektorientierte Konzepte für gefärbte
Petrinetze. In Gert Scheschonk and Wolfgang Reisig, editors, Petri-Netze im Ein-
satz für Entwurf und Entwicklung von Informationssystemen, Informatik Aktuell,
pages 140–151, Berlin Heidelberg New York, 1993. Springer-Verlag.
4. G. Booch. Object-Oriented Design. Benjamin/Cummings Redwood City, CA, 2.
edition, 1993.
5. Soren Christensen and Niels Damgaard Hansen. Coloured Petri Nets Extended
with Channels for Synchronous Communication. In International Conference on
the Application and Theory of Petri Nets, volume 815 of Lecture Notes in Computer
Science, pages 159–178. Springer-Verlag, 1994.
6. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Pat-
terns – Elements of Reusable Object-Oriented Software. Addison-Wesley Publish-
ing Company, Reading, Massachusetts, 1995.
7. Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard.
Object–Oriented Software Engineering – A Use Case Driven Approach. Addison–
Wesley Publishing Company, 1992.
8. Ivar Jacobson, Maria Ericsson, and Agneta Jacobson. The Object Advantage, Busi-
ness Process Reengineering with Object Technology. Addison-Wesley, 1995.
9. Kurt Jensen. Coloured Petri Nets: Volume 1; Basic Concepts, Analysis Methods
and Practical Use. EATCS Monographs on Theoretical Computer Science. Sprin-
ger-Verlag, Berlin Heidelberg New York, 1992.
OCP-Nets – A Formal Technique for Object Oriented Modelling 427
1 Introduction
The object-oriented research community developed techniques, tools, and envi-
ronments that have been applied to several software development projects in
the context of a wide range of application domains. In particular, distributed
object-oriented programming is one of the most promising candidate paradigms
to build large scale distributed systems. OMG the Object Management Group
consortium, CORBA [24] the object-oriented standard for integrating applica-
tions running in heterogeneous distributed environments developed by OMG,
and Java [7], the new internet language developed by Sun Microsystems, are all
examples of such efforts.
On the other hand, most of the theoretical computer science efforts in the
theory of concurrency are oriented to study process algebras such as CCS [18]
or the π-calculus [19] which do not provide a direct representation of objects
as first class entities. In these formalisms processes are stateless entities which
communicate exploiting synchronous message passing and the representation of
an object involves a large number of processes [25].
As a consequence of this situation there is a big gap between theory and
practice: results developed from the theory of concurrent systems, such as the
theories of equivalence for process algebras, can hardly be applied to real object
oriented distributed systems.
This paper has been partially supported by the Italian Ministry of Universities
(MURST).
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 428–444, 2001.
c Springer-Verlag Berlin Heidelberg 2001
The Hurried Philosophers Case Study 429
(mail address) determined at the time of its creation. This name is used to specify
the recipient of a message. Conversely, object-identity is not easily embeddable
in formalisms such as CCS [18] or π-calculus [19], where message dispatching is
performed by means of channels. In these formalisms the association address-
process is not unique: a process may have several ports (channels) from which it
receives messages and the same channel can be accessed by different processes.
2.5 Summary
The actor model was introduced by Carl Hewitt about 20 years ago [14] . Actors
are self-contained agents with a state and a behaviour which is a function of
incoming communications. Each actor has a unique name (mail address) deter-
mined at the time of its creation. This name is used to specify the recipient of a
message supporting object identity. Actors communicate by asynchronous and
reliable message passing exploiting an implicit receive mechanism.
Actors make use of three basic primitives which are asynchronous and non-
blocking: create, to create new actors; send, to send messages to other actors;
and become, to change the behaviour of an actor [2].
The current formalizations of actors, such as [3,4,22], do not exploit a “pro-
cess algebra” style, for this reason it is difficult to import in the actor model
techniques and results developed for other asynchronous calculi [9,15,5]. Unfor-
tunately most of current efforts on the semantics of concurrent languages do not
consider the actor model at all. Although recently Robin Milner [20] suggested
that it may worth to investigate in this direction.
3 An Algebra of Actors
assuming that a and s are subsituted for self and state inside e; e.g. [[self ]]as = a
and [[state]]as = s. The special expression message represents the contents of the
last received message. Whenever a message is received, its contents is substituted
for each occurrence of the expression message in the receiving actor.
Let C be a countable set of actor behaviours: C , D, . . . will range over C.
We suppose that every behaviour D is equipped with a corresponding definition
def
D = P where P is a program, that is a term defined by the following abstract
syntax:
P :: = become(C , e).P | send√ (e1 , e2 ).P | create(b, C , e).P |
e1 :P1 + . . . + en :Pn |
Observe that we allow also the recursive definition of behaviours, e.g,
def √
C = become(C , state). .
Actor terms are defined by the following abstract syntax:
A :: = a Cs | a [P]s | a, v
| A|A | A\a | 0
An actor can be idle or active. An idle actor a Cs (composed by a behaviour
C , a name a, and a state s) is ready to receive a message. When a message is
received the actor becomes active. Active actors are denoted by a [P ]s where P
is the program that is executed. The actor a will not receive new messages until
it becomes idle (by performing a become primitive). The state s is sometimes
omitted when empty (i.e. s = ∅). A program P is a sequence of actor primitives
(become, send and create)
√ and guarded choices e1 :P1 + . . . + en :Pn terminating
in the null program (which is usually omitted). An actor term is the parallel
composition of (active and idle) actors and messages, each one denoted by a term
a, v
where v is the contents and a the name of the actor the message is sent to.
Also a restriction operator A\a is used in order to allow the definition of local
actor names (A\L is used as a shorthand for A\a1 \ . . . \an if L = {a1 , . . . , an })
while 0 stands for an empty actor.
The actor primitives and the guarded choice are described as follows.
– send :
The program send (e1 , e2 ).P sends a message with contents described by e2
to the actor indicated by e1 :
a τ
[send (e1 , e2 ).P ]s −→ a [P ]s | [[e1 ]]as , [[e2 ]]as
a τ a
Send [send (e1 , e2 ).P ]s −→ [P ]s | [[e1 ]]as , [[e2 ]]as
av ∅
Deliver a, v −→ 0
a τ
Become [become(C , e).P ]s −→ (d [P {a/self }]s )\d | a C[[e]]as d fresh
a τ
Create [create(b, C , e).P ]s −→ (a [P {d /b}]s | d C[[e]]as )\d d fresh
a av a def
Receive Cs −→ [P {v /message}]s if C = P
a τ a
Guard [e1 :P1 + . . . + en :Pn ]s −→ [Pi ]s if [[ei ]]as = true
α
A −→ A
Res a ∈ n(α)
α
A\a −→ A \a
av L
A −→ A
Open a = b ∧ b ∈ n(v )
av L∪{b}
A\b −→ A
α
A −→ A if α = av L then
Par a ∈ act(B ) ∧
A|B −→ A |B
α L ∩ fn(B ) = ∅
av av L
A −→ A B −→ B
Sinc
τ
A|B −→ (A |B ) \ L
α
B ≡A A −→ A A ≡ B
Cong
α
B −→ B
expression self , which is the unique one that returns the value d , is changed
in order to refere to the name a of the initial actor.
– create:
The program create(b, C , e).P creates a new idle actor having state s and
behaviour C :
a τ
[create(b, C , e).P ]s −→ (a [P {d /b}]s | d C[[e]]as )\d with d fresh
The new actor receives a fresh name d . This new name is initially known only
to the creating actor, in fact a restriction on the new name d is introduced.
– e1 :P1 + . . . + en :Pn :
In the agent e1 :P1 +. . .+en :Pn , the expressions ei are supposed to be boolean
expressions with value true or false. The branch Pi can be chosen only if the
value of the corresponding expression ei is true:
a τ
[e1 :P1 + . . . + en :Pn ]s −→ a [Pi ]s if [[ei ]]as = true
The function n returns the set of the actor names appearing in an expression, a
program, or an actor term. Given the actor term A, the set n(A) is partitioned
434 M. Gaspari and G. Zavattaro
in fn(A) (the free names in A) and bn(A) (the bound names in A) where the
bound names are defined as those names a appearing in A only under the scope
of some restriction on a. We use act(A) to denote the set of the names of the
actors in A. An actor term is well formed if and only if it does not contain two
distinct actors with the same name. In the following we will consider only well
formed agents, and we will use Γ to denote the set of well formed terms (A, B ,
D, E , F ,. . . will range only over Γ ).
We model the operational semantics of our language following the approach of
Milner [19] which consists in separating the laws which govern the static relation
among actors (for instance A|B is equivalent to B |A) from the laws which rules
their interaction. This is achieved defining a static structural equivalence relation
over syntactic terms and a dynamic relation by means of a labelled transition
system [21].
The rules Send , Become, Create and Guard have been already discussed. Rule
Deliver states that the term a, v
(representing a message v sent to the actor a)
is able to deliver its contents to the receiver by performing the action av ∅. The
corresponding receiving action labeled with av can be performed by the actor
a when it is idle (rule Receive). The other rules are simply adaptation to our
calculus of the standard laws for the π–calculus. The most interesting difference
is due to the fact that in our calculus, more than one restriction can be extended
by one single delivering operation. In fact, in our case the contents of a message
is an expression instead of a unique name. This is the reason why we have added
the set L to the label av L.
Another difference is in the rule Par : the actor term A|B can deliver a mes-
sage inferred by A (i.e., execute an emission action av L), only if B does not
contain the target actor (i.e., a ∈ act(B )).
The Hurried Philosophers Case Study 435
3.1 Discussion
There are several differences with respect to the formal semantics of actors in
[3,4] and in [22] which is worth to point out.
4 Hurried Philosophers
In this section we present a specification of the Hurried Philosophers case study,
which aims to establish the expressive power of object-oriented formalisms, test-
ing features such as dynamic object creation and termination; dynamic binding
of communication channels (i.e., the partner of a communication is defined when
the communication occurs); inheritance (a class of objects may inherit some fea-
tures from other classes of objects).
To improve the presentation, we introduce some further notations which
will be useful in the specification, giving a direct representation of the stan-
dard object-oriented concepts of methods, inheritance and attributes. Then, we
provide a specification of the traditional (static) version of dining philosophers
problem [17]. Finally, we show how dynamic aspects concerning the creation of
new philosophers and the deletion of them, can be added to the specification
exploiting inheritance.
Philosopher
Fork
WaitForks
get Busy eat take
put
Free put get Think WaitForks
This algorithm ensures that neither deadlock nor starvation can occur, if at
least one right and one left philosopher are present at the table. In fact, under
this condition, no circular waiting chains can be reached during the computation
(see [17] for more details on the proof of the correctness of the algorithm).
The way we implement the right-left algorithm consists in representing each
philosopher and each fork as an actor. We assume a fixed structure for messages
which are represented using records containing two fields: act indicating the
name of the sender of the message, and con representing the contents of the
message.
An actor representing a fork can be free or busy. The state of the fork fi can
be null or pj indicating that the philosopher pj is waiting for that fork (hence
when the fork fi will be freed it will be given to pj ) while null says that no
philosophers is waiting for the fork fi . When a fork receives a get request and it
is free it becomes busy, otherwise if it is busy it stores such a request. This is
needed to implement a fair policy. See Figure 1 for a graphical representation of
the possible behaviours of fork actors.
Initially all the philosophers are thinking. When a philosopher receives a
message having contents eat, he starts asking for the forks he needs to eat,
and, eventually, he starts eating. A philosopher eats until he receives a message
having contents think , in this case he frees the forks and starts thinking. Note
that, we do not consider the source of the messages eat and think , we only
The Hurried Philosophers Case Study 439
fork1 fork2
phil
phil philNew
define how the philosophers react to them. The state of an actor representing a
philosopher is a record having the form: (fork 1:fi , fork 2:fj ) where fi is the name
of the first fork that the philosopher asks for, and fj the name of the second one.
In our solution actors do not know the names of their neighboring philosophers: a
philosopher only knows his first and his second fork. See Figure 1 for a graphical
representation of the possible behaviours of philosopher actors.
The actor term which specifies the static dining philosophers is the following
one:
def f
DinPhil = 0
Freenull | . . . | fn−1 Freenull |
p0 pn−1
Think(fork 1:f0 ,fork 2:f1 ) | . . . | Think(fork 1:f0 ,fork 2:fn−1 )
where the actors fi Freenull and pi Think(fork 1:fk ,fork 2:fl ) represent the i -th fork and
the i -th philosopher, respectively.1 We explicitly require that the philosophers
p0 and pn−1 share the first fork, in this way the condition of having at least one
right and one left philosopher is satisfied. The behaviours Free and Think are
defined in Table 2 where in every behaviour is omitted the choice:
which resends to the same actor a message which can not be managed from the
actual active message handlers.
1
The state null of each fork indicate that no philosopher is waiting for it, while the
fields fork 1 and fork 2 of the state of each philosopher contain the name of the first
and of the second fork that the philosopher needs to eat.
440 M. Gaspari and G. Zavattaro
which has the responsability of creating a new fork, whenever a new philosopher
is added to the table. The maximum number of new forks that can be created
is m (the initial state of the heap actor). Thus, if n is the number of starting
philosophers, no more than n + m philosophers can be present around the table
at the same time. In fact, when the heap creates a new fork, the state of the
heap is decremented, and when it reach 0 no further fork can be added.
The process of creation of a new philosopher starts when a philosopher who
is thinking receives a message containing the create operation. A philosopher
can manage this kind of messages only when he does not own any fork.
A philosopher, before creating his new neighbor, asks to the heap for a new
fork. If the operation succeeds, the heap creates the new fork, and sends its
name to the creating philosopher. Otherwise, the creation fails and the protocol
terminates. When a philosopher receives from the heap the name of the new fork,
he creates his new neighbor philosopher who is located in between himself and
his first fork (see Figure 2). It is interesting to note that every philosopher is able
to introduce new neighbors without knowing the name of the actual neighbors.
The Hurried Philosophers Case Study 441
phil1 phil3
Moreover, in order to be sure that at least one right and one left philosopher
stay at the table, the neighbors will share the same fork as first fork. The function
compState(i , self , state) computes the new state of the neighbor i of the leaving
philosopher:
def
compState(i , self , state) =
rec: = (fork 1:state.fork 2, phil 1:state.phili )
if (state.stPhili .phil 1 = self )
then rec: = rec (fork 2:state.stPhili .fork 2, phil 2:state.stPhili .phil 2)
else rec: = rec (fork 2:state.stPhili .fork 1, phil 2:state.stPhili .phil 1)
return rec
5 Conclusion
We have defined an algebra of actors that provides basic object-oriented features.
We have presented the specification of the Hurried Philosopher case study which
shows the expressive power of the algebra.
As we have already stated, the process algebraic definition that we have
given to the actors, allows the reuse of standard techniques used in the field of
The Hurried Philosophers Case Study 443
asynchronous calculy. For instance we have investigated the actor model by using
the asynchronous bisimulation of [5] and we found interesting results presented
in [12].
Currently the applications of the algebra of actors concern the study of a
communication language for multi-agent systems [11] and the specification of
the new asynchronous messaging service of CORBA [13].
A number of additional research items still need to be carried out. Among
them: a study of how typing and inheritance issues, such as in [1], can be ad-
dressed in our algebra; and the definition of a framework for formal reasoning
about programs, e.g., following the style of the Hennessy and Milner logic [18].
References
1. M. Abadi and L. Cardelli. An Imperative Object Calculus. Theory and Practice
of Object Systems, 1(3):151–166, 1995.
2. G. Agha. Actors: A Model of Concurrent Computation in Distributed Systems.
MIT Press, Cambridge, MA, 1986.
3. G. Agha, I. Mason, S. Smith, and C. Talcott. Towards a Theory of Actor Computa-
tion. In Proc. of CONCUR’92, volume 630 of Lecture Notes in Computer Science,
pages 564–579. Springer Verlag, 1992.
4. G. Agha, I. Mason, S. F. Smith, and C. Talcott. A Foundation for Actor Compu-
tation. Journal of Functional Programming, 7(1):1–69, January 1997.
5. R. Amadio, I. Castellani, and D. Sangiorgi. On Bisimulations for the Asynchronous
π-Calculus. Theoretical Computer Science, 195(2):291–324, 1998.
6. J. Andreoli and R. Pareschi. Linear Objects: Logical Processes with Built-in In-
heritance. New Generation Computing, 9(3-4):445–473, 1991.
7. M. Campione and K. Walrath. The Java Tutorial: Object-Oriented Programming
for the Internet. Addison Wesley, 1996.
8. L. Cardelli. A Language with Distributed Scope. Computing Systems, 8(1):27–59,
January 1995.
9. P. Ciancarini, R. Gorrieri, and G. Zavattaro. Towards a Calculus for Generative
Communication. In Proc. FMOODS’96, pages 283–297. Chapmann & Hall, 1996.
10. F. deBoer, J. Klop, and C. Palamidessi. Asynchronous Communication in Process
Algebra. In Proc. LICS’92, pages 137–159. IEEE Computer Society Press, 1992.
11. M. Gaspari. Concurrency and knowledge-level communication in agent languages.
Artificial Intelligence, 105(1-2):1–45, 1998.
12. M. Gaspari and G. Zavattaro. An algebra of actors. In Proc. 3nd IFIP Conf.
on Formal Methods for Open Object-Based Distributed Systems (FMOODS), pages
3–18. Kluwer Academic Publishers, Feb 1999.
13. M. Gaspari and G. Zavattaro. A process algebraic specification of the new asyn-
chronous corba messaging service. In Proc. European Conf. on Object Oriented Pro-
gramming (ECOOP), Lecture Notes in Computer Science. Springer-Verlag, Berlin,
1999.
14. C. Hewitt. Viewing control structures as patterns of passing messages. Artificial
Intelligence, 8(3):323–364, 1977.
444 M. Gaspari and G. Zavattaro
Susanne Schacht
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 445–460, 2001.
c Springer-Verlag Berlin Heidelberg 2001
446 Susanne Schacht
programming language specific part (the domain part) and a program specific
part. In Section 2, we introduce the basic temporal logic system. In Section
3, we briefly sketch the actor model and introduce a simple syntax for actor
programs. Next, we adjust the general proof system to the description of actor
computations in Section 4, thus introducing the domain part of our proof system.
We then demonstrate the application of the logical framework – the building
of the program part – to a definition of receipt handlers which manage the
termination recognition of subcomputations.
In this section, we give a basic proof system for discrete and linear1 tempo-
ral logic, following [16]. We will first introduce a set of temporal-logic future
operators:
Ki ( A) = t iff Ki+1 (A) = t
Ki (✸ A) = t iff Kj (A) = t for some j ≥ i
Ki (✷ A) = t iff Kj (A) = t for every j ≥ i
Ki (A U B) = t iff Kj (B) = t for some j ≥ i and Kk (A) = t for every k, i ≤ k < j
Ki (A N B) = t iff Kj (B) = f for every j > i
or Kk (A) = t for the smallest k > i with Kk (B) = t
as well, mapping a unique tag (an identifier created in order to distinguish be-
tween similar tasks) to pairs consisting of a target actor address and a message.
Transitions between configurations are determined by choosing one of several
unprocessed tasks for execution: the effects of processing of this task’s message
at its target are evaluated, giving a set of new tasks, a set of newly created ac-
tors and the replacement behavior for the target actor. This semantics depends
on the existence of one (of several possible) global view(s) of the system: the
configurations describe all actors involved. This kind of semantics as well as the
denotational one of Clinger [8] does not allow abstract propositions about parts
of the system’s computations that could be combined. Mechanisms for abstrac-
tion over the total ordering of events as well as abstraction over specific details of
a configuration are needed to make comprehensive statements about the overall
system behavior or that of selected parts.
A more recent approach to actor semantics is conducted in [4] where the λ-
calculus-based semantics of functional languages in terms of transitions modeled
as reduction steps is extended by integrating actor primitives like send, become,
newAddress, and initBehavior, the latter building create. To specify open
systems, a configuration states internal recipient actors which are able to receive
messages from outside and external actors which do not belong to the actors in
the configuration but can be addressed by them. Although partial descriptions
of an actor system become possible now, this semantics, on the other hand,
Formal Reasoning about Actor Programs Using Temporal Logic 449
Some further definitions: Usual λ expressions e are taken from the set E, actor
addresses a from AI. Local states s are elements of AS := {(?a )|a ∈ AI} ∪
{(b)|b ∈ B} ∪ {[e]|e ∈ E}. A local states function sa is defined as an element of
α : AI ∪ { } → AS. Messages m are in M, behaviors b in B, and tasks (a, m) in
T := AI × M.
Let α be a partial function from addresses (AI ∪ { }2 ) to local states (AS),
let θ ⊆ T be a set of tasks, ρ ⊂ Dom(α) a set of recipient actors, and η ⊂ AI (η
∩ Dom(α) = ∅) a set of external actors. This way, a configuration is a quadrupel
c of (α, theta, ρ, η) written as α | θ ρη .
The transition rules for configurations are shown below (we omit the rules
for in and out, the rules that concern external actors). The fun rule is for
internal computation steps that can be done in λ-calculus. The other rules use
reduction contexts that incorporate the usual left-first - call-by-value reduction
strategy [23]. These are expressions with a ”hole” that can be filled with a
reducible expression (e.g., e in R[[e]]) [11]. newadd reduces a reduction context
with newAddress to a new address with an undefined state and to the reduction
context that contains this new address. init assigns a new behavior to an
actor with undefined state. become reduces the actor to a new behavior and
leaves an anonymous address in the context. send adds a new task to θ, and
rcv reduces an idle actor and one of its tasks to the application of the actor’s
behavior to the task.
fun e
→λ e ⇒ α ∪ {[e]a } | θ ρη
→ α ∪ {[e ]a } | θ ρη
newadd α ∪ {[R[[newAddress()]]]a } | θ ρη
→ α ∪ {[R[[a ]]]a , (?a )a } | θ ρη ,
a ∈ Dom(α) ∪ {a} ∪ η
init α ∪ {[R[[initBehave(a , b)]]]a , (?a )a } | θ η
→ α ∪ {[R[[nil]]]a , (b)a } | θ ρη
ρ
become α ∪ {[R[[become(b)]]]a } | θ ρη
→ α ∪ {R[[nil]]] , (b)a } | θ ρη
send α ∪ {[R[[send(a , m)]]]a } | θ ρη
→ α ∪ {[R[[nil]]]a } | θ ∪ {(a , m)} ρη
rcv α ∪ {(b)a } | {(a, m)} ∪ θ ρη
→ α ∪ {[app(b, m)]a } | θ ρη
2
is like an anonymous variable in PROLOG: only its existence is of interest.
450 Susanne Schacht
In order to adapt the system from Section 2 to the actor model and to construct
the domain part of the proof system, the actor language must provide the ele-
ments for building local, non-temporal propositions about pending tasks and the
actors involved. These will serve as basic state descriptions. Sequences of states
will then be defined by determining the effects of one of the pending tasks. We
assume a standard FOL plus identity in order to express propositions about the
bindings between identifiers and values (i.e., actor addresses and basic values)
and between actors and their definitions. Accordingly, we use unary predicates
to indicate whether a term denotes an instance of a certain actor definition and
binary predicates named after acquaintance or variable names to indicate an ac-
tor’s acquaintances. A name can be used as a function symbol, taking the actor
as a parameter and denoting the acquaintance’s or variable’s value, thus forming
a term.
For tasks, we use the notation (a, m), with a denoting an actor address and
m denoting a unique message. The predicate Task takes three places, two for the
task itself and a third one to actually indicate whether the task is an element of
the set of unprocessed tasks. This third parameter is a Boolean variable whose
value flips from “false” to “true” (thus denoting an unprocessed task), is kept
unchanged until the task is processed, and after being processed flips back from
“true” to “false” (this value will not be changed anymore). Such a behavior
guarantees the interpretation of the predicate Task not to change over time in
our semantics. This feature is axiomized as follows:
∀(a, m, f ) :
Task(a, m, true) ∧ ¬Task(a, m, false)
∧( ✷ ¬Task(a, m, f ) ∨ (¬Task(a, m, f ) U (Task(a, m, f ) U ✷ ¬Task(a, m, f )))
The following axiom (single transition) states that as long as there are un-
processed tasks, exactly one of them, (a, m), is processed at each step and no
changes on SP and TP are made other than those caused by (a, m):
SP ∧ T P ∧ ∃ a, m, f : Task(a, m, f ) ↔
∀ b, n, g : Task(b, n, g) ↔
(¬Task(a, m, f ) ∧ (Task(b, n, g) ∨ (a, m) = (b, n)) ∧ effects(a, m))
Fairness must also be included as an axiom of the proof system — any pending
task will stay pending until eventually it is chosen for execution. Then, in the
next state, it will be removed from tasks and its effects can be observed. Since
no pending task can be cancelled, this axiom (fairness) is sufficient to guarantee
fair computations.
∀ (a, m, f ) : Task(a, m, f ) ↔
Task(a, m, f ) U (Task(a, m, f ) ∧ (effects(a, m) ∧ ✷ ¬Task(a, m, f )))
since:
Ki (A U (A ∧ (B ∧ ¬A))) = t
⇒ Kj (A ∧ (B ∧ ¬A))) = t for j > i
⇔ Ki ( ✸ (A ∧ (B ∧ ¬A))) = t
⇒ Ki ( ✸ (A ∧ B)) = t
To reason about a particular program, existing actors and sent messages as well
as the program’s actor definitions must be accounted for. The local state propo-
sitions about actors are determined by their binding to actor definitions and the
values of their acquaintances, both forming the state propositions SP. For tasks
(a, m), from a’s method definition for m’s message key, we take the combined
action to determine m’s effects. The bindings of m’s parameters can be found
in SP, as they must have been either acquaintances or variables of m’s sender
or newly created actors known from the previous steps of computation. If no
identifier of an actor is available (e.g., if it is created anonymously), we use a
variable which can be considered existentially quantified. With these conven-
tions, effects(a, m)(SP, TP) can be defined in a straightforward way. The effects
of performing (a, m) on the set of pending tasks, tasks, are determined by iden-
tifying all send actions in the method’s definition that are actually performed
(depending on a’s state). The receivers and messages are combined to tasks and
then added to tasks. Below, act(a, m) denotes the action that is the body of m’s
definition at a (“\” denotes the set complement operator).
The effects on the local state propositions, SP, concern newly created actors
via create actions and changes on a via become. For any actor b created from
a definition D with initial acquaintances aqci bound to ai , D(b) and Aqci (b, ai )
are added to SP. Also, we refer to ai as acq(b), and extend the function as well
as the predicate notation to local variables where necessary. All elements of SP
concerning a itself are changed according to the occurrence of a become action.
effects(a, m)(SP ) := SP ∪ created (act(a, m)) ∪ new (act(a, m))\old (act(a, m))
For the initial configuration, tasks and SP are determined from the initially
created actors and sent messages in the program.
To summarize, a TAL proof system Θ for a program P as in Section 3 is
a quadruple Σ Θ , Op, Rb , Rp , consisting of a signature Σ Θ , the set Op of the
usual first-order and temporal logic operators, and two sets of rules and axioms.
The set Rb contains the axioms and rules of the basic proof system (cf. Section
2). The set Rp consists of the rules taken from P by instantiating the axioms for
fairness and single transition. This is achieved by evaluating the effects function
Formal Reasoning about Actor Programs Using Temporal Logic 453
A, A → B A A → B, A → A
modus ponens: next: induction:
B A A→ ✷B
Single transition:
SP ∧ T P ∧ ∃ a, m, f : Task(a, m, f )
∀ b, n, g : Task(b, n, g) ↔
(¬Task(a, m, f ) ∧ (Task(b, n, g) ∨ (a, m) = (b, n)) ∧ effects(a, m))
Fairness:
Task(a, m, f )
Task(a, m, f ) U (Task(a, m, f ) ∧ (effects(a, m) ∧ ✷ ¬Task(a, m, f )))
Task(a, m, f )
or:
✸ (Task(a, m, f ) ∧ (effects(a, m) ∧ ✷ ¬Task(a, m, f )))
Task(a, m, f ) ∧ effects(a, m)
(¬Task(a, m, f ) ∧ ∀(ai , mi ) ∈ newTasks(action(a, m))∃fi Task(ai , mi , fi )
∧ created(action(a, m)) ∧ ¬old(action(a, m)) ∧ new(action(a, m)))
454 Susanne Schacht
Due to its fine granularity, the asynchronous actor mode of message passing does
not easily fit complex real-world applications. Especially, synchronization con-
structs are needed (for suggestions, cf. [12], and [3]). As an example for applying
the temporal logic system, we will discuss a programming scheme for ’partial
termination’. Instead of detecting the termination of arbitrary processes, we fo-
cus on a characteristic subset of computations which are obliged to signal their
Formal Reasoning about Actor Programs Using Temporal Logic 455
3
We use set-algebraic operators instead of low-level message passing expressions.
456 Susanne Schacht
After having received a receipt message, both sets exp and rec will be
calculated. If and only if for both sets the result equals the empty set, the
terminated message will be issued. Therefore, the invariant (2) holds. From
the definition of ReceiptHandler itself no (useful) liveness properties can be
derived, since they depend on the respective application of ReceiptHandlers.
We will now demonstrate such an application of ReceiptHandlers on a sim-
ple recursive computation, the printing of the structure and the contents of
a tree in a depth-first manner. Fig. 2 shows a graphical representation of the
ReceiptHandler gen
era
teT
rec ag
eip
t
gen
TreeNode pri
ntC
era
hil
n
rec
dre
teT
dre
n
eip
ag
hil
t
ntC
pri
acquaintance
objects and messages involved. The program code is shown below4 . All of the
messages, except for the generation of tags, operate asynchronously. After a
ReceiptHandler has been created, each non-leaf tree node’s daughters are asyn-
chronously accessed and printed. At each node, for each daughter node a receipt
tag is computed and sent to the daughter as a parameter of the printChildren
message (rtTag). With the receipt message sent to the receipt handler, the set
of all these tags is returned as those which are to be expected (furtherTags)
and the node’s own receipt tag as that tag which is hereby received (rtag).
4
Two further syntactical enhancements: ask expressions denote rpc-like communica-
tions, for <var> in <collection> do abbreviates an enumeration of the elements
of <collection>. Both can be expanded to patterns of asynchronously communicat-
ing actors.
Formal Reasoning about Actor Programs Using Temporal Logic 457
In order to prove the termination we have to show that (a) if the tags transmitted
as ’received’ are exactly those transmitted as ’expected’ the sets will eventually
be empty, and (b) given (a), the terminated message will be sent, and (c) that
(a) and (b) will be guaranteed to happen.
For the first part, we have to prove that the bookkeeping of tags is correct.
Assuming a collection of receipt messages ri (ti Si ) with 1 ≤ i ≤ k, ti pair-
k
wise distinct, Si pairwise distinct or empty, and {t1 . . . tk } = i=1 Si sent to
a ReceiptHandler with initially empty sets tagsExp1 and tagsRec1 . At each
arrival of a message ri , tagsExpi+1 and tagsReci+1 are calculated as follows:
The newly generated tags i are assumed to be pairwise distinct, which can
easily be ensured by an appropriate name server. Given the above formalizations
of ReceiptHandler and TreeNode, an initial set tasks = {(tree, printAll(prt))},
and TreeNode (tree), we can derive (3) by the following deduction. The single
element of tasks is immediately chosen for execution and its effects occur in the
next step:
Now, we can derive the effects of the two new elements of tasks:
... →
✸((ReceiptHandler(rh) ∧ 1 #∈ tagsRec(rh) ∧ exp = tagsExp(rh) ∪ {1} #= ∅)
∧ (ReceiptHandler(rh) ∧ 1 ∈ tagsExp(rh))
∨(ReceiptHandler(rh) ∧ 1 ∈ tagsRec(rh) ∧ rec = tagsRec(rh) \ {1})
∧ (ReceiptHandler(rh) ∧ 1 #∈ tagsRec(rh) ∧ 1 #∈ tagsExp(rh)))
∧ ✸((Children(tree, ∅) ∧ (rh, receipt(1 ∅)) ∈ tasks)
∨(¬Children(tree, ∅) ∧ (∃T : A ∧ Task(rh, receipt(1 T))))
(5)
with A ≡ ∀c : c ∈ children(tree) ↔ (∃cTag : cTag ∈ T∧ Task(c, printChildren(prt
rh cTag))) Transitively from (4) and the first disjunction of (5), we can conclude
that whether the receipt(nil {1}) or the receipt(1 X) message arrives first at rh,
1 will be excluded from both sets, tagsExp and tagsRec. This holds analogously
for all elements of T in the second disjunction of (5) until both sets are empty
again
6 Related Work
Our work clearly benefits from previous work that has been done in the field of
applying temporal logics to concurrent program specification. Among the tem-
poral approaches, the work of Emerson et al. [7,10] and of Manna & Pnueli
[18] is fundamental; TLA [17] and UNITY [6] both are elaborated specification
languages based on temporal logics. They all have in common that they con-
centrate on the temporal part of the specification and do not provide a deep
treatment of single states. This strangely neglected topic is, however, crucial
Formal Reasoning about Actor Programs Using Temporal Logic 459
7 Conclusion
We have shown how a general proof system for discrete linear temporal logic
can be tailored to describe the behavior of actor systems. We express the con-
figurations of an actor system at a time step as sets of formulas serving as
(temporally spoken) local states for the temporal logic TAL. This specialized
proof system has been applied to an extension of the basic actor communication
mode that allows for detecting the termination of partial computations. Tempo-
ral logics turns out to be a suitable formal framework for describing actor-style
distributed computations.
References
1. Agha, G. Actors: a Model of Concurrent Computation in Distributed Systems.
MIT Press, Cambridge, MA, 1986.
2. Agha, G. The structure and semantics of actor languages. In Foundations of
Object-Oriented Languages, J. de Bakker, W.-P. de Roever, and G. Rozenberg,
Eds., no. 489 in LNCS. Springer, Berlin etc., 1990, pp. 1–59.
3. Agha, G., Frølund, S., Kim, W. Y., Panwar, R., Patterson, A., and Stur-
man, D. Abstraction and modularity mechanisms for concurrent computing. In Re-
search Directions in Concurrent Object-Oriented Programming, G. Agha, P. Weg-
ner, and A. Yonezawa, Eds. MIT Press, Cambridge, MA, 1993, pp. 3–21.
460 Susanne Schacht
4. Agha, G., Mason, I. A., Smith, S. F., and Talcott, C. L. A foundation for
actor computation. Journal of Functional Programming 7 (1997), 1–72.
5. Barringer, H. The use of temporal logic in the compositional specification of
concurrent systems. In Temporal Logics and their Applications, A. Galton, Ed.
Academic Press, London etc., 1987, pp. 53–90.
6. Chandy, K. M., and Misra, J. Parallel Program Design. Addison-Wesley, 1989.
7. Clarke, E. M., Emerson, E. A., and Sistla, A. P. Automatic verification
of finite state concurrent systems using temporal logic specifications: A practical
approach. ACM Transactions on Programming Languages and Systems 8, 2 (April
1986), 244–263.
8. Clinger, W. D. Foundations of Actor Semantics. PhD thesis, Cambridge, MA:
MIT, Dept. of Mathematics, 1981.
9. Duarte, C. H. C. A proof-theoretic approach to the design of object-based
mobility. In Proc. 2nd IFIP Conf. on Formal Methods for Open Object-Based
Distributed Systems (London, 1997), H. Bowman and J. Derrick, Eds., Chapman
and Hall, pp. 37–56.
10. Emerson, E., and Halpern, J. ’sometimes’ and ’not never’ revisited: On branch-
ing time versus linear time temporal logic. Journal of the ACM 33, 1 (1986).
11. Felleisen, M., and Friedman, D. P. Control operators, the SECD-machine, and
the λ-calculus. In Formal Descriptions of Programming Concepts III, M. Wirsing,
Ed. Elsevier, Amsterdam, NL, 1986, pp. 193–217.
12. Frølund, S. Inheritance of synchronization constraints in concurrent object-
oriented programming languages. In ECOOP ’92 – European Conference on Object-
Oriented Programming (1992), O. L. Madsen, Ed., no. 615 in LNCS, Springer,
pp. 185 – 196.
13. Greif, I. G. Semantics of Communicating Parallel Processes. PhD thesis, MIT,
Dept. of Electrical Engineering and Computer Science, 1975.
14. Hewitt, C., and Baker, H. Actors and continuous functionals. In Proceedings
of the IFIP Working Conference on Formal Description of Programming Concepts
(1978), E. Neuhold, Ed., Amsterdam etc.: North-Holland, pp. 367–390.
15. Hoare, C. Communicating Sequential Processes. Prentice-Hall, 1985.
16. Kröger, F. Temporal Logic of Programs. Springer, 1987.
17. Lamport, L. The Temporal Logic of Actions. Transactions on Programming
Languages and Systems 16, 3 (May 1994), 872–923.
18. Manna, Z., and Pnueli, A. The Temporal Logic of Reactive and Concurrent
Systems. Springer, Berlin etc., 1992.
19. Milner, R. Communication and Concurrency. Prentice-Hall, Englewood Cliffs,
NJ, 1989.
20. Milner, R., Parrow, J., and Walker, D. A calculus of mobile processes, I/II.
Information and Computation 100, 1 (1992), 1–77.
21. Nierstrasz, O. Towards an object calculus. In ECOOP’91 – Proceedings
of the European Workshop on Object-Based Concurrent Computing (Berlin etc.,
Geneva, Switzerland, July 15–16 1992), M. Tokoro, O. Nierstrasz, P. Wegner, and
A. Yonezawa, Eds., Springer.
22. Owicki, S., and Lamport, L. Proving liveness properties of concurrent programs.
ACM Transactions on Programming Languages and Systems 4, 3 (1982), 455–495.
23. Plotkin, G. Call-by-name, call-by-value and the lambda calculus. Theoretical
Computer Science 1 (1975), 125–159.
Flexible Types for a Concurrent Model
Franz Puntigam
1 Introduction
The basic concept of object-oriented programming languages is that of objects
communicating with other objects [4,22]. An object is a self-contained entity
characterized by its identity, state and behavior. Objects are classified according
to their behavior into a system of types. We also regard subtyping [5,11] and the
related sort of polymorphism as necessary features of object-oriented languages.
In concurrent object-oriented languages it is advantageous to use active ob-
jects [2,15], i.e. to regard objects as processes. The computation models for such
languages can be based on, for example, Hoare’s CSP model [9], the object-based
actor model [1] and process calculi [3] like Milner’s π-calculus [13].
In this chapter we explore a combination of the actor model with a process
calculus, where active objects communicate by asynchronous message passing.
The major contribution is a type model based on two principles: The sender
updates his view of the receiver’s type after sending a message (1); and each
object accepts messages corresponding to all clients’ type views in arbitrary
interleaving (2). These principles support very flexible and expressive types.
In Sect. 2 we describe how types can help in the development of concurrent
software and give a motivation for the type model. Our basic model of compu-
tation (without types) is introduced in Sect. 3. Type annotations are added in
Sect. 4. We give conditions on which programs are well-typed.
2 Types
Most type-theoretic foundations for object-oriented languages are based on a
typed λ-calculus extended by records [5,8]. Subtyping is defined by Wegner and
Zdonik’s principle of substitutability [22]: “An instance of a subtype can always
be used in any context in which an instance of a supertype was expected.”
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 461–472, 2001.
c Springer-Verlag Berlin Heidelberg 2001
462 F. Puntigam
1
It is not our goal to prevent deadlocks in general. But the execution of an active
object shall be blocked only if the queue of received messages is empty.
Flexible Types for a Concurrent Model 463
(p1 ; p2 ); p3 ≡ p1 ; (p2 ; p3 ) p; ε ≡p ε; p ≡ p
(p1 p2 ) p3 ≡ p1 (p2 p3 ) p1 p2 ≡ p2 p1 pε ≡ p
(p1 + p2 ) + p3 ≡ p1 + (p2 + p3 ) p1 + p2 ≡ p2 + p1 p+ε ≡ p
(p1 + p2 ); p3 ≡ p1 ; p3 + p2 ; p3 p+p ≡p
x(v1 , . . . , vn ) ≡ p[v1 , . . . , vn /v1 , . . . , vn ] if x(v1 , . . . , vn ) := p
3 Model of Computation
An actor is an active object with a unique mail address, a behavior and a mail
queue holding received messages. The messages in the mail queue are dealt with
in the same sequence as they were received: Depending on its current behavior
and the message dealt with, the actor sends messages to acquainted mail ad-
dresses, creates new actors and replaces its own behavior. Furthermore, in our
model we assume that messages are received in the same (logical) order they
have been sent.
In our model we specify the behavior of actors by process expressions. The
actions deal with accepting (receiving) and sending messages and creating actors.
We assume that a set of message names M, a set of process names X, an infinite
set of variables and mail addresses V are given; elements of M, X and V are
denoted by m, x and v (sometimes quoted or indexed), respectively. The syntax
of process expressions p and process definitions q is given by:
p ::= ε empty process (skip)
| v$p create actor with mail address v and behavior p
| v.m(v1 , . . . , vn ) send m with concrete parameters v1 , . . . , vn to v
| m(v1 , . . . , vn ) get m from mail queue; formal parameters v1 , . . . , vn
| x(v1 , . . . , vn ) apply process x with concrete parameters v1 , . . . , vn
| p1 ; p2 sequential composition; first p1 , then p2
| p1 + p2 alternative composition; either p1 or p2
| p 1 p2 parallel composition (merge); p1 and p2 interleaved
q ::= x(v1 , . . . , vn ) := p define process x; formal parameters v1 , . . . , vn
A process expression is the empty process, an action (create, send, receive), a
process application, or a sequential, alternative or parallel composition. Empty
parentheses can be omitted. Among composition operators, “;” has highest and
“+” lowest priority. A process definition associates a process expression with a
name and parameters. For each x ∈ X there is exactly one process definition; the
set of these process definitions is a program. The reflexive, transitive closure of
the rules in Fig. 2 defines an equivalence relation on process expressions: Com-
position operators are associative and have ε as neutral element; “” and “+”
are commutative; “+” is idempotent; “;” is right-distributive over “+”. Process
applications are equivalent to the applied process expression, where concrete pa-
rameters are substituted for formal parameters. (p[v1 , . . . , vn /v1 , . . . , vn ] denotes
the simultaneous substitution of v1 , . . . , vn for all free occurrences of v1 , . . . , vn
in p.) Usually, we do not distinguish between equivalent process expressions.
464 F. Puntigam
“Buffer” is a process name, “put”, “get” and “back” are message names, and v1
and v2 variables. The argument of “get” is supposed to be the mail address of
an actor to which the buffer content v1 is sent on receipt of “get”. The cycle of
putting an element into the buffer and getting it from there can be repeated as
often as needed by applying the last rule in Fig. 2; the above definition of “Buffer”
is (by substituting the process expression for the process name) equivalent to
this one:
An actor behaving as “Buffer” always contains only a single element. One be-
having as “IBuffer” can hold an unbounded number of elements simultaneously:
An unbounded buffer can deal with “put” and “get” in arbitrary ordering.
When the buffer is empty, the execution of “get” is delayed as in the Linda
coordination model [7]:
4 Typed Processes
Under some conditions, an actor cannot proceed with its execution: There may
be no appropriate alternative handling the next message in the mail queue; the
numbers of concrete and formal parameters in process applications do not match;
or the addressee of a message does not exist. A strong, static type system has
to ensure at compile-time that such errors cannot occur.
The first step in adding a type concept is to annotate all variables with type
expressions. We assume that a set Z of type names z is given. The syntax of
type expressions t and type definitions d is given by:
Flexible Types for a Concurrent Model 465
(t1 ; t2 ); t3 ≡ t1 ; (t2 ; t3 ) t; ε ≡ t ε; t ≡ t
(t1 t2 ) t3 ≡ t1 (t2 t3 ) t 1 t2 ≡ t2 t1 tε ≡ t
(t1 + t2 ) + t3 ≡ t1 + (t2 + t3 ) t1 + t2 ≡ t2 + t1 t+ε ≡ t
(t1 + t2 ); t3 ≡ t 1 ; t 3 + t2 ; t 3 t1 ; (t2 + t3 ) ≡ t1 ; t 2 + t 1 ; t 3 t+t ≡ t
(t1 + t2 ) t3 ≡ t 1 t3 + t2 t3 z≡ t if z(t1 , . . . , tn ) := t
r1 ; t1 r2 ; t2 ≡ r1 ; (t1 r2 ; t2 ) + r2 ; (r1 ; t1 t2 )
t1 ≡ t2
t≤ε
t 1 ≤ t2
t1 ≤ t1 . . . tn ≤ tn z(t1 , . . . , tn ) := t ≤ z (t1 , . . . , tn ) := t
m(t1 , . . . , tn ) ≤ m(t1 , . . . , tn ) z ≤ z
t 1 ≡ t3 t 2 ≤ t4 t 1 ≤ t3 t 2 ≤ t4
t1 ; t2 ≤ t 3 ; t4 t 1 t2 ≤ t 3 t4
t 1 ≤ t3 t 2 ≤ t4 t 1 ≤ t3 t 2 ≤ t4
t 1 + t2 ≤ t 3 + t4 t 1 t2 ≤ t 3 ; t4
t 1 ≤ t3 t 2 ≤ t4 t1 ≤ t1 . . . tn ≤ tn t ≤ t
t 1 t2 ≤ t 3 + t4 z(t1 , . . . , tn ) := t ≤ z (t1 , . . . , tn ) := t
Fig. 4. Subtyping
type definitions) is the reflexive, transitive closure of the rules in Fig. 4. A type
expression t is a subtype of t (and t is a supertype of t) if t ≤ t . Trivially,
each type is a subtype of a type expression equivalent to itself and of the most
general type ε. The type of a receive-action is a subtype of another receive-
action only if message name and parameter number are equal and the types of
the parameters in the subtype are supertypes of those in the supertype. These
contravariant parameter types ensure that each instance of a subtype can deal
with all parameters satisfying the constraints expressed in a supertype, according
to the principle of substitutability [5,11]. For the same reason, parameter types
in type definitions are contravariant.
The left-hand sides of sequential compositions must be equivalent if they
are related by subtyping.3 An example shows the reason: Assume that t1 ; t2 ≤
t3 ; t4 if t1 ≤ t3 and t2 ≤ t4 . Then, it is possible to infer m1 ; m2 ≤ ε; m2 and
(equivalently) m1 ; m2 ≤ m2 (where m1 and m2 are types of receive-actions
without parameters). But according to the principle of substitutability, m1 ; m2
cannot be a subtype of m2 because instances of the first type expect to receive
m1 as the first message, while instances of the second type expect m2 first; a
message m2 sent according to a supertype cannot be accepted by an actor that
behaves according to m1 ; m2 . Therefore, Fig. 4 does not contain this rule. On
the other side, m1 ; m2 ≤ m1 ; ε and (equivalently) m1 ; m2 ≤ m1 does not cause
such problems; a message m1 sent according to the supertype can be accepted
by an actor that behaves according to m1 ; m2 . It is always possible to extend a
supertype by adding type expressions at the end, using sequential composition.
In subtypes of alternative and parallel compositions, both sides can be sub-
types of the respective parts of the supertypes. Supertypes can be extended by
adding alternatives or type expressions specifying additional messages acceptable
in parallel. These rules are understandable through the principle of substitutabil-
ity: All messages sent according to an alternative (or parallel part) of a supertype
can be handled by an actor of a subtype with additional alternatives (parallel
3
It is possible to relax this strict condition by using a more complex set of subtyping
rules. The smaller rule set was selected in order to keep subtyping comprehensive.
Flexible Types for a Concurrent Model 467
parts). Using these argument, it is easy to see that a parallel composition can
be a subtype of a corresponding sequential or alternative composition.
We have to address the question of “what typed processes are well-typed so
that ‘message-not-understood-errors’ cannot occur”: Of course, all parameters
must be type-conforming, i.e., concrete parameter types must be subtypes of
corresponding formal parameter types. Furthermore, each sender of a message
must be sure that the receiver can deal with the message. For example, if a
variable is of a type m1 ; m2 +m3 ; m4 , the first message sent to the corresponding
mail address must be either m1 or m3 ; the second message must be m2 if m1
was sent as first message, and m4 if m3 was the first message.
In concurrent systems it is usually not known which sending actor is the first,
second, etc. to send a message to a receiving actor. Moreover, different senders
may know different types of the receiver. We have to provide precaution against
type conflicts caused by the fact that each actor has only partial information
about a receiver’s behavior. As a solution of this problem we could require that
each message accepted as the first one is also accepted in all further execution
states. In a rigid system it might be appropriate to simply restrict changes of
object behavior so that the same set of messages is accepted in each state. But
we can be much less restrictive: If an actor A behaves according to a parallel
composition t1 · · · tn so that each actor Ai (1 ≤ i ≤ n) that may send a
message to A knows only the partial type ti of A, the actors A1 , . . . , An can
independently send messages to A according to their knowledge of A’s type; all
possible interleavings of received messages can be handled by A.
We demonstrate this use of parallel type composition by a typed version of
a previous example:
It is easy to see that “tUBuffer” and “tIBuffer” are subtypes of “tBuffer”, and
“tUBuffer” is a subtype of “tIBuffer”. Furthermore, “tUBuffer” has the super-
types
tPutUBuffer := put(tElem) tPutUBuffer
tGetUBuffer := get(back(tElem)) tGetUBuffer
Clients who know that a server’s type is “tPutUBuffer” can send only “put”-
messages, and others knowing that this server is of type “tGetUBuffer” can send
only “get”-messages.
So far we used the principle of type updating only implicitly:
In the above examples, the variable v2 is initialized with the mail address of
an actor behaving according to “back(tElem)”. After sending “back” to v2 , the
type of v2 (implicitly) becomes ε; no further message can be sent to v2 .
Fig. 5 shows a solution for a version of the dining philosophers problem. The
types “tF” and “tH” represent forks on the table and in a philosophers hand, re-
spectively. A new philosopher arriving at the table puts a new fork onto the table.
When a philosopher leaves, he takes a fork on the table with him. Philosophers
send their forks (being on the table) to their left neighbors and receive forks from
their right neighbors. Hungry philosophers keep the forks and begin to eat when
they have two forks. In order to avoid deadlocks, a single token is passed around
the table. When receiving a token, philosophers must send all forks they have to
their left neighbors. Also, a thinking philosopher having the token can create a
new philosopher as his left neighbor. After receiving initial messages from their
creators, new philosophers behave like all other philosophers at the table. Eat-
ing philosophers with the token can ask their left neighbors to leave the table
(“go”). The neighbors send “done” around the table, indicating that they are
ready to go. (The argument of this message tells the asking philosopher the leav-
ing philosopher’s left neighbor.) The forks received by leaving philosophers are
immediately sent to the left neighbors; leaving philosophers don’t deal with other
messages. Each philosopher is either not yet initialized (Pn), thinking (Pth), hun-
gry (Ph), eating (Pe), waiting for a “done”-message (Pw) or leaving (Pl). Not
yet initialized philosophers are of the type “tPn”, leaving philosophers of “tPl”,
and all other philosophers of “tP”.
The example shows the principle of type updating in many places: After
sending “up” to a fork of type “tF” the type of this fork becomes “tH”; after
sending “init” to a philosopher of type “tPn” the type becomes “tP”; after
sending “go” to a philosopher of type “tP” the type becomes “tPl”, and so on.
Fortunately, the principle of type updating is statically enforceable. It would
not be necessary to associate each use of a variable with a type annotation as we
Flexible Types for a Concurrent Model 469
tF := up; tH + take
tH := down; tF
tPn := init(tP); tP
tP := fork(tF); tP + token; tP + go; tPl + done(tP); tP
tPl := fork(tF); tPl
Pn := init(x:tP); f :tF$F; x:tP.fork(f :tF); Pth(x:tP)
Pth(x:tP) := fork(f :tF); x:tP.fork(f :tF); Pth(x:tP) +
fork(f :tF); Ph(x:tP, f :tF) +
token; x:tP.token; Pth(x:tP) +
token; x:tP.token; y:tPn$Pn; init(x:tP); Pth(y:tP) +
go(f :tF); f :tF.take; x:tP.done(x:tP); Pl(x:tPl) +
done(y:tP); x:tP.done(y:tP); Pth(x:tP)
Ph(x:tP, f :tF) :=
fork(g:tF); f :tF.up; g:tF.up; Pe(x:tP, f :tH, g:tH) +
token; x:tP.fork(f :tF); x:tP.token; Pth(x:tP) +
go(g:tF); g:tF.take; x:tP.fork(f :tF); x:tP.done(x:tP); Pl(x:tPl) +
done(y:tP); x:tP.done(y:tP); Ph(x:tP, f :tF)
Pe(x:tP, f :tH, g:tH) :=
fork(h:tF); x:tP.fork(h:tF); Pe(x:tP, f :tH, g:tH) +
token; f :tH.down; g:tH.down; x:tP.fork(f :tF);
x:tP.fork(g:tF); x:tP.token; Pth(x:tP) +
token; f :tH.down; g:tH.down; x:tP.fork(f :tF);
x:tP.go(g:tF); Pw(x:tPl) +
go(h:tF); h:tF.take; f :tH.down; g:tH.down; x:tP.fork(f :tF);
x:tP.fork(g:tF); x:tP.done(x:tP); Pl(x:tPl) +
done(y:tP); x:tP.done(y:tP); Pe(x:tP, f :tH, g:tH)
Pw(x:tPl) := fork(f :tF); x:tPl.fork(f :tF); Pw(x:tPl) +
token; Pw(x:tPl) /∗ should not occur ∗/ +
go(f :tF); Pw(x:tPl) /∗ should not occur ∗/ +
done(y:tP); y:tP.token; Pth(y:tP)
Pl(x:tPl) := fork(f :tF); x:tPl.fork(f :tF); Pl(x:tPl)
F := up; down; F + take
do in this chapter for didactic reasons; the compiler can compute this information
from type annotations associated with parameters (variable initializations) in
received messages and process name specifications.
Whenever a single object shall be used in several places simultaneously, the
principle of type updating is not sufficient: A type update of one variable refer-
encing the object is not visible at other variables referencing the object. There-
fore, we additionally need the principle of type splitting which is applied when
a new variable referencing the object (an alias) is introduced:
associated with the argument, the other with further uses of the variable.
This type splitting is repeated for each use of the variable as an argument.
When this principle is obeyed, all clients can independently send messages ac-
cording to the supertypes of the servers known by the clients. Parallel composi-
tion ensures that servers can deal with all messages received from their clients
in arbitrary interleaving.
Types like “tIBuffer” and “tUBuffer” can easily be split into any number of
types. In these cases, the principle of type splitting does not restrict the usability
of objects in any way. But many types cannot be split arbitrarily. Often, a type
t can be split only into t and ε. For example, the type of forks “tF” does not
support type splitting because each messages accepted by a fork depends on each
previous message. In Fig. 5 each fork is always referenced only once. Philosopher
types are split when handling “go”-messages: The variable x of type “tP” is sent
to the left neighbor and also occurs in the following call of “Pl” with type “tPl”.
Therefore, “tP” has to be equivalent to “tP tPl”. The proof of this equivalence
using the rules in Fig. 3 is rather difficult because of the recursive definition. But
it is easy to see that “tP” supports any number of “fork”-messages in arbitrary
interleaving with the other messages specified by the type.
All type expressions have to conform to a further rule:
5 Related Work
6 Conclusions
We have shown that type expressions provide a feasible basis for statically typed,
concurrent, object-oriented languages. We proposed two principles—the princi-
ples of type updating and type splitting. They support very flexible and ex-
pressive type systems: The behavior of active objects can change; subtyping is
supported; and type-consistency can be checked at compile-time, ensuring that
each object understands all received messages.
References
1. Gul Agha. Actors: A Model of Concurrent Computation in Distributed Systems.
MIT Press, 1986.
2. Gul Agha, Peter Wegner, and Akinori Yonezawa, editors. Research Directions in
Concurrent Object-Oriented Programming. MIT Press, 1993.
3. J. C. M. Baeten and W. P. Weijland. Process Algebra, volume 18 of Cambridge
Tracts in Theoretical Computer Science. Cambridge University Press, 1990.
472 F. Puntigam
LAAS-CNRS
Laboratoire d’Analyse et d’Architecture des Systèmes
7 avenue du Colonel Roche F-31077 Toulouse cedex
{vernadat,azema}@laas.fr
1 Introduction
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 473–492, 2001.
c Springer-Verlag Berlin Heidelberg 2001
474 F. Vernadat and P. Azéma
that the system dynamism, that is the possibility of agent creation and deletion,
does not prevent a space exploration, or even an exhaustive search. Section VIII
gives some concluding remarks.
In the sequel, a local predicate next( nextref) will be associated with each
site to record the name of the next site. A philosopher has not to know the name
of the previous philosopher on the ring.
Some philosophers may not be present on the ring, and their names have to
be locally managed, because there is no centralized control.
As a consequence, each philosopher has to know some non present philoso-
phers, in order to introduce them; the names of these philosophers are supplied by
local predicate name( list of names). These predicates define a partition over
the set of all non present philosophers. A present philosopher may introduce a
new philosopher if and only if predicate name, that is the local name subset, is
not empty. Complementary, a philosopher, who leaves the table, transmits the
list of non-present philosophers he knows to one of its neighbor.
With respect to the topology structure of the table, a philosopher leaving
the table has to transmit the identity of its next neighbor on the ring to its
High Level Transition Systems for Communicating Agents 475
predecessor, so that this predecessor updates predicates next, name, that is its
local knowledge about the ring.
Figure 1 demonstrates the modification of local data associated with the
departure of a philosopher, in the case of a ring composed of several nodes
{A,B,C, . . . }.
Figure 2 indicates the modification of local data associated with the entry of a
non-present philosopher.
with an empty set of free references (name = ∅) and predicate next with value
B (the former successor of philosopher C). Philosopher C changes the successor
value to A and removes value A on its set of unused names.
create([class(_class),group(_group)],_create) :-
create_site(ring,_class,_group,_group,[],_create).
.../...
478 F. Vernadat and P. Azéma
create and create site are directly written in a prolog syntax. The input
parameters, group and class, respectively represents the list of references and
the class of the elements to be created. Clause create site produces as output
term create specifying the set of associated creations.
For instance, when group = {1, 2, 3} and class = site then produced term
create = {(site,1,[left(2)]),(site,2,[left(3)]),(site,3,[left(1)])}.
Each element of this set will be interpreted according to the creation procedure
of structure site as viewed in the previous paragraph. For people interested by
PROLOG source, here is the code:
create_site(ring,_class,_group,[],_create,_create):-!.
create_site(ring,_class,_group,[_head|_tail],_pc,_create) :-
others(ring,_entity,_group,[_left,_right]),
_npc = [(_class,_head,[next(_left)])|_pc],
create_site(ring,_class,_group,_tail,_npc,_create).
nb: others is a routine provided by the kernel and computes the identities of
adjacent sites according to a specific topology. Several topologies are available:
ring, complete graph, n-trees, bus. In the present case, the left neighbor identity
is enough to define a ring.
Structure Hurried is the highest structure in the hierarchy. The two sub-struc-
tures ring and site are declared. The creation is parameterized by the set of
references ( group). The creation consists in the ring creation of site compo-
nents referenced by group.
create([group(_group)],[(ring,@ref,[group(_group),class(site)])]).
3.2 Agent
An agent declaration (cf Table 1) is similar to a structure definition.
An agent has no sub-component and corresponds to a leaf of the architecture
tree. The agent behavior is introduced by clause body.
Clause init defines the initial state of the created instance. This state may
be derived from a parameter list: init( list of parameters, initial marking)).
The agent behavior is described in Section 4 and 6.
In the case of agent P hi, the parameter list is empty, and the initial state
is thinking. Agent man initially is idle and possesses a fork. For agent net,
the initial marking consists of two predicates. Predicate next( other) supplies a
ground value other, i.e. the identity of the next site on the ring, and predicate
name([]) defines an (initially empty) list of free references.
High Level Transition Systems for Communicating Agents 479
3.3 Configuration
Finally, the configuration file defines a specific instance of the whole system
described by the hierarchy of structures. The following configuration describes
a system constituted of 3 “philosophers“ referenced by {1, 2, 3}.
4 Description of Layers
The behavior of each agent class is defined by a specific net. In a standard way,
a net may be viewed as a set of transitions. A transition occurrence requires en-
abling conditions, or preconditions. The transition occurrence establishes conse-
quences, or postconditions. The pre and postcondition variables are constrained
by application dependant selectors. A transition depicts either an internal event,
without communication, or an external event with (possibly multiple) commu-
nication. The agent environment is modified by a transition firing when new
agents are created, or when the current agent disappears.
A transition definition consists of several fields, introduced by keywords.
T rans introduces the transition name.
F rom (resp. T o) introduces the precondition (resp. postcondition) set.
480 F. Vernadat and P. Azéma
At the upper level, the behavior of agent phi is described by the following tran-
sitions:
Trans req
From thinking
Rdv (man,@ref,ip,ask) Trans leave
To waiting From thinking
Rdv (man,@ref,ip,stop)
Trans entry Exit true
From waiting
Rdv (man,@ref,ip,entry) Trans new
To eating From thinking
Rdv (man,@ref,ip,new)
Trans release To thinking
From eating
Rdv (man,@ref,ip,stop)
To thinking
The following behavior is introduced: each philosopher possesses a fork and asks
the left neighbor for a second fork, via the topology layer, that is by means of a
rendez-vous with agent net.
Trans lending
Trans req From fork
From idle Rdv (net,@ref,previous,give)
Rdv (phi,@ref,ip,ask) To nofork
To waitnext
Trans recovering
Trans ack From nofork
From waitnext Rdv (net,@ref,previous,release)
Rdv (phi,@ref,ip,entry), To fork
(net,@ref,next,give)
To work Trans dynamic( mes)
From fork
Trans release Rdv (phi,@ref,ip, mes),
From work (net,@ref,ip, mes)
Rdv (phi,@ref,ip,exit), Cond If mes = stop
(net,@ref,next,release) then exit = true
To fork,idle else exit = fail
TO fork
Exit exit
Site Removal. Predicate name deals with references available for the creation of
a new philosopher. This data management is locally performed.
Transitions leave and change next are complementary and simultaneously
occur between two adjacent philosophers. A philosopher disappearance is decided
at the upper (application) layer, a synchronization occurs with the predecessor;
two kinds of information are exchanged: the next philosopher identity and the
available reference set. On the other side change next( Nnext), the partner
updates its successor value and the available reference set.
Site insertion
The decision to introduce a new
partner is local to a site. The site
needs an available reference in order
to name the new site. The created
site takes as “next” value, the old
one of the creating site, conversely,
the creating site updates the value of
predicate next by the identity of the
created site. The figure on the right
indicates the main creation steps.
Transmission. Agent phi knows only the left neighbor identity: predicate next
records this knowledge.
Transition to next( mes) describes the synchronization of two adjacent sites.
The condition next = @ref prevents the exit of the last element of the ring
(in the case of a ring constituted by a single element, next = @ref).
Transition from previous( mes) represents a synchronization initiated by
the predecessor site (cf transitions lending or recovering of agent man).
ground term is a term without any variable. In the sequel, G(T erms) denotes the
subset of the ground terms of T erms. The set of identifiers is denoted Identif ier.
Communications: For communication-structuring purpose, a topic is associ-
ated with any message. This concept is similar to the concept of interaction point
or gate introduced in formal description techniques.
An elementary synchronization consists of a quadruple
<Class, Ref, topic, message>∈ T erms4 where Class, Ref represents the part-
ner in the synchronization, topic the topic devoted to the synchronization and
message the message content.
The formalism allows multiple synchronisations, a synchronization is a
(finite) set of elementary synchronisations. Synchronisations is the set of all
synchronisations, Synchronisations =Def Pf (T erms4 ).
Dynamism: The creation constraint is the name conflict resolution: two distinct
instances of the same class must have distinct names. The “initial state” of an
instance of agent is specified at its creation.
An elementary creation is represented by a triple
<Class, Ref, M arking>∈ T erms2 × Pf (G(T erms)) where Class represents the
class of agent to be created, Ref its reference, and M arking its initial “state”
The formalism allows multiple creations, a creation is a set of elementary cre-
ations. We note Creations, the set of all creations.
Creations =Def Pf (T erms2 × Pf (T erms))
We note T ransitions, the set of all the transitions. We assume the existence of
an injective map from T ransitions to Identif ier furnishing an unique identifier
for each transition.
A behavior, is a (finite) subset of the set of transitions. We note Behaviour,
the set of all behaviors. Behaviour =Def Pf (T ransitions)
Interpretation: To facilitate data manipulation, logic programming (Prolog) is
used as a declarative and prototyping language. The interpretation is defined as
High Level Transition Systems for Communicating Agents 485
a set of Horn Clauses (implication with at the most one conclusion). The selector
of a condition will be expressed as a Prolog Expression. In the sequel, we note
(cond : σ) |=I true to indicate that the instance of a prolog expression cond
determined by σ holds according to interpretation I. In the sequel, we assume
the existence of a general interpretation allowing for arithmetic operations shared
by all the agents.
A Class of Agent is composed of a behavior and an interpretation. We note
Agents, the set of all agents. Agents =Def Behaviour × Interpretations
A marked instance of agent is a triple <class, ref, marking>
∈ Agents × Identif iers × Pf (G(terms))
C, a set of marked instances of agent makes a Configuration of marked in-
stances of agent if this set does not contain homonymous agent (instances of
the same class sharing the same reference), that is:
∀ <class1 , ref1 , marking1>∈ C, ∀ <class2 , ref2 , marking2>∈ C :
<class1 , ref1 , marking1>=<class2 , ref2 , marking2>
⇒<class1 , ref1>=<class2 , ref2>
We note Conf igurations the set of all configurations. Conf igurations is a
subset of Creations(Pf (T erms2 × Pf (T erms)))
A system is defined as a (finite) set of agent classes. We note Systems, the set
of all the systems. Systems =Def Pf (Agents)
C, a Configuration of marked instances of agent is valid for a system S iff
<class, ref, marking>∈ C ⇒ class ∈ S
We note V alid Conf igurations(S), the set of the valid configurations for
system S. Table 2 gives an instance of such configuration.
A marked system is finally defined as a pair (S, C) where S is the system and
C a valid configuration for S.
With respect to standard Petri Nets, the following analogies occur: a net
corresponds to a system (a set of agent classes) and a marking corresponds to a
valid configuration (a set of marked agent instances).
6 Semantics
Notations: In the sequel of the paper, (S, C) denotes a marked system and
< class, ref, marking > a marked agent instance of the configuration C. For a
transition trans =< name, . . . , cond > and a substitution σ, we note (trans : σ)
for < (name : σ), . . . (cond : σ) >
- Let t, a transition belonging to the behavior of agent class class and trans its
identifier, σ a substitution such that (trans : σ) is a ground transition instanti-
ation.
class(ref ).trans denotes transition identified by trans of the instance ref of the
agent class class and class(ref ).trans : σ the instance of the above transition
defined by substitution σ.
486 F. Vernadat and P. Azéma
∅ if [trans.exit : σ] = true
N ew marking class(ref ) =Def
{<class, ref, marking>} otherwise
Example: Consider transition new( first) of agent net (cf section 4.3) and the
state system described in table 4.
The firing of the resulting instance of transition leads to the state system1
described in table 6.
Example: Transition req of agent phi involves the following elementary syn-
chronization: (man,@ref,ip,ask), while transition req of agent phi involves
(phi,@ref,ip,ask) leading to 2 complementary rendez-vous:
(phi,@ref,man,@ref,ip,ask), (man,@ref,phi,@ref,ip,ask).
∅ if E = ∅
(E) =Def
(F ) if E = {rdv1 , rdv2 } ∪ F and rdv1 C rdv2
Enabling and Firing Rule. Let E = {Cl1 (ref1 ).t 1 : σ1 , Cl2 (ref2 ).t 2 :
E
σ2 , ...Cln (refn ).t n : σn } a synchronization transition, C =
| S=
==
==
⇒> Iff the two
following hold.
Cli (refi ).t i:σi
1) ∀i ∈ [1, n] : C −
| S−−−−−−−−−−→>
each transition of the set is enabled (in the sense of definition 6.1)
2) Create(E) ∈ V alid Conf igurations
where Create(E) =Def Cli (refi ).t i:σi ∈E [t i.create : σi ]
the set of the elementary creations involved in the Synchronization transition
makes a valid Configuration.
E E
Firing Rule: For E = {e1 , . . . en }, If C =
| S=
==
==
⇒> Then C =
| S=
==
==
⇒> C
e1 en
where C −
| S−−−−−−−−−−→
> C1 , . . . Cn−1 − > Cn = C
| S−−−−−−−−−−→
High Level Transition Systems for Communicating Agents 489
SYNCHRO(E) = {(phi,1,man,1,ip,stop),(man,1,phi,1,ip,stop),
(man,1,net,1,ip,stop),(net,1,man,1,ip,stop),
(net,1,net,2,ip,exit(3,[])),(net,2,net,1,ip,exit(3,[]))
}
and
(SY N CHRO(E)) = ∅
E
Then C =
| S==
==
=⇒> C where
{phi 2([thinking]) phi 3([thinking]),
C = man 2([fork,idle]), man 3([fork,idle]),
net 2([next(3),name([1])]), net 3([next(2),name([])])}
To check the mutual exclusion property, the observed events are, for each
philosopher, the critical section entry and exit. Weak bissimulation is considered,
the resulting quotient graph is represented in Fig. 6.
The second verification concerns the local service associated with a single
philosopher. More precisely, observed events are those occurring at the manage-
ment layer. The minimal LTS obtained in the case of safety equivalence [6] is
depicted below. Roughly speaking, class 1 corresponds to system states where
the philosopher is thinking, class 2 to states where the philosopher is waiting
and state 3 where the philosopher is eating. Since this quotient LTS is deadlock
free, we can deduce that a philosopher is itself deadlock free.
8 Conclusion
A formalism based on Logic Programming and Predicate/Transition Nets has
been introduced for describing dynamic systems by means of communicating
agents.
Multiple synchronisations are allowed. Within a transition, an agent may
specify a synchronization profile, that is a set of one to one, possibly bidirectional
High Level Transition Systems for Communicating Agents 491
rendez-vous. In Lotos [9], the synchronization operates through gates and does
not require any knowledge on the process environment. A process may specify a
rendez-vous with others processes on a specific gate without knowing the number
of these processes. From this point of view, Lotos multi-rendez-vous is more
expressive than the proposed one. However Lotos does not allow to exchange
gates as messages; this is allowed in the proposed formalism, and in higher order
formalisms such as Π-Calculus [11].
Finally, the communication profile may be computed during the transition
evaluation, resulting in greater expressive power. Comparisons have to be made
with higher order formalisms such as the Π-Calculus or Chemical Abstract Ma-
chine [3]. A first comparison has been made with the Actor formalism [16].
The proposed formalism meets the requirements introduced in the case-study
proposal, by C. Sibertin-Blanc [14,13], for the 2nd Workshop on Object-Oriented
Programming and Models of Concurrency [19,20]
Local Control: The formalism is mainly devoted to the description of dis-
tributed systems, that is agents without common memory or global control,
each agent is thus an autonomous entity.
Dynamism is an important feature of this proposal. Agents may join or leave
the system at run time. Moreover, dynamism is supported during all the design
steps, even the formal verification.
Dynamic Binding holds because the communication partners are defined on-
line, when the communication happens. Moreover, another feature (not demon-
strated here) is the dynamic specification of communication profiles, such as a
generic pattern.
Inheritance In the current state, the proposal does not allow for inheritance.
Verification The proposed formalism is supported by a transitional semantics;
there is no need to translate the description into an other kind of net. The formal
verification is conducted directly on the initial description.
A software environment V AL based on this formalism is available. The possi-
bility to describe dynamic systems, through agent creation and suppression, and
mobile processes, through addressing by name and logic unification, offer a great
flexibility to the designer. The associated execution engine includes all the fea-
tures of the presented model. The specification may be simulated for debugging
purpose or exhaustively analyzed for verification purpose, even in the case of
dynamic description. The former environment is presently used in the domain of
communications protocols and Computer Supported Cooperative Work [15,18].
References
1. Agha, G.: Actors: a model of concurrency computation in distributed systems. MIT
Press, Cambridge (Mass.), 1986
2. Banâtre, J.P., Le Métayer, D.: The Gamma model and its discipline of programming.
Science Computer Programming, Vol. 15, 1990
3. Boudol, G.: Some Chemical Abstract Machines. In: J.W de Bakker and All (Eds.),
“A Decade of Concurrency: Reflections and Perspectives.” LNCS, Vol. 803, Springer
Verlag, 1994
492 F. Vernadat and P. Azéma
4. Emerson, E.A., Srinivasan, J.: Branching Time Temporal Logic. LNCS Vol. 354.,
Springer Verlag, 1989
5. Diaz, M. and all (Eds.) The formal description technique Estelle. North-Holland,
1989
6. Fernandez, J.C, Garavel, H., Mounier, L., Rasse, A., Rodriguez, C., Sifakis, J.: A
Tool Box for the verification of Lotos programs. In: 14th Conf. on Software Engi-
neering. Melbourne, Australia, 1992
7. Genrich, H.J.: Predicate/Transition Nets. In: Jensen, K., Rozenberg, G. (Eds.),
“High-Level Petri Nets: Theory and Application.” Springer Verlag, 1991, pp 3-44
8. Lloret, J.C., Azéma, P., Vernadat, F.: Compositional design and verification with
labelled predicate transition nets. In: Clarke, E.M., Kurshan, R.P. (Eds.), “Computer
Aided Verification” DIMACS, Vol. 3, 1990, pp 519-533
9. van Eijk, P.H.J. and all (Eds.) The formal description technique Lotos. North-
Holland, 1989
10. Milner, R.: Communication and Concurrency. Prentice Hall, 1989
11. Milner, R., Parrow, J., Walker, D.: A Calculus of mobile processes. Information
and Computation, Vol. 100, pp 1-77
12. Reisig, W.: Petri Nets: an Introduction. Monographs on Theoretical Computer
Science, Springer Verlag, 1985
13. Sibertin-Blanc, C.: Cooperative Nets. Application and Theory of Petri Nets. LNCS
Vol. 815, Springer Verlag, 1994
14. Sibertin-Blanc, C.: The hurried Philosophers. Case study proposal for the 2nd
Workshop on Object-Oriented Programming and Models of Concurrency. 1996
15. Villemur, T., Diaz, M., Vernadat, F., Azéma, P.: Verification of Services and Pro-
tocols for Dynamic Membership to Cooperative Groups. Workshop on Computer
Supported Cooperative Work, Petri Nets and related formalisms, 1994
16. Vernadat, F., Azéma, P., Lanusse, A.: Actor Validation by means of Petri Nets.
In: “ Object-Oriented Programming and Models of Concurrency.”, Italy, 1995
17. Vernadat, F., Azéma, P.: Validation of Communicating Agent System. In: “Special
Issues in Object-Oriented Programming.“ Max Mühlhäuser (Ed.) dpunkt.verlag,
Heidelberg Germany ISBN 3-9200993-67-5, 1996
18. Azéma, P., Vernadat, F., Gradit, P.: A workflow specification environment. In:
“Workflow Managament: Net-Based Concepts, Models, Techniques, and Tools.” A
workshop within the XIX ICATPN, Lisbon, Portugal, 1998
19. Agha, G., de Cindio, F. (Eds.): First Workshop on Object-Oriented Programming
and Models of Concurrency. A workshop within the XVI ICATPN, Turin, Italy,
1995
20. Agha, G., de Cindio, F. (Eds.): Second Workshop on Object-Oriented Programming
and Models of Concurrency. A workshop within the XVII ICATPN, Osaka, Japan,
1996
Schedulability Analysis of Real Time Actor Systems
Using Coloured Petri Nets1
Abstract. This paper proposes a modular and real-time actor language which
addresses timing predictability through a holistic integration of an application
with its operating software, i.e., scheduling algorithm. The actor language
fosters a development life cycle where the same concepts and entities migrate
unchanged from specification down to design and object-oriented
implementation. The paper concentrates on the specification and analysis of
distributed real-time systems using Coloured Petri Nets. Both functional and
temporal properties can be validated by simulation and occurrence graphs in the
context of the Design/CPN tools.
1 Introduction
Many distributed software systems can be represented, abstracting away from time
aspects, as a set of asynchronous, autonomous components which interact one to
another in order to co-ordinate local activity. The Actor model [1] is a well
established computational framework suitable for building open and re-configurable
general distributed applications.
In real-time systems time management is fundamental: application correctness
depends not only on the functional results produced by computations, but also on the
time at which such results are generated. Timing correctness is related to guaranteeing
that a given logical behaviour is provided at the right time, not before nor after a due
time.
In the last years, Agha et al. [27, 28, 30] have proposed extensions to the actor
model in order for it to be applicable to real-time systems. The extensions rely on
capturing message interaction patterns among actors through a RTsynchronizer
1 A preliminary version of this paper was presented at the First Workshop on The Practical Use of
Coloured Petri Nets and Design/CPN, University of Aarhus, K. Jensen (Ed.), DAIMI PB-532, pp. 271-
285, May 1998.
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 493–513, 2001.
ã Springer-Verlag Berlin Heidelberg 2001
494 L. Nigro and F. Pupo
analysis and the adjustment of timing constraints, this work relies on a widely known
Petri nets language, CPN, which is semantically extended in order to support the
specification and analysis of real-time actor systems.
The CSR is a language for specifying modular and verifiable real-time systems.
Both the functional and the temporal aspects can be specified in the CSR Application
Language. Timing parameters, e.g., a deadline on the execution of a command, and
more general scheduling attributes (priorities) are part of the Configuration Language
which specifies also the CSP-like channel connections among the processes and the
mapping of processes to resources (e.g., processors) in order to assemble a system
“in-the-large”. Parameters and attributes of the Configuration Language are critical to
ensure that a system is schedulable, i.e., the hard-real-time operations meet their time
obligations. For the verification task, the CSR specification and configuration
descriptions of a system are first automatically translated into the terms of the
Calculus of CSR (CCSR) which is based on a process algebra and provides a
Reachability Analyser to validate and possibly to correct iteratively the system timing
constraints.
Besides any differences in the language notations, a key distinction between the
real-time actor model proposed in this paper and TCPN and CSR is that the
specification of an actor system is kept very close to the its design/implementation.
The CPN specification is used as a prototype which can be executed and analysed for
visualising the functional and temporal properties of the system. On the other hand,
both TCPN and CSR separate specification from design and implementation.
Verification activities are independent from the scheduler algorithm which ultimately
will orchestrate the system evolution. This work argues that the analysis and the
fulfilment of timing constraints require prototyping the specification of a system
together with its scheduling strategy.
The structure of the paper is the following. Section 2 describes the proposed
variant of the Actor model [19, 25] where reflective actors are used to capture
RTsynchronizers. Section 3 exemplifies the application of the actor concepts and
timing constraints to a crane example. Section 4 shows a translation of the actor
model into Design/CPN. Section 5 discusses the analysis of an actor-based CPN
model with a special focus on the timing verification. The schedulability of the crane
example is showed. Finally, the conclusions are presented together with directions of
further work.
A modified version of the Actor model [1] was designed [19, 25] to support the
construction of real-time applications. It centres on actors directly modelled as finite
state machines. As in the Actor model three basic operations are available:
• new, for the creation of a new actor as an instance of a class which directly or
indirectly derives from a basic Actor class. The data component of an actor
includes a set of acquaintances, i.e., the known actors to which messages can be
sent
496 L. Nigro and F. Pupo
• a local clock, which contains a “real” time reference clock for all the actors in the
subsystem
• a plan, which arranges message invocations along a timeline
• a scheduler, which filters messages, applies to them a set of timing control clauses
and schedules them on the plan. The scheduler is actually split into two actors: the
input filter (iFilter) and the output filter (oFilter). iFilter is responsible of the
scheduling actions of just sent messages; oFilter can be specialised to verifying
timing violations at the dispatch time of a message
• a controller, which provides the basic control engine which repeatedly selects
(selector block) from the plan the next message to be dispatched, and delivers it
(dispatcher block) to its receiver actor.
Control Machine
external Scheduler
messages
Real Time Clock
iFilter
schedule
“just sent local Plan
messages” oFilter
next
message
Dispatcher Selector
message delivery Controller
comms network
stamped by their dispatch time. A scheduled message cannot be delivered before its
dispatch time. Message selection is regulated by minimum dispatch time. An HRT
control machine is depicted in Fig. 1. It will be assumed in the rest of this paper along
with a discrete time model. The organisation of the message plan consists of a set of
partial ordered time validity intervals of message invocations. A message invocation
includes a message specification (identifier and data contents), its destination actor
and two pieces of timing information: tmin and tmax, tmin≤tmax. It is intended that msg
cannot be dispatched before tmin and should be delivered before tmax to avoid a timing
violation. The selector component chooses the next dispatch message on the basis of
an Earliest Deadline First (EDF) strategy.
In the architecture of Fig. 1, application actors are not aware of timing nor of when
they will be activated by a message. Actors are developed according to functional
aspects only. Timing constraints are the responsibility of the scheduler component
which hosts a set of RTsynchronizers. The approach favours modularity and
reusability. A given actor can be re-used within different applications with different
timing requirements.
The control machines of a whole system interact one to another in order to fulfil
system-level requirements. To this purpose a suitable interaction pattern (protocol)
[2] is introduced which is responsible of inter-subsystem synchronisation (e.g., real-
time barrier synchronisation [30]). For example, in [4] a specific protocol was
implemented based on the Time Warp algorithm [9] for synchronising the control
machines of a distributed simulation system. An actor system can require both local
and global co-ordination and control. A selected subsystem can host a master control
machine, where the operator, through a friendly and asynchronous graphical user
interface, can issue configuration or monitoring commands.
given pattern, i.e., a boolean expression involving message parameters and local data
of the filter. If the pattern is satisfied the corresponding timing constraint is applied,
possibly executing a scheduling action.
The following are some common examples of timing constraints. For simplicity,
they are expressed in Java syntax. The concept of a “thread of control” [32] is used to
model the chained execution of messages triggered by an environment stimulus
sensed by a periodic terminator. A thread of control defines the system response to the
stimulus. Its processing can be required to terminate within a deadline.
Periodic message
The time clause is associated with an actor (e.g., a terminator) which has a repetitive
message (e.g., ReadCO for reading the environment CO level). After being processed,
the message is sent again by the actor to itself. Message periodicity is ensured
externally to the actor in the iFilter:
Deadline on a message
A message can be required to be handled within a given deadline D measured since
the invocation time of its cause:
This construction allows to propagate the deadline of a thread among its constituent
messages.
Discarding a message
A message can be logically discarded by the following time clause
3 An Example
The following considers a simplified model of a software controlled crane [5] that can
lift and carry containers from arriving trucks to a buffer area, from where they are
taken for further handling. To carry the containers, the crane uses a magnetic latching
mechanism. Actors can naturally model the crane control system (Crane), the buffer
area (BoundedBuffer) and the operator (Console). Terminator actors control the
engine, the magnet, and the periodic item detector and left and right position sensor
physical devices. The Crane actor understands the following messages:
• On, Off (turn on and off the magnet)
• Loaded, UnLoaded (raised by the ItemDetector)
• Forward, Backward (start a forward/backward crane movement)
• RightStop, LeftStop (raised respectively by RightSensor and LeftSensor)
• Emergency (stops crane and turns off the magnet in emergency situations).
In addition, Crane exports the accessor functions: isOn, isOff, Moving, Stationary,
isLoaded, isUnLoaded, which return information about crane current state. The
Engine and the Magnet actor classes understand messages for turning their state on
and off. The Engine has also a message to setup the direction movement
(forward/backward). The ItemDetector senses when a container is loaded into the
latching mechanism, and sends a Loaded or Unloaded message to the crane. The
Position sensors capture crane limit positions where the engine should be turned off.
They transmit a RightStop or LeftStop message respectively.
Starting from a loaded container, first a Loaded message is received by crane.
Loaded causes a Forward message to be sent by crane to itself. Processing Forward in
turn generates messages for setting up the engine rotation movement and turning it
on. Then the crane enters a MOVING state where it waits for a RightStop message.
After that, the engine is turned off and a Put message is sent to the buffer area. After
Schedulability Analysis of Real Time Actor Systems Using Coloured Petri Nets 501
receiving a reply for put, the crane releases the container by turning off the magnet. It
then sends and a Backward message to itself for the backward movement.
The crane system can also be controlled by the operator at the console under the
restriction that On or Off requests are rejected while crane is moving. However, an
Emergency message has to be processed within an assigned deadline d. Fig. 2 shows
an iFilter which schedules the crane system. It is initialised with the relevant timing
attributes: period of sensors and emergency deadline. The scheduler behaviour is
captured in the handler method [25]. To each “just sent message” m the handler
applies the relevant time clause.
Self-driving periodic actors send to themselves the first periodic message during
initialisation (i.e., within the constructor). Exchanged messages during normal,
automated behaviour, are handled by a weak timing constraint with tmax being
infinite. However, an Emergency thread of control is managed according to its
deadline.
In this section a mapping from actor concepts to CP-nets is described. CPN combine
the strength of Petri nets [23], i.e., the possibility of modelling synchronisation and
concurrency problems, with the facilities of high-level programming languages which
allow the definition of powerful data types and permit the manipulation of their
values. Places of a CP-net are typed and tokens carry data values (colours). Transition
502 L. Nigro and F. Pupo
enabling depends also on the token values which can be modified by transition firing.
A binding-element represents a pair <transition, enabling token values>. CPN ML, an
extension of the functional programming language Standard ML [22], is used for
colour declarations and net inscriptions. Binding-elements are constrained by input
arc inscriptions and transition guards. Output arc inscriptions affect the construction
of generated tokens at a transition firing.
Besides the high-level character, CP-nets are provided of abstraction mechanisms
such as modularity and compositionality which are essential in the modelling and
analysis of complex systems. More in particular, the hierarchical extension of CP-nets
[13] allow to relate a transition (and its surrounding arcs and places) to a separate sub-
net (page) providing a detailed description of the activity associated to the transition.
It is possible to construct a large model from a number of pages which are
interconnected to one another according to a well-defined semantics which preserve
the same formal analysis of the corresponding non hierarchical net model.
CP-nets have also been extended with a time concept [16]. A global clock is
introduced that represents the model simulation time. In addition to its value, a token
is assigned a time stamp expressing the earliest time at which the token can be
removed by a binding-element. To be enabled, a binding-element must be also ready,
i.e., the time stamps of the enabling tokens must be less than or equal to the current
system time. Each generated token gets as the time stamp the occurrence time of the
fired transition, that is the current global time. When there is no ready binding-
element, the global clock is advanced to the minimum time stamp in the model so
enabling at least one transition. A transition can be associated with a delay δ which is
the increment to the time stamp of the generated tokens with respect to the transition
occurrence time. This means that the produced tokens are unavailable for binding-
elements for δ time units.
All these features are integrated into Design/CPN, a graphical environment for the
editing, simulation and analysis of CP-nets.
Basic components of an actor system (actors, control machine, scheduler, network
protocol, ...) can be 1-to-1 mapped on to CPN pages with well-established
interconnection pins. At a first level, a simple description of the system can be given
by ignoring component internal details. At a subsequent level a more detailed
description of the internal behaviour is specified.
At the highest abstraction level, an actor subsystem is represented by a description
page containing the (substitution) transitions Actors and ControlMachine that
respectively model the group of the application actors and the orchestrating control
machine. Each transition is refined by substituting it with a page giving the details of
the actor group or the internal components of the control machine. Actually, the
Actors page is organised as a collection of sub-pages, one per actor. Similarly, the
ControlMachine page admits sub-pages associated to its internal components (see
section 2.1). The process of substituting a transition with an inner page can be
continued until concrete sub-nets are used as substitutions. The refinement process
can purposely reuse some pages. For instance, the control machine sub-pages are
obvious candidates to be reused into different projects. Moreover, some pages can be
shared between different components, e.g., the control machine pages among the
various subsystems of a distributed system. Page reuse implies that different page
instances are actually used in the model topology. The overall page organisation of a
Schedulability Analysis of Real Time Actor Systems Using Coloured Petri Nets 503
The hierarchy page shows the net structure of the model. It is composed of three
parts:
• the System Description part, which consists of the page Crane_System
• the Actors part, which consists of eleven pages (Actors, Crane, BoundedBuffer,
Console, SensorSet, LeftSensor, RightSensor, ItemDetector, Actuators, Magnet,
Engine)
• the Control Machine part, which consists of five pages (ControlMachine, iFilter,
Selector, oFilter, Dispatcher).
The Crane_System is the topmost page in the hierarchy and it is shown in Fig. 4.
Actors and ControlMachine transitions communicate through the interface places
CMPIn and CMPOut. Each of these transitions is marked with the HS tag indicating
that it is a substitution transition and contains interface information, i.e., the
504 L. Nigro and F. Pupo
correspondence between super-page sockets and sub-page ports. For simplicity, the
interface information is omitted in Fig. 4.
The page Actors#16 contains the actor sub-pages. Some sub-pages directly model
corresponding actors (e.g., the BoundedBuffer actor page portrayed in Fig. 5), others
abstract a group of logically related actors (e.g. SensorSet and Actuators) that are
refined at a further sub-level.
The BoundedBuffer actor can receive a Get or Put message and can find itself into
one of three states: Empty, Partial and Full. An incoming unexpected message, e.g., a
Put in the Full status, is deferred by storing it in a local queue (token in the DEQ
place). Deferred messages are re-scheduled to be received again as soon as the actor
changes its current state.
The BoundedBuffer sub-net receives an incoming message in its input place BBP2
and generates new messages in the output place BBP1. These places coincide
respectively with CMPOut and CMPIn places in Fig. 4.
Owing to the high-level nature of CP-nets, the actor sub-net is reduced to a single
transition which is annotated by the actor worst case execution time. The actor
behaviour is captured by CPN ML arc expressions and some local state places. On the
other hand, it could equal be possible to derive a more articulated actor sub-net [31, 3]
which is capable of displaying more directly states and state transitions of the actor
life cycle.
The adopted modelling technique for actors has two advantages. The first one is
related to a reduction of the net complexity and therefore to a minimisation of the
state explosion problem of the occurrence graph method (see later in this paper).
Reductions are among the classical approaches [23] when analysing large systems.
Schedulability Analysis of Real Time Actor Systems Using Coloured Petri Nets 505
The second one is concerned with a reduction of the “distortion risks” during the
translation of the verified model to the target application. This is obtained by
expressing actor state transitions and actions in a form very close to the final
implementation language. This in turn facilitates an automatic translation of
specification to design and implementation [21].
Synchronous accessor methods among the actors of a same subsystem are
implemented by shared places in the subsystem page. Each such a place gets a copy
of the status of a supplier actor and can directly be read by requestor actors.
It contains a transition (iFilter) and four places. At each occurrence of the iFilter
transition, the ifilt(...) function is invoked which takes the plan message list from the
iFP2 place and the just sent message list from the iFP1 place, applies the time clauses
of Fig. 2 and generates a new plan message list. Place LDM holds a copy of the last
dispatched message which is used as a repository for inquiring about the causal
message and its attributes of a message under scheduling.
The CMMonitor place is a member of a Fusion Global set and contains a token of
the CMMon colour set which ensures that scheduling, selecting and dispatching
activities in the control machine are strictly sequenced.
The iFP2 place corresponds to the socket place Plan in the page
ControlMachine#15. This socket node is assigned also to the Plan port node of the
page Selector#6 which is represented in Fig. 8.
This page models the selection of the next message to be dispatched from the Plan.
In this case an EDF strategy is used. First the Plan message list is duplicated into the
SP4 and SP5 places. The t_marg() function appends to each message item its
temporal margin, i.e., the difference between the tmax value of the message time
window and the current time. Transition ST2 edf() function is responsible of
determining in the SP6 place the message with the minimum temporal margin which
Schedulability Analysis of Real Time Actor Systems Using Coloured Petri Nets 507
is removed (ST3 transition) from the message list copy in the place SP4. Finally, the
firing of the ST4 transition updates the Plan message list and copies the selected
message into the SP9 place for the subsequent dispatch phase.
It should be noted that for the purposes of the Crane example, the oFilter page
doesn’t apply any function to the message to be dispatched. Therefore, this page is
omitted.
The Dispatcher page depicted in Fig. 9 is in charge of delivering the selected
message to its relevant actor. The time inscription of the Dispatch transition:
@+if (tmin>time()) then (tmin-time()) else 0
allows to timestamp the message token in the DP2 place with the amount of time
possibly required to advance the system time to the message tmin.
The destination actor receives the dispatched message, processes it by firing its
action transition and generates a list of new messages. All these messages get time
stamped with the occurrence time of the actor transition augmented by the action
duration. After that the control machine resumes its activity into the iFilter component
thus starting a new cycle of the control loop.
The analysis process of an actor-based CPN model aims at verifying and possibly
correcting the specification of timing constraints and action worst-case-execution-
times in order to ensure schedulability [11, 35]. In particular, the analysis has to assert
that every thread is completed within its deadline.
Both informal and formal analysis methods can be applied. The informal analysis
can be conducted by simulating the model (specifications testing [12]), i.e., by
providing an initial marking and then by tracing one or more possible resulting
behaviours. By observing these behaviours the analyst can realise whether or not the
specified system meets functional or timing requirements. Temporal behaviour can be
verified by analysing the multiple concurrent threads especially under peak-loads.
508 L. Nigro and F. Pupo
Formal analysis consists in defining general properties of the net model which
reflect special types of desirable (or undesirable) behaviours of the specified system,
and then using the specification to formally prove (or disprove) such properties. For
this purpose the occurrence graph (OG) method [16] and the Occurrence Graph Tool
(Occ Tool) [7] can be used.
An OG is a directed graph which has a node for each reachable marking and an arc
for each occurring binding element. An arc links the node of the marking in which the
associated binding element occurs to the node of the marking resulting from the
occurrence. Such a graph may become so large, even for relatively small nets, that it
cannot possibly be generated even with the most powerful computer. Another
limitation is dependency from the initial marking: each possible initial marking may
originate a different occurrence graph.
The OGs generated for the analysis of an actor system are always timed, i.e., each
node represents a system state and contains a time value and a timed marking. Since
the typical periodic behaviour of such an RT system, it is possible to reduce the size
of an OG by choosing a simulation time during which meaningful system activity
(e.g., peak-load conditions) occurs. In addition, the adopted modelling techniques
(i.e., colour sets as intervals or enumerated values, and the adopted net structure for
actors) purposely contribute to keep under control the state space explosion problem.
All standard dynamic properties for a CP-net can be derived from its OG, e.g.,
boundedness, home, liveness, and fairness properties. They all can be investigated by
available functions in the OG Tool. Moreover ML functions can be written for issuing
non-standard inquiries to OG.
510 L. Nigro and F. Pupo
When invoked on any generated OG for the Crane CPN model, the function returns 1:
MaxTransEnabled ();
1 : int;
thus confirming that the modelled system always evolves in a predictable manner.
Indeed, when a system consists of a single subsystem there is always only one
transition enabled (belonging either to an actor or to an internal component of the
control machine).
Similarly, one such a function can capture the verification of a temporal property in
positive or negative form, provided an OG is generated for a suitable simulation
period.
To exemplify, it is possible to carry out the verification of properties like the
following: “is it always true that for each instance of a given transition firing
(representing, e.g., the beginning of a thread) there always (as the OG state space
allows) exists an instance of the corresponding transition firing (modelling, e.g., the
end of the thread) such that the time distance between them is less than a fixed time
interval (e.g., deadline of thread execution) ?”
The negative form of a property can be more immediate. In this case the existence
of a single occurrence of a searched event that contradicts the property is sufficient to
assert that the property doesn't hold.
In the crane example we have verified (see Fig. 11) that for each occurrence of the
Emergency event it always (in the generated OG) follows a transition instance
corresponding to turning off the magnet (Magnet action transition) such that the
temporal distance between the two events is less than a deadline d.
When invoked, the EmerDeadln() function always returns an empty list, proving
that the list built with Magnet transition instances which are causally connected to an
Emergency event and temporally internal to the deadline interval, is never empty:
EmerDeadln();
val it = [] : Node list
The CP-net modelling of an actor system supports an incremental development
through a modified spiral lifecycle model [36]. Functional and temporal analysis can
start as soon as a CPN specification has been produced and be based on the required
obligations (periods, thread deadlines, ...) and a preliminary estimation of actor
message processing times. As the temporal information about actors get more
accurate, i.e., the project is tuned to a physical target architecture, the CPN model can
Schedulability Analysis of Real Time Actor Systems Using Coloured Petri Nets 511
be applied again to check that the system remains schedulable. The key point is that
the CPN model closely mirrors the design/implementation models of a system.
Therefore, conclusions drawn from CPN analysis can directly be interpreted at the
lower levels of development.
The experimental analysis of the Crane system was performed on a Sun Sparc 5
with 24 MB of physical RAM.
6 Conclusions
Acknowledgments
Work carried out under MURST project “MOSAICO”. The authors are grateful to the
anonymous referee whose comments contributed to improving the paper presentation.
Thanks are also expressed to CPN group at the University of Aarhus for their support
during the experimental work with the Design/CPN tools.
References
1. Agha, G.: Actors: A model for concurrent computation in distributed systems. MIT Press,
1986.
2. Agha, G.: Abstracting interaction patterns: a programming paradigm for open distributed
systems. Formal Methods for Open Object-based Distributed Systems, Vol. 1, Najm E. and
Stefani J. B. (eds), Chapman & Hall, 1996.
3. Agha, G., Miriyala, S., Sami, Y.: Visualizing Actor Programs using Predicate Transition
Nets. Journal of Visual Languages and Computation, 3(2), June 1992, pp. 195-220.
4. Beraldi, R., Nigro, L.: Performance of a Time Warp based simulator of large scale PCS
networks. Simulation Practice and Theory, 6(2), February 1998, pp. 149-163.
5. Bergmans, L., Aksit, M.: Composing synchronisation and real-time constraints, J. of Parallel
and Distributed Computing, September 1996.
6. Cheng, A., Christensen, S., Mortensen, K.H.: Model checking Coloured Petri Nets:
Exploiting strongly connected components. WoDES’96, August 20, 1996.
http://www.daimi.aau.dk/designCPN/libs/askctl.
7. Christensen, S., Jensen, K., Kristensen, L.: The Design/CPN Occurrence Graph Tool. User’s
manual version 3.0. Computer Science Department, University of Aarhus, 1996.
http://www.daimi.aau.dk/designCPN/.
8. Fortino, G., Nigro, L.: QoS centred Java and actor based framework for real/virtual
teleconferences. Proc. of SCS EuroMedia98, Leicester (UK), Jan. 5-6, 1998, pp. 129-133.
9. Fujimoto, R.M.: Parallel discrete event simulation. Communications of the ACM, 33(10),
1990, pp. 30-53.
10. Genrich, H. J.: Predicate/transition nets. In Advances in Petri Nets, W. Brauer, W. Reisig
and G. Rozenberg (eds.), New York, Springer Verlag, 1987.
11. Gerber, R., Lee, I.: A layered approach to automating the verification of real-time systems.
IEEE Trans. on Software Engineering, 18(9), September 1992, pp. 768-784.
12. Ghezzi, C., Mandrioli, D., Morasca, S., Pezzè, M.: A unified high-level Petri net formalism
for time-critical systems. IEEE Trans. on Software Engineering, 17(2), February 1991, pp.
160-172.
13. Huber, P., Jensen, K., Shapiro, R.M.: Hierarchies in Coloured Petri Nets. In Advances in
Petri Nets, Springer Verlag, LNCS 483, 1991, pp. 313-341.
Schedulability Analysis of Real Time Actor Systems Using Coloured Petri Nets 513
14. ISO/DIS 11898: Road Vehicles, Interchange of digital information, Controller Area
Network (CAN) for high speed communications, 1992.
15. Jensen, K.: Coloured Petri Nets - Basic concepts, analysis methods and practical use. Vol.
1: Basic concepts. EATCS Monographs on Theoretical Computer Science. Springer, 1992.
16. Jensen, K.: Coloured Petri Nets - Basic concepts, analysis methods and practical use. Vol.
2: Analysis methods. EATCS Monographs on Theoretical Computer Science. Springer,
1994.
17. Jensen, K.: Coloured Petri Nets - Basic concepts, analysis methods and practical use. Vol.
3: Practical use. EATCS Monographs on Theoretical Computer Science. Springer, 1997.
18. Jensen, K., Christensen, S., Huber, P., Holla, M.: Design/CPN. A reference manual.
Computer Science Department, University of Aaurus, 1996. http://www.daimi.aau.dk
/designCPN/.
19. Kirk, B., Nigro, L., Pupo, F.: Using real time constraints for modularisation. Springer-
Verlag , LNCS 1204, 1997, pp. 236-251.
20. Kouvelas, I.., Hardman, V., Watson, A.: Lip synchronization for use over the Internet:
analisys and implementation. In Proc. of IEEE Globecom'96, London UK, 1996.
21. Kummer, O., Moldt, D., Wienberg, F.: A framework for interacting Design/CPN and Java
processes. In First Workshop On the Practical Use of CPN and Design/CPN, University of
Aarhus, K. Jensen (Ed.), DAIMI PB-532, 1998, pp. 131-150, http://www.daimi.aau.dk
/CPnets/
22. Milner, R., Harper, R., Tofte, H.: The definition of Standard ML. MIT Press, 1990.
23. Murata, T.: Petri nets: properties, analysis and applications. Proceedings of the IEEE, 77(4),
1989, pp.541-580.
24. Nigro, L., Pupo, F.: Modelling and analysing DART systems through high-level Petri nets,
LNCS 1091, Springer-Verlag, 1996, pp. 420-439.
25. Nigro, L., Pupo, F.: A modular approach to real-time programming using actors and Java.
Control Engineering Practice, 6(12), December 1998, pp. 1485-1491,.
26. Nigro, L., Tisato, F.: Timing as a programming in-the-large issue. Microsystems and
Microprocessors, 20, June 1996, pp. 211-223.
27. Ren, S., Agha, G.: RTsynchronizer: language support for real-time specification in
distributed systems. ACM SIGPLAN Notices, 30, 1995, pp. 50-59.
28. Ren, S., Agha, G., Saito, M.: A modular approach for programming distributed real-time
systems. J. of Parallel and Distributed Computing, Special issue on Object-Oriented Real-
Time Systems, 1996.
29. Ren, S., Venkatasubramanian, N., Agha, G.: Formalizing multimedia QoS constraints using
actors. Formal Methods for Open Object-based Distributed Systems (FMOODS’97), Vol. 2,
H. Bowman and J. Derrick (Eds.), Chapman & Hall, 1997, pp. 139-153.
30. Saito, M., Agha, G.: A modular approach to real-time synchronisation. In Object-Oriented
Real-Time Systems Workshop, 13-22, OOPS Messenger, ACM SIGPLAN, 1995.
31. Sami, Y., Vidal-Naquet, G.: Formalization of the behaviour of actors by coloured Petri nets
and some applications. PARLE ’91, 1991.
32. Shlaer, S., Mellor S.J.: Object Lifecycles-Modeling the world in states. Yourdon Press
Computing Series, 1992.
33. Stankovic, J.A.: Misconceptions about real-time computing, IEEE Computer, 21(10), 1988,
pp.19-19.
34. Tindel, K., Burns, A., Wellings, A.J.: Analysis of hard real time communications. Real
Time Systems, 9, 1995, pp. 147-171.
35. Tsai, J.J.P., Yang, S.J. Chang, Y.-H.: Timing Constraints Petri Nets and their application to
schedulability analysis of real-time system specification. IEEE Trans. on Software
Engineering, 21(1), January 1995, pp. 32-49.
36. Verber, D., Colnaric, M., Frigeri, A.H., Halang, W.A.: Object orientation in the real-time
system lifecycle. Proc. of 22nd IFAC/IFIP Workshop on Real-Time Programming, Lyon,
15-17 September 1997, pp. 77-82.
Control Properties
in Object-Oriented Specifications
A. Diagne
1 Introduction
Verification and Validation (V&V) are becoming the most important activities
in software engineering because of the stronger need to ensure and also enhance
quality. The quality assurance had been shifted to the earliest phases of the
software life cycle, thus disabling systematic test along the implementation as
an evaluation procedure. The engineers concerned with system design must be
aware of the specific aspects of a given system like its architecture and expected
properties. These specificities must be represented in a model of the system
and be evaluated before any realization. Evaluation of a model is twofold. A
system designer must be able to answer the couple of questions Boehm asks in
[Boehm 81]:
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 514–533, 2001.
c Springer-Verlag Berlin Heidelberg 2001
Control Properties in Object-Oriented Specifications 515
The answer to the first question is stated through the activities which en-
sure that the system or its model is traceable back to customer requirements,
it is validation (see [Pressman 92] and [Rushby 93]). The answer to the second
question is stated through the activities which ensure that the system or its
model correctly realizes specific functionalities, it is verification. V&V encom-
pass so many kinds of properties that the use of one single method is definitely
disabled. Among these aspects we stress on control properties and advocate the
use on Petri nets for their evaluation. There are some kinds of control properties
which can be considered as basic ones on system models because they mean that
some bad control happenings like deadlocks or starvation do not occur. Some
other kinds of properties are specific to a given application domain because they
represent what can be considered as good control happenings for that domain.
Petri nets is a very relevant formalism to evaluate both basic and specific
control properties like liveness, fairness, home state or terminal state, etc. Their
main drawback is the lack of structuring facilities that allow one to handle
large scale systems. Many extensions of nets aiming to overcome this drawback
have been proposed in the literature (see [Buchs 91], [Sibertin-Blanc 94] and
[Lakos 95a] as a non-exhaustive list). Almost all of them are based on integra-
tion of object-oriented contributions. 1 But in general authors do not worry too
much about the cost of integration of such extensions in existing methodologies, a
sine qua none condition to the success of Petri nets as industrial-strength formal
method. Object paradigm has gained legitimacy to cover life-cycle of systems
from requirements analysis to exhibition of a model in a language-independent
way and further to its implementation using an object-oriented language. Its
suitability comes mainly from the tight correspondence between its construction
units (object and class ) and the entities of the real world. The seamless use along
the life-cycle is an appeal for engineers who only need to win up and manage
a restricted set of concepts. In the object-oriented specification area, there are
many methodologies, each one organizes and uses the concepts according to a
given set of steps and instructions towards production of software. The steps and
instructions characterize the methodology. The specificities of a given applica-
tion domain and the skillfulness of its experts can be caught into reusable design
patterns to structure the result of a methodology (see [Gamma 95]). Granularity
and complexity of objects can be tuned to model architecture and control aspects
at a level that can be evaluated. But in general, there is no built-in facilities in
object methodologies that allow one to undertake such evaluation.
Modular and incremental constructions in Petri nets have also been inves-
tigated for verification purposes (see [Baumgarten 88], [Vogler 92], [Murata 94],
[Valmari 94] and [Schreiber 95] as a non-exhaustive list). In [Baumgarten 88],
distributed systems are structured into building blocks on which one has two kind
of functional equivalences. Internal and external equivalences and their relation-
ships allow to state about interchanging building blocks and its induced effect on
the neighborhood. An extension of external equivalence to failure semantics is
achieved in [Vogler 92] where a complete range of materials on equivalence and
1
The main trends in integrating objects with nets can be found in [Bastide 95].
516 A. Diagne
2 Design Methodology
Basic concepts enhance the decomposition of a system or its model into in-
teracting components. Each component encapsulates data and bears operations
(also called services or methods) an is called an object. Data is represented as
attributes of object (instance variables) or on classes (class variables). The data
determines the state of the object. An operation is a set of access/modification
instructions on the encapsulated data that has semantics meaning for the object
and its environment. Operation invocation may have side effects (persistent or
not) on the state of the object.
The elaborated concepts give facilities to enhance reuse and to formalize in-
teractions between objects. Composition mechanisms allow the system designer
to put control on inter-objects communication. The basic composition mecha-
nism is the functional one. With functional composition, an object is viewed a
generic parameterized entity that can be activated by receiving arguments which
are bound to parameters. In order to undertake formal activities, we must em-
phasize the notion of object compatibility. Each object is characterized by the
sequence of messages it accepts and the other objects are expected to respect
such sequences as contracts. For instance, an object modeling a file server will
accept first an open operation on an existing file, then one can repeat the read or
write operation and finishes by close. Such composition mechanism allows a sys-
tem designer to avoid propagation of faulty events. It is used in [Nierstrasz 93],
[Diagne 96a] and [Sa 96] and is a valuable way to formalize the interface of ob-
jects that was usually regarded as a record of functions. An object can have
many accepted sequences, each of them then determines a given class of clients.
1. The “how to realize” i.e. one must put in the model the information on the op-
erating cycles of the target system and its components. To fulfill this need, we
need more information about the dynamic of the objects than the axiomatic
518 A. Diagne
pre and post-conditions for the methods. The limitations of pre and post
conditions is that they are not history sensitive (see [Matsuoka 93]). With
pre and post conditions we can not ensure that an object will not receive a
message it can not yet or no longer handle (see [Puntigam 97]). Objects are
mainly active entities and their possible behaviors must be known by their
environment which must stick on that as contracts. Behaviors are implicit in
the dynamic models and need to be made explicit (see [Rumbaugh 91] and
[Rumbaugh 97]).
2. The explicit expression of expected control properties on the model. Expres-
sion of properties is often missing in classical object-oriented specification.
However, it is a rather good way to enforce engineers “to think formal”.
There is no universal good or bad properties and the best way to build a
specification with such properties is first to determine which they are. For
instance a system with a terminal state can be considered as system with one
admissible deadlock (the terminal state) and therefore reaching this state is
quite a good property. It must hence be clearly stated in the specification
and verified afterwards.
3. The explicit expression architecture of the system. This last need is harder
to fulfill. The architecture of a system is made of static and dynamic links
between its components. The static links are often not directly related to
the control. They are often integrity constraints expressed through the class
diagrams. The dynamic links are made of roles assigned to components and
the rules governing the interactions. The architecture of a system, at less in
its dynamic part, helps to understand, formalize and evaluate the synchro-
nization problems which are often tough to tackle. In a method like OMT, it
can be deduced from the dynamic model. This model hides representation of
the composition mechanism that can be highlighted by restriction to couples
of interacting objects.
Design patterns
Knowledge Domain
Object Model
Functional Model
Component
Extraction
Structure
Dynamic Model
Functionalities
Analysis and Design
Refinement
The evaluation model in figure 1 is the entry point of the Petri nets evaluation
environment. Petri nets are equivalent to high level programming languages and
all control structures can be represented (see [Jensen 90] and [Heiner 92]). So
it is rather easy to transform each object of an evaluation model into modular
colored Petri nets.
We present hereafter how the basic control structures can be modeled in Petri
nets. This is to give hints and directions to someone who wants to translate
software statements into nets. The main structures used to express control are:
Definition 1 (Preliminaries)
1. Γ n = Γ × . . . × Γ and Γ = n∈IN Γ n ,
n times
2. Cγ is the set of all the constants of the elementary color set γ, VΓ the set of
variables over the elementary color set γ and Symbγ = Cγ ∪Vγ . For a color
domain γ1 × . . . × γn ∈ Γ , Cγ1 ×...×γn = Cγ1 ×. . .×Cγn ,
Vγ1 ×...×γn = Vγ1 ×. . .×Vγn and Symbγ1 ×...×γn = Symbγ1 ×. . .×Symbγn .
3. For a given set S, Bag(S) is the set of multi-sets over S. Roughly speaking, a
multi-set is a set where elements
may occur several times. A multi-set over
a set S is formally denoted s∈S x(s).s where x(s) ∈ IN. Multi-sets can be
equipped with addition, subtraction and multiplication by an integer. The
empty multi-set is denoted .
4. As usually, •x and x• are the pre and post sets of a place or a transition in
a Petri net. If S is a set, •S and S• are the union of pre and post sets of
elements of S.3
Definition 2 (OF-CPN)
An OF-CPN is a 7-tuple (Net, Pacc , Pres , Psnd , Pget , acc−res , snd−get ) where:
1. Net is a colored Petri net (P, T, Dom, Pre, Post, Guard, M0 ) with:
3
Presentation of Petri nets can found in [Murata 89].
522 A. Diagne
An OF-CPN is a Petri net with some special subsets of places (Pacc , Pres ,
Psnd and Pget ) called the interface places. Pacc is the the set of accept places hold-
ing the tokens modeling requests accepted from the environment. Pres is the the
set of result places holding the tokens modeling results issued for requests ac-
cepted from the environment. The bijection acc−res ensures the correspondence
between incoming requests and outgoing results.
Psnd is the the set of send places holding the tokens modeling requests sent to
the environment. Pget is the the set of result places holding the tokens modeling
results for requests sent to the environment. The bijection snd−get ensures the
correspondence between outgoing requests and incoming results.
•
The interface transitions are those in Intobs = (Pacc ∪• Pres ∪• Psnd ∪ Pget
•
).
Firing these transitions consumes or produces tokens in the interface places. We
assume that there is a naming facility mapping the interface places to different
names. The interface transitions are named according to the names of places
they are connected with.
The points (7) and (8) of the definition give an operational semantics to OF-
CPN. They allow to model an operation as a sequence of elementary actions.
Point (7a) ensures that every transition producing an outgoing result belongs to
a possible sequence containing a transition that consumes an incoming request.
Point (7b) states the symmetrical assertion. Point (8a) is similar to point (7a) for
Control Properties in Object-Oriented Specifications 523
outgoing requests and incoming results. Point (8b) is the symmetrical of point
(8a). Point (8c) ensures that the computation of request is not immediate i.e. one
can not send a request and expect the result by the same transition. This point
has equivalent (point 7c) for incoming requests. This operational semantics is a
structural one. Behavioral operational semantics is also ensured by verification
(see 3.1).
Pacc1
Announce
Pres1
Trigger1 Trigger2
Psnd
Pget
Guard = fbool1(res)
Pacc2
Oper2
Exception1
Interrogation
Pres2
The V&V is run in a Petri net environment on a set of OF-CPNs (see figure
1). The aim of this work is to take profit from the natural modularity in object
orientation and avoid to build a global net from OF-CPNs by some composi-
tion mechanism (places or transitions fusion or arcs addition). We promote a
method in which V&V focus on a given object and consider an abstraction of
its environment (see figure 3). The abstraction of an object is built according
to the encapsulation equivalence presented in section 4. The abstraction of the
environment is a set of black boxes able at their interfaces to accept requests
and issue results without modeling into full details their internal control flow.
Occurrence Graphs
VIN (resp. VOU T ) is the set of vertices reachable by consuming tokens from (resp.
producing tokens in) the interface places. VIN is called the post-synchronization
set of the graph and VOU T its pre-synchronization set.
For a given vertex v, we define its post-synchronization set and pre-synchron-
ization set like following:
Two equivalent vertices are linked by paths, each of which contains at least
two synchronizations with the environment, one modeling a request or result
received and the other modeling either the result delivery of the previous request
or another request issue. In some cases, we are in presence of nested incoming
and outgoing requests, e.g. an object that needs to send a request in order to
achieve another one. In the remainder of the paper, the equivalence class of a
vertex v is noted v ∼ .
E-equivalence is stronger then I-O similarity presented in [Murata 94]. I-O
similarity corresponds to the condition (1) given in the definition 5 which means
that if vIN ∩ VIN = ∅, ∀vin ∈ vIN ,∃vout ∈vOU T, σinternal ∈ (T \ Tinterf ace ) such
that vin [σinternal ❀ vout . E-equivalence takes into account the nested requests
and allows one to look for preservation of the request-reply correspondence. This
strong condition (2 & 3) of definition 5 is enforced to check interaction faults
(see 3.1). If it is not true, then the request-reply correspondence is broken.
Some equivalence classes must be distinguished from the others. They are the
one which contains (post or) pre-synchronizations i.e. {v ∼ such that v ∼ ∩VIN = ∅
or v ∼ ∩ VOU T = ∅}. They model events occurring at the interface of the objects.
4
σ leads from w to v.
5
The in-set and the out-set are noted vIN and vOU T in the remainder of the definition.
Control Properties in Object-Oriented Specifications 527
We call them synchronizing classes. The others which are in the set {v ∼ such
that v ∼ ∩ VIN = ∅ or v ∼ ∩ VOU T = ∅} model internal events that are related
by the precedence relation of the flow control. We call them internal classes. For
all classes, we are interested in what we call entry-state (resp. exit-state). An
entry-state of a class is a state which is not reachable from any other state of the
class. An exit-state of a class is a state such that there is no other state in the
class reachable from it. For synchronization classes, the entry and exit-states are
unique. For a given class, each couple of entry and exit state is linked by a class
encapsulated path, i.e. a path which only visits states of the class. Such paths do
not involve the environment and can be hidden except for classes which verify
v ∼ ∩ VIN = ∅ and v ∼ ∩ VOU T = ∅. For such classes, the encapsulated paths are
relevant for the environment.
1. V ∼ = V/E−equivalence , E ∼ = ∅ and T ∼ = ∅,
(a) ∀ v ∼ ∈ V ∼ , if v ∼ ∩ VIN = ∅ and v ∼ ∩ VOU T = ∅, then
E ∼ = E ∼ ∪ {(v ∼ , tIO (v ∼ ), v ∼ )} ; T ∼ = T ∼ ∪ {tIO (v ∼ )},
(b) ∀ (v ∼ , w∼ ) ∈ V ∼ × V ∼ such that v ∼ ∩ VIN = ∅; and w∼ is an internal
class, so that v ∼ [t ❀ w∼ then E ∼ = E ∼ ∪ {(v ∼ , tIN (v ∼ , w∼ ), w∼ )}; T ∼
= T ∼ ∪ {tIN (v ∼ , w∼ )},
(c) ∀(v ∼ , w∼ )∈V ∼ × V ∼ such that v ∼ is an internal class; w∼ ∩ VOU T =∅,
and ∃t∈(T \ Tinterf ace ) so that v ∼ [t ❀ w∼ then
E ∼ = E ∼ ∪ {(v ∼ , tOU T (v ∼ , w∼ ), w∼ )}; T ∼ = T ∼ ∪ {tOU T (v ∼ , w∼ )};
(d) ∀(v ∼ , w∼ )∈V ∼ × V ∼ such that v ∼ and v ∼ are internal classes, and
∃t ∈(T \ Tinterf ace ) so that v ∼ [t ❀w∼ then E ∼ =E ∼ ∪{(v ∼ , τ, w∼ )};
T ∼ =T ∼ ∪{τ }6 ,
2. v0∼ is the equivalence class of v0 .
1. a path σ has an edge t ∈ pacc• where pacc ∈ Pacc and σ has no edge in
•
(acc−res (pacc )),
2. a path σ has an edge t ∈ •pres where pres ∈ Pres and σ has no edge in
(−1 •
acc−res (pres )) ,
3. a path σ has an edge t ∈ •psnd where psnd ∈ Psnd and σ has no edge in
(snd−get (psnd ))• ,
4. a path σ has an edge t ∈ pget• where pget ∈ Pget and σ has no edge in
(−1 •
snd−get (pget )) ,
An interaction failure is either “a path in which an object does not send (resp.
receive) a result for an accepted request (resp. for a sent request)” or “a path
in which an object receives (or sends) an unexpected result without any previous
request sent (or received)”. Interaction failures model starvation when waiting a
result or what is called honesty and discretion of objects in [Sibertin-Blanc 93].
They correspond to pathes that can not be reduced by E-equivalence. They must
be evaluated on the initial occurrence graph. Once interaction failures evaluated,
one can focus on reduced occurrence graph to evaluate a whole system of objects.
System Analysis. The main idea here is to prove that results which would be
obtained from the global net built from all the objects can be deduced from the
one built from their minimal representation. We consider in the remainder of the
paper a system of n (n ≥ 2) objects (Oi )i∈[1,..,n] and (Oi∼ )i∈[1,..,n] their minimal
representations. Each of the objects has an initial marking M0 (Oi ). We denote
i∈[1,..,n] (Oi ) the net built from
the objects by place fusion and conserving
∼
the initial marking of objects. i∈[1,..,n] (Oi ) is the net built from the mini-
mal representations with the initial markings of objects. OG( i∈[1,..,n] (Oi ) and
OG( i∈[1,..,n] (Oi∼ )) design the respective occurrence graphs of i∈[1,..,n] (Oi )
an i∈[1,..,n] (Oi∼ ).
530 A. Diagne
Abstracted component
Full Component
As
E-equivalence is stronger than I-O similarity, we can use the abstraction
OG( i∈[1,..,n] (Oi∼ ) to validate the reachability of states of the system according
to the results demonstrated by Murata and Notomi in [Murata 94]. Interaction
failures also can be validated on OG( i∈[1,..,n] (Oi∼ ) which costs less to compute
than OG( i∈[1,..,n] (Oi ). If the reduced occurrence graph has no interaction fail-
ure, then the global one and henceforth the system do not have interaction
failure. The terminal vertices in the occurrence graph OG( i∈[1,..,n] (Oi∼ ) must
be analyzed. Each of such vertices has restrictions on the occurrence graph of
the object which are terminal ones. So the deadlocks can be checked into details
by analyzing the faulty objects. For this purpose, we also avoid to build the
global occurrence graph OG( i∈[1,..,n] (Oi ). We build the occurrence graph for
the faulty object interfaced with the minimal representations of the others.
Object Analysis. The analysis at object level allows one to go into details of
a given object when it appears faulty in the analysis of interactions or terminal
vertices. We consider therefore the object and an abstraction of its environment.
The viewpoint from O1 is denoted O1+ = O1 ⊕ ( i∈[2,..,n] (Oi∼ )) with the initial
marking of O1 . It is built by place fusion between the whole net modeling O1 and
the minimal representations of the other objects. The corresponding occurrence
graph is noted OG(O1+ ). We consider a weak encapsulation equivalence noted
WE-equivalence on the set (Oi )i∈[1,..,n] which is the E-equivalence on (Oi )i∈[2,..,n]
In other words, the equivalence is not considered on object O1 because we want
to keep it entirely. With OG(O1 ⊕ ( i∈[2,..,n] (Oi∼ )), we can go into details of one
(or even many) object model(s). If the object O1 presents an interaction failure,
we can examine in detail the sequence(s) leading to that interaction failure. It
is a kind of local debugging on the high symbolical level of specifications. This
per-object V&V is a way to enhance reuse.
4 Conclusions
This paper presents a method whose aim is to integrate Petri nets in object-
oriented methodologies in order to validate and verify control properties. The
method is based on analysis of occurrence graph with a reduction technique. It
focuses on validation and verification of interaction between objects. The reduc-
tion technique allows one to build smaller nets to handle in order to manage large
libraries of objects. The method aims to integrate Petri nets in an object-oriented
methodology by means of design patterns. It allows one to manage a library of
objects and to build (sub-)systems in a bottom-up approach with many abstrac-
tion levels. It is a way to enhance reuse of valid objects. The design patterns
must be tailored according to the application domain and we can not be pre-
scriptive on them as the paper does not consider any domain in particular. The
reduction method allows to enhance reuse and management of objects libraries.
Once an object is validated and verified, we can henceforth use its reduction in
systems where it is reused. The reduced occurrence graph is a valuable basis to
evaluate temporal logic formula on the observable behavior of a system or its
components.
Acknowledgements
All the proofreadings done on the first versions of this paper are acknowledged
here. Anonymous reviewers have also helped by their comments and suggestions.
References
Bastide 95. Bastide R. , Approaches in Unifying Petri Nets and the Object-
oriented Approach, In Proceedings of the First Workshop
on Object-oriented Programming and Models of Concurrency,
Torino, June 1995.
Baumgarten 88. Baumgarten B., ”On Internal and External Characterizations of
PT-net building block Behaviour”, In Advances in Petri Nets,
1988, Rozenberg G. Ed., Springer Verlag, 1990, LNCS vol. 340,
pages 44-61.
Boehm 81. Boehm B., “Software Engineering Economics”, Prentice Hall,
1981.
532 A. Diagne
Bruno 95. Bruno G., Castella A., Agarwal R. & Pescarmona M.-P., “CAB :
An Environment for Developing Concurrent Applications”, In
Proceedings of ICATPN’95, Torino, Italy, June 1995, De Miche-
lis G. & Diaz M. Eds., Springer Verlag, LNCS vol. 935, pages
141-160.
Buchs 91. Buchs D. & Guelfi N., A Concurrent Object-oriented Petri Nets
Approach for System Specification, In Proceedings of the Inter-
national Conference on Application end Theory of Petri Nets,
Aarhus, Denmark, 1991, LNCS vol. 524.
Colette 93. Colette P., “Application of the Composition Principle to Unity-
Like Specification”, In Proceedings of TAPSOFT’93, Orsay,
France, April 1993, Gaudel M.-C. & Jouannaud J.-P. Eds., LNCS
vol. 668, pages 230-242.
Diagne 96a. Diagne A. & Estraillier P., “Formal Specification and Design
of Distributed Systems”, In Proceedings of FMOODS’96, Paris,
France, March 1996, Najm E. & Stefani J.-B. Eds, Chapman &
Hall, pages 325-340.
Diagne 96b. Diagne A. & Kordon F., “A Multi-Formalism Prototyping
Approach from Conceptual Description to Implementation of
Distributed Systems”, In Proceedings of IEEE International
Workshop on Rapid System Prototyping’96, Greece, Porto
Caras, Thessaloniki, June 1996, IEEE Comp. Soc. Press, Num.
96TB100055, pages 102-107.
Gamma 95. Gamma E., Helm R., Johnson R. & Vlissides J., “Design Pat-
terns : Elements of Reusable Object-oriented Software”, Addison
Wesley Professional Computing Series, 1995.
Heiner 92. Heiner M., “Petri Net Based Software Validation, Prospects and
Limitations”, Technical Report TR92-022, GMD/First at Berlin
Technical University, Germany, March 1992.
Jensen 90. Jensen K., “Coloured Petri Nets : A High Level Language for
System Design and Analysis”, In Proceedings of the Advances in
Petri Nets 1990, Rozenberg G. Ed., Springer Verlag, 1990, LNCS
vol. 483, pages 342-416.
Lakos 95a. Lakos, C. A., “From Coloured Petri Nets to Object Petri Nets”, In
Proceedings of ICATPN’95, Torino, Italy, June 1995, De Michelis
G. & Diaz M. Eds., Springer Verlag, LNCS vol. 935, pages 278-
297.
Lakos 95b. Lakos C. A. & Keen C. D., “An Open Software Engineering En-
vironment Based on Object Petri Nets”, Technical Report TR95-
6, Computer Science Department, University of Tasmania, Aus-
tralia.
Matsuoka 93. Matsuoka S. & Yonezawa A. Analysis of Inheritance Anomaly
in Object-Oriented Concurrent Programming Languages, In Re-
search Directions in Concurrent Object-Oriented Programming,
Agha G., Wegner P. & Yonezawa A. Eds., MIT Press, 1993, pages
107-150.
Mellor 94. Mellor S. J. & Shlaer S., “A Deeper Look at .. Execution and
Translation”, In Journal of Object Oriented Programming, 7(3),
1994, pages 24-26.
Murata 89. Murata T., “Petri Nets : Properties, Analysis and Applications”,
In the Proceedings of the IEEE, 77(4), April 1989, pages 541-580.
Control Properties in Object-Oriented Specifications 533
Introduction
This case study presents a standard example for evaluating formal specification
approaches that combine a formal model of concurrency (such as Petri nets)
with the object-oriented approach. You are expected to exercise your formalism
of choice on this problem in order to demonstrate how well it deals with a system
of reasonable size.
We describe how the structure of a problem can be modeled in a formalism
and how component reuse can be incorporated.
It is desirable to highlight or emphasize the way that the structure of the
problem can be modeled in your formalism, and the way that reuse of compo-
nents can be incorporated.
– Users may join or leave the editing session at will, and may join with different
levels of editing privileges. For example, a user may join the session merely
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 534–535, 2001.
c Springer-Verlag Berlin Heidelberg 2001
A Cooperative Petri Net Editor 535
to view the diagram, or perhaps to edit it as well. (See below.) The current
members of an editing session ought to be visible to all, together with their
editing privileges.
– Graphical elements may be free or owned by a user. Different levels of owner-
ship should be supported, including ownership for deletion, ownership for en-
capsulation, ownership for modification, and ownership for inspection. Own-
ership must be compatible with a user’s editing privileges.
– Ownership for deletion requires that no one else has any ownership of the
component - not even for inspection.
– Ownership for encapsulation requires that only the owner can view internal
details of the component - all other users can only view the top level or
interface to the component.
– Ownership for modification allows a user to modify attributes, but not to
delete the component.
– Ownership for inspection only allows a user to view the attributes.
– Only ownership for encapsulation can persist between editing sessions. Note
that this ownership is tied to a particular user, not a particular workstation;
all other ownership must be surrendered between sessions.
– Ownership for inspection is achieved simply by selecting the component.
– Other forms of ownership (and release) are achieved by an appropriate com-
mand, having first selected the component.
– The level of ownership of a component is visible to all other users, as is the
identity of the owner.
– The creator of an element owns it for deletion until it is explicitly released.
C. Sibertin-Blanc
Introduction
The purpose of this case study is to test the expressive and analytic power of
languages merging Petri nets and concepts of the Object-Oriented approach.
Regarding the expressive power, the main tested features are:
– local control: each object plays its own Petri net, without regard to the state
of other objects;
– dynamic instantiation: while the system is running, new objects may appear
and some may disappear;
– dynamic binding: the partner of a communication is defined when the com-
munication occurs, and not by the model (or at “compile time”);
– inheritance and polymorphism: a class may inherit some features from other
classes, and a communication happens according to the actual class of the
partner.
1. When a philosopher does not have his left fork, he can ask his left neighbor
for this fork, and the same holds for his right fork;
2. When a philosopher has his right fork and has received a request for this
fork, he must give it to his right neighbor, and the same holds for his left
fork;
3. A philosopher can eat only when he has both forks;
4. Some philosophers have the additional capability enabling them to introduce
a new guest; when a new philosopher arrives at the table, he has one plate
and one fork coming from a heap of forks;
5. Some philosophers (possibly the same ones as described above) have the
additional capability to leave the table, or to ask their right (or left) neighbor
to leave; when a philosopher leaves the table, he goes with his plate and one
fork, and he puts the fork into the fork heap;
6. Each philosopher behaves in such a way that the whole system is fair: philoso-
phers eat in turn;
7. At all times, there is at least two philosophers at the table;
G. Agha et al. (Eds.): Concurrent OOP and PN, LNCS 2001, pp. 536–537, 2001.
c Springer-Verlag Berlin Heidelberg 2001
The Hurried Philosophers 537