Now Reading: A Comprehensive Guide to Include and Extend Relationships in UML Use Case Diagrams

1
  • 01

    A Comprehensive Guide to Include and Extend Relationships in UML Use Case Diagrams

A Comprehensive Guide to Include and Extend Relationships in UML Use Case Diagrams

Visual Paradigm, Unified Modeling Language, Use Case Modeling2 days ago

Introduction

Unified Modeling Language (UML) use case diagrams are powerful tools for modeling the functional requirements of a system. They illustrate how actors (users or external systems) interact with the system through use cases, which represent specific functionalities. Two key relationships in use case diagrams—Include and Extend—help manage complexity by structuring and modularizing behavior. This tutorial provides a detailed explanation of these relationships, their purposes, characteristics, and practical applications, complete with examples to ensure clarity.

What Are Include and Extend Relationships?

In UML use case diagrams, Include and Extend relationships allow you to break down complex use cases into smaller, reusable, or optional components. These relationships enhance modularity, reduce redundancy, and improve the clarity of diagrams.

Include” and “Extend” Use Cases - Visual Paradigm Blog

  • Include Relationship (<<include>>): Represents mandatory behavior that is always executed as part of a base use case. It extracts common functionality shared across multiple use cases into a reusable component.

  • Extend Relationship (<<extend>>): Represents optional or conditional behavior that extends a base use case under specific conditions, keeping the base use case focused on its core functionality.

Both relationships use dashed arrows to connect use cases, with labels indicating <<include>> or <<extend>>. The direction of the arrow is critical, as it reflects the dependency between the use cases.

Include Relationship (<<include>>)

Purpose

The Include relationship is used to extract common, mandatory behavior from multiple use cases into a single, reusable use case. This promotes reusability and simplifies the base use cases by avoiding duplicated functionality.

Characteristics

  • Mandatory: The included use case is always executed when the base use case is performed.

  • Reusable: The included use case is a standalone, coherent function that can be used by multiple base use cases.

  • Simplifies Diagrams: By extracting common steps, the base use case remains concise and focused.

  • Direction: The arrow points from the base use case to the included use case, indicating that the base use case depends on the included one.

Notation

  • A dashed arrow labeled <<include>> connects the base use case to the included use case.

Example 1: Online Shopping System

Consider an online shopping system where a customer can Place Order or Cancel Order. Both use cases require the customer to Log In to the system.

  • Base Use Cases: Place Order, Cancel Order

  • Included Use Case: Log In

  • Explanation: Logging in is a mandatory step for both placing and canceling an order. Instead of duplicating the login functionality in both use cases, it is extracted into a separate Log In use case, which is included by both.

Diagram Representation:

[Place Order] ----<<include>>----> [Log In]
[Cancel Order] ----<<include>>----> [Log In]

Example 2: Library Management System

In a library system, a user can Borrow Book or Return Book. Both processes require Verify User.

  • Base Use Cases: Borrow Book, Return Book

  • Included Use Case: Verify User

  • Explanation: Verifying the user’s identity (e.g., checking their library card) is a mandatory step in both borrowing and returning a book. The Verify User use case is included to avoid redundancy.

Diagram Representation:

[Borrow Book] ----<<include>>----> [Verify User]
[Return Book] ----<<include>>----> [Verify User]

When to Use

  • When multiple use cases share a common, mandatory step.

  • When you want to simplify use case descriptions by extracting reusable functionality.

  • When the included use case is meaningful independently (e.g., Log In or Verify User can be understood as standalone functions).

Extend Relationship (<<extend>>)

Purpose

The Extend relationship is used to model optional or conditional behavior that is only executed under specific circumstances. It allows the base use case to remain focused on its core functionality while adding optional behavior modularly.

Characteristics

  • Optional/Conditional: The extending use case is executed only if certain conditions are met.

  • Dependent: The extending use case is not meaningful on its own and depends on the base use case.

  • Extension Points: The base use case may define specific points where the extending behavior can be inserted.

  • Direction: The arrow points from the extending use case to the base use case, indicating that the extending use case adds behavior to the base.

Notation

  • A dashed arrow labeled <<extend>> connects the extending use case to the base use case, often with a note specifying the condition or extension point.

Example 1: ATM System

In an ATM system, the base use case is Withdraw Cash. An optional behavior, Print Receipt, may occur if the user requests a receipt.

  • Base Use Case: Withdraw Cash

  • Extending Use Case: Print Receipt

  • Condition: The user chooses to print a receipt after withdrawing cash.

  • Explanation: Printing a receipt is not mandatory and only happens if the user explicitly requests it. The Print Receipt use case extends Withdraw Cash at the extension point “User requests receipt.”

Diagram Representation:

[Print Receipt] ----<<extend>>----> [Withdraw Cash]
(Note: Condition = User requests receipt)

Example 2: Online Course Platform

In an online course platform, a user can Take Quiz. An optional behavior, Request Hint, occurs if the user struggles with a question.

  • Base Use Case: Take Quiz

  • Extending Use Case: Request Hint

  • Condition: The user requests a hint during the quiz.

  • Explanation: Requesting a hint is optional and depends on the user’s need. The Request Hint use case extends Take Quiz at the extension point “User needs assistance.”

Diagram Representation:

[Request Hint] ----<<extend>>----> [Take Quiz]
(Note: Condition = User needs assistance)

When to Use

  • When behavior is optional or depends on specific conditions.

  • When you want to keep the base use case focused on its primary functionality.

  • When the extending use case is not meaningful without the base use case (e.g., Print Receipt is irrelevant without Withdraw Cash).

Key Differences Between Include and Extend

The table below summarizes the differences between Include and Extend relationships to guide their usage:

Criteria

Include (<<include>>)

Extend (<<extend>>)

Is the behavior mandatory?

Yes, always executed as part of the base use case

No, executed only under specific conditions

Can the behavior stand alone?

Yes, it is a coherent, reusable function

No, it depends on the base use case

Does it occur in multiple use cases?

Yes, shared across multiple use cases

Usually specific to one use case

Purpose

Promote reuse and simplify base use case

Add optional or exceptional behavior modularly

Arrow Direction

Base → Included use case

Extending → Base use case

Practical Example: Restaurant Management System

Let’s apply both relationships in a restaurant management system to illustrate their use in a real-world scenario.

Scenario

A restaurant system allows customers to Order Food and Reserve Table. The system also handles additional behaviors like Pay Bill and Request Takeout.

Use Cases

  • Order Food: The customer orders food from the menu.

  • Reserve Table: The customer reserves a table for dining.

  • Authenticate Customer: Verifies the customer’s identity (e.g., via a loyalty account).

  • Pay Bill: The customer pays for their order (mandatory for Order Food).

  • Request Takeout: An optional request to package the order for takeout.

Relationships

  • Include: Both Order Food and Reserve Table require Authenticate Customer to verify the customer’s identity. Order Food also includes Pay Bill because payment is mandatory after ordering.

  • Extend: Order Food can be extended by Request Takeout if the customer chooses to take their food to go.

Diagram Representation

[Order Food] ----<<include>>----> [Authenticate Customer]
[Order Food] ----<<include>>----> [Pay Bill]
[Reserve Table] ----<<include>>----> [Authenticate Customer]
[Request Takeout] ----<<extend>>----> [Order Food]
(Note: Condition = Customer requests takeout)

Explanation

  • Authenticate Customer is included in both Order Food and Reserve Table because it is a mandatory step to access the system.

  • Pay Bill is included in Order Food because payment is required to complete the order.

  • Request Takeout extends Order Food because it is an optional behavior that only occurs if the customer requests takeout.

Best Practices for Using Include and Extend

  1. Use Include Sparingly: Only extract behavior into an included use case if it is shared by multiple use cases or significantly simplifies the base use case. Overusing includes can make diagrams cluttered.

  2. Define Clear Extension Points for Extend: Specify the conditions or points in the base use case where the extending behavior applies to avoid ambiguity.

  3. Keep Use Cases Focused: Ensure the base use case remains simple and focused on its primary goal, using Include for mandatory steps and Extend for optional ones.

  4. Validate Reusability for Include: The included use case should be meaningful and reusable across different contexts.

  5. Avoid Overcomplicating Diagrams: Use Include and Extend only when they add clarity. Complex relationships can confuse stakeholders.

Common Pitfalls and How to Avoid Them

  1. Confusing Include with Extend:

    • Pitfall: Using Include for optional behavior or Extend for mandatory behavior.

    • Solution: Always check if the behavior is mandatory (use Include) or conditional (use Extend).

  2. Overusing Relationships:

    • Pitfall: Creating too many Include or Extend relationships, making the diagram hard to read.

    • Solution: Only use these relationships when they reduce redundancy or improve clarity.

  3. Vague Extension Conditions:

    • Pitfall: Not specifying the condition for an Extend relationship, leading to confusion.

    • Solution: Always include a note or description of the condition or extension point.

  4. Including Non-Reusable Behavior:

    • Pitfall: Creating an included use case that is only used by one base use case.

    • Solution: Ensure the included use case is reusable or significantly simplifies the base use case.

Conclusion

The Include and Extend relationships in UML use case diagrams are essential for managing complexity and ensuring modularity. The Include relationship promotes reusability by extracting mandatory, shared behavior, while the Extend relationship keeps base use cases focused by modeling optional or conditional behavior. By understanding their purposes, characteristics, and best practices, you can create clear, maintainable, and effective use case diagrams that communicate system functionality to stakeholders.

Reference

Follow
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...