A Use Case Diagram is a vital tool in system design, it provides a visual

representation of how users interact with a system. It serves as a

blueprint for understanding the functional requirements of a system from
a user’s perspective, aiding in the communication between stakeholders
and guiding the development process.
What is a Use Case?
A use case is a specific sequence of interactions between an external actor
and a system that results in a measurable outcome. These interactions are
depicted in the Use Case Diagram, outlining the essential functionalities and
behaviors of the system as experienced by the user.
Actors
Actors are external entities that interact with the system. These can include
users, other systems, or hardware devices. In the context of a Use Case
Diagram, actors initiate use cases and receive the outcomes. Proper
identification and understanding of actors are crucial for accurately
modeling system behavior.

Relationships Between Actors and Use Cases

The relationships between actors and use cases are crucial for illustrating
the dynamics of system interactions:
• Association: Represented by a line connecting an actor to a use
case, it signifies the communication or interaction between the
actor and the use case.
• Include Relationship: Indicated by a dashed arrow, it signifies that
a use case includes the functionality of another use case, providing
a modular and reusable design.
• Extend Relationship: Denoted by a dashed arrow with an “extend”
keyword, it demonstrates that a use case can be extended by
another use case under specific conditions.
Types of Relationships
In a Use Case Diagram, relationships play a crucial role in depicting the
interactions between actors and use cases. These relationships provide a
comprehensive view of the system’s functionality and its various scenarios.
Let’s delve into the key types of relationships and explore examples to
illustrate their usage.
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.
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.
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.
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.”
Dependency Relationship
The Dependency Relationship indicates that changes in one use case may
affect another. It is represented by a dashed line with an arrow pointing
from the dependent use case to the independent use case.
Example: Document Management System
• Use Cases: Create Document, Print Document
• Dependency Relationship: The “Print Document” use case
depends on the existence of a created document. Changes in the
“Create Document” use case may affect the “Print Document” use
case.
Use Case Notation
Various graphical elements are used in a Use Case Diagram to represent
different entities and relationships:
• Oval: Represents a use case.
• Stick Figure: Represents an external actor.
• Dashed Line: Indicates an association.
• Solid Line with Arrowhead: Represents an “include” relationship.
• Dashed Line with Arrowhead: Denotes an “extend” relationship.
System Boundary
The System Boundary in a Use Case Diagram is a visual element that
defines the scope of the system and separates its internal components from
external entities, such as actors. It is represented by a box that encloses all
the use cases of the system. The system boundary helps to clarify what is
considered part of the system and what lies outside of it.
Purpose of System Boundary:
• Scope Definition: It clearly outlines the boundaries of the system,
indicating which components are internal to the system and which
are external actors or entities interacting with the system.
• Focus on Relevance: By delineating the system’s scope, the
diagram can focus on illustrating the essential functionalities
provided by the system without unnecessary details about
external entities.
Notation:
The system boundary is typically represented by a rectangular box that
surrounds all the use cases of the system. The use cases and actors are
placed inside this box, while external entities, not part of the system, are
positioned outside.
Use Case Diagram Examples
Library Management System
Actors:
• Librarian
• Member
Use Cases:
1. Search for a Book
2. Check Out a Book
3. Return a Book
4. Manage Member Information
5. Manage Book Information
Relations:
• The Librarian can perform all the use cases.
• The Member can search for a book, check out a book, and return a
book.
Online Shopping System
Actors:
• Customer
• Admin
Use Cases:
1. Browse Products
2. Add to Cart
3. Checkout
4. Manage Inventory (Admin)
Relations:
• The Customer can browse products, add to the cart, and complete
the checkout.
• The Admin can manage the inventory.
Use Case Diagram Best Practices
Creating effective and clear Use Case Diagrams is crucial for communicating
system functionality and interactions. Here are some best practices to
follow:
Keep it Simple:
• Focus on High-Level Functionality: Avoid unnecessary details and
concentrate on representing the system’s primary functionalities.
• Use Concise Language: Use clear and concise language for use
case and actor names to enhance readability.
Consistency:
• Naming Conventions: Maintain a consistent naming convention for
use cases and actors throughout the diagram. This promotes
clarity and avoids confusion.
• Formatting Consistency: Keep a consistent format for elements
like ovals (use cases), stick figures (actors), and lines to maintain a
professional look.
Use Colors Sparingly:
• Enhance Readability: While color can enhance readability, use it
sparingly to avoid overwhelming the diagram. Reserve color for
specific purposes, such as highlighting critical elements.
Organize and Align:
• Logical Grouping: Organize use cases into logical groups to
represent different modules or subsystems within the system.
• Alignment: Maintain proper alignment of elements to make the
diagram visually appealing and easy to follow.
Prioritize Use Cases:
• Essential Functionality First: Place the most critical and
commonly used use cases prominently. This helps stakeholders
quickly understand the primary system functions.
Include Actors Strategically:
• Relevant Actors Only: Include actors that are directly involved in
system interactions. Exclude irrelevant actors to avoid clutter.
Use Proper Notation:
• Consistent Symbols: Adhere to standard symbols for actors (stick
figures), use cases (ovals), and relationships to ensure
understanding.
• Proper Line Types: Clearly distinguish between association,
include, extend, and generalization relationships using appropriate
line types.
Review and Iterate:
• Feedback Loop: Regularly review the diagram with stakeholders
to ensure accuracy and completeness.
• Iterative Process: Use an iterative process, updating the diagram
as the system evolves or more information becomes available.
Add Brief Descriptions:
• Use Case Descriptions: Include brief descriptions for complex or
critical use cases to provide additional context and understanding.
Validate with Stakeholders:
• Stakeholder Involvement: Collaborate with stakeholders to
validate the accuracy of the diagram, ensuring that it aligns with
their understanding of system requirements.
By following these best practices, you can create Use Case Diagrams that
effectively communicate the essential aspects of a system, fostering a
shared understanding among stakeholders and facilitating the development
process.
d