The very first attempt at a use-case model is usually done mainly graphically, in diagrams showing actors and associated use cases (see Figure 6.1). These sketches of a use-case model are complemented by brief descriptions of the use cases and the actors, to make sure that everyone involved in the process understands and agrees on what each actor and use case represents. When these diagrams and descriptions of the model stabilize, more details are provided by means of detailed descriptions of each use case.
During this work, the model is bound to undergo changes, because more details of what actually happens in each use case will be captured. The addition of more details sometimes reveals that the original structure of the model may not have been optimal, or may even have been incorrect. One common type of change involves splitting one use case into two or more use cases, which is necessary when alternative flows prove to constitute completely different flows rather than variants of the basic flow, and hence will be better expressed as separate use cases. At other times, two use cases will be replaced by a single use case—for instance, when detailed descriptions of the flows show that they are in fact very similar and therefore had better be treated as variations of one use case.
Furthermore, parts of some of the use cases may prove to be identical or should be identical, and some parts may be configurable; that is, not all configurations of the system will include these parts. Moreover, some use cases in the system may be mutually exclusive; that is, the system must include either of the two use cases, but not both.
In other cases, mainly when developing a new version of an already existing system, one may want to reuse parts of existing use cases in some of the new use cases, or want to extend already existing use cases with some additional behavior (see Figure 6.2).
The approach described above suggests starting with the identification of the use cases, and then continuing with the identified commonalities found during the description of the use cases. However, the opposite approach is also feasible, which may occur if there is a requirement stating that certain parts of two or more usages must be the same—in other words, when we know in advance that the flows of two or more use cases are to share common parts. Usually, the procedure is a mix of the two alternative approaches. It should be pointed out, however, that the second alternative should be used only when such a requirement has been explicitly stated.
Subsequent chapters describe how such situations can be expressed as well as be prepared for in the use-case model by introducing three different kinds of relationships between use cases: include (Chapter 7, “Include: Reusing Existing Use Cases”), extend (Chapter 8, “Extend: Expanding Existing Use Cases,” and Chapter 10, “More on Extend and Extension Points”), and generalization (Chapter 11, “Use-Case Generalization: Classification and Inheritance”). We also discuss how commonalities between actors should be expressed (Chapter 12, “Actor Generalization: Overlapping Roles”). Using these relationships will make the model easier to maintain and usually easier to understand. However, these relationships should not be overused, because this will make the model overly complex (see Chapter 17, “Commonality,” Chapter 19, “Concrete Extension or Inclusion,” Chapter 23, “Multiple Actors,” and Chapter 26, “Use-Case Sequence”).