Professional Courses
Industry-relevant training in Business, Technology, and Design to help professionals and graduates upskill for real-world careers.
Categories
Interactive Games
Fun, engaging games to boost memory, math fluency, typing speed, and English skillsβperfect for learners of all ages.
Typing
Memory
Math
English Adventures
Knowledge
Interactive Audio Lesson
Listen to a student-teacher conversation explaining the topic in a relatable way.
<<include>> Relationship
Unlock Audio Lesson
Signup and Enroll to the course for listening the 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
Signup and Enroll to the course for listening the 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
Signup and Enroll to the course for listening the 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
Signup and Enroll to the course for listening the 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 a summary of the section's main ideas. Choose from Basic, Medium, or Detailed.
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 <
Definitions & Key Concepts
Learn essential terms and foundational ideas that form the basis of the topic.
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 & Real-Life Applications
See how the concepts apply in real-world scenarios to understand their practical implications.
Examples
-
In an online shopping system, 'Place Order' and 'Manage Inventory' both require 'Log In', thus can use <
> to avoid redundancy. -
In a payment processing system, 'Process Payment' may extend with 'Handle Fraud' if certain fraud detection criteria are met.
Memory Aids
Use mnemonics, acronyms, or visual cues to help remember key information more easily.
π΅ Rhymes Time
-
To avoid repeat in every way, <
> comes to save the day.
π Fascinating Stories
-
Imagine a shopping mall where a store requires customers to show ID before shoppingβthis is like an <
>. However, if customers can receive discounts based on special offers at checkout, thatβs like an < >!
π§ Other Memory Gems
-
<>nclude for mandatory steps, <
>xtend for whatβs optional, so keep your flow perceptual!
π― Super Acronyms
I.E. for Include and Extend
- Include is Essential
- Extend is Optional!
Flash Cards
Review key concepts with flashcards.
Glossary of Terms
Review the Definitions for terms.
-
Term: <<include>>
Definition:
A relationship in Use Case Modeling that represents a mandatory inclusion of one use case's behavior within another.
-
Term: <<extend>>
Definition:
A relationship in Use Case Modeling that represents an optional or conditional extension of a base use case's behavior.
-
Term: Base Use Case
Definition:
The main use case that either incorporates or is augmented by another use case.
-
Term: Included Use Case
Definition:
A use case whose behavior is included in the main flow of another use case.
-
Term: Extending Use Case
Definition:
A use case that provides optional behavior to a base use case under certain conditions.
-
Term: Reusability
Definition:
The property of a feature or component that allows it to be utilized in different contexts.