Chapter 4: LLD Deliverables: Class Diagrams and Sequence Diagrams

Why this matters

Class diagrams and sequence diagrams are two of LLD's most common artifacts, and they answer genuinely different questions — a class diagram shows static structure (what exists and how it relates), a sequence diagram shows dynamic behavior (what happens, in what order, when a specific operation runs). Producing only one when a design genuinely needs both is a common, easily-avoided gap.

Class diagrams: static structure

[BEGINNER] Directly building on the companion OOP book's Chapter 11 UML coverage: a class diagram shows classes, their key fields and methods, and the relationships between them (composition, aggregation, association, inheritance). At the LLD level specifically, this diagram should be detailed enough that an engineer could start implementing directly from it.

+---------------------------+
|          Booking          |
+---------------------------+
| - id: string              |
| - guestId: string         |
| - roomId: string          |
| - checkIn: Date           |
| - checkOut: Date          |
| - status: BookingStatus   |
+---------------------------+
| + confirm(): void         |
| + cancel(): void          |
| + calculateTotal(): number|
+---------------------------+
         | ◆ (composition: a booking owns its own line items)
         v
+---------------------------+
|       BookingLineItem      |
+---------------------------+
| - description: string      |
| - amountCents: number      |
+---------------------------+

Sequence diagrams: dynamic behavior over time

[BEGINNER] A sequence diagram shows the specific sequence of method calls/messages between objects for one particular operation or scenario — where a class diagram is a system's "anatomy," a sequence diagram is a specific "story" of one interaction playing out over time, read top to bottom as a timeline.

Client          BookingService       AvailabilityChecker      Database
  |                    |                       |                  |
  |--createBooking()-->|                       |                  |
  |                    |--checkAvailable()---->|                  |
  |                    |                       |--query()-------->|
  |                    |                       |<--rooms----------|
  |                    |<--available: true-----|                  |
  |                    |--save(booking)------------------------->|
  |                    |<--bookingId---------------------------- |
  |<--bookingId--------|                       |                  |

[SENIOR INSIGHT] Sequence diagrams earn their specific value precisely for scenarios involving multiple objects/services collaborating, especially when the order of operations matters for correctness (e.g., availability must be checked before saving, not after, or a double-booking becomes possible — directly the companion Database book's Chapter 3 check-then-act race condition, made visible in diagram form). A sequence diagram for a single class's single method, with no collaboration involved, usually isn't worth producing — it's solving a documentation problem (showing collaboration order) that doesn't exist for a self-contained operation.

Choosing which operations deserve a sequence diagram

[IN PRACTICE] Not every operation needs one — reserve sequence diagrams for the operations that are genuinely complex to trace mentally, involve multiple components, or have a correctness-critical ordering requirement worth making explicit and reviewable. A simple CRUD "get a booking by ID" operation rarely needs one; "create a booking" (involving availability checking, payment authorization, and notification triggering, potentially across multiple services) usually does.

Common mistakes

1. Producing only a class diagram for a design that genuinely involves complex, multi-component interaction, missing the chance to make ordering-dependent correctness requirements explicit and reviewable via a sequence diagram.
2. Producing a sequence diagram for a trivial, single-component operation that doesn't need one, adding documentation overhead disproportionate to the operation's actual complexity.
3. Not making a correctness-critical ordering requirement (like checking availability before saving) explicit in the sequence diagram, leaving it as an implicit assumption that an implementer might get wrong.
4. Treating a class diagram as showing behavior, or a sequence diagram as showing structure — conflating the two diagram types' genuinely distinct purposes (static structure vs. dynamic behavior over time).

Checklist: producing effective LLD diagrams

1. Produce a class diagram detailed enough to implement directly from — key fields, methods, and relationships (using the composition/aggregation/association distinctions from the companion OOP book's Chapter 11).
2. Produce a sequence diagram for any operation involving multiple components with a correctness-critical ordering requirement, making that ordering explicit and reviewable.
3. Skip a sequence diagram for simple, single-component operations where the documentation overhead wouldn't be justified by the operation's actual complexity.
4. Use each diagram type for its genuinely distinct purpose — class diagrams for static structure, sequence diagrams for dynamic behavior over time.

Discussion / interview questions

1. "What's the difference between a class diagram and a sequence diagram, and when would you use each?" Strong answer: A class diagram shows static structure (classes, fields, methods, relationships); a sequence diagram shows a specific operation's dynamic behavior over time (the order of calls/messages between objects) — use a sequence diagram specifically when an operation's correctness depends on a specific, non-obvious ordering across multiple components.

2. "Why might you produce a sequence diagram for a 'create booking' operation but not for a 'get booking by ID' operation?" Strong answer: Create-booking involves multiple components with a correctness-critical ordering requirement (checking availability before saving, to avoid a race condition) worth making explicit and reviewable; get-by-ID is a simple, single-component lookup with no meaningful ordering complexity to document.

3. "How does a sequence diagram help catch a race condition before implementation begins?" Strong answer: By making the exact order of operations across components explicit and visible for review, a sequence diagram can reveal that, e.g., a save happens before an availability check completes — a reviewer can catch this ordering flaw on paper, far more cheaply than discovering the resulting race condition in production.

4. "Should every method in a system have its own sequence diagram?" Strong answer: No — reserve sequence diagrams for genuinely complex, multi-component operations with a correctness-critical ordering requirement; producing one for every trivial, single-component operation adds documentation overhead disproportionate to the actual complexity being documented.

Chapter summary / cheat sheet

• Class diagrams: static structure — classes, fields, methods, relationships (composition/aggregation/association, per the companion OOP book's Chapter 11) — detailed enough to implement directly from.
• Sequence diagrams: dynamic behavior over time for a specific operation — the order of calls/messages between collaborating objects/services.
• Reserve sequence diagrams for genuinely complex, multi-component operations with a correctness-critical ordering requirement (like checking availability before saving) — skip them for simple, single-component operations.
• The two diagram types answer genuinely different questions (structure vs. behavior) — a complete LLD often needs both, for different specific purposes.

---