subroute.
Beginner15 min readUML & Diagramminglive prototype

Class Diagrams

A class diagram is a labelled box for each class — its name, its data, its actions — joined by lines that show how the classes relate. It is the single most-used picture in low-level design.

The idea

What it is

A class diagram is a picture of the classes in your design. You draw one box per class, write what that class knows and what it does inside the box, and then draw lines between boxes to show how the classes are connected. That's the whole idea. It is the most common diagram in low-level design because it answers the two questions an interviewer (or a teammate) always asks: what are the pieces, and how do they fit together?

Think of it like a blueprint for a house. The blueprint isn't the house — it's a simple drawing that lets everyone agree on the shape before a single brick is laid. A class diagram does the same for code: you sketch the boxes and lines, everyone looks at the same picture, and you catch design mistakes before you write them.

The one sentence to remember

A class diagram = boxes (each box is a class, split into name / data / actions) joined by lines (each line shows how two classes relate). Learn to read the box and read the line, and you can read any class diagram.

Mechanics

How it works

The box: three stacked compartments

Every class is a rectangle split into three rows from top to bottom. The top row is the class name. The middle row lists its attributes — the data it holds. The bottom row lists its operations — the things it can do (its methods). That order never changes, so once you've seen one box you can read them all.

BankAccount - owner: String - balance: double + deposit(amount: double) + withdraw(amount: double) + getBalance(): double name attributes (data it knows) operations (what it can do)
Read the box top to bottom: the name sits on top, the attributes (the data it knows) in the middle, and the operations (what it can do) at the bottom. The symbol in front of each line is its visibility — + means public (anyone can use it) and - means private (hidden inside the class).

The symbols: + - # in front of every line

Each attribute and method starts with a small symbol that says who is allowed to touch it — this is the visibility. There are only a few, and they map exactly onto the access keywords you already know from code:

  • `+` public — anyone can use it. (public in code.)
  • `-` private — only this class can use it; hidden from everyone else. (private in code.)
  • `#` protected — this class and classes that inherit from it. (protected in code.)
  • `~` package — anything in the same package/module. (the default in Java.)

How to read a single line

Read a line left to right: visibility · name · type. So - balance: double is “a private attribute named balance that holds a double.” And + deposit(amount: double): void is “a public method named deposit that takes a double called amount and returns nothing.” The return type comes after the colon at the end.

The lines: how two boxes connect

Boxes on their own just list pieces. The lines between boxes are where the design lives — they show how classes depend on, contain, or build on one another. The exact shape of the line's end carries the meaning, so the arrowhead matters. Here are the six you'll meet, from loosest to tightest:

  • Association (a plain line) — “knows about / uses.” A Teacher is associated with the Students they teach.
  • Dependency (a dashed line with an open arrow) — “uses temporarily.” One class needs another just for a moment, e.g. it takes it as a method argument.
  • Aggregation (a line with a hollow ◇ diamond) — “has-a, but the parts can live on their own.” A Team has Players; delete the team and the players still exist.
  • Composition (a line with a filled ◆ diamond) — “owns-a; the parts die with the whole.” A House is composed of Rooms; demolish the house and the rooms are gone too.
  • Inheritance / Generalization (a solid line with a hollow ▷ triangle) — “is-a.” A SavingsAccount is a BankAccount.
  • Realization / Implementation (a dashed line with a hollow ▷ triangle) — “promises to do.” A Dog class implements an Animal interface.

Diamond trick: which end, and hollow vs filled

The diamond always sits on the side of the whole (the container), not the part. Hollow ◇ = aggregation (parts survive without the whole). Filled ◆ = composition (parts can't exist without the whole). Remember it as: filled means a stronger bond — they share one fate.

Multiplicity: how many?

Next to the ends of a line you'll often see numbers — that's multiplicity, the count of objects on each side. It reads just like a range: 1 is exactly one, 0..1 is zero or one (optional), * (or 0..*) is any number including none, and 1..* is one or more. So an Order 1 ── * OrderLine means one order has many order lines.

Three small conventions for special classes

  • Abstract class — the class name is written in italics (it can't be instantiated directly).
  • Interface — the box has the keyword «interface» above its name.
  • Static member — the attribute or method is <u>underlined</u> (it belongs to the class, not to any one object).

Don't draw every getter and field

A class diagram is communication, not a code dump. Show the attributes and methods that explain the design and skip the obvious noise (trivial getters/setters, framework boilerplate). A box with 40 methods teaches nothing; a box with the 4 that matter teaches everything.

Interactive prototype

See it. Build it. Break it.

A sandboxed, hands-on simulation — no setup, no install. Play with it as you read.

About this simulation

Two clean panels. Anatomy walks you through one real class box — BankAccount — one part at a time: the name, the data, the actions, and the little + - # symbols in front of each line. Click Next and the highlighted part lights up while a one-line plain-English note explains it. The Relationships panel is a cheat-sheet of the six lines that connect classes; click any line to see what it means and a way to remember it. Only one note shows at a time, so nothing scrolls away or grows the page.

Hands-on

Try these yourself

Open the prototype above, predict what happens, then verify.

try 01

Read the box top-to-bottom

Open the prototype's Anatomy panel. Before clicking anything, read the BankAccount box yourself: name on top, the two - attributes in the middle, the three methods at the bottom. Now click Next to step through each part — confirm your reading matched the plain-English note that appears.

try 02

Decode the symbols

On the visibility step, find the + on deposit and the - on balance. Say out loud what each means: deposit is public (anyone can call it); balance is private (only the account touches it). That - is exactly why encapsulation works — outsiders must go through deposit/withdraw, never poke balance directly.

try 03

Tell the six lines apart

Switch to the Relationships panel and click each of the six connectors. Focus on the two diamonds: click aggregation (hollow ◇) then composition (filled ◆) back-to-back and read how they differ — parts survive vs parts die with the whole. That single distinction is the most common class-diagram interview question.

In practice

When to use it — and what trips people up

When to reach for a class diagram

Draw one whenever you need to show structure: at the start of a design to agree on the pieces, in an interview to lay out your classes before coding, in a code review to explain how a new module hangs together, or when onboarding someone into an unfamiliar codebase. It's the default diagram for low-level design because almost every LLD problem is, at heart, “what classes, and how connected?”

In an interview, the box is your thinking out loud

When asked to design something (a parking lot, an elevator, a vending machine), start by sketching boxes for the nouns and lines for the relationships. The diagram is the conversation — it shows the interviewer you can decompose a problem into clean, well-related classes.

What it gives you

  • Universal — almost every engineer can read one, so it's the fastest way to share a design.
  • Catches structural mistakes (wrong ownership, missing relationships, a god class) before you write code.
  • Maps almost one-to-one to real code, so it's easy to go from diagram to implementation and back.
  • Scales from a quick 3-box whiteboard sketch to a full module map.

Common mistakes

  • Shows structure, not behaviour — it can't tell you the order things happen in (that's a sequence diagram's job).
  • Goes stale fast if drawn in too much detail; an over-precise diagram becomes a second copy of the code to maintain.
  • Easy to overload — cramming every field and getter in turns a teaching tool into unreadable noise.
  • The notation has corners (multiplicity, diamonds, dashed vs solid) that beginners mix up until practised.

Reference

Code & further reading

A minimal reference implementation and pointers worth bookmarking.

// The class diagram box on the left becomes this code on the right.
// Visibility symbols map straight to keywords: + → public, - → private, # → protected.

// «interface» Account  — a dashed-triangle "realization" in the diagram
interface Account {
  deposit(amount: number): void;
  getBalance(): number;
}

// BankAccount  ──▷  Account   (implements / realization)
class BankAccount implements Account {
  private owner: string;       // - owner: String
  private balance: number;     // - balance: double

  constructor(owner: string) {
    this.owner = owner;
    this.balance = 0;
  }

  public deposit(amount: number): void {  // + deposit(amount: double)
    this.balance += amount;
  }

  public getBalance(): number {           // + getBalance(): double
    return this.balance;
  }
}

// SavingsAccount  ──▷  BankAccount   (inheritance / generalization, "is-a")
class SavingsAccount extends BankAccount {
  private rate: number = 0.04;            // - rate: double
}

References & further reading

5 sources

Knowledge check

Did it land?

Quick questions, answers revealed on submit. Sign in to save your best score.

question 01 / 05

In a UML class box, what do the three compartments contain, from top to bottom?

question 02 / 05

You see - balance: double inside a class box. What does the leading - mean?

question 03 / 05

A House is made of Rooms, and if you demolish the house the rooms cease to exist too. Which relationship and notation models this?

question 04 / 05

What does the multiplicity in Order 1 ── * OrderLine tell you?

question 05 / 05

Which kind of question can a class diagram NOT answer well?

0/5 answered