Separate mandatory parts of the use cases from optional parts that can be ordered and delivered separately.
Characteristics: Common. Basic solution.
Keywords: Ordering unit, separating services, system configuration, system version.
The Optional Service: Addition pattern contains two use cases and an extend relationship. The first use case models a usage that is compulsory in the system. The second use case models an addition to the first use case that can be added to the system. Because only the additional part is expressed in the second use case, it is abstract; that is, it will not be performed on its own. The complete use case—the compulsory behavior together with the optional behavior—is formed by the aggregation of the two, expressed by the extend relationship.
This pattern is preferred when the optional part is a pure addition to the compulsory use case.
In another Optional Service pattern, the compulsory use case is specialized into a use case including the optional part.
We choose this pattern when the compulsory use case includes a simple form of the optional behavior. The child use case will specialize this simple part into the optional, more advanced behavior.
From a configuration point of view, it would be disastrous to mix mandatory and optional parts. The mandatory parts will always be delivered, whereas the optional parts will be delivered only when they have explicitly been ordered. Therefore, these parts must be separated, not only in the code but also in the models, because the models are also deliverables.
More generally speaking, parts with different ordering criteria must be separated because they are not always to be delivered together. Moreover, two parts may both be mandatory, but at the same time also be alternatives to each other, or in other words, be mutually exclusive. For example, a sailing boat may have either a steering wheel or a tiller, but sailing boats with both types of steering equipment are very rare. Still, it is mandatory to have one of the two facilities, each of which will have its own ordering criteria. In the following discussion, we distinguish only between compulsory parts and optional parts, even though the arguments are the same for handling parts with different ordering criteria.
Because one usage of a system often spans over several parts of it, it is quite common that both mandatory and optional parts of the system will be employed. This means that use cases often contain both mandatory and optional parts in the first draft of the use-case model. However, it must be possible to deliver a version of the model that covers only what a particular customer has ordered. The optional parts must therefore be extracted from the mandatory use cases and be put into separate use cases in the final version of the use-case model. In this way, a mandatory use case will contain only actions that every installation of the system must have, and the optional parts can be included upon request.
So, how do we model that the optional parts may be added to the mandatory use cases? Clearly, the most obvious way is to use extend relationships from the optional parts to the mandatory parts as in the Optional Service: Addition pattern (see Figure 24.1). This implies that one configuration of the system can contain only the compulsory service, and another configuration has the more advanced one consisting of the compulsory part extended with the optional part. This is one of the original purposes of the extend relationship: It makes it possible to add to an already existing model additional parts having other, less-compulsory ordering criteria, without any changes of the existing parts.
Figure 24.1. The automatic spell checking of a text is treated as an optional part of the system. Hence, it is extracted into a separate, abstract use case with an extend relationship to the Edit Text use case.
In a typical text editor, there is one use case modeling entering and modification of the text. An optional service that may be included, possibly depending on how much the writer paid for this configuration of the editor, is automatic spell checking. At the same time the writer enters or modifies the text, the editor will look for spelling errors. Because it is not included in all versions of the system, those parts that deal with the spell checking are extracted into a separate use case with an extend relationship to the
Edit Textuse case (see Figure 24.1).There is, of course, more behavior involved in spell checking, such as an administrative use case for defining new words. All these use cases, including the abstract
Automatic Spell Checkinguse case, can be grouped together in a package representing the entire spell checking service.
Another alternative way of handling optional behavior is used when the system always has to include the function: either in a simple or in a more advanced form. In this case, the simple version of the function is modeled with one use case, and the more advanced function as another use case. Because the more advanced version is a specialization of the simple, a generalization is introduced from the advanced use case to the simple use case, according to the Optional Service: Specialization pattern. In the basic configuration of the system, the simple use case (the parent), is included and the child use case, which models the advanced form of the function, is included in the more advanced configuration of the system.
Assume that the text editor will always include the automatic spell checking service, but what is done when an error is found may differ. The simplest and most straightforward way is to decorate the erroneous word in some way so that the writer understands that the word is misspelled and can correct it. An optional alternative is to automatically correct the word, if possible (see Figure 24.2).
Figure 24.2. The spell checking is mandatory in the system, but it can be performed in two different ways. Therefore, the two use cases are variants of each other, and only one of them should be used in one installation of the system.
Each time someone buys a copy of the text editor, he or she has to choose between the
Edit Text with Automatic Decoration of Misspelled Wordsuse case and theEdit Text with Automatic Correction of Misspelled Words. Both of them must not be used in the same installation.
In a variant of this model, the function itself is modeled as one use case, the parent use case, and the different versions of it as separate child use cases. This alternative is recommended when there are multiple versions of the functions and there is no one version that can be seen as the parent of all the different versions (see Figure 24.3).
Figure 24.3. The function itself is modeled as a separate, abstract use case (the parent), and the different versions of the function are modeled as children of this use case.
In some cases, the optional parts are unrelated to the obligatory ones; that is, they neither extend nor form special cases of the obligatory use cases. An optional part may, for example, compute and present additional statistics, which is unrelated to other usages of the system. In such cases, the Optional Service: Independent pattern is applied resulting in the optional usages modeled as separate use cases with no relationships to other use cases in the model.
It is imperative that we do not confuse the term optional from a configuration point of view with a conditional usage of a part of the system. The purpose is not to extract all the conditional branches defined in a use case and define them in separate use cases (which would be altogether incorrect). Only those parts that are not to be included in every configuration of the use case should be extracted. Note that these parts are not even necessarily located in conditional branches. Note also that this pattern is applicable when a service is mandatory, but there is a choice between variants of it; that is, each configuration of the system must have the service, but there are different variants of that service.
This section provides an example of the Optional Service: Addition pattern and presents two examples of use-case descriptions: Create Order and Restock Item. A Clerk will use the Create Order use case to register a new order in the system. The Restock Item use case is an example of an optional addition to the Create Order use case, adding an automatic check of the number of items remaining in stock, comparing this number with a threshold value, and if needed generating a restock order (see Figure 24.4).
Figure 24.4. The mandatory use case Create Order is extended with the optional use case Restock Item.
Here, the Message Transfer blueprints are useful, and the CRUD patterns should also be considered.
As pointed out previously, the optional parts should be expressed in separate use cases that have some kind of relationships to the mandatory use cases. This is true in the analysis model as well (and in all other models that follow the analysis model). Operations, attributes, and associations originating in the optional use cases should be captured by optional classes that can be added or removed without affecting the mandatory classes. This should at least be a high-priority requirement when producing the analysis model. As made clear more than 10 years ago (see, for example, the book Object-Oriented Software Engineering, Jacobson et al. 1993), it is possible and fruitful to use the same technique with extend relationships between classes as we have done for use cases (see Figure 24.5). The semantics and the pragmatics of the relationship between classes are the same as those of the relationship between use cases.
If you do not want to introduce extend relationships in your model as described above, you can instead use either a generalization or an ordinary association (see Figure 24.6). You will still have localized the optional part mostly to new, optional classes.
Figure 24.6. Two other techniques for adding additional features to mandatory classes, each with its own drawbacks.
However, there are drawbacks with both alternatives. Replacing the extend relationship with a generalization will force you to replace all the existing instances of the superclass (subclass) with instances of the subclass (superclass) if you add (remove) the optional service to (from) a system that is already in use.
On the other hand, using an association instead implies that you will have to modify the mandatory class to which the association is connected, because it will now have a new association and will have to communicate over this association to initiate the optional class. (This comes for free with the extend relationship because there will still be only one instance.) Moreover, the context, or the namespace, in which the association is defined will also have to be modified.
An extend relationship on the other hand is owned by the client—the optional class—and it extends the already existing instances.