12.3.30 ForkNode

*Generalizations

   • ControlNode (from BasicActivities ) on page 371

*Description

   A fork node has one incoming edge and multiple outgoing edges.

*Attributes

   No additional attributes

*Associations

   No additional associations

*Constraints

   [1] A fork node has one incoming edge.

   [2] The edges coming into and out of a fork node must be either all object flows or all control flows.

*Semantics

   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.

*Notation

   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.

*Examples

   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.

*Changes from previous UML

   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.