What is UML

What is UML

You are three engineers deep in a design discussion. One draws boxes on a whiteboard, another scribbles arrows, a third describes the same idea in prose in a Slack thread. Everyone thinks they agree about how Order, Payment, and Customer relate — until code review reveals three different mental models. The cost of that ambiguity is rework, and in an interview it is a fumbled design round. UML is the shared vocabulary that removes it.

1. Intuition — the problem it solves

Object-oriented systems are graphs of collaborating objects. The interesting part is rarely a single class; it is the relationships — who owns whom, who calls whom, what implements what, and in which order messages flow at runtime. Natural language is bad at expressing graphs precisely ("the order has some items and talks to payment" — owns? references? one? many?). Raw code is precise but too low-level to reason about architecture; you cannot see the shape of the system through 40 files. UML (Unified Modeling Language) sits deliberately in the middle: a standardized visual notation for describing structure and behavior at exactly the altitude where design decisions live.

"Unified" is historical: in the mid-1990s three rival notations (Booch, Rumbaugh's OMT, Jacobson's OOSE) were merged into one standard, later governed by the OMG. The value is not any single diagram — it is that a diamond, an arrowhead, or a dashed line means the same thing to every engineer who reads it.

2. Precise definition / how it works

UML is a family of diagram types, split into two groups. Structural diagrams show what the system is: class, object, component, deployment, package. Behavioral diagrams show what it does: sequence, use-case, state machine, activity. For LLD interviews, two carry almost all the weight:

• Class diagram — the static picture. Each class is a box with three compartments: name, attributes, methods. Visibility is marked + public, - private, # protected. Relationships are the real content:
  • Association (solid line) — one class uses/knows another.
  • Aggregation (hollow diamond) — a "has-a" where the part can outlive the whole (a Team has Players).
  • Composition (filled diamond) — a strong "has-a"; the part dies with the whole (an Order owns its OrderLines).
  • Inheritance (hollow triangle, solid line) — "is-a".
  • Realization (hollow triangle, dashed line) — a class implements an interface.
  • Dependency (dashed arrow) — a transient use, e.g. a parameter type.
  Multiplicities (1, 0..1, *, 1..*) sit at the line ends to say how many.
• Sequence diagram — the dynamic picture. Vertical lifelines per object; horizontal arrows are messages ordered top-to-bottom in time. This is how you show a scenario executing: "place order" walking through controller, service, and repository.

3. Concrete example

The diagram below and this sketch describe the same design. Note how the code makes concrete what the diagram asserts: Order composes its lines (created and owned internally), depends on a PaymentGateway abstraction passed in, and StripeGateway realizes that interface.

interface PaymentGateway {                 // realized by StripeGateway
    PaymentResult charge(Money amount);
}

final class Order {
    private final String id;
    private final List<OrderLine> lines = new ArrayList<>();  // composition: 1 --> *

    void addLine(Product p, int qty) {     // Order creates & owns the line
        lines.add(new OrderLine(p, qty));
    }

    Money total() {
        return lines.stream().map(OrderLine::subtotal)
                    .reduce(Money.ZERO, Money::plus);
    }

    // dependency: PaymentGateway is used, not owned
    PaymentResult checkout(PaymentGateway gateway) {
        return gateway.charge(total());
    }
}

class StripeGateway implements PaymentGateway { /* ... */ }

When it applies: reach for a class diagram the moment you have more than ~3 collaborating types and need to fix ownership and abstraction boundaries before writing code — exactly the artifact an interviewer expects in the first five minutes of an LLD round.

Sequence diagram for the same design

The class diagram above showed structure; this diagram shows one scenario executing. Time flows down, so a lower arrow happens after a higher one.

1. Customer calls :Order.checkout(1999).
2. Order delegates to its PaymentGateway dependency with charge(1999). It never names Stripe.
3. The call dispatches through the interface to StripeGateway, which produces the receipt.
4. The Receipt returns back up the call chain to the customer.

The sequence diagram makes the dependency direction visible: Order points at PaymentGateway, and StripeGateway realizes that interface. If you later swap in PaypalGateway, this diagram changes in exactly one lifeline name — the message shapes stay the same.

4. When to use / when NOT — the judgment layer

UML earns its keep when a design must be communicated or agreed on before implementation, or when the relationship structure is genuinely non-obvious. In interviews it is table stakes for LLD/OOD questions: a class diagram makes your ownership and abstraction choices legible in seconds.

• vs. plain code: code is the ground truth and never goes stale, but it hides the graph. Use UML to reason about code you haven't written yet; use code once the shape is settled.
• vs. C4 model: C4 (Context/Container/Component/Code) targets system architecture and boundaries and is friendlier for high-level system design; UML class/sequence diagrams win at object-level detail. Many teams use C4 for the big picture and drop to a UML class diagram for a hot module.
• vs. ad-hoc boxes-and-lines: informal sketches are faster to draw but ambiguous — nobody knows if your diamond means composition. UML's cost is the notation you must learn; its payoff is unambiguous, portable meaning.

Do NOT produce exhaustive, tool-generated UML of an entire system ("big design up front"). Such diagrams rot instantly and nobody reads them. The modern, pragmatic stance (Fowler's "UML as sketch") is: draw the few diagrams that clarify a hard decision, keep them lightweight, discard them once the code exists.

5. Pitfalls / what interviewers probe

• Aggregation vs. composition. The classic trap. Composition = coincident lifetimes and exclusive ownership (filled diamond); aggregation = shared, independent lifetime (hollow diamond). If you can't justify which, interviewers pounce.
• Arrow directions. Inheritance/realization triangles point at the parent/interface; dependency arrows point at the thing depended on. Reversing them signals shaky fundamentals.
• Realization vs. inheritance. Dashed triangle = implements an interface; solid triangle = extends a class. Interviewers watch whether you program to abstractions (dashed) rather than concretions.
• Confusing static and dynamic. A class diagram cannot show order of operations — that is what a sequence diagram is for. Reaching for the wrong diagram type is a common tell.
• Over-modeling. Drawing getters/setters, every field, and every class wastes the whiteboard. Show only what carries a design decision.

Key takeaways

• UML is a standardized visual notation for OO structure and behavior — a shared language that removes design ambiguity.
• For LLD interviews, master two: the class diagram (static relationships) and the sequence diagram (runtime message flow).
• Know the relationship glyphs cold: association, aggregation (hollow diamond), composition (filled diamond), inheritance (solid triangle), realization (dashed triangle), dependency (dashed arrow) — plus multiplicities.
• Use it to reason before coding and to communicate; prefer lightweight "UML as sketch" over exhaustive up-front models that rot.
• Interviewers probe aggregation-vs-composition, arrow direction, realization-vs-inheritance, and whether you pick the right diagram for static vs. dynamic questions.

Which diagram answers which question

The two diagrams above carry most LLD rounds, but knowing which diagram a question actually calls for is itself the skill:

Spending a 45-minute LLD budget

Concretely, in a timed round do not draw everything — draw the two views that carry decisions and skip the rest:

Class diagram: 4–8 core types, the key associations, 1–2 critical methods
Sequence:      one happy path (e.g. placeOrder) + one failure (payment fails)
Skip:          every getter/setter, a full deployment diagram, pixel-perfect stereotypes
Code maps:     class → type, association → field, message → method call

The tell of a weak answer is a beautiful class diagram of 30 near-empty boxes that omits ownership and locking, or a sequence diagram that could not actually be implemented. Show only what carries a design decision, and be ready to defend an incomplete diagram with "I modeled the load-bearing types; the rest is mechanical" — that is the correct instinct, not a gap.