Simplifying Large Use Case Diagrams with Include Relationships

Introduction

In software engineering, use case diagrams help visualize the interactions between users (actors) and a system to capture its functional requirements. As systems scale, use case diagrams can become unwieldy, filled with repetitive or complex behaviors that obscure the system’s core functionality. The include relationship in UML addresses this challenge by allowing common behaviors to be extracted into reusable, modular use cases. This article delves into how include relationships simplify use case diagrams, their key benefits, and practical examples to demonstrate their utility.

What is an Include Relationship?

An include relationship in UML specifies that a base use case incorporates the behavior of another use case, called the included use case. The included use case represents a sequence of actions that is always executed as part of the base use case’s flow. Visually, this relationship is depicted as a dashed arrow with an open arrowhead pointing from the base use case to the included use case, labeled with the stereotype «include».

The include relationship is analogous to a subroutine call in programming: the base use case “calls” the included use case to perform a specific task, promoting structured and hierarchical modeling. By extracting common or complex behaviors into separate use cases, include relationships reduce duplication, enhance clarity, and improve maintainability.

Benefits of Include Relationships

Include relationships offer several advantages when modeling large and complex systems:

1. Reuse of Common Behavior: Shared functionality across multiple use cases can be encapsulated in a single included use case, eliminating redundancy.

2. Simplification of Complex Use Cases: Large use cases can be broken into smaller, manageable modules, making the diagram less cluttered.

3. Mandatory Execution: The included use case is always executed as part of the base use case, ensuring completeness without overloading the main flow with details.

4. Improved Clarity and Maintainability: By separating concerns, the base use case focuses on its unique behavior, while included use cases handle reusable sequences, simplifying updates.

5. Structured Modeling: Include relationships support a hierarchical design, similar to subroutines, making the system easier to understand and extend.

Examples of Include Relationships

To illustrate the power of include relationships, let’s explore several practical examples across different domains.

Example 1: Online Shopping System

Consider an online shopping platform where users can browse products, add items to a cart, and checkout. Many use cases, such as “Purchase Product,” “Reserve Item,” and “Gift Item,” require the user to be authenticated before proceeding.

• Base Use Cases: “Purchase Product,” “Reserve Item,” “Gift Item”

• Included Use Case: “Authenticate User”

Instead of duplicating the authentication steps in each use case, we extract them into a single “Authenticate User” use case. This included use case handles tasks like prompting for login credentials and verifying them. The use case diagram would show:

• A dashed arrow from “Purchase Product” to “Authenticate User” with «include».

• Similar arrows from “Reserve Item” and “Gift Item” to “Authenticate User”.

This approach reduces redundancy, as the authentication logic is defined once and reused across multiple use cases, keeping the diagram clean and maintainable.

Example 2: Banking System

In a banking system, customers can perform actions like “Withdraw Cash,” “Deposit Money,” and “Transfer Funds.” Each of these use cases requires validating the customer’s account before proceeding.

• Base Use Cases: “Withdraw Cash,” “Deposit Money,” “Transfer Funds”

• Included Use Case: “Validate Account”

The “Validate Account” use case checks the account status, balance, and permissions. By including this use case in each of the base use cases, the diagram avoids repeating the validation logic. The visual representation includes dashed arrows labeled «include» from each base use case to “Validate Account”. This modularization simplifies the diagram and ensures that account validation is consistently applied.

Example 3: Library Management System

In a library system, users can “Borrow Book,” “Return Book,” or “Reserve Book.” Each of these actions requires checking the book’s availability.

• Base Use Cases: “Borrow Book,” “Return Book,” “Reserve Book”

• Included Use Case: “Check Book Availability”

The “Check Book Availability” use case verifies whether the book is in stock and not reserved. By including this use case in the base use cases, the diagram remains uncluttered, and updates to the availability-checking logic (e.g., integrating a new inventory system) only need to be made in one place.

Example 4: Hospital Management System

In a hospital management system, patients can “Schedule Appointment,” “Cancel Appointment,” or “Reschedule Appointment.” Each of these use cases requires verifying the patient’s identity.

• Base Use Cases: “Schedule Appointment,” “Cancel Appointment,” “Reschedule Appointment”

• Included Use Case: “Verify Patient Identity”

The “Verify Patient Identity” use case handles tasks like checking the patient’s ID or insurance details. Including this use case in the base use cases ensures that identity verification is consistently performed without duplicating steps in the diagram. The dashed «include» arrows connect each base use case to “Verify Patient Identity,” enhancing clarity.

Example 5: E-Learning Platform

In an e-learning platform, students can “Take Quiz,” “Submit Assignment,” or “View Grades.” Each of these actions requires the student to log in to the system.

• Base Use Cases: “Take Quiz,” “Submit Assignment,” “View Grades”

• Included Use Case: “Log In”

The “Log In” use case encapsulates the steps for user authentication. By including it in the base use cases, the diagram avoids repeating login steps, making it easier to understand and maintain. The visual representation shows dashed arrows labeled «include» from each base use case to “Log In”.

Visual Representation in UML

In UML use case diagrams, the include relationship is depicted as follows:

• A dashed arrow with an open arrowhead points from the base use case to the included use case.

• The arrow is labeled with the stereotype «include».

For instance, in the online shopping example:

• Purchase Product → «include» → Authenticate User

• The diagram clearly shows that “Authenticate User” is a mandatory part of the “Purchase Product” flow.

This visual convention ensures that stakeholders can quickly grasp the relationships between use cases and their dependencies.

Comparison with Extend Relationships

It’s worth noting the difference between include and extend relationships to avoid confusion:

• Include: The included use case is always executed as part of the base use case (mandatory).

• Extend: The extending use case is optional and only executed under specific conditions.

For example, in the online shopping system, “Authenticate User” is included because it’s mandatory, but a use case like “Apply Discount Code” might be an extend relationship, as it’s optional and depends on whether the user has a valid code.

Best Practices for Using Include Relationships

To maximize the benefits of include relationships, consider the following:

1. Identify Common Behaviors: Look for sequences of actions repeated across multiple use cases, such as authentication, validation, or logging.

2. Keep Included Use Cases Focused: Ensure that included use cases encapsulate specific, reusable behaviors rather than entire processes.

3. Balance Modularity and Simplicity: Avoid over-fragmenting use cases, as too many included use cases can make the diagram harder to follow.

4. Use Clear Naming Conventions: Name included use cases to reflect their purpose (e.g., “Authenticate User” instead of “Login Process”) for better readability.

5. Validate Mandatory Execution: Confirm that the included use case is always required; otherwise, consider an extend relationship.

Summary of Benefits

The following table summarizes the key benefits of include relationships:

Conclusion

Include relationships are a cornerstone of effective use case modeling in UML, enabling the reuse and modularization of common, mandatory behaviors. By extracting shared functionality into included use cases, developers can create cleaner, more maintainable diagrams that are easier to understand and update. The examples provided—ranging from online shopping to hospital management—demonstrate the versatility of include relationships across domains. By leveraging this mechanism, teams can model complex systems with greater clarity and efficiency, ultimately improving the quality of their software designs.

Reference

• Documenting use case details in Visual Paradigm
  Guide on how to edit and view use case details within Visual Paradigm.
• How to Draw Use Case Diagram? – Visual Paradigm
  Step-by-step instructions for creating UML use case diagrams using Visual Paradigm.
• What is Use Case Diagram? – Visual Paradigm
  Overview of use case diagrams and their role in modeling system behavior.
• Use case diagram in Visual Paradigm
  Detailed explanation of use case diagram elements and how to document use case events.
• Use Case Diagram notations guide – Visual Paradigm
  Comprehensive guide to UML use case diagram notations supported in Visual Paradigm.
• Comprehensive Guide to Creating Use Case Diagrams with Visual Paradigm
  A detailed tutorial on identifying actors, defining use cases, and modeling relationships in Visual Paradigm.
• Use Case Description in Visual Paradigm for UML – Angelfire
  Explains use case description, scheduling, elaboration, and documentation generation in Visual Paradigm.
• Demystifying Use Case Models: Bridging Textual Detail and Visual Insight
  Discusses how to combine textual use case details with visual diagrams in Visual Paradigm.
• Use Case Diagram – UML Modeling Tool – Visual Paradigm
  Visual Paradigm’s official page showcasing use case diagram features and notation support.