Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.

Modeling Executable Statemachines

Most of the work required to model an Executable State Machine is standard UML based modeling of Classes and State models. There are a couple of conventions that must be observed to ensure a well formed code base. The only novel construct is the use of a stereotyped Artifact element to form the configuration of an Executable State Machine instance or scenario. The Artifact is used to specify details such as:

The code language (Javascript, C#, Java, C++ including C)
The Classes and State Machines involved in the scenario
The instance specifications including run-state; note that this could include multiple instances of the same State Machine, for example where a 'Player' Class is used twice in a Tennis Match simulation.

Basic Modeling Tools and Objects for Executable State Machines

This table details the primary modeling elements used when building Executable State Machines.

Object	Details
Classes and Class Diagrams	Classes define the object types that are relevant to the State Machine(s) being modeled. For example, in a simple Tennis Match scenario you might define a Player, a Match, a Hit and an Umpire Class. Each will have its own State Machine(s) and at runtime will be represented by object instances for each involved entity. See the UML modeling guide for more information on Classes and Class diagrams.
State Machines	For each Class you define that will have dynamic behavior within a scenario, you will typically define one or more UML State Machines. Each State Machine will determine the legal state-based behavior appropriate for one aspect of the owning Class. For example, it is possible to have a State Machine that represents a Player's emotional state, one that tracks his current fitness and energy levels, and one that represents his winning or losing state. All these State Machines will be initialized and started when the State Machine scenario begins execution.
Executable StateMachine Artifact	This stereotyped Artifact is the core element used to specify the participants, configuration and starting conditions for an Executable State Machine. From the scenario point of view it is used to determine which Instances (of Classes) are involved, what events they might Trigger and send to each other, and what starting conditions they operate under. From the configuration aspect, the Artifact is used to set up the link to an analyzer script that will determine output directory, code language, compilation script and similar. Right clicking on the Artifact will allow you to generate, build, compile and visualize the real time execution of your State Machines.

Object

Details

Classes and Class Diagrams

Classes define the object types that are relevant to the State Machine(s) being modeled. For example, in a simple Tennis Match scenario you might define a Player, a Match, a Hit and an Umpire Class. Each will have its own State Machine(s) and at runtime will be represented by object instances for each involved entity. See the UML modeling guide for more information on Classes and Class diagrams.

State Machines

For each Class you define that will have dynamic behavior within a scenario, you will typically define one or more UML State Machines. Each State Machine will determine the legal state-based behavior appropriate for one aspect of the owning Class. For example, it is possible to have a State Machine that represents a Player's emotional state, one that tracks his current fitness and energy levels, and one that represents his winning or losing state. All these State Machines will be initialized and started when the State Machine scenario begins execution.

Executable StateMachine Artifact

This stereotyped Artifact is the core element used to specify the participants, configuration and starting conditions for an Executable State Machine. From the scenario point of view it is used to determine which Instances (of Classes) are involved, what events they might Trigger and send to each other, and what starting conditions they operate under.

From the configuration aspect, the Artifact is used to set up the link to an analyzer script that will determine output directory, code language, compilation script and similar. Right clicking on the Artifact will allow you to generate, build, compile and visualize the real time execution of your State Machines.

State Machine Constructs Supported

This table details the State Machine constructs supported and any limitations or general constraints relevant to each type.

Construct	Description
State Machines	Supported Simple State Machine: State Machine has one region. Orthogonal State Machine: State Machine contains multiple regions. Top level region (owned by State Machine) activation semantics: Default Activation: When the State Machine starts executing. Entry Point Entry: Transitions from Entry Point to vertices in the contained regions. Note 1: In each Region of the State Machine owning the Entry Point, there is at most a single Transition from the entry point to a Vertex within that Region. Note 2: This State Machine can be referenced by a Submachine State. Connection point reference should be defined in the Submachine State as sources/targets of transitions. The Connection point reference represents a usage of an Entry/Exit Point defined in the State Machine and referenced by the Submachine State. Not Supported Protocol State Machine State Machine Redefinition
States	These State types are supported: Simple State: has no internal Vertices or Transitions. Composite State: contains exactly one Region. Orthogonal State: contains multiple Regions. Submachine State: refers to an entire State Machine
Composite State Entry	Supported. Default Entry Explicit Entry Shallow History Entry Deep History Entry Entry Point Entry
Substates	Supported. Sub States and Nested Sub States. Entry and Exit semantics where transition covers multiple nested levels of states will obey correct execution of nested behaviors (such as OnEntry and OnExit).
Transitions support	Supported: External Transition Local Transition Internal Transition (draw a self Transition and change Transition kind to Internal) Completion Transition and Completion Events Transition Guards Compound Transitions Firing priorities and selection algorithm For further details, refer to the UML Specification.
Trigger and Events	An Executable State Machine supports event handling only for Signals. To use Call, Timing or Change Event types you need to define an outside mechanism to generate signals based on these events.
Signal	Supported. Attributes can be defined in Signals; the value of the attributes can be used as event arguments in Transition Guards and Effects. For example, this is the code set in the effect of a transition in C++: if(signal->signalEnum == ENUM_SIGNAL2) { int xVal = ((Signal2*)signal)->myVal; } Signal2 is generated as this code: class Signal2 : public Signal{ public: Signal2(){}; Signal2(std::vector<String>& lstArguments); int myVal; }; Note: Further details can be found by generating an Executable State Machine and referring to the generated 'EventProxy' file.
Initial	Supported. An initial Pseudostate represents a starting point for a Region; It is the source for at most one Transition;There can be at most one initial Vertex in a Region.
Regions	Supported. Default Activation & Explicit Activation: Transitions terminate on the containing state: If initial Pseudostate is defined in the Region: Default activation; If no initial Pseudostate is defined, region will remain inactive and the containing state is treated as a Simple state. Transition terminate on one of the region's contained vertices: Explicit activation. This will result in the default activation of all of its orthogonal Regions, unless those Regions are also entered explicitly (multiple orthogonal Regions can be entered explicitly in parallel through Transitions originating from the same fork Pseudostate). For example, if there are 3 regions defined for a Orthogonal State, if RegionA and RegionB have initial Pseudostate, then RegionC is explicitly activated, default Activation applies to RegionA and RegionB; the containing state will have 3 active regions.
Choice	Supported. Guard Constraints on all outgoing Transitions are evaluated dynamically, when the compound transition traversal reaches this Pseudostate.
Junction	Supported. Static conditional branch: guard constraints are evaluated before any compound transition is executed.
Fork / Join	Supported. Non-threaded, each active region move one step alternatively based on completion event pool mechanism.
EntryPoint / ExitPoint Nodes	Supported. Non-threaded for orthogonal state or orthogonal statemachine; each active region move one step alternatively based on completion event pool mechanism.
History Nodes	Supported. DeepHistory: represents the most recent active state configuration of its owning State. ShallowHistory: represents the most recent active substate of its containing State, but not the substates of that substate.
Deferred Events	Supported. Draw a self Transition and change Transition kind to Internal. Type 'defer();' in the 'Effect' field for the transition.
Connection Point References	Supported. A connection point reference represents a usage (as part of a submachine State) of an Entry/Exit Point defined in the StateMachine referenced by the Submachine State. Connection point references of a submachine State can be used as sources/targets of Transitions. They represent entries into or exits out of the StateMachine referenced by the Submachine State.
State behaviors	Supported. State entry, doActivity and exit behavior can be defined as Operations on a state. The code that will be used for each behavior is entered into the 'initial code' field by default. Note that this could be changed to 'Behavior' field via customization of the generation template. The doActivity behavior generated will be run to completion before proceeding. The code is not concurrent as to other entry behavior; the doActivity behavior is implemented as execute in sequence after entry behavior.

Reusing Executable Statemachine Artifacts

You can create multiple models or versions of a component using a single executable Artifact. An Artifact representing a resistor, for example, could be re-used to create both a foil resistor and a wire wound resistor. This is likely the case for similar objects who although represented by the same classifier, typically exhibit different run states. A property named 'resistorType' taking the value 'wire' rather than 'foil' might be all that is required from a modeling point of view. The same State Machines can then be re-used to test behavioral changes that might result due to variance in run-state. This is the procedure:

Step	Action
Create or open component diagram	Open a component diagram to work on. This might be the diagram that contains your original artifact.
Select the Executable State Machine to copy	Now find the original Executable Statemachine Artifact in the Project Browser.
Create the New Component	Whilst holding the Ctrl key, drag the original artifact on to your diagram. You will be prompted with two questions. The answer to the first is Object and to the second All. Rename the artifact to differentiate it from the original and then proceed to alter its property values.

Step

Action

Create or open component diagram

Open a component diagram to work on. This might be the diagram that contains your original artifact.

Select the Executable State Machine to copy

Now find the original Executable Statemachine Artifact in the Project Browser.

Create the New Component

Whilst holding the Ctrl key, drag the original artifact on to your diagram. You will be prompted with two questions.

The answer to the first is Object and to the second All. Rename the artifact to differentiate it from the original and then proceed to alter its property values.