Identify and Model the Includes Stereotype

Most systems have a certain amount of behavior used in a number of places throughout the system. In software, these behaviors often appear as common subroutines or classes. At the use case level, you can avoid rewriting the same flow events multiple times by separating the flow into its own use case. The new use case may then be invoked by other use cases whenever that flow of events is needed. Other use cases may simply “include” the new use case in their own flow of events. This ensures consistency and simplifies the flow events in calling the use case. To include the new use case, use the keyword include and the use case name at the point in the flow of events where it needs to be used.

In the Unified Modeling Language (UML), the `«include»` stereotype is used within use case diagrams to represent an include relationship between two use cases. This relationship models a situation where one use case (the base use case) incorporates the behavior of another use case (the included use case) as part of its execution. The inclusion is mandatory every time the base use case runs.
Purpose of the `«include»` Stereotype:

• Modularity and Reusability: By extracting common functionalities into separate use cases, you promote reuse and simplify maintenance.
• Avoiding Redundancy: Prevents duplication of shared behaviors across multiple use cases.
• Clarifying Behavior: Makes the use case diagrams cleaner and more understandable by breaking down complex processes.

How to Use the `«include»` Stereotype:

1. Identify Common Behavior: Determine the functionality that is shared among multiple use cases.
2. Create an Included Use Case: Define a separate use case that encapsulates the shared behavior.
3. Establish the Include Relationship:
   • Draw a dashed arrow from the base use case to the included use case.
   • Label the relationship with the `«include»` stereotype.

Example:
Suppose you have multiple use cases that require user authentication:

• Base Use Cases:
  • "Place Order"
  • "View Order History"
• Included Use Case: "Authenticate User"

In the use case diagram:

• Draw "Place Order" and "View Order History" as separate use cases.
• Draw "Authenticate User" as another use case.
• From each base use case, draw a dashed arrow pointing to "Authenticate User" and label it with `«include»`.

Visual Representation:

[Place Order] --«include»--> [Authenticate User]
[View Order History] --«include»--> [Authenticate User]

Key Points:

• The included use case cannot stand alone; it is always called by the base use case.
• The base use case depends on the included use case to complete its process.
• The include relationship is unconditional; the included use case is always executed when the base use case runs.

By using the `«include»` stereotype, you effectively model the decomposition of complex behaviors into manageable, reusable components within your UML use case diagrams.
Summary: The `«include»` stereotype in UML use case diagrams indicates that one use case mandatorily incorporates the behavior of another, modeling a reusable, included action within the base use case.

As a rule of thumb, wait until the use case diagram is reasonably complete before refining it with the Include stereotype. If you are not careful, you can easily fall into a functional decomposition of the system instead of a use case model. Functional decomposition describes a system in increasing levels of detail. Each level goes deeper into the inner workings of the application. This sabotages the scope of the project initiation phase and sends you into analysis and design much too early in the project. Use the include convention to simplify your model and remove redundancies. Do not use it to describe subfunctions or implementations.

Click the Exercise link below to refine the course project use case diagram with the Includes dependency stereotype.
Include Dependency - Exercise