Jinal Desai

My thoughts and learnings

Mastering UML Diagrams: Behavioral Diagrams – Use Case Diagrams

Mastering UML Diagrams: Behavioral Diagrams – Use Case Diagrams
  1. Mastering UML Diagrams – Introduction to UML
  2. Mastering UML Diagrams: Structural Diagrams – Class Diagrams
  3. Mastering UML Diagrams: Structural Diagrams – Object Diagrams
  4. Mastering UML Diagrams: Structural Diagrams – Component Diagrams
  5. Mastering UML Diagrams: Structural Diagrams – Deployment Diagrams
  6. Mastering UML Diagrams: Structural Diagrams – Package Diagrams
  7. Mastering UML Diagrams: Behavioral Diagrams – Use Case Diagrams
  8. Mastering UML Diagrams: Behavioral Diagrams – Sequence Diagrams
  9. Mastering UML Diagrams: Behavioral Diagrams – Activity Diagrams
  10. Mastering UML Diagrams: Behavioral Diagrams – State Machine Diagrams
  11. Mastering UML Diagrams: Behavioral Diagrams – Communication Diagrams
  12. Mastering UML Diagrams: Interaction Diagrams – Timing Diagrams
  13. Mastering UML Diagrams: Interaction Diagrams – Interaction Overview Diagrams
  14. Mastering UML Diagrams: Advanced UML Topics


Welcome to the seventh installment of our “Mastering UML Diagrams” series. In this article, we delve into one of the most critical aspects of UML modeling: Use Case Diagrams. These diagrams are pivotal for capturing and visualizing the functional requirements of a system, bridging the gap between system design and user expectations. We’ll explore every facet of Use Case Diagrams, from their fundamentals to advanced concepts. 

Introduction to Use Case Diagrams

Understanding Use Case Diagrams

Use Case Diagrams are visual representations of a system’s functionality, focusing on how the system interacts with its external entities, known as actors. They provide a high-level view of a system’s behavior, answering the question, “What does the system do?” Use Case Diagrams are instrumental in UML because they emphasize the system’s behavior, complementing other diagrams that emphasize structure and interactions.

Role in UML

The role of Use Case Diagrams in UML is pivotal:

– Functional Requirements: Use Case Diagrams are the go-to tool for capturing functional requirements from a user’s perspective.
– Communication: They facilitate effective communication between stakeholders, ensuring everyone has a shared understanding of the system’s behavior.
– Design Foundation: Use Case Diagrams serve as the foundation for system design and development, guiding the creation of software that meets user needs.

Use Case Symbols and Notations

Symbols and Notations Explained

Use Case Diagrams employ various symbols and notations to represent system elements:

– Actor: Actors, often depicted as stick figures, represent external entities interacting with the system.
– Use Case: Use cases, represented by ovals, signify specific functionalities or tasks that the system can perform.
– Association: Associations, depicted by lines connecting actors to use cases, indicate interactions between actors and use cases.
– System Boundary: A boundary box encloses use cases, demarcating the system from external entities.


Actors in Use Case Diagrams


Unpacking Actors

Actors are central to Use Case Diagrams:

– Definition: Actors represent entities, roles, or external systems interacting with the system under consideration.
– Significance: Actors define the “who” in user requirements, ensuring that the system aligns with user expectations.
– Primary vs. Secondary Actors: Primary actors initiate interactions with the system, while secondary actors are impacted by the system but don’t initiate interactions.

Actor Interaction

Actors interact with use cases in meaningful ways:

– Association: The association lines between actors and use cases clarifies specific user-system interactions, mapping out the system’s functionality from an external perspective.

Use Cases and Scenarios

Understanding Use Cases

Use cases are the core elements of Use Case Diagrams:

– Definition: Each use case represents a discrete functionality or task that the system can execute.
– Importance: Use cases are pivotal for capturing user requirements and defining the system’s intended behavior.
– Creating Use Cases: Use cases are named and briefly described to convey their purpose clearly.

Use Cases and Actors

Use cases often involve interactions with actors:

– Use Case Relationships: The connections between actors and use cases specify which actors are involved in the execution of a particular use case.
– Scenarios: Scenarios provide detailed descriptions of how the system behaves within specific conditions or situations, enhancing the depth and clarity of use cases.







Use Case Relationships

Exploring Relationship Types

Use cases can have various relationships, influencing the system’s behavior:

– Includes: The “includes” relationship allows one use case to encompass the behavior of another, representing shared or common functionality.
– Extends: The “extends” relationship signifies that one use case can extend to another under specific conditions or exceptional circumstances.
– Generalization: Use case generalization establishes a hierarchy where one-use case inherits behavior from another, similar to class inheritance in object-oriented programming.
– Association: Associations link actors to use cases, illustrating which actors interact with which use cases.


Choosing the Right Relationship

Selecting the appropriate relationship is crucial:

– Includes and Extends: Use “includes” for mandatory behavior shared among use cases, and “extends” for optional or exceptional behavior.
– Generalization: Employ generalization when use cases share common behavior but have additional specific behavior.
– Association: Associations demonstrate straightforward actor-use case interactions.

Impact on System Behavior

The relationships between use cases significantly impact the system’s behavior, ensuring that it behaves as intended across various scenarios.

Real life examples

Example 1: ATM (Automated Teller Machine) Use Case Diagram



  • Actors: In this diagram, we have four actors – Customer, Bank, Cashier, and ATM Operator. The Customer interacts with the ATM for various tasks, the Bank handles the banking operations, the Cashier assists with in-person transactions, and the ATM Operator maintains the ATM.
  • Use Cases: Use cases represent actions or functionalities. Customers can perform actions like withdrawing money, checking their balance, transferring funds, and changing their PIN. The Cashier can deposit money, withdraw money, and check balances for customers. The ATM Operator is responsible for maintaining the ATM.
  • Relationships: The diagram illustrates how actors and use cases are related. For example, the Customer can “Withdraw Money,” and this use case involves a communication link with the Bank to request a withdrawal.

Example 2: Online Shopping Use Case Diagram



  • Actors: In this diagram, we have three actors – Customer, Online Shop, and Payment Gateway. The Customer shops online, the Online Shop manages products and orders, and the Payment Gateway handles payment processing.
  • Use Cases: Use cases represent actions or functionalities. Customers can perform actions like browsing products, adding/removing items from the cart, proceeding to checkout, and making payments. The Online Shop can manage products and orders. Payment processing is performed by the Payment Gateway when the Customer chooses to proceed to checkout.
  • Relationships: The diagram shows how actors interact with use cases. For example, when a Customer chooses “Proceed to Checkout,” it involves a communication link with the Payment Gateway to process the payment.


Use Case Diagrams are indispensable for capturing and visualizing functional requirements, fostering effective stakeholder communication, and guiding system design and development. By mastering symbols, actors, use cases, and relationships within Use Case Diagrams, you can create models that align precisely with user needs and expectations. Stay tuned for the next installment in our “Mastering UML Diagrams” series, where we’ll explore another crucial aspect of UML modeling.

Leave a Reply

Your email address will not be published. Required fields are marked *