Use Case Diagrams: When to Use and Trade-offs
Use case diagrams are powerful for requirements elicitation but have specific contexts where they excel and scenarios where alternatives are better. Understanding these trade-offs is critical for LLD interviews.
Second, Systems with multiple user roles and diverse interactions
Third, Stakeholder communication when non-technical audiences need clarity
Fourth, Initial design discussions before detailed class modeling
Second, Data structure design (use class diagrams)
Third, Algorithm specification (use pseudocode)
Fourth, Real-time system constraints (use state machine diagrams)
Oversimplification: Use case diagrams show what happens, not how. "Process Payment" doesn't reveal the validation, authorization, and settlement steps. But if Y (workflow details matter for implementation), then follow up with sequence diagrams showing message flows between objects.
Relationship Confusion: Teams often misuse <<include>> and <<extend>>. Remember: include is mandatory (always happens), extend is conditional (sometimes happens). But if Y (you're unsure), then avoid these relationships initially and use simple associations until requirements clarify.
Actor Granularity: Too many actors create clutter (Regular Customer, Premium Customer, VIP Customer). Too few lose important distinctions. But if Y (roles share 80%+ behavior), then use actor generalization with a parent actor and specialized children.
Use Case Diagrams vs Class Diagrams: Use case diagrams capture functional requirements (user goals), while class diagrams capture structural design (entities and relationships). In interviews, start with use cases to understand scope, then move to classes. But if Y (the problem is data-centric like a database schema), then class diagrams are more appropriate initially.
Use Case Diagrams vs Sequence Diagrams: Use cases show which functionalities exist. Sequence diagrams show how objects collaborate to implement them. Use cases answer "What features?", sequences answer "What order?". But if Y (the interviewer asks about object interactions), then transition from use case to sequence immediately.
Use Case Diagrams vs User Stories: User stories ("As a customer, I want to park my vehicle so that I can attend my appointment") capture requirements in Agile format. Use case diagrams visualize these graphically with relationships. But if Y (your team prefers textual formats), then user stories with acceptance criteria may suffice without diagrams.
When Use Case Diagrams are Overkill:
Simple CRUD Applications: If the system is just Create, Read, Update, Delete operations on entities, use case diagrams add little value. A class diagram with service methods is clearer. But if Y (even CRUD systems have complex business rules like "only authors can delete their own posts"), then use cases help clarify access control requirements.
Internal Libraries or Utilities: Designing a HashMap implementation or sorting algorithm doesn't need use case diagrams. These are algorithmic challenges without user roles. But if Y (you're designing a library management system that uses these utilities), then use cases apply to the system level, not the utility level.
Single-Actor Systems: A personal calculator app with one user type needs no use case diagram. But if Y (the calculator has scientific mode, programmer mode, and graphing mode), then use cases can clarify feature sets even with one actor.
Real-Time Embedded Systems: Systems driven by hardware interrupts and state transitions (elevator control logic, traffic lights) are better modeled with state machine diagrams. But if Y (you need to capture user interactions like "Passenger presses button"), then use cases model the user-facing portion while state machines model the control logic.