Comprehensive Tutorial on Use Case Diagrams

Introduction

A use case diagram is a type of behavioral diagram defined by the Unified Modeling Language (UML). It is used to describe the interactions between users (actors) and a system to achieve specific goals. Use case diagrams are essential for understanding and documenting the functional requirements of a system from the user’s perspective. This tutorial will guide you through creating and understanding use case diagrams, using the Wheels bike hire system as an example.

What is a Use Case Diagram?

A use case diagram consists of the following key components:

1. Actors: Represent users or external systems that interact with the system. Actors can be humans, other systems, or hardware devices.
2. Use Cases: Represent specific functionalities or services that the system provides to the actors. Each use case describes a goal that an actor wants to achieve by interacting with the system.
3. Relationships:
   • Communication Association: A line connecting an actor to a use case, indicating that the actor participates in that use case.
   • Include: A relationship between use cases where one use case includes the behavior of another.
   • Extend: A relationship between use cases where one use case extends the behavior of another under certain conditions.

Creating a Use Case Diagram

Step 1: Identify Actors

Identify all the actors that will interact with the system. For the Wheels bike hire system, the actors are:

• Administrator
• Receptionist

Step 2: Identify Use Cases

Identify the main functionalities or services that the system provides. Each use case should represent a specific goal that an actor wants to achieve. For the Wheels system, the use cases are:

• Maintain bike list
• Maintain customer list
• Handle enquiries
• Issue bike
• Handle bike return
• Find bike
• Print receipt

Step 3: Draw the Use Case Diagram

1. Draw Actors: Represent actors as stick figures.
2. Draw Use Cases: Represent use cases as ovals.
3. Connect Actors and Use Cases: Use lines to connect actors to the use cases they participate in.
4. Add Relationships: Use dashed arrows to represent “include” and “extend” relationships.

Example: Wheels Bike Hire System

Let’s create a use case diagram for the Wheels bike hire system based on the provided image.

Actors:

• Administrator
• Receptionist

Use Cases:

• Maintain bike list
• Maintain customer list
• Handle enquiries
• Issue bike
• Handle bike return
• Find bike
• Print receipt

Use Case Diagram:

Explanation:

1. Actors:
   • Administrator (adm)
   • Receptionist (rec)
2. Use Cases:
   • Maintain bike list (UC1)
   • Maintain customer list (UC2)
   • Handle enquiries (UC3)
   • Issue bike (UC4)
   • Handle bike return (UC5)
   • Find bike (UC6)
   • Print receipt (UC7)
3. Relationships:
   • The Receptionist is involved in Handle enquiries, Issue bike, and Handle bike return.
   • The Administrator is involved in Maintain bike list and Maintain customer list.
   • The Issue bike use case includes the Handle enquiries use case.
   • The Handle bike return use case includes the Print receipt use case.
   • The Issue bike use case extends the Maintain customer list use case.
   • The Find bike use case is included in Maintain bike list, Maintain customer list, Handle enquiries, and Issue bike.

Use Case Descriptions

In addition to the diagram, it’s important to document the use cases with descriptions. A use case description typically includes:

1. Use Case Name: The name of the use case.
2. Actors: The actors involved in the use case.
3. Goal: The goal or purpose of the use case.
4. Overview: A brief description of what happens in the use case.
5. Typical Course of Events: A step-by-step description of the normal flow of events.
6. Alternative Courses: Descriptions of any alternative or exceptional flows of events.

Example: Issue Bike Use Case Description

Use Case: Issue bike

Actors: Receptionist

Goal: To hire out a bike

Overview: When a customer comes into the shop, they choose a bike to hire. The Receptionist looks up the bike on the system and tells the customer how much it will cost to hire the bike for a specified period. The customer pays, is issued with a receipt, and then leaves with the bike.

Typical Course of Events:

1. The customer chooses a bike.
2. The Receptionist keys in the bike number.
3. The system displays the bike details, including the daily hire rate and deposit.
4. The customer specifies the length of hire.
5. The Receptionist keys in the length of hire.
6. The system displays the total hire cost.
7. The customer agrees to the price.
8. The Receptionist keys in the customer details.
9. The system displays the customer details.
10. The customer pays the total cost.
11. The Receptionist records the amount paid.
12. The system prints a receipt.

Alternative Courses:

• Steps 8 and 9: The customer details are already in the system, so the Receptionist needs only to key in an identifier, and the system will display the customer details.
• Steps 7-12: The customer may not be happy with the price and may terminate the transaction.

Issue Bike Use Case: Detailed Explanation

The “Issue Bike” use case in the Wheels bike hire system represents the process of hiring out a bike to a customer. This use case involves several interactions between the Receptionist and the system to achieve the goal of issuing a bike. Below, we will explain the flow of events in the “Issue Bike” use case and how it relates to the “include” and “extend” use cases.

Actors:

• Receptionist: The primary actor who interacts with the system to issue a bike.

Goal:

• To hire out a bike to a customer.

Overview:

When a customer comes into the shop, they choose a bike to hire. The Receptionist looks up the bike on the system and tells the customer how much it will cost to hire the bike for a specified period. The customer pays, is issued with a receipt, and then leaves with the bike.

Typical Course of Events:

1. Customer Chooses a Bike: The customer selects a bike from the available options.
2. Receptionist Keys in the Bike Number: The Receptionist enters the bike number into the system.
3. System Displays Bike Details: The system shows the bike details, including the daily hire rate and deposit.
4. Customer Specifies Length of Hire: The customer indicates how long they want to hire the bike.
5. Receptionist Keys in the Length of Hire: The Receptionist enters the hire duration into the system.
6. System Displays Total Hire Cost: The system calculates and displays the total cost of hiring the bike.
7. Customer Agrees to the Price: The customer confirms that they agree to the hire cost.
8. Receptionist Keys in Customer Details: The Receptionist enters the customer’s details into the system.
9. System Displays Customer Details: The system shows the entered customer details for verification.
10. Customer Pays the Total Cost: The customer makes the payment.
11. Receptionist Records the Amount Paid: The Receptionist records the payment in the system.
12. System Prints a Receipt: The system generates and prints a receipt for the customer.

Relationships with Other Use Cases:

1. Include Relationships:
   • Handle Enquiries: The “Issue Bike” use case includes the “Handle Enquiries” use case. This means that whenever a bike is issued, the system must handle enquiries about the bike’s availability and cost. The flow of events in the “Issue Bike” use case will always involve handling enquiries.
   • Find Bike: The “Issue Bike” use case includes the “Find Bike” use case. This means that the Receptionist will use the system to find the bike details based on the bike number entered. This is a necessary step in issuing a bike.
2. Extend Relationships:
   • Maintain Customer List: The “Issue Bike” use case extends the “Maintain Customer List” use case. This means that during the process of issuing a bike, the system may need to add a new customer or update existing customer details. This extension is conditional and occurs only when necessary.

Flow of Events with Include and Extend Use Cases:

1. Customer Chooses a Bike: The customer selects a bike.
2. Receptionist Keys in the Bike Number: The Receptionist enters the bike number.
   • Include: Find Bike: The system finds the bike details based on the entered number.
3. System Displays Bike Details: The system shows the bike details, including the daily hire rate and deposit.
   • Include: Handle Enquiries: The system handles enquiries about the bike’s availability and cost.
4. Customer Specifies Length of Hire: The customer indicates the hire duration.
5. Receptionist Keys in the Length of Hire: The Receptionist enters the hire duration.
6. System Displays Total Hire Cost: The system calculates and displays the total hire cost.
7. Customer Agrees to the Price: The customer confirms the hire cost.
8. Receptionist Keys in Customer Details: The Receptionist enters the customer’s details.
   • Extend: Maintain Customer List: If the customer is new or if their details need to be updated, the system will add or update the customer information.
9. System Displays Customer Details: The system shows the entered customer details for verification.
10. Customer Pays the Total Cost: The customer makes the payment.
11. Receptionist Records the Amount Paid: The Receptionist records the payment.
12. System Prints a Receipt: The system generates and prints a receipt for the customer.

The “Issue Bike” use case is a comprehensive process that involves several interactions between the Receptionist and the system. The use of “include” relationships with the “Find Bike” and “Handle Enquiries” use cases ensures that the necessary steps of finding bike details and handling enquiries are always performed. The “extend” relationship with the “Maintain Customer List” use case allows for the conditional addition or updating of customer details, providing flexibility in the bike issuing process. Understanding these relationships helps in creating a robust and user-centric system that effectively meets the functional requirements of the Wheels bike hire system.

Conclusion

Use case diagrams are essential tools in the software development process, particularly within the realm of object-oriented development. They provide a clear and concise visual representation of how users (actors) interact with a system to achieve specific goals (use cases). By identifying actors, use cases, and their relationships, developers can effectively model and communicate the functional requirements of a system.

In the context of the Wheels bike hire system, we have demonstrated how to create use case diagrams that capture the interactions between different actors (Receptionist and Administrator) and the system’s functionalities (such as maintaining bike and customer lists, handling enquiries, issuing bikes, and handling bike returns). We have also shown how to incorporate relationships like “include” and “extend” to represent common and additional behaviors, respectively.

The use case diagrams, along with their descriptions, serve as a foundation for further development activities, including the creation of other UML models and the eventual implementation of the system. By following the steps outlined in this tutorial, developers can ensure that they have a comprehensive understanding of the system’s requirements and can effectively communicate these requirements to stakeholders.

In summary, mastering the creation and interpretation of use case diagrams is crucial for any software developer aiming to build robust, user-centric systems. With practice, these diagrams become invaluable tools for modeling, documenting, and validating the functional requirements of any software project.