Luis Pedro, Matteo Risoldi, Levi Lucio, Adrien Chantre and Didier Buchs Submitted to FASE’07 workshop at ETAPS 2007 conference
3.1 Abstract
Currently we are developing tools that support Meta-Model based transformations and Model based testing. In this article we present the work we have been developing by using UML2 State Charts as an example of its application. In order to enhance the usability of this work, we propose a methodology that encapsulates UML2 State Charts, Class diagrams and OCL. This allows to fully specify the behavior of reactive systems. Thus, we present a model-based approach that allows to transform a semi-formal sys-tem specification into a formal one that provides us with the necessary constructs to perform simulation, execution and specification of test intentions.
3.2 Introduction
This paper describes a methodology for specifying a system using UML2, transforming the specification into a formal model, and specifying test intentions for automatic test case generation. Sec. 3.3 will show through an example how we join class diagrams, statecharts and OCL for system specification. Sec. 3.4 will detail how we use a meta-model-based transformation to achieve an executable formal model. Sec.
3.5 will present a language allowing to semi-automatically express test intentions on the formal model.
3.3 System Specification and Transformation Result
The system that will be specified is a drink vending machine (DVM). It is a simple version of a DVM, which will be used to highlight some of the main features we take into account for the transformation.
45
46 CHAPTER 3. SIMULATING AND VALIDATING SYSTEM BEHAVIOUR USING...
3.3.1 The UML2 Specification
Fig. 3.1 shows the UML2 class diagram for the DVM. We see a representation of a hierarchically com-posed system: a DVM contains a Fridge, which in turn includes two different Containers (for drinks).
Classes have an attribute for each possible state their objects can be in; as such, the DVM has at-tributesOnand Off, the Fridge hasOK,Error,TempHighandTempLow, and the Containers have OK, LowNumber,Error,EmptyandBlocked. Moreover, there are also attributes not related to states, as the self explainingly-namedTemperature for the Fridge andPrice, Capacityand Number (as in number of contained drinks) for the Containers.
Speaking about operations, a noteworthy thing is that in this class diagram they all have only post conditions. This is due to the fact that preconditions are expressed separately in the state charts, as will be explained further down in this section. Postconditions are written here in Object Constraint Language (OCL) and are shown for some of the operation as linked constraints.
Figure 3.1: Drink Vending Machine Class Diagram
On the other hand, Fig. 3.2 shows the State Charts for the class diagram of Fig. 3.1. Every class is associated with one of these State Charts (via their classifier behaviour). Here, for simplicity we have simple states, macro states, and a fork. These are only some of the features that the transformation approach takes into account; more of them will be discussed in Sec. 3.4. The states which are present in the State Chart also exist with the same names as attributes in the class diagram. This has the main consequence that we are able to refer states from OCL annotations in the class diagrams (see the postcondition ofgiveDrinkBeer, stating self.Empty=true). Conversely, every State Chart has been given the context of the corresponding class; this allows referencing class attributes from annotations in the State Charts.
Operations of the class diagram which have a direct consequence on state changes are present in the State Chart as a transition, with the same name of the operation. Here the resulting state is one more postcondition added to those eventually existing in the class diagram. Moreover, preconditions are here specified as pre-states (implicitly expressed by the transition’s origin) and eventually as guards on the transitions.
As an example, let’s consider thegiveDrinkBeeroperation, which should have pre- and postconditions on theNumberattribute, and which can change the state ofContainerBeer. The class diagram tells us that giveDrinkBeerdecrements theNumberattribute by 1 and putsContainerBeerinto theEmptystate when there are no more drinks; the State Chart informs us from which states and under which conditions we can executegiveDrinkBeer. Having multiple transitions with different guards forgiveDrinkBeerit allows expressing complex behaviours, leading to different states depending on theNumber attribute and on the pre-state.
3.3. SYSTEM SPECIFICATION AND TRANSFORMATION RESULT 47
Figure 3.2: Drink Vending Machine State Chart
This division of pre- and postconditions among the State Charts and the class diagram is a con-sequence of both what are the objectives of the transformation approach and what are the limitations of the used formalisms. We want to be able to express operations with multiple preconditions (in the simplest case, with different pre-states), and with postconditions which are not only established on states but also on other attributes. However State Chart transitions do not allow the specification of explicit postconditions; and class diagrams do not allow the specification of multiple preconditions. The limita-tions of both formalisms can be overcome by using, in each, what is available, and delegating the rest to the other.
3.3.2 The Resulting CO-OPN Specification
The UML specification of Sec. 3.3.1 can be automatically transformed into other formalisms.
The target of the transformation herein discussed is a model expressed in Concurrent Object-Oriented Petri Nets (CO-OPN) language [11, 9], a formalism based on Petri Nets with abstract algebraic data types. A strong reason for this 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]). Moreover, it has formally defined executable, concurrent, transactional semantics, which helps us in cases where the UML formalism does not have a clear semantic definition (we are giving semantics by transformation) and allows java code generation from the model for test execution [33, 32].
CO-OPN specifications are made of modules. A module can be an ADT (Algebraic Data type), a Class or a Context. ADTs are algebraic definitions of data (by means of generators, operations, and axioms). Classes, as in the usual O-O paradigm, define entities with operations and attributes which can
48 CHAPTER 3. SIMULATING AND VALIDATING SYSTEM BEHAVIOUR USING...
be instantiated, have inheritance and encapsulation. Input and output for classes are given by methods and gates (events), which behaviour is specified by axioms. Contexts provide coordination features for the language: they instantiate classes and synchronize their inputs/outputs with other classes/contexts.
Following, the structure of the model will be presented, as well as the behaviour for thegiveDrinkBeer that has been discussed at the end of Sec. 3.3.1, which will demonstrate that it corresponds to the specified behaviour. The mechanics of UML transformation into CO-OPN will be the subject of Sec.
3.4. Note that, as the model is quite large, we removed a lot from the illustrations for clarity’s sake: we will only show the synchronizations corresponding to one of the behaviours of giveDrinkBeer. Keep in mind that there are more behaviours (seen in the statechart) and also more operations. Also, we will use the CO-OPN graphical notation, but remind that CO-OPN is in fact a textual modeling language;
we will only present code when useful for comprehension.
CTXDVMSM
Figure 3.3: Structure of the CO-OPN model
Fig. 3.3 shows the structure of the CO-OPN model. For each object seen in the class diagram, there is a Context (identified by the prefix CTX) and a class instance (identified by the prefix CLASS). Contexts are contained one into another, forming a hierarchy, according to the directed associations found in the class diagram. Abstracting for the moment from the internals of classes, we can see here the behaviour of thebuy operation of the DVM: a methodbuyhas two different synchronizations (depending on the parameter) leading to different methods in different sub-contexts,giveDrinkBeerandgiveDrinkCoke. This is easily derivable from the OCL annotation for thebuyoperation in the class diagram in Fig. 3.1
OK LowNumber Error Error#Empty Error#Blocked
3.4. UML2 TO CO-OPN TRANSFORMATION 49 Fig. 3.4 is showing a detail of the CTXContainerBeerSM and its class instance. The call to the giveDrinkBeermethod of the context is synchronized to the omonymous method of the contained class instance. Internally, this class has a number of places defined, one for every attribute found in the class diagram (thus including states, with some renaming strategy for states inside macrostates). Taking as an example the behaviour of giveDrinkBeer when there is only one drink left (see the statechart, the giveDrinkBeer transition going from LowNumber to Error, and the class diagram, with the OCL postcondition saying thatEmptyshould become true), we can observe the following:
• the precondition expressed on theNumberattribute is verified by taking a tokennfrom theNumber place and putting a guard on the transition,[(n=1)=true].
• the pre-state is verified by taking a token (@) from theLowNumberplace.
• the OCL postcondition onNumberis achieved by putting back a tokenn-1into theNumberplace.
• the postconditions on states are achieved by putting tokens in the placesError(the macrostate) andError#Empty(the inner state).
This behaviour of giveDrinkBeeris expressed, in CO-OPN, by the following axiom:
this = Self & ((n=1)=true) => giveDrinkBeer::
Number n, LowNumber @ -> Number n-1, Error @, Error#Empty @;
where it is easy to recognize the guard and the method name in the first line, and the pre- and postcon-ditions in the second. A more detailed explanation of how these axioms are built is given in Sec. 3.4, in particular for what concerns theError#Emptyinner state.
3.4 UML2 to CO-OPN Transformation
In this section it is provided an exhaustive description on how we perform the transformation from the Class diagrams, State Charts and associated OCL constraints. It should be taken into consideration that this section provides a description of the transformation that goes beyond the UML artefacts used in Sec. 3.3.1.
3.4.1 Transformation Methodology
The transformation action takes place whenever we have a source model and the Metamodel for both target and source language specifications. The Metamodel (also known as the abstract syntax) we are using for UML2 is the one provided by the Eclipse project, in particular the one[18] that is an implementation of the Object Management Group (OMG) UML 2.x Metamodel[17]. Regarding the CO-OOPN Metamodel we are using our own version of it, also developed using ECore formalism.
Having both Metamodels definition allow us to be able to browse the source UML2 model by means of Java interfaces. These interfaces provide all necessary means to interpret the models accordingly to its Metamodel. The same thing applies to the target specification language: using the Java inter-faces obtained from the Metamodel, we are able to create CO-OPN specifications that are syntactically correct. In Fig. 3.5 we present a schema of the transformation process: both interfaces that conform the Metamodel are used by the transformation algorithm that can be written either directly in Java language or using a Metamodel based language like for example YATL [30], modTransf or MTL [39].
Queries/Views/Transformations (QVT)[16] support is also expected to be available.
The semantics match is provided by the transformation algorithm that uses the Metamodels and gives a correct mapping between the UML model elements and the CO-OPN constructions.
3.4.2 State Charts Transformation
Although State Charts syntax is very simple and intuitive the same thing can not be said about the meaning of its semantics. In order to better understand it, this work was mainly based on two documents:
the first one being theUML 2.0 Superstructure Specification [17] by the OMG; and the second one the
50 CHAPTER 3. SIMULATING AND VALIDATING SYSTEM BEHAVIOUR USING...
Figure 3.5: Schematic view of the transformation process from UML2 to CO-OPN articleThe Rhapsody Semantics of State-charts (or, On the Executable Core of the UML[19] from David Harel and Hillel Kugler.
Since CO-OPN is an O-O specification language, our transformation will have to take this into account and perform the necessary assumptions. This means that each State Machine in our UML2 model will correspond to a CO-OPN Class with the nameCLASS+StateM achineN ameas well as a CO-OPN contextCT X+StateM achineN ame. Lets take as background example the State Chart of the DVM in Fig. 3.2
Statestransform into places of the underlying Petri-Net of the CO-OPN class. Since CO-OPN places contain ADTs, we use a special purpose ADT that is calledblackTokenwhich behaviour corresponds to a standard token in a standard Petri-Net. If we take theContainerBeerSMState Machine, we will get in the CO-OPNCLASSContainerSMeight places: three corresponding to the states that concern directly the state machine; two other corresponding to the macro stateError; and three other (Capacity, Price andNumber) that we will discuss later on this section;
Transitions transform into Class methods with the same name as the transitions name, and CO-OPN axiomatic expressions. A CO-CO-OPN axiomatic expression is of form:
condition => Event With Synchronisation :: Pre -> Post
The axioms define the behaviour of the class. In this case they define what should happen when methods are called. This means that we also interpret transitions by transforming their source state into a precondition that holds in the corresponding place, and their target state as the postcondition of the axiom. If we take take statesLowNumberand OK inContainerBeerSMand the transitions between the two of them, we generate two methods namedgiveDrinkBeerandrefilland the axioms for each one of them (in this first phase ignoring the OCL constraints):
refill :: LowNumber @ -> OK @; giveDrinkBeer::OK @ -> LowNumber @;
We should also note that states that own other elements (macro states) are transformed as follows: inner states in are transformed as regular Petri-Net places in the State Machine CO-OPN class by composing their name with the name of the macro state; the states inside of the macro stateErrorwill then be created with names Error#EmptyandError#Blocked.
The algorithm that has been implemented also generates some additional methods and gates by default, which are not present in the CO-OPN derived model in Sec. 3.3.2:
• getStatemethod that can be called whenever we need to know the actual state of the system;
• currentStategate that is automatically called via a parallel (//) synchronization every time that the method getStateis executed. This gate will have the value of the state in with the State machine is whengetState is called;
• changeState(statename)as the method that can be called to change the system to the statestatename. This operation will only succeed if it is allowed to be executed by the axioms in the class.
3.4. UML2 TO CO-OPN TRANSFORMATION 51
• checkState(statename)method that allows to ask the system if it is instatename. This method implies a synchronisation with the following gate,onState
• onStategate that will generate events of typestatename trueorstatename falseif the system respectively is or is not in statestatename.
Besides all these constructions, we also support the transformation of State Charts Pseudo-States. A pseu-dostate is an abstraction that encompasses different types of transient vertices in the state machine graph[17].
The following Pseudo-States are supported for the moment:
Figure 3.6: Example of State Machines with Pseudo States
Choice Points Choice points realizeconditional breaks. They result in a dynamic evaluation of the guards of the triggers of its outgoing transitions. It allows splitting of transitions into multiple outgoing paths: if more than one of the guards evaluates to true, an arbitrary one is selected. In the example of Fig. 3.6 for the choice point in the left side three CO-OPN axiom as follows is generated:
1)goSetB :: A@→B@; 2)goSetC :: A@→C@;
3)goSetD :: A@→D@;
meaning that, if no more information is provided on the diagram, the three transitions can be fired with equal probability, originating a typical example of non-determinism. Note that the name of the transitions are automatically generating by composing the name of the transition in the left hand side of the choice point with the name of the transitions in the right hand side.
Fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices. The segments outgoing from a fork vertex must not have guards or trigger
Forks are like Petri-Net transitions with one arc as input for the transition and many arcs as output of the transition. This means that from one state we are able to go to more than one by firing only one transition.
Fig. 3.6 presents an example of a fork: from staterunningis possible to set statesA,BandC.
In terms of CO-OPN this is expressed as a method with a name generated by the composition of the set of transitions involved in the fork Pseudo-state. Only one axiom is generated that removes a token from the state before the fork and adds a token to each one of the states in the target of the fork. By convention the name of the transition is a composition of the name of the input transition in the fork and the states that are pointed by the set of output transitions. If no additional constraints are present in the diagram, the axiom ”splitBAC :: Running@→B@, A@, C@;” is generated.
Join vertices serve to merge several transitions emanating from source vertices in different orthogonal regions.
The transitions entering a join vertex cannot have guards or triggers. A Join vertex is presented in Fig.
3.6 by the output transitionstart. This UML2 construction is transformed into CO-OPN by removing a token from the states that serve as source of the transitions that go to the Join pseudo state and adding a token to the target state. In terms of CO-OPN this is expressed as:start :: B@, A@, C@→D@;
3.4.3 Class Diagrams Transformation
As a general approach for class diagram transformation we assume that a Class in UML2 is a Class in CO-OPN plus a CO-OPN context that allows communication with the external environment. The attributes of each class are transformed as Places in the underying Petri-Net of the CO-OPN class with a type matching on the CO-OPN Foundation Classes (CFC) available in the framework. Associations are transformed as classes with source and target values. Operations are transformed into CO-OPN methods in both CO-OPN Context and Class and their attributes transformed again accordingly to the CFC type match.
52 CHAPTER 3. SIMULATING AND VALIDATING SYSTEM BEHAVIOUR USING...
The algorithm searches first for State Machines that are linked to a Class (or vice-versa) using theContext orClassifier Behavior features of the UML2 Metamodel. For those Classes it cheches wether the Attributes and Operations correspond to the States and Transition names in the State Machine. If they do not correspond, new Places and Methods are generated. The expressiveness of CO-OPN allow us to have, in the same CO-OPN class, both the behaviour (corresponding to the State Machine) and the static structure (corresponding to the Class). As example we can point the fact that inContainerBeer class of the Fig. 3.1 has a correspondence with
The algorithm searches first for State Machines that are linked to a Class (or vice-versa) using theContext orClassifier Behavior features of the UML2 Metamodel. For those Classes it cheches wether the Attributes and Operations correspond to the States and Transition names in the State Machine. If they do not correspond, new Places and Methods are generated. The expressiveness of CO-OPN allow us to have, in the same CO-OPN class, both the behaviour (corresponding to the State Machine) and the static structure (corresponding to the Class). As example we can point the fact that inContainerBeer class of the Fig. 3.1 has a correspondence with