12.3.34 JoinNode

*Generalizations

   • ControlNode (from BasicActivities ) on page 371

*Description

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

Issue 8509 -capitalize ‘boolean’ and add package header

   Package CompleteActivities

   Join nodes have a Boolean value specification using the names of the incoming edges to specify the conditions under which the join will emit a token.

*Attributes

   Package CompleteActivities

*Associations

   Package CompleteActivities

Issue 8252 - add subsets constraint

   • joinSpec : ValueSpecification [1..1] A specification giving the conditions under which the join will emit a token.Default is and. {Subsets Element::ownedElement}

*Constraints

Issue 8252 - add OCL for constraints

   [1] A join node has one outgoing edge.

   self.outgoing->size() = 1

   [2] If a join node has an incoming object flow, it must have an outgoing object flow, otherwise, it must have an outgoing control flow.

   (self.incoming.select( e | e.isTypeOf(ObjectFlow )->notEmpty() implies self.outgoing.isTypeOf(ObjectFlow )) and(self.incoming.select( e | e.isTypeOf(ObjectFlow )->empty() implies self.outgoing.isTypeOf(ControlFlow ))

*Semantics

   If there is a token offered on all incoming edges, then tokens are offered on the outgoing edge according to the following join rules:

1. If all the tokens offered on the incoming edges are control tokens, then one control token is offered on the outgoing edge.

2. If some of the tokens offered on the incoming edges are control tokens and others are data tokens, then only the data tokens are offered on the outgoing edge. Tokens are offered on the outgoing edge in the same order they were offered to the join.

   Multiple control tokens offered on the same incoming edge are combined into one before applying the above rules. No joining of tokens is necessary if there is only one incoming edge, but it is not a useful case.

   Package CompleteActivities

   The reserved string and used as a join specification is equivalent to a specification that requires at least one token offered on each incoming edge. It is the default. The join specification is evaluated whenever a new token is offered on any incoming edge. The evaluation is not interrupted by any new tokens offered during the evaluation, nor are concurrent evaluations started when new tokens are offered during an evaluation.

   If any tokens are offered to the outgoing edge, they must be accepted or rejected for traversal before any more tokens are offered to the outgoing edge. If tokens are rejected for traversal, they are no longer offered to the outgoing edge. The join specification may contain the names of the incoming edges to refer to whether a token was offered on that edge at the time the evaluation started.

   If isCombinedDuplicate is true, then before object tokens are offered to the outgoing edge, those containing objects with the same identity are combined into one token.

   Other rules for when tokens may be passed along the outgoing edge depend on the characteristics of the edge and its target. For example, if the outgoing edge targets an object node that has reached its upper bound, no token can be passed. The rules may be optimized to a different algorithm as long as the effect is the same. In the full object node example, the implementation can omit the unnecessary join evaluations until the down stream object node can accept tokens.

*Notation

   The notation for a join node is a line segment, as illustrated on the left side of the figure below. The join node must have one or more activity edges entering it, and only one edge 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 specification supports the interchange of diagram elements and their mapping to model elements.

   Join specifications are shown near the join node, as shown below.

    {joinSpec = ...}

   Join node (with flowsand a join specification)

   Figure 12.102 - Join node notations

*Examples

Issue 8252 -replace ‘Accept Order’ with ‘Send Invoice’

   The example at the left of the figure indicates that a Join is used to synchronize the processing of the Ship Order and Send Invoice behaviors. Here, when both have been completed, control is passed to Close Order.

   Package CompleteActivities

   The example below illustrates how a join specification can be used to ensure that both a drink is selected and the correct amount of money has been inserted before the drink is dispensed. Names of the incoming edges are used in the join specification to refer to whether tokens are available on the edges.

   {joinSpec =

   A and B

   and the total coin value

   inserted is >= drink price}

*Changes from previous UML

   Join nodes replace the use of PseudoState with join kind in UML 1.5 activity modeling.