A team documents each feature with UML interaction diagrams alone. Which modelling questions does that leave unanswered?

## What an interaction diagram is actually scoped to An interaction diagram makes a narrow, honest claim: **for one chosen scenario, these participants exchange these messages in this order.** Every word in that claim is a limit. It is one scenario out of many; it is one path through that scenario unless alternatives are drawn explicitly; the participants are the ones the author chose to include; and it is instance-level, so it says what happened once, not what must always hold. That narrowness is a virtue when the question is *in what order does this go*. It becomes a defect when such diagrams are the entire design record, because the missing claims are all of one kind: those that quantify over every scenario rather than one. ## The four questions the pack cannot answer 1. **The type-level rules.** Which participants may exist at all, which relationships between them are permitted, and with what multiplicities. A scenario shows one learner with one active subscription; nothing in it says whether two are possible. That claim belongs on a class diagram. 2. **Lifecycle legality.** Which lifecycle states one object may occupy and which transitions between them are legal — and, crucially, which are **illegal**. A scenario diagram can only ever show a transition that did happen. It has no way to assert that a cancelled subscription must never move directly back to active, and that assertion is the one defects are made of. It belongs on a state machine diagram. 3. **Goal coverage.** Which outside parties want what from the system at all. A pack of scenarios cannot tell you what is missing from it, because the pack contains no statement of the whole. A use-case diagram makes the set of goals visible so gaps are visible too. 4. **Placement and topology.** What is co-located and what crosses a boundary. Two participants side by side on a lifeline chart may sit in the same process or on separate machines, and the diagram is identical either way — which means every question about failure across that boundary is unanswerable from the pack. That belongs on a deployment diagram. A fifth gap hides in plain sight: a long-running process with real concurrency and several alternative paths is enumerable as scenarios, but the enumeration explodes and the shape stops being visible. One activity diagram carries what a dozen paths carry. | The claim the record needs | Can a scenario diagram make it? | Where it belongs | | --- | --- | --- | | In this case, A messages B then C | Yes — this is its job | Interaction diagram | | At most one active subscription per learner | No — one instance is not a rule | Class diagram | | Cancelled must never return directly to active | No — it can only draw what happened | State machine diagram | | These are all the goals the system serves | No — a set cannot show its own gaps | Use-case diagram | | These two participants sit on separate machines | No — the drawing is identical either way | Deployment diagram | ## The tell, and what it looks like in practice The observable symptom is repetition. On a language-learning app, look for twenty-three scenario diagrams that between them re-draw the same six lifecycle states of a learner's subscription, each from a slightly different start, with no single place stating which of those states may follow which. A third of a 47-item backlog then turns out to be defects living in that gap: a state combination nobody drew because no scenario visited it. The pressure that exposes it fastest is a legacy system being decommissioned in parallel, because during the parallel run two systems write the same lifecycle and must agree on which transitions are legal. Scenario diagrams cannot settle that argument — each side produces a diagram in which its own path is drawn, and both diagrams are correct about the scenario they show. Only a single lifecycle model, stated once and agreed by both sides, adjudicates it. That is a structural-versus-behavioural routing failure at heart: the team kept answering *what happened in this case* when the question in the room was *what is always true*. ## The fix, and what to keep The repair is not more scenarios. It is to promote the invariant out of them: - **Extract one lifecycle model** for each object whose states the scenarios keep restating, and let it be the authority on legal transitions. Keep two or three scenario diagrams — the representative path and the awkward ones — and delete the rest. - **Add one type-level structural diagram** covering the participants and their multiplicities, so a scenario no longer has to be read as though it were a rule. - **Add one goal-level behavioural diagram** if it is unclear what the system is for, so missing scenarios show up as visible gaps rather than absences nobody notices. - **Add topology only if a boundary matters** to the questions being asked; if everything is co-located and always has been, that diagram earns nothing. The principle is worth stating plainly, because it is what an interviewer listens for: **one scenario can never establish an invariant, and one structural diagram can never establish an ordering.** A record built from one half of UML has a predictable blind spot, and the senior move is to name it before someone finds it as a defect.