Class Diagrams and UML for Low Level Design

You’re in an LLD interview. You’ve identified the classes, thought through the relationships, and designed a clean architecture. Now the interviewer says: “Can you draw that out?”

If you can’t translate your thinking into a clear visual diagram, half your design work is invisible. UML (Unified Modeling Language) is the standard way engineers communicate software designs — and in LLD interviews, it’s the language of the whiteboard.

The good news? You don’t need to learn all 14 UML diagram types. For Low Level Design, you need exactly three — and you can learn the essentials of each in minutes.

Why UML Matters (Even If Your Team Doesn’t Use It)

The Complete Notation Reference

Before diving into examples, here’s the notation you need. Save this as your cheat sheet:

That’s it. These symbols cover 95% of what you’ll ever need in LLD interviews and design documents. Let’s see them in action.

Part 1: Class Diagrams

Class diagrams are the backbone of LLD. They show the static structure of your system — what classes exist, what they contain, and how they relate.

Anatomy of a Class Box

Every class in UML is drawn as a rectangle divided into three sections:

• Top section: Class name (bold or centered)
• Middle section: Attributes (fields/properties) with visibility
• Bottom section: Methods (operations) with visibility

The visibility prefix tells you who can access what:

• +getName() — anyone can call this
• -hashPassword() — only the class itself can call this
• #createdAt — the class and its children can access this

Your First Complete Class Diagram

Let’s build a class diagram for a simple coffee machine step by step:

Here’s the complete diagram:

Reading the diagram: The solid diamond (*--) from CoffeeMachine to Inventory means composition — the Inventory lives and dies with the CoffeeMachine. The simple arrow (-->) from Order to Beverage means association — an Order references a Beverage, but they have independent lifecycles.

Relationships in Action

Let’s see each relationship type in a real LLD context:

What this tells you at a glance:

• Composition (solid diamond): ParkingLot owns Floors, Floors own Spots — destroy the lot, everything inside is destroyed
• Inheritance (hollow triangle): Car, Truck, Motorcycle are all types of Vehicle — they share the base interface
• Association (arrow): A Ticket references a Vehicle and a Spot, but doesn’t own them
• Interface implementation (dashed + triangle): HourlyPricing and FlatRatePricing both fulfill the PricingStrategy contract

This is exactly the kind of diagram you’d draw in a parking lot interview.

Multiplicity: How Many?

Sometimes you need to show how many objects are in a relationship:

Part 2: Sequence Diagrams

While class diagrams show structure (what exists), sequence diagrams show behavior (what happens). They trace a single flow through your system, showing which objects interact and in what order.

Anatomy of a Sequence Diagram

How to read it:

• Solid arrow (->>) = a request or call
• Dashed arrow (-->>) = a response or return
• Time flows downward — interactions at the top happen first
• Each vertical line (lifeline) represents one object

This diagram shows the complete ATM withdrawal flow. In an ATM system interview, drawing this sequence diagram demonstrates you understand the interactions, not just the classes.

When to Use Sequence Diagrams

Use them for the critical flows in your system — the ones the interviewer will ask about:

Part 3: State Diagrams

State diagrams show how an object transitions between states in response to events. They’re essential for any problem with a lifecycle: orders, bookings, elevators, vending machines.

A Vending Machine State Diagram

How to read it:

• Circles represent states the object can be in
• Arrows represent transitions triggered by events
• [*] is the initial state
• An object is always in exactly one state

This is exactly the state machine you’d design for a vending machine. Each state maps to a class in the State pattern.

Order Lifecycle State Diagram

This order lifecycle applies to any restaurant ordering system. Each state becomes an enum value, and the transitions become the validation logic in your service layer.

Complete Worked Example: Library Management System

Let’s bring it all together. We’ll design a Library Management System using all three diagram types — exactly as you would in an interview.

1. The Class Diagram

2. The Sequence Diagram (Borrow Flow)

3. The State Diagram (Book Lifecycle)

Three diagrams, one complete design. The class diagram shows what exists, the sequence diagram shows how borrowing works, and the state diagram shows when a book changes status. Together, they give the interviewer complete confidence that you understand the system.

Tools for Drawing UML

You don’t need expensive software. Here are the best tools, ranked by how useful they are for LLD:

1
classDiagram
2
    class Dog {
3
        -name: String
4
        +bark(): void
5
    }
6
    class Cat {
7
        -name: String
8
        +meow(): void
9
    }
10
    Animal <|-- Dog
11
    Animal <|-- Cat

Common Interview Mistakes with UML

Tips for Drawing Clean Diagrams

Key Takeaways

What to Read Next

• What is Low Level Design? — Understand how UML fits into the LLD process
• OOP Concepts — The class relationships that UML diagrams visualize
• UML Class Diagrams (Full Reference) — In-depth syntax with code examples in Python, Java, and TypeScript
• Class Relationships Guide — Deep dive into association, aggregation, composition, and dependency
• Top 20 LLD Interview Questions — Practice drawing diagrams for real problems
• LLD Playground — 40+ problems where you’ll use these diagrams

The best designers don’t just think in objects — they communicate in diagrams. Master the notation in this guide, practice on a few playground problems, and you’ll walk into your next interview ready to draw designs that speak for themselves.