UML Class Diagram Basics

1. What Is It?

A UML class diagram is a static structural diagram that shows the classes in a system, their attributes and methods, and the relationships between them. It is the primary diagram used in OOD interviews to communicate a design visually before writing code.

Without a shared notation, "Car has an Engine" is ambiguous — does Engine exist independently? Is it owned by Car? Can multiple Cars share one Engine? UML class diagrams answer these questions precisely with a compact, universally understood visual language. In an interview, sketching a class diagram demonstrates that you can think structurally and communicate unambiguously.

2. How It Works

Class Box

A class is drawn as a three-section rectangle:

┌────────────────────────┐
│      ClassName         │  ← Class name (bold, centered)
├────────────────────────┤
│ - privateField: Type   │  ← Attributes
│ # protectedField: int  │
│ + publicField: String  │
├────────────────────────┤
│ + publicMethod(): void │  ← Methods
│ # helperMethod(): int  │
│ - privateMethod(): bool│
└────────────────────────┘

Visibility modifiers:

• + public
• - private
• # protected
• ~ package-private (Java default)

Stereotypes: Use <<interface>>, <<abstract>>, <<enum>> above the class name to indicate the kind.

Relationships — The Core of UML

Association

Two classes know about each other. The most general relationship.

Customer ──────────────> Order
          places

• Solid line, optional arrow showing direction
• Label the association with the role or verb
• Add multiplicity at each end: 1, 0..1, * (zero or many), 1..* (one or many)

Aggregation (weak "has-a")

A "whole-part" relationship where the part can exist independently of the whole. Depicted by a hollow diamond at the whole end.

Team ◇──────────── Player
 1          0..*

Example: A Team has Players, but players exist independently — they can join other teams.

Composition (strong "has-a")

A "whole-part" relationship where the part cannot exist without the whole. Depicted by a filled diamond at the whole end.

House ◆──────────── Room
  1           1..*

Example: Rooms exist only within a House. If the House is deleted, the Rooms are deleted too.

Inheritance (Generalization)

An "is-a" relationship. Subclass extends base class. Depicted by a solid line with a hollow triangle arrowhead pointing to the parent.

Animal ◁────────── Dog

Realization (Interface Implementation)

A class implements an interface. Depicted by a dashed line with a hollow triangle arrowhead pointing to the interface.

<<interface>>
   Flyable ◁ - - - - Bird

Dependency

The weakest relationship: one class uses another (e.g., as a method parameter or local variable) but does not hold a persistent reference. Depicted by a dashed line with an open arrow.

OrderService - - - -> EmailService

Full Example — Mermaid Notation

Mermaid is the notation used in these documents. Here is the mapping:

-+ResetFullscreen

3. Variants & Comparisons

Aggregation vs. Composition — the key question: "If I delete the whole, do the parts still make sense on their own?"

• Library and Book: delete the library, books still exist → Aggregation
• Order and OrderLineItem: delete the order, line items have no meaning → Composition

4. When to Use It (and When NOT To)

Use class diagrams:

• At the start of an OOD interview to communicate your object model before diving into code.
• Whenever you need to show inheritance hierarchies or interface contracts.
• To make relationships explicit — especially composition vs. aggregation vs. association.

Do NOT use class diagrams for:

• Showing runtime behavior or message sequencing — use a sequence diagram instead.
• Showing state transitions — use a state diagram.
• Showing the full method implementations — class diagrams show signatures, not bodies.

Anti-patterns in interview class diagrams:

• Missing multiplicities: "has a" without 1, *, 0..1 leaves the relationship vague.
• Unlabeled relationships: A line without a label or arrow direction is hard to read.
• Every class connected to every other: Draw the key structural relationships; not everything needs to be shown.
• Showing all private getters/setters: Focus on the semantically important methods; omit trivial accessors.

5. Real-World Usage

1. Design tools and IDEs IntelliJ IDEA, Eclipse, and Visual Paradigm generate UML class diagrams from code and vice versa. Understanding UML lets you read auto-generated diagrams to understand unfamiliar codebases quickly.

2. Gang of Four pattern documentation Every GoF design pattern is defined with a UML class diagram showing the participants and their relationships. Knowing UML notation lets you read and apply the original pattern catalog directly.

3. Java Collections Framework The Java Collections documentation is best understood as a class diagram: Collection <|-- List <|-- AbstractList, AbstractList <|-- ArrayList. The diagram shows why ArrayList has polymorphic identity at every level up the hierarchy.

6. Interview Cheat Sheet

Key sentences to say:

1. "Let me sketch the class diagram first — it'll make the relationships explicit before I write any code."
2. "I'll use a filled diamond for composition here because the child objects have no meaning outside the parent's lifecycle."
3. "The hollow diamond is aggregation — the parts can exist independently, so their lifecycle isn't owned by the whole."
4. "I'm using a dashed arrow for dependency here — OrderService calls EmailService in one method, but doesn't hold a persistent reference."
5. "Multiplicity matters: this is a 1..* relationship — there's always at least one, not zero."

Common follow-up questions:

Q: What's the difference between aggregation and composition? A: Both are "has-a" relationships, but composition implies ownership of lifecycle. If the whole is destroyed and the parts lose meaning, it's composition (filled diamond). If the parts can exist independently, it's aggregation (hollow diamond). Example: Order and OrderLineItem is composition; Team and Player is aggregation.

Q: When do you use a dashed arrow vs. a solid arrow? A: Solid lines represent structural relationships — the class holds a reference (association, aggregation, composition). Dashed lines represent weaker relationships — dependency (used as a parameter/local variable) or realization (implements an interface).

Q: How detailed should a class diagram be in an interview? A: Show all major classes with their key attributes and methods. Include every significant relationship (especially inheritance and composition). Omit trivial getters/setters and purely internal helpers. The diagram should communicate design intent, not be a complete code spec.

Connections to other concepts:

• Every design pattern is described with a class diagram — learning UML makes GoF patterns directly readable.
• Composition vs. Inheritance maps directly to the diamond types in UML.
• The Phase 3 of every OOD interview uses a class diagram as the primary deliverable.