EA beta v11 - new state machine code generation

[David C]

Hi

While trying to generate code from the new v11 state machine templates I have noticed that the only class generated is the one containing the actual state machine. Other required classes (such as ContextManager and EventsProxy) referenced in the FSM class are not generated. The code is therefore not compilable.
I would be grateful to know if anyone have actually managed to enerate, compile and test the new state machine implementation.

Best regards
David Carmeli

[MMA]

0. Create a class diagram;
    Create a class element on it; E.g. "Class1"
    Context menu on the Class element in the project browser | Add | State Machine;
    Model your statemachine.

1. hit SPACE bar on the class diagram, at the very bottom | Artifacts | Executable StateMachine. E.g. "Artifact1" with "executable statemachine" as stereotype;

2. Enlarge "Artifact1";
    Ctrl + Drag "Class1" from Project Browser and drop on "Artifact1";
    Paste as "Property" | OK;

3. "Alt + 1" to open the Element Properties window;
    Select "Artifact1";
    Specify the Language as on of the supported "Java/C++/C/C#/JavaScript";
    Context menu on "Artifact1" | Code Engineering | Executable StateMachine | Generate.

4. Examples of compiler's path (your machine might be different):
    Java:
        JAVA_HOME: C:\Program Files (x86)\Java\jdk1.7.0_17
    C/C++:
        VC_HOME :   C:\Program Files (x86)\Microsoft Visual Studio 9.0
    C#:
        CS_HOME :   C:\Windows\Microsoft.NET\Framework\v3.5
    JavaScript:
        Don't need any setting.

5. Specify a path and generate.
    Take Java for example, you will find following files generated:
    Class1.java / Context Manager.java / SimulationManager.java / EventProxy.java / ConsoleManager.java
    
6. Context menu on Artifact1 | Code Engineering | Executable StateMachine | Build;
    
7. If the build succeeded, "Artifact1 | Code Engineering | Executable StateMachine | Run", you will see the simulation started in EA

NOTE:
(1) You can drag multiple classes into one Artifact, even the same class as multiple properties into the same Artifact. In this way, you can simulate interaction between classes (multiple statemachines) via broadcast events.

(2) When you want to test on multiple languages, You can Ctrl + Drag the Artifact on the diagram and drop as Instance (with all Structural Elements) for each of the language and generate code from the instance of the Artifact.

(3) During the Generation process, there is a Validation function that might detect any diagramming or modeling error against the UML constraints. The result will be showing in the "System | Executable State Machine Output" window, read the error message and double click it to guide you to the element on the diagram, and you fix it. Then generate again.

(4) Analyzer | Simulation Events window to trigger the events;
     Analyzer | Simulation window will print the trace in accordance with the simulation. Like this:

[03516677]      Part1[Class1].Initial_367__TO__State4_142 Effect
[03516683]      Part1[Class1].StateMachine_State4 ENTRY
[03516684]      Part1[Class1].StateMachine_State4 DO
[03518375]      Blocked

Hope that helps  

[David C]

It did help. Thanks!

The new code generation templates look promising. Nice work  
As I am mostly interested in hierarchical FSMs, I have created a composite HSM:
https://www.dropbox.com/s/aqbd46wx1rqvnft/UN_fsm.jpg

Code genration is producing the following states enums:
enum StateEnum
{
    NOSTATE,
    TmpMgrFsm_VIRTUAL_SUBMACHINESTATE,
    TmpMgrFsm_ENUM_TMPMGRFSM_STATE1,
    TmpMgrFsm_ENUM_TMPMGRFSM_STATE2,
    TmpMgrFsm_ENUM_TMPMGRFSM_FINAL_60,
    TmpMgrFsm_ENUM_TMPMGRFSM_STATE1_STATE11,
    TmpMgrFsm_ENUM_TMPMGRFSM_STATE1_STATE12,
    TmpMgrFsm_ENUM_TMPMGRFSM_STATE1_STATE12_FINAL_33,
    TmpMgrFsm_ENUM_TMPMGRFSM_STATE1_STATE12_STATE121,
    TmpMgrFsm_ENUM_TMPMGRFSM_STATE1_STATE12_STATE122
};

And transitions as follows:
      enum TransitionEnum
      {
      NOTRANSITION,
      TmpMgrFsm_ENUM_INITIAL_50__TO__STATE1_28,
      TmpMgrFsm_ENUM_STATE12__TO__STATE2_32,
      TmpMgrFsm_ENUM_STATE2__TO__HISTORY_17_6,
      TmpMgrFsm_ENUM_STATE1__TO__FINAL_60_35,
      TmpMgrFsm_ENUM_INITIAL_58__TO__STATE11_31,
      TmpMgrFsm_ENUM_STATE11__TO__STATE12_11,
      TmpMgrFsm_ENUM_STATE122__TO__STATE121_34,
      TmpMgrFsm_ENUM_STATE121__TO__STATE122_14,
      TmpMgrFsm_ENUM_STATE121__TO__FINAL_33_20,
      TmpMgrFsm_ENUM_INITIAL_52__TO__STATE121_30
      };



I am holding a simple integer T in the FSM class which is manually set to 0 in the constructor and serve as simple guard for state transitions.

My observations so far are as follows:
- Entry and exist behaviors are recursively invoked as expected.
- Hierarchical DO behavior of parent state are not invoked (e.g. while being in STATE121 no DO calls are invoked for STATE12, and STATE1)
- Common transitions from composite state (such as from STATE12 to STATE2 while being in STATE121 or STATE122) are not triggered.
- Guards as means of triggering mechanism on the transitions (T>4 etc..) are ignored, and transitions do not occure.
Would be great to know if I am missing something…

[MMA]

Hi David,

Seen from your HSM, following things need to be considered:

1. Currently, the doActivity behavior is implemented as starting to execute after ENTRY behavior.
So you should be able to see following sequence:

• State1.Entry

State1.Do
Transition from Initial to State11
State11.Entry
State11.Do
State11.Exit
Transition from State11 to State12
State12.Entry
State12.Do
Transition from Initial to State121
State121.Entry
State121.Do
....
[/list]

2. "Common transitions" as you referred, or "Ultimate Hook" pattern technically, which means if the current state can not handle the trigger, try the parent, until one of the ancestor can handle the trigger.

Actually, I didn't find any trigger used in your model, then the transitions are "Completion Transition". Completion transition should not be applied the "Ultimate Hook" pattern.

According to the UML specification, the only way to get transition from State12 to State2 traversed is to reach a "Final"(you missed it in your model) inside State12.

Meanwhile, since there aren't any "Final" node inside State1 nor any trigger defined on the "transition from State1 to Final", the transition will never have a chance to be invoked.

The features you used in the model should already be well supported by the new statemachine.

Hope that helps.