Decision and merge node

How to read it

UML 2.5.1 uses the same diamond for both, and the arrows tell them apart. At a decision, each outgoing arrow can carry a guard, a condition in square brackets such as [paid], and the flow takes only one of the outgoing arrows. The guard [else] is taken only when no other arrow is. A merge brings alternative flows together without waiting for them: whatever arrives on any incoming arrow passes straight on. One diamond can do both jobs at once, with several arrows in and several out. The University of Pretoria's course notes compare decisions to if and while statements in a program, and point out that only one of the alternative flows runs at a time. In a state machine diagram, a diamond is a choice pseudostate, where the guards are checked when the transition reaches it.

Also searched as: decision and merge node symbol, decision node uml, uml decision and merge node.

Merge or join?

A merge doesn't wait. The specification's example has Buy Item and Make Item both leading into a merge before Ship Item: if only one of them happens, Ship Item happens once, and if both do, it happens twice. A join bar waits for all its incoming flows before going on. Scott Ambler, in The Object Primer, points to a join in one of his own diagrams that should have been a merge: the flow could enter the join but not get out of it, because only one of its incoming paths would ever run.

Look-alikes

The decision diamond in activity diagrams has a counterpart on flowcharts, the decision symbol; Ambler calls activity diagrams the object-oriented equivalent of flowcharts. In a Chen entity-relationship diagram a diamond is a relationship. In a UML class diagram, a small diamond at the end of a line is Aggregation or Composition, and a large diamond with lines to three or more classes is an association between them.