Decision Node   A decision node is a control node that has one incoming flow and two or more outgoing flows. When a token arrives at a decision node it is offered to all the outgoing flows, one (and only one) of which accepts the token. Tokens cannot be detained at the node, nor are they copied; they are passed onto an outgoing flow. The guards (conditions) on the outgoing flows determine which flow will accept the token. The incoming flow and all outgoing flows must be either all control flows or all object flows.

Explanation

A decision node represents a point of choice in an activity. Tokens arriving at the node via a single incoming flow will take one (and only one) path out of the decision node via one of the outgoing flows. The decision simply offers the token to all of the outgoing flows; it is the guards (conditions) on the outgoing flows that determine whether the token will be accepted. It is the responsibility of the modeler to ensure that the guard conditions as a set ensure that at least one (and only one) outgoing path can accept the token. An outgoing flow guarded with the keyword "else" will ensure that the token has a way out of the decision in the event that all other guards stop the token from being accepted. In our daily lives we see similar situations; for example at an airport when passengers arrive they hold a ticket for a particular class of travel on an airline. Depending upon the class of travel they will enter the terminal and present themselves at a particular check-in counter: either at economy, business or first class. A passenger service counter acts as the else condition.

Important Points

All flows regardless of whether they are incoming or outgoing must be either all control flows or all object flows.

A decision node is a type of control node and therefore can only manage a single type of flow. So all incoming and outgoing flows must all be of a single type: either control flows carrying control tokens, or object flows carrying data or object tokens, but not a mixture of both types of flows.

Related Entries

Merge Node  Graphically Similar,  Used Together A merge node is related to a decision node as they are paired elements. A decision node splits an incoming flow into a number of outgoing flows (only one of which receives a token), a merge node reunites these flows into a single flow offering a single token to the outgoing flow.

Fork Node  Confused with A fork node is related to a decision node as it is often confused with the decision node. They have very different semantics. While both the decision node and the fork node have one incoming flow and a number of outgoing flows a decision node offers tokens to one (and only one) outgoing flow whereas a fork node creates concurrent flows by offering tokens to all the outgoing flows.

Choice  Graphically Similar,  Confused with A choice pseudostate is related to a decision node as they and are often confused with each other because they have the same appearance, a diamond shape with one incoming flow and two or more outgoing flows. They have very different usages, a choice pseudostate is used in state machine diagrams and the incoming and outgoing lines are transitions, whereas a decision node is used on activity and interaction overview diagrams which are based on token flow and petri nets. The incoming and outgoing lines to a decision node are flows.

N-ary Association  Graphically Similar,  Confused with An n-ary association is related to a decision node only because it has the same fundamental shape - a diamond with three or more attached lines. Semantically they are not related. The lines in the n-ary associations are associations representing structural relationships, whereas the incoming and outgoing lines (flows) in a decision node are conduits for token flows. They also appear in different UML diagrams. The n-ary association is used in the same diagrams where binary associations are found, such as class, component and deployment diagrams, whereas the decision node is used in activity and interaction overview diagrams.