How do you draw a class diagram for a simple parking lot on a whiteboard?
Fast recall
Quick revision
Core answer
Practical ability to translate a real-world system into a class diagram on the spot, under time pressure, which is the core of LLD interview rounds.
Either drawing too many classes with every possible detail (wasting time) or drawing only entity names without showing relationships and key members.
Explain your design choices aloud while drawing—why Vehicle is abstract, why you chose composition for floors, and how the ticket links vehicle to spot for billing.
Interview-ready guide
Interview answer
On a whiteboard I start by listing the main entities so I don't forget any: ParkingLot, ParkingFloor, ParkingSpot, the Vehicle hierarchy with Car and Motorcycle, and ParkingTicket. Then the layout trick that keeps the diagram clean is to arrange boxes by ownership, top to bottom. I put ParkingLot at the top, ParkingFloor underneath it, and ParkingSpot under that, with the Vehicle hierarchy off to one side. That way the composition lines all flow downward and don't cross each other.
In each box I write three to five of the most important attributes and methods — enough to convey the design decisions — and I deliberately skip getters, setters, and trivial helpers, because they add clutter without adding meaning. Then I draw the relationships. ParkingLot to ParkingFloor and ParkingFloor to ParkingSpot are composition, so I use a solid line with a filled diamond on the owner's end, since a spot can't exist without its floor. For the vehicles, Car and Motorcycle inherit from the abstract Vehicle, so I draw solid lines with hollow triangles pointing up to Vehicle.
Finally I annotate multiplicities — a one next to the lot and a star next to the floors — so anyone reading it instantly sees the one-to-many. The whole point is that a clean diagram with correct arrowheads and multiplicities communicates the design faster than any amount of talking, so I keep it tidy and let the notation do the work.
For example, the entry use case should be traceable directly on the drawing: ParkingLot selects one ParkingSpot, the spot accepts one Vehicle, and TicketService creates a ParkingTicket associated with both objects.
How do you draw a class diagram for a simple parking lot on a whiteboard
Direct Answer
Start by identifying the main entities: ParkingLot, ParkingFloor, ParkingSpot, Vehicle (with Car/Motorcycle subclasses), ParkingTicket, and a fee calculator. Draw a box for each with 3-5 key attributes and methods. Then connect them: ParkingLot contains multiple ParkingFloors (composition), each floor has multiple ParkingSpots (composition), Vehicle is abstract with inheritance arrows to concrete types, and ParkingTicket associates with Vehicle and ParkingSpot.
Deep Dive & Architecture
Boxes follow ownership
Place ParkingLot above ParkingFloor and ParkingSpot so their composition chain reads from top to bottom. Put the Vehicle hierarchy to one side and ParkingTicket near the spot and vehicle it connects. Each box needs only the fields and operations that explain the design.
Relationships carry the meaning
A filled diamond at the owner shows composition from one lot to many floors and from one floor to many spots. Hollow triangles from Car and Motorcycle point to abstract Vehicle. Associations connect a ticket to one vehicle and one spot. Multiplicities such as 1 and 1..* make collection sizes explicit.
A single entry flow checks the diagram
For example, ParkingLot.findSpot(vehicle) selects a compatible free spot, the spot becomes occupied, and TicketService.issue(vehicle, spot) creates the ticket. If that flow cannot be followed through the boxes and relationships, a responsibility or association is probably missing.
Code Example
class ParkingLot { List<ParkingFloor> floors; Optional<ParkingTicket> park(Vehicle v); }
class ParkingFloor { List<ParkingSpot> spots; Optional<ParkingSpot> findFree(SpotSize s); }
class ParkingSpot { SpotSize size; boolean free; boolean park(Vehicle v); }
abstract class Vehicle { String plate; SpotSize requiredSize(); }
class Car extends Vehicle { SpotSize requiredSize() { return SpotSize.REGULAR; } }
Three composition links down the chain, one inheritance fan for vehicles.
Common Mistakes & Pitfalls
- Cramming every method into boxes — show 3–5 that convey design; skip getters.
- Tangled lines — lay out by ownership (top-down) to keep composition lines clean.
- Wrong diamond direction — the filled diamond sits on the owner (lot), not the part.
- Forgetting multiplicities —
1and*communicate the one-to-many at a glance.
Check your understanding
Answer these without looking back at the article.
- What are the key elements of a UML class diagram?
- How do you show an interface and its implementations in a class diagram?
- How much detail should a class diagram in an LLD interview have?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.