State Machine Behaviors

Overview

State Machine 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.

Behaviors are categorized into four distinct types:

• Events:

  Utilized exclusively by Transitions to trigger state changes.

• Actions:

  Applied to a State’s Entry and Exit Behaviors, or used as a Transition’s Effect Behavior.

• DoActivity Actions:

  Reserved exclusively for a State’s ongoing DoActivity Behavior.

• Guards:

  Used solely to define Transition Guard conditions.

Note: Submachine Behavior Repository Inheritance

Submachines inherit the Behaviors of their root State Machine and do not maintain a separate Behavior repository SV1030.

Events

An Event Behavior represents a signal or occurrence that can trigger a state transition within a State Machine execution. Events are utilized exclusively by Transitions to trigger state changes.

Operations

An Event Behavior can be managed from either the State Machine Behaviors Window or the Transition Behaviors Window. The operations for the State Machine Behaviors Window are listed below. To learn about managing Events directly on a transition, refer to Transition Behaviors.

• Opening the Events Management Tab:

  Click the E shortcut button in the Main Toolbar to open the State Machine Behaviors Window focused on the Events Management Tab.

• Creating:

  To create a new Event Behavior, type the name in the top input box and press Enter or click the Add button. A Behavior name must be unique across all Behavior types SV1008 and follow the system naming convention SV1010.

• Renaming:

  Double-click an Event 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 SV1008 SV1010.

• Deleting:

  Select the 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.

• Sorting:

  Use the Sort Ascending and Sort Descending toggle buttons in the toolbar, or uncheck both to sort ascending by creation time.

• Editing Notes:

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

UML Specification (Subclause 14.2.3.8):

“A Transition may own a set of Triggers, each of which specifies an Event whose occurrence, when dispatched, may trigger traversal of the Transition. A Transition trigger is said to be enabled if the dispatched Event occurrence matches its Event type. When multiple triggers are defined for a Transition, they are logically disjunctive, that is, if any of them are enabled, the Transition will be triggered.”

Actions

An Action Behavior represents an executable computation or behavior definition within a State Machine. Actions are applied to a State’s Entry and Exit Behaviors, or used as a Transition’s Effect Behavior.

Operations

An Action Behavior can be managed from either the State Machine Behaviors Window, the Entry and Exit tabs of the State Behaviors Window, or the Effect tab of the Transition Behaviors Window. The operations for the State Machine Behaviors Window are listed below. To learn about managing behaviors on states or transitions, refer to State Behaviors and Transition Behaviors.

• Opening the Actions Management Tab:

  Click the A shortcut button in the Main Toolbar to open the State Machine Behaviors Window focused on the Actions Management Tab.

• Creating:

  To create a new Action Behavior, type the name in the top input box and press Enter or click the Add button. A Behavior name must be unique across all Behavior types SV1008 and follow the system naming convention SV1010.

• Renaming:

  Double-click an Action 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 SV1008 SV1010.

• Deleting:

  Select the 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.

• Sorting:

  Use the Sort Ascending and Sort Descending toggle buttons in the toolbar, or uncheck both to sort ascending by creation time.

• Editing Notes:

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

UML Specification (Subclauses 14.2.3.4.3 & 14.2.3.8):

“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 Transition is a single directed arc originating from a single source Vertex and terminating on a single target Vertex... It may have an associated effect Behavior, which is executed when the Transition is traversed (executed)...”

DoActivity Actions

A DoActivity Action Behavior represents an ongoing, asynchronous execution carried out while a State remains active. DoActivity Actions are reserved exclusively for a State’s ongoing DoActivity Behavior.

Operations

A DoActivity Action Behavior can be managed from either the State Machine Behaviors Window or the DoActivity tab of the State Behaviors Window. The operations for the State Machine Behaviors Window are listed below. To learn about managing behaviors directly on states, refer to State Behaviors.

• Opening the DoActivity Actions Management Tab:

  Click the D shortcut button in the Main Toolbar to open the State Machine Behaviors Window focused on the DoActivity Actions Management Tab.

• Creating:

  To create a new DoActivity Action Behavior, type the name in the top input box and press Enter or click the Add button. A Behavior name must be unique across all Behavior types SV1008 and follow the system naming convention SV1010.

• Renaming:

  Double-click a DoActivity Action 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 SV1008 SV1010.

• Deleting:

  Select the 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.

• Sorting:

  Use the Sort Ascending and Sort Descending toggle buttons in the toolbar, or uncheck both to sort ascending by creation time.

• Editing Notes:

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

UML Specification (Subclause 14.2.3.4.3):

“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.”

Guards

A Guard Behavior represents a boolean condition or constraint evaluated prior to or during transition traversal. Guards are used solely to define Transition Guard conditions.

Operations

A Guard Behavior can be managed from either the State Machine Behaviors Window or the Guards tab of the Transition Behaviors Window. The operations for the State Machine Behaviors Window are listed below. To learn about managing behaviors directly on transitions, refer to Transition Behaviors.

• Opening the Guards Management Tab:

  Click the G shortcut button in the Main Toolbar to open the State Machine Behaviors Window focused on the Guards Management Tab.

• Creating:

  To create a new Guard Behavior, type the name in the top input box and press Enter or click the Add button. A Behavior name must be unique across all Behavior types SV1008 and follow the system naming convention SV1010.

• Renaming:

  Double-click a Guard 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 SV1008 SV1010.

• Deleting:

  Select the 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.

• Sorting:

  Use the Sort Ascending and Sort Descending toggle buttons in the toolbar, or uncheck both to sort ascending by creation time.

• Editing Notes:

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

UML Specification (Subclause 14.2.3.8.3):

“A Transition may have an associated guard Constraint. Transitions that have a guard which evaluates to false are disabled. Guards are evaluated before the compound transition that contains them is enabled, unless they are on Transitions that originate from a choice Pseudostate. In the latter case, the guards are evaluated when the choice point is reached. A Transition that does not have an associated guard is treated as if it has a guard that is always true.”