The state machine generator create or update the classes implementing a behavioral state machine on which it is applied.
Currently the state machine generator only generates C++ definitions.
When you apply this plug-out on a state machine, a class having the same name (removing non legal characters) is created (or updated in case it already exist) in the same class view to implement it. This class doesn't contain static attributes and may have several instances. Each sub-state is managed through an own sub-class, the tree of the states and the associated classes is the same. For each trigger, whatever the state waiting for it, an operation having the same name (the C++ trigger must have a legal C++ name, the C++ guards must be legal C++ forms etc ...) is defined. Currently the triggers can't have parameters, and a transition can't have several triggers. You must apply these operations on the instance of the class implementing the state machine to simulate the event, the returned value is true until the final state is reached. The operation starting the execution is named create (the only legal trigger for a transition from an initial pseudo state). The operation doActivity() allows to explicitly execute out of a transition the do activity of the current state if it is not empty. A trigger's name can't start by the character '_', allowing me to produce operations and attributes starting by '_' without collision.
For instance, in case you apply the state machine generator on the following state machine :
you will obtain these definitions :
Having an instance of ReadAmount, you must first call create to execute the initial transition, then you may call otherAmount etc ...
When you modify the state machine then you recall this plug-out, the classes are updated. The classes, operations and attributes produced by a previous state machine definition but now useless are deleted. Warning : if a state or other elements is renamed or was moved to have a new parent, the corresponding class or class member is deleted and a new one is created. If you add classes or class members, these ones will not be deleted while their container is not itself deleted, and if they don't have a user property named STM generated (so, don't duplicate elements created by the state machine generator to not have this property or remove it after).
Some parts of the generated source code are instrumented to produce a debug message using iostream. The instrumentation is always a form :
#ifdef VERBOSE_STATE_MACHINE
cout << "the message" << endl;
#endif
To activate these traces you must compile the code defining VERBOSE_STATE_MACHINE.
Previous : Roundtrip body
Next : XMI generator