The Include Relationship’s Other Use
Introduction
Article [1] outlined the primary use of the include relationship, in which a common set of steps in the specifications of two or more existing use cases are factored out as the specification of a new abstract use case, after which the common steps in the specifications of the existing use cases are replaced with an include relationship to the abstract use case. This article explores the include relationship’s secondary use, where an already existing concrete use case is included in another use case. Throughout, the two patterns are compared and contrasted.
The include mechanism
As per [1], when a concrete base use case includes an abstract use case, it means that at run time the specifications of the two use cases are combined into a single use case specification that governs the behavior of each use case instance in the base use case; the base use case is instantiated, but the included use case is not.
This mechanism follows from the fact that the include relationship is a single relationship between two use case specifications; it does not represent a class of relationships (links) between use case instances, as does an association between two use cases.
The other use
The description under ‘Semantics’ in section 16.3.5 of [2] gave me the impression that the include relationship is solely intended “for reuse of common parts”, that is, for reuse of abstract included use cases (use case fragments, really), as described in [1]. Since that section doesn’t describe any other use, this impression came easily.
However, an overseas colleague (see Acknowledgement below) pointed out that the section describes this as the ‘primary’ use, so there must also be a ‘secondary’ use, at the very least. As for what that secondary use might be, he pointed to [3] which states that “concrete use cases can […] be included in a base use case.”
That had me puzzled, because didn’t that mean that such an included use case would at the same time have to be concrete (in its own right, capable of being instantiated) and abstract (as an included use case, which doesn’t get instantiated)? Clearly, that is impossible.
(I share this mental block in case others suffer from it as well; the remedy follows.)
Remember the mechanism
The resolution came when I expressed this secondary use in terms of the include mechanism summarized above (substitution in bold):
In other words, the fact that during the execution of a base use case neither an abstract included use case nor a concrete included use case gets instantiated, is inherent in the include relationship; it has nothing to do with the included use case being abstract or concrete.
(I feel a lot better now.)
Further considerations
Stay within the system boundary
Article [1] pointed out that include relationships cannot cross system boundaries. Therefore, just like an included abstract use case, an included concrete use case must belong to the system to which the including use case belongs.
This is simply the flip side of the statement in section 16.3.6 of [2], “Two use cases specifying the same [system] cannot be associated since each of them individually describes a complete usage of the [system].”
- Two use cases of a given system can be connected via an include relationship, but not through an association.
- Two use cases of different systems can be connected via an association, but not through an include relationship.
In other words, include relationships can only exist within a system boundary and associations can only exist across a system boundary.
Another way to look at this is by realizing that a system encapsulates (does not disclose) its use case specifications. These are for the system’s internal use only, that is, they are used ‘behind’ the system’s public interface. Defining an include relationship across system boundaries would amount to breaking that encapsulation and is therefore inappropriate.
For more on the need to define the system(s) to which use cases apply, see [4].
Include relationship or precondition?
Article [5] distinguishes functional and sequential dependencies between concrete use cases.
- A functional dependency can be represented by an include relationship between two concrete use cases.
- A sequential dependency can be represented by one or more postconditions (of the ‘upstream’ concrete use case) and corresponding preconditions (of the ‘downstream’ concrete use case), rather than by an include relationship from the latter to the former.
Concrete use case can be instantiated
A concrete use case that’s also included in a base use case can be instantiated (after all, that’s what defines a concrete use case), but only when it’s initiated by an instance of its initiating actor, outside the context of the base use case in which it is included. At such times, the include relationship between the two is irrelevant.
- The base use case is functionally dependent on the concrete use case, but the concrete use case is not functionally dependent on the base use case.
- Hence, any concrete use case instance is governed by the concrete use case’s specification, without any reference to the base use case’s specification.
Which actor and user?
A user (Alex) instantiates a concrete use case (UC1). In the context of the resulting use case instance, any mention of “the actor” in the use case’s specification is a reference to that user (Alex, an Assistant). When another user (Megan) instantiates a second concrete use case (UC2) that includes the first concrete use case (UC1), the specifications of the two use cases combine into a single run time specification for the including concrete use case (UC2). In the context of the resulting use case instance, any mention of “the actor” in the included use case’s specification now is a reference to the other user (Megan, a Manager). See the following diagram.
Writing tip
Because of the above, when writing use case specifications, use “the actor” as the standard way to refer to a use case’s initiating actor (*). In terms of the above example:
- Don’t write “the Assistant” in the UC1 specification and “the Manager” in the UC2 specification, because that might suggest that a Manager temporarily switches to the role of an Assistant for the duration of the UC1 steps included in UC2, which of course is not so.
- Which roles a given user can play, that is, to which actors a given user can belong, is solely part of modeling and defining those actors.
(*) Supporting actors are best referred to by name in order to tell them apart from the initiating actor (“the actor”) and from each other (when there are several).
Included use case varieties
Article [1] makes the point that abstract included use cases come in two varieties. These apply to concrete included use cases as well, as follows (see [4] for the stereotypes (*) used below).
- An included <
> use case ends up being a textually included concrete included use case, because it represents a back-and-forth interaction between “the actor” and “the system” during which input data is provided, system data is retrieved, both can be transformed, output data is returned and system data is stored, step by step (i.e., it’s about the steps as well as the ultimate result). - An included <
> use case ends up being a parameterized concrete included use case, because it accepts one or more input parameters, returns one or more output parameters, and encapsulates (hides) the steps that transform the former into the latter (i.e., it’s about the ultimate result, not about the steps that lead to it).
(*) Even though a <
Other points
Article [1] makes additional points about abstract included use cases that apply equally to concrete included use cases, as follows:
- Concrete included use cases may be optional. For the reasons outlined in [1].
- Concrete included use cases are not intended for functional decomposition. Including a use case, whether abstract or concrete, amounts to partial functional decomposition of the base use case, but the point is that the included use case wasn’t created for functional decomposition (see table above).
Implementing the include relationship
Article [1] and this article deal with how to understand and use the include relationship as reflected in the UML, where the distinction between classes and instances and the difference between associations, links and relationships are fundamental. Translating the include relationship to constructs in implementation environments depends on the characteristics of those environments and is outside the scope of these articles.
In conclusion
By definition, a concrete use case can be initiated (instantiated) by users (actor instances) outside the system to which it belongs. On the other hand, including a concrete use case represents the direct or indirect inclusion of its specification in the specification of another concrete use case within the system to which they both belong, such that the including concrete use case gets instantiated (as a result of being initiated by a user) but the included concrete use case does not (because it only lends its specification to the including concrete use case).
This pattern can be used, for example, when modeling a component with a number of service use cases, so that a smaller service use case, representing a reusable public service in its own right (e.g., validate credit card), may be included in a larger service use case (e.g., place order).
This article was submitted in the hope that it will contribute to a comprehensive understanding of the include relationship.
Don’t forget to leave your comments below.
Acknowledgement
My thanks to Piermarco Burrafato for bringing this secondary use to my attention.
References
[1] Willem Van Galen, Putting The Inclusion Use Case In Focus, 21 August 2012.
[2] Object Management Group (OMG), OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.4.1.
[3] Ivar Jacobson, Use Cases: Yesterday, Today, and Tomorrow, 20 November 2003.
[4] Willem Van Galen, The System: Don’t Model A Use Case Without It!, 11 September 2012.
[5] Willem Van Galen, Use Case Preconditions: A Best-Kept Secret?, 15 October 2012.