|Previous||UML Classes||Table of Contents||UML Packages||Next|
A decision node is a control node that chooses between outgoing flows.
ControlNode (from BasicActivities ) on page 371
A decision node has one incoming edge and multiple outgoing activity edges.
No additional attributes
• decisionInput : Behavior [0..1] Provides input to guard specifications on edges outgoing from the decision node.
 A decision node has one incoming edge.
 A decision input behavior has zero or one input parameter and one output parameter. Any input parameter must be the same
as or a supertype of the type of object tokens coming along the incoming edge. The behavior cannot have side effects.
 The edges coming into and out of a decision node must be either all object flows or all control flows.
Each token arriving at a decision node can traverse only one outgoing edge. Tokens are not duplicated. Each token offered
by the incoming edge is offered to the outgoing edges.
Most commonly, guards of the outgoing edges are evaluated to determine which edge should be traversed. The order in which
guards are evaluated is not defined, because edges in general are not required to determine which tokens they accept in any
particular order. The modeler should arrange that each token only be chosen to traverse one outgoing edge, otherwise there
will be race conditions among the outgoing edges. If the implementation can ensure that only one guard will succeed, it is
not required to evaluate all guards when one is found that does. For decision points, a predefined guard else may be defined
for at most one outgoing edge. This guard succeeds for a token only if the token is not accepted by all the other edges outgoing
from the decision point.
Notice that the semantics only requires that the token traverse one edge, rather than be offered to only one edge. Multiple
edges may be offered the token, but if only one of them has a target that accepts the token, then that edge is traversed.
If multiple edges accept the token and have approval from their targets for traversal at the same time, then the semantics
is not defined.
If a decision input behavior is specified, then each data token is passed to the behavior before guards are evaluated on the
outgoing edges. The behavior is invoked without input for control tokens. The output of the behavior is available to the guard.
Because the behavior is used during the process of offering tokens to outgoing edges, it may be run many times on the same
token before the token is accepted by those edges. This means the behavior cannot have side effects. It may not modify objects,
but it may for example, navigate from one object to another or get an attribute value from an object.
The notation for a decision node is a diamond-shaped symbol, as illustrated on the left side of the figure below. Decision
input behavior is specified by the keyword «decisionInput» placed in a note symbol, and attached to the appropriate decision
node symbol as illustrated in the figure below.
Issue 8238 -remove extraneous ‘a’
A decision node must have a single activity edge entering it, and one or more edges leaving it. The functionality of decision
node and merge 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 merge node with all the incoming edges shown in the diagram and one outgoing edge to a decision
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.
Decision node Decision node and merge node used Decision node
Decision node (with control flows) together, sharing the same symbol
Figure 12.76 - Decision node notation
The figure below contains a decision node that follows the Received Order behavior. The branching is based on whether order
was rejected or accepted. An order accepted condition results in passing control to Fill Order and rejected orders to Close
Figure 12.77 - Decision node example
The example in the figure below illustrates an order process example. Here, an order item is pulled from stock and prepared
for delivery. Since the item has been removed from inventory, the reorder level should also be checked; and if the actual
level falls below a pre-specified reorder point, more of the same type of item should be reordered.
Decision nodes are introduced to support conditionals in activities. Decision input behaviors are introduced to avoid redundant
recalculations in guards.
Decision nodes replace the use of PseudoState with junction kind in UML 1.5 activity modeling.