Overview
A UML class diagram shows the static structure of a design: classes with their key attributes and methods, interfaces, and the relationships between them (inheritance, implementation, association, aggregation, composition, dependency) with multiplicities like 1 or 0..*.
In LLD interviews, a quick class diagram on the whiteboard is the backbone of the discussion. It does not need perfect UML; it needs clear boxes, the important methods, the right relationship arrows, and multiplicities that encode rules ('a spot holds 0..1 vehicle').
It shows rooms (classes), doors between them (relationships), and room sizes (attributes). It does not show people walking around; that is what sequence diagrams are for.
When to use it
- Communicating a design before coding.
- Checking responsibilities and dependencies visually.
- Documenting modules in design reviews.
Where it shows up in interviews
Recognize it when: every LLD interview.
- Design a parking lot
- Design an elevator system
- Design a library system
Where it is used in real software
Text-based diagrams embedded in Markdown docs and GitHub READMEs.
IntelliJ can generate class diagrams from code to understand unfamiliar modules.
Architecture decision records often include a class or component diagram.
Key terms
- Visibility
- + public, - private, # protected.
- Inheritance / realization
- Solid line with hollow triangle / dashed line with hollow triangle.
- Association
- Solid line: one class uses or knows another.
- Aggregation / composition
- Hollow diamond (shared parts) / filled diamond (owned parts).
- Multiplicity
- 1, 0..1, *, 1..* on relationship ends.
How it works, step by step
- 1Draw core entities as boxes
Name plus key fields.
- 2Add main methods
Only those that express behavior.
- 3Add interfaces for variation points
PricingStrategy, Notifier.
- 4Connect with the right relationship
Composition for owned parts, association for references.
- 5Annotate multiplicities
ParkingLot 1 -- * Floor.
Parking lot class diagram (text form)
Key relationships
| From | Relationship | To | Multiplicity |
|---|---|---|---|
| ParkingLot | composition | Floor | 1 to 1..* |
| Floor | composition | ParkingSpot | 1 to 1..* |
| ParkingSpot | association | Vehicle | 0..1 |
| Car, Truck, Bike | inheritance | Vehicle | - |
| HourlyPricing | realization | PricingStrategy | - |
| ParkingLot | dependency | PricingStrategy | 1 |
NOWFrom: ParkingLot | Relationship: composition | To: Floor | Multiplicity: 1 to 1..*
The diagram encodes rules: a spot holds at most one vehicle, and floors cannot exist without the lot.
Implementation
classDiagram class ParkingLot { -floors: Floor[] -pricing: PricingStrategy +park(v: Vehicle) Ticket +exit(ticketId: string) Money } class Floor { -spots: ParkingSpot[] +findSpot(size) ParkingSpot } class ParkingSpot { -id: string -size: Size -vehicle: Vehicle +assign(v) +release() } class Vehicle { <<abstract>> +plate: string +size() Size } class PricingStrategy { <<interface>> +fee(ticket, exitTime) Money } ParkingLot "1" *-- "1..*" Floor Floor "1" *-- "1..*" ParkingSpot ParkingSpot "1" --> "0..1" Vehicle Vehicle <|-- Car Vehicle <|-- Truck PricingStrategy <|.. HourlyPricing ParkingLot --> PricingStrategyComplexity and performance
Keep it readable.
Iterate as you go.
Trade-offs
Perfect UML notation matters less than clear relationships and responsibilities.
Generate or keep diagrams as code (Mermaid) to stay current.
Variants and related techniques
Snapshot of instances at runtime.
Higher-level module structure.
Common mistakes
- Listing every getter and setter.
Fix: Show only meaningful behavior.
- Wrong relationship types.
Fix: Composition only when the part cannot exist without the whole.
- Missing interfaces for variation.
Fix: Show where new behavior plugs in.
Interview questions
Composition vs aggregation in a class diagram?
Composition (filled diamond) means the whole owns the part's lifecycle, like Floor and ParkingSpot. Aggregation (hollow diamond) means the part can exist independently, like Team and Player.
How detailed should an interview class diagram be?
Core entities, key attributes, meaningful methods, interfaces for extension points, relationships with multiplicities. Skip trivial getters and setters.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Draw a class diagram for a library system | Easy | Relationships. |
| Draw a class diagram for an elevator system | Medium | Controllers and strategies. |