5.4.2.3.3. Fork

Fork

Fork is a type of Pseudostate used in State Machines to model concurrent transitions. It allows the State Machine to split its flow into multiple parallel paths, each leading to a different target state.

Each Transition outgoing from a Fork must be targeted in a State or Pseudostate defined in different orthogonal Region of Orthogonal State.

All Transitions coming out from a Fork are Default Transitions - they are not explicitly triggered by an Event.

As Fork is a Pseudostate and not a State, the State Machine cannot stop its flow on it. Therefore, no Guards are allowed in Transitions outgoing from a Fork.

Definition

In UML, a Fork pseudostate is represented by a horizontal or vertical bar with multiple outgoing transitions:

stateDiagram-v2
state Fork <<fork>>
[*] --> InitialState
InitialState --> Fork : TriggerEvent
state ParallelStates {
    State1
    --
    State2
    --
    State3
}
Fork --> State1
Fork --> State2
Fork --> State3

Loading

Equivalent Stateflows notation of a Fork pseudostate:

Lambda style

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddInitialState("InitialState", b => b
        .AddTransition<TriggerEvent>("Fork")
    )
    .AddFork("Fork", b => b
        .AddTransition("State1")
        .AddTransition("State2")
        .AddTransition("State3")
    )
    .AddOrthogonalState("ParallelStates", parallel => parallel
        .AddRegion(region => region.AddInitialState("State1"))
        .AddRegion(region => region.AddInitialState("State2"))
        .AddRegion(region => region.AddInitialState("State3")))

If there is just one Fork in the State Machine, a shortened notation with the default name can be used:

Unnamed pseudostate shorthand

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddInitialState("InitialState", b => b
        .AddTransition<TriggerEvent>(Fork.Name)
    )
    .AddFork(b => b // no name provided here, default name is used
        .AddTransition("State1")
        .AddTransition("State2")
        .AddTransition("State3")
    )
    .AddOrthogonalState("ParallelStates", parallel => parallel
        .AddRegion(region => region.AddInitialState("State1"))
        .AddRegion(region => region.AddInitialState("State2"))
        .AddRegion(region => region.AddInitialState("State3")))

Using lambda style means that the Fork pseudostate and its Transitions are defined using string names.

Typed style

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddInitialState<InitialState>(b => b
        .AddTransition<TriggerEvent, Fork>()
    )
    .AddFork(b => b
        .AddTransition<State1>()
        .AddTransition<State2>()
        .AddTransition<State3>()
    )
    .AddOrthogonalState("ParallelStates", parallel => parallel
        .AddRegion(region => region.AddInitialState<State1>())
        .AddRegion(region => region.AddInitialState<State2>())
        .AddRegion(region => region.AddInitialState<State3>()))

Using typed style here means that the Fork pseudostate is represented by a class, in the example predefined Fork class is used.

Fork class can be used as a target for typed style Transitions if the State Machine contains just one Fork. If there are more Forks, there is an important concern of State identity to be considered.