Use Case Diagrams

What This Diagram Is For

Before any class exists, someone must answer: who uses this system and what can they do? The use case diagram is that answer drawn as an oval list per actor. It is deliberately low-detail — no flow, no data — making it the requirements-alignment artifact rather than a design one.

Anatomy

                 ┌──────────────────────────────────────┐
                 │              ATM System               │
   ┌──────┐     │   ┌────────────┐                      │
   │Customer│────┼──►│ Withdraw   │◁┄┄«include»┄┄┐       │
   └──┬───┘     │   │ Cash       │              │       │
      │         │   └────────────┘      ┌────────┴─────┐ │
      │         │   ┌────────────┐      │ Authenticate │ │
      │         │   │ Check Bal  │◁┄┄┄┄┘ «included»   │ │
      │         │   └────────────┘      └──────────────┘ │
      │         │   ┌────────────┐                       │
   ┌──┴────┐    │   │ Deposit    │                       │
   │ Bank  │────┼──►│ Cash/Chqs  │                       │
   │Teller │    │   └────────────┘                       │
   └───────┘    │        △                               │
                └────────┼───────────────────────────────┘
                    ┌────┴─────────┐
                    │ Fast Withdraw│ ◁── «extend» of Withdraw Cash
                    └──────────────┘     (optional extra behavior)

• Actor (stick figure): anything outside the boundary interacting with it — humans or external systems (payment gateway, KYC service). Actors are roles, not people; one human may be two actors.
• Use case (oval): a user-visible goal, verb-phrased (“Withdraw Cash”), not a screen or function.
• System boundary box: everything inside is your build scope — drawing it settles scope disputes instantly.

Include vs Extend (the exam classic)

	«include»	«extend»
Meaning	Base case always runs the included one	Extension runs sometimes, conditionally
Arrow direction	base ─▷ included (base points to what it needs)	extension ─▷ base
Example	Withdraw always Authenticates	Fast-withdraw extends Withdraw optionally

Memory hook: include = mandatory subroutine; extend = optional add-on.

When It Earns Its Place in Interviews

Rarely drawn fully in LLD rounds — but naming actors explicitly (“actors: Customer, Admin, PaymentGateway-as-system-actor”) before modeling is high-value and cheap. It surfaces entities (Admin implies admin-only operations), API surface (system actors imply service-to-service endpoints), and out-of-scope clarity.

Writing Good Use Cases

• Goal-level verbs: “Book Ticket” ✓; “Click Submit” ✗ (too small); “Manage System” ✗ (too vague).
• One actor primary per use case; secondary actors (the gateway) sit on the right side.
• Every oval must be traceable to a stated requirement — ovals nobody asked for are scope creep made visible.

Common Mistakes

• Drawing internal components (database, cache) inside the boundary — use cases show behavior, not architecture.
• Actor inheritance misused to mean reporting hierarchy instead of role generalization (RegisteredUser ◁—Guest).
• Confusing «extend» arrow direction — it points from the optional behavior toward the base.