When developing or building a construction of some sort, such as a house or a machine, we all rely on previous experience from similar work. In this way, we will be more productive and will therefore be able to complete a better construction in less time than an inexperienced person. We will know what solutions work, and can thus avoid pitfalls, and we will know or have qualified guesses about possible ways to tackle arising problems. In some cases, we know how a part, a service, or an assembly was successfully built in another construction, and we can then reuse that solution in the current construction. In other cases, it is not a particular solution that can be reused; instead, it is the underlying design that is relevant when we decide how to solve the current problem. In other words, we reuse both existing solutions as well as techniques that have proved to be well suited and efficient in other contexts.

Use-case modeling does not differ from other kinds of developmental work in the sense that an experienced modeler will reuse solutions that he or she has found useful and efficient. The more experience the modeler has, the more frequently and efficiently will he or she reuse earlier solutions.

The experienced use-case modeler does not focus on a single use case when expressing what the system under development is meant to do. Instead, the modeler knows that a specific problem as a whole should be expressed with a particular set of use cases. The solution to the problem may include several use cases as well as relationships between them. Hence, the modeler will reuse fragments of previous, successful models when producing a new use-case model.

The reused model fragments are seldom identical copies of parts produced in the earlier models. After gathering more and more experience, the fragments boil down to blueprints capturing the essence of how a particular service offered by a system should be modeled in general, or how a common use-case modeling problem should be solved. Hence, a blueprint may be a use-case model of security in terms of access control of information in the system, or a use-case model capturing the use of a legacy system.

Blueprints can be more or less directly copied into a use-case model of a system including the service or modeling situation captured by the blueprint. Usually it will be necessary to tune some of the details in the blueprint to the specific needs at hand, such as choosing names that are natural to the stakeholders of the current project, and stating particular sequences of actions that are to be performed in the use-case descriptions.

Similarly, the successful techniques and designs that are used over and over again in the use-case models become formalized as patterns expressing good use-case model designs. Such a pattern does not describe a particular usage of the system. Instead, it captures a technique for making the model maintainable, reusable, and understandable. To apply a pattern in a use-case model means structuring a part of the model or describing an individual use case in a specific way. Hence, use-case patterns capture good practice in use-case modeling. For example, a subsequence that must be the same in several use cases should be modeled as a separate use case with explicit relationships to the original use cases, and services that are optional in the system should be modeled separately from the mandatory ones.

As opposed to blueprints, patterns are not just copied into a use-case model. Instead, they are used as templates for how the model should be structured, or, for description patterns, how use-case descriptions should be organized.

What then constitutes a reusable use-case blueprint or pattern? First of all, it describes an understanding of a problem, either a particular usage of a system or an underlying design, and gives a solution that is proven sound and reliable. Second, it includes information on situations when the blueprint or pattern is applicable, and third, it describes what the consequences will be when it is applied. To summarize:

Experienced use-case modelers will not only know how to develop a good use-case model, they will also discover when certain use cases are missing, simply because they know that such use cases will most likely appear in this kind of system. In most systems, for example, the users must be identified before they can use the system—that is, they must log in to the system. This implies that there must be use cases not only for logging in, but also for logging out and for registering and deregistering users. Furthermore, if all the users are not supposed to have the same access rights to everything in the system, there must be use cases for registering and checking their access rights as well. All together, this means that experienced modelers do not look for single use cases; they look for groups of use cases. Therefore, the patterns and the blueprints include not only the significant use cases for the modeling problem, but also the supporting use cases needed to be able to perform the significant use cases. This means that the collection of patterns and blueprints in this book offers a lot of help when producing use-case models by providing comprehensive solutions to modeling problems.

However, other people's experiences as well as our own do not only tell us how things should be done, they also make it clear how things should not be done. Experienced use-case modelers can often quickly identify imperfections in use-case models they review. This is not because they have modeled the same system before. Just by studying the structure of the model, they detect common mistakes, such as an abnormally large number of relationships in the model, or functional decomposition of use cases. We have therefore complemented the patterns and the blueprints in this book with a collection of common mistakes that we have found over and over again. Use this collection as an indicator that something may be flawed in the model, but not as a sharp divider between right and wrong. There might be a good reason why a specific model triggers such an indicator and still is acceptable. However, such situations are rare!

For each pattern, blueprint, and common mistake presented in this book, we provide a thorough description. However, because of their different forms and nature, we have organized them in three different groups and structured their descriptions slightly differently. Within each group, we have organized related patterns or blueprints in chapters, each addressing one specific issue. Although we have described the different solutions to modeling problems as separate blueprints and the different designs of models as different patterns, most real modeling situations are not so precise and clear-cut that only one blueprint or one pattern can be deemed fitting or applicable. On the contrary, in most situations, a combination of several blueprints and patterns will have to be used. In some of the examples in the book, you will find that we have used another pattern or blueprint as well, but we have tried to focus each example on the topic of the chapter. We do, however, for each example suggest other patterns or blueprints that also may be applicable to the specific example at hand.

All the patterns, blueprints, and common mistakes are enumerated here to give an overview of the catalog found in Parts III through V of this book. For each chapter, we give the title and a description of the intent (for patterns), the modeling problem (for blueprints), or the fault (for common mistakes). For pattern chapters and blueprint chapters, the names of the individual patterns or the blueprints in that chapter are also listed.