Excavating The Extension Use Case – Part 3 Nuance

Introduction

Article [1] outlined two considerations for determining whether nonessential use case behavior can be represented as an extension use case, or not. Article [2] introduced a new kind of use case flow for representing nonessential behavior that cannot be represented as an extension use case. In that context, this article adds a further consideration about an aspect not discussed so far. The three considerations are thought to cover most, perhaps even all, possible situations for representing nonessential behavior in a use case model.

Review

The nonessential use case behavior at the heart of this article is behavior that can be executed during a use case’s execution, but that is not essential to reaching the use case’s goal; it can be skipped without affecting the use case’s ability to reach its goal.

Article [1] placed two conditions on representing such behavior as an extension use case of a given use case, which is then called the base use case:

1. The behavior must in no way contribute to the base use case’s goal.
2. The behavior must not require access to the base use case’s private data.

Article [2] introduced the option flow concept to represent nonessential behavior that doesn’t meet the above conditions.

These initial aspects are summarized in the following table.

Additional nuance

When nonessential behavior in some way contributes to the use case’s goal, the primary reason for representing it as an option flow (*) is to ensure that its result is accounted for in the use case’s postconditions, which would have been impossible had the behavior been represented as an extension use case (see [2] for details).

(*) The secondary reason for representing it as an option flow is when it accesses the use case’s private data, which an extension use case can’t (see [2] for details).

This article adds a nuance to the understanding of nonessential behavior that in some way contributes to a use case’s goal, by recognizing two kinds of such behavior:

1. The ‘stated contribution’ kind, where the behavior’s contribution is stated as part of the use case’s postconditions, which define how to measure that the use case’s goal has been achieved.
2. The ‘unstated contribution’ kind, where the behavior’s contribution is not stated as part of the use case’s postconditions, and thus plays no role in measuring whether the use case’s goal has been achieved.

The Coupon option flow in [2] is an example of ‘stated contribution’ behavior, where the use of a valid coupon results in an order discount. 

• This must be stated in the use case’s postconditions so it can be part of measuring whether the use case’s goal has been achieved.

Examples of ‘unstated contribution’ behavior are the Check Spelling, Change Template and Find Synonym extension use cases mentioned in [3] as extension use cases of the Edit Document base use case.

• Whether a user of the Edit Document use case corrected the spelling or not, and if she did, whether she used the Check Spelling behavior or spotted and corrected the mistake herself, is unlikely to be stated in the Edit Document use case’s postconditions. The same goes for the other examples.
• Therefore, and assuming the edited document is considered public data, the Check Spelling, Change Template and Find Synonym behaviors can be represented as extension use cases, because even though they contribute to the Edit Document use case’s goal, their result plays no role in how the achievement of that goal is measured.

The result of combining this consideration with the aspects mentioned earlier is shown in the following table.

Note: If you want to avoid the use of an extension use case altogether, you can use an option flow for situations 1 and 5 instead.

Checking against the UML

Even an extension use case that makes an unstated contribution to the base use case’s goal, still upholds the statement in section 16.3.3 of [4] that “the [base] use case is defined independently of the [extension] use case and is meaningful independently of the [extension] use case.” In other words, the base use case in no way depends on the extension use case to reach its goal, according to how the goal’s achievement is defined by the base use case’s postconditions.

In conclusion

How often we may encounter nonessential ‘unstated contribution’ behavior remains to be seen. It might depend on the kind of application being modeled (e.g., the above examples are related to a word processing application). Such behavior may be less prevalent in transaction-oriented applications, such as a webstore application, which is implied in the Coupon option flow in [2].

In any case, it is my hope that this article and the referenced ones will help towards distinguishing essential behavior from nonessential behavior, and representing each in a use case model with clarity, consistency, and conformance to the UML.

Note

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.

References

[1] Willem Van Galen, Excavating the extension use case, 10 July 2012, (Part 1) and 24 July 2012, (Part 2).

[2] Willem Van Galen, Use Case Goals, Scenarios and Flows, 13 November 2012.

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

[4] Object Management Group (OMG), OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.4.1.

Don’t forget to leave your comments below.