States and Behaviors

A State is created within the context of a StateMachine and is used to model the engineer-defined significant condition of the owning Block. It is important to remember that the StateMachine is describing the lifetime of the Block from a particular perspective, and the States must be defined from this point of view - not all States, but the significant ones such as On/Off, Open/Closed, Green/Amber/Red or Ice/Water/Vapor. Formally, a State models a situation in the execution of a StateMachine Behavior where some invariant condition holds for a particular duration.

A Block typically spends some time in a given State, which might last nanoseconds or days depending on the context; this temporal aspect is not typically codified in the models but can be set in a simulation. There are three behaviors (called Actions) that can be defined with respect to any given State:

• Entry - Fired when a State is entered
• Do - Fired after the Entry behavior and before the Exit behavior
• Exit - Fired before the State is exited

This diagram shows how these States are represented in a StateMachine diagram. Enterprise Architect can conditionally display these and other compartments at the level of an individual element, or collectively for all elements on the diagram.

It is also important to note that the Final node is formally also a State, but it does not have the same semantics of behavior as the States represented on diagrams as rectangles with rounded corners.

There are three fundamental types of State, each of which is important for modeling a different class of problem:

• Simple State - does not contain internal States
• Composite State - contains a least one region that owns States
• Submachine State - represents an entire StateMachine that is nested within the owning State

Enterprise Architect allows you to model each of these State types, and a modeler can use them productively in StateMachine diagrams to express real world engineering problems and solutions.