Excavating The Extension Use Case


Several years ago, I was asked to create a use case modeling course. This set me off on “an archeological dig” of the use case domain, scraping away layers of vague, confusing and sometimes WVGJuly10th1contradictory information until I hit bedrock. The construct for which I felt the greatest need to do this is the extension use case (a close second was the inclusion use case, but that’s perhaps for another time).  In this two-part article, I summarize my exploration and share my interpretation of what I found. 

My impression is that the extension use case is often misunderstood and misapplied, which may lead to confusing inconsistencies and counterproductive debates. However, understood from the ground up, the subjectivity that drives its traditional use gives way to an objectivity that guides its further application.

Scraping the surface: the typical explanation

An extension use case is often explained as representing behavior that is “optional” to a base use case, where some executions of the base use case will trigger the extension use case and others will not. This explanation didn’t sit well with me, because why couldn’t such optional behavior be represented as an alternative flow in the base use case? An alternative flow and an extension use case are both responses to a condition or event that occurs at a certain point in the base use case, so when do you use the one and when the other?

Digging sideways and down: Alistair Cockburn

Cockburn [2] advocates the use of extension use cases when “there are many […] interrupting services the user might use” (e.g., “Check spelling,” ”Change template” and “Find synonym” are extension use cases of the “Edit document” base use case) and “when you are writing additions to a locked requirements document.” 

  • The first reason refers to behaviors that are “optional” to the base use case, but Cockburn’s example implies that “optional” means non-essential to reaching the base use case’s goal, because you can complete the “Edit document” use case countless times without ever triggering any of the extension use cases.
  • The second reason strikes me as arbitrary because here the use of extension use cases is driven by project circumstances rather than by the nature of the system being modeled.

Cockburn also provides some valuable concepts. The following are relevant to this article.

  1. Goal orientation. Each actor-initiated use case represents, and is named after, a single goal of the initiating actor. In order to reach the goal, the actor needs the assistance of the system to which the use case belongs. Each step of the use case’s main flow and alternative flows is a mini goal toward reaching the initiating actor’s goal (this does not apply to exception flows, which represent failures to reach the goal).
  2. Off-stage stakeholder. “A use case captures a contract between the stakeholders of a system about its behavior.” A use case’s initiating actor can be called an on-stage stakeholder because the actor is directly involved in the use case’s execution. An off-stage stakeholder is not directly involved in the execution of a use case, but does have interests the use case needs to address.

We’ll return to these concepts momentarily.

Digging deeper: the UML

The UML superstructure [1] refers to an extension use case as behavior that is “usually supplementary” to a base use case. That’s different from “optional,” when “supplementary” is understood to mean “additional,” as will become clear. The description is worth quoting in its entirety.

“This relationship specifies that the behavior of a use case may be extended by the behavior of another (usually supplementary) use case. The extension takes place at one or more specific extension points defined in the extended use case. Note, however, that the extended use case is defined independently of the extending use case and is meaningful independently of the extending use case. On the other hand, the extending use case typically defines behavior that may not necessarily be meaningful by itself. Instead, the extending use case defines a set of modular behavior increments that augment an execution of the extended use case under specific conditions.”

This description also conveys the key notions that a base use case “is defined independently” of an extension use case and “is meaningful independently” of an extension use case. Different people interpret these statements differently; my interpretation follows shortly.  

While this description hints at the extension mechanism, it doesn’t strike me as a clear indication of when to use it.

Hitting bedrock: Ivar Jacobson

Jacobson wrote two articles [3] that for me brought home the extension use case concept. In [3] he provides the original example he used to explain the extension use case idea. Set in a telecommunications context, it includes a base use case, Call Handling, that represents a Subscriber making a phone call, and an extension use case, Traffic Recording, “the goal of which is to measure the average traffic from subscribers during, say, a 15-minute period.” The caption of Figure 2 in [3] is, “With a simple technique—separation of concerns with extensions and extension points—the Call Handling [base] use case could become oblivious of the Traffic Recording [extension] use case.”  

The concerns being separated are making a phone call and gathering phone call traffic data. What I find crucial here is that in Cockburn’s terms:

  1. These are concerns, or goals, of different stakeholders. Of the Subscriber as the on-stage stakeholder on the one hand and of a department in the Organization as an off-stage stakeholder on the other.
  2. The goal of the extension use case in no way contributes to the goal of the base use case. The extension use case is not a mini goal, whether mandatory or optional, toward reaching the base use case’s goal as the Subscriber sees

As far as the Subscriber is concerned, the extension use case doesn’t even exist! 

So the need for an extension use case is driven by separate concerns or goals, of different stakeholders, that are perpendicular to each other and intersect only at a single condition or event in a base use case, that is of interest to both. The goal of an extension use case cuts across (is perpendicular to) the goal of any use case it extends. This is represented visually in the diagram below.


I believe that’s why Jacobson states that the base use case has “become oblivious” of the extension use case (the extension use case in no way contributes to the goal of the base use case), and why the UML description states that “the [base] use case is defined independently of the [extension] use case and is meaningful independently of the [extension] use case” (in the eyes of the base use case’s initiating actor, who doesn’t necessarily know the extension use case exists). 

In fact, a base use case doesn’t even know whether it’s being extended at a given extension point, let alone by which extension use case!

In [4] Jacobson relates an interesting exchange he and James Rumbaugh had when they were working on UML 1.1. In Jacobson’s example mentioned above, the base use case is an open book and the extension use case defines the extension point by referring to a specific step in the base use case. Rumbaugh saw this as “breaking encapsulation” of the base use case (referring to its inner details from the outside). 

To avoid this he suggested that an extension point “belongs to” the base use case, not to the extension use case. Thus the extension use case would only see the base use case’s public extension point and be “oblivious” of the base use case’s private details. “If you changed the [base] use case, [Rumbaugh] said, only that use case would know the [extension point’s] new location.” Jacobson concludes, “I agreed with him.”

So not only is a base use case “oblivious” of the existence of an extension use case, an extension use case is also “oblivious” of the internals of a base use case it extends.

Part 2 of this article elaborates on this. 

In conclusion

This “archeological dig” revealed to me that the extension use case is a more specialized construct than commonly suggested. Part 2 of this article increases that notion and deals with some of the consequences of this narrower view of extension use cases.


The term “base use case” only applies in the context of a use case relationship (e.g., in the context of an extend relationship, it refers to the extended use case). For ease of reference, I have used the term here also to refer to a ‘candidate’ base use case, even when, after further consideration, it doesn’t end up being an extended use case.


[1] Object Management Group (OMG), OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.4.1, Section 16.3.3, Description.

[2] Alistair Cockburn, Writing Effective Use Cases, 12th Printing, November 2004.

[3] Ivar Jacobson, Use Cases and Aspects – Working Seamlessly Together, Journal Of Object Technology, Vol. 2, No. 4, July-August 2003.

[4] Ivar Jacobson, Use Cases: Yesterday, Today, and Tomorrow, 20 November 2003, found at http://www.ibm.com/developerworks/rational/library/775.html (page no longer exists; see: http://www.spinsp.org.br/grupo/Future_%20of_Cases.pdf).