|Previous||UML Classes||Table of Contents||UML Packages||Next|
A fork node is a control node that splits a flow into multiple concurrent flows.
ControlNode (from BasicActivities ) on page 371
A fork node has one incoming edge and multiple outgoing edges.
No additional attributes
No additional associations
 A fork node has one incoming edge.
 The edges coming into and out of a fork node must be either all object flows or all control flows.
Tokens arriving at a fork are duplicated across the outgoing edges. If at least one outgoing edge accepts the token, duplicates
of the token are made and one copy traverses each edge that accepts the token. The outgoing edges that did not accept the
token due to failure of their targets to accept it, keep their copy in an implicit FIFO queue until it can be accepted by
the target. The rest of the outgoing edges do not receive a token (these are the ones with failing guards). This is an exception
to the rule that control nodes cannot hold tokens if they are blocked from moving downstream (see
Activity (from BasicActivities , CompleteActivities , FundamentalActivities , StructuredActivities) on page 328). When
an offered token is accepted on all the outgoing edges, duplicates of the token are made and one copy traverses each edge.
No duplication is necessary if there is only one outgoing edge, but it is not a useful case.
If guards are used on edges outgoing from forks, the modelers should ensure that no downstream joins depend on the arrival
of tokens passing through the guarded edge. If that cannot be avoided, then a decision node should be introduced
to have the guard, and shunt the token to the downstream join if the guard fails. See example in Figure 12.44 on page 342.
The notation for a fork node is simply a line segment, as illustrated on the left side of the figure below. In usage, however,
the fork node must have a single activity edge entering it, and two or more edges leaving it. The functionality of join node
and fork node can be combined by using the same node symbol, as illustrated at the right side of the figure below. This case
maps to a model containing a join node with all the incoming edges shown in the diagram and one outgoing edge to a fork node
that has all the outgoing edges shown in the diagram. It assumes the UML 2.0 Diagram Interchange RFP supports the interchange
of diagram elements and their mapping to model elements.
|Fork node||Fork node||Join node and fork node used|
|(without flows)||(with flows)||together, sharing the same symbol|
|Figure 12.94 - Fork node notation|
In the example below, the fork node passes control to both the Ship Order and Send Invoice behaviors when Fill Order is completed.
Figure 12.95 - Fork node example.
Fork nodes are introduced to support parallelism in activities.
Fork nodes replace the use of PseudoState with fork kind in UML 1.5 activity modeling. State machine forks in UML 1.5 required
synchronization between parallel flows through the state machine RTC step. UML 2.0 activity forks model unrestricted parallelism.