EA beta v11 - new state machine code generation

[C@localhost 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

[original message]

[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  ;)
[original message]

[C@localhost David C]

Yes it does help  ;) thanks.

I was trying to set up an heirarchcal FSM, and trace the transitions.
My observations so far are as follows:
- State1

- Internal state do not call it's parent's do behavior periodically.
- Transitions from parent composite states are not invoked.

[img][/img]
[original message]

[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
  ....
  

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. ;)
[original message]