Use Case Diagrams in Interviews: Common Questions

Use case diagrams frequently appear in LLD interviews as a requirements elicitation tool. Here are patterns, gotchas, and strategies for handling common interview scenarios.
Common Interview Questions:

Question 1: "Draw a use case diagram for an elevator system."
Strategy: Identify actors first (Passenger, Maintenance Staff, Emergency Services). Then list user goals (Request Floor, Open Door, Emergency Stop, Schedule Maintenance). Connect actors to use cases. Discuss whether Door Control should be separate or included in Request Floor.

Question 2: "How would you model optional features in use cases?"
Answer: Use <<extend>> relationships. Example: "Borrow Book" can be extended by "Place Hold" when the book is unavailable. The extension point is conditional: only when book.isAvailable == false. But if Y (the feature is always required like authentication), then use <<include>> instead.

Question 3: "When would you have two actors connected to the same use case?"
Answer: When multiple roles can initiate the same functionality through different interfaces. Example: In a library system, both Member (via self-service kiosk) and Librarian (via staff terminal) can initiate "Check Out Book". The use case logic is identical, but access methods differ.
Interview Tip: Always verbalize your thought process when drawing use case diagrams. Say: "I'm placing Payment Gateway outside the system boundary because it's an external actor that the system integrates with." This shows you understand boundaries and component separation.
Machine Coding Considerations:

First, Use case diagrams inform class identification. Each use case often maps to a service or manager class. "Park Vehicle" becomes ParkingService.parkVehicle().

Second, Actors map to user roles or external interfaces. Customer actor becomes Customer class. Payment Gateway actor becomes IPaymentGateway interface with implementations like StripeGateway.

Third, <<include>> relationships suggest composition. If "Pay Fee" includes "Process Payment", then PaymentService composes PaymentProcessor.

Fourth, <<extend>> relationships suggest strategy pattern or decorators. "Dispense Product" extended by "Apply Discount" can use a decorator chain of pricing strategies.
Common Mistakes to Avoid:

Mistake: Including implementation details in use case names like "Query Database for Available Spots"
Fix: Use user-goal phrasing: "Find Available Spots". The database query is implementation detail.

Mistake: Making every actor interact with every use case
Fix: Respect role-based access. Admin shouldn't connect to "Park Vehicle". Customer shouldn't connect to "Generate Report".

Mistake: Drawing use cases for internal system operations like "Update Database" or "Log Event"
Fix: Use cases represent user-visible functionality. Internal operations are implementation details, not use cases.

Mistake: Confusing actors with classes. Drawing "Vehicle" as an actor when it's actually a data entity
Fix: Actors initiate actions. Vehicle is passive data. The Customer who owns the vehicle is the actor.
Interview Tip: If the interviewer says "Let's skip the use case diagram and go straight to classes," respectfully ask: "Could I spend 30 seconds identifying the main actors and use cases? It helps me understand the requirements before designing classes." This shows requirements discipline without slowing the interview.
Advanced Scenarios:
Temporal Actors: How do you model scheduled tasks? Create an actor called "System Timer" or "Scheduler" that initiates time-based use cases like "Generate Daily Report" or "Expire Reservations". But if Y (the scheduling is purely internal with no external trigger), then you might question whether it needs use case representation at all.
Nested System Boundaries: What if your parking lot system integrates with a payment system you also design? You can nest boundaries: outer boundary for the complete system, inner boundaries for subsystems. But if Y (this creates visual clutter), then separate diagrams for each subsystem are cleaner, showing integration points with actor relationships.
Variations and Extension Points: In complex use cases with multiple conditional paths, specify extension points with conditions. Example: "Borrow Book" has extension point [book unavailable] where "Place Hold" extends it. But if Y (you have many extension points), then the use case is too complex and should be decomposed or modeled with an activity diagram showing branching logic.
Security Use Cases: Should authentication be a use case? Yes, if users explicitly log in. Model "Authenticate User" as a use case included by other protected use cases. But if Y (authentication is transparent like session tokens), then it's an implementation detail, not a user-facing use case. However, "Reset Password" is definitely a use case because users initiate it.

💡 Key Takeaways

✓Use case diagrams inform initial class and interface identification in machine coding

✓Actors map to user roles (classes) or external systems (interfaces)

✓Use cases typically become service methods or use case handler classes

✓<<include>> relationships suggest composition in code

✓<<extend>> relationships suggest strategy pattern or decorators

✓Always identify actors and use cases before jumping to class design

✓Avoid implementation details in use case names and focus on user goals

📌 Examples

1Elevator interview: Actors are Passenger and Maintenance Staff with use cases Request Floor and Schedule Maintenance

2Library interview: Member and Librarian both connect to Check Out Book use case

3Parking Lot machine coding: ParkingService.parkVehicle() implements Park Vehicle use case

4Payment Gateway actor becomes IPaymentGateway interface in code

← Back to Use Case Diagrams Overview