Sequence Diagram

The UML picture of one scenario over time: which objects send which messages, in what order, and what comes back. It is how you show that a class design actually works.

Overview

A sequence diagram shows one scenario as it plays out. Each participant gets a vertical lifeline; time runs down the page; each message is a horizontal arrow from the sender to the receiver. Where a class diagram shows what exists, a sequence diagram shows what happens when a user places an order or an elevator is called.

The notation is in clause 17 of UML 2.5.1. A lifeline is a head box with a vertical line under it. A synchronous call has a filled arrowhead; an asynchronous message has an open arrowhead; a reply is a dashed line. The time a participant spends busy is a thin rectangle on its lifeline, called an execution specification. Boxes called combined fragments wrap parts of the diagram to show alternatives (alt), options (opt), loops (loop) and parallel work (par).

In an LLD interview, the sequence diagram is the proof that your class diagram is more than boxes. Walking one main flow through your classes shows which object owns each step, exposes a class that is doing too much, and surfaces the failure paths you will be asked about. Draw the happy path first; add the alternatives when asked.

The parts

Lifeline — a head box and a vertical line — one participant for the whole scenario
Synchronous message — solid line, filled arrowhead — the caller waits for the answer
Asynchronous message — solid line, open arrowhead — the caller continues without waiting
Reply — dashed line back to the caller — the return value
Execution specification — thin rectangle on the lifeline — the participant is busy
Create message — dashed line with an open arrowhead to a new head box — an object is created during the scenario
Combined fragment — a labeled box around some messages — alt, opt, loop, par, break, critical and others
Note — a folded-corner box — a comment or a state

Fragments: branches, loops and parallel work

UML 2.5.1 defines twelve fragment operators. Interviews use five of them.

alt — exactly one of several guarded sections runs — success versus failure
opt — the section runs if its guard is true — an optional step
loop — the section repeats while its guard holds — retries, iterating a list
par — the sections run at the same time — fan-out to independent services
break — if the guard holds, run the section and leave the enclosing fragment — early exit on error
critical, strict, seq, neg, assert, ignore, consider — rarer; ordering and validity rules — protocol specifications

Sync, async and what it costs

An arrowhead is a design decision. A filled head means the caller blocks; a chain of five filled heads is five network hops of latency before the user hears anything. An open head means the caller moves on and the work happens later, which is faster for the user but means the result may arrive after the reply.

a long chain of synchronous calls — latency adds up; ask which can run in parallel or later
one lifeline with most of the bars — that class is doing too much (a God object)
the same two lifelines exchanging many small messages — a chatty interface; batch or move the logic
a message to a participant that is not on the class diagram — a missing class or a missing dependency

Sequence, activity and state: which to draw

who talks to whom, in order, for one scenario — sequence diagram — 'who does what, and when?'
the steps and decisions of a process, regardless of who does them — activity diagram — 'what happens next?'
the states one object can be in and what moves it — state machine diagram — 'what can this object do right now?'

What you will be able to do

Draw the main flow of a design problem with the right arrowheads and replies.
Use alt, opt, loop and par to show failures, retries and parallel work.
Read latency, chattiness and misplaced responsibility off a sequence diagram.
Choose between a sequence, activity and state diagram for a given question.

Interview questions

What are the key elements of a sequence diagram, and how do you show synchronous versus asynchronous calls?
Draw a sequence diagram for placing an order, including the failure path.
How do you show error handling and retries?
How do you show an object being created or destroyed during the scenario?
When should you draw a sequence diagram rather than an activity diagram?