Informal Presentation of ICO
(for a formal presentation see article)
The ICO formalism is a formal description technique dedicated to the specification of interactive systems [1]. It uses concepts borrowed from the object-oriented approach (dynamic instantiation, classification, encapsulation, inheritance, client/server relationship) to describe the structural or static aspects of systems, and uses high-level Petri nets [1] to describe their dynamic or behavioral aspects. The ICO notation has evolved since to address news challenges raised by the various application domains it has been applied to. This paper presents the current version with the last extensions.
ICOs are dedicated to the modeling and the implementation of event-driven interfaces, using several communicating objects to model the system, where both behavior of objects and communication protocol between objects are described by the Petri net dialect called Cooperative Objects (CO) [2]. The following paragraphs briefly recall basics about Petri nets and their extensions in order to finally present the main features of the ICO formal description technique.
Petri nets (PN)
Petri nets were initially introduced in C.A Petri’s PhD thesis in 1962 and are used for modeling discrete event systems. Petri nets are a formalism that features a complete equivalence between a graphical and an algebraic representation. We present here the basics of Petri nets through their structural aspects and their dynamic behavior.
Structure
A Petri net is an oriented graph composed of two disjoint sets of nodes and a set of arcs:
-
Places (represented by ellipses) symbolize states variables holding untyped tokens which symbolize values.
-
Transitions (represented by rectangles) symbolize actions and state changes.
-
Arcs link places to transitions (called input arcs), or transitions to places (called output arcs), and symbolize the flow of tokens through the Petri nets. Arcs may be given integer values which are described as the weight of the arc, e.g. the quantity of tokens that is consumed following this arc.
The global state of the modeled system is fully represented by the distribution of tokens across the set of places (called marking).
Dynamic behaviour
Given a marked Petri net, its behavior is expressed in terms of a token game. The token game defines two basic rules, the enabling rule and the firing rule:
-
Enabling of transition: the enabling rule involves input arcs of a transition. A transition is enabled if each input place (places linked to the transition with input arcs) contains at least as many tokens as the weight of the input arcs it is linked to.
-
Firing of transitions: firing a transition leads to the removal of as many tokens as the weight of the corresponding input arcs from its input places and then setting into the output places as many tokens as the weight of the corresponding output arcs.
These rules illustrate one of the main properties of Petri nets, called locality of enabling and firing of transitions. This property makes Petri nets able to model true concurrent systems.
Object Petri Nets (OPN)
Classic Petri nets do not easily allow describing data. The introduction of Object Petri nets (OPN) [3][4] provides a means to handle more complex data structure using the Object paradigm.
Structure
-
Typed place and tokens: each place of an OPN is a typed tuple that may hold a set of tokens which are tuples of values of the corresponding type.
-
Transition with Actions and Preconditions: Transitions may be constituted of a precondition (expressed as a predicate depending of the values held by the input places) and actions on the values held by the tokens from input places in order to produce the output values.
-
Variable names on arcs: each arc is decorated while a tuple of variable names, in order to make actions and preconditions of a transition able to handle values held by token.
-
Inhibitor and Test arcs: inhibitor arcs are used as zero tests or threshold tests that allow the enabling of transitions if the linked places are empty, and test arcs are used for simple tests on the tokens held by a place, without removing them from the place while firing the transition.
Dynamic behaviour
-
Enabling of transitions: the enabling rule evolves to account the precondition and the new kind of arc. The rule remains basically the same as for classic Petri nets (e.g. enough tokens in each input places), and then the precondition is evaluated using the set of possible input values (called substitutions).
-
Firing of transitions: the firing is the same as for classic Petri nets, and the value of the produced token may be the result of actions inside the transition.
Cooperative Objects formalism (CO)
A Cooperative Object states how the object reacts to external stimuli according to its inner state. This behavior, called the Object Control Structure (ObCS) is described by means of OPN.
Structure
-
A software interface which describes the set of public methods provided by the object. The syntax used to express this set is the Java syntax as it is precise enough for describing method signature and basic types.
-
Several communication protocols:
-
A unicast synchronous communication (e.g. method calls): Cooperative Objects may communicate among each other using method calls, where these methods are the ones from the associated software interface. A binding mechanism provides a translation of one signature of one method into a set of special places in the Petri net itself, which corresponds to input or output or exception parameters of the method. The semantic of this way of communication is based on a rebuild mechanism, which describes the communication as a Petri net.
-
A multicast asynchronous communication (e.g. event communication): Cooperative Objects may provide a set of events to which other Cooperative Objects may listen. The CO formalism defines ways to add/remove listeners, to trigger events and catch events using event handlers (represented by a set of particular transitions, called synchronized transitions). The semantics are not yet fully described, but we are investigating among related works in the Petri net community such as using Signal nets [5].
-
Dynamic behaviour
-
Enabling of transitions: the enabling rule is exactly the same as for OPN.
-
Firing of transitions: the firing rule is exactly the same as for OPN, and the action inside the transitions may result into a method call of another CO or into the raise of an event.
-
Observability: the execution of the Petri net itself is fully observable, based on the event mechanism presented below. This feature is based on the design pattern called Observer [6], e.g. it provides means for the notification of state changes (e.g. marking changes for places), transitions and event handlers availability and firing.
Interactive Cooperative Objects formalism (ICO)
In the ICO formalism, an object is an entity featuring four components: a cooperative object which describes the behavior of the object, a presentation part, and two functions (the activation function and the rendering function) that make the link between the cooperative object and the presentation part.
Cooperative Object: Using the Cooperative Object formalism, ICO provides the following features:
-
Links between user events from the presentation part and event handlers from the CO.
-
Links between user events availability and event handlers availability.
-
Links between state in the CO changes and rendering.
Presentation part: the presentation of an object states its external appearance. This presentation is a structured set of widgets organized in a set of windows. Each widget may be a way to interact with the interactive system (user → system interaction) and/or a way to display information from this interactive system (system → user interaction). Even if the method used to render (description and/or code) is out of the scope of an ICO specification, it is possible for it to be handled by an ICO in the following way. The presentation part is viewed as a set of rendering methods (in order to render state changes and availability of event handlers) and a set of user events, embedded in a software interface, in the same language as for the CO interface description.
Activation function: the user → system interaction (inputs) only takes place through widgets. Each user action on a widget may trigger one of the CO event handlers. The relation between user services and widgets is fully stated by the activation function that associates each event from the presentation part with the event handler to be triggered and the associated rendering method for representing the activation or the deactivation:
-
When a user event is triggered, the Activation function is notified (via the event mechanism) and asks the CO to fire the corresponding event handler providing it values that only come from the user event.
-
When the state of an event handler changes (e.g. becomes available or not), the Activation function is notified (via the Observer+event mechanism) and calls the corresponding activation rendering method from the presentation part with values for its parameters that only come from the event handler.
The activation function is fully expressed through a mapping as a CO which provides it with its semantic.
Rendering function: the system → user interaction (outputs) aims at presenting the state changes that occurs in the system to the user. The rendering function maintains the consistency between the internal state of the system and its external appearance by reflecting system states changes: * When the state of the Cooperative object changes (e.g. marking changes for a place), the Rendering function is notified (via the Observer + event mechanism) and call the corresponding rendering method from the presentation part with values for its parameters that only come from the event handler.
As for the Activation function, the Rendering function is fully expressed as a CO class.
ICOs are used to provide a formal description of the dynamic behaviour of an interactive application. An ICO specification fully describes the potential interactions that users may have with the application. The specification encompasses both the "input" aspects of the interaction (i.e. how user actions impact on the inner state of the application, a nd which actions are enabled at any given time) and its "output" aspects (i.e. when and how the application displays information relevant to the user). An ICO specification is fully executable, which gives the possibility to prototype and test an application before it is fully implemented [7]. The specification can also be validated using analysis and proof tools developed within the Petri net community and extended in order to take into account the specificities of the Petri net dialect used in the ICO formal description technique.
Advantages
The main advantages of ICOs for the formal description of behavioral specification of interactive applications are related to their use of Petri nets. Indeed, by the representation of tokens.
An ICO specification is fully executable, which gives the possibility to prototype and test quickly an application before its is fully implemented. The specification can also be validated using analysis and prof tools developped within the Petri nets community.