Top
In this rapidly changing business and technological environment, use case modeling has emerged as one of the premier techniques for defining business processes and software systems. Business engineers now employ use cases to define complex business processes across lines of business and even to define entire businesses. Use cases are also the standard for defining requirements for the software systems created using today's object-oriented development languages such as Java, Smalltalk, and C++. In the field of software components, a very young industry whose market is estimated to be more than $12 billion in 2001 Hanscome 1998, use cases are rapidly becoming a method of communication between suppliers and vendors.
The users of this technique for defining systems are as diverse as its uses. Use case modeling is already being employed by most Fortune 1000 companies and is being taught at many academic institutions all over the world, and the popularity of this modeling technique continues to grow.
Business process and software requirements engineering are rapidly evolving fields. Research in these areas continues to propose new methods of dealing with potential problems, even while actual practice is slow to adopt only a fraction of those proposed. This slow-moving partial adoption has been termed the "research–practice gap" Berry 1998. Creating yet another use case book without an extensive experience base would merely add to this gap. Our approach is significant because we present a practitioner's approach firmly grounded in the real world.
Goals
Over the past six years, we have worked on some large, ambitious projects involving software development and business engineering. To create the best possible use case models, we found it necessary to extend the seminal work of Ivar Jacobson in certain areas. This book details our extensions, which complement Ivar's ongoing work. The flexibility of use case modeling and the Unified Modeling Language, which we use to describe these models, allows us to produce extensions to solve real-world problems successfully.
The goal of this book is to further the advancement of use case modeling in software and business engineering. To achieve this goal, the book provides a comprehensive yet readable guide to use case modeling for the practitioner. Specifically, it explains advanced use case modeling concepts, describes a process for implementing use case modeling, and discusses various use case modeling issues.
Audience
The audience for this book is anyone involved in the conceptualization, development, testing, management, modeling, and use of software products and business processes. Although it contains a sizable amount of content related to business processes, this book is geared toward all of us in the software industry. Software professionals are the largest body of use case engineers because use case development was first introduced as a software requirements vehicle.
Business analysts will agree that use case engineering has undergone the greatest transformations on their front. Business analysts and their software process brethren are quickly learning that automation via software is not the only reason for employing use cases. In fact, more and more of business process modeling using use cases is not geared toward the generation and production of new software but is being done to understand, and in some cases, standardize and optimize key business processes across multiple lines of business.
Many of the techniques described in this book transcend the software or business arenas of the reader community. The well-established link between business use cases and software system use cases is described as we illustrate the ways in which software systems can be derived from a business process. The only thing we ask is that our business readers be patient as we start on the software side.
Academic institutions will also find this book useful. This book can be used as a text in an object-oriented analysis (OOA) course in which use cases play a key role.
How to Use This Book
The theory of use case development often differs from the actual practice of use case development. One reason for this difference is that very few software development projects are "green fields"; most are started with a preconceived notion of a legacy process for successfully creating software. We are not advocating the removal of the legacy processes. In fact, many of the artifacts involved in these processes may be necessary due to the nature of the problem that is being solved through software development. Some of these artifacts may also be mandatory for getting the necessary approval to begin a software development project.
Use case modeling cannot be successful in isolation. The process of creating use case models must be put in the context of the specific organization. Every organization has unique cultural aspects. Luckily, we find some commonality as well as differences in nearly every facet of the business engineering and software development processes across organizations.
Experience in one organization can often be useful in another. When patterns of failure have emerged from our use case adventures, we have attempted to capture the factors that have been directly responsible. The pitfalls of use case modeling generally fall into two categories: those in the use case development process itself and those found when use cases are integrated with commonly used software development practices. Some of the pitfalls are so significant that they can stop the development of a system dead in its tracks.
This book provides a process framework for creating models of software systems. A process framework is a set of activities used to develop a process. Our frameworks should be customized specifically for your organization. This book describes the second of the three process frameworks (Figure P-1), the conceptualization and specification of software systems.
Figure P-1 Process frameworks of the advanced use case modeling process
Each process framework is independent and fully defined. They may all be performed in concert or separately. For example, software system and component engineering may be used together to provide requirements for software system development using components. The combination of business process and software system engineering creates an understanding of the elements necessary for business process automation. A business process is not usually completely automated via software systems. The requirements for the business process, therefore, become a superset of those of the software systems used by people carrying out the business process.
The three frameworks provide a means for specifying the requirements for engineering all of the systems required for business process automation, incorporating software building blocks. When process frameworks are combined, the outputs created during the previous framework may be utilized as inputs to the next.
To make the most of this book, we recommend following an established software development process. We respect the notion that not all companies are capable of following a software development process in exactly the same way. The ceremony, or amount of formality, involved usually differs dramatically from company to company and even from project to project Booch 1996.
Ceremony helps define how much of a process framework to use Miller 2000. High-ceremony projects tend to utilize more of the activities, perhaps adopting advanced use case modeling wholesale. Low-ceremony projects use only a portion of the material described. Regardless of the level of ceremony, you will certainly find use cases in some form useful for the definition o
