In a UML activity diagram, why must a decision node's outgoing guards cover every case?

## Where a guard lives A **guard** is a condition written in square brackets on a **control flow edge** — not inside the node the edge leaves. In an activity diagram the guards that matter sit on the outgoing edges of a **decision node**, the diamond that picks one path. A token arrives at the diamond, the guards on the outgoing edges are evaluated, and the token departs along the single edge whose guard holds. The node carries no logic at all; every bit of the logic is on the edges. That is why writing the condition inside the diamond is a reading error: the diamond marks *where* the choice happens, and the edges say *what* the choice is. Two properties make a guard set correct: - **Complete** — for every state of the world reachable at that point, at least one outgoing guard is true. - **Mutually exclusive** — for every such state, at most one outgoing guard is true. Miss the first and the flow can dead-end. Miss the second and the diagram stops having a single meaning. ## What each failure does to the model | Guard-set defect | What the model now says | What a reader does with it | |---|---|---| | A case matches no guard | The token stops at the diamond and that path makes no further progress | Invents a default, or finds the gap in production | | A case matches two guards | Either path is permitted and neither is preferred | Two implementers build two behaviours, both defensible | | Condition written inside the node | Nothing at all; the outgoing edges are unlabelled | Cannot tell which edge is the affirmative one | | No catch-all edge | Every case nobody enumerated is undefined | Adds one silently, in code, undocumented | An **incomplete** guard set is a silent dead end. Nothing on the page looks wrong and the notation reports no error; the diagram is simply mute about one case. It surfaces in review as the question 'and what happens when the balance is exactly zero?', and if nobody in the room can answer, the picture has failed at the one job it had. An **overlapping** guard set fails more quietly still, because both paths look deliberate. A diagram whose token could legally go two ways is not one specification — it is two, and which one gets built is decided by whoever reads it first. ## The catch-all edge The notation predefines an **else** guard for exactly this problem: an edge marked else is taken when no other outgoing guard on that decision node is true. It buys completeness cheaply — enumerate the cases you genuinely care about, then route everything else down one labelled edge. Two things else is not: 1. **It is not 'do nothing'.** The else edge has to lead somewhere real — a rejection action, a compensating step, an exception path, a final node. An else edge that trails off the page restores exactly the dead end you drew it to remove. 2. **It is not a substitute for thinking.** If most of the real traffic ends up on the else path, the guard set is naming the exceptions and hiding the rule, and the diagram is describing a process nobody actually follows. ## Boundaries are where guard sets rot Almost every guard-set defect found in review sits on a numeric or empty-value boundary, and the two failure modes are mirror images: - `[amount < 250]` beside `[amount > 250]` leaves exactly 250 unrouted — an incomplete set that exactly one input value exposes. - `[amount <= 250]` beside `[amount >= 250]` routes 250 down both — an overlapping set that the same single input exposes. - Guards over a collection routinely forget the empty case: `[all items approved]` beside `[some item rejected]` says nothing about a collection with no items. - Guards over an optional value forget the absent case, which is neither the true nor the false side of a condition about its content. The habit that fixes all four is to write guards that *partition* the input rather than describe it, then read them back as a sentence — 'zero, above zero up to the limit, above the limit, anything else' — and check the seams between the phrases. ## Reviewing a guard set in ninety seconds 1. Read the outgoing edges of every diamond aloud, as a list of cases. 2. Name one input for each edge, then name one input you believe reaches none of them. 3. Name one input you believe reaches two of them; if you can, the set overlaps. 4. Confirm the catch-all edge exists and lands on a real action rather than on white space. 5. Check that each guarded edge eventually reaches a rejoin or a final node, so no case has a shorter life than the others. A guard set that survives that pass is worth more than the rest of the diagram, because it is the part a reader can get *wrong* while believing they read it right.