A Use Case Diagram is a UML diagram that shows how users (actors) interact with a system and the functionalities (use cases) it provides. It gives a high-level view of the system from the user's perspective and helps define system requirements and scope.
- Represents actors (users or external systems) and the use cases they interact with.
- Shows relationships between users and system functionalities, making requirements easier to understand.
Example: In an Online Banking System, actors such as Customer and Admin interact with use cases like Login, Check Balance, Transfer Funds, and Manage Accounts.
When to Apply Use Case Diagram?
Use case diagrams are used to understand, analyze, and communicate how users interact with a system.
Requirements Gathering
Used to identify and clarify user requirements and system functionalities.
- Helps understand user needs and expectations.
- Visualizes interactions between users and the system.
Communication with Stakeholders
Provides a simple representation that is easy for both technical and non-technical users to understand.
- Improves communication among stakeholders.
- Makes system functionality easier to explain.
System Design and Planning
Helps define user interactions during the design phase.
- Assists in planning system features and workflows.
- Ensures the design aligns with user requirements.
Defining System Boundaries
Clarifies what is part of the system and what is external to it.
- Identifies actors interacting with the system.
- Helps establish the scope of the system clearly.
Use Case Diagram Notations
UML notations provide a visual language that enables software developers, designers, and other stakeholders to communicate and document system designs, architectures, and behaviors in a consistent and understandable manner.
1. Actors
Actors are external entities that interact with a system to perform specific tasks or achieve goals. They can be users, other systems, or hardware devices that initiate or participate in use cases.
- Actors interact with the system but are not part of the system itself.
- They initiate use cases and receive the results of system operations.
Example: In an ATM System, the Customer is an actor who performs actions such as Withdraw Cash and Check Balance.
.webp)
2. Use Cases
Use Cases represent specific functionalities or services provided by a system to achieve a user's goal. They describe what the system does in response to an actor's interaction and are represented by ovals in a Use Case Diagram.
- Define the actions or functions that the system performs.
- Represent interactions between actors and system functionalities.
Example: In an Online Shopping System, "Place Order", "Track Delivery", and "Update Product Information" are examples of use cases.
3. System Boundary
The System Boundary defines the scope and limits of the system being modeled. It separates the system's internal functionalities from external actors and entities and is usually represented by a rectangular box around the use cases.
- Identifies what is included within the system and what lies outside it.
- Helps clearly define the scope of the system.
Example: In an Online Shopping System, all use cases such as "Place Order" and "Track Delivery" are enclosed within the system boundary, while Customer and Admin remain outside as actors.
Use Case Diagram Relationships
In a Use Case Diagram, relationships play a crucial role in depicting the interactions between actors and use cases.
1. Association Relationship
The Association Relationship represents a communication or interaction between an actor and a use case. It is depicted by a line connecting the actor to the use case. This relationship signifies that the actor is involved in the functionality described by the use case.
Example: Online Banking System
- Actor: Customer
- Use Case: Transfer Funds
- Association: A line connecting the "Customer" actor to the "Transfer Funds" use case, indicating the customer's involvement in the funds transfer process.
.webp)
2. Include Relationship
The Include Relationship indicates that a use case includes the functionality of another use case. It is denoted by a dashed arrow pointing from the including use case to the included use case. This relationship promotes modular and reusable design.
Example: Social Media Posting
- Use Cases: Compose Post, Add Image
- Include Relationship: The "Compose Post" use case includes the functionality of "Add Image." Therefore, composing a post includes the action of adding an image.
3. Extend Relationship
The Extend Relationship illustrates that a use case can be extended by another use case under specific conditions. It is represented by a dashed arrow with the keyword "extend." This relationship is useful for handling optional or exceptional behavior.
Example: Flight Booking System
- Use Cases: Book Flight, Select Seat
- Extend Relationship: The "Select Seat" use case may extend the "Book Flight" use case when the user wants to choose a specific seat, but it is an optional step.
4. Generalization Relationship
The Generalization Relationship establishes an "is-a" connection between two use cases, indicating that one use case is a specialized version of another. It is represented by an arrow pointing from the specialized use case to the general use case.
Example: Vehicle Rental System
- Use Cases: Rent Car, Rent Bike
- Generalization Relationship: Both "Rent Car" and "Rent Bike" are specialized versions of the general use case "Rent Vehicle."
Draw a Use Case diagram in UML
Below are the main steps to draw use case diagram in UML:
Step 1: Identify Actors
Determine who or what interacts with the system. These are your actors. They can be users, other systems, or external entities.
Step 2: Identify Use Cases
Identify the main functionalities or actions the system must perform. These are your use cases. Each use case should represent a specific piece of functionality.
Step 3: Connect Actors and Use Cases
Draw lines (associations) between actors and the use cases they are involved in. This represents the interactions between actors and the system.
Step 4: Add System Boundary
Draw a box around the actors and use cases to represent the system boundary. This defines the scope of your system.
Step 5: Define Relationships
If certain use cases are related or if one use case is an extension of another, you can indicate these relationships with appropriate notations.
Step 6: Review and Refine
Step back and review your diagram. Ensure that it accurately represents the interactions and relationships in your system. Refine as needed.
Step 7: Validate
Share your use case diagram with stakeholders and gather feedback. Ensure that it aligns with their understanding of the system's functionality.
Use Case Diagram example(Online Shopping System)
Let's understand how to draw a Use Case diagram with the help of an Online Shopping System:
- Actors
- Customer
Use Cases
- Browse Products
- Add to Cart
- Checkout
- Manage Inventory (Admin)
Relations
- The Customer can browse products, add items to the cart, and complete the checkout.
- The Admin can manage the inventory
The use case diagram of an Online Shopping System:
Common Use Case Diagram Tools and Platforms
Several tools and platforms are available to create and design Use Case Diagrams. These tools offer features that simplify the diagram creation process, facilitate collaboration among team members, and enhance overall efficiency.
Lucidchart
Cloud-based collaborative platform
- Real-time collaboration and commenting
- Templates for various diagram types
draw.io
Free, open-source diagramming tool
- Works offline and integrates with Google Drive, Dropbox, and others
- Supports a wide range of diagram types, including Use Case Diagrams
Microsoft Visio
Part of the Microsoft Office suite
- Supports various diagram types, including Use Case Diagrams
- Extensive shape libraries and templates
SmartDraw
User-friendly diagramming tool
- Templates for different diagram types, including Use Case Diagrams
- Integration with Microsoft Office and Google Workspace
PlantUML
Open-source tool for creating UML diagrams
- Text-based syntax for diagram specification
- Supports collaborative work using version control systems
Common Mistakes while making Use Case Diagram
Avoiding common mistakes ensures the accuracy and effectiveness of the Use Case Diagram. Here are key points for each mistake:
- Adding too much detail can confuse people.
- Unclear connections lead to misunderstandings about system interactions.
- Different names for the same elements create confusion.
- Incorrectly using generalization can misrepresent relationships.
- Failing to define the system’s limits makes its scope unclear.
- Treating the diagram as static can make it outdated and inaccurate.
Best Practices for Use Case Diagram
Crafting clear and effective Use Case Diagrams is essential for conveying system functionality and interactions. Here are some best practices to consider:
- Use Case Diagram focus on capturing the core functions of the system, avoiding extraneous details.
- They uses a uniform naming scheme for use cases and actors throughout the diagram to enhance clarity and prevent misunderstandings.
- They ensure uniformity in the appearance of elements such as ovals (for use cases), stick figures (for actors), and connecting lines to create a polished presentation.
- They help in organizing use cases into coherent groups that represent distinct modules or subsystems within the overall system.
- Use Case Diagrams adopt an iterative method, updating the diagram as the system changes or as new information emerges.
