Use case diagrams in LLD - System Design Exercise

Design: Use Case Diagram Design

Designing use case diagrams to capture functional requirements and user interactions. Out of scope: detailed class or sequence diagrams.

Functional Requirements

FR1: Identify actors who interact with the system

FR2: Define system use cases representing user goals

FR3: Show relationships between actors and use cases

FR4: Include system boundaries to separate system from external actors

FR5: Support generalization and include/extend relationships between use cases

Non-Functional Requirements

NFR1: Diagram must be clear and easy to understand for non-technical stakeholders

NFR2: Must support scalability to add more actors and use cases without clutter

NFR3: Should be technology-agnostic and focus on user interactions

NFR4: Use standard UML notation for use case diagrams

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Actors (users or external systems)

Use cases (functional goals)

System boundary box

Relationships (associations, include, extend, generalization)

Design Patterns

Include relationship to reuse common behavior

Extend relationship for optional or conditional behavior

Generalization for actor or use case inheritance

Grouping use cases for modularity

Reference Architecture

  +-----------------------------+
  |         System Boundary     |
  |                             |
  |   (Use Case 1) <------------|---- Actor 1
  |   (Use Case 2) <------------|---- Actor 2
  |       ^                     |
  |       |                     |
  |   (Use Case 3) --include-->|
  +-----------------------------+

Actors outside the box, use cases inside the box, arrows show interactions.

Components

Actor

UML notation

Represents a user or external system interacting with the system

Use Case

UML notation

Represents a functional goal or task the system performs for an actor

System Boundary

UML notation

Defines the scope of the system and separates it from external actors

Relationships

UML notation

Shows associations, include, extend, and generalization between actors and use cases

Request Flow

1. 1. Identify all actors who interact with the system.

2. 2. Define use cases representing the goals actors want to achieve.

3. 3. Draw the system boundary box to enclose use cases.

4. 4. Connect actors to use cases with association lines.

5. 5. Use include relationships to factor out common behavior.

6. 6. Use extend relationships for optional or conditional behavior.

7. 7. Use generalization to show inheritance among actors or use cases.

8. 8. Review diagram for clarity and completeness.

Database Schema

Not applicable for use case diagrams as they are behavioral models focusing on interactions.

Scaling Discussion

Bottlenecks

Diagram becomes cluttered with many actors and use cases

Difficulty in maintaining clarity as system complexity grows

Hard to represent detailed behavior or data flow

Solutions

Group related use cases into packages or modules

Use multiple diagrams to separate different system parts or user roles

Limit scope per diagram to keep it understandable

Combine with other UML diagrams (sequence, activity) for detailed behavior

Interview Tips

Time: Spend 10 minutes explaining use case diagram basics, 15 minutes drawing a sample diagram, 10 minutes discussing extensions and scaling.

Explain purpose of use case diagrams to capture user goals

Describe actors and system boundary clearly

Show how include and extend relationships improve reuse and clarity

Discuss how diagrams help communication with non-technical stakeholders

Mention limitations and when to use complementary diagrams

Practice

1. What is the primary purpose of a use case diagram in system design?

easy

A. To show user roles and their interactions with the system

B. To display database table relationships

C. To illustrate the internal code structure

D. To list all system hardware components

Solution

1. Step 1: Understand the role of use case diagrams

   Use case diagrams focus on users (actors) and what they do with the system (use cases).

2. Step 2: Compare with other diagram types

   Database diagrams show tables, code diagrams show code structure, hardware diagrams show physical parts, none are use case diagrams.

3. Final Answer:

   To show user roles and their interactions with the system -> Option A

4. Quick Check:

   Use case diagram = user roles + actions [OK]

Hint: Use case = users + actions, not code or hardware [OK]

Common Mistakes:

• Confusing use case diagrams with class or sequence diagrams
• Thinking use case diagrams show database details
• Assuming use case diagrams show internal code logic

2. Which of the following is the correct symbol for an actor in a use case diagram?

easy

A. A rectangle with the actor's name inside

B. An oval shape showing a system function

C. A stick figure representing a user

D. A diamond shape indicating a decision

Solution

1. Step 1: Identify actor symbol in use case diagrams

   Actors are shown as stick figures to represent users or external systems.

2. Step 2: Differentiate other symbols

   Ovals represent use cases (functions), rectangles can be system boundaries, diamonds are for decisions in flowcharts, not use case diagrams.

3. Final Answer:

   A stick figure representing a user -> Option C

4. Quick Check:

   Actor symbol = stick figure [OK]

Hint: Actors are stick figures, use cases are ovals [OK]

Common Mistakes:

• Using rectangles for actors instead of stick figures
• Confusing use case ovals with actor symbols
• Mixing flowchart symbols with use case diagram symbols

3. Consider a use case diagram with actors Customer and Admin, and use cases Place Order, Cancel Order, and Update Inventory. Which use case should only be connected to the Admin actor?

medium

A. Place Order

B. Cancel Order

C. Place Order and Cancel Order

D. Update Inventory

Solution

1. Step 1: Analyze actor responsibilities

   Customers place and cancel orders; Admin manages inventory updates.

2. Step 2: Match use cases to actors

   Only Admin should connect to Update Inventory as it is a system management task.

3. Final Answer:

   Update Inventory -> Option D

4. Quick Check:

   Admin-only use case = Update Inventory [OK]

Hint: Admin manages system tasks, customers do orders [OK]

Common Mistakes:

• Connecting customers to inventory updates
• Assuming customers can update system data
• Linking all use cases to all actors

4. A use case diagram shows an actor connected to a use case with a dashed arrow labeled <<extend>>. What does this indicate?

medium

A. The extended use case adds optional behavior to the base use case

B. The actor is not allowed to perform the extended use case

C. The actor must always perform the extended use case

D. The use case is a system boundary

Solution

1. Step 1: Understand <<extend>> relationship

   The <<extend>> arrow shows optional or conditional behavior added to a base use case.

2. Step 2: Interpret actor connection meaning

   The actor can perform the base use case; the extended use case happens only sometimes.

3. Final Answer:

   The extended use case adds optional behavior to the base use case -> Option A

4. Quick Check:

   <<extend>> = optional behavior [OK]

Hint: <<extend>> means optional addition, not mandatory [OK]

Common Mistakes:

• Thinking <<extend>> means mandatory action
• Confusing <<extend>> with <<include>>
• Assuming <<extend>> defines system boundaries

5. You are designing a use case diagram for an online library system. Which of the following best represents a correct use case for the Member actor that includes an Admin actor managing the system?

hard

A. Member: Add Book, Remove Book; Admin: Borrow Book, Return Book

B. Member: Borrow Book, Return Book; Admin: Add Book, Remove Book

C. Member: Borrow Book, Add Book; Admin: Remove Book, Return Book

D. Member: Remove Book, Return Book; Admin: Borrow Book, Add Book

Solution

1. Step 1: Identify typical member actions

   Members usually borrow and return books, not manage inventory.

2. Step 2: Identify admin responsibilities

   Admins add or remove books to keep the library updated.

3. Step 3: Match actions to actors correctly

   Member: Borrow Book, Return Book; Admin: Add Book, Remove Book correctly assigns borrowing and returning to Member, and adding/removing to Admin.

4. Final Answer:

   Member: Borrow Book, Return Book; Admin: Add Book, Remove Book -> Option B

5. Quick Check:

   Member = borrow/return, Admin = add/remove [OK]

Hint: Members use books; Admins manage books [OK]

Common Mistakes:

• Swapping member and admin roles
• Assigning management tasks to members
• Mixing use cases between actors