Use case diagrams in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Identify the primary actor in a use case diagram

In a use case diagram for an online bookstore, which of the following is the primary actor?

A The customer who buys books

B The database storing book information

C The payment gateway service

D The server hosting the website

💡 Hint

Think about who initiates the interaction with the system.

The primary actor is the user or entity that interacts directly with the system to achieve a goal. Here, the customer is the primary actor because they initiate buying books.

❓ Architecture

intermediate

Determine the correct use case relationship

Which option correctly describes the include relationship in use case diagrams?

A Actors inherit behaviors from other actors

B A use case always calls another use case to reuse its behavior

C Two use cases are unrelated and independent

D A use case extends another use case optionally

💡 Hint

Consider which relationship means mandatory reuse of behavior.

The include relationship means one use case always uses the behavior of another use case to avoid repetition.

❓ scaling

advanced

Scaling use case diagrams for large systems

When designing use case diagrams for a large banking system, which approach best helps manage complexity?

A Only model the most important use cases and ignore others

B Create one large use case diagram with all actors and use cases

C Divide the system into subsystems and create separate use case diagrams for each

D Use sequence diagrams instead of use case diagrams

💡 Hint

Think about how to keep diagrams clear and understandable.

Dividing into subsystems and creating separate diagrams keeps each diagram focused and easier to understand.

❓ tradeoff

advanced

Tradeoffs in actor identification

What is a common tradeoff when deciding how many actors to include in a use case diagram?

A More actors make the diagram simpler but less detailed

B Fewer actors reduce clarity but increase diagram size

C Actors do not affect diagram complexity

D Too many actors can clutter the diagram and confuse readers

💡 Hint

Consider how visual clutter affects understanding.

Including too many actors can make diagrams crowded and hard to read, reducing their usefulness.

❓ component

expert

Analyzing request flow from use case to system components

In a use case diagram for a ride-sharing app, the 'Request Ride' use case involves the Rider actor and triggers several system components. Which sequence best represents the request flow from the actor to components?

A Rider → Authentication Service → Ride Matching Service → Payment Service

B Rider → Ride Matching Service → Authentication Service → Payment Service

C Rider → Payment Service → Ride Matching Service → Authentication Service

D Rider → Payment Service → Authentication Service → Ride Matching Service

💡 Hint

Think about the logical order of verifying identity, matching rides, then processing payment.

The rider must first be authenticated, then the system matches a driver, and finally processes payment.

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