Prev Next

Fork/Join

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 Fork/Join elements can be used to:

  • Fork or split the flow into a number of concurrent flows
  • Join the flow of a number of concurrent flows
  • Both join and split a number of incoming flows to a number of outgoing flows

These elements are used in both Activity and StateMachine diagrams, in either vertical or horizontal orientation. With respect to StateMachine diagrams, Forks and Joins are used as pseudostates. Other pseudostates include History states, Entry Points and Exit Points. Forks are used to split an incoming transition into concurrent multiple transitions leading to different target states. Joins are used to merge concurrent multiple transitions into a single transition leading to a single target. They are semantic inverses. To learn more about these individual elements see their specific topics.

Example Diagrams

Description

Diagram

Fork or split the flow into a number of concurrent flows

Use of an Activity Fork/Join as a Fork in Sparx Systems Enterprise Architect's UML Activity model.

Join the flow of a number of concurrent flows

Use of an Activity Fork/Join as a Join in Sparx Systems Enterprise Architect's  UML Activity model.

Join and Fork a number of incoming flows to a number of outgoing flows

Using a Join and Fork on a number of incoming flows to a number of outgoing flows modeled in Sparx Systems Enterprise Architect.

Toolbox icon

Horizontal Fork/Join element

or

Vertical Fork/Join element

Learn more

OMG UML Specification:

Forks in Activity Diagrams

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

Fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices (i.e. vertices in different regions of a composite state). The segments outgoing from a fork vertex must not have guards or triggers.

Forks in State Machine Diagrams

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

(A) fork Pseudostates serve to split an incoming Transition into two or more Transitions terminating on Vertices in orthogonal Regions of a composite State. The Transitions outgoing from a fork Pseudostate cannot have a guard or a trigger.

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.