Class Diagram

A class diagram is a contract you can compile: each box is a type, each connecting line is a reference one object holds to another, and the small adornments on that line (arrowheads, diamonds, numbers) encode exactly how that reference behaves at runtime — who can navigate to whom, how many objects sit on each end, and whose destruction takes the other down with it. Read the line, and you know what the constructor takes, what the field looks like, and what delete does.

The anatomy of one class box

A class is drawn as a rectangle split into three stacked compartments: name (top), attributes (middle), operations (bottom). Visibility prefixes map straight to access modifiers: + public, - private, # protected, ~ package. An italic class name or operation means abstract. Underlined members are static. This is the part that maps one-to-one onto source code.

The five relationship lines and what each one means

The whole expressive power of a class diagram lives in the line connecting two boxes. Each variant is a different statement about object references and lifetimes:

The single most-tested distinction here is aggregation vs composition, and it is decided by exactly one question: if I destroy the whole, does the part have any reason to keep existing?

Worked example: an airline reservation model

Take four real classes and read every line as a lifetime decision.

Now trace what delete does, the way the runtime would:

1. Delete FlightInstance UA90/2026-07-04. Its two Pilot references are associations, so the pilots survive — they just lose one entry from their own flight list. Nothing cascades to people.
2. Delete its parent Flight UA90. The WeeklySchedule hanging off it by composition is destroyed in the same breath — no other object could legally hold it.
3. Shut down the Airline. Each Aircraft, attached by aggregation, keeps existing. They are reassigned to a new operator. The diagram predicted this: hollow diamond = no cascade.

That cascade-or-not behaviour is the payload of the diagram. Reading the diamond fill tells you, before you write a line of code, whether the whole's destructor must dispose the part.

When to use which relationship — and the trade-offs

The line you draw is a design commitment with real cost. A senior engineer picks deliberately:

Composition vs Aggregation

Choose composition when the part has no identity or use outside its whole and you want the whole to guarantee the part's invariants (it created it, so nothing else can hand it a broken one). You gain encapsulation and a clean lifecycle: one delete, no dangling parts. You pay with rigidity — the part can't be shared or swapped, and it's harder to unit-test the part in isolation because you can't inject a fake (the whole builds the real one internally).

Prefer aggregation when the part is shared across wholes or supplied from outside (an Aircraft serving several routes; a ConnectionPool handed to many services). You gain reuse and testability (inject a mock). You pay with the lifetime question becoming your problem: nobody auto-cleans the part, so you risk leaks or use-after-free-style bugs (a whole holding a reference to a part another owner already disposed).

One-liner: choose composition when destroying the whole should destroy the part; prefer aggregation when the part is shared or has a life of its own.

Association vs Dependency

Use an association (a stored field) when the collaborator is needed across many calls and across time. Prefer a dependency (a method parameter) when the collaborator is needed for one operation only. Promoting a dependency to an association costs you coupling and state to manage; demoting an association to a dependency costs you re-passing the object on every call. Default to the narrowest one that works — a dashed arrow is cheaper to change than a field.

Concrete pick

Modeling Order and its LineItems: line items have no meaning without their order and should vanish with it → composition. Modeling Order and the Customer who placed it: the customer clearly outlives the order and is shared across many orders → aggregation/association, never composition.

Pitfalls

• Drawing composition where aggregation is true. Modeling University ◆— Student implies deleting the university destroys the students. Students transfer; they outlive the institution. This is the most common diamond error — apply the destruction test every time.
• Confusing the diamond end. The diamond always sits on the whole, never the part. A diamond on the wrong side inverts the ownership and misleads everyone reading it.
• Using association for what is really a dependency. If Payment only appears as a method argument, a solid line falsely implies FlightReservation stores a payment forever. Reviewers will look for a field that isn't there.
• Mis-stating multiplicity defaults. An unlabeled end is ambiguous, not "1". Always write the numbers. And remember directionality: an arrowhead means navigation is one-way — the unarrowed class doesn't hold a back-reference, which changes what queries are even possible.
• Over-modeling getters/setters and trivial classes. A class diagram is a communication tool. Cramming every accessor and every DTO makes the structural story invisible. Show the relationships that carry design risk.
• Treating the diagram as the source of truth after code drifts. Because class diagrams map directly to code, a stale one is actively misleading — worse than none. Regenerate from code or delete it.
• Assuming a composition diamond means the database cascade-deletes. UML composition is a statement about object lifetimes in memory, not about your persistence layer. An ORM will not delete the part rows for you unless you configure ON DELETE CASCADE / orphanRemoval=true; a filled diamond in the diagram and a missing cascade rule in the schema is a real source of orphaned rows. The diagram states the intent — you still have to enforce it in the DB.

Takeaways

• Every line is a statement about references and lifetimes; learn to read the adornments and you read the code.
• Aggregation vs composition is decided by one test: does destroying the whole destroy the part? Filled diamond = yes (owns), hollow = no (shares).
• Default to the narrowest relationship — dependency over association, aggregation over composition — and widen only when the design demands it; each widening adds coupling or lifecycle burden.
• The diagram earns its keep only while it matches the code; a stale class diagram misleads precisely because the mapping is so direct.

Re-authored and deepened for this guide. Drawn from the OMG UML 2.5.1 specification (association, aggregation, and composition semantics), Martin Fowler's UML Distilled (the lifetime test for composition and the "diagram as communication" stance), Grady Booch et al., The Unified Modeling Language User Guide, and the Grokking the Object-Oriented Design Interview airline-system example, which supplied the Flight/WeeklySchedule and Airline/Aircraft cases. Placeholder figures replaced with hand-authored, labeled SVG diagrams; worked deletion trace and selection/trade-off guidance added.