Preface Preface Collecting 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 nece...
|
