=Paper=
{{Paper
|id=None
|storemode=property
|title=Modeling and Simulation-Based Design Using Object-Oriented Petri Nets: A Case Study
|pdfUrl=https://ceur-ws.org/Vol-851/paper19.pdf
|volume=Vol-851
|dblpUrl=https://dblp.org/rec/conf/apn/KociJ12
}}
==Modeling and Simulation-Based Design Using Object-Oriented Petri Nets: A Case Study==
https://ceur-ws.org/Vol-851/paper19.pdf
Modeling and Simulation-Based Design Using
Object-Oriented Petri Nets: A Case Study
Radek Kočí and Vladimír Janoušek
Faculty of Information Technology, Brno University of Technology,
Bozetechova 2, 612 66 Brno, Czech Republic
{koci,janousek}@fit.vutbr.cz
Abstract. The aim of the paper is to show basic elements of a system
design methodology which uses Object oriented Petri nets. The method-
ology features conformity with UML and uses simulation as a means
to verify the models in all system development phases. Simulation also
helps in making decisions about structural and behavioral specification
of the system. The paper will demonstrate layered modeling technique
based on Object oriented Petri nets.
1 Introduction
Modeling and Simulation-Based Design (MSBD) of systems denotes a set of tech-
niques and tools intended for the software system development which is based
on formal models, model continuity, and simulation techniques. Its goal is to in-
crease efficiency and reliability of development processes including the software
system deployment. The key activities in the system development are specifica-
tion, testing, validation, and analysis (e.g., of performance, throughput, etc.).
Most of the methodologies use models for system specification, i.e., for defin-
ing the structure and behavior of developed system. There are different kinds
of models, from models of low-level formal basis to pure formal models. Each
kind has its advantages and disadvantages. Less formal models (e.g., UML) al-
lows to quickly describe basic system concepts, in the other hand, they do not
allows to check the system correctness or validity by means of testing or formal
methods—the system has to be implemented before its testing. The more ad-
vanced approaches (e.g., Executable UML and Model Driven Architecture [15])
allow to simulate models, i.e., to provide simulation testing. The pure formal
models (e.g., Petri Nets, calculus, etc.) allows to use formal or simulation ap-
proaches to complete the testing and analysis activities.
The paper aims at system specification using a formalism of Object Oriented
Petri Nets [2, 3] (OOPN). The idea of merging Petri nets and objects has been
found and elaborated in the 1990’s independently by several researchers. The
approach closest to our work is the system Renew [11] and associated formalism
of Nets-in-Nets [16, 14, 1]. Renew supports modeling of systems using layered
Petri Nets and Java language. Similarly to the system Renew, the proposed ap-
proach fully supports an integration of formal objects described by Petri Nets
254 PNSE’12 – Petri Nets and Software Engineering
and other objects (e.g., it allows to reference and communicate with Smalltalk
objects and Petri Net objects uniformly). This feature eases interfacing objects
with surrounding world and consequently facilitates hardware-in-the-loop simu-
lation. The idea of using models in all development stages, in conjunction with
hardware-in-the-loop simulation, was working up in several projects and is sup-
ported by several tools, e.g., the MetaEdit System [13] or Simulink [12]. MetaEdit
supports Domain Specific Modeling which allows to generate code from high-level
models defined for the domain-specific language. Simulink is aimed at design
control systems and hardware architectures. It allows for hardware-in-the-loop
simulation for testing designed models in a real environment. Contrary to the
works cited above, the proposed approach uses the same model in all develop-
ment phases including deployment (or final implementation). The formalism of
OOPN, in conjunction with the design and simulation framework PNtalk [5],
can be directly interpreted and, consequently, integrated into the target system
[6].
This paper summarizes methodical approach to system design using Object
Oriented Petri Nets. It is a result of previous activities on the field of system
design techniques [4, 7], modeling techniques [10], simulation testing and analysis
[8], and combination of the OOPN formalism and the UML language [9]. The
paper is organized as follows. First, we introduce the used formalism of Object
Oriented Petri Nets in section two. The section three describes the basis of design
methodology resulted from principles of Modeling and Simulation Based Design.
The next three sections deal with particular parts of design methodology includ-
ing the demonstration on the simple case study. We conclude by summarizing
of results and definition of future works.
2 Modeling Formalisms
2.1 Object Oriented Petri Nets
An object-oriented Petri net (OOPN) is a triple (Σ, c0 , oid0 ) where Σ is a system
of classes, c0 an initial class, and oid0 the name of an initial object from c0 .
A class is specified by an object, a set of method nets, a set of synchronous ports
and negative predicates. Object nets describe possible autonomous activities of
objects, while method nets describe reactions of objects to messages sent to them
from the outside. Each net is described by means of high-level Petri nets.
Object nets consist of places and transitions. Every place has its initial mark-
ing. Every transition has conditions (i.e., inscribed testing arcs), preconditions
(i.e., inscribed input arcs), a guard, an action, and postconditions (i.e., inscribed
output arcs). Method nets are similar to object nets but, in addition, each of them
has a set of parameter places and a return place. Method nets can access places
of the appropriate object nets in order to allow running methods to modify states
of objects, which they are running in.
Object nets can also contain special kinds of transitions—synchronous ports
and negative predicates. Synchronous ports are special transitions, which cannot
R. Kočí, V. Janoušek: Modeling and Simulation-Based Design Using OOPN 255
fire alone but only dynamically fused to some other transitions, which activate
them from their guards via message sending. Every synchronous port embodies
a set of conditions, preconditions, and postconditions over places of the appropri-
ate object net, and further a guard, and a set of parameters. Thus, synchronous
ports combine concepts of transitions (they have to satisfy preconditions and
guards; if the synchronous port is fired, the postconditions are performed) and
method nets (they have to be called from a guard of another transition).
A synchronous port can be activated via a message sent from a guard of some
transition. During transition fireability testing, the searching for suitable vari-
ables binding uses backtracking mechanism which takes in account also guard
expressions which can consequently test synchronous ports fireability. A syn-
chronous port can be activated with either bound, or unbound formal parame-
ters. In the second case, activation of the synchronous port can bind the formal
parameter to some value which can be further used by the calling transition.
Negative predicates are special variants of synchronous ports. Its semantics is
inverted—the calling transition is fireable if the negative predicate is not fireable.
C0 is_a PN C1 is_a PN
empty get: o x
doFor: x
x t1 p1
o o
c := C0 new. c
x p2 c init: x.
c c
init: x t2
o t3 c get: n
x t1
c empty
t1 o := Rand next s := s + n
x‘#e s s
s
x #e s
0 p2
p1
return return
Fig. 1. An OOPN example.
An example illustrating the important elements of the OOPN formalism is
shown in Figure 1. There are depicted two classes C0 and C1. The object net of
the class C0 consists of places p1 and p2 and one transition t1. The object net
of the class C1 is empty. The class C0 has a method init:, a synchronous port
get:, and a negative predicate empty. The class C1 has a method doFor:. An
invocation of the method doFor: leads to random generation of x numbers and
a return of their sum.
Let us investigate what happens if we call the method doFor: with a value
3 on the instance of a class C1 (the instance will be denoted by obj1). First,
the transition t1 is fired with following actions: the instance of the class C0 is
created (the instance will be denoted by obj0) and the symbol #e is put to the
place p1 of the object net obj0 three times (see the method net init:). Now, the
object net of obj0 generates three random numbers (the transition t1) and puts
256 PNSE’12 – Petri Nets and Software Engineering
them into the place p2. Second, the transition t2 of the object net obj1 tests if
there is any random number in the object net obj0—then the synchronous port
get: is firable. If the transition t2 fires, the synchronous port get: fires too.
Since the variable n is unbound, the calling binds any random number from the
place p2 of the object net obj0 to the variable n. The transition t2 of the object
net obj1 then adds this value to the sum (the variable s). Third, the transition
t3 of the object net obj1 tests if there is no random number in the object net
obj0—then the negative predicate empty is firable. If the transition t3 fires, it
places the sum (the variable s) to the return place as a method result.
3 Modeling and Simulation Based Design Technique
Modeling and Simulation Based Design (MSBD) is a technique of system design
where the system is specified in a form of an executable model which can be
verified using simulation experiments. During the development, the model is
incrementally refined and each development step is tested and verified. There are
two phases which rotate until the system development is finished: Modeling phase
and simulation phase. We will especially take into account the techniques of the
modeling. In the following sections, we will demonstrate their basic concepts in
a small case study.
3.1 Modeling Technique
The modeling technique is focused on the technique of system description, i.e.,
how the models are created. The technique stems from the classic approach of
class identification and definition and extends it to the new features. The design
process comprises:
– the identification of use cases of the system,
– the specification of roles and active subjects,
– the specification of activity nets—it is similar to workflow modeling,
– the specification of application nets.
The models are layered hierarchically as shown in Figure 2. Each arrow shows
what layers encapsulated another ones. There is a special relationship between
use cases in UML and activity nets, and roles in UML and roles nets. These
mentioned nets represent appropriate use cases and roles in the system (see the
sections 4 and 5). Each role net encapsulate one active subject (see the section
4.1). Each role encapsulate activity nets (see the section 5.3). Moreover, each
role can encapsulate another role, and the active subject can also encapsulate
another active subject. It allows to get a new view to the role (or active subject)
based on the existing one.
The way of system usage is defined by application nets which encapsulate
roles nets. Each role has its own set of allowed activities which offers to appli-
cation nets. The application net can then instantiate and use this activity (see
R. Kočí, V. Janoušek: Modeling and Simulation-Based Design Using OOPN 257
the section 6). The execution of layered nets are synchronized by means of syn-
chronous ports. The nested nets define synchronous port for synchronization of
executions and the net at higher layer is controlled by calling these ports. This
principle will be demonstrated at the appropriate places in following parts.
Fig. 2. The layered architecture: an overview.
The design activities are performed in a sequence use cases–roles and sub-
jects–activity nets–application nets. But, the system is developed incrementally,
in each step, we model selected parts, make decision what part is to be modeled
at what layer, and, if necessary, we decide what nets should be changed. Thus,
the developer has to go back to designed layer and modify them. The decisions
are supported by simulation techniques, i.e., designed models are simulated, the
statistic data can be collected, the condition testing can be performed, etc.
3.2 Case Study
We will demonstrate the key features of presented modeling technique on the
simple case study. It concerns the reservation system whereas the structure and
workflow is only taken into account. The real data associated with the real system
will not be modeled.
As we mentioned in the brief description of design process, the process starts
with use cases identification. The use case diagram is one of the key diagrams in
system specification defined by the Unified Modeling Language (UML). The use
case defines a functionality of the system, it is usually complex set of functions
to achieve a particular behavior. There is a set of actors who can interact with
the use case. The use cases of our case study is shown in Figure 3—there is one
actor and two use cases. It represents a system allowing users (an actor User ) to
sign up to the system (a use case Login) and to edit its reservations (a use case
Edit Reservation). In UML, the use case is supplemented with its specification
258 PNSE’12 – Petri Nets and Software Engineering
Fig. 3. The use case diagram.
(a text description or other models from UML). Presented technique supposes
that the use case is specified by OOPN as will be demonstrated in the section 5.
4 Roles and Active Subjects
4.1 Specification of Active Subjects
Each actor from use case diagrams has its own subset of use cases it can partic-
ipate with. However, different actors usually have the same basis, e.g., the user
represented by its name can act as different actors (administrator, customer,
manager, etc.) having different set of behavior (use cases). So we can identify
active subjects (e.g., person) and their roles (e.g., customer, manager). Although
we call it an active subject, it does not perform any autonomous action. It only
models current state and possible actions shared by all its roles.
type
notType: t t t type: t
name
n name: n
reservations
notRes: r r s res: s
r
changeRes: nR
nR r id = nR id
Fig. 4. The active subject Member (modeled as OOPN class).
The example of an active subject is shown in Figure 4. It depicts the object
net of OOPN class Member storing information about person’s name, type, and
set of reservations. The type is a set of role identifications the member can act
as. Attributes are stored in places (name, type, and reservations) and are
R. Kočí, V. Janoušek: Modeling and Simulation-Based Design Using OOPN 259
accessible by means of synchronous ports. Ports including negative predicates
can also serve for testing whether some value of the attribute is set or not.
In real system, the reservations should be stored in some database system,
but it is possible to use places for the same purpose for a relative small number
of records. But, in this case, there is a problem how to model the iteration of
the place content effectively, e.g., if we want to show list of records. The arc
between the place reservations and the synchronous port res: is denoted by
a symbol . It means that the variable s is bound to whole content of the
place and this content is accessible as a list (the list is assigned to the variable
s). Then it is possible to use conventional approach to this list. To change a
reservation, the synchronous port changeRes: is defined. Each reservation has
its unique identification accessible via a call id. The event is fireable, if there is
the reservation (r) in the place reservations with the same identification as
the given one (nR). Then the old reservation is replaced by its new variant.
4.2 Specification of Roles
The member can act in different roles—for our needs we will describe only one
role called User. The role is modeled as an object net of OOPN class User. The
example is shown in Figure 5. The role should know about an active subject
this role is intended for. In our example, this information is stored in the place
member.
member
notMember: m m m member: m
member m m noMember
for: member
m m
t2 t1
self member: mm self noMember
self fail: ’...’
true
false
return
Fig. 5. The role User (modeled as OOPN class).
The net User defines two testing negative predicates notMember: (it is true
if the role does not represent given member m) and noMember (it is true if there
is no represented member) and one synchronous port member:. The synchronous
port can server for testing (if the role represents given member m) or for attribute
collection (the example will be shown in chapter 5).
260 PNSE’12 – Petri Nets and Software Engineering
The attributes should be initialized by method nets. Figure 5 shows one net
as an example. The method net for: initializes the attribute member and tests
if the role was not initialized yet. If the role is not initialized, the transition
t1 is fireable (the negative predicates noMember is true). If the role is already
initialized, the transition t2 is fireable (the synchronous port member: is true
for a member m). In this case, the method net returns false and can generate
an exception (the calling of self fail: ’...’); it is useful for testing.
4.3 System as a Special Role
The system usually needs means for persistence, accessing shared objects etc.
For this purposes, we introduce a special role net called Application (see Figure
6). It allows for getting members (the external event member:), storing logged
users (the external event newUser:), etc.
members
notMember: m m m member: m
loggedUsers
notRegistered: u u u newUser: u
u logout: u
Fig. 6. The role Application (modeled as OOPN class).
5 Activity nets
5.1 Specification of Activity nets
An activity net describes a use case of the system. Each use case is modeled as an
OOPN class. Its object net contains transitions, synchronous ports, and places.
Since a transition is conditioned only by its input places, it models internal event
in the activity. On the other hand, a synchronous port is intended for activation
from the outside of the activity object. Therefore the synchronous port represent
external event. Each place in the activity net represents the state of the activity.
The state can be tested by means of synchronous ports or negative predicates.
Let us demonstrate this principles in our small example. The example defines
Member’s role User who participates in the use case editReservation. The activity
net which corresponds to the use case is modeled by the object net of OOPN
class EditReservation which is shown in Figure 7. The activity net has to know
about the role which is associated with the activity. The role is stored in the
R. Kočí, V. Janoušek: Modeling and Simulation-Based Design Using OOPN 261
place user. This attribute should be initialized by a method net—because the
concept is similar to the net intended for the same purpose (e.g., the net for:
in the role User), the implementation is not shown here.
ready
notReady
finish
user
u show: s
u member: m. m res: s
showing
notShowed finish
edit: r
r
editing
notEdited r r
r
confirm: r cancel: r
u u member: m.
m changeRes: r
Fig. 7. The activity EditReservation (modeled as OOPN class).
The basic workflow consists of following events: list of reservations represen-
tation (see the external event show:), one reservation editing (the external event
edit:), and confirmation (the external event confirm:) or to cancellation (the
external event cancel:) of changes. The net defines three places representing
three states of the activity (ready, showing, and editing). The activity can be
finished from states ready and showing by external event finish.
It is possible to add synchronous ports for testing activity states. There are
defined events for testing whether the activity is not in the defined state, modeled
as negative predicates notReady, notShowed, and notEdited. This predicates are
true (fireable) only if the state is not satisfied.
5.2 Specification of Actions
The activity usually needs to define some actions. Actions are associated either
with internal events or with external events. In the case of internal events, actions
are defined inside the transitions (in the action part) or in subnets—then the
net is modeled as a method of the appropriate OOPN class and is called from
the internal event. In the case of external event, actions are modeled by calling
another external events (synchronous ports) from the event’s guard.
262 PNSE’12 – Petri Nets and Software Engineering
Figure 7 shows the second approach. For example, the external event show:
detects the member which is represented by the role User (calling the syn-
chronous port u member: m—because the variable m is unbound, the object net
Member stored in the place member in the object net User is bound to the variable
m). Then the synchronous port m res: s is called and the variable s then the
bound to a list of reservations. The transition, which calls this event, can then
use this list (it is shown in the chapter 6).
ready
login: name as: type
(name, type)
nested
verify (name, type)
u := self verify: name as: type
u a
u u
notVerifiedUser user verifiedUser: u
u = nil u != nil. a newUser: u.
Fig. 8. The activity Login.
Figure 8 shows the activity net Login corresponding with the use case Login.
The basic workflow consists of following events: user’s data getting (the external
event login:as:), the data verification (the internal event verify), and testing if
the desired role has been created (the external event verifiedUser:) or not (the
external event notVerifiedUser). The action of user verification is associated
with the internal event modeled as the sub-net verify:as: called from the
internal event verify. The sub-net is not shown because its implementation is
not important for this paper.
There are also actions associated with the external event. If the user is ver-
ified and its role is detected (the external event verifiedUser:), one action is
performed—adding the role into the special role Application (a newUser: u);
see the section 4.3.
5.3 Instantiation of Activity Nets
The activity nets have to be instantiated to serve for their purpose. Because
each activity is usually allowed for only specified roles, it is just a role which can
instantiate an activity. The example for the role User is shown in Figure 9 on the
left. The role allows for reservation editing so that the role defines the method
net newEditReservation which creates a new activity net for reservation edit.
R. Kočí, V. Janoušek: Modeling and Simulation-Based Design Using OOPN 263
Each activity has to know for which role it is created—it is set by the message
for:.
newEditReservation newLogin
p1 p1
t1 t1
n := EditReservation new. n := Login new.
n for: self. n for: self.
n n
return return
Class User Class Application
Fig. 9. The methods creating instances of activities.
There is a special kind of activity nets associated with the system instead of
the role. These activities are instantiated from special roles as they was intro-
duced in the section 4.3. As an example we can take an activity of user login
associated with the role Application. Figure 9 on the right shows the instanti-
ation of the activity net Login from the role Application; the principle is same
as in ordinary roles.
6 Application Nets
Application nets model a presentation layer of the system. We can also imagine
it as an interface to the system. The application net uses roles to generate a
list of permitted activities and to instantiate the concrete activity net. The
particular behavior of application nets is then controlled by the appropriate
activity net. The application nets execution is synchronized by means of external
events (synchronous ports) of control (activity) nets.
The presented case study needs some kind of user interface—the part of appli-
cation net UserInterace is shown in Figure 10. The application net UserInterface
represents an interface to behavior of one role of User—how the user can work
with the system. The net knows the user (i.e., the role User) and the special role
Application.
Let us investigate the modeled functionality of the application net. First,
the transition login tests if the user is logged to the system (see the negative
predicate noUser). If there is no logged user (no role User is stored in the place
user, the activity net Login is created (via the special role Application) and
then the method net loginUser: is called. Its execution is controlled by the
activity net Login using synchronous ports and negative predicates. If the login
action is successful, the created role User is placed into place user. If the login
action failed, the procedure is repeated, i.e., the transition login is fired again.
264 PNSE’12 – Petri Nets and Software Engineering
en
show: en
en en
t1 t2
en notReady en show: s
"not allowed" "to show a list"
login
nil s
self noUser
ln := a newLogin.
return self loginUser: ln.
ln a a
loginUser: ln
ln
t1
application
d := self openLoginForm. (ln, n, t)
n := d name.
t := t type.
(ln, n, t) edit
ln
ln login: n as: t
ln ln t1
ln notVerifiedUser ln verifiedUser: u en := u newEditReservation.
nil u en
user
return u u return
noUser u
Fig. 10. UserInterface. The topmost level of the application modeled as OON class.
The procedure can be performed at most one at the same time. It is assured by
the precondition of the transition login to the place application.
Second, if the logged user perform an action edit reservation, the activity
net EditReservation is created (see the transition t1 in the method net edit).
The activity net then serves as a control mechanism watching if some operation
is allowed or not. For example, the method net show: makes decision if it is
possible to show the reservation list (the activity net is in appropriate state) on
not. The method net has show: one parameter en of the activity net which is
used for control.
The model of application net uses rather asynchronous processing of events.
For instance, the methods edit and show represent fragments of a behavior
controlled by the activity net EditReservation. Each fragment is called as a
reaction to the event. For example, there can be generated a graphic user inter-
face offering a button to start reservation editing—if the actor press this button,
it generates an event and the method net edit is called and the instance of
activity net EditReservation is created. Then, the first event of activity is to
R. Kočí, V. Janoušek: Modeling and Simulation-Based Design Using OOPN 265
show a list of reservation—as a reaction, the method net show: is called. Its
execution checks the activity state and collects a list of reservations (calling the
synchronous port en show: s in the transition t2). Then the list can be dis-
played. The details of graphics user interface and its cooperation with application
nets are not described here.
7 Conclusion
The paper dealt with Modeling and Simulation Based Design using the formalism
of Object Oriented Petri Nets. It presented the key ideas of a modeling technique
which is based on layered approchach. The presented approach is a part of the
development methodology, which allows to use formal models in all phases of
system development including as basic design, analysis and also programming
means with a vision to allow to combine simulated and real components and to
deploy models as the target system with no code generation.
So far, the models are interpreted in deployed application and are connected
to other software components. The advantage is a possibility to monitor, to pro-
file, to test, and to debug application at the model level with no needs to model
transformations. The disadvantage is a possible inefficiency of the model inter-
pretation. Therefore we plan to investigate an approach allowing to transform
models into low-level models. Nevertheless, this transformation have to fulfil a
condition of having a view to the system at the model level. It means, that it has
to be possible to get a state from low-level models and to impose a new state to
the low-level model.
Acknowledgment. This work has been partially supported by the European
Regional Development Fund in the IT4Innovations Centre of Excellence project
(CZ.1.05/1.1.00/02.0070), by BUT FIT grant FIT-11-1, and by the Ministry of
Education, Youth and Sports under the contract MSM 0021630528.
References
1. L. Cabac, M. Duvigneau, D. Moldt, and H. Rölke. Modeling dynamic architec-
tures using nets-within-nets. In Applications and Theory of Petri Nets 2005. 26th
International Conference, ICATPN 2005, Miami, USA, pages 148–167, 2005.
2. M. Češka, V. Janoušek, and T. Vojnar. PNtalk — a Computerized Tool for Object
Oriented Petri Nets Modelling, volume 1333 of Lecture Notes in Computer Science,
pages 591–610. Springer Verlag, 1997.
3. V. Janoušek and R. Kočí. PNtalk Project: Current Research Direction. In Simu-
lation Almanac 2005. FEL ČVUT, Praha, CZ, 2005.
4. R. Kočí and V. Janoušek. System Design with Object Oriented Petri Nets For-
malism. In The Third International Conference on Software Engineering Advances
Proceedings ICSEA 2008, pages 421–426. IEEE Computer Society, 2008.
5. R. Kočí and V. Janoušek. On the Dynamic Features of PNtalk. In International
Workshop on Petri Nets and Software Engineering 2009, pages 189–206. University
of Pierre and Marie Curie, 2009.
266 PNSE’12 – Petri Nets and Software Engineering
6. R. Kočí and V. Janoušek. Simulation Based Design of Control Systems Using
DEVS and Petri Nets, volume 5717 of Lecture Notes in Computer Science, pages
849–856. Springer Verlag, 2009.
7. R. Kočí and V. Janoušek. Towards Simulation-Based Design of the Software Sys-
tems. In The Fourth International Conference on Software Engineering Advances
– ICSEA’09, pages 452–457. IEEE Computer Society, 2009.
8. R. Kočí and V. Janoušek. OOPN and DEVS Formalisms for System Specification
and Analysis. In The Fifth International Conference on Software Engineering
Advances, pages 305–310. IEEE Computer Society, 2010.
9. R. Kočí and V. Janoušek. Towards Design Method Based on Formalisms of Petri
Nets, DEVS, and UML. In ICSEA 2011, The Sixth International Conference on
Software Engineering Advances, pages 299–304, 2011.
10. R. Kočí, V. Janoušek, and F. Zbořil. Object Oriented Petri Nets - Modelling
Techniques Case Study. International Journal of Simulation Systems, Science &
Technology, 10(3):32–44, 2010.
11. O. Kummer, F. Wienberg, and et al. An Extensible Editor and Simulation Engine
for Petri Nets: Renew, volume 3099 of Lecture Notes in Computer Science, pages
484–493. Springer Verlag, 2004.
12. MathWorks. Simulink – Simulation and Model-Based Design.
http://www.mathworks.com, February 2010.
13. MetaCase. Domain-Specific Modeling with MetaEdit+.
http://www.metacase.com, February 2010.
14. D. Moldt. OOA and Petri Nets for System Specification. In Object-Oriented
Programming and Models of Concurrency. Italy, 1995.
15. C. Raistrick, P. Francis, J. Wright, C Carter, and I. Wilkie. Model Driven Archi-
tecture with Executable UML. Cambridge University Press, 2004.
16. R. Valk. Petri Nets as Token Objects: An Introduction to Elementary Object Nets.
In Jorg Desel, Manuel Silva (eds.): Application and Theory of Petri Nets; Lecture
Notes in Computer Science, volume 120. Springer-Verlag, 1998.