UML and Class Diagrams

1The problem it solves#

Pin down what the pieces are and how they connect before you argue about method signatures. The diagram is the shared language that makes that possible.

The situation you are handed.

• You get asked to design a parking lot, a ride-sharing system, or a vending machine.
• You have 35 minutes, and maybe 5 go to clarifying requirements.
• You need to agree on the objects and their connections before debating whether withdraw() returns a boolean or throws.

Why jumping straight to code hurts you.

• You lose the forest for the trees: deep in a withdraw() method while the interviewer wonders why there is no Account class at all.
• You cannot change your mind cheaply. Moving a box takes two seconds; refactoring whiteboard code at minute 25 burns the time you needed for the hard part.

What the diagram buys you.

• It is compact, visual, and forces the big decisions out loud: what are the objects, what do they own, who talks to whom.
• Get that right and the code almost writes itself.

2The idea (mental model)#

Think of a class diagram as a set of boxes connected by arrows. That is the entire model.

Each box is a class, in three stacked sections.

• The name on top.
• The data it holds (fields) in the middle.
• The things it can do (methods) on the bottom.

The arrows are the interesting part. They answer one question: when object A needs to know about object B, what kind of relationship is that?

• Is B a part of A?
• Does A just borrow a reference to B?
• Is A a specialized kind of B?

So the whole technique reduces to two moves.

• Boxes for the nouns.
• Arrows for how the nouns relate.
• Name the nouns, draw the right arrow between each pair, and you have a class diagram.

One note on visibility symbols, because they come up.

• + means public, - means private, # means protected.
• I keep fields private (-) and methods public (+) unless there is a reason not to.
• Nobody fails you over a visibility marker, but it signals you think about encapsulation, which is the start of the Single Responsibility and open-closed thinking the interviewer is watching for.

3Structure#

The relationships are where candidates either look sharp or look shaky. There are really only five, and they sit on a spectrum from "loosely knows about" to "literally made of."

• Association (-->): A uses B. A holds a reference, but B can live on its own. A Driver is associated with a Car.
• Aggregation (o--): A "has" B, and B can exist without A. A Team has Player objects, but if the team dissolves the players still exist. Hollow diamond.
• Composition (*--): A owns B, and B dies when A dies. An Order is composed of OrderItems. Delete the order and those line items mean nothing. Filled diamond.
• Inheritance (<|--): B is a kind of A. A SavingsAccount is an Account. Hollow triangle pointing at the parent.
• Realization or implements (..|>): B implements interface A. A CreditCardPayment realizes a PaymentMethod interface.

The honest truth about aggregation versus composition.

• In interviews the line gets fuzzy, and nobody quibbles if you call a has-a relationship by either name.
• What matters is knowing the difference in lifetime.
• Composition means shared death. Aggregation means independent life.

Here is a small banking model that uses most of these:

Read it out loud the way you would at the whiteboard.

• A Customer has Accounts (aggregation, because closing one account does not delete the customer).
• Each Account owns its Transactions (composition, because a transaction without its account is garbage).
• SavingsAccount and CheckingAccount are kinds of Account.
• CreditCardPayment implements the PaymentMethod interface.

That last arrow is not decoration.

• Programming to the PaymentMethod interface instead of a concrete card class is the Dependency Inversion Principle.
• It is exactly where the Strategy pattern slots in when you want to swap card, wallet, and UPI at runtime.

4Implementation in Java#

Each arrow becomes a specific Java construct, which is why a clean diagram translates straight into code. Here is the banking model turned into just enough Java to make the relationships concrete.

// Inheritance: SavingsAccount <|-- Account
abstract class Account {
    private String id;
    private double balance;

    public void deposit(double amount) {
        balance += amount;
    }

    public boolean withdraw(double amount) {
        if (amount > balance) return false;
        balance -= amount;
        return true;
    }

    public double getBalance() { return balance; }
}

class SavingsAccount extends Account {
    private double interestRate;

    public void applyInterest() {
        deposit(getBalance() * interestRate);
    }
}

// Composition: Account *-- Transaction
// The account creates and owns its transactions.
class Transaction {
    private final double amount;
    private final String type;

    Transaction(double amount, String type) {
        this.amount = amount;
        this.type = type;
    }
}

// Aggregation: Customer o-- Account
// Accounts are passed in from outside; the customer does not create them.
class Customer {
    private String name;
    private final List<Account> accounts = new ArrayList<>();

    public void addAccount(Account account) {
        accounts.add(account);   // reference held, not owned
    }
}

// Realization: CreditCardPayment ..|> PaymentMethod
interface PaymentMethod {
    boolean pay(double amount);
}

class CreditCardPayment implements PaymentMethod {
    @Override
    public boolean pay(double amount) {
        // charge the card
        return true;
    }
}

The tell for composition versus aggregation lives in the code, not the diagram.

• Composition: the owner creates the part. An Account would new its own Transaction.
• Aggregation: the part is handed in from outside, as in addAccount(Account account).
• That is the exact distinction the diamond notation captures, and it is worth saying out loud in the interview.

The aggregation version is also looser coupling, which earns points on its own.

• Customer depends on the Account type, not on constructing it.
• That keeps the class testable: you can hand in a stub instead of a real account.

5A real-world example#

Take a food delivery app, the kind of thing you might actually get asked to design. The nouns fall out quickly, and the arrows follow from one question about ownership.

The nouns.

• User, Restaurant, MenuItem, Cart, Order, Payment, DeliveryAgent.

The arrows, decided by "does the part die with the whole?"

• A Restaurant owns its MenuItems. If the restaurant leaves the platform, those menu items go with it. Composition.
• A Cart references MenuItems. Deleting your cart does not delete the restaurant's dishes. Association.
• An Order owns its OrderLines (the frozen snapshot of what you bought at what price). Composition, because an order line outside its order is meaningless.
• An Order references one Payment and one DeliveryAgent. The agent exists whether or not this order does. Association.

Why this maps straight onto real backend models.

• Composition relationships usually become owned child tables with cascade-delete.
• Associations become foreign keys to rows that live independently.
• Drawing these four arrows correctly tells me you understand data ownership, and that is most of LLD right there.

The same shape shows up everywhere once you see it.

• ParkingLot o-- ParkingSpot, Playlist o-- Song, Document *-- Paragraph.
• Learn to ask "does the part die with the whole?" and the arrow picks itself.

6When to use it, and when not to#

The class diagram is your default opening move, but it answers only one kind of question. Know the boundary.

Use it when the problem is about structure.

• What objects exist, what they contain, how they relate.
• Almost every LLD interview is exactly this.
• Draw it in the first five minutes, right after you nail down requirements.

Do not lean on it when the question is about behavior over time.

• "What happens, step by step, when a user checks out?" is a sequence question, not a structure question.
• A class diagram shows a frozen snapshot; it cannot show order of events.
• For that, reach for a sequence diagram:

Also skip the full UML ceremony when a quick sketch does the job.

• You do not need multiplicities, stereotypes, and perfectly drawn diamonds on a whiteboard.
• Clear boxes and correct arrows beat a textbook-perfect diagram that took fifteen minutes.
• Fifteen minutes is nearly half your budget.

7Common mistakes#

These are the ones I see cost real candidates. Each maps to a principle the interviewer is quietly scoring.

• Fields and methods everywhere, no arrows. The most common one. Five beautiful boxes, never connected. The arrows are the design; a diagram with no relationships tells me nothing.
• Inheritance for code reuse. Reaching for extends just to share a couple of methods. Inheritance means "is-a." If AdminUser is genuinely a kind of User, fine. If you are inheriting to grab a helper, use composition. This is the single most over-used arrow, and "favor composition over inheritance" is the exact phrase the interviewer wants to hear. Deep inheritance trees also break the Liskov Substitution Principle fast.
• God class. One box with twenty fields and fifteen methods. That is a smell, not a design. It usually means you skipped asking what the real nouns are, and it violates Single Responsibility on its face.
• Confusing composition with aggregation and then sweating it. Know the lifetime difference, say which one you mean, and move on. I have never failed a candidate over a diamond color. I have failed them for not knowing an Order owns its line items.
• Drawing the diagram and then ignoring it. If your code and your diagram disagree by minute 25, you have lost the plot. The diagram is a living contract. Update it when you change your mind.

8Where it shows up in interviews#

Every structural LLD question opens here. "Design a parking lot," "design a library management system," "design an elevator," "design a chess game."

The expected first move is always the same.

• Clarify requirements, then draw the class diagram.
• This is the Easy-rated opener at companies like Amazon, Uber, and Atlassian.
• It gates the rest of the loop: botch the structure and you never reach the patterns that earn the senior signal.

What the interviewer is actually scoring.

• Did you find the right classes? (Good noun extraction.)
• Are your relationships correct? (Aggregation versus composition versus inheritance.)
• Did you program to interfaces where it matters? (That is where Strategy, Factory, and Dependency Inversion start.)
• Can you walk the diagram and explain a flow? (This is where a sequence diagram earns points.)

My one piece of advice: talk while you draw.

• "I will make Account abstract because we never instantiate a plain account."
• "Customer aggregates accounts, hollow diamond, because accounts outlive any single session."
• That narration is worth more than the drawing itself. It shows how you reason, and reasoning is the thing I am hiring for.

Next, read the guides on the Strategy and Factory patterns, and the full Parking Lot LLD walkthrough, to see these arrows turn into real designs.