At first glance, a CoOperative Object looks like the gathering of an object, as they are usually defined in compiled Object-Oriented Languages, and a Petri net determining its internal behavior. To be more precise, a COO is composed of a set of attributes, a set of operations, a control structure net called its OBCS, and a set of services supported by this OBCS.
Operations are methods in the usual meaning. The type of their parameters belongs to the additional code or is a COO class, and their code is written using the C++ language. Some of these operations are private, while others are public.
Public attributes and operations of an Object may be used by other Objects in any place of their embedded code, and they allow for synchronous communications: reading the value of an attribute or calling an operation blocks the client until it gets a result. Thus, a public operation must be designed in such a way that, in any case, the Object is able to immediately provide a result.
Places are the state variables of the Object. The type of a place either belongs to the additional code, or is a COO class reference, or is a list of such types, and a place contains tokens of this very type. Accordingly, a token is either a constant value, a reference toward an Object, or a list of such items. The net state (or marking) is defined by the distribution of tokens into places and the value of these tokens.
Transitions aim at changing the net state, that is the tokens’ value and location.
Transition are connected to places by oriented arcs. Arcs are labeled with variables acting as formal parameters of transitions. They define the flow of tokens from input places to output places, and determine what tokens the transition action is applied to.
A transition may be guarded by a precondition, a side-effect free boolean expression involving Object’s attributes and variables labeling its input arcs.
A transition may include an action which consists either in a request for a service of another Object, or in a request for the creation or the deletion of an Object, or in any piece of C++ code in which calls for operations may take place.
A transition may also be provided with a list of boolean expressions called emission rules. In this case, each output arc is connected to one emission rule. At the end of an occurrence of the transition, the emission rules are evaluated, and only the arcs starting from to the first rule to evaluate to true are activated.
A transition may occur (or is enabled) if its input places contain tokens to which its input variables may be bound, in such a way that the precondition evaluates to true.
The occurrence (or firing) of an enabled transition changes the marking of its input and output places. Tokens bound to input variables are removed from input places. At that time, the action of the transition is executed. The transition occurrence completes by evaluating the emission rules if any, creating tokens according to variables labeling output arcs, and putting these tokens into output places.
Executing an OBCS consists in repeatedly firing transitions which are enabled from the current marking, starting from the initial marking.
Each Service of a COO is implemented by a couple of places of its OBCS: an accept-place intended to receive tokens which are requests for the service (each token groups together the parameters of a call), and a result-place in which the client retrieves the result of its invocation.
A service request is treated by a sequence of transition occurrences: the first transition of this sequence takes the request token from the accept-place, while the last transition puts a token down in the result-place. Graphically, accept- and result-places do not appear in the OBCS, but transitions connected to them by an arc (respectively referred to as accept- and return-transitions) are pointed out by a dangling arc bearing the parameters as variables.
A service is called by a client only in the action of a transition, through the following syntax:
Its semantics is defined according to the client / server protocol:
It is possible that the occurrence of a transition including a service request lasts some time until the server provides the result. But a client is not blocked by a service call, since other transitions may occur during this time. Indeed, the formal semantics of a transition including a service request is defined by splitting the transition into one transition for sending the request-token and one transition for retrieving the result-token, and connecting these two transitions by a waiting place which holds the request identifiers. This semantics is implemented by the code generator of SYROCO.
As a conclusion, the OBCS of an Object fully determines its behavior:
Syntactically speaking, the definition of a COO class is made up of a specification and an implementation. The specification of a COO class corresponds to its interface; it includes contextual clauses, the definition of its public attributes and operations, and the declaration of its services. The contextual clauses mention the types of the additional code and the COO classes which are referred to or inherited. On the other hand, the implementation of a class includes contextual clauses, the definition of its private attributes and operations, and its OBCS.
A COO class may be edited either as a text file or using the graphical Petri Nets editor MACAO.
The Stack example, The Dynamic Philosopher example
Mail to: C. Sibertin-Blanc