When to Use <<include>> vs. <<extend>>
Interactive Audio Lesson
Listen to a student-teacher conversation explaining the topic in a relatable way.
<<include>> Relationship
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Let's explore the <<include>> relationship. Can anyone tell me what it represents in Use Case Modeling?
Is it about including another use case in the description?
Exactly! The <<include>> relationship allows one use case to incorporate another's behavior. It's mandatory and often used to avoid redundancy in common functionalities across multiple use cases.
Could you give an example?
Certainly! For instance, both 'Place Order' and 'Manage Inventory' might require a user to 'Log In.' Instead of repeating the 'Log In' steps in each use case, we can simply say that they include 'Log In.' This is efficient!
So, itβs like a shared subroutine?
Exactly! Well put. Remember, when you use <<include>>, the included use case is always executed as part of the main flow of the base use case.
<<extend>> Relationship
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Now, letβs discuss the <<extend>> relationship. Who can summarize what this represents?
Is it about optional functionalities?
Correct! The <<extend>> relationship allows an optional or conditional behavior to be executed only under certain conditions within a base use case.
Can you illustrate that with an example?
Sure! Take 'Process Payment' as a base use case. If a system detects potential fraud during payment processing, then the use case 'Handle Fraud' could extend 'Process Payment.' This only happens if the specified conditions are met.
So the base use case can still stand alone?
Exactly! The base use case remains meaningful even without the optional extensions, ensuring that we keep system functionality intact.
Distinguishing <<include>> and <<extend>>
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Let's discuss the differences between <<include>> and <<extend>>. Who can highlight the main differences?
Is <<include>> about mandatory behaviors and <<extend>> about optional ones?
Yes! You've got it. <<include>> is mandatory and is always part of the flow, while <<extend>> is conditional and only adds behavior sometimes.
How about the execution of the use cases?
Great question! In <<include>>, the included use case must be executed for the base use case to work. In <<extend>>, the base use case can function independently, and the extension happens at specific extension points.
So we use <<include>> for shared routines and <<extend>> for specific cases?
Absolutely! That distinction is crucial for designing clear models. Always remember this while drafting your UML diagrams.
Best Practices
π Unlock Audio Lesson
Sign up and enroll to listen to this audio lesson
Now that we understand the differences, let's talk about best practices for using <<include>> and <<extend>>. What should we keep in mind?
Donβt overuse either relationship?
Exactly! Over-factoring can lead to confusion. Use these relationships to improve clarity and manage complexity, not to complicate things further.
What about defining extension points?
Good point! Clearly defining extension points in the base use cases is essential for using <<extend>> effectively. It indicates where the optional behaviors can occur.
Should we balance diagrams with specifications too?
Absolutely. Ensure that the diagrams and specifications complement each other to provide a full understanding of the model.
Introduction & Overview
Read summaries of the section's main ideas at different levels of detail.
Quick Overview
Standard
The section outlines when to apply the <
Detailed
In Use Case Modeling, understanding when to use the <
<
- Represents a mandatory inclusion of one use case's behavior within another. It emphasizes reusability by allowing common functionalities to be included across multiple use cases without redundant descriptions. The base use case always executes the included use case as part of its main flow.
- Example: In a shopping system, both 'Place Order' and 'Manage Inventory' may require 'Log In' as a prerequisite. Thus, 'Log In' can be included in both, avoiding duplication.
<
- Represents an optional or conditional extension of a base use case's behavior, activated only under specific conditions. This allows the base use case to function independently while providing additional functionalities when required.
- Example: In the 'Process Payment' use case, a behavior for 'Handle Fraud' can extend it if certain conditions (e.g., fraud detection) are met. Here, the base use case remains complete and meaningful on its own without the extension.
Key Takeaways:
- Use the <
Key Concepts
-
<
>: Used for mandatory behaviors shared across use cases. -
<
>: Used for optional behaviors that occur under specific conditions. -
Base Use Case: The primary use case that includes or is extended by other use cases.
-
Included Use Case: A subroutine that is compulsorily invoked by a base use case.
-
Extending Use Case: An optional behavior added to the base use case.
Examples & Applications
In an online shopping system, 'Place Order' and 'Manage Inventory' both require 'Log In', thus can use <
In a payment processing system, 'Process Payment' may extend with 'Handle Fraud' if certain fraud detection criteria are met.
Memory Aids
Interactive tools to help you remember key concepts
Rhymes
To avoid repeat in every way, <
Stories
Imagine a shopping mall where a store requires customers to show ID before shoppingβthis is like an <
Memory Tools
<>nclude for mandatory steps, <
Acronyms
I.E. for Include and Extend
Include is Essential
Extend is Optional!
Flash Cards
Glossary
- <<include>>
A relationship in Use Case Modeling that represents a mandatory inclusion of one use case's behavior within another.
- <<extend>>
A relationship in Use Case Modeling that represents an optional or conditional extension of a base use case's behavior.
- Base Use Case
The main use case that either incorporates or is augmented by another use case.
- Included Use Case
A use case whose behavior is included in the main flow of another use case.
- Extending Use Case
A use case that provides optional behavior to a base use case under certain conditions.
- Reusability
The property of a feature or component that allows it to be utilized in different contexts.
Reference links
Supplementary resources to enhance your learning experience.