Provide different views of the flows of a system that are perceived differently by different stakeholders.
Characteristics: Not so common. Advanced solution.
Keywords: Different reader categories, internal structure of use-case model, level of abstraction, multiple descriptions, user view of use-case model.
The Orthogonal Views: Specialization pattern consists of one use case and a collection of specializations of that use case. The former (the parent use case) models what is actually performed inside the system, whereas each one of the other use cases (each of the children use cases) models one specific usage of the parent use case as it is perceived by the user.
This pattern is suitable when the use-case model should make explicit that several different usages of the system are special cases of a general usage of the system and they are all to be performed in the same way internally, although perceived differently by the user.
In some situations, a use case includes much more behavior than the users of the system perceive. In this alternative, we model the use case as a single use case with the extra behavior described in separate sections of the use-case description.
This alternative is preferable when different stakeholders have different perceptions of a use case; some stakeholders might, for example, be unaware of the magnitude of the use-case performance.
In some systems, such as rule-based systems and meta tools, the external view of the system is quite different from the internal view in the sense that a user of the system might perceive it to be quite different from the actual implementation of it. This causes problems when developing a use-case model of such a system, because different stakeholders will have quite different views on how the system is supposed to work. The users of the system tend to think of the system in terms of what concrete functions can be used, whereas the developers tend to think in terms of what functions will have to be implemented. Other stakeholders, such as the owner of the system, can belong to either of the two groups, depending on their knowledge of the implementation of the system.
In a text editor, there are tools for checking the spelling, for checking the grammar, and for proposing how documents and letters are to be organized and formulated. A user of the text editor would probably model these as three different use cases.
However, assume that this part of the text editor is to be implemented using a rule-matching technique where each rule has a template and a body. The template is used for matching different parts of the written text. If a template matches a part of the text, the body of that rule is executed, so that, for example, the text is highlighted, a certain dialog box is opened, or the text is modified.
A developer of such a system would like the use-case model to contain use cases for defining the rules and for evaluating the rules. This use-case model is quite different from the users' model, even though both of them describe the same system.
The problem arises because of the two main purposes of a use-case model, namely to describe how the system is to be used and to be a basis for developing the realization of the system. There are situations, fortunately not very frequent, when these two goals are more or less impossible to meet in a single description of the system.
From a user's point of view, the use-case model describes how the system is to be used, but such a model does not help the developers who are to implement the requirements using a technique that does not immediately reflect the user's point of view. From a developer's standpoint, the use cases should model how the system is actually used—not how it is perceived from the outside—if a proper realization of the system is to be produced (see Figure 25.1). In most projects, there is no significant conflict between the two viewpoints, but using techniques for implementing the system that are not obvious to the user—using techniques that do not reflect how the users normally think—constitutes a problem that must be addressed explicitly. Otherwise, at least one of the groups will not find the use-case model useful.
Figure 25.1. A system not implemented with a technique natural to the users can be described with two different use-case models, both equally correct. The left one is the user's point of view, and the right one is the developer's.
The solution to the problem is producing a model that contains the use cases of both sides and establishing firm relationships between them, according to the Orthogonal Views: Specialization pattern. Then each group can focus on their subset of use cases, but at the same time also see the constraints placed by the relationships between the use cases that indicate that the other group's use cases cannot be neglected. It must be possible to perform every use case that the users want to use by means of the use cases produced by the developers. Therefore, the users' use cases are specific performances of the use cases presented by the developers. To express this kind of relationship, we use generalization between the use cases. The use cases that the users want to use are specializations of the use cases that are going to be realized by the developers (see Figure 25.2). The realizations of the former use cases will be special cases of the realizations of the latter.
Figure 25.2. The use cases modeling how the system is perceived from the outside are specializations of the use cases modeling how the system is implemented (Orthogonal Views: Specialization).
A variant of this situation arises when the number of actions performed inside the system is considerably larger than what is noticed or comprehended by someone on the outside. In most such cases, both sides accept the same use-case model, but the two groups' constraints on the descriptions of the use cases are often in conflict. For example, very few of us know or understand what takes place in a telephone exchange during a telephone call. If the subscribers had to review and agree on what should be included in the descriptions of such a system's use cases, they would no doubt prefer to exclude all the detailed stuff that they do not comprehend. However, the developers of the telephone exchange will insist that the descriptions must include all those details.
In this case, the best solution is to apply the Orthogonal Views: Description pattern and develop two descriptions of the use cases, one of them covering how the use case is perceived by the users, and one encompassing all the actions that are actually performed. To minimize the risk of having two descriptions of the same use case that are not compatible, and at the same time reducing the number of documents, the additional descriptions can often be placed in separate subsections of the use-case description (see Figure 25.3). Our experience is that with this approach, both groups of stakeholders will accept the descriptions. One group, the users, will want a stripped version of each description, whereas the other group, including the developers, will use the complete description.
This section provides two examples of use cases based on the Orthogonal Views: Specialization pattern (see Figure 25.4). The first use case is Evaluate and Apply Rules, which models how the system actually behaves, and the second one is Check Spelling, which shows how the users perceive one of the usages of the former use case.
Figure 25.4. The Check Spelling use case models a specific usage of how the rules are evaluated and applied, which is modeled by the Evaluate and Apply Rules use case.
The Large Use Case patterns might be useful in this example.
There is no analysis model for this chapter because it describes different views of the use-case model. The mapping to the analysis model is done based on the use case that models the actual performance of the flow (in our example, the Evaluate and Apply Rules use case) and not on how the flow is perceived. Moreover, it does not matter how the description of the use case has been organized in the different chapters. Every part of the use case must, of course, be mapped onto the analysis model.