Section 3.3. Decisions and Merges
3.3. Decisions and MergesDecisions are used when you want to execute a different sequence of actions depending on a condition. Decisions are drawn as diamond-shaped nodes with one incoming edge and multiple outgoing edges, as shown in Figure 3-5. Figure 3-5. Only one edge is followed after a decision node Each branched edge contains a guard condition written in brackets. Guard conditions determine which edge is taken after a decision node. They are statements that evaluate to true or false, for example:
The branched flows join together at a merge node, which marks the end of the conditional behavior started at the decision node. Merges are also shown with diamond-shaped nodes, but they have multiple incoming edges and one outgoing edge, as shown in Figure 3-6. Figure 3-6. If the input value of age is 1200, then the Notify Blog Entry too long action is performed Activity diagrams are clearest if the guards at decision nodes are complete and mutually exclusive. Figure 3-7 shows a situation in which the paths are not mutually exclusive. If an item is in stock and the order is a rush order, then two guards evaluate to true. So which edge is followed? According to the UML specifications, if multiple guards evaluate to true, then only one edge is followed and that choice is out of your control unless you specify an order. You can avoid this complicated situation by making guards mutually exclusive. The other situation to avoid is incomplete guards. For example, if Figure 3-7 had no guard covering out of stock items, then an out of stock item can't follow any edge out of the decision node. This means the activity is frozen at the decision node. Modelers sometimes leave off guards if they expect a situation not to occur (or if they want to defer thinking about it until later), but to minimize confusion, you should always include a guard to cover every possible situation. If it's possible in your activity, it's helpful to label one path with else, as shown in Figure 3-7, to make sure all situations are covered. Figure 3-7. Beware of diagrams where multiple guards evaluate to true If you're coming from a UML 1.x background, it may not seem necessary to show merge nodes. In UML 1.x, it was common to see multiple edges starting at a decision node flow directly into an action, as shown in the top part of Figure 3-8. This meant the flows were merged implicitly. As of UML 2.0, when multiple edges lead directly into an action, all incoming flows are waited on before proceeding. But this doesn't make sense because only one edge is followed out of a decision node. You can avoid confusing your reader by explicitly showing merge nodes. |
EAN: 2147483647
Pages: 175