Skip to content

State Machine Orthogonal State

Mikołaj Milewski edited this page Oct 27, 2026 · 1 revision

Orthogonal State

Orthogonal State represents stable configuration of State Machine that also contains its own set of States (referred to as its substates) grouped in Regions. Regions owned by Orthogonal State are orthogonal to each other - this means, there can be an active substate in each such Region at the same time. Orthogonal State is the way to introduce both State nesting and orthogonality (parallelism) concepts to defined State Machine.

Composite State can be seen as Orthogonal State with exactly one Region - no orthogonality (parallelism), just nesting of States.

Orthogonal State consist of:

  • Name, uniquely identifying State within State Machine,
  • Parent State, if State is a substate of Composite State or Orthogonal State,
  • OnEntry, logic that is executed when State is entered,
  • OnExit, logic that is executed when State is exited,
  • OnInitialize, logic that is executed when State is initialized,
  • OnFinalize, logic that is executed when State is finalized,
  • Set of outgoing Transitions.
  • Set of Regions with their States.

Definition

In UML, Orthogonal State is represented by rounded rectangle with compartments (representing Regions) that are containers for other States:

stateDiagram-v2
state Keyboard {
  NumLockOff --> NumLockOn : ToggleNumLock
  NumLockOn --> NumLockOff : ToggleNumLock
--
  CapsLockOff --> CapsLockOn : ToggleCapsLock
  CapsLockOn --> CapsLockOff : ToggleCapsLock
--
  ScrollLockOff --> ScrollLockOn : ToggleScrollLock
  ScrollLockOn --> ScrollLockOff : ToggleScrollLock
}
Loading

Orthogonal State Regions may also contain one initial pseudostate:

stateDiagram-v2
state Keyboard {
  [*] --> NumLockOff
  NumLockOff --> NumLockOn : ToggleNumLock
  NumLockOn --> NumLockOff : ToggleNumLock
--
  [*] --> CapsLockOff
  CapsLockOff --> CapsLockOn : ToggleCapsLock
  CapsLockOn --> CapsLockOff : ToggleCapsLock
--
  [*] --> ScrollLockOff
  ScrollLockOff --> ScrollLockOn : ToggleScrollLock
  ScrollLockOn --> ScrollLockOff : ToggleScrollLock
}
Loading

Equivalent Stateflows notation of States:

Lambda style

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddOrthogonalState("Keyboard", b => b
        .AddRegion(b => b
            .AddInitialState("NumLockOff", b => b
                .AddTransition<ToggleNumLock>("NumLockOn")
            )
            .AddState("NumLockOn", b => b
                .AddTransition<ToggleNumLock>("NumLockOff")
            )
        )
        .AddRegion(b => b
            .AddInitialState("CapsLockOff", b => b
                .AddTransition<ToggleCapsLock>("CapsLockOn")
            )
            .AddState("CapsLockOn", b => b
                .AddTransition<ToggleCapsLock>("CapsLockOff")
            )
        )
        .AddRegion(b => b
            .AddInitialState("ScrollLockOff", b => b
                .AddTransition<ToggleScrollLock>("ScrollLockOn")
            )
            .AddState("ScrollLockOn", b => b
                .AddTransition<ToggleScrollLock>("ScrollLockOff")
            )
        )
    )

Using lambda style here means that State is referred to by string name and each bit of State logic is implemented as lambda function passed as parameters to AddOn* methods in State definition.

Typed style

    public class Keyboard : IOrthogonalState { }

    public class NumLockOn : IState { }

    public class NumLockOff : IState { }

    public class CapsLockOn : IState { }

    public class CapsLockOff : IState { }

    public class ScrollLockOn : IState { }

    public class ScrollLockOff : IState { }

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddOrthogonalState<Keyboard>(b => b
        .AddRegion(b => b
            .AddInitialState<NumLockOff>(b => b
                .AddTransition<ToggleNumLock, NumLockOn>()
            )
            .AddState<NumLockOn>(b => b
                .AddTransition<ToggleNumLock, NumLockOff>()
            )
        )
        .AddRegion(b => b
            .AddInitialState<CapsLockOff>(b => b
                .AddTransition<ToggleCapsLock, CapsLockOn>()
            )
            .AddState<CapsLockOn>(b => b
                .AddTransition<ToggleCapsLock, CapsLockOff>()
            )
        )
        .AddRegion(b => b
            .AddInitialState<ScrollLockOff>(b => b
                .AddTransition<ToggleScrollLock, ScrollLockOn>()
            )
            .AddState<ScrollLockOn>(b => b
                .AddTransition<ToggleScrollLock, ScrollLockOff>()
            )
        )
    )

Using typed style here means that State is a class that is referenced in typed overloads of AddOn* methods in State Machine definition.

Class can be used as Orthogonal State if it implements at least one interface from IOrthogonalState* family:

  • IOrthogonalState - simply represents Orthogonal State,
  • IOrthogonalStateEntry - represents Orthogonal State with OnEntry logic implemented as OnEntryAsync() method,
  • IOrthogonalStateExit - represents Orthogonal State with OnExit logic implemented as OnExitAsync() method,
  • IOrthogonalStateInitialization - represents Orthogonal State with OnInitialize logic implemented as OnInitializeAsync() method,
  • IOrthogonalStateFinalization - represents Orthogonal State with OnFinalize logic implemented as OnFinalizeAsync() method,
  • IOrthogonalStateDefinition - represents Orthogonal State with additional Build() method that allows to extend its definition, for example to define Transitions and/or Regions within State class.

Creating multiple classes that are implementing different interfaces enables reusing of State's logic, but there is an important concern of State identity to be considered.

Overview
Installation
Runtimes
   Orleans runtime
Concepts
   Events and Structural Events
   Messaging Patterns
   Validation
   Scheduling
   Observability
Behaviors
   Behavior Values
   Dependency Injection
   Behavioral Groups
   State Machines
       Concepts
           State Identity
           In-State Event Deferrals
           Evaluation of Transitions
           Exception Handling
       Building blocks
           Regions
           States
               State
               Composite State
               Orthogonal State
               Final State
           Pseudostates
               Choice
               Junction
               Fork
               Join
               History
           Transitions
               Transition
               Default Transition
               Internal Transition
   Activities
       Concepts
           Exception Handling
           Implicit Fork and Join
           Tokens
       Building blocks
           Nodes
               Action Node
               Decision Node
               Merge Node
               Initial Node
               Final Node
               Input Node
               Output Node
               Fork Node
               Join Node
               Accept Event Action Node
               Send Event Action Node
               Publish Event Action Node
               Time Event Action Node
               Data Store Node
               Structured Activity Node
               Iterative Activity Node
               Parallel Activity Node
           Flows
               Data Flow
               Control Flow
   Actions
   Entities
       Fields
       Mutations
       Projections
Extensions
   ClearScript
   FluentValidation
   JSON definitions
   Minimal APIs
   OneOf
   OpenTelemetry
   PlantUML
   Scheduling

Clone this wiki locally