Extending and Including Use Cases Effectively

When modeling user interactions in software, reusing common behaviors across multiple use cases is essential. That’s where <> and <> relationships come in. These aren’t just optional connectors—they’re foundational tools for reducing redundancy and ensuring consistency. I’ve seen countless beginners struggle with when to use one over the other, often ending up with tangled, confusing diagrams. The key isn’t memorizing rules. It’s understanding intent.

Think of <> as a way to package shared functionality—like a “mini-use case” that multiple others depend on. <> is for optional or conditional behavior that enhances a base use case. Knowing when to use each can turn a chaotic diagram into a clean, maintainable blueprint.

Here, you’ll learn how to apply these relationships with real-world logic, avoid common mistakes, and craft diagrams that others can actually understand. I’ll share patterns I’ve used in production systems and warn you about the pitfalls that can derail your modeling early on.

Understanding <>: Reusing Common Functionality

Use <> to represent mandatory inclusion of a reusable use case into a base use case. It’s like a function call—something that must happen for the base use case to succeed.

For example, in a payment processing system, the “Process Payment” use case might <> “Verify Payment Details” and “Confirm Transaction.” These aren’t optional—they’re part of the core flow.

Use <> when:

• The included use case is required for the base use case to complete.
• You have overlapping steps across multiple use cases (e.g., login, data validation).
• You want to isolate complex behavior into a single reusable component.

Don’t use <> if the behavior is optional or conditional. That’s where <> comes in.

When <> is the Right Choice

Consider a hospital appointment system. The use case “Schedule Appointment” must always include “Check Doctor Availability” and “Validate Patient Records.” These are not optional—they’re prerequisites.

Here’s how to draw it:

• Draw the base use case (e.g., “Schedule Appointment”).
• Draw the included use case (e.g., “Check Doctor Availability”).
• Connect with a dashed line labeled «include».
• Use a dashed arrow pointing from the base to the included use case.

Remember: <> is about required behavior, not optional branches.

Understanding <>: Adding Optional or Conditional Behavior

Use <> to model optional or alternative flows that enhance a base use case. It’s like adding a “bonus feature” that only triggers under certain conditions.

For example, in an online shopping app, “Place Order” might <> with “Apply Discount Coupon” or “Request Gift Wrapping.” These aren’t required—they’re extras.

Use <> when:

• The behavior is optional and only applies under certain conditions.
• You need to model alternative paths (e.g., success vs. error handling).
• The extension depends on a specific event or user decision.

Never use <> if the behavior is mandatory. That’s a clear sign you should have used <> instead.

When <> is the Right Choice

Imagine a login system. The base use case is “Login.” You can <> this with “Send Two-Factor Code” if the user has 2FA enabled.

Here’s how it works:

• Draw the base use case (“Login”).
• Draw the extension use case (“Send Two-Factor Code”).
• Connect with a dashed line labeled «extend».
• Use a dashed arrow from the extension to the base use case.
• Mark the extension with a «extend» stereotype.

Now, the extension only triggers under a defined condition—like a guard on a decision node.

Use Case Extend vs Include: Key Differences

Confusion between <> and <> is one of the most common mistakes in beginner use case diagrams. Let’s clarify with a comparison.

Aspect	<<include>>	<<extend>>
Relationship Type	Mandatory inclusion	Optional extension
Direction	Base → Included	Extension → Base
When Used	Shared, required steps	Conditional, optional flows
Example	“Process Payment” <> “Verify Identity”	“Place Order” <> “Apply Coupon”

Remember: if it’s required and repeated, use <>. If it’s optional and conditionally triggered, use <>.

Guidelines to Avoid Clutter and Maintain Clarity

Overusing <> and <> leads to “spaghetti diagrams” that no one can read. Here’s how to keep your models clean and effective.

1. Limit extensions to 2–3 per use case. More than that, and the diagram becomes unwieldy. If you need more, consider splitting the use case or creating a new one.
2. Use <> only for truly reusable logic. Don’t break down simple steps like “Enter Name” into a separate use case unless it’s repeated across 3+ use cases.
3. Never nest <> relationships. A use case shouldn’t <> another <>. If the dependency is complex, use a generalization or separate use case.
4. Label conditions clearly. When using <>, always specify the condition in a note or as a guard on the extension.
5. Use stereotypes consistently. Always write «include» and «extend» in lowercase with angle brackets to distinguish them from regular text.

Clarity is more important than completeness. A clean, focused diagram that captures the core logic is worth more than a cluttered one that tries to include every possible variation.

Practical Example: Online Shopping Use Case

Let’s walk through a real-world example to see <> and <> in action.

Base Use Case: “Place Order”

• Must <> “Verify Cart” and “Confirm Shipping Address”.
• May <> with “Apply Discount Coupon” or “Request Gift Wrapping”.

The diagram remains readable because:

• Required steps are grouped via <>.
• Optional features are clearly marked as <>.
• Each extension has a defined condition (e.g., “if user has coupon”).

This structure makes it easy for developers to understand the flow and for business analysts to validate requirements.

Advanced Use Case Relationships Beginners Often Misunderstand

Many beginners think <> and <> are interchangeable. They’re not. I’ve reviewed hundreds of use case diagrams, and the most common error is misapplying <> where <> is needed.

Ask yourself:

• “Is this step required for the use case to succeed?” → Use <>.
• “Is this step optional, dependent on a condition, or triggered by an event?” → Use <>.

Another pitfall: overusing <> for minor steps. If a use case only needs “Enter Email” once, don’t extract it into a separate use case. It adds noise without benefit.

Always ask: Could the base use case work without this component? If not, <>. If yes, and only sometimes, <>.

Frequently Asked Questions

When should I use <> vs <>?

Use <> for mandatory, shared behavior. Use <> for optional, conditional behavior. If the step is required for success, use <>. If it’s an enhancement only in certain cases, use <>.

Can a use case both <> and <>?

Yes. A use case can have both. For example, “Process Order” might <> “Verify Payment” and <> “Apply Discount.” The key is ensuring each relationship serves a distinct purpose.

How do I show conditions for <> in a diagram?

Add a note near the <> arrow stating the condition (e.g., “if user has coupon”), or use a guard in the interaction flow. The condition must be unambiguous and testable.

Is <> the same as inheritance?

No. <> is a behavioral dependency for reuse. Inheritance (generalization) is a structural relationship between classes. They serve different purposes and should not be confused.

What’s the best way to avoid overusing <>?

Limit extensions to 2–3 per use case. If you have more, consider splitting the use case into smaller, focused ones. Also, evaluate whether the extension is truly optional or just a variation of the base flow.

Can <> be used for error handling?

Yes, but use it carefully. Error handling like “Handle Invalid Input” can <> the base use case. However, if it’s a standard fallback, it may be better modeled as part of the base flow or as a separate use case.

Now that you’ve seen how <> and <> work together, try drawing a use case for a real app—like a task manager, library system, or booking service. Focus on reuse, clarity, and logical flow.

Mastering these relationships is one of the first steps toward creating use case diagrams that not only look professional but actually guide development and communication.

Keep practicing. The more you draw, the faster you’ll spot the right pattern. And remember: clean diagrams are not about perfection—they’re about clarity.