| Prev | Next |
Fork/Join
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 |
|
|
Join the flow of a number of concurrent flows |
|
|
Join and Fork a number of incoming flows to a number of outgoing flows |
|
Toolbox icon
or
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.