When designing complex software systems, the goal is to break down functionality into manageable, reusable components. In the world of Unified Modeling Language (UML), Use Case diagrams serve as the blueprint for understanding how users interact with a system. However, as systems grow, writing distinct use cases for every single action becomes redundant and inefficient. This is where the Structuring Use Cases concept comes into play, specifically through the <> relationship.

This tutorial explores the mechanics, purpose, and visual representation of the Include relationship, ensuring you can model complex interactions efficiently without repetitive effort.

Why Structure Your Use Cases?

In simple systems, independent use cases might suffice. However, for complex or large-scale systems, we often find that certain sequences of user-system interaction occur repeatedly across different scenarios. Trying to define these sequences inside every single parent use case leads to cluttered diagrams and difficult maintenance.

Establishing relationships between use cases allows for the reuse of those use cases that need to be defined over and over again. By abstracting common behavior, you significantly reduce developer effort and ensure consistency throughout the system’s logic.

Defining the <> Relationship

The <> relationship is a fundamental tool for managing complexity. It represents a directed relationship between two use cases where one use case (the base use case) explicitly requires the behavior of another use case (the included use case) to complete its own process.

Think of it this way: The base use case cannot function correctly without the functionality provided by the included use case. It is a mandatory dependency.

Key Characteristics

• Mandatory Execution: Unlike extensions, which are optional, the included use case is always executed as part of the base use case’s flow.
• Reuse of Logic: It captures common behavior, such as “Login” or “Validate User,” that might be needed by “Place Order,” “Update Profile,” and “Check Balance.”
• Decomposition: It allows you to break down a complex use case into smaller, more manageable chunks.

Visualizing the Relationship

In UML diagrams, the <> relationship is depicted with a specific syntax to distinguish it from other associations.

1. Dotted Line: The connection is drawn using a dashed or dotted line.
2. Open Arrowhead: The line terminates with an open arrowhead.
3. Directionality: Crucially, the arrowhead points towards the child use case (the one being included). The base use case is connected at the base of the arrow.
4. Stereotype: The relationship is labeled with the stereotype <>.

Visual Example

Consider a scenario where a user must log in to place an order. The Place Order use case relies on the Login use case. The diagram below illustrates this structure:

When to Use the Include Relationship

Timing is key in the modeling process. The recommended time to utilize the <> relationship is after you have completed the first cut description of all your main Use Cases.

Once you have your initial list of high-level use cases, review them to identify common sequences of interaction. If you notice that multiple use cases (like “Checkout” and “Register”) both require a “Login” step, you have identified a prime candidate for an Include relationship.

The Workflow

1. Identify the base use case (e.g., Place Order).
2. Identify the common behavior (e.g., Login).
3. Create a directed dotted arrow from the base to the common behavior.
4. Label the arrow with <>.

This structure indicates that an instance of the base use case will include the behavior as specified in the child use case. It adds additional functionality not specified in the base use case’s primary flow, but which is necessary to support the reuse of common behavior.

Summary

By utilizing the <> relationship, you create a cleaner, more maintainable Use Case model. It allows you to define a “Login” or “Validate Payment” process once and reference it everywhere it is needed, reducing redundancy and clarifying the system’s architecture.