UML Sequence Diagrams: Who Calls Whom, in What Order

A UML sequence diagram shows the calls made during one run of a program, in the order they happen, from top to bottom. A class diagram says which classes can talk to which; a sequence diagram shows one particular conversation. Several patterns are easier to understand from their sequence than from their structure, and this card covers the three marks needed to follow one.

Each object gets a lifeline: its name at the top and a vertical line below it, which stands for time. A solid arrow from one lifeline to another is a message, a method call. A dashed arrow back is a return, the value the call hands back. Time runs down the page, so a lower arrow happens later.

The diagram shows the Observer pattern, in which one object tells several others when it changes. A thermostat has a display and a logger watching it.

Read it from the top. The client sets the temperature. The thermostat sends notify() to itself, drawn as an arrow that leaves and returns to its own lifeline. It then calls update() on the display, which asks for the temperature and receives 21 on a dashed return. The same happens for the logger, after the display has finished.

That order is something the class diagram cannot show. It tells you the display is updated before the logger, that each observer asks for the new value rather than being handed it, and that nothing happens until set_temperature is called. When a later card says an observer "pulls" its data, this is the picture it means.

Sequence diagrams have more marks, for loops, conditions and objects being created, but the pattern cards in this subject need only lifelines, messages and returns.