- Typically, and in this example, this pattern is about different stakeholders, but perhaps there are situations where both goals have the same stakeholder.
I use the term ‘deviation extension’ to indicate that the goal of the extension use case deviates from (is at odds with) the goal of the extended use case, albeit without the extended use case knowing so.
- The ‘deviation’ extension use case’s goal can also said to be ‘perpendicular’ to the extended use case’s goal, in the sense that it ‘cuts across’ that goal (see ).
- In the next diagram, this is emphasized by drawing the two use cases at a right angle of each other and by using the <<deviation>> stereotype.
Regarding the following diagram, which is based on Ivar Jacobson’s example in :
- The Call Handling use case allows a user to make a phone call. The use case starts when the user lifts the receiver off the hook (the example is from 1979).
- The conditional Traffic Recording use case counts the phone call being made, but only when traffic must be recorded.
In other words, a call can be counted, but this behavior is non-essential to completing the Call Handling use case.
Key observations about this pattern are provided after pattern 4.
Pattern 4: User’s Goal = Use Case Goal + Augmentation Extension Use Case Side Goal
This is the pattern where the initiated use case pursues part of a larger user goal and, unbeknownst to itself, is augmented by an extension use case that represents another part of that larger user goal.
- This pattern is typically about situations where both goals have the same stakeholder.
I use the term ‘augmentation extension’ to indicate that the goal of the extension use case augments (is incremental to) the goal of the extended use case, albeit without the extended use case knowing so.
- The ‘augmentation’ extension use case’s goal can also said to be ‘linear’ to the extended use case’s goal, in the sense that it ‘falls in line’ with that goal.
- In the next diagram, this is reinforced by drawing the two use cases horizontally in line with each other and by using the <<augmentation>> stereotype.
Regarding the following diagram (i):
- The Bonus Employee use case allows a user to specify a one-time bonus for an employee. The use case enables the user to provide the employee’s id, to correct it when necessary, to provide the bonus amount and description, and to complete or cancel the transaction.
- The conditional Verify Employee Id use case provides the user with the employee name for the employee id provided.
In other words, the user can choose to verify the employee id, but this behavior is non-essential to completing the Bonus Employee use case.
On patterns 3 and 4
The following observations about patterns 3 and 4 apply in the end to the extension use case construct in general.
In summary, an extension use case always represents a side goal to the extended use case’s goal (the former is not nested within the latter).
These four patterns (see article’s part 1 for the first two) result from ‘separating concerns’, which in this case requires recognizing the difference between:
- User goal vs. use case goal;
- User goal vs. off-stage stakeholder goal;
- Sub goal vs. side goal;
- Deviation extension vs. augmentation extension.
DEVIATION EXTENSION USE CASE VS. AUGMENTATION EXTENSION USE CASE
In keeping with the article’s theme, this section compares and contrasts the notions of ‘deviation’ and ‘augmentation’ extension use cases introduced above.
TO BE CONTINUED
Part 3 compares and contrasts a few more pairs of use case model elements and explores whether use cases can be instantiated in their capacity as included, extending and generalization use cases.
Don't forget to leave your comments below.
(i) The comments added to [1.2] introduced the example of a word processing application with an extended use case Edit Document and an extending use case Check Spelling. Even though this could serve in principle as an example of an ‘augmentation’ extension, it is purposely avoided here, for the following reasons.
- I doubt it’s a good idea to use a use case model to represent a word processing application, because while use cases are great for modeling sequential processes, they seem to be less than ideal for modeling event-driven processes like those of a word processing application (not to be confused with the loose/event-driven coupling of sequential processes detailed in ).
- Marking extension points in a predefined sequential process is straightforward, but doing so in an event-driven process is pretty well impossible, because there is no predetermined sequence of steps a user must take.
[1.1] Willem Van Galen, Excavating the extension use case, Part 1, 10 July 2012.
[1.2] Willem Van Galen, Excavating the extension use case, Part 2, 24 July 2012.
[1.3] Willem Van Galen, Excavating the extension use case, Part 3, 12 March 2013.
 Ivar Jacobson, Use Cases and Aspects – Working Seamlessly Together, Journal Of Object Technology, Vol. 2, No. 4, July-August 2003.
 Object Management Group (OMG), OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.4.1.
 Willem Van Galen, Modeling Loosely Coupled Use Cases, 30 April 2012.