Book a Demo

Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.

Prev Next

Join

Description

A Fork/Join used in UML Activity diagrams as modeled using Sparx Systems Enterprise Architect. A Fork/Join used in UML Activity diagrams as modeled using Sparx Systems Enterprise Architect.

The Join element is used by Activity and StateMachine diagrams. The example illustrates a Join transition between Activities. With respect to StateMachine diagrams, a Join pseudosate indicates multiple States concurrently transitioning into the Join and onto a single State. Unlike Choice or Junction pseudostates, Joins must not have triggers or guards. This diagram demonstrates a Fork pseudostate dividing into two concurrent Regions, which then return to the End State via the Join.

Using a Fork/Join in a StateMachine diagram modeled in Sparx Systems Enterprise Architect.

Learn more

OMG UML Specification:

Joins in Activity Diagrams

The OMG Unified Modeling Language specification, (v2.5.1, p.389) states:

A JoinNode is a ControlNode that synchronizes multiple flows. A JoinNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges. If any of the incoming edges of a JoinNode are ObjectFlows, the outgoing edge shall be an ObjectFlow. Otherwise the outgoing edge shall be a ControlFlow.

Joins in State Machine Diagrams

The OMG Unified Modeling Language specification, (v2.5.1, p.313) states:

(A Join) Pseudostate serves as a common target Vertex for two or more Transitions originating from Vertices in different orthogonal Regions. Transitions terminating on a join Pseudostate cannot have a guard or a trigger. Similar to junction points in Petri nets, join Pseudostates perform a synchronization function, whereby all incoming Transitions have to complete before execution can continue through an outgoing Transition.