UML2 toCO-OPN transformation State Machines and Class Diagrams by uig68777

VIEWS: 15 PAGES: 31

									UML2 to CO-OPN transformation
State Machines and Class Diagrams transforma-
tion


Luis Pedro
Centre Universitaire D’Informatique
Universite de Geneve




      SMV technical report series, No 208, September 2006

         Centre Universitaire d’Informatique
                  Battelle Bat. A
                 Route de Drize 7
                   1227 Carouge
                    Switzerland




Abstract:
This technical report describes the work being developed in the
SMV! (SMV!)a group of the University of Geneva in the context
of meta-modeling based transformations. This particular work is
focused in describing how do we cope with the transformation
of UML2 diagrams into CO-OPN. In this first approach we are
mainly interested in describing how do we handle with the trans-
formation of UML2 State-Charts and Class Diagrams.




  a
      http://smv.unige.ch
UML2 to CO-OPN transformation




Software Modeling and Verification   Corresponding author:
Department of Computer Science      Luis Pedro
University of Geneva                tel: +41 22 37 91 117
Battelle Bat. A                     Luis.Pedro@cui.unige.ch
Route de Drize 7                    http://smv.unige.ch/~pedro
CH-1227 Carouge
Switzerland

tel: +41 22 37 90 161
fax: +41 22 37 90 250
http:/smv.unige.ch/
Section 1   Introduction                                                         1



1     Introduction
Introduction here[?]


2     The Transformation
The following elements are supported by the existing transformation algorithm:

2.1     State Charts
In this section we provide a detailed description on how the State Charts trans-
formation is performed. Although State Charts syntax is very intuitive the same
thing can not be applied to its semantics. In this work we base ourselves mainly in
two documents in order to better understand the State Chart’s semantics so that
the transformation could be as correct as possible. The first document in which
this work is based is the UML 2.0 Superstructure Specification [?] by the Object
Management Group [?]. The second one is the article The Rhapsody Semantics of
State-charts (or, On the Executable Core of the UML[?] from David Harel and Hillel
Kugler.

2.1.1    State Machine
A State Chart is composed of State Machines. Each State Machine has a name and
is composed of several regions. A CO-OPN Class and Context are created for each
State Machine with name CLASSStateMachineName and CTXStateMachineName.
The CO-OPN class will be typed as the name of the State Machine transformed
to lower case characters.

2.1.2    Simple States




                  Figure 1: State Machine only with Simple States
     2                                                                            Luis Pedro



         These are the State Machines states that don’t contain any other type of owned
     elements. We call them simple states for simplicity, but in reality in UML there is
     absolutely no difference except for the fact that simple states don’t owned elements.
     Simple states are transformed into CO-OPN places of type Blacktoken in the
     corresponding CO-OPN class. These places create the Petri-Net associated to the
     CO-OPN class and will be the responsible for handling the system’s state. The name
     of the place will be the same as the name of the simple state in the State Machine
     except if these names are not syntactically or semantically coherent with CO-OPN
     language - see Section ??.
         As an example we can take Fig. ?? that presents a simple State Machine with
     only three states: Running, Idle and Processing. As mentioned above, each one of
     this state is going to be transformed as Petri-Nets places as follows:

     §       Listing 1: Transformed CO-OPN Class for SimpleStateSM in Fig. ??                  ¤
     ( : : Automatic Generated by UML2COOPN T r a n s f o r m a t i o n t o o l
 2   L u i s Pedro Tue Sep 26 1 3 : 3 2 : 0 5 CEST 2006
     This i s a C l a s s from a UML S t a t e Machine : : )
 4   Class CLASSSimpleStateSM ;
         Interface
 6          Type
              simplestatesm ;
 8          Use
              BlackTokens ;
10      Body
            Places
12            Idle    : blackToken ;
              Processing      : blackToken ;
14            Running     : blackToken ;
     End CLASSSimpleStateSM ;
     ¦                                                                                         ¥

     2.1.3    Transitions




                Figure 2: State Machine only with Simple States and Transitions


        A transition is the act of passing from one state (including macro states and
     pseudo states) the next. Transitions are transformed as CO-OPN class methods
     Section 2       The Transformation                                                                                     3



     and axioms that state the pre- and post-conditions. The methods names are either
     equal to the name of the transition, or equal to set concatenated with the post-state
     name.


     §        Listing 2: Transformed CO-OPN Class for SimpleStateSM in Fig. ??                                                  ¤
     ( : : Automatic Generated by UML2COOPN T r a n s f o r m a t i o n t o o l
 2   L u i s Pedro Tue Sep 26 1 3 : 3 2 : 0 5 CEST 2006
     This i s a C l a s s from a UML S t a t e Machine : : )
 4   Class CLASSSimpleStateSM ;
         Interface
 6          Type
              simplestatesm ;
 8          Method
              changeState                  : statesort ;
10            getState ;
              pause ;
12            process ;
              run ;
14          Gates
              currentState                  : statesort ;
16          Use
              ADTObjectList ;
18            ADTStates ;
              BlackTokens ;
20      Body
            Places
22            Idle          : blackToken ;
              Processing                : blackToken ;
24            Running             : blackToken ;
            Axiom
26            pause : : P r o c e s s i n g @ −> I d l e @;
              p r o c e s s : : Running @ −> P r o c e s s i n g @;
28            run : : I d l e @ −> Running @;
              t h i s = S e l f & ( s = I d l e = t r u e ) =>
30              c h a n g e S t a t e s With t h i s . pause           : : −> ;
              t h i s = S e l f & ( s = P r o c e s s i n g = t r u e ) =>
32              c h a n g e S t a t e s With t h i s . p r o c e s s       : : −> ;
              t h i s = S e l f & ( s = Running = t r u e ) =>
34              c h a n g e S t a t e s With t h i s . run         : : −> ;
              t h i s = S e l f =>
36                g e t S t a t e With t h i s . c u r r e n t S t a t e I d l e : : I d l e @ −> I d l e @;
              t h i s = S e l f =>
38                g e t S t a t e With t h i s . c u r r e n t S t a t e P r o c e s s i n g : : P r o c e s s i n g @ −>
                          P r o c e s s i n g @;
              t h i s = S e l f =>
40                g e t S t a t e With t h i s . c u r r e n t S t a t e Running : : Running @ −> Running @;
            Where
42            s : statesort ;
              t h i s : simplestatesm ;
44   End CLASSSimpleStateSM ;
     ¦                                                                                                                          ¥
          As it is possible to observe from List ??

     2.1.4      Final States
     Final states are a special case of regular State Machine states. Although we would
     like to highlight them since they have one particularity: once being in one of these
     states, the general state of our system can no longer evolve. The Fig. ?? shows an
     example of a State Machine with a Final State.
4                                                                                         Luis Pedro




                   Figure 3: Example of a State Machine with a Final State


2.1.5        Macro States
Macro states are states as any others but that contain owned elements. This means
that they can have other states, transitions and other pseudo-states1 as its compo-
nents. Each macro state is transformed both into a place in the Petri-Net of the
parent State-Machine (or other Macro state) and into a new CO-OPN Class and
Context. This process is recursive in the sense that, if a macro state contains another
macro state, the process will repeat it self until only simple states are found.
   We should also highlight that for every CO-OPN class and context generated is
provided with two special methods and one gate that have specific proposes:

getState method This method allows to ask to the State Machine or Macro State
     entities which state handles: it will send the comment to put the current state
     in a gate named currentState .

changeState method This is a method that sends a command to the State Ma-
     chine or Macro State to go to a specific state by using the state’s name.

currentState gate This gate will handle the name of the state that is the current
     state of the State Machine or Macro State by the time that the method getState
     was issued. This method and gate currentState are synchronized by means
     of the operator parallel ”/ /” operator.

    In order to fully exemplify the usability and the way we handle with State Ma-
chines macro states, we will use two different examples. These two examples clearly
have a different semantics and the transformation must be performed differently
taking this into account.

    1. Macro States without transitions from another region: This example
       concerns a State Machine that contains macro states with a set of states as
    1
        Transitions, Initial States, Forks, Junction Points, Choice Points, Join Points
Section 2      The Transformation                                                    5




   Figure 4: Example of a State Machine with a Macro State that do not have
              transitions going from the exterior to one of its internal States

        its components but without any transitions that have different source and
        target regions. As it can be depicted in Fig. ?? we have a macro state named
        Processing and in its region we have states Counting and Calculating but there
        are no transitions from any of the state Running (in another region) to these
        ones.
        The result of transforming this State Chart are two CO-OPN Classes and
        two CO-OPN Contexts: 1) a first class is generated to cope with the simple
        states and transitions inside the region of the state machine StateMachineWith-
        MacroState - the resulting CO-OPN class in graphical representation is the one
        presented in Fig. ??. To be highlighted the fact that there are created three
        Places in the underlying Petri-Net of the CO-OPN class, two corresponding
        to the simple states Initial1 and Running and another one for the macro state
        Processing.


            Listing 3: Transformed CO-OPN Class for the State Machine with Macro
        §        State without transitions going from one region to the other             ¤
        Class CLASSStateMachineWithMacroState ;
    2     Interface
            Type
    4         statemachinewithmacrostate ;
            Method
    6         changeState     : statesort ;
              getState ;
    8         process ;
              run ;
   10       Gates
              currentState     : statesort ;
   12       Use
              ADTObjectList ;
   14         ADTStates ;
              BlackTokens ;
6                                                                                                             Luis Pedro



     16     Body
              Places
     18          Initial1              : blackToken ;
                 Processing                : blackToken ;
     20          Running             : blackToken ;
              Initial
     22          I n i t i a l 1 @;
              Axiom
     24          p r o c e s s : : Running @ −> P r o c e s s i n g @;
                 run : : I n i t i a l 1 @ −> Running @;
     26          t h i s = S e l f & ( s = P r o c e s s i n g = t r u e ) =>
                   c h a n g e S t a t e s With t h i s . p r o c e s s     : : −> ;
     28          t h i s = S e l f & ( s = Running = t r u e ) =>
                   c h a n g e S t a t e s With t h i s . run         : : −> ;
     30          t h i s = S e l f =>
                     g e t S t a t e With t h i s . c u r r e n t S t a t e I n i t i a l 1 : : I n i t i a l 1 @ −> I n i t i a l 1 @
                             ;
     32          t h i s = S e l f =>
                     g e t S t a t e With t h i s . c u r r e n t S t a t e P r o c e s s i n g : : P r o c e s s i n g @ −>
                             P r o c e s s i n g @;
     34          t h i s = S e l f =>
                     g e t S t a t e With t h i s . c u r r e n t S t a t e Running : : Running @ −> Running @;
     36       Where
                 s : statesort ;
     38          t h i s : statemachinewithmacrostate ;
          End CLASSStateMachineWithMacroState ;
          ¦                                                                                                                              ¥
          Although there are no transitions that goes from a simple state in the State




    Figure 5: Resulting CO-OPN Class for the StateMachineWithMacroState State
                                                 Machine in Fig. ??
Section 2      The Transformation                                                  7




Figure 6: Resulting CO-OPN Clontext for the StateMachineWithMacroState State
                                    Machine in Fig. ??


        Machine to another simple state in the Macro state, when transition process
        is triggered, in the State Machine CO-OPN context (Fig. ?? and List ??)
        a parallel synchronization is generated so that CLASSProcessing goes to its
        initial state. This can be achieved by means of the axiom

        process With objstatemachinewithmacrostate . process
           // objprocessing . changeState Initial1;


            Listing 4: Transformed CO-OPN Class for the State Machine with Macro
        §             State without transitions between different regions               ¤
        Context CTXStateMachineWithMacroState ;
    2     Interface
            Method
    4         changeState     : statesort ;
              getState ;
    6         process ;
              run ;
    8       Gates
              currentState     : statesort ;
   10       Use
              ADTObjectList ;
   12         ADTStates ;
              CLASSProcessing ;
   14         CLASSStateMachineWithMacroState ;
         Body
   16       Object
              objprocessing : processing ;
   18         objstatemachinewithmacrostate : statemachinewithmacrostate ;
8                                                                                                                  Luis Pedro



             Axiom
    20         c h a n g e S t a t e s With o b j s t a t e m a c h i n e w i t h m a c r o s t a t e . c h a n g e S t a t e s ;
               g e t S t a t e With o b j s t a t e m a c h i n e w i t h m a c r o s t a t e . g e t S t a t e ;
    22         o b j s t a t e m a c h i n e w i t h m a c r o s t a t e . c u r r e n t S t a t e s With c u r r e n t S t a t e s ;
               p r o c e s s With o b j s t a t e m a c h i n e w i t h m a c r o s t a t e . p r o c e s s // o b j p r o c e s s i n g .
                       changeState I n i t i a l 1 ;
    24         run With o b j s t a t e m a c h i n e w i t h m a c r o s t a t e . run ;
             Where
    26         s : statesort ;
         End CTXStateMachineWithMacroState ;
         ¦                                                                                                                                   ¥




     Figure 7: Resulting CO-OPN Class for the for the Macro State Processing

         b) a second CO-OPN class and context are generated in order to represent
         the macro-state itself. The class CLASSProcessing is generated with methods
         calculate, count and run which are the equivalent to the transitions inside
         state Processing from the State-Machine in ??. The three places Calculating,
         Counting and Initial1 corresponding to the simple states (and Initial one) are
         also created. In Fig. ?? and List ??

         Listing 5: Transformed CO-OPN Class for the Macro State Processing in Fig.
                                                                   ??
Section 2       The Transformation                                                                                       9


        §                                                                                                                              ¤
        Class CLASSProcessing ;
    2     Interface
            Type
    4          processing ;
            Method
    6          calculate ;
               changeState                  : statesort ;
    8          count ;
               getState ;
   10          run ;
            Gates
   12          currentState                   : statesort ;
            Use
   14          ADTObjectList ;
               ADTStates ;
   16          BlackTokens ;
          Body
   18       Places
               Calculating                  : blackToken ;
   20          Counting              : blackToken ;
               Initial1              : blackToken ;
   22       Axiom
               c a l c u l a t e : : Counting @ −> C a l c u l a t i n g @;
   24          count : : C a l c u l a t i n g @ −> Counting @;
               run : : I n i t i a l 1 @ −> Counting @;
   26          t h i s = S e l f & ( s = C a l c u l a t i n g = t r u e ) =>
                 c h a n g e S t a t e s With t h i s . c a l c u l a t e     : : −> ;
   28          t h i s = S e l f & ( s = Counting = t r u e ) =>
                 c h a n g e S t a t e s With t h i s . count           : : −> ;
   30          t h i s = S e l f & ( s = Counting = t r u e ) =>
                 c h a n g e S t a t e s With t h i s . run         : : −> ;
   32          t h i s = S e l f & ( s = I n i t i a l 1 = t r u e ) =>
                 c h a n g e S t a t e s : : −> I n i t i a l 1 @;
   34          t h i s = S e l f =>
                   g e t S t a t e With t h i s . c u r r e n t S t a t e C a l c u l a t i n g : : C a l c u l a t i n g @ −>
                           C a l c u l a t i n g @;
   36          t h i s = S e l f =>
                   g e t S t a t e With t h i s . c u r r e n t S t a t e Counting : : Counting @ −> Counting @
                           ;
   38          t h i s = S e l f =>
                   g e t S t a t e With t h i s . c u r r e n t S t a t e I n i t i a l 1 : : I n i t i a l 1 @ −> I n i t i a l 1 @
                           ;
   40       Where
               s : statesort ;
   42          this : processing ;
        End CLASSProcessing ;
        ¦                                                                                                                              ¥

   2. Macro States with transitions from another region:

2.1.6       Pseudo-States
From [?], ”A pseusostate is an abstraction that encompasses different types of tran-
sient vertices in the state machine graph”

Initial States It is a state that allows to now what are the possible transition
      sequences when the system is at its initial state. More concretely, from [?]:
      represents a default vertex that is the source for a single transition to the default
      state of a composite state. There can be at most one initial vertex in a region.
      The initial transition may have an action.
10                                                                            Luis Pedro



          These states are transformed into CO-OPN places in the underlying Petri-
          Net. A token is added by default to this state using the Initial keyword in the
          CO-OPN class. Simultaneously

Choice Points Choice points realize conditional 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. The Fig. ?? shows a
    simple State Machine that contains a Pseudo-State of type choice.




                        Figure 8: Example of a choice pseudo-state

          Applying the transformation results in a CO-OPN specification as presented
          in List ??. The transition go does not exists by its one. In fact, the result
          of the transformation is a composition between transitions go, SetB, SetC
          and setD. Since that for a Pseudo-state of type choice any of the transitions
          can be arbitrarily selected, a set o axioms are generated in order to comply
          with the specified behavior. The transformation results in what is typically
          denominated as non-determinism: once in State A (represented as a Place in
          the CO-OPN specification) the system can go either to State A, State B or
          State C with equal probability.


          §    Listing 6: Transformed CO-OPN Class for a Choice Pseudo-State                ¤
          Class CLASSChoiceStateMachine ;
      2     Interface
              Type
      4         choicestatemachine ;
              Method
      6         changeState   : statesort ;
                getState ;
      8         goSetB ;
                goSetC ;
     10         goSetD ;
Section 2      The Transformation                                                    11



               run ;
   12   ...
          Body
   14       Places
              A        : blackToken ;
   16         B        : blackToken ;
              C        : blackToken ;
   18         D        : blackToken ;
               Initial1            : blackToken ;
   20       Initial
               I n i t i a l 1 @;
   22       Axiom
               goSetB : : A @ −> B @;
   24          goSetC : : A @ −> C @;
               goSetD : : A @ −> D @;
   26          run : : I n i t i a l 1 @ −> A @;
        ...
   28   End CLASSChoiceStateMachine ;
        ¦                                                                                  ¥

Forks From the UML Infrastructure Specification, v2.0, Fork vertices serve to split
    an incoming transition into two or more transitions terminating on orthogonal
    target vertices (i.e., vertices in different regions of a composite state). The
    segments outgoing from a fork vertex must not have guards or trigger
        Forks are like Petri-Nets 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 state by firing only one transition. Fig. ??
        presents an example of a fork: from state A is possible to set states B, C and
        D.




                           Figure 9: Example of a Fork pseudo-state

        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. An
        axiom that removes a token from the state before the fork and that adds a
        token to each one of the states in the target of the fork is also created. Using
        Fig. ?? for exemplification and applying transformation we get a method
        named startBCD. By convention the name of the transition is a composition of
12                                                                             Luis Pedro



          the name of the input transition in the fork and the states that are pointed by
          the set of output transitions. The axiom ”startBCD :: A@ → B@, C@, D@;”
          is also generated.


          §      Listing 7: ransformed CO-OPN Class for a Fork Pseudo-State                  ¤
          Class CLASSForkStateMachine ;
      2     Interface
          ...
      4       Method
                changeState             : statesort ;
      6         getState ;
                run ;
      8         startBCD ;
          ...
     10       Places
                A       : blackToken ;
     12         B       : blackToken ;
                C       : blackToken ;
     14         D       : blackToken ;
                Initial1            : blackToken ;
     16       Initial
                I n i t i a l 1 @;
     18       Axiom
                run : : I n i t i a l 1 @ −> A @;
     20         startBCD : : A @ −> B @ , C @ , D @;
          ...
     22   End CLASSForkStateMachine ;
          ¦                                                                                  ¥
          The code presented in Fig. ?? shows a fragment of the CO-OPN class gener-
          ated after transformation for the State Machine depicted in Fig. ??. To be
          highlighted is the fact that, being in State A after firing transition run we can
          use the method startBCD that will remove the token from the place A adding
          one to each one of the places in the post-condition of the axiom (Places B, C
          and D).

Join From the UML specification, 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.

Junction From [?], junction vertices are semantic-free vertices that are used to
    chain together multiple transitions. They are used to construct compound tran-
    sition paths between states. For example, a junction can be used to converge
    multiple incoming transitions into a single outgoing transition representing a
    shared transition path (this is known as a merge). Conversely, they can be
    used to split an incoming transition into multiple outgoing transition segments
    with different guard conditions. Taking into account that Junction points have
    a not so well defined behavior, for this first approach of this work, we decided
    to not include it in elements supported by the transformation algorithm.

2.2       Class Diagrams
Classes Classes as CO-OPN Classes and Contexts
Section 2   The Transformation                                                   13




                    Figure 10: Example of a Join pseudo-state


Attributes Attributes as places with the corresponding type from the CFC (CO-
     OPN Foundation Classes)

Operations

   The following elements are not yet supported by the transformation algorithm,
but should be added in the near future:

  1. State Machines with multiple regions

  2. OCL in guard of the State Chart transitions

  3. Transitions with source and target states in different regions (this is just not
     yet implement for lack of time: all the infrastructure is there!)

  4. OCL in the Class diagram operations

  5. OCL in pre- and post-conditions of the State Chart states

  6. State Machine Junction Points - multiple states as pre-conditions and multiple
     states as post-conditions

  7. State Machine Join Points - the opposite of a Fork pseudo-state
14                                                                     Luis Pedro



3     Case Study: Drink Vending Machine
3.1   The UML2 Diagram
The Fig. ?? shows the Drink Vending Machine State Chart using UML2 notation.
This model represents all state transitions allowed for each of DVM’s components.
Each one of the components has its own state machine and there is nothing in this
diagram that implies a hierarchical relationship between the components.




                 Figure 11: Drink Vending Machine State Chart

    In addition to the State Chart of Fig. ??, the DVM model becomes more com-
plete when it is added a more complete description of the components structure.
This can be achieved by using an UML2 Class Diagram represented in Fig. ??.
Section 3   Case Study: Drink Vending Machine                               15




                 Figure 12: Drink Vending Machine Class Diagram


3.2   The CO-OPN Specification
As an example we present the transformation of Class/StateMachine Drink Vend-
ing Machine - the CO-OPN Class CLASSDrinkVendingMachine, and the Class/S-
tateMachine Cold - by means of the resulting CO-OPM Context CTXCold. The
Fig. ?? shows the ilustration of the CO-OPN class obtained by transformation of
the Class and State Machine Drink Vending Machine; The resulting CO-OPN source
code can be seen in Listing ??.
     16                                                                                                                    Luis Pedro



     §                         Listing 8: CO-OPN Class Drink Vending Machine                                                                   ¤
     ( : : Automatic Generated by UML2COOPN T r a n s f o r m a t i o n t o o l
 2   L u i s Pedro Mon Aug 14 1 6 : 4 0 : 3 5 CEST 2006
     This i s a C l a s s from a UML S t a t e Machine : : )
 4   Class CLASSDrinkVendingMachine ;
         Interface
 6          Type
              drinkvendingmachine ;
 8          Method
              changeState                  : statesort ;
10            getState ;
              getlocalization ;
12            setFaulty                : blackToken ;
              setOK            : blackToken ;
14            setWarning                 : blackToken ;
              setlocalization                  : natural ;
16          Gates
              currentState                  : statesort ;
18            currentlocalization                       : natural ;
            Use
20            ADTObjectList ;
              ADTStates ;
22            BlackTokens ;
              CLASSCold ;
24            Naturals ;
        Body
26          Object
              objcold : cold ;
28          Places
              Faulty             : blackToken ;
30            Initial1              : blackToken ;
              OK        : blackToken ;
32            Warning              : blackToken ;
              localization                  : natural ;
34          Initial
              I n i t i a l 1 @;
36          Axiom
              s e t F a u l t y @ : : OK @ −> F a u l t y @;
38            s e t F a u l t y @ : : Warning @ −> F a u l t y @;
              setOK @ : : F a u l t y @ −> OK @;
40            setOK @ : : I n i t i a l 1 @ −> OK @;
              setOK @ : : Warning @ −> OK @;
42            setWarning @ : : F a u l t y @ −> Warning @;
              setWarning @ : : OK @ −> Warning @;
44            s e t l o c a l i z a t i o n v a r l o c a l i z a t i o n : : −> l o c a l i z a t i o n v a r l o c a l i z a t i o n ;
              t h i s = S e l f & ( s = F a u l t y = t r u e ) =>
46              c h a n g e S t a t e s With t h i s . s e t F a u l t y @ : : −> ;
              t h i s = S e l f & ( s = OK = t r u e ) =>
48              c h a n g e S t a t e s With t h i s . setOK @ : : −> ;
              t h i s = S e l f & ( s = Warning = t r u e ) =>
50              c h a n g e S t a t e s With t h i s . setWarning @ : : −> ;
              t h i s = S e l f =>
52                g e t S t a t e With t h i s . c u r r e n t S t a t e F a u l t y : : F a u l t y @ −> F a u l t y @;
              t h i s = S e l f =>
54                g e t S t a t e With t h i s . c u r r e n t S t a t e I n i t i a l 1 : : I n i t i a l 1 @ −> I n i t i a l 1 @
                          ;
              t h i s = S e l f =>
56                g e t S t a t e With t h i s . c u r r e n t S t a t e OK : : OK @ −> OK @;
              t h i s = S e l f =>
58                g e t S t a t e With t h i s . c u r r e n t S t a t e Warning : : Warning @ −> Warning @;
              t h i s = S e l f => g e t l o c a l i z a t i o n With t h i s . c u r r e n t l o c a l i z a t i o n
                      varlocalization : :                   l o c a l i z a t i o n v a r l o c a l i z a t i o n −> l o c a l i z a t i o n
                      varlocalization ;
60          Where
              s : statesort ;
     Section 3   Case Study: Drink Vending Machine   17



62         t h i s : drinkvendingmachine ;
           varlocalization : natural ;
64   End CLASSDrinkVendingMachine ;
     ¦                                                    ¥
     18                                                                                                    Luis Pedro



     §                             Listing 9: CO-OPN Context CTXCold                                                    ¤
     ( : : Automatic Generated by UML2COOPN T r a n s f o r m a t i o n t o o l
 2   L u i s Pedro Mon Aug 14 1 6 : 4 0 : 3 5 CEST 2006
     This i s a C o n t e x t from a UML S t a t e Machine : : )
 4
     Context CTXCold ;
 6     Interface
         Method
 8          changeState                : statesort ;
            getState ;
10          getWarning ;
            setFaulty             : blackToken ;
12         setOK            : blackToken ;
            setWaring             : blackToken ;
14          setWarning               : boolean ;
         Gates
16          currentState                 : statesort ;
            currentWarning                 : boolean ;
18       Use
            ADTObjectList ;
20          ADTStates ;
            Booleans ;
22         CLASSCold ;
       Body
24       Object
            objcold : cold ;
26          objdrinkvendingmachine : drinkvendingmachine ;
            objexit : exit ;
28          objfridge : fridge ;
            objnaturalcontainer : naturalcontainer ;
30       Axiom
            c h a n g e S t a t e s With o b j c o l d . c h a n g e S t a t e s ;
32          g e t S t a t e With o b j c o l d . g e t S t a t e ;
            getWarning With o b j c o l d . getWarning ;
34          o b j c o l d . c u r r e n t S t a t e s With c u r r e n t S t a t e s ;
            o b j c o l d . c u r r e n t W a r n i n g varWarning With c u r r e n t W a r n i n g varWarning ;
36          s e t F a u l t y @ With o b j c o l d . s e t F a u l t y @;
           setOK @ With o b j c o l d . setOK @;
38          setWaring @ With o b j c o l d . setWaring @;
            setWarning varWarning With o b j c o l d . setWarning varWarning ;
40       Where
            s : statesort ;
42          varWarning : b o o l e a n ;
     End CTXCold ;
     ¦                                                                                                                  ¥
     Section 4       Case Study: UML2 to CO-OPN transformation                                                                19



     4      Case Study: UML2 to CO-OPN transformation
     4.1      The State Chart Diagram
     4.2      The CO-OPN Specification
     4.2.1      CO-OPN CLASSStateChartTransfomation
     This is the CO-OPN Class results from the transformation of the State Machine
     StateChartTransformatio. This state machine contains not only simple states (in the
     sense that we wrote previously) but also a macro state named ProcessState. In the
     List ?? we can see the resulting CO-OPN class after applying transformation


     §              Listing 10: CO-OPN Class CLASSStateChartTransformation                                                         ¤
     ( : : Automatic Generated by UML2COOPN T r a n s f o r m a t i o n t o o l
 2   L u i s Pedro Tue Aug 15 0 2 : 4 1 : 4 6 CEST 2006
     This i s a C l a s s from a UML S t a t e Machine : : )
 4   Class CLASSStateChartTransformation ;
         Interface
 6          Type
              statecharttransformation ;
 8          Method
              changeState                 : statesort ;
10            checkStateType−g e t R e g i o n s M a c r o                   : blackToken ;
              checkStateType−setCoopnModuleState                                 : blackToken ;
12            getBehavioralElements                          : blackToken ;
              getElementsProcessStateProcessPseudoStateProcessTransitions                                                 :
                      blackToken ;
14            getRegions                : blackToken ;
              getState ;
16            getStateMachines                       : blackToken ;
              setCoopnModulePseudoState                             : blackToken ;
18            setCoopnModuleTransition                            : blackToken ;
            Gates
20            currentState                   : statesort ;
            Use
22            ADTObjectList ;
              ADTStates ;
24            BlackTokens ;
        Body
26          Places
              ProcessModel                   : blackToken ;
28            ProcessPseudoState                        : blackToken ;
              ProcessRegion                   : blackToken ;
30            ProcessState                   : blackToken ;
              ProcessStateMachine                         : blackToken ;
32            ProcessTransitions                        : blackToken ;
              Start           : blackToken ;
34            WriteCOOPN                : blackToken ;
            Initial
36            S t a r t @;
            Axiom
38            checkStateType−g e t R e g i o n s M a c r o @ : : P r o c e s s S t a t e @ −> P r o c e s s R e g i o n @;
              checkStateType−setCoopnModuleState @ : : P r o c e s s S t a t e @ −> WriteCOOPN @;
40            g e t B e h a v i o r a l E l e m e n t s @ : : S t a r t @ −> P r o c e s s M o d e l @;
              getElementsProcessStateProcessPseudoStateProcessTransitions @: :
                      P r o c e s s R e g i o n @ −> P r o c e s s S t a t e @ , P r o c e s s P s e u d o S t a t e @ ,
                      P r o c e s s T r a n s i t i o n s @;
42            g e t R e g i o n s @ : : P r o c e s s S t a t e M a c h i n e @ −> P r o c e s s R e g i o n @;
              g e t S t a t e M a c h i n e s @ : : P r o c e s s M o d e l @ −> P r o c e s s S t a t e M a c h i n e @;
44            setCoopnModulePseudoState @ : : P r o c e s s P s e u d o S t a t e @ −> WriteCOOPN @;
     20                                                                                                             Luis Pedro



           s e t C o o p n M o d u l e T r a n s i t i o n @ : : P r o c e s s T r a n s i t i o n s @ −> WriteCOOPN @;
46         t h i s = S e l f & ( s = P r o c e s s R e g i o n = t r u e ) =>
             c h a n g e S t a t e s With t h i s . g e t R e g i o n s @ : : −> ;
48         t h i s = S e l f & ( s = P r o c e s s S t a t e M a c h i n e = t r u e ) =>
             c h a n g e S t a t e s With t h i s . g e t S t a t e M a c h i n e s @ : : −> ;
50         t h i s = S e l f & ( s = WriteCOOPN = t r u e ) =>
             c h a n g e S t a t e s With t h i s . setCoopnModulePseudoState @ : : −> ;
52         t h i s = S e l f & ( s = WriteCOOPN = t r u e ) =>
             c h a n g e S t a t e s With t h i s . s e t C o o p n M o d u l e T r a n s i t i o n @ : : −> ;
54         t h i s = S e l f =>
               g e t S t a t e With t h i s . c u r r e n t S t a t e P r o c e s s M o d e l : : P r o c e s s M o d e l @ −>
                       P r o c e s s M o d e l @;
56         t h i s = S e l f =>
               g e t S t a t e With t h i s . c u r r e n t S t a t e P r o c e s s P s e u d o S t a t e : :
                       P r o c e s s P s e u d o S t a t e @ −> P r o c e s s P s e u d o S t a t e @;
58         t h i s = S e l f =>
               g e t S t a t e With t h i s . c u r r e n t S t a t e P r o c e s s R e g i o n : : P r o c e s s R e g i o n @ −>
                       P r o c e s s R e g i o n @;
60         t h i s = S e l f =>
               g e t S t a t e With t h i s . c u r r e n t S t a t e P r o c e s s S t a t e : : P r o c e s s S t a t e @ −>
                       P r o c e s s S t a t e @;
62         t h i s = S e l f =>
               g e t S t a t e With t h i s . c u r r e n t S t a t e P r o c e s s S t a t e M a c h i n e : :
                       P r o c e s s S t a t e M a c h i n e @ −> P r o c e s s S t a t e M a c h i n e @;
64         t h i s = S e l f =>
               g e t S t a t e With t h i s . c u r r e n t S t a t e P r o c e s s T r a n s i t i o n s : :
                       P r o c e s s T r a n s i t i o n s @ −> P r o c e s s T r a n s i t i o n s @;
66         t h i s = S e l f =>
               g e t S t a t e With t h i s . c u r r e n t S t a t e S t a r t : : S t a r t @ −> S t a r t @;
68         t h i s = S e l f =>
               g e t S t a t e With t h i s . c u r r e n t S t a t e WriteCOOPN : : WriteCOOPN @ −>
                      WriteCOOPN @;
70       Where
           s : statesort ;
72         this : statecharttransformation ;
     End CLASSStateChartTransformation ;
     ¦                                                                                                                               ¥


     4.2.2      CO-OPN CLASSProcessState
     The macro state ProcessState is also transformed in a CO-OPN class as it can be
     seen in ??.


     §                         Listing 11: CO-OPN Class CLASSProcessState                                                            ¤
     ( : : Automatic Generated by UML2COOPN T r a n s f o r m a t i o n t o o l
 2   L u i s Pedro Tue Aug 15 0 2 : 4 1 : 4 6 CEST 2006
     This i s a C l a s s from a UML S t a t e Machine : : )
 4   Class CLASSProcessState ;
         Interface
 6          Type
              processstate ;
 8          Method
              changeState      : statesort ;
10            getMembersRelationships          : blackToken ;
              getMembets      : blackToken ;
12            getState ;
            Gates
14            currentState      : statesort ;
            Use
16            ADTObjectList ;
              ADTStates ;
18            BlackTokens ;
     Section 4         Case Study: UML2 to CO-OPN transformation                                                                        21



       Body
20       Places
            ParseRelations                     : blackToken ;
22          ProcessStateMembers                         : blackToken ;
            StartProcessState                       : blackToken ;
24       Initial
            S t a r t P r o c e s s S t a t e @;
26       Axiom
            g e t M e m b e r s R e l a t i o n s h i p s @ : : P r o c e s s S t a t e M e m b e r s @ −> P a r s e R e l a t i o n s @;
28          getMembets @ : : S t a r t P r o c e s s S t a t e @ −> P r o c e s s S t a t e M e m b e r s @;
            t h i s = S e l f & ( s = P a r s e R e l a t i o n s = t r u e ) =>
30            c h a n g e S t a t e s With t h i s . g e t M e m b e r s R e l a t i o n s h i p s @ : : −> ;
            t h i s = S e l f =>
32              g e t S t a t e With t h i s . c u r r e n t S t a t e P a r s e R e l a t i o n s : : P a r s e R e l a t i o n s @
                       −> P a r s e R e l a t i o n s @;
            t h i s = S e l f =>
34              g e t S t a t e With t h i s . c u r r e n t S t a t e P r o c e s s S t a t e M e m b e r s : :
                       P r o c e s s S t a t e M e m b e r s @ −> P r o c e s s S t a t e M e m b e r s @;
            t h i s = S e l f =>
36              g e t S t a t e With t h i s . c u r r e n t S t a t e S t a r t P r o c e s s S t a t e : :
                        S t a r t P r o c e s s S t a t e @ −> S t a r t P r o c e s s S t a t e @;
         Where
38          s : statesort ;
            this : processstate ;
40   End CLASSProcessState ;
     ¦                                                                                                                                       ¥
22                                                                        Luis Pedro



   sectionTransformation Limitations This section should be updated while the
transformation algorithm is improved being the ultimate goal to have it empty!

     • Places and Methods containing the - and    characters:
       CO-OPN interprets a - as if it was a minus operation and a as if it was an
       input/output parameter. Taking this into account, both - and are removed
       from the names.

     • Initial Pseudo-States in Macro states:
       For the time being an initial State in any Macro state must be named Initial1.
       This is a clear limitation of the algorithm that MUST be solved very quickly.
Section 5     Implementation                                                       23



5     Implementation
5.1     Transformation Parameters
5.2     Transformation Execution Process
Transformation of State Charts and Class diagrams follows the sequence:

    1. Gets the State Machines in the UML2 diagram

    2. ....

    3. Processes a region

        (a) adds an entry to the CoopnModuleManager object. Both to the Class and
            Context. An entry in this class means that, for a given region identified
            by its qualified name is associated an object of type CoopnWriter.
        (b) Iterates in States
         (c) Iterates in Pseudo-States
        (d) Iterates in Transitions
               • Checks if source and target of the transition are in the same region
24                                                    Luis Pedro



6    Conclusion
To be done..... as many other things in this report


7    Acronyms
SMV Software Modelling and Verification
Section 7   Acronyms                                                25




            Figure 13: Drink Vending Machine CO-OPN Class Diagram
26                                                           Luis Pedro




     Figure 14: Drink Vending Machine CO-OPN Class Diagram
Section 7   Acronyms                                           27




               Figure 15: UML2 to CO-OPN State Chart diagram
28   Luis Pedro
SMV Technical Reports
This report is in the series of SMV technical reports. The series editor is Didier
Buchs (Didier.Buchs@unige.ch).

Any views or opinions contained in this report are solely those of the author, and
do not necessarily represent those of SMV group, unless specifically stated and the
sender is authorized to do so.


You may order copies of the SMV technical reports from the corresponding author
or the series editor. Most of the reports can also be found on the web pages of the
SMV group (http://smv.unige.ch/).

								
To top