UML for Interviews
Read and draw class, sequence, and state diagrams fast — the notation interviewers expect on the whiteboard.
Introduction
UML is a compact interview language for explaining object structure, runtime collaboration, and state transitions before you write Java. You do not need every notation from the UML standard. You need the subset that lets a Microsoft, Oracle, or Adobe interviewer see your classes, ownership boundaries, APIs, and object interactions quickly.
This lesson focuses on class diagrams, the six relationship types, multiplicity, sequence diagrams, state diagrams, activity diagrams, and a fast whiteboard method for drawing a class diagram under time pressure.
Learning Objectives
Draw a class diagram with class names, attributes, methods, and visibility markers.
Explain association, aggregation, composition, inheritance, realization, and dependency with correct Mermaid arrows.
Use multiplicity to show one-to-one, one-to-many, optional, and many-to-many object links.
Choose sequence, state, or activity diagrams when structure alone is not enough.
Build a useful class diagram quickly from requirements in an interview setting.
Avoid common UML mistakes that make a design look more coupled or less precise than intended.
Core Theory
UML in interviews is a communication tool, not a paperwork exercise
Interviewers use UML to test whether you can make design decisions visible. A good diagram answers three questions:
- What are the main responsibilities?
- Who owns or depends on whom?
- What changes over time during important flows?
Use only enough notation to remove ambiguity. If you spend ten minutes perfecting arrowheads and miss the core objects, the diagram has failed. If the diagram makes class ownership, APIs, and request flow clear, it has done its job.
Class diagrams show static structure
A class diagram captures the types in your design and how they relate. Each class box usually has three compartments: class name, attributes, and methods.
Visibility markers matter because they show encapsulation:
- plus means public.
- minus means private.
- hash means protected.
- tilde means package-private.
In an interview, show only attributes that affect the design. Do not list every getter, setter, or simple DTO field. Focus on state that drives rules and methods that represent domain behavior.
public final class Order {
private final String orderId;
private final List<OrderItem> items = new ArrayList<>();
private OrderStatus status = OrderStatus.CREATED;
public void addItem(Product product, int quantity) {
items.add(new OrderItem(product, quantity));
}
public Money total() {
return items.stream()
.map(OrderItem::subtotal)
.reduce(Money.zero(), Money::add);
}
}Association is a structural link between objects
Association means one object knows or is linked to another in the domain. It is a broad relationship and does not imply ownership by itself.
Use association when the relationship is stable enough to appear in the object model, such as Customer places Order or Driver is assigned Ride. Add multiplicity near each end so the reader knows cardinality: 1, 0..1, 0.., 1.., or many when the whiteboard is informal.
Association is stronger than a temporary method call. If an object merely receives another object as a parameter during one operation, that is usually dependency, not association.
Aggregation models weak whole-part ownership
Aggregation is a has-a relationship where the part can outlive the whole. The whole groups or references parts, but destroying the whole does not destroy the parts.
Use aggregation for examples like Team has Players, Catalog has Products, or Playlist has Songs when those parts can exist independently. In Mermaid class diagrams, aggregation uses a hollow diamond at the whole side.
In interviews, be conservative with aggregation. If the lifetime rule is not important, plain association is often enough.
Composition models strong ownership and lifetime control
Composition is a whole-part relationship where the whole owns the part. The part is created, managed, and usually deleted with the whole.
Use composition for Order owns OrderItems, ParkingLot owns Levels, or Level owns ParkingSpots. It communicates strong invariants: an OrderItem should not float around without its Order.
Composition is useful in LLD because it tells the interviewer where lifecycle rules and consistency checks belong.
public final class Order {
private final List<OrderItem> items = new ArrayList<>();
public void addItem(Product product, int quantity) {
if (quantity <= 0) {
throw new IllegalArgumentException("quantity must be positive");
}
items.add(new OrderItem(product, quantity));
}
public List<OrderItem> items() {
return List.copyOf(items);
}
}Inheritance and realization show type substitution
Inheritance, also called generalization, means a child class is a true subtype of a parent class. Use it for stable is-a relationships such as CardPayment is a Payment or Car is a Vehicle.
Realization means a class implements an interface contract. Use it when a concrete class provides a capability, such as StripePaymentProcessor implements PaymentProcessor.
In class diagrams, inheritance uses a solid line with a hollow triangle toward the parent. Realization uses a dashed line with a hollow triangle toward the interface. Both imply substitutability, so do not use them for ownership or service calls.
public interface PaymentProcessor {
PaymentReceipt charge(Money amount);
}
public final class StripePaymentProcessor implements PaymentProcessor {
@Override
public PaymentReceipt charge(Money amount) {
return new PaymentReceipt("stripe", amount);
}
}Dependency is a temporary uses relationship
Dependency means one class uses another but does not own it as part of its long-term state. Examples include a service calling a gateway, a method accepting a formatter, or a controller invoking a validator.
Use dependency when a class needs another type to complete work but the target is not a domain part. The dashed arrow keeps the diagram honest: CheckoutService depends on PaymentGateway does not mean the gateway is contained inside checkout.
Dependencies should usually point from high-level behavior toward small abstractions, not concrete infrastructure classes.
Multiplicity makes relationship meaning precise
Multiplicity shows how many objects can participate in a relationship. It is often the difference between an acceptable diagram and an ambiguous one.
Common values are:
- 1 exactly one.
- 0..1 optional, at most one.
- 0..* zero or many.
- 1..* at least one.
- m..n bounded range.
Always ask whether the requirement allows zero, one, or many. For example, a Customer can place 0..* Orders, while each Order belongs to 1 Customer. That single detail drives storage, validation, and API choices.
Sequence diagrams show one important runtime flow
A sequence diagram shows how participants collaborate over time. It is best for flows such as checkout, reservation, payment, login, notification delivery, or ride matching.
Read it top to bottom. Participants are vertical lifelines. Messages are arrows. Responses can be dashed. Use alt branches when success and failure paths matter. Do not show every internal helper call; show the calls that explain the design.
In interviews, a sequence diagram is strongest after the class diagram. It proves that your classes can actually satisfy a functional requirement.
State diagrams show lifecycle rules
A state diagram models how one object changes state in response to events. It is useful when lifecycle rules are central: tickets, orders, payments, documents, reservations, games, elevators, and workflows.
A good state diagram names allowed transitions and makes invalid transitions obvious. For example, an Order can move from Created to Paid, then Packed, then Shipped, then Delivered. Cancellation may be allowed early but not after delivery.
Use it when enum values alone are not enough. The diagram should answer which event moves the object and which transitions are forbidden.
public enum OrderStatus {
CREATED,
PAID,
PACKED,
SHIPPED,
DELIVERED,
CANCELLED
}Activity diagrams show workflow and branching
An activity diagram shows the steps of a process, including decisions, parallel work, and loops. It is useful when the interviewer cares more about workflow than object ownership.
Use activity diagrams for flows such as process return, approve expense, fulfill order, or retry notification. They are less common than class and sequence diagrams in LLD, but they help when the problem is a business process with many branches.
If time is limited, describe the activity flow in bullets instead of drawing it. Save diagram time for class structure and one critical sequence.
Fast method to draw a class diagram under time pressure
Use this five-minute loop:
- Box the nouns: list the main domain objects from requirements.
- Assign responsibilities: write one sentence per class before adding fields.
- Add public behavior: include the methods interviewers need to see, not boilerplate accessors.
- Connect relationships: choose association, aggregation, composition, inheritance, realization, or dependency deliberately.
- Add multiplicity: mark 1, 0..1, 0.., or 1.. on important links.
- Walk one flow: use a sequence diagram mentally or visibly to catch missing services and methods.
If stuck, start with composition and dependency. Add inheritance or realization only when substitution is clearly useful.
Diagrams
Class diagram relationships and multiplicity
Checkout sequence diagram
Order state diagram
Comparisons
Aggregation vs Composition
| Dimension | Aggregation | Composition | Interview guidance |
|---|---|---|---|
| Ownership strength | Weak whole-part relationship | Strong whole-part relationship | Use composition when the whole controls the part lifecycle |
| Part lifetime | Part can outlive the whole | Part usually dies with the whole | Ask whether the child object makes sense independently |
| Mermaid arrow | Hollow diamond at the whole | Filled diamond at the whole | Draw the diamond near the owner or grouping object |
| Example | Catalog has Products | Order owns OrderItems | Prefer association if lifetime ownership does not matter |
Association vs Dependency
| Dimension | Association | Dependency | Interview guidance |
|---|---|---|---|
| Meaning | A stable structural link between objects | A temporary uses relationship | Use association for domain relationships and dependency for service calls |
| Typical implementation | Field, collection, or persistent reference | Method parameter, local variable, injected collaborator, or call target | Do not turn every helper call into a structural link |
| Mermaid arrow | Solid line arrow | Dashed line arrow | Dashed arrows reduce visual overstatement of ownership |
| Example | Customer places Orders | CheckoutService calls PaymentGateway | If the target is not part of the domain model, dependency is often cleaner |
Best Practices
- ✓
Start diagrams from responsibilities and flows, not from database tables.
- ✓
Use class diagrams for structure, sequence diagrams for one runtime scenario, and state diagrams for lifecycle-heavy objects.
- ✓
Put multiplicity on relationships that affect validation, storage, or API design.
- ✓
Use composition for owned parts and dependency for temporary service usage.
- ✓
Show interfaces only where variation or testability matters.
- ✓
Keep Mermaid class names and participant names simple and alphanumeric.
- ✓
Prefer one clear diagram over several crowded diagrams with tiny labels.
- ✓
After drawing, walk one requirement through the diagram to find missing methods or collaborators.
Common Mistakes
- ×
Using inheritance arrows for has-a relationships such as Order and OrderItem.
- ×
Drawing composition when the part can exist independently and is not lifecycle-owned by the whole.
- ×
Leaving multiplicity out of relationships where optionality or many-to-many behavior matters.
- ×
Listing every getter and setter instead of domain methods that reveal behavior.
- ×
Confusing dependency with association and making temporary calls look like permanent ownership.
- ×
Putting too many controllers, repositories, and infrastructure details in the first class diagram.
- ×
Drawing sequence diagrams with every private helper call instead of major participant interactions.
- ×
Using a state diagram for stateless services rather than lifecycle-driven domain objects.
Quiz
0/7 answered
1.What is the main purpose of a class diagram in an LLD interview?
2.Which relationship should you use when Order strongly owns OrderItem objects?
3.What does realization mean in a UML class diagram?
4.When should you add multiplicity to a relationship?
5.Which diagram best explains the checkout request flow across services?
6.Which diagram is most useful when an object has strict lifecycle transitions?
7.What is a good fast first step when drawing a class diagram under time pressure?
Flashcards
Cheat Sheet
Class diagrams: Show class name, key attributes, public behavior, visibility, and relationships. Skip boilerplate getters and setters.
Visibility: plus is public, minus is private, hash is protected, tilde is package-private.
Association: Stable structural link. Example: Customer places Orders.
Aggregation: Weak whole-part. The part can outlive the whole. Example: Catalog has Products.
Composition: Strong whole-part. The whole owns the part lifecycle. Example: Order owns OrderItems.
Inheritance or generalization: Child is a true subtype of parent. Example: CardPayment extends Payment.
Realization: Class implements interface. Example: StripePaymentProcessor implements PaymentProcessor.
Dependency: Temporary uses relationship. Example: CheckoutService calls PaymentGateway.
Multiplicity: Add 1, 0..1, 0.., or 1.. when cardinality affects rules.
Sequence diagrams: Use for one flow over time, such as checkout, payment, reservation, or login.
State diagrams: Use for lifecycle objects with allowed transitions, such as Order, Ticket, Reservation, or Payment.
Activity diagrams: Use for branching business workflows. If time is short, describe the workflow in bullets.
Fast class diagram method: Box nouns, assign responsibilities, add public behavior, connect relationships, add multiplicity, then walk one flow.
References
- BookUML Distilled — Martin Fowler
- BookThe Unified Modeling Language Reference Manual — James Rumbaugh, Ivar Jacobson, and Grady Booch
- DocsMermaid Class diagrams
- DocsMermaid Sequence diagrams