5.4.2.3.2. Junction

Junction

Junction is a type of Pseudostate used in State Machines to model unconditional or conditional branching. Unlike the Choice pseudostate, which evaluates conditions dynamically, Junction is typically used for static branching logic where transitions are evaluated in a predefined order.

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

As Junction is a Pseudostate and not a State, a State Machine cannot stop its flow on it. Add an outgoing else transition when the model requires a fallback if no guarded branch is enabled.

Definition

In UML, a Junction pseudostate is represented by a small black circle with multiple outgoing transitions:

flowchart LR
    initial(( )):::vertex --> source(InitialState)
    source -->|TriggerEvent| junction(( )):::vertex
    junction -->|condition1| one(State1)
    junction -->|condition2| two(State2)
    junction -->|else| three(State3)
    classDef vertex fill:#000,stroke:#000,color:#000

Loading

Mermaid has no native junction pseudostate in its state-diagram syntax. This flowchart approximation uses a filled circle for the junction and rounded boxes for states; branch labels denote UML guards ([condition1], [condition2], [else]). It is not a native UML state-diagram rendering.

Equivalent Stateflows notation of a Junction pseudostate:

Lambda style

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddInitialState("InitialState", b => b
        .AddTransition<TriggerEvent>("Junction")
    )
    .AddJunction("Junction", b => b
        .AddTransition("State1", b => b
            .AddGuard(c => true)
        )
        .AddTransition("State2", b => b
            .AddGuard(c => false)
        )
        .AddElseTransition("State3")
    )
    .AddState("State1")
    .AddState("State2")
    .AddState("State3")

If there is just one Junction 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>(Junction.Name)
    )
    .AddJunction(b => b // no name provided here, default name is used
        .AddTransition("State1", b => b
            .AddGuard(c => true)
        )
        .AddTransition("State2", b => b
            .AddGuard(c => false)
        )
        .AddElseTransition("State3")
    )
    .AddState("State1")
    .AddState("State2")
    .AddState("State3")

Using lambda style means that the Junction pseudostate and its Transitions are defined using string names and lambda functions for conditions.

Typed style

    public class JunctionCondition1 : IDefaultTransitionGuard
    {
        public Task<bool> GuardAsync()
        {
            return Task.FromResult(true);
        }
    }

    public class JunctionCondition2 : IDefaultTransitionGuard
    {
        public Task<bool> GuardAsync()
        {
            return Task.FromResult(false);
        }
    }

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddInitialState<InitialState>(b => b
        .AddTransition<TriggerEvent, Junction>()
    )
    .AddJunction(b => b
        .AddTransition<JunctionCondition1, State1>()
        .AddTransition<JunctionCondition2, State2>()
        .AddElseTransition<State3>()
    )
    .AddState<State1>()
    .AddState<State2>()
    .AddState<State3>()

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

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