Drawing a Sequence Diagram

Drawing a Sequence Diagram

Sequence diagrams are the workhorses of behavioral modeling. Where a use case tells you what a system does, a sequence diagram shows how it does it — which objects talk to each other, in what order, and what they say. In this lesson you will draw a realistic end-to-end sequence diagram for an online store checkout flow, walking through every notation element as you build it up.

The Scenario: Online Store Checkout

A customer has items in a shopping cart and proceeds to checkout. The flow covers: the customer submitting the order, the system validating the cart and checking stock, the payment gateway processing the card, and the system confirming the order and sending a confirmation email. This is a six-participant interaction with both synchronous calls and a return path — ideal for practicing full sequence diagram notation.

Step 1 — Identify the Participants

Start by listing every actor and system component that exchanges messages during the scenario. For the checkout flow the participants are:

• Customer — the human actor who initiates the checkout.
• Browser / UI — the front-end interface (often shown as an actor or a boundary object).
• OrderController — the application component that orchestrates the flow.
• CartService — validates the cart contents and checks stock availability.
• PaymentGateway — the external payment processor.
• NotificationService — sends the order confirmation email.

Each participant becomes a lifeline: a labeled rectangle at the top and a dashed vertical line descending from it, representing that object's existence over time.

Step 2 — Draw the Lifelines and Time Axis

In a sequence diagram time flows downward. Each lifeline has a participant box (rect) at the top and a dashed vertical line below it. When a participant is actively executing — processing a call — a thin activation rectangle is drawn on the lifeline. Activations help the reader see exactly when each component is busy.

Step 3 — Add Messages

Messages are horizontal arrows between lifelines, drawn at the appropriate vertical position to reflect sequence. UML defines several arrow types:

• Synchronous call — solid line with a filled arrowhead. The sender waits for a reply before continuing. Use this for normal method or API calls.
• Return message — dashed line with an open arrowhead. Shows the value or acknowledgment sent back to the caller.
• Asynchronous message — solid line with an open (stick) arrowhead. The sender does not wait. Common for events, fire-and-forget notifications, or message queues.

Label each arrow with the message name and, where useful, its key parameters. Keep labels concise — placeOrder(cartId, paymentToken) is good; reproducing a full JSON payload is not.

The Complete Checkout Sequence Diagram

The diagram below shows the full checkout flow. Read it top-to-bottom: the Customer submits the order, the OrderController orchestrates validation, CartService checks stock, PaymentGateway processes payment, and finally NotificationService sends the confirmation email.

Reading the Diagram Step by Step

1. Message 1 — The Customer clicks "Place Order"; the Browser receives a submitCheckout() event. The Browser's activation bar starts, indicating it is now busy.
2. Messages 2–6 — The Browser sends POST /orders to OrderController, which activates and immediately delegates to CartService. Two synchronous calls happen: validateCart() and checkStock(). Each returns a dashed arrow carrying its result back before the next call starts.
3. Messages 7–9 — OrderController calls PaymentGateway.chargeCard(). Notice the self-call loop: the gateway verifies the token internally before processing. Once done, it returns a chargeResult: success dashed arrow.
4. Message 10 — OrderController fires sendConfirmation(orderId) as an asynchronous message (open arrowhead, blue). It does not wait — the email queues in the background while the controller immediately prepares its HTTP response.
5. Messages 12–13 — The controller returns 201 Created to the Browser, which renders the confirmation page for the Customer.

A Simplified View: Login Sequence

To reinforce the notation with a shorter example, here is a user login flow. Three participants — Customer, AuthController, and UserRepository — exchange five messages. This is a good template to hand stakeholders before presenting the full checkout diagram; it introduces all key notation without overwhelming the reader.

Drawing Checklist for Your Own Diagrams

Before presenting any sequence diagram to stakeholders, verify each of the following:

1. Every participant has a labeled box and a dashed lifeline.
2. Every active period has an activation rectangle on the lifeline.
3. Synchronous calls use filled arrowheads; returns use dashed lines with open arrowheads.
4. Asynchronous messages are clearly distinguishable (open stick arrowhead, or annotated «async»).
5. Message labels carry enough information to be unambiguous without being verbose.
6. The diagram has a title and the scenario it depicts is clearly scoped (happy path, error path, or both — marked with a frame).

Summary

Drawing a sequence diagram is a disciplined, step-by-step process: identify participants, draw lifelines, place messages in time order, mark activations, and distinguish call types. The checkout scenario you modeled here captures a complete, realistic business interaction — six participants exchanging thirteen messages, with both synchronous calls and an asynchronous notification. Mastering this foundation prepares you to add interaction fragments (alt, opt, loop) in the next lesson, which let you model conditional and repetitive behavior within the same diagram.