UML diagrams: the visual language of software design

UML stands for Unified Modeling Language. It is a standard visual notation for communicating software structure and behavior, and it has been the working language of software design since the late 1990s. You do not need to memorize every UML diagram type. In practice and in interviews, four types cover 95% of what you will ever need.

In interviews, drawing on a whiteboard IS UML. The moment you sketch a box labeled OrderService with an arrow to PaymentGateway, you are doing UML. Interviewers expect you to draw those boxes and arrows fluently, label every relationship, and explain what you mean. The candidates who stand out are the ones who draw instinctively, not the ones who ask "should I draw a diagram?"

I reach for a class diagram first in any LLD interview. It forces me to name the entities, define relationships, and expose coupling before writing a single line of code.

Class Diagrams

Class diagrams are the foundation of LLD design. A well-drawn class diagram communicates the entire structure of a system before any code exists.

Building Blocks

A class box has three compartments: name at the top, fields in the middle, methods at the bottom. Visibility modifiers prefix every member:

• + public
• - private
• # protected
• ~ package-private

Interfaces use the <<interface>> stereotype. Abstract classes use <<abstract>> or render the class name in italics. In Mermaid's classDiagram syntax, use <<interface>> and <<abstract>> annotations.

Relationships (Most Candidates Get This Wrong)

The six relationship types are where most candidates stumble. They use inheritance for everything, or they draw arrows without knowing what type they are.

Aggregation vs Composition is the question I hear most often in interviews. The answer is one question: "Can the part exist without the whole?"

• University aggregates Department. A department can exist independently (it could be transferred to another university, or outlive a reorganization). The diamond is open.
• House composes Room. A room without a house is not a room. When the house is torn down, the rooms go with it. The diamond is filled.

In Java, neither aggregation nor composition has a keyword. The difference lives in intent and lifecycle management. If you manage the part's creation and destruction inside the enclosing class, it is composition. If the part is passed in and could outlive the owner, it is aggregation.

All Six Relationships in One Diagram

Notice: Order composes OrderItem (items cannot exist outside an order), but aggregates Discount (a discount code can exist independently and apply to many orders). Order depends on Payment as a temporary use at checkout.

Multiplicity

Multiplicity tells you how many instances participate on each end of an association:

A Customer has 0..* orders. An Order has 1..* items. An Order ships to exactly 1 address. These constraints are design decisions, not afterthoughts.

Complete Example: Library Management System

This is the kind of class diagram I would draw in a 45-minute LLD interview for "design a library system."

Library composes Book (the books belong to this library instance). Member composes LibraryCard (a card without a member is meaningless). Book is associated with Author (authors exist independently). Loan is associated with both Member and Book.

Now here is how the key classes map directly to Java:

// Maps to the Book node in the class diagram.
// availableCopies is managed by Library, not by Book itself,
// so checkout/return logic stays in Library (single responsibility).
public class Book {
  private final String isbn;
  private final String title;
  private int totalCopies;
  private int availableCopies;

  public Book(String isbn, String title, int totalCopies) {
      this.isbn = isbn;
      this.title = title;
      this.totalCopies = totalCopies;
      this.availableCopies = totalCopies;
  }

  public boolean isAvailable() {
      return availableCopies > 0;
  }

  // Package-private: only Library should manipulate copies
  void decrementAvailable() {
      if (availableCopies <= 0) throw new IllegalStateException("No copies available");
      availableCopies--;
  }

  void incrementAvailable() {
      if (availableCopies >= totalCopies) throw new IllegalStateException("All copies already returned");
      availableCopies++;
  }

  public String getIsbn() { return isbn; }
  public String getTitle() { return title; }
  public int getAvailableCopies() { return availableCopies; }
}

Sequence Diagrams

Sequence diagrams show what happens over time between components. Where class diagrams show static structure, sequence diagrams show dynamic behavior. In interviews, I draw a sequence diagram whenever the interviewer asks "walk me through how this request flows."

Building Blocks

• Participants: Named boxes at the top. Can be actors (users) or objects (services).
• Lifelines: Vertical dashed lines hanging from each participant.
• Synchronous messages: Solid arrow with filled arrowhead. Caller waits for response.
• Asynchronous messages: Solid arrow with open arrowhead. Caller does not wait (fire and forget, Kafka produce).
• Return messages: Dashed arrow. Always label these.
• Activation boxes: Thin rectangles on the lifeline showing when an object is active.
• Alt/opt/loop/par frames: Rectangles with a label in the top-left corner for conditional and repeating logic.

Alt Frame (If-Else Branching)

The alt frame is your if-else. Label both branches. Never draw a happy path without an error path in an interview.

Loop Frame

Complete Example: User Places an Order

This is the kind of end-to-end sequence I draw when asked "how does order placement work?"

The dashed --) arrow to NotificationService is async (fire and forget). The notification is sent to a queue; order placement does not wait for it. Getting this right in an interview shows you understand async boundaries.

Common Sequence Diagram Mistakes

State Diagrams

State diagrams model the lifecycle of a single object. Every domain object that can be in multiple states and transitions between them under specific conditions is a candidate for a state diagram. I draw these the moment an interviewer describes an entity with a "status" field.

Building Blocks

• States: Rounded rectangles. Each state is a stable condition the object can be in.
• Initial state: Filled circle. Every state machine has exactly one.
• Final state: Circle with a ring around it. May have multiple.
• Transitions: Arrows between states. Label format: event [guard] / action.
  • event: what triggers the transition
  • [guard]: optional condition that must be true
  • /action: what happens during the transition
• Entry/exit actions: Side effects that happen every time you enter or leave a state.

Complete Example: Order Lifecycle

Every arrow has a label. The guard conditions (e.g. all_items_in_stock, within_30_days) are embedded in the transition label to show the condition that must be true for the transition to fire. This diagram tells you immediately that cancellation after processing starts requires a different flow.

Mapping to the State Pattern in Java

This state diagram maps directly to the State pattern. Each state node becomes a class implementing a OrderState interface.

// Each box in the state diagram becomes one implementation of this interface.
// The order object delegates all state-dependent behavior to the current state.
public interface OrderState {
  void confirm(Order order);
  void startProcessing(Order order);
  void ship(Order order);
  void deliver(Order order);
  void cancel(Order order);
  void requestReturn(Order order);

  String getStateName();
}

The state diagram and the code are isomorphic. Each state node is a class. Each arrow is a method call. Each guard is a condition inside that method. When a product manager describes a new status transition, you can trace it straight to the correct state class without hunting through a chain of if-else blocks.

When to Draw State Diagrams

Draw a state diagram when the object has:

• A named "status" field that drives behavior
• Multiple transitions with guards (not just linear: A to B to C)
• Behavior that differs depending on which state the object is in

Common candidates:

• User-facing workflows: order, subscription, booking, ticket
• Protocol implementations: TCP socket (CLOSED / SYN_SENT / ESTABLISHED / FIN_WAIT / CLOSED)
• Resource lifecycle: document (DRAFT / REVIEW / PUBLISHED / ARCHIVED)

Component Diagrams

Component diagrams operate at a higher level than class diagrams. Where class diagrams show individual classes, component diagrams show modules, services, and the dependencies between them. I use these in architecture discussions, not in LLD sessions.

A component diagram answers: "Which service calls which?" It exposes coupling at the service level so you can spot circular dependencies and identify which services need to be deployed together.

Notice NotificationService has no inbound arrows from other services in the business logic layer. It only receives events from OrderService via an async channel. This is a deliberate design: notification delivery details (email vs SMS vs push) do not belong in order processing.

How to Draw UML in an Interview

The whiteboard is where UML lives in interviews. The marker-in-hand skill is separate from the knowledge skill. Practice both.

The Whiteboard Protocol

1. Ask what level of detail the interviewer wants. "Should I go full class diagram with all methods, or start with a high-level entity sketch?" Some interviewers want details, others want to see how you decompose problems. Their answer tells you which to start with.

2. Start with main entities as boxes. Write the class name in the center. Do not add fields or methods yet. Get the landscape of entities on the board first so you can see all the relationships.

3. Add relationships with arrows as you discover them. Draw the arrow, then decide what type it is. Ask yourself: is this HAS-A (composition/aggregation/association) or IS-A (generalization)?

4. Label every arrow. Never leave an arrow unlabeled. At minimum, write the relationship verb ("places", "contains", "implements"). Add multiplicity for associations.

5. Add multiplicities to all associations. Customer 1 places 0..* Order is infinitely clearer than a naked arrow.

6. Use <<interface>> for abstractions. Any time you hear "we might need different implementations" from the interviewer, that is your cue to draw an interface.

7. Talk while drawing. "I am making Payment an interface here because we will have Stripe, PayPal, and internal credit implementations. This keeps OrderService decoupled from any specific gateway."

What Interviewers Look For

• Correct IS-A vs HAS-A. Overusing inheritance is the most common mistake. If OrderProcessor does not truly specialize Processor, use composition, not inheritance.
• Interface extraction for dependencies. If OrderService depends directly on StripeClient, the interviewer notes the coupling. Extract PaymentGateway as an interface.
• Correct multiplicity. A Customer has MANY orders over time, not one. Getting multiplicity wrong suggests weak domain modeling.
• Separation of concerns. Service classes separate from model classes. No god class with 20 arrows pointing at it.
• Naming. Use domain terms, not pattern jargon. PaymentGateway is better than IPaymentStrategy. OrderRepository is better than DataAccessObject.

Common Interview UML Mistakes

UML Tools

Test Your Understanding

Quick Recap

1. Four diagram types cover 95% of interviews: class, sequence, state, component. Master these four, ignore the rest.
2. Six class diagram relationships in order of strength: dependency (weakest), association, aggregation, composition, realization, generalization. Know the difference between aggregation and composition by asking "can the part survive without the whole?"
3. Every arrow needs a label. Unlabeled arrows are unfinished thinking. In a diagram, as on a whiteboard, every relationship needs a name.
4. Multiplicity is not optional. Customer 1 to Order 0..* is design. Customer to Order with no multiplicity is a sketch.
5. Sequence diagrams need alt frames. A happy-path-only sequence diagram misses the design. Always add the failure branch.
6. State diagrams map directly to the State pattern. Each node is a class. Each arrow is a method. The diagram is the design.
7. In interviews, draw while talking. Narrate every decision. "I am making this an interface because..." is exactly what interviewers want to hear.