In a use-case model, sometimes several use cases model the same kind of usages. For example, there will be different kinds of account transactions in an ATM, such as deposit and withdrawal, or different kinds of telephone calls between subscribers in a telephone exchange. To capture that a collection of use cases model the same kind of usage of the system, we introduce a new use case into the model. In this new use case, we provide a general description of this kind of usage, stating that it describes the commonalities and the general pattern of this usage. Then we define generalization relationships from the other use cases to this new use case stating that they are specializations of the new use case (see Figure 11.1). The use case capturing the commonalities is called the parent use case, and the specializing use cases are called the children, just as with ordinary generalization relationships. However, it is important that all the children express the same kind of usage of the system as the parent, because in UML, generalization is a taxonomy relationship.
Figure 11.1. Classification of use cases using generalization to the use case expressing the commonalities. Because the parent use cases are abstract in these two examples, their names are in italic.
Usually such a parent use case is abstract; that is, it is not instantiable on its own. It is only used to capture the common nature of its children.
In this way, the model becomes easier for the readers to understand because they can immediately discern the commonalities. Another advantage is that the children use cases do not have to duplicate things described in the parent use case, which means that their definitions do not have to start from scratch. Another way of putting this is to say that we enforce the sequence of actions from the parent use case onto the children; that is, the children must exhibit the same kind of usage as the parent. When capturing the requirements of, say, the ATM system, we can, by use of the generalization, require that the Deposit Money and the Withdraw Money use cases must follow the same kind of sequence of actions, and this sequence is defined in the Perform Transaction on Account use case. This means that the children use cases include the same behavior as the parent. In the children use cases, we can specialize that behavior as well as add new behavior, as long as the children are still modeling the same kind of usage as the parent (see Figure 11.2). However, on no account must we remove behavior in a child use case or reorganize the sequence of actions.
Figure 11.2. The sequence of actions of Withdraw Money starts and ends as described in Perform Transaction on Account, and specializes the middle part. The headings do not add any behavior, but only serve to clarify the structure.
Note, finally, that a generalization between two use cases implies that the whole parent use case is inherited—that is to say, not only the normal flow, but also all the alternative flows are inherited. If only part of the parent is to be reused, generalization is not the correct relationship. Instead, consider extracting that particular part into a separate use case and use an include or an extend relationship between the two old use cases and the new use case.
In the description of a child use case, we may choose between two ways of describing the actions defined in the parent. Formally speaking, all the actions of the parent appear in the child as well. However, we do not duplicate the description of what is defined in the parent unless needed (cf. generalization between classes). For use cases, this usually means that the description of the child use case includes some kind of references to the description of the parent use case implying that this specific piece of behavior described in the parent use case is to be performed here in the child (see Figure 11.2).
In the use-case descriptions in Figure 11.2, we have included extra headings into the text. These have no formal meaning, and add nothing to the flows themselves, but are added to make it easier to see the common structure of the flows. This is entirely optional, of course, but may in fact prove useful in more situations than just use-case generalizations. When a use-case description is long, for example, inserting headings such as these can be very useful to readers as well as writers of the description.
When the interleaving of reused and new/redefined text is very fine-grained, it is sometimes more efficient for both the reader and the writer if the description of the parent is in fact duplicated in the child, and then any new behavior is inserted into the description, and any specializing behavior replaces corresponding inherited behavior.