Behavioral modeling

Use cases and system operations

A use case is one goal a user can finish with the system — park, exit, mark a spot out of service. Classes come after you name those goals and what is out of scope.

Example: the interviewer says “design a parking lot.” One candidate starts boxes: ParkingLotManager, GateHelper, TicketUtil. Another says: “A driver parks, a driver exits, an admin might mark a spot out of service. I am not building Stripe.” Start with use cases.

Before any class

1
Name the actors
Driver, admin, a second gate.
2
Name the jobs
Park, exit, pay, disable.
3
Cut the rest
Rules, data, and out of scope.
4
Write the signatures
park(Vehicle) → Ticket.

Interview flow

Conversation map: verbs first, boxes later

Treat the first five minutes as a filter. Every sentence in the problem is either an actor, a job, a rule, a fact, or . Only jobs become operations. Only operations need classes.

Who is talking?

↓

What job do they want?

↓

What is the method?

Stripe, GPS, iOS, multi-city

What is a use case, and what is not

A is one getting one job done with the system. The job is a verb. Until you can say those verbs, every class you invent is a guess. ParkingLotManager appears because you needed a box. Start with park and exit. The boxes come from who must carry those verbs.

Not every sentence in the problem is a use case. “Tickets have ids” is a fact. “Fees depend on vehicle type” is a rule. “Drivers enter and leave” is the use case. Split the paragraph. Write four lists on the board: actors, jobs, rules, out of scope. The class diagram waits until the jobs have signatures.

Is a use case

A driver parks a vehicle and receives a ticket.
A driver exits with a ticket and receives a receipt.
A driver pays an active stay (sometimes folded into exit).
An admin disables a broken spot.

Not a use case

Ticket has an id and an entry time.
Fees depend on vehicle type and duration.
The lot has floors and spots.
Money is a value object — that is a modeling fact, not a job.

Worked parking lot: two actors, four jobs

Say the product in one breath. A arrives, parks, later pays, and leaves. An admin can take a spot out of service. That is the whole round unless they add EV spots or airport pricing — those are rules and seams, not new actors.

Actor: Driver

park — vehicle in, ticket out.
pay — ticket id in, receipt out (or folded into exit).
exit — ticket id in, receipt out, spot free.

Actor: Admin

disable — spot id in, that stall stops accepting cars.
No receipt. No ticket. The lot just has one fewer free stall.
If a car is already there, refuse. Do not add an evict use case unless they ask.

Jobs become operations

A is the contract you will implement. Types in, types out. After this table exists, you may open responsibility assignment and ask which pocket owns each verb. Not before.

Actor	Verb	Operation	Failure that belongs here
Driver	park	park(Vehicle) → Ticket	Lot is full — no ticket, no occupy.
Driver	exit	exit(TicketId) → Receipt	Unknown ticket — no release, no close.
Driver	pay	pay(TicketId) → Receipt	Already PAID — ignore or reject, never reopen.
Admin	disable	disable(SpotId) → void	Spot occupied — refuse, do not evict.

Happy path — park

Driver arrives with a car. The lot has a free stall that fits. The system occupies the stall, issues a ticket in CREATED then ACTIVE, and hands the ticket back. That is the . Write it as a sentence before you draw classes.

Failure that is still the use case

Lot full: no occupy, no ticket, an error the driver can hear. Unknown ticket on exit: no release, no close. A second pay on an already PAID ticket is not “put it back to ACTIVE.” That illegal move lives on the state machine page.

The public door in Java

The controller is allowed to be thin. These methods are the use cases. Everything else — lot, strategy, repository — exists so these four lines stay honest. A God service that also sends SMS is a later smell, not a use-case win.

java

class ParkingService { // controller — use-case door, not a class dump
  Ticket park(Vehicle vehicle) { /* allocate, occupy, issue, save */ }
  Receipt pay(TicketId id)     { /* load, price, ticket.pay, save */ }
  Receipt exit(TicketId id)    { /* load, require PAID, release, close */ }
  void disable(SpotId id)      { /* refuse if occupied */ }
}

// Not a use case: Ticket has an id.
// Out of scope: StripeCharge, IosPush, CityWideFleet.

Split the problem paragraph

Interviewers read a paragraph. You sort it. This is the same discipline as the HLD “clarify users and scope” step, aimed at in-process verbs instead of QPS.

Actors

Driver, admin

Jobs

Park, exit, pay, disable

Rules

Fee by type, one car per spot

Out of scope

Stripe, GPS, multi-city

Why classes wait

Requirements to classes is the next shelf. This page stops earlier on purpose. If you draw Ticket, Spot, and ParkingLotManager before park exists as a signature, you will invent helpers that have no caller. The LLD approach is the same walk: clarify, then operations, then types.

Ticket lifecycle — CREATED → ACTIVE → PAID → CLOSED — is not a use case either. It is the biography of one entity after park and exit exist. Model it on object lifecycle once the verbs are named.

Common mistakes

Drawing classes before verbs

ParkingLotManager appears because you needed a box. Start with park and exit. The boxes come from who must carry those verbs. A Manager with no operation behind it is furniture.

Treating every noun as a use case

Floor, Spot, and Money are things in the domain. They are not jobs the user performs. If you cannot put an actor in front of the verb, it is not a use case.

Saving failures for “later”

Lot full and unknown ticket are part of park and exit. If you only write the happy cartoon, the interviewer will ask the failure and you will invent a new class under pressure.

Board check

Can you name every actor without saying “the system”?
Does each job have types in and types out?
Did you write one failure per operation?
Is Stripe still off the board?