What can a UML sequence diagram not show, and when does adding every call make it useless?
answer
- One trace, not every trace
- Absence never means impossible
- Distance down is order, not seconds
- Transcription has no stopping point
- Fix the question, fix the altitude
basics
~20 sA sequence diagram shows one ordered trace of one scenario. It cannot assert completeness, structure, data shape, real elapsed time, or what holds when nobody is calling. Transcribing every call produces a diagram that is unreadable and wrong within a sprint.
solid answer
~50 sThe notation orders **message exchanges between participants for one scenario**. Everything outside that is a claim it cannot make: it does not say the drawn path is the only path, does not describe the participants' structure or data, does not measure elapsed time (vertical distance is ordering, not duration), and says nothing about what is true when no messages are flowing. Read completeness off a sequence diagram and you will be wrong. The failure mode is **altitude drift**. Once you start transcribing calls, there is no natural place to stop: every helper, every accessor, every logging call has as much claim to a message as the exchange the reader came for. The result mixes abstraction levels, answers no single question, and goes stale on the first refactor. The discipline is to fix the question the diagram answers, pick one altitude, and draw only messages that a reader who does not know the code would need.
go deeper
Recall the two honest limits: the diagram shows one scenario rather than all of them, and vertical distance orders events without measuring them. Do not read a drawn path as the only possible path.
Explain why absence of a message means "not shown" rather than "cannot happen", and why a happy-path-only diagram quietly misleads a reviewer about failure handling.
Demonstrate the editorial judgement: name the one question a diagram answers, hold a single altitude, cap the participants, and say out loud which diagrams you intend to throw away after the discussion.
Own the tradeoff between coverage and cost: decide which interactions are worth a maintained diagram at all, knowing that an unowned diagram that has drifted from reality is more damaging than no diagram.
## One trace, not the behaviour The most important limit is also the least obvious: a sequence diagram shows **one trace of one scenario**. It says "here is an order in which these participants can exchange these messages". It does not say that this is the only order, that these are the only participants, or that this path is the common one. Combined fragments soften that a little — an `alt` shows alternatives, a `loop` shows repetition — but they do not turn a trace into a specification. A reader still cannot answer "what else could happen here?" from the picture, because everything not drawn is simply absent, and absence in this notation means "not shown", never "impossible". ## What the notation has no symbol for | A reader's question | Can this diagram answer it? | | --- | --- | | In what order do these participants exchange messages here? | Yes — that is exactly what it asserts | | Which participant waits, and across which nested exchanges? | Yes — activation bars and filled arrowheads show it | | Is every run like this one? | No — the diagram is one trace, not a specification | | How are these participants related when nothing is happening? | No — structure is not an interaction | | How long does each step take? | No — vertical distance is ordering, never duration | | What shape is the data being passed? | No — a label is not a definition | | What happens on failure? | Only if you drew the failure path; silence is not "nothing goes wrong" | The last row is where diagrams mislead most in practice. A happy-path diagram silently implies a system in which nothing fails, and a reviewer reading it will not ask about the timeout that is not drawn. ## The failure mode of drawing every call Suppose a 7-person museum ticketing team documents its partner check-in flow ahead of an integration deadline, and does it by transcribing the code: 31 lifelines and 214 messages across 9 nested combined fragments, printed across four sheets taped together. What has gone wrong is not size but **altitude**. Once transcription is the rule, there is no principled stopping point: - Every accessor, mapper and logging call has exactly as much claim to an arrow as the exchange the reader came for. - The one interesting fact — that the partner call happens *before* the seat is held, so a partner timeout strands a reservation — is now one arrow among 214, indistinguishable from the rest. - Nine nesting levels of fragments mean the reader must track which guards are live at every point, which is harder than reading the code the diagram was meant to replace. - The diagram now encodes the call graph at one instant, so the first refactor makes it wrong, and being wrong in ways nobody can spot is worse than not existing. ## The discipline that keeps one useful 1. **Write the question first.** One sentence: "how does a partner check-in end up holding a seat?" If a message does not help answer that sentence, it does not go on the diagram. 2. **Pick one altitude and hold it.** Either participants are components, or they are objects — never both on one diagram. Mixed altitude is the single strongest signal that a diagram was transcribed rather than designed. 3. **Cap the participants.** Beyond roughly seven or eight lifelines a reader loses the thread; if you need more, the interaction has more than one question in it. 4. **Draw the interesting path, not the whole path.** The ordering hazard, the blocking call, the point of no return. Uninteresting stretches can be collapsed into one message, or referenced as a separate interaction. 5. **Decide the diagram's lifespan up front.** A sketch drawn to settle an argument in a review is finished when the argument is settled and should be thrown away; only a diagram someone has agreed to maintain deserves to be checked in. ## What to say when asked to "document the system" this way The honest answer is that this notation documents an **interaction**, and asking it to document a system is asking for the thing it does worst. Three or four small diagrams, each answering one named scenario at one altitude, carry more than one exhaustive diagram, are individually cheap to redraw when the design moves, and can be thrown away independently when a scenario stops mattering. A senior candidate is expected to say this without being prompted: the value of the notation is that it makes **order and blocking** visible, and every message that does not serve those two things is dilution.
- A colleague argues the diagram is fine because it matches the code exactly. What is your response?Matching the code exactly is the defect, not the defence. A diagram whose content is the call graph carries no editorial judgement, so it cannot show a reader which exchange matters, and it is wrong the moment anything is refactored. A diagram earns its keep by leaving things out — the value is in the selection, and a faithful transcription is strictly harder to read than the code it duplicates.
- How do you decide whether a diagram is worth checking in rather than throwing away?By whether someone has agreed to own it. A sketch drawn to settle a disagreement in a review has done its job when the disagreement is settled, and keeping it just creates a claim nobody is checking. Check in a diagram only when there is a named owner, a stated question it answers, and a reason a future reader would go looking for it — otherwise the honest move is to delete it.
- The happy path is drawn and nothing else. What does a reviewer lose?Every failure question. The notation gives no signal that a path is missing, so a reader sees a system in which the partner always answers, the seat is always free and no step times out. If failure handling is what the diagram is for, the alternative and error paths must be drawn explicitly — or the diagram should state in a note that it covers the successful path only.
saying these in an interview costs you the question
- Reads a single diagram as a complete behavioural specification
- Believes vertical distance encodes elapsed time
- Argues a diagram is good because it mirrors the code exactly
- Mixes component-level and object-level participants on one diagram
- Draws only the happy path and calls the design documented
- Cannot name a question the diagram is meant to answer