| 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, the conceptualization
and specification of software systems.
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
of requirements for a project.
Organization and Content
There 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.
Chapter 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.
In 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.
Chapter 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 Works
This 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.
|
