Module 03 · Design notation · Lesson 1 of 4
Class diagrams
The working subset of UML class diagrams: classes, interfaces, the six relationship arrows and what each means, multiplicity, and what to leave out. How to draw one in an interview that clarifies the design instead of decorating it.
Why it matters
A class diagram is how a low-level design is communicated: in interviews, in design reviews and in onboarding docs. A clear one shows at a glance which classes exist, what each holds and how they relate; a cluttered one buries the design under every field and getter. You do not need all of UML, which is enormous. You need a small, precise subset and the judgement to draw only what matters.
The idea
A class is a box with up to three compartments: the name, the important fields, and the important operations. An interface is a box marked «interface». Relationships are lines with specific arrowheads. Visibility can be marked with + (public), − (private) and # (protected), but in interviews it is usually enough to show public operations.
The six relationships
| Relationship | Notation | Means | Example |
|---|---|---|---|
| Association | Plain line, optional arrow for navigability | Objects of one class hold references to objects of another | Booking knows its Customer |
| Aggregation | Line with hollow diamond at the whole | A whole groups parts that can exist without it | A Team aggregates Players |
| Composition | Line with filled diamond at the whole | The whole owns the parts; they live and die with it | A Booking is composed of BookingLines |
| Inheritance (generalisation) | Solid line, hollow triangle at the parent | is a kind of | VipCustomer extends Customer |
| Realization | Dashed line, hollow triangle at the interface | implements | StripeGateway implements PaymentGateway |
| Dependency | Dashed line with open arrow | uses temporarily, for example as a parameter or local | Booking.confirm uses a Clock |
In practice, aggregation is drawn inconsistently even by experts; many teams use plain association for "has" and composition (filled diamond) only when lifecycle ownership matters. That is a reasonable simplification as long as you are consistent.
Multiplicity
Numbers at each end of an association say how many: 1, 0..1, * or 0..* (any number), 1..* (at least one). "Customer 1 — 0..* Booking" reads as "each booking belongs to exactly one customer; a customer has zero or more bookings". Multiplicity is often where interviewers probe: can a booking cover several shows? Can a seat appear in two bookings?
What to leave out
- 1
Getters, setters and constructors
They add noise and no design information. - 2
Infrastructure plumbing
Loggers, mappers and framework base classes, unless they are the point. - 3
Every field
Show the fields that drive behaviour or identity; omit the rest or write 'details'. - 4
Every class
Draw the core model for the use case being discussed; mention supporting classes in words.
Drawing one in an interview
Start with the three to six classes at the heart of the problem, connect them with relationships and multiplicities, then add the key operations that carry the rules. Add interfaces where behaviour varies (strategies, gateways). Keep inheritance arrows few and deliberate. Talk while you draw: each line is a decision you should be able to justify in a sentence.
Trade-offs
Diagrams are fast to change and great for agreeing on structure, and they say little about behaviour or concurrency, which is why sequence and state diagrams exist. Formal UML precision helps in documentation shared across teams; in a whiteboard interview, clarity and consistency matter more than strict notation.
In an interview
Narrate the relationships as decisions: "A Show is composed of Seats, since seats do not exist outside a show; a Booking references seats and belongs to one Customer; payment goes through a PaymentGateway interface so we can swap providers." Interviewers grade the decisions, not the arrowheads, but correct arrowheads make the decisions unambiguous.
Check yourself
Which relationship best models an Order and its OrderLines, where lines are created with the order, belong to exactly one order and are deleted when the order is deleted?