Comparing and Contrasting Use Case Model Elements Part 3

Written by Willem Van Galen on December 3, 2013. Posted in Articles.

INTRODUCTION

This final part of the article compares and contrasts three more pairs of use case model elements, and suggests that use cases are not instantiated in their capacity as included, extending and generalization use cases.

EXTENSION USE CASE VS. OPTION FLOW

The ‘extension use case’ concept is explored in [1] and in section ‘Instantiating Included and Extending Use Cases?’ below.

The ‘option flow’ idea is introduced in [2] and further referenced in [1.3].

In summary:

It seems to me that the use of the extension use case to represent conditional behavior whose outcome is reflected in the postconditions of the extended use case, is actually an antipattern (i).
As Jacobson writes in [3], “The base use case must be complete by itself and not require the extension. Otherwise, you must use alternative paths to describe additional behavior.”
When such conditional behavior is non-essential to the extended use case (i.e., the use case can achieve its goal without the behavior), option flows are those “alternative paths”.

EXTENSION USE CASE VS. SUBSCRIBER USE CASE

The ‘extension use case’ concept is explored in [1] and in section ‘Instantiating Included and Extending Use Cases?’ below.
The ‘subscriber use case’ and ‘publisher use case’ notions are introduced in [4].

Article [1.2] provides a rationale for why base & extension use cases don’t reflect Event-Driven Architecture, while publisher & subscriber use cases do.

INSTANTIATING INCLUDED AND EXTENDING USE CASES?

Where I encountered the idea

In [3], Jacobson seems to suggest that during the execution of a concrete base use case an included or extending use case can be instantiated, as follows.

When a user initiates the concrete base use case, it gets instantiated;
At an inclusion point in the base use case, the included use case gets instantiated as well;
At an extension point in the base use case, the extending use case gets instantiated as well.

This impression is based on:

The statement, “Concrete use cases can extend a base use case or be included in a base use case.” (ii)
The definition of concrete extension and inclusion use cases as use cases that “interact with and provide value to actors” and that have “significant behavior”.

At first blush, I’m not won over by this definition, as it seems arbitrary:

Abstract extension and inclusion use cases can also “interact with and provide value to [users]”; they just can’t be initiated (instantiated) by them.
Obviously, “significant” is a subjective term.

More important, the UML doesn’t seem to support the notions of a concrete extension use case and a concrete inclusion use case (where ‘inclusion use case’ refers to a use case fragment as defined in [5.1], not to an included use case that’s concrete in its own right as discussed in [5.2]).

The following sections explore this in more detail.

Extension use cases in the UML

Key excerpts of chapter 16.3.3 in [6] are:

An extended use case has an “extension location”, which is an “ordered list of extension points […] specifying where the respective behavioral fragments of the extending use case are to be inserted.”
An extension use case “consists of one or more behavior fragment descriptions that are to be inserted into the appropriate spots of the extended use case.”

The paragraph after that states:

“The individual fragments are executed as the corresponding extension points of the extending use case are reached. Once a given fragment is completed, execution continues with the behavior of the extended use case following the extension point. Note that even though there are multiple use cases involved, there is just a single behavior execution.”

No concrete extension use cases, then

The preceding leaves me with the following impression.

An extension use case isn’t meant to be concrete, because its specification is nothing more than a bunch of “behavior fragment descriptions”, whose only purpose is “to be inserted into the appropriate spots of the extended use case [specification]” (it’s not meant to represent the full life cycle behavior of an independent extension use case instance).
In other words, an extension use case’s specification only makes sense in the context of the behavior of the extended use case, and only to the extent that the extended use case’s extension points reveal clues about that behavior (the rest of the behavior is encapsulated in the extended use case).
Moreover, the quote’s concluding note reinforces the notion that at execution time there is only one use case instance (“just a single behavior execution”), which, of course, is an instance of the concrete use case the user initiated and whose specification is, in this case, combined with the specification of the extension use case, as described in detail in [6] (the extension use case isn’t instantiated).

See (iii) for additional comments on [3] and event-driven use case coupling.

Directed relationships in the UML

More generally, in [6] the include, extend and generalization relationships are different types of directed relationship. They are relationships between use cases, but as the above shows, they are fundamentally (at modeling time and execution time) about connections between the specifications of the related use cases; they are not about links between instances of the related use cases (at execution time), because that’s what associations are for (at modeling time).

Functional dependencies

These relationships represent functional dependencies between the specifications of the related use cases, as summarized below (initiating actors omitted for brevity).

The diagram shows the included, extending and generalization use cases as abstract. However, it’s not their abstract nature, but their capacity as included, extending and generalization use cases, that determines they won’t be instantiated.

The remaining question, “can an included, extending or generalization use case be a concrete use case outside its capacity as a related use case?”, is explored below and in [5.2] and [7].

No instantiation of included, extending and generalization use cases, then

Based on this reading:

I don’t see how it’s possible or necessary to instantiate a use case in its capacity as an included, extending or generalization use case.
An included use case and a generalization use case can be concrete in their own right, but I cannot think of any situation in which an extending use case can be concrete in its own right; it seems that an extending use case is always abstract.

FUNCTIONAL DEPENDENCY VS. SEQUENTIAL DEPENDENCY

Before concluding the article, this section compares and contrasts ‘functional’ and ‘sequential’ dependencies between use cases. These are detailed in [8] and [5.2].

Note that the following applies to dependencies between use cases within a given system, not between use cases of different systems (iv).

In summary, being able to recognize and model sequential dependencies between use cases is likely to reduce the use of relationships between use cases as compared to viewing and modeling every dependency as a functional one (e.g., including the ‘Sign In’ use case in every concrete use case that requires a user to be signed in).

IN CONCLUSION

It is my hope that this article helps to underline the unique purpose of each of the referenced use case model elements, is instructive in deciding when to use them, and promotes greater consistency across use case models (that is, system models…).

NOTES

(i) An example of this antipattern is:

The Place Order use case is extended by the Apply Discounts use case.
The Place Order use case’s postconditions state that one or more discounts may have been applied (e.g., “For each approved discount, the order’s pre-tax total amount has been reduced by the discount amount”).

This is an antipattern because Place Order is oblivious of Apply Discounts and therefore neither knows about discounts nor can refer to them in its postconditions.

If Apply Discounts were to be maintained as an extending use case, any mention of discounts would have to be removed from Place Order’s postconditions, because applying discounts could not possibly be a sub goal of Place Order’s goal; however, the fact that Apply Discounts would have to update Place Order’s ‘pre-tax total amount’ disqualifies it from being an extending use case (see section ‘On patterns 3 and 4’ in part 2 of this article).
So, discounts must be mentioned in Place Order’s postconditions and Apply Discounts must be represented as an option flow, making applying discounts an optional sub goal of Place Order’s goal.

(ii) Article [5.2] deals with including a use case that’s already a concrete use case in its own right, but the questions this section pursues are:

In its capacity as an included use case, can a concrete use case be instantiated?
Can an extending use case be a concrete use case in its own right?
Can an extending use case be instantiated at all?

(iii) Figure 2 in [3] is about a quasi event-driven connection between the concrete use cases Conduct Transaction and Inspect Transaction Failures.

The extending use case Register Failures ‘publishes’ an ‘event’ (of type ‘transaction failed’) that occurred in the extended use case Conduct Transaction.
The ‘special’ dependency (without a definite stereotype) between the concrete use case Inspect Transaction Failures and use case fragment Register Failures represents that Inspect Transaction Failures is a ‘subscriber’ to the ‘events’ that are ‘published’ by Register Failures.

That being so, I’d model this connection using the Event-Driven Architecture approach outlined in [4] instead, for the following reasons.

Figure 2 of [3] deals with exception events; the approach in [4] is first of all about normal events, but can handle exception events just as well (why have two approaches for the same pattern?).
Figure 2 of [3] shows a ‘dependency trail’ from Inspect Transaction Failures, via Register Failures, all the way back to Conduct Transaction (tight coupling); using the approach in [4], there is no dependency between a subscriber use case and any ‘upstream’ use cases, because a subscriber use case is only interested in events, independent of the use case(s) that published them (loose coupling).

In Figure 2 of [3], the publication of events is handled by an extension use case; in the approach in [4], the publication is part of the use case that encounters them. Reasons for favoring the latter pattern include the following.

Publishing an event typically means including event data in the published event object; such data is, of course, readily accessible by the use case that encounters the event, but is not necessarily accessible, or easily accessible, by a separate extension use case of that use case.
Depending on how widely the approach gets used, the number of ‘publisher’ extension use cases could get large and use case diagrams could look cluttered.

In the end, it’s a matter of preference, because both approaches work.

(iv) A use case of a given system is functionally dependent on a use case of another system when the other system is a supporting actor of the given system’s use case; this dependency is shown as an association that crosses the system boundaries and ought to be detailed in the given use case’s specification (e.g., “The system initiates of ”).

Don’t forget to leave your comments below.

REFERENCES

[1.1] Willem Van Galen, Excavating the extension use case, Part 1, 10 July 2012, http://www.batimes.com/articles/excavating-the-extension-use-case.html

[1.2] Willem Van Galen, Excavating the extension use case, Part 2, 24 July 2012, http://www.batimes.com/articles/excavating-the-extension-use-case-part-2.html

[1.3] Willem Van Galen, Excavating the extension use case, Part 3, 12 March 2013, http://www.batimes.com/articles/excavating-the-extension-use-case-part-3-nuance.html

[2] Willem Van Galen, Use Case Goals, Scenarios and Flows, 13 November 2012, http://www.batimes.com/articles/use-case-goals-scenarios-and-flows.html

[3] 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).

[4] Willem Van Galen, Modeling Loosely Coupled Use Cases, 30 April 2012, http://www.batimes.com/articles/modeling-loosely-coupled-use-cases.html

[5.1] Willem Van Galen, Putting The Inclusion Use Case In Focus, 21 August 2012, http://www.batimes.com/articles/putting-the-inclusion-use-case-in-focus.html

[5.2] Willem Van Galen, The Include Relationship’s Other Use, 18 June 2013, http://www.batimes.com/articles/the-include-relationships-other-use.html

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

[7] Willem Van Galen, Generalization and Use Case Models, Part 2, 2 September 2013, http://www.batimes.com/articles/generalization-and-use-case-models-part-2.html

[8] Willem Van Galen, Use Case Preconditions: A Best-Kept Secret?, 15 October 2012, http://www.batimes.com/articles/use-case-preconditions-a-best-kept-secret.html