OOAD and UML — Overview

Summary#

Object-oriented analysis and design (OOAD) is the discipline of going from a problem statement to a runnable design by way of objects — entities with state and behaviour that exchange messages. Analysis asks “what are the things in the world this system cares about, and how do they relate?” Design asks “what classes, interfaces, and collaborations represent those things, and how do messages flow between them?” The Unified Modelling Language (UML) is the picture vocabulary the industry settled on for sketching the answer.

In an LLD interview, OOAD is the activity and UML is the artefact. The interviewer wants to watch you do the activity and read the artefact. They are not grading the prettiness of the diagrams; they are grading whether each diagram answers the question it is the right diagram to answer. Four of the fourteen UML diagram types carry essentially the entire weight of the round: use case, class, sequence, and activity. The remaining ten are useful in industry and rarely demanded in an interview window.

If you can pick the right diagram for the right question, draw it in under five minutes by hand, and read someone else’s diagram without misinterpreting the arrows, you have the UML skill the round is testing.

Why it matters#

Every LLD problem — Parking Lot, Elevator, ATM, Chess, Hotel — moves through the same four-step arc, and each step has a UML diagram that is the natural artefact for it.

The first step is scoping: who interacts with this system, and to do what? A use case diagram pins this down before you draw a single class. Skipping it is the single most common failure mode in LLD: candidates start drawing classes for features the interviewer never asked about and miss a feature the interviewer assumed was in scope. Two minutes of use cases is the cheapest insurance available.

The second step is structure: what are the nouns, and how are they related? A class diagram answers this. Boxes for classes, lines for relationships, multiplicities at the line ends, stereotypes (`<<interface>>`, `<<abstract>>`) where the kind of box matters. This is the artefact the interviewer will spend the most ink reviewing, because it is the artefact most directly tied to the code.

The third step is dynamics: when a request enters the system, what message goes to whom and in what order? A sequence diagram answers this. It is the diagram that catches a missing collaborator faster than any other — the moment you cannot draw the next arrow, you have discovered an undefined responsibility.

The fourth step is non-trivial workflow: when the control flow has branches, parallel paths, or a multi-actor lifecycle, an activity diagram is the right tool. State machines for a single object’s lifecycle (a ticket, an order, a session) are a special case the activity-diagram notation also covers cleanly.

How it works#

The four diagrams operate at different levels of abstraction and answer different kinds of question. Holding that distinction is the core skill.

                +----------------+   answers "who and what"
   level 1 ---> |   Use case     |   actors, goals, scope
                +----------------+
                        |
                        v
                +----------------+   answers "what are the things"
   level 2 ---> |     Class      |   nouns, relationships, contracts
                +----------------+
                        |
                        v
                +----------------+   answers "what message goes where"
   level 3 ---> |    Sequence    |   one flow, ordered, object-to-object
                +----------------+
                        |
                        v
                +----------------+   answers "what is the control flow"
   level 4 ---> |    Activity    |   branches, joins, swim-lanes, states
                +----------------+

The arrows are not strict — you can iterate. But the first pass through the problem usually proceeds top-down: scope, then structure, then a key flow, then any workflow with branches.

What each diagram is, in one sentence#

• Use case diagram — actors as stick figures, use cases as ellipses inside a system boundary, with `<<include>>` and `<<extend>>` for shared sub-flows. It is the scope picture.
• Class diagram — classes as boxes (three compartments: name, fields, methods), relationships as lines (association, aggregation, composition, generalization, realization), multiplicities like `1`, `0..1`, `0..*`, `1..*` at line ends. It is the structure picture.
• Sequence diagram — lifelines as vertical dashed lines under object boxes, messages as horizontal arrows between lifelines, activation bars on the lifeline showing when an object is executing. It is the flow picture.
• Activity diagram — rounded rectangles for actions, diamonds for decisions, bars for forks and joins, optional swim-lanes for actors. It is the workflow picture.

A worked thread through all four#

For the Parking Lot problem:

• Use case. Two actors (Driver, Admin). Three primary use cases for the Driver (park vehicle, retrieve vehicle, pay fare). Admin use cases (configure rates, audit revenue) are explicitly out of scope.
• Class. ParkingLot aggregates Floor (1..), each Floor aggregates ParkingSpot (1..), a Vehicle is HAS-A inside a Ticket, a RateTable and PaymentStrategy hang off ParkingLot by composition.
• Sequence. The parkVehicle flow: EntryGate → ParkingLot → Floor → ParkingSpot.assign → new Ticket → return ticket to driver. Six arrows, one direction, no branches.
• Activity. The Ticket lifecycle: Issued → (Lost?) → Paid → Closed. Two branches, one terminal state, no concurrency.

Four diagrams; the interviewer can read the design without you saying a word. That is the bar.

Variants and trade-offs#

Choosing among the four — and choosing whether you need a fifth — is a recurring micro-decision.

The four-diagram set covers ~95% of LLD interviews. The remaining UML diagram types — component, deployment, state machine (as a standalone), object, package, communication, timing, interaction overview, composite structure, profile — are rarely asked for in a 45-minute window. The two most likely to appear as an explicit ask:

• State machine diagram when the problem has a clearly stateful entity (a payment, an order, a session). The activity-diagram notation usually covers this; only reach for a separate state machine if the interviewer explicitly names the diagram.
• Component / deployment diagram when the interviewer pushes from LLD into HLD (“draw the deployment topology”). Rare in a pure LLD round; common at the LLD-HLD boundary.

A useful rule for noise: never draw a diagram you cannot defend in two sentences. If you cannot say “this diagram exists because the interviewer asked X, and it answers X by showing Y,” the diagram is decoration.

When this is asked in interviews#

Three failure modes show up repeatedly.

The first is skipping use cases entirely and going straight to classes. The interviewer asks “who uses this and to do what?” three minutes in, and the candidate realises they have been designing for the wrong actor. Two minutes of use cases at the top would have surfaced this. The fix is muscle memory: every problem starts with actors and primary use cases on the board, even if they are crude.

The second is drawing a class diagram that is actually pseudocode. The boxes have method bodies inside them, the relationships are missing multiplicities, the arrows do not distinguish association from aggregation from composition. The diagram works for the candidate because they are reading it as code, but the interviewer reads it as a diagram and finds it unparseable. The fix is to treat each compartment as a contract: name on top, fields in the middle, method signatures (not bodies) on the bottom; arrows annotated.

The third is a sequence diagram that drifts into business logic instead of object messages. The candidate writes “validate payment is valid and not expired” inside an activation bar; what should be there is validate(payment) as the message label, with the validation logic discussed verbally. The sequence diagram is a score the interviewer reads along with your narration — keep it readable.

A signal interviewers reward: at the start of each diagram, name it out loud. “This is the class diagram. The interesting relationship is ParkingLot composes Floor — floors do not exist without a lot. Multiplicity is `1..*`.” Saying the type of diagram and the load-bearing relationship orients the room.

Related concepts#

The four diagrams have their own writeups; each carries a small worked example, the notation rules, and the failure modes specific to that diagram type.

• Use Case Diagrams — actors, use cases, `<<include>>`, `<<extend>>`. The scope picture.
• Class Diagrams — boxes, lines, multiplicities. The structure picture.
• Sequence Diagrams — lifelines, messages, activations. The flow picture.
• Activity Diagrams — branches, merges, swim-lanes. The workflow picture.
• OOP Fundamentals — The Four Pillars — the vocabulary the class diagram is drawn in.
• Approaching the OOD Interview — the meta-script that uses all four diagrams in sequence.
• Parking Lot — the gold reference for what all four diagrams look like on a real problem in this codebase.