Two minutes example

February 8, 2006

PDF version

Firstly, we are going to write a simple COOPN class to represent a machine with state “stopped” or “running”, its equivalent of classical Petri net likes the following graph:

machine.png
Fig.1

This trivial Petri net contains two places and two transitions, where the transitions move the state of the machine from one to another. It’s a “State machine” because only and always one token exists in the net.
Supposing you’ve already create a package in CoopnBuilder, just right-click the “Coopn Source” on the package tree, a popup menu with selection “Add module” will appear, by selecting it you can add a module “Machine” in your package. After that you can use the text editor or the tree-like editor to write your COOPN codes.
Follwing are complete source of COOPN class “machine”, bold words are keywords of COOPN language:

Class machine;

Interface

Type machineType;

Methods start; stop;

Body Use BlackTokens;

Places

stopped _ : blackToken;

running _ : blackToken;

Initial

stopped @;

Axioms

start::stopped @ ->running @;

stop::running @ ->stopped @;

End machine;

In this class, we have two visible methods: start and stop, two places which represent the state of the machine: stopped_ and running_, the valid value type of the places is blackToken, this means the places can only have tokens of type “blackToken”.
The initial marking is a token in the place “stopped_”, we’ve also defined two axioms to specify the pre- and post-condition of the two transition. The axiom

start::stopped @ -> running @

says that the pre-condition of transition start is a token “@” in the place “stopped_”, after the transition, the token is moved to the place “running_”.
You’ll see that we “Use” the module “BlackTokens”, the keyword Use has the same meaning of “include” or “import” of other programming languages. The module “BlackTokens” is an ADT, it defines only one symbol “@” representing the non-typed token of Place/Transition nets.

CoopnBuilder can generate graphcal representation of classes or contexts. Just select the “GraphEdit” tab at the bottom of the editor panel, you’ll get the following graph (layout by hand):

coopn-machine.png
Fig. 2

We’ve got the same Petri net as Figure 1.

The above Petri net is more like a state machine, later we’ll show an example with multiple tokens in a place. Now we’ll use Algebraic Abstrait Data Types (ADTs) to represent tokens in Petri net: a more powerful approach to represent the state of a Petri net. The expressiveness of algebraic ADTs makes COOPN as a powerful language to modelize interactions between systems.

We define an ADT “State” with finite number of possible values: stopped and running. We mention this because ADTs may have infinite number of values, like natural and integer. ADTs can also have operations and theorems, here we just enumerate the possible values using “Generators“.

ADT State;
Interface

Sort state;

Generators

stopped : -> state;

running : -> state;

End State;

We have “stopped” and “running” as sort of state.
Then we define another machine class using State at the place of BlackToken, note that the definition of place and axioms changed but the interface (methods) did not:

Class machine2;

Interface

Type machine2Type;

Methods

start;

stop;

Body

Use State;

Place

mState _ : state;

Initial

mState stopped;

Axioms

start::mState stopped -> mState running;

stop::mState running -> mState stopped;

End machine2;

coopn-machine2.png
Fig. 3

We have another equivalent Petri net with ADT, comparing with Figure 2., we observe that:

  • only one place is need because we use an ADT State to represent the state of machine. machine2 is more compact and it’s also easy to understand.
  • from the outside of module, we don’t see the difference between machine and machine2, because the interface did not change. We are able to encapsulate a Petri net as an object and seperate its interface from its implementation (intenal behavior).

One minutes description of COOPN

February 8, 2006

PDF version

COOPN (Concurrent Object-Oriented Petri Nets) is an object-oriented specification language based on synchronized algebraic Petri nets. CoopnBuilder is an integrated development environment designated to the support of concurrent software development based on the COOPN language.
Briefly,

COOPN defines Petri nets and coordination between Petri nets using object-oriented approach.

The main characteristics of COOPN are:

  • Declarative language: using prolog-like syntax, behavior of Petri nets are defined by rules. Transitions are specified with pre- and post- conditions.
  • Algebraic Petri net based: the essential elements of a COOPN defined system are place, transition(event) and token. They are extended notion of classical place/transition nets because of their richness and complicity. It’s fairly easy to represent classical P/T nets and colored Petri nets using COOPN, the inverse is often not possible.
  • Object-oriented: a Petri net is encapsulated by means of COOPN class, only defined methods/events are visible from exterior.
  • Concurrency: the semantic of COOPN guarantees the synchronization of events of defined Petri nets, three primitive operators are: alternative, parallel and sequential.
  • Coordination: COOPN context is a higher level of encapsulation, it’s an environment model and specifies the connections of internal components: objects (instances of classes) and sub-contexts. COOPN contexts do not define Petri nets but their compositions.

The execution of COOPN uses prolog-like interference engine.

COOPN can be used to model large, concurrent, transactional, distributed systems and construct prototypes for these systems. CoopnBuilder provides the facilities to edit, verify COOPN modules, compile them into java prototype and interpret, simulate the prototype.

There are three types of COOPN module: Abstract(Algebraic) Data Type(ADT), Object and Context.

  • ADT represents data with no states and they are immutable. ADTs have operations.
  • Class has places, methods(visible transitions), non-visible transitions and gates(outgoing events). Places may contain ADT data or objects.
  • Context has methods and gates.

Methods are input events, gates are output events. Both of them can have parameters, the type of parameters can be ADT or COOPN class.

We define tokens using ADT with algebraic specifications, thus the type of tokens are richer than colored Petri nets, in addition, tokens support operations.