5.4.2.3.4. Join

Join

Join is a type of Pseudostate used in State Machines to model the synchronization of multiple parallel transitions. It allows the State Machine to wait for all incoming transitions to complete before continuing to a single outgoing transition.

Each Transition incoming to a Join must originate from a State or Pseudostate defined in different orthogonal Regions of an Orthogonal State.

All Transitions incoming to a Join are Default Transitions - they are not explicitly triggered by an Event. Also, no Guards are allowed in Transitions incoming to a Join.

As Join is a Pseudostate and not a State, the State Machine cannot stop its flow on it. Therefore, Join must have exactly one outgoing Transition which must follow the same restrictions as incoming Transitions: no Trigger nor Guard is allowed there.

Definition

In UML, a Join pseudostate is represented by a horizontal or vertical bar with multiple incoming transitions and a single outgoing transition:

stateDiagram-v2
state Join <<join>>
[*] --> ParallelStates
state ParallelStates {
    [*] --> State1
    --
    [*] --> State2
    --
    [*] --> State3
}
State1 --> Join
State2 --> Join
State3 --> Join
Join --> Completed

Loading

Equivalent Stateflows notation of a Join pseudostate:

Lambda style

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddInitialOrthogonalState("ParallelStates", parallel => parallel
        .AddRegion(region => region
            .AddInitialState("State1", state => state.AddDefaultTransition("Join")))
        .AddRegion(region => region
            .AddInitialState("State2", state => state.AddDefaultTransition("Join")))
        .AddRegion(region => region
            .AddInitialState("State3", state => state.AddDefaultTransition("Join"))))
    .AddJoin("Join", b => b
        .AddTransition("FinalState")
    )
    .AddState("FinalState")

If there is just one Join 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 */
    .AddInitialOrthogonalState("ParallelStates", parallel => parallel
        .AddRegion(region => region
            .AddInitialState("State1", state => state.AddDefaultTransition(Join.Name)))
        .AddRegion(region => region
            .AddInitialState("State2", state => state.AddDefaultTransition(Join.Name)))
        .AddRegion(region => region
            .AddInitialState("State3", state => state.AddDefaultTransition(Join.Name))))
    .AddJoin(b => b // no name provided here, default name is used
        .AddTransition("FinalState")
    )
    .AddState("FinalState")

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

Typed style

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddInitialOrthogonalState("ParallelStates", parallel => parallel
        .AddRegion(region => region
            .AddInitialState<State1>(state => state.AddDefaultTransition<Join>()))
        .AddRegion(region => region
            .AddInitialState<State2>(state => state.AddDefaultTransition<Join>()))
        .AddRegion(region => region
            .AddInitialState<State3>(state => state.AddDefaultTransition<Join>())))
    .AddJoin(b => b
        .AddTransition("Completed")
    )
    .AddState("Completed")

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

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