A use-case model containing use cases defined at different levels of abstraction.
Keywords: Business use case, different reader categories, level of abstraction, level of detail, levels of use cases.
It is often apparent already from the use-case names when a model comprises use cases at different levels of abstraction. Some will be describing general actions and abstract concepts, whereas others will describe detailed actions and concrete concepts.
Otherwise, a litmus test for this modeling mistake is to let a designer perform a review of the use-case model, checking whether the model is detailed enough to be used as a basis for use-case realization and design. The designer may then point out use cases that are described at too high a level of abstraction, asking for more details, and complain about use cases described at too low a level of abstraction, because they go into detail on design issues.
The same kind of review can be done by a business stakeholder, such as a system user, who will most likely make the opposite complaints.
Use cases that are to be realized and implemented by the development team and not by existing products must be detailed enough to make it possible to identify the internal structure of the system based on the use cases, as well as to describe these components' behaviors.
An example of mixing use cases at different levels of abstraction from the telecom world is a model containing both the use case Make Telephone Call and the use case Check Background Noise on a Call Using a Trunk of Type X. The former use case models a general flow at a high level of abstraction, whereas the latter is defined at a very detailed level of abstraction.
Models with use cases at different abstraction levels are difficult to read and understand, as well as to realize and implement. Furthermore, some parts of the system's services will be emphasized just because they are much elaborated, whereas other parts will seem less important as they are modeled briefly.
System owners and users will probably appreciate the high-level use cases, whereas they will have difficulties understanding the low-level use cases. On the other hand, the developers of the system will consider the high-level use cases as insufficient input to the design work.
Usually the final use-case model will have to be refined into quite a low level of abstraction to provide sufficient input to the realization, design, and implementation work. Therefore, the way to resolve the problem is to elaborate on those parts of the model that are defined at a high level of abstraction to make them harmonize with the low-level parts. Rewrite (the parts of) the descriptions that are defined at a too abstract level. The descriptions of the use cases must contain all details needed to design the system based on them; that is, they must describe all platform-independent actions as well as all actions independent of the internal structure of the system performed by the system when it is used. However, make sure not to define the model at too low level of abstraction! The model should still model the usages of the system and be understandable by the different stakeholders. Furthermore, writing extremely detailed use-case descriptions is a task very much subjected to the temptation to unconsciously make design or implementation decisions and include them in the flow descriptions. Even if this pitfall is avoided, many of the details will still have to be changed as a result of design decisions.
Probably, elaborating the high-level parts of the use-case model implies not only detailing the descriptions, but also defining new sets of use cases instead of the high-level ones.
If it is desirable to keep the original high-level use cases in the model, we define generalizations from the new low-level concretizations to the high-level use cases (see Figure 42.1).
