Overview

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. GoalsOver 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. AudienceThe 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 BookThe 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 processEach 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 of requirements for a project. Organization and ContentThere are many books on use cases available on the market today. Ours is unique in its coverage of the role of use cases in software development. We also present some substantially new material not found in any other paper or book. We balance this new material with a comprehensive survey of the existing work in the field of use case modeling.To allow this book to stand on its own, we present two chapters of fundamental material. These two chapters begin after an introduction to advanced use case modeling. Chapter 1 discusses the conceptual role of actors in the use case model. A detailed account of how to recognize actors is provided to prepare the use case modeler to discover use cases. Chapter 2 discusses the general format and protocol for creating use cases. The Unified Modeling Language, the Object Management Group (OMG) standard for use case modeling, is explained.Part 2 starts with the first phase of software development, project initiation (Figure P-2). Chapter 3 focuses on this phase by looking at the things that define the system scopethe problem that is to be solved and the business opportunity created by the new or improved system, and the financial feasibility of building a software system to address this opportunity.Figure P-2 Generic phases of a software development processChapter 4 describes use case modeling in the requirements analysis phase of the software development process (Figure P-3). Use cases help to describe the functions of the system and to balance the use case model; form is provided with a well-designed architecture that can enhance the use case model.Figure P-3 Decomposition of the requirements analysis and partial analysis phasesIn Part 3, we introduce a bank loan application example that is used throughout the book to illustrate the concepts of use case modeling. The example does not represent any actual loan system. The necessary functionality for an actual loan application has been streamlined for purposes of the example.In Part 3 we also describe the advanced use case modeling process framework. Chapter 5 decomposes use case modeling into activity groups, or groups of logically related activities (Figure P-4). The chapter describes a framework for use case modeling that is used to describe system use case modeling through Chapter 15.Figure P-4 The advanced use case modeling process frameworkChapter 6 describes the initial steps in setting up a use case modeling effort. The selection and customization of use case frameworks, the selection of standards and techniques, and the consideration of training and mentoring needs are outlined.Chapter 7 discusses the initial steps of creating the use case model. The outcome of this activity group is a use case model that captures a "conceptual" picture of what the system will need to do.Part 4 focuses on expanding the use case model. Chapter 8 begins the discussion of how initial use case descriptions are expanded to become base use cases with more detailed requirements and how this increased complexity is modeled. Chapter 9 discusses the practice of placing conditional and iterative logic within a use case's flow of events. Two techniques for modeling these concepts are presented.Chapter 10 describes the use of extend, include, and generalization relationships to model the alternatives, variations, and commonality in the use case model. Chapter 11 discusses the capture of additional or supplemental information associated with an individual use case. Chapter 12 discusses the importance of mapping the use cases to the analysis object model. Techniques such as CRUD matrixes, object to use case tables, and sequence diagrams are outlined. Chapter 13 discusses the concept and utilization of scenarios to complement the use case model.The final phase of any software engineering process is testing. Chapter 14 discusses testing and documenting the system and the role use cases play in driving these activities. Chapter 15 examines organizing use cases by business functional packages and by dependencies based on use case preconditions and postconditions. A discussion of various views of the use case model is presented. A wrap-up of key use case artifacts is also presented.Part 5, Additional Topics, begins with Chapter 16. This chapter examines the effect of use cases on user interface design. Transactions are used to segment the use case model to provide elements for conceptual user interface development. Grouping techniques allow screens to be built from the transactions.Chapter 17 examines the effect of change on the use case model. In successful software systems, changes that affect the functionality of the system are inevitable. Change may occur during the project or after it has shipped.Chapter 18 discusses some of the necessary considerations for deploying advanced use case modeling. All or part of the process framework may be utilized depending on the needs of the project. This chapter outlines the elements that determine how much to use. It also describes how to document this process.The final chapter, Chapter 19, discusses the quality attributes of a good use case model. It also describes the various roles that use case modeling can play within a system analysis effort. Finally, iterative and incremental development with advanced use case modeling is briefly outlined. Complementary WorksThis book stands on its own and can be read without referring to other works. However, quite a bit of helpful material is available on requirements engineering, use case development, and process improvement. Software development process Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development Process, Addison-Wesley, Reading, MA, 1999. Dean Leffingwell and Don Widrig, Managing Software Requirements: A Unified Approach, Addison-Wesley, Reading, MA, 2000. Geri Schneider and Jason P. Winters, Applying Use Cases: A Practical Guide, Addison-Wesley, Reading, MA, 1998. Rational Software Corporation, Rational Unified Process, 2000. Business process engineering Ivar Jacobson, Maria Ericsson, and Agneta Jacobson, The Object Advantage: Business Process Reengineeering with Object Technology, Addison-Wesley, Reading, MA, 1995. Michael Hammer and James Champy, Reengineering the Corporation, Harper Business, New York, 1993. Rational Software Corporation, Rational Unified Process, 2000. Component development Ivar Jacobson, Martin Griss, and Patrik Jonsson, Software Reuse: Architecture, Process, and Organization for Business Success, Addison- Wesley, Reading, MA, 1997. Clemens Szyperski, Component Software: Beyond Object-Oriented Programming, Addison-Wesley, Reading, MA, 1998.You may notice a number of references to other works in the body of this book. We did an extensive survey of the use case literature that predates the publication of this book and found many ideas worthy of inclusion. We also found many areas where we had developed solutions independently that were similar to those found in the literature. In these cases, we refer to the work in which the idea originally appeared. This gives the reader the flexibility to explore these references to get other viewpoints and gives credit to the other deserving authors.For the latest information on use cases, supplemental and additional material, or how to contact the authors, visit us at our website, advancedusecases.0201615924P04062001