The CoOperative Objects Formalism

 

CoOperative Objects (COOs) are a formalism allowing designers to model a system as a collection of high level objets, which encapsulate their multi-threaded control structure and cooperate through a request /reply protocol.

A system is viewed as being defined by the following rules:

System = Objects + Cooperation

Object = Data structure + Operations + Behavior

 These features are gained through the integration of concepts of the object-oriented (O-O) approach and Petri nets (PN), so that COOs have a high expressive power, including the modeling capabilities of both the O-O approach and Petri nets. Concepts of the O-O approach are used to define the general organization of a system (classification and dynamic instantiation, encapsulation, distinction between the specification and the implementation, inheritance, dynamic linking and polymorphism) and also to define the data processing dimension of a system (instance variables and methods). As for Petri nets, they are used to define the internal control structure of each object (intra-object concurrency), and also the communication and synchronization between objets (inter-object concurrency). So the designer benefits from the well known facilities provided by the O-O approach, and from the suitability of PN to deal with concurrency issues.

COOs are supported by SYROCO, a C++ based environment allowing designers to edit and implement COO classes.

COO classes

The structure of each Object is determined by the class of which it is an instance. An Object is equipped with attributes and functions for the processing of these attributes (the Data and Operations dimensions). It is also equipped with a control structure which defines all its potential behaviors (the Behavior dimension). This control structure is described by means of a High-Level Petri net, which allows an Object to have several concurrently on going activities; transitions occur one by one, but these occurrences may belong to different activities so that these activities progress in turn.

Thanks to this internal concurrency, each Object is able to concurrently:

Classes may be organized in accordance with several inheritance relationships which authorize the polymorphism and the sharing of items.

The definition of COO classes requires a sequential O-O programming language to deal with their data processing aspect, and SYROCO uses the C++ language for that purpose. C++ is used to write the embedded code of Objects, that is the code of operations and pieces of code which appear in various locations of the control structure net. It is also used to write the additional code which includes the definition of types, functions and constants which are shared by the Objects of a system.

COO systems

A COO system is a collection of such Objects. The Cooperation dimension determines circumstances in which an Object of a certain class may (or must) interact with another one. These interactions obey to a request / reply protocol. Interactions corresponding to a data flow are synchronous (when a client requests an operation, it blocks until the server provides a result), while interactions corresponding to a control flow are asynchronous (when a client requests a service, its other activities go on as long as they are not blocked).

To a large extent, the Objects of a system are autonomous. There is no central control and the behavior of the system results from the concurrent behavior of each Object and the way they cooperate. In addition, a COO system is open: during its evolution, new Objects can be dynamically created, yet some others can disappear.

Thus, the definition of a COO system includes the definition of its additional code, the definition of the COO classes appearing in this system, and its initial configuration. This initial configuration usually is an instance of a COO class which, at the time of its initialization, produces the creation of other Objects composing the initial state of the system.

Publications,
definition of COO classes, SYROCO
The Stack example, The Dynamic Philosopher example

IRIT, DAIMI

Mail to: C. Sibertin-Blanc