From the Back Cover

"Gunnar and Karin have not only defined a large collection of use-case patterns and examples of how specific usages are to be modeled in a use-case model, they have also provided an accurate, complete, and comprehensible description of the constructs used in use-case modeling... I am impressed by this book."

—From the Foreword by Ivar JacobsonEmploy the proven concept of design patterns to build more accurate, usable, and maintainable use-case models

This book brings together dozens of proven patterns for creating use cases that more accurately reflect real requirements, are easier to translate into working systems, and are simpler to maintain. Utilizing these patterns, architects, analysts, engineers, and managers can leverage decades of hard-earned knowledge to achieve far better results, far more quickly.

The authors carefully describe how each pattern works, what problems it is intended to solve, and the consequences associated with using it. All patterns are supported with detailed examples and platform-independent class models that demonstrate how they may be realized. All constructs and diagrams reflect the current UML 2.0 standard. This book also includes an insightful use-case primer that will be indispensable both to novices and veteran modelers seeking to become more effective.

Coverage includes

Modeling rules that lead to more comprehensible, maintainable, and correct models

Patterns for structuring, layering, mapping, sequencing, and viewing use cases more effectively

Blueprints for security, legacy integration, data input/ output, task scheduling, and reporting

Constructing use cases that separate mandatory elements from optional parts that can be delivered separately

Incorporating business rules in use-case modeling

Practical techniques for documenting use cases more effectively

When to use multiple patterns and blueprints together

Identifying and avoiding eight common mistakes in use-case modeling: guidance for designers and reviewers

Examples from a wide range of application domains

Rely on this book as the world's #1 reference to reusable use-case solutions—and as a catalyst for inspiration in all your use-case modeling projects. © Copyright Pearson Education. All rights reserved.

About the Author

GUNNAR ÖVERGAARD is recognized as a leading authority on UML and use cases, and a prime mover in the global object technology community. He has worked with use-case-driven development, object-oriented development processes, consulting, and education since the mid 1980s.

KARIN PALMKVIST has more than fifteen years of experience with use cases and object technology. She mentors and instructs development organizations introducing use cases and object technologies, speaks frequently at seminars and conferences, and participates actively in the UML development community. © Copyright Pearson Education. All rights reserved.

Excerpt. © Reprinted by permission. All rights reserved.
PrefacePrefaceCollecting Models and Designs

Our aim with this book is to share some of the experience we have gained in working with use cases for more than 30 years altogether. Over the years, we have participated in the development of hundreds of use-case models, both as use-case modelers and as reviewers and mentors. This has of course given us a lot of know-how and understanding of use-case modeling and how a good use-case model should be organized and described.

One obvious finding is that more or less the same modeling problems are encountered over and over again, because many functions reoccur in multiple systems. Studying how these functions were expressed in the use-case models of these systems has led to many interesting reflections. We saw, for example, that some of these models were easier to understand and maintain than others, and we started to analyze why. We also noticed that some models, although they seemed easy to understand, did not quite capture the intended meaning, because they were too simplistic.

During this period, we have had a great many discussions, often involving other participants, why certain ways to use a system should or should not be modeled in a specific way. Over and over again, we have discussed different aspects of various ways to model a specific usage in a use-case model to make it correct, understandable, and maintainable. What were the important parameters, and what did not have a significant impact? As the years went by, we discerned more and more general solutions to common use-case modeling problems in terms of good models of many of these reoccurring functions or ways to use a system. We chose to refer to the use-case model fragments constituting these general solutions as use-case blueprints.

Fairly soon, we also realized that some solutions could be generalized even further. Of the specific usages modeled there were some general, underlying design rules that should be fulfilled independently. Applying these design rules, or use-case patterns, made the models even more comprehensible, more maintainable, and, in fact, often more correct according to the essential definitions of use-case modeling.

Over the years, a number of people have suggested that we make our gained experience available in writing. This book is the result of an effort to do so, by presenting and describing several of the patterns and blueprints we have identified. The catalog is by no means complete, so your favorite pattern or blueprint might not be included. However, we believe the assembled list is useful for most use-case modelers, novices as well as experienced modelers.

It is unlikely that one could work with use-case models for such a long time without noticing repeatedly occurring good solutions, and it is just as unlikely not to notice reoccurring mistakes in use-case models. We have therefore also included a collection of common use-case modeling mistakes in this book, hoping that they will prove useful to modelers as well as to reviewers of use-case models.

We hope this book may be a starting point for a growing amount of shared knowledge and vocabulary within the use-case modeling community. Hence, if there is some specific pattern or blueprint that you have found useful, but that is not included in this book, or if you have a modeling problem that you think you would like to share with many other people in this field, please let us know. We would also appreciate any feedback you might have on the current catalog and its contents.

It is not possible to write a book about patterns without mentioning Christopher Alexander and his groundbreaking work on identifying and describing patterns when designing constructions (Alexander, Ishikawa, Silverstein 1977). He was working as a building architect, and as such he and his colleagues studied and documented patterns used in what was generally considered high-quality buildings.

Two decades later, patterns became a well-established and important concept in software development. In their pioneering book Design Patterns (Gamma et al. 1995), E. Gamma et al. presented a collection of patterns for object-oriented design of software systems. Today patterns are used quite extensively in software development, and you can find any number of books on the subject. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns (Buschmann et al. 1996) describes different patterns for software architectures. M. Fowler has produced a book titled Patterns of Enterprise Application Architecture (Fowler 2002) that discusses patterns used for developing enterprise architectures. Patterns for Effective Use Cases, by S. Adolph and P. Bramble (Adolph and Bramble 2002), discusses patterns that appear in the process of developing a use-case model. There are several books about patterns for specific languages and standards, such as Java: A Catalog of Reusable Design Patterns Illustrated with UML, by M. Grand (Grand 2002); EJB Design Patterns: Advanced Patterns, Processes, and Idioms, by F. Marinescu (Marinescu 2002); and Core J2EE Patterns: Best Practices and Design Strategies, by D. Alur et al. (Alur, Malks, and Crupi 2003). Patterns are defined also for specific domains, such as security. The Open Group has produced Security Design Patterns (Open Group 2004), in which different patterns for software security are defined. In fact, patterns are not only used for defining good designs; they are used also for defining bad designs that should be avoided, as in AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, by W. Brown et al. (Brown et al. 1998).This Book

This book provides a collection of use-case patterns and blueprints extracted from a large number of use-case models that we have encountered in our work with use cases for more than three decades altogether. It is not focused on a specific domain or technology, although we do not expect every pattern and blueprint to be relevant to all systems. The book is intended for use-case modelers, such as software engineers, developers, system analysts, and requirements specifiers. Others who might benefit from reading this book include managers, customers, and students, who want to develop, review, approve, and in general learn about use cases and high-quality use-case models.

By using patterns and blueprints presented in this book, a project will reduce the time spent finding out how to express the usages of the system at hand in terms of use cases as well as the time deciding how to structure and describe these use cases. The time spent developing a use-case model will be reduced because the wheel will not have to be invented once again, and the quality of the model will be increased because well-proven solutions are used. In addition, it will be easier to read and understand a use-case model if it is based on well-known techniques and solutions. Furthermore, because each pattern and each blueprint is given a descriptive name, we hope and expect that a common vocabulary among the use-case modelers will be achieved.

Hence, this is not just another book describing use cases. Nor is it a book about capturing requirements in general. The main purpose of the book is to provide a collection of useful use-case patterns and blueprints. However, to be self-contained, the book also includes a thorough description of what a use case is, as well as what other constructs might be used in a use-case model and what they mean. The constructs and the diagrams used in the book are in accordance with the definitions found in UML 2.0 (Object Management Group 2003). We have also described some approaches to documenting the use cases. However, because it is not our intention to provide another textbook about use cases, we have not included certain aspects of use-case modeling in this book. For example, we have not covered several techniques for describing use cases. Furthermore, we have not focused on how to identify use cases in general, how to organize them in packages, or how to structure diagrams presenting a use-case model. In these matters, we refer you to other books covering these subjects. In Use Case Modeling, K. Bittner and I. Spence (Bittner and Spence 2002) give a thorough presentation of the use-case concept and how it is to be used. Applying Use Cases: A Practical Guide, by G. Schneider and J. Winters (Schneider and Winters 2001), is another book with a good presentation of use cases. Writing Effective Use Cases, by A. Cockburn (Cockburn 2000) provides a detailed discussion about how to describe use cases and how to ensure that they are all at the same level of abstraction.

In this book, we have taken a pragmatic approach to use-case modeling. The main goal for a project is, after all, to produce a new version of a system. However, because a use-case model is used as a basis in a number of different situations, such as signing a contract or developing the design of a system, the meaning of the use-case model must be clear. Some of the patterns and blueprints will therefore lead to somewhat more thorough and complex models than what can be seen in some other books and examples. Obviously, we have preferred correctness to simplicity, but even so, all the examples in the book are what we would prefer to find in real-life use-case models.

The patterns in this book bear some resemblance to the patterns described in the Design Patterns book (Gamma et al. 1995) in that they describe modeling of common situations. However, the Design Patterns book is about object-oriented designs, whereas this book focuses on use cases. Nevertheless, the reuse aspect is the same in both books. Thus, this book illustrates how usages found in many systems are to be modeled by use cases.

By nature, use-case modeling and the resulting use-case models are less formal than design modeling and design models. This difference is apparent also when it comes to use-case patterns compared to design patterns. Although it is necessary to reach a certain level of formality to achieve the goal of a common understanding of a pattern, it is also necessary to make sure that use-case modeling remains a useful tool in any early-stage system development involving non-technically skilled people. The reader already familiar with design patterns might therefore find the patterns in this book loosely defined, while at the same time an experienced use-case modeler might find them formally described. Organization of the Book

The book consists of five parts.

In Part I, "Introduction," we introduce the reader to the idea of use-case patterns and blueprints. We also provide a small model example to show how these can be applied when developing a use-case model of a system, and what can be gained by using the catalog of patterns and blueprints.

Part II of the book, called "Use Cases," provides a comprehensive description of the use-case construct and all the other constructs specific to a use-case model. This part concludes with a chapter on how use cases are realized in terms of classes, because a basic knowledge of this is essential if the reader is to understand the corresponding part of the pattern and blueprint descriptions. We have included Part II in the book to make it self-contained; both so that the reader will not have to find another book to understand the constructs used in the patterns, but also to provide accurate definitions of the different constructs that we have used.

The main part of the book, the very reason why we wrote it, is Part III, "Use-Case Patterns," and Part IV, "Use-Case Blueprints." Here you will find 27 different use-case patterns and 30 use-case blueprints applicable to use-case models of various kinds of application domains.

We have chosen to group related patterns or blueprints together in chapters to be able to discuss them together and to make it easier for a reader to look for a relevant pattern or blueprint. Each chapter has a name and a short statement describing the intent or modeling problem that the patterns or the blueprints in the chapter address. Then follows an enumeration of the patterns or the blueprints in the chapter together with a description of how each of them is expressed in a use-case model and when it is applicable. The chapter continues with a thorough discussion of the patterns or blueprints and why they form good use-case models, followed by an example, including use-case descriptions of the participating use cases. The chapter ends with a section presenting how the use cases in the pattern or the blueprint can be realized in a logical class model.

We also enumerate a few common use-case modeling mistakes—that is, situations that should not appear in a use-case model—in Part V, "Common Mistakes." Each such common mistake has a name and short description of the incorrect model, followed by an explanation why this is not a good use-case model. The discussion is followed by suggestions on how to improve the model.On Patterns and Blueprints

Regardless of your previous knowledge and experience with use cases, we expect you to find some of the patterns and blueprints very valuable, whereas others will probably seem less interesting, or even completely irrelevant, to you. However, different readers will most likely find different subsets of them useful depending on their different experiences, problem domains, as well as application and modeling knowledge.

Furthermore, because we do not know all the specific requirements for a specific project or system, you might encounter modeling situations that might be better expressed in a different way from what is proposed in these patterns and blueprints. This is, of course, a general issue with patterns and blueprints and nothing particular to use-case modeling; nonetheless, it is something to keep in mind.

The collection of patterns and blueprints presented in this book is not exhaustive; there exist several others that are useful and valuable. Again, we encourage you to give us feedback on those presented in this book, give us criticism for our choice of examples, tell us about new applications of the patterns and blueprints, and suggest others that you think should be included.On Examples

The purpose of the use-case descriptions presented in this book is to provide an understanding of the patterns and the blueprints by giving concrete examples of their application. These use-case descriptions are what we would expect to find in an industrial project, although somewhat simplified regarding details and functionality unnecessary for understanding the pattern or blueprint. In addition, the alternative flows are often fewer and shorter than normal, because we do not want the examples to diverge due to exceptions and error handling.

Because we do not think there is one domain that includes all the necessary examples, we have taken the examples from several different domains. However, this does not mean that the pattern or the blueprint exemplified is applicable only to systems belonging to those domains. In fact, we have encountered all patterns and blueprints in this book in several different domains.

Furthermore, we realize that similar systems are different when it comes to details, and we acknowledge that systems of the same type and with the same purpose function differently in different organizations and in different places over the world. We hope the reader will see the examples for what they are—namely, examples of patterns and blueprints—and not parts of exemplary systems. How to Use This Book

First of all, we firmly suggest that you do not read this book just once. Instead, we hope you will return to it and use it repeatedly as a catalog, for inspiration, as a reference, and as a catalyst in your work.

Our suggestion on how to approach this book depends on your previous experience with use cases. If You Are an Experienced Use-Case Modeler

Being an experienced use-case modeler, you should start with Part I. This part consists of two chapters that present what we mean by the use-case pattern and the use-case blueprint concepts and give you an example of how they can be applied.

As an experienced use-case modeler, you can probably skip Part II of the book covering the different constructs in a use-case model and go directly to Parts III through V, the catalog of use-case patterns, blueprints, and common mistakes.

We recommend that you read the introduction to each catalog part to get an overview of the structure of the parts before you dive into the different patterns, blueprints, and common mistakes.

We do not expect you to read all details about each pattern, blueprint, and common mistake in the catalog at your first reading. Instead, you should focus on those that you currently find relevant based on your experience and the project at hand. However, we recommend that you read the introduction to all the chapters in Parts III through V to get an overview of what you can find in this book. This means that for each pattern chapter, you should read its Intent and Patterns sections; for blueprints, the Problem and Blueprints sections; and for common mistakes, the Fault and Incorrect Model sections. If You Are a Novice or Inexperienced with Use Cases in Practice

If you are more or less new to use-case modeling, you need to get an understanding of what use cases are and what they are to be used for before you start studying patterns and blueprints. This implies a different reading path through the book than for the experienced reader.

As an introduction, you might begin by reading Chapter 2, specifically the section that describes a small Internet banking system and the section presenting the complete model of this system. For now, you can skip the rest of the second chapter, which examines the application of some use-case patterns and use-case blueprints to the use-case model of this system.

Then you should focus on Part II of the book, describing use-case fundamentals. Chapters 3 through 5 give you all the information you will need on use cases and actors. You should also be familiar with the different kinds of relationships in use-case modeling as well as with how to describe use cases; therefore, you should read Chapters 6 through 14. However, you do not need to study these in detail at this moment. If the relationships are used in the patterns or the blueprints you are about to apply, you can always return to those chapters for reference.

When you understand what use-case modeling is, you can go to Parts III through V of this book to understand the different use-case patterns, blueprints, and common mistakes. Before doing so, however, return to Part I and read Chapter 1 and the whole of Chapter 2 to get an understanding of what use-case patterns and blueprints are and how different patterns and blueprints can be applied when developing a use-case model.If You Are Not a Designer

In general, if you are not a designer, a software architect, or otherwise interested in the interior structuring of a system, you can skip Chapter 15 in Part II as well as the Analysis Model sections in each chapter in Parts III through IV.Future Use of This Book

After reading through the book, return to it and use it as a dictionary and knowledge base in your future tasks of developing use-case models—both to look up different constructs used in use-case modeling that you feel uncertain about and to look up different patterns and blueprints that might be applied in your model. History of Use Cases

The use-case (Swedish: användningsfall anvÁndniñs'fal) construct was invented by Ivar Jacobson, as a result of a need to describe complete sequences of actions in complex telecommunication systems, and not only the components that made up the systems. The term was coined in 1986, but the construct had been presented before (for example, in his Ph.D. thesis (Jacobson 1985), for which he studied concepts for modeling large real-time systems). In his thesis, Ivar Jacobson defined a construct called course, which is very similar to the use-case instance construct of today. In 1987, the construct received wider attention when he presented a paper about the use-case construct at the OOPSLA '87 conference (Jacobson 1987). The definition of a use case presented in that paper is basically the same as today's definition of the construct.

In 1987, Ivar Jacobson founded a company developing the Objectory software development process. (One of the authors of this book joined him that year and the other joined the company in 1989.) The use-case construct was described in greater detail in Objectory, where it was also slightly modified and enhanced. For example, classes modeling domain objects were no longer included in the use-case model. The extend relationship existed already, but it was called builtOn in those days.

In the next couple of years, the generalization relationship was introduced (it was first called inheritance and then renamed uses because it captured more than traditional inheritance), and the three different kinds of analysis classes and their different kinds of relationships were also defined. In 1992, the Object-Oriented Software Engineering: A Use-Case Driven Approach book was published (Jacobson et al. 1993), in which the use-case-driven approach was presented for a wider audience. Another book, The Object Advantage (Jacobson, Ericsson, and Jacobson 1994), showed how use cases could be used also for modeling businesses.

After Rational's acquisition of Ivar Jacobson's company, the Objectory process first turned into ROP (Rational Objectory Process) and then into RUP (Rational Unified Process) (Kroll and Kruchten 2003; Rational Software Corporation 2003). During this period, the development of the Unified Modeling Language (UML) was initiated. It implied a very small change of the definition of use cases. The relationship between use cases formerly called uses was split into two relationships: generalization and include. All the other constructs used in use-case modeling, however, remained the same (Object Management Group 1997; Rumbaugh, Jacobson, and Booch 1999). In the latest version of UML, called UML 2.0, the use-case construct is still the same (Object Management Group 2003).

Hence, as Ivar Jacobson points out, most of the definitions of the use case constructs were established by 1992 (Jacobson 2003). The fact that use case is a major construct in UML and a cornerstone in most software development projects, being used by thousands of modelers in hundreds of modeling efforts, makes use-case modeling a reliable technique for modeling how a system is to be used.Acknowledgments

Many have inspired and encouraged us in the writing of this book. First, we must thank Ivar Jacobson for introducing us to use cases back in the 1980s. We have had many inspiring and stimulating discussions with him about why use cases should or should not be defined, modeled, and described in particular ways. Without his groundbreaking work, modern software development would not be where it is today.

We particularly want to thank Steve Berczuk, Katarina Jönsson, Neil Harrison, and Bengt Övergaard for their many valuable comments and suggestions on how to improve the book and its contents.

We also want to thank Christian Averskog, Karl Dickson, Erik Lindahl, and Dan Ståhlberg for their constructive reviews on earlier drafts of the book, as well as Christina Skaskiw for triggering us to actually write this book.

We are grateful to Gerd Övergaard for her invaluable effort helping us make the text more effective and correct, and to Åke Westin for preparing all nonformal artwork in the book. Without the two, the book would have been much more cumbersome and uninteresting to read.

We are also thankful to the team at Addison-Wesley for all their help and patience, especially John Neidhart, Lori Lyons, and Keith Cline.

Needless to say, we are deeply indebted to all who have provided feedback and shared their experiences in use-case modeling over the years.

Finally, without the patience and support of our families, Maria and Vidar, and Johan, Viktor, and Hanna, there would have been no book about use-case patterns and blueprints.

Gunnar Övergaard and Karin Palmkvist
Stockholm, Sweden
July 2004
© Copyright Pearson Education. All rights reserved.

FROM THE PUBLISHER