GATHERING REQUIREMENTS 35

• we use a domain specific language (DSL), suitable to express hierarchical and functional charac-teristics of objects.

• for storing this data we use a database (according to a very well-established schema for control systems[2]) containing the system composition, geometry and dataflow. Often this kind of database generally will already exist, because it’s used in the system engineering phase, for construction and testing. In other cases still it should not be difficult to build, because of its modularity and the fact that the information it asks for has normally been defined anyway.

• we are deriving a dynamic state-machine language from State Manager Language (SML) [15]; this solution also presents an advantage in which SML is a widely used language as it is integrated in one of the major monitoring and supervision softwares, PVSS II [14].

An example of specification is the following. Let’s consider a part of the hierarchy of the DVM of Figure 2.1: a fridge containing a tray and a thermostate, with the tray containing a door and a container for drinks. In Listing 2.1 the Container class is defined.

Listing 2.1: Definition of a Container

36 CHAPTER 2. TOWARDS A FORMAL, MODEL-BASED FRAMEWORK FOR...

We can see the description of the base features of the object class - its name, type, and the geometrical features. The type is useful if we want to define features at a sub-class level: there might be different types of containers, and in each type we might have specific features, but still have a container. This can help in large scale systems, where the number of types is generally much more limited than the number of objects.

The functional features (properties and methods) are then listed. For each property we have its type; for each method we define the types of the parameters and an implementation. Note that in this phase the specification should abstract objects to focus on the control aspects; we don’t implement all the details of thebuymethod, but simply the fact that it takes one drink from the container.

Finally, there is the definition of the state machine. States are listed one after the other, and the initial state (hereEmpty) is indicated. For each state, where relevant, the possible events are listed, and the actions triggered by the event are written. Here, in the stateEmpty, whenever there is arefill event, the new value ofdrinkNumberis checked; if it is more than fine, the object goes to stateOK; if it is more than 0 but less or equal to 5, it goes to stateLowNumber. Note thepoststatement, which expresses the value of a propertyafter the event; this allows us to distinguish between pre- and post-conditions of events.

An interesting case to see is the definition of the state machine for a composite object, a Tray. In Listing 2.2 we can see how a state change can be triggered by the state change of a child object. The event here is the state change of a child object,container1. Complex events can be envisaged when there are several children objects, for example establishing a majority rule where the state turns to Faultyonly if the majority of children areFaulty.

Listing 2.2: State change trigger

We then have to declare the instances of the classes, as in Listing 2.3. We are saying here that there is an objectcontainer1which belongs to the previously declared classContainer, and that it is a child of Tray. We can declare as many objects of this class as we want, and build complex hierarchies in a very simple recurring way (we will declare a Tray object to have a Fridge parent, we will declare a Fridge object to have a DVM parent...).

Since we can’t foresee system experts writing directly into a DSL or a database, unless we fall again in the difficulty problems approached by [13], we have to develop tools based on wizards which help them provide the requirements, and which represent the organization of the system in a comprehensible way.

Not only this, but also allow a partial specification of a system when the requirements are not complete (a common guideline in rapid software development).

2.5 Modeling

We want a model that expresses hierarchy. We need to model elementary and composite objects, with dynamic states that as we saw can be composite as well. We want to be able to interact with objects at

2.5. MODELING 37 various levels of the hierarchy (as in Figure 2.1). Another very relevant feature is concurrency: in any given real-world system, more events can occur at the same time, and they could trigger state changes or communications which are concurrent. In order to avoid the nightmare of having to model every single execution case, we needed a modeling language that already takes into account concurrency via its semantics.

The choice was the Concurrent Object-Oriented Petri Nets (CO-OPN) language [10, 8], a formalism based on Petri Nets with abstract algebraic data types. A strong motivation for the choice is that CO-OPN allows for mathematical verification of formal model properties (thanks to its strictly formal semantics) and for automated test generation and selection. Related work has been published on the subject ([24, 22]).

It is supported by a tool, CoopnBuilder, which allows Java code generation from the model. This can be used to generate and run tests on the model even before passing to the implementation phase [5, 23]. Finally, it has a coordination model, based onContexts[10], which goes further than typical Petri Nets strategies for hierarchy based on substitution of nets with transitions (see the remarks on limits of subnet substitutions with transitions in [29] and several papers by P. Palanque and R. Bastide, which can be found in [28]) and can efficiently scale for large systems thanks to its modularity.

2.5.1 Transforming requirements to a model using meta-modeling

By specifying the system as in the previous section, we have enough information to produce two outcomes.

The first is to construct a model ofthe system itself. This will be important with respect to testing the developed interfaces prior to implementing them. The second thing is to deduce elements of the GUI from the features of the system. There are two sources of information for this task: the nature of the data exchange with the object (what methods and parameters it has, if they are in input or output) and the type of paradigm of interaction (like 2D windows and buttons, 3D, textual...). These factors are processed according to tables of rules (similar to [40]) which establish a ”best guess” of what should be used to represent the object, eventually offering alternatives. The developer can still adapt this choice according to specific requirements. For example, the Containerobject has arefill method with an integer parameter. Rules could say that in this case a suitable 2D representation is a textfield (for the integer parameter) and a button (to send the command). The developer could choose to use a combobox instead of a textfield. This will be done using a transformation engine (called Model Transformer) with a graphical interface resuming relevant features for every object (and letting the developer make modifications to single objects or to whole classes).

To produce these outcomes, the completed specification, expressed in our DSL, is transformed au-tomatically by the Model Transformer to a formal model of both the system and the GUI using the CO-OPN language. This is possible thanks to having both the meta-models of CO-OPN and of our DSL, and to meta-model based transformations which are defined between the two. The transformation technique from other languages to CO-OPN is a vast subject, for which related work has been published [32]. The structure of the resulting model is the subject of the following subsections.

2.5.2 A structured model

The model we use is structured in a way that separates functionality and visualization, in a way very much inspired to the Model-View-Controller pattern. With the information we gathered in the initial phase (and that we refined through the model transformer) we can produce three different models. The first, called System Model, represents the physical system. It models all its objects in their hierarchy and inter-communication aspects, by using CO-OPN contexts and synchronization between objects. It can be built using the information about the hierarchy of the system (for structuring the model), the data flow of every object (for defining every object’s methods/gates), and the dynamic behaviour of the system (for defining the internal state machine of every object as well as the synchronization axioms between objects). The second model, called GUI Logical Model, is a model of the GUI in its behavioural aspects.

We don’t have its actual visual representation here, but only its abstraction in terms of interaction -what objects make it up, -what are their structural parameters, -what they accept and return, and how they interface with the objects of the system in terms of commands and values. The third and last,

38 CHAPTER 2. TOWARDS A FORMAL, MODEL-BASED FRAMEWORK FOR...

called GUI Visual Model, models the visual aspects of the GUI and the associated semantics. Models communicate with each other just like the interface communicates with the system (see Figure 2.3).

System Model

Figure 2.3: The structure of the model

2.5.3 The System Model

As an example of the system model we can build one for our example specification of the DVM. A part of the System model is shown in Figure 2.4(a), using CO-OPN graphical notation. As a quick reference, large white squares are context, grey squares are objects; small black rectangles are methods, and small white rectangles are gates (events). Arrows represent axioms of synchronization between gates and methods. The underscore near some methods and gates represents its parameter, which is an algebraic data type (ADT) token.

The hierarchy is obtained by having CO-OPN contexts for each object; the context of a child object is contained in the context of the parent object (seeTrayContextwhich is contained inFridgeContext).

The functional aspects of objects are expressed with a CO-OPN object associated with each context (see theFridgeobject, associated withFridgeContext), that presents methods and events of the object, and that keeps state information. The object also models the implementation of methods via its internal Petri Net.

To model vertical communication in the hierarchy, every context has aCmd method and aReturn gate. These two have axioms that allow the routing of commands and messages in the hierarchy to the right objects. TheCmdmethod takes as parameters the name of the target object, the name of the method to call and its parameters. TheReturn gate gives back the name of the object sending the message, the name of the message and its parameters. Let’s see this with an example. In Figure 2.4(b) we are highlighting the sequence of synchronizations using thicker arrows, numbered 1-4 in sequence (the numbers in circles are only for illustration purposes, and not part of the CO-OPN formalism). We are calling theunlock method of theTray object. To do so we callCmd Tray unlock [] on the outmost context (in this caseFridgeContext). TheCmdmethod has 3 possible synchronizations: calling theCool orStop methods of Fridge, or passing the call to the child context. Axiom 2.1 in theFridgeContext will say that if the object name in theCmdcall is notFridge, the right synchronization is with the child

2.5. MODELING 39

Figure 2.4: Part of the System model and hierarchical communication

context’sCmd(arrow 1):

(o=F ridge) =f alse=>

Cmd In F ridgeContext obj met W ith Cmd In T rayContext obj met; (2.1) Similarly, the axioms inTrayContextwill make so that the call is passed to theunlockmethod of the Trayobject (arrow 2).

A very similar strategy is used for sending up messages using theReturn gate. In arrow 3 a state change ofTrayis sent out through theReturngate, in a form likeReturn Tray state OK. When passing into FridgeContext(arrows 4), not only the message is passed on to the upper Return gate, but the state change of the child is notified to theFridgeobject, which will eventually decide whether to change state (according to its state machine).

In other words, the outmost context will act as an interface to the model, taking inputs and giving outputs. This, in addition to giving an elegant abstraction, allows us to have a single entry/exit point, which in the implementation phase is an advantage (we can substitute the outmost context of the model with a communication driver). Since this pattern is repetitive and all the information needed to build it is already in the specification, it can be easily generated by the model transformer, and regenerated with the model as the specification changes.

Thanks to CO-OPN transactional semantics, we can also automatically manage the case of a wrong method call (non existing method or object or wrong parameters) without adding mechanisms to manage it. When a command is passed down, it will not succeed until all the synchronisations called by it succeed.

For a wrong call all the possible synchronisation sequences will fail at some point, and the fail will be propagated to the caller.

2.5.4 The GUI Logical Model

This model is built mainly from the analysis of the objects in the system, in terms of what interaction they require. This is part of the information in the Model Transformer tool, notably the part that says

40 CHAPTER 2. TOWARDS A FORMAL, MODEL-BASED FRAMEWORK FOR...

what kind of data is input/output. According to the choices made in the transformer tool, and by using a library of corresponding model patterns, we can build a model which represents the flow of info between the GUI and the system. A similar approach had been used by [40]: for example, if we know that an object has a command which accepts no parameters and returns an integer, we can abstract its GUI behaviour with a model providing a method with no parameters and a gate with an integer parameter.

Continuing our example of the DVM, Figure 2.5 shows the logical model for the control of the Tray object from Figure 2.4(b), and its communication with the System model.

The GUI object is represented by a CO-OPN object and context, and for each method we want to control from the GUI there is a method on the model (e.g. the unlockmethod here). Calls on these methods are sent (together with the object’s name) to the System model’sCmdmethod. Messages coming from the System’sReturngate are received and eventually sent to the GUI through gates (e.g. thestate gate here).

This model does not worry about calculating states; in principle, the GUI should only reflect the state of the system. No state is changed unless the system communicates so.

2.5.5 The GUI Visual Model

Finally, we shall model the actual visual aspect of the GUI. This model, called GUI Visual Model is modular; we build it using components taken from a library of ”model widgets”, in fact pieces of CO-OPN models representing basic controls; these widgets can be assembled and composed to build more complex objects with elaborate behaviour. These objects will be mapped to objects in the GUI logical model. The decision about what widget to use comes from the choices made in the Model Transformer, where the developer decided that for a particular object, say, a text field and a red/green led were needed.

To finish our example, let’s see the visual model for the Tray object. The model transformer will have shown us that there is an unparametrized input (unlockhas no parameters) and that there is an enumerator output (thestate, which can be{OK, Faulty}). Let’s suppose that we chose a 2D windows and buttons paradigm, and that for theunlockcommand we accepted the default suggestion, a button (perfect to send a command without having parameters). For thestatefeedback, the default suggestion was a combo box, but we rather decided for a coloured led, mapping different colours to different values of the enumerator (green=OK, red=locked). Based on these choices, the model in Figure 2.6 can be built using widgets forSimpleButtonandColourLed.