States and Regions

State

A State models a condition or situation in the execution of a State Machine during which an invariant condition holds. While usually implied by the name associated with the State, it represents a period where the system satisfies specific criteria or executes active Behaviors before transitioning in response to Event occurrences.

A Simple State is an atomic leaf state that has no internal Vertices or Transitions. It serves as a primary resting point within an active State configuration during execution.

Operations

• Creating:

  Click the State Stencil in the Stencil Toolbar, then click anywhere within the Canvas or a State Region to create a new simple State.

• Renaming:

  Select the State on the Canvas and edit the Name field in the Properties Panel. A State's name must be unique within the containing State Machine SV1002.

• Moving & Reparenting:

  • Repositioning:

    Click and drag the State across the Canvas or within its current Region to change its visual location.

  • Reparenting:

    To move a State to a different Region (or out onto the root Canvas), select the State, drag it over the target Region or Canvas, and hold the Alt key while releasing the mouse button.

• Resizing a State:

  Select the State and drag its edges or corners to adjust its size. A State's dimensions cannot be reduced below the bounds of its connected Transitions, Connection Points, or contained Regions SV1011.

• Deleting:

  Select the State on the Canvas and hit Delete, or right-click the State and select Delete from the context menu. Deleting a State automatically deletes all its Transitions and contained Regions (cascade delete).

• Editing Notes:

  Select the State and edit the Notes field in the Properties Panel (maximum 500 characters SV1031).

UML 2.5.1 Specification (Subclause 14.2.3.4):

“A State models a situation in the execution of a StateMachine Behavior during which some invariant condition holds. In most cases this condition is not explicitly defined, but is implied, usually through the name associated with the State... A simple State has no internal Vertices or Transitions.”

State Behaviors

State Behaviors define actions executed during specific phases of a State's lifecycle. A State can specify up to three distinct internal Behaviors: Entry, Exit, and DoActivity.

While Entry and Exit Behaviors execute synchronously during state transitions, a DoActivity Behavior represents ongoing work that runs asynchronously while the State remains active.

Note:

Behaviors are stored at the root State Machine level and referenced across elements. This maintains a single source of truth across all States, Transitions, and Submachines for maximum reusability. Edits made to a Behavior automatically propagate to all of its references SV1009.

Operations

• Opening the State Behaviors Window:

  Right-click a State and select Edit Behaviors, or select the State and press Enter to open the State Behaviors Window. This window features dedicated tabs and sections to manage Entry, DoActivity, and Exit Behaviors for the selected State.

• Referencing a State Machine Behavior:

  In the top input box, type text to filter existing State Machine Behaviors, then select an item from the results list to create a reference. To create and reference a new State Machine Behavior, type the name and press Enter or click the Add button. A Behavior name must be unique across all Behavior types SV1008.

• Ordering:

  Behaviors execute top-down in order of priority. Select a Behavior reference and use the Move Up or Move Down buttons in the toolbar to reorder execution sequence.

• Renaming:

  Double-click a Behavior or select it and click the Edit button in the toolbar to rename it. Renaming automatically propagates to all existing references across the State Machine. A Behavior name must be unique across all Behavior types SV1008.

• Removing References:

  Select one or more Behavior references (multi-select using Ctrl or Shift) and click the Remove (X) button in the toolbar. This detaches the reference from the State without deleting the underlying State Machine Behavior definition.

• Clearing References:

  Click the Clear button in the toolbar to remove all Behavior references from the active tab at once.

• Deleting Behaviors:

  Select a Behavior and click the Delete button in the toolbar to delete the underlying State Machine Behavior definition. This performs a cascade delete, removing all references across the entire State Machine tree and clearing the Undo/Redo history for all affected Canvases.

• Finding References:

  Select a Behavior and click the Find References button in the toolbar to open a navigable result list in the Bottom Panel of the Editor Interface.

• Editing Notes:

  Select the Behavior and edit the Notes field at the bottom of the tab section (maximum 500 characters SV1031).

UML 2.5.1 Specification (Subclause 14.2.3.4.3):

“A State may have an associated entry Behavior. This Behavior, if defined, is executed whenever the State is entered through an external Transition. In addition, a State may also have an associated exit Behavior, which, if defined, is executed whenever the State is exited.

A State may also have an associated doActivity Behavior. This Behavior commences execution when the State is entered (but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be associated with the State, until:
• it completes (in which case a completion event is generated) or
• the State is exited, in which case execution of the doActivity Behavior is aborted.

The execution of a doActivity Behavior of a State is not affected by the firing of an internal Transition of that State.”

Composite State and Regions

A composite State is a hierarchical State that contains at least one internal Region enclosing substates and transitions. It allows complex State Machine models to be decomposed into modular, nested execution structures.

When a composite State contains two or more concurrent Regions, it becomes an orthogonal State. Each orthogonal Region maintains its own independent active substate configuration, allowing parallel behaviors to execute simultaneously within a single composite State boundary.

Operations

• Make a State composite:

  Convert a simple State into a composite State by adding one or more orthogonal Regions. Right-click the State and select New Region from the context menu.

• Renaming a Region:

  Select the Region and edit the Name field in the Properties Panel. A Region's name must be unique within the parent State SV1013.

• Add Vertices to a Region:

  Select a Vertex stencil from the Stencil Toolbar and click inside the target Region. Vertices can be freely moved and resized within their parent Region; the entire parent hierarchy (including the top-level Canvas) automatically expands to accommodate descendant layout changes.

• Change Region Priority:

  Orthogonal Regions execute top-to-bottom based on visual order. You can adjust a Region's execution priority using the Properties Panel.

• Resizing a Region:

  Select the Region and drag its edges to adjust its size. A Region cannot be reduced below the bounds of its contained Vertices, nor below the locations of Transitions and Connection Points anchored to its parent State's edges SV1012.

• Multi-Select Vertices in a Region:

  To select multiple Vertices within a Region, hold Ctrl while clicking individual elements, or hold Shift while dragging the Rubberband Selector.

• Editing Notes for a Region:

  Select the Region and edit the Notes field in the Properties Panel (maximum 500 characters SV1031).

• Reparenting Vertices:

  Select the Vertices, drag them over the target Region or the Canvas, and hold Alt before releasing to drop them inside.

• Add Entry or Exit Points:

  Select an Entry Point or Exit Point stencil from the Stencil Toolbar and click on a composite State. These Connection Points automatically anchor to the outer boundaries of their parent State, and cannot be reparented to a different State. A Connection Point can only be added to a composite State. SV1020 SV1021 SV1014

UML 2.5.1 Specification (Subclause 14.2.3.4.1 & 14.2.3.4.2):

“A composite State contains at least one Region... A composite State can be either a simple composite State with exactly one Region or an orthogonal State with multiple Regions (isOrthogonal = true)...

A particular ‘state’ of an executing StateMachine instance is represented by one or more hierarchies of States, starting with the topmost Regions of the StateMachine and down through the composition hierarchy to the simple, or leaf, States... An executing StateMachine instance can only be in exactly one state configuration at a time, which is referred to as its active state configuration.”

State History

State history is a mechanism associated with Regions of composite States that tracks the active substate configuration when a Region is exited. When a Transition later targets a history Pseudostate within that Region, execution restores the preserved state configuration instead of executing the default entry path.

For step-by-step authoring workflows, visual representation, and specific rule validations, refer to the dedicated Shallow History or Deep History articles.

UML 2.5.1 Specification (Subclause 14.2.3.4.4):

“The concept of State history was introduced by David Harel in the original statechart formalism. It is a convenience concept associated with Regions of composite States whereby a Region keeps track of the state configuration it was in when it was last exited. This allows easy return to that same state configuration, if desired, the next time the Region becomes active...

Two types of history Pseudostates are provided. Deep history (deepHistory) represents the full state configuration of the most recent visit to the containing Region... Shallow history (shallowHistory) represents a return to only the topmost substate of the most recent state configuration, which is entered using the default entry rule.”

Deferred Events

Deferred Events allow a State to postpone the processing of specific Event occurrences while it remains active. Instead of being dispatched or discarded, deferred Events are held in the event pool and automatically re-evaluated once the State Machine transitions to a state configuration where those Events are no longer deferred.

Events for a State can be deferred by configuring an Internal Transition for the State.

UML Specification (Subclause 14.2.3.4.4):

“A State may specify a set of Event types that may be deferred in that State. This means that Event occurrences of those types will not be dispatched as long as that State remains active. Instead, these Event occurrences remain in the event pool until:
• a state configuration is reached where these Event types are no longer deferred or,
• if a deferred Event type is used explicitly in a Trigger of a Transition whose source is the deferring State...

An Event may be deferred by a composite State or submachine States, in which case it remains deferred as long as the composite State remains in the active configuration.”

Submachine State

A Submachine State is a specialized State reference that invokes an entire, distinct State Machine definition within its containing State Machine. Similar to a programming language macro or reusable sub-routine, it allows common execution patterns to be encapsulated once and instantiated across multiple contexts.

Incoming and outgoing Transitions bind to the internal execution structure of the referenced Submachine through Connection Point References. Each Submachine State represents an independent runtime instantiation of its referenced State Machine model.

Operations

• Creating:

  Click the Submachine State Stencil in the Stencil Toolbar, then click anywhere within the Canvas or a State Region to open the Submachine Selection Window. You can select an existing Submachine or create and reference a new one directly from this window.

• Renaming:

  Select the Submachine State and edit the Name field in the Properties Panel. A Submachine State's name must be unique within the containing State Machine SV1002.

• Moving & Reparenting:

  • Repositioning:

    Click and drag the Submachine State across the Canvas or within its current Region to change its visual location.

  • Reparenting:

    To move a Submachine State to a different Region (or out onto the root Canvas), select the Submachine State, drag it over the target Region or Canvas, and hold the Alt key while releasing the mouse button.

• Resizing:

  Select the Submachine State and drag its edges or corners to adjust its size. A Submachine State's dimensions cannot be reduced below the bounds of its connected Transitions or Connection Point References SV1011.

• Deleting:

  Select the Submachine State on the Canvas and hit Delete, or right-click the Submachine State and select Delete from the context menu. Deleting a Submachine State automatically deletes all its Transitions and Connection Point References.

• Navigating to the Submachine:

  To navigate to the referenced Submachine, right-click the Submachine State and select Open Submachine from the context menu, or click the Submachine Link in the Properties Panel.

Connection Point References

Connection Point References enable explicit execution binding between the outer Submachine State and the entry/exit boundaries of its referenced Submachine.

• Creating:

  First, create new Entry or Exit Points in the Submachine's top-level composite State. Next, navigate to the referencing Submachine State, and right-click it. Hovering over the Add Connection Point Reference submenu displays all available references to the Submachine's Connection Points. Select an item from this list to create a new Connection Point Reference SV1007.

• Deleting:

  Select the Connection Point Reference on the Submachine State and hit Delete, or right-click and select Delete from the context menu. Deleting an Entry or Exit Point from a Submachine automatically deletes all corresponding Connection Point References across all referencing Submachine States (cascade delete).

• Editing Notes:

  Select the Connection Point Reference and edit the Notes field in the Properties Panel (maximum 500 characters SV1031).

UML Specification (Subclause 14.2.3.4.7):

“Submachines are a means by which a single StateMachine specification can be reused multiple times... This is achieved through the concept of submachine State (i.e., States with isSubmachineState = true), which represent references to corresponding submachine StateMachines. The concept of ConnectionPointReference is provided to support binding between the submachine State and the referenced StateMachine.

A submachine State implies a macro-like insertion of the specification of the corresponding submachine StateMachine. It is, therefore, semantically equivalent to a composite State... Each submachine State represents a distinct instantiation of a submachine, even when two or more submachine States reference the same submachine.”

Final State

A Final State is a specialized State that signifies the enclosing Region or State Machine has completed its execution. Entering a Final State indicates that all active Behaviors within that Region have terminated, triggering a completion Event for the containing composite State or State Machine.

Unlike standard States, a Final State cannot contain internal Regions, Vertices, or State Behaviors, nor can it serve as the source for outgoing Transitions.

Operations

• Creating:

  Click the Final State Stencil in the Stencil Toolbar, then click anywhere within the Canvas or a State Region to create a new Final State.

• Renaming:

  Select the Final State and edit the Name field in the Properties Panel. A Final State's name must be unique within the containing State Machine SV1002.

• Moving & Reparenting:

  • Repositioning:

    Click and drag the Final State across the Canvas or within its current Region to change its visual location.

  • Reparenting:

    To move a Final State to a different Region (or out onto the root Canvas), select the Final State, drag it over the target Region or Canvas, and hold the Alt key while releasing the mouse button.

• Deleting:

  Select the Final State on the Canvas and hit Delete, or right-click the Final State and select Delete from the context menu. Deleting a Final State automatically deletes all its Transitions.

• Resizing:

  A Final State has a fixed visual footprint and cannot be manually resized SV1018.

UML Specification (Subclause 14.2.3.6):

“FinalState is a special kind of State signifying that the enclosing Region has completed. Thus, a Transition to a FinalState represents the completion of the behaviors of the Region containing the FinalState.”