UML: Use Case Diagrams & Scenarios

Include & Extend Relationships

18 min Lesson 4 of 10

Include & Extend Relationships

A use case diagram that shows only actors and plain associations quickly becomes a wall of identical ovals. Two stereotyped relationships — <<include>> and <<extend>> — let you factor out shared behaviour and model optional or conditional behaviour without duplicating logic. Mastering them is the single biggest step from a beginner diagram to a professional one.

Notation reminder: Both relationships are drawn as dashed arrows labelled with the stereotype in guillemets. The direction of the arrow is the key to telling them apart — and it is the part most analysts get backwards at first.

The <<include>> Relationship

Use <<include>> when one use case always and unconditionally invokes another. Think of it as a subroutine call: every time the base use case runs, the included use case runs too. The arrow points from the base use case to the included one — meaning "I always call you."

Classic trigger: you notice that two or more use cases share a large block of identical steps. Rather than duplicating that logic, you extract it into its own use case and <<include>> it from both callers.

Example — Online Pharmacy: Both Place Order and Renew Prescription require the customer to be authenticated. Authenticate Customer is extracted into its own use case and included by both.

Both Place Order and Renew Prescription always invoke Authenticate Customer via <<include>>.

Notice the arrows: both base use cases point toward Authenticate Customer. This is the defining rule — the base case points to the included case. If you draw it backwards, it reads as the included case invoking the base case, which is incorrect.

The <<extend>> Relationship

Use <<extend>> when a use case optionally or conditionally adds behaviour to another. The extension runs only under certain conditions — it is a variation, not a guaranteed subroutine. The arrow points from the extending use case back to the base use case, which is the opposite of <<include>>. Read it as: "I extend you when a condition is met."

Classic trigger: you have a base flow that works perfectly on its own, but there is an optional path that only some users take — or that only fires under specific circumstances. Modelling it as <<extend>> keeps the base use case clean.

Example — Clinic Appointment Booking: The base use case is Book Appointment. Under certain conditions (e.g., the patient selects a specific doctor or a chronic condition flag is set), the system may optionally Request Referral Letter or Notify GP.

Extension points: Formally, a use case that accepts extensions declares one or more extension points — named locations in its flow where an extension can insert itself. In textual scenarios you write these as a bulleted list; in diagrams it is common to add a small note attached to the base use case ellipse. Many teams omit extension point labels on quick diagrams without losing meaning — but include them in formal specifications.

Extending use cases point back to the base use case; conditions in notes explain when each extension fires.

Side-by-Side Comparison

The table below crystallises the essential difference. Commit this to memory before your next diagram review.

Relationship   | Arrow direction          | When it fires    | Analogy
---------------|--------------------------|------------------|---------------------------
<<include>>  | Base → Included          | Always           | Function call / subroutine
<<extend>>   | Extension → Base         | Conditionally    | Optional plug-in / hook

The most common mistake: drawing both arrows in the same direction. Remember — <<include>> and <<extend>> point in opposite directions. If all your dashed arrows point the same way, something is wrong.

A Combined Example: Online Library

Real systems use both relationships together. The library below demonstrates them in a single diagram. Search Catalogue always includes Log Search Query (audit requirement). Borrow Book always includes Verify Membership. Two optional behaviours extend Borrow Book: Apply Fine fires only if the member has an outstanding balance, and Send SMS Reminder fires only if SMS notifications are enabled.

Library system combining <<include>> (blue, always fires) and <<extend>> (amber, fires conditionally).

Practical Decision Guide

When you are in front of a whiteboard and unsure which relationship to use, ask yourself two questions:

Is the behaviour required every single time? If yes → <<include>>. The base case is incomplete without it.
Is it optional, rare, or conditional? If yes → <<extend>>. The base case works perfectly without it.

A secondary test: could you delete the candidate use case without breaking the base flow? If yes → probably <<extend>>. If the base flow collapses without it → definitely <<include>>.

Keep it sparse. Every <<include>> or <<extend>> arrow you add is a promise to document the relationship in your written scenarios. Do not model optional paths unless they have real business significance. Overusing <<extend>> for every minor variation produces unmaintainable diagrams.

Summary

<<include>>: always executes; arrow points from base to included; used to factor out shared mandatory behaviour.
<<extend>>: conditional or optional; arrow points from extension back to base; used for plug-in or exceptional flows.
Both use dashed arrows with a stereotype label in guillemets — only the direction differs.
Declare an extension point on the base use case ellipse whenever the trigger condition needs to be communicated clearly.