Instant Ebook Access, One Click Away – Begin at ebookball.

com

Object Oriented Software Engineering Using UML

Patterns and Java 3rd Edition by Bernd Bruegge,
Allen H Dutoit ISBN 0133002098 9780133002096

https://ebookball.com/product/object-oriented-software-
engineering-using-uml-patterns-and-java-3rd-edition-by-
bernd-bruegge-allen-h-dutoit-
isbn-0133002098-9780133002096-16122/

OR CLICK BUTTON

DOWLOAD EBOOK

Get Instant Ebook Downloads – Browse at https://ebookball.com

 Your digital treasures (PDF, ePub, MOBI) await
Download instantly and pick your perfect format...

Read anywhere, anytime, on any device!

Object Oriented Software Engineering Practical Software

Development using UML and Java 1st Edition by Timothy
Lethbridge, Robert Laganiere ISBN 0072834951 9780072834956

https://ebookball.com/product/object-oriented-software-engineering-
practical-software-development-using-uml-and-java-1st-edition-by-
timothy-lethbridge-robert-laganiere-
isbn-0072834951-9780072834956-16120/
ebookball.com

Applying UML and Patterns An Introduction to Object

Oriented Analysis and Design and Iterative Development 3rd
Edition by Craig Larman ISBN 0131489062 9789332553941

https://ebookball.com/product/applying-uml-and-patterns-an-
introduction-to-object-oriented-analysis-and-design-and-iterative-
development-3rd-edition-by-craig-larman-
isbn-0131489062-9789332553941-16128/
ebookball.com

Applying UML and Patterns An Introduction to Object

Oriented Analysis and Design and Iterative Development 3rd
Edition by Craig Larman ISBN 0131489062 9780131489066

https://ebookball.com/product/applying-uml-and-patterns-an-
introduction-to-object-oriented-analysis-and-design-and-iterative-
development-3rd-edition-by-craig-larman-
isbn-0131489062-9780131489066-15634/
ebookball.com

Applying UML and Patterns An Introduction to Object

Oriented Analysis and Design and Iterative Development 2nd
Edition by Craig Larman 0130925691 9780130925695

https://ebookball.com/product/applying-uml-and-patterns-an-
introduction-to-object-oriented-analysis-and-design-and-iterative-
development-2nd-edition-by-craig-
larman-0130925691-9780130925695-17238/
ebookball.com
Java Java Java Object Oriented Problem Solving 3rd Edition
by Ralph Morelli, Ralph Walde ISBN 0131474340
9780131474345

https://ebookball.com/product/java-java-java-object-oriented-problem-
solving-3rd-edition-by-ralph-morelli-ralph-walde-
isbn-0131474340-9780131474345-12410/

ebookball.com

Data Structures and Algorithms with Object Oriented Design

Patterns in Java 1st Edition by Bruno Preiss, PEng ISBN
0471346136 9780471346135

https://ebookball.com/product/data-structures-and-algorithms-with-
object-oriented-design-patterns-in-java-1st-edition-by-bruno-preiss-
peng-isbn-0471346136-9780471346135-19836/

ebookball.com

Applying UML and Patterns An Introduction to Object

Oriented Analysis and Design and the Unified Process 2nd
edition by Craig Larman ISBN ‎ 0130925691
978-0130925695

https://ebookball.com/product/applying-uml-and-patterns-an-
introduction-to-object-oriented-analysis-and-design-and-the-unified-
process-2nd-edition-by-craig-larman-isbn-
aeurz-0130925691-978-0130925695-15044/
ebookball.com

Software Modeling and Design UML Use Cases Patterns and

Software Architectures 1st Edition by Hassan Gomaa ISBN
9781139036740 1139036742

https://ebookball.com/product/software-modeling-and-design-uml-use-
cases-patterns-and-software-architectures-1st-edition-by-hassan-gomaa-
isbn-9781139036740-1139036742-15590/

ebookball.com

Object Oriented Data Structures Using Java 1st Edition by

Nell Dale, Daniel T Joyce, Chip Weems ISBN 0763710792
9780763710798

https://ebookball.com/product/object-oriented-data-structures-using-
java-1st-edition-by-nell-dale-daniel-t-joyce-chip-weems-
isbn-0763710792-9780763710798-14762/

ebookball.com
 Object-Oriented Software Engineering
Using UML, Patterns, and Java™
Third Edition

Bernd Bruegge & Allen H. Dutoit

Technical University of Munich
Department of Computer Science
Munich, Germany

Carnegie Mellon University

School of Computer Science
Pittsburgh, PA, United States

Prentice Hall
Boston Columbus Indianapolis New York San Francisco Upper Saddle River
Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montreal Toronto
Delhi Mexico City Sao Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo
Vice President and Editorial Director, ECS: Marketing Coordinator: Kathryn Ferranti
Marcia J. Horton Senior Managing Editor: Scott Disanno
Editor in Chief: Michael Hirsch Senior Operations Supervisor: Alan Fischer
Executive Editor: Tracy Dunkelberger Operations Specialist: Lisa McDowell
Assistant Editor: Melinda Haggerty Art Director: Kenny Beck
Editorial Assistant: Allison Michael Cover Designer: Bruce Kenselaar
Director of Marketing: Margaret Waples Media Editor: Dan Sandin
Marketing Manager: Erin Davis

Copyright © 2010, 2004, 2000 Pearson Education, Inc., publishing as Prentice Hall. All rights
reserved. Manufactured in the United States of America. This publication is protected by
Copyright, and permission should be obtained from the publisher prior to any prohibited
reproduction, storage in a retrieval system, or transmission in any form or by any means,
electronic, mechanical, photocopying, recording, or likewise. To obtain permission(s) to use
material from this work, please submit a written request to Pearson Education, Inc.,
Permissions Department, One Lake Street, Upper Saddle River, NJ, 07458.
Many of the designations by manufacturers and seller to distinguish their products are claimed
as trademarks. Where those designations appear in this book, and the publisher was aware of a
trademark claim, the designations have been printed in initial caps or all caps.
Quote of Chapter 1 from Object-Oriented Analysis and Design with Applications by Booch,
© 1994 Benjamin Cummings Publishing Company Inc. Reprinted by permission of Pearson
Education, Inc.
Quotes of Chapters 2 & 12 from Zen and the Art of Motorcycle Maintenance by Robert Pirsig,
© 1974 by Robert Pirsig. Reprinted by permission of HarperCollins Publishers Inc. William
Morrow. For British Commonwealth excluding Canada, Zen and the Art of Motorcycle
Maintenance by Robert M. Pirsig published by Bodley Head. Used by persmission of The
Random House Group Limited.
Quote of Chapter 6 from The Emperor’s Old Clothes by C. A. R. Hoare, © 1981 Association
for Computing Machinery, Inc. Reprinted by permission.
Quote of Chapter 13 from Chapterhouse: Dune by Frank Herbert, © 1985 by Frank Herbert.
Used by permission of Berkeley Publishing Group, a division of Penguin Group (USA) Inc.
All other chapter quotes are in the public domain or fall within the realm of fair use.
Book photos: Bernd Bruegge, Rich Korf, and Blake Ward

Library of Congress Cataloging-in-Publication Data on File

10 9 8 7 6 5 4 3 2 1

Prentice Hall
is an imprint of
ISBN 10: 0-13-606125-7
www.pearsonhighered.com ISBN 13: 978-0-13-606125-0
 To Goeg, Toby, and Clara.
—B.B.

To my family:
Vicky, Eleni, Anna-Maria, Michelle, and Chris
with love.
—A.H.D.
This page intentionally left blank
Foreword

O ver ten years ago, I read about a software engineering course taught by Bernd Bruegge at
Carnegie-Mellon University. In software engineering courses at many other universities, small
groups of 3 or 4 students were assigned several toy problems during a semester with deadlines of
less than a month. On such small projects, one strong programmer can carry the whole team by
brute force. It isn’t necessary to learn communication skills, use modeling tools, or deal with the
ambiguities of actual problems. Students come away unprepared for the complexities of real-
world development. In Bruegge’s course, the entire class worked on a single, semester-long
project to produce a query-oriented navigation system for the city of Pittsburgh. They had to
build on the interactive mapping system produced by the previous semester’s class. The clients
were managers for the county planning department and port authority. The geographic and bus
schedule data had misspellings, inaccuracies, and incompatible formats. The students produced
an accepted system of over 27,000 lines of code. What a difference from the toy projects taught
at many other places! Students came away from the course with an appreciation of the need for
strategy, organization, and tools to deal with the complexity and messiness of the real world.
They learned software engineering the only way one learns any craft—by practicing it on
realistic cases.
This book is a reflection of that pragmatic philosophy of software development as an
engineering discipline. The authors adopt a point of view—an object-oriented approach using
UML—that makes the many facets of software engineering approachable to students. They
cover both the modeling techniques and the human communications skills needed to achieve
success. They also include several chapters on managing change, a topic that appears in every
real project but which is often neglected in texts. Readers of this book will gain a solid
appreciation of the rich scope and complexity of software engineering.

v
vi Foreword

I particularly enjoyed the many illuminating anecdotes selected from a wide range of
fields. These provide lively examples of problems large and small that illustrate the subtleties
and traps that engineers must confront. Any book that makes relevant examples of Polynesian
navigation, the tangled history of the text of Tolkien’s Lord of the Rings, and grandmother’s
recipe for trimming hams is not only useful but also fun to read.

Jim Rumbaugh
Preface

T he K2 towers at 8,611 meters in the Karakorum range of the western Himalayas. It is the
second highest peak of the world and is considered the most difficult 8000er to climb. An
expedition to the K2 typically lasts several months in the summer, when the weather is most
favorable. Even in summer, snowstorms are frequent. An expedition requires thousands of
pounds of equipment, including climbing gear, severe weather protection gear, tents, food,
communication equipment, and pay and shoes for hundreds of porters. Planning such an
expedition takes a significant amount of time in the life of a climber and requires dozens of
participants in supporting roles. Once on site, many unexpected events, such as avalanches,
porter strikes, or equipment failures, will force the climbers to adapt, find new solutions, or
retreat. The success rate for expeditions to the K2 is currently less than 40%.
The United States National Airspace System (NAS) monitors and controls air traffic in the
United States. The NAS includes more than 18,300 airports, 21 air route traffic control centers,
and over 460 control towers. These add up to more than 34,000 pieces of equipment, including
radar systems, communication switches, radios, computer systems, and displays. The current
infrastructure is aging rapidly. The computers supporting the 21 air route traffic control centers,
for example, are IBM 3083 mainframes that date back to the early 1980s. In 1996, the United
States government initiated a program to modernize the NAS infrastructure, including
improvements such as satellite navigation, digital controller/pilot communications, and a higher
degree of automation in controlling the air routes, deciding the order in which aircraft land, and
controlling ground traffic as aircraft move from and to the runways. Such a complex
infrastructure, however, can only be modernized incrementally. Consequently, while new
components offering new functionality are introduced, older components still need to be
supported. For example, during the transition period, a controller will have to be able to use both
analog and digital voice channels to communicate with pilots. Finally, the modernization of the

vii
viii Preface

NAS coincides with a dramatic increase in global air traffic, predicted to double within the next
10–15 years. The previous modernizing effort of the NAS, called the Advanced Automation
System (AAS), was suspended in 1994 because of software-related problems, after missing its
initial deadline by several years and exceeding its budget by several billions of dollars.
Both of the above examples discuss complex systems in which external conditions can
trigger unexpected changes. Complexity puts the problem beyond the control of any single
individual. Change forces participants to move away from well-known solutions and to invent
new ones. In both examples, several participants need to cooperate and develop new techniques
to address these challenges. Failure to do so results in failure to reach the goal.
This book is about conquering complex and changing software systems.

The theme

The application domain (mountain expedition planning, air traffic control, financial
systems, word processing) usually includes many concepts that software developers are not
familiar with. The solution domain (user interface toolkits, wireless communication, middleware,
database management systems, transaction processing systems, wearable computers) is often
immature and provides developers with many competing implementation technologies.
Consequently, the system and the development project are complex, involving many different
components, tools, methods, and people.
As developers learn more about the application domain from their users, they update the
requirements of the system. As developers learn more about emerging technologies or about the
limitations of current technologies, they adapt the system design and implementation. As quality
control finds defects in the system and users request new features, developers modify the system
and its associated work products. The result is continuous change.
Complexity and change represent challenges that make it impossible for any single
person to control the system and its evolution. If controlled improperly, complexity and change
defeat the solution before its release, even if the goal is in sight. Too many mistakes in the
interpretation of the application domain make the solution useless for the users, forcing a
retreat from the route or the market. Immature or incompatible implementation technologies
result in poor reliability and delays. Failure to handle change introduces new defects in the
system and degrades performance beyond usability.
This book reflects more than 10 years of building systems and of teaching software
engineering project courses. We have observed that students are taught programming and
software engineering techniques in isolation, often using small problems as examples. As a
result, they are able to solve well-defined problems efficiently, but are overwhelmed by the
complexity of their first real development experience, when many different techniques and tools
need to be used and different people need to collaborate. Reacting to this state of affairs, the
typical undergraduate curriculum now often includes a software engineering project course,
organized as a single development project.
Preface ix

The tools: UML, Java, and Design Patterns

We wrote this book with a project course in mind. The book can be used, however, in other
situations as well, such as short and intensive workshops or short-term R&D projects. We use
examples from real systems and examine the interaction among state-of-the art techniques, such
as UML (Unified Modeling Language), Java-based technologies, design patterns, design
rationale, configuration management, and quality control. Moreover, we discuss project
management related issues that are related to these techniques and their impact on complexity
and change.

The principles

We teach software engineering following five principles:

Practical experience. We believe that software engineering education must be linked with
practical experience. Students can understand complexity only by working with a complex
system—that is, a system that no single student can completely understand.
Problem solving. We believe that software engineering education must be based on problem
solving. Consequently, there are no right or wrong solutions, only solutions that are better or
worse relative to stated criteria. Although we survey existing solutions to real problems and
encourage their reuse, we also encourage criticism and the improvement of standard solutions.
Limited resources. If we have sufficient time and resources, we could perhaps build the ideal
system. There are several problems with such a situation. First, it is not realistic. Second, even if
we had sufficient resources, if the original problem rapidly changes during the development, we
would eventually deliver a system solving the wrong problem. As a result, we assume that our
problem-solving process is limited in terms of resources. Moreover, the acute awareness of
scarce resources encourages a component-based approach and reuse of knowledge, design, and
code. In other words, we support an engineering approach to software development.
Interdisciplinarity. Software engineering is an interdisciplinary field. It requires contributions
from areas spanning electrical and computer engineering, computer science, business
administration, graphic design, industrial design, architecture, theater, and writing. Software
engineering is an applied field. When trying to understand and model the application domain,
developers interact regularly with others, including users and clients, some of whom know little
about software development. This requires viewing and approaching the system from multiple
perspectives and terminologies.
Communication. Even if developers built software for developers only, they would still need
to communicate among themselves. As developers, we cannot afford the luxury of being able to
communicate only with our peers. We need to communicate alternatives, articulate solutions,
negotiate trade-offs, and review and criticize others’ work. A large number of failures in
software engineering projects can be traced to the communication of inaccurate information or
x Preface

to missing information. We must learn to communicate with all project participants, including,
most importantly, the client and the end users.
These five principles are the basis for this book. They encourage and enable the reader to
address complex and changing problems with practical and state-of-the-art solutions.

The book
This book is based on object-oriented techniques applied to software engineering. It is
neither a general software engineering book that surveys all available methods nor a
programming book about algorithms and data structures. Instead, we focus on a limited set of
techniques and explain their application in a reasonably complex environment, such as a multi-
team development project that includes 20 to 60 participants. Consequently, the book also
reflects our biases, our strengths, and our weaknesses. We hope, nevertheless, that all readers
will find something they can use. The book is structured into 16 chapters organized into three
parts, which can be taught as a semester-long course.
Part I, Getting Started, includes three chapters. In this part, we focus on the basic skills
necessary for a developer to function in a software engineering context.

• In Chapter 1, Introduction to Software Engineering, we describe the difference between

programming and software engineering, the current challenges in our discipline, and
basic definitions of concepts we use throughout the book.
• In Chapter 2, Modeling with UML, we describe the basic elements of a modeling
language, UML, used in object-oriented techniques. We present modeling as a
technique for dealing with complexity. This chapter teaches the reader how to read and
understand UML diagrams. Subsequent chapters teach the reader how to build UML
diagrams to model various aspects of the system. We use UML throughout the book to
model a variety of artifacts, from software systems to processes and work products.
• In Chapter 3, Project Organization and Communication, we introduce basic concepts
of project organization and communication. Developers and managers spend more than
half of their time communicating with others, either face-to-face or via E-mail,
groupware, video conference, or written documents. Whereas modeling deals with
complexity, communication deals with change. We describe project organizations and
discuss what constitutes effective communication.

In Part II, Dealing with Complexity, we focus on methods and technologies that enable
developers to specify, design, and implement complex systems.

• In Chapter 4, Requirements Elicitation, and Chapter 5, Analysis, we describe the

definition of the system from the users’ point of view. During requirements elicitation,
developers determine the functionality users need and a usable way of delivering it.
During analysis, developers formalize this knowledge and ensure its completeness and
Preface xi

consistency. We focus on how UML is used to deal with application domain

complexity.
• In Chapter 6, System Design: Decomposing the System, and Chapter 7, System Design:
Addressing Design Goals, we describe the definition of the system from the
developers’ point of view. During this phase, developers define the architecture of the
system in terms of design goals and a subsystem decomposition. They address global
issues, such as the mapping of the system onto hardware, the storage of persistent data,
and global control flow. We focus on how developers can use architectural styles,
components, and UML to deal with solution domain complexity.
• In Chapter 9, Object Design: Specifying Interfaces, Chapter 9, Object Design:
Specifying Interfaces, and Chapter 10, Mapping Models to Code, we describe the
detailed modeling and construction activities related to the solution domain. During
this phase, developers identify and adapt design patterns and frameworks to realize
specific subsystems. They refine and specify precisely the interfaces of classes using
constraint languages such as UML’s Object Constraint Language. Finally, they map the
detailed object design model to source code and database schema.
• In Chapter 11, Testing, we describe the validation of system behavior against the
system models. Testing detects faults in the system, including those introduced during
changes to the system or its requirements. Testing activities include unit testing,
integration testing, and system testing. We describe several testing techniques, such as
whitebox, blackbox, path testing, state-based testing, and inspections, and discuss their
application to object-oriented systems.

In Part III, Managing Change, we focus on methods and technologies that support the
control, assessment, and implementation of changes throughout the development of a system.

• In Chapter 12, Rationale Management, we describe the capture of design decisions and
their justifications. The models developed during requirements elicitation, analysis, and
system design help us deal with complexity by providing different perspectives on what
the system should be doing and how it should do it. To be able to deal with change, we
need also to know why the system is the way it is. Capturing design decisions,
considered alternatives, and their argumentation enables us to access the rationale of
the system.
• In Chapter 13, Configuration Management, we describe techniques for modeling the
project history. Configuration management complements rationale in helping us deal
with change. Version management records the evolution of the system. Release
management ensures consistency and quality across the components of a release.
Change management ensures that modifications to the system are consistent with
project goals.
• In Chapter 14, Project Management, we describe techniques for initiating a software
development project, tracking its progress, and dealing with risks and unplanned
xii Preface

events. We focus on organizations, roles, and management activities that allow a large
number of participants to collaborate and deliver a high-quality system within planned
constraints.
• In Chapter 15, Software Life Cycle, we describe software life cycles, such as Boehm’s
Spiral Model and the Unified Software Development Process, that provide an abstract
model of development activities. In this chapter, we also describe the Capability
Maturity Model, which is used for assessing the maturity of organizations.
• In Chapter 16, Methodologies: Putting It All Together, we describe methodologies and
heuristics for applying the material covered in the other chapters to concrete situations.
No matter how thorough the requirements elicitation or detailed the planning, projects
of any realistic size encounter unexpected events and changes. Dealing with uncertainty
makes real projects and systems look very different from projects and systems
examined in textbooks. In this chapter, we describe several different methodologies,
discuss issues that need to be addressed in every project, and present three case studies
of actual projects.

The topics above are strongly interrelated. To emphasize their relationships, we selected
an iterative approach. Each chapter consists of five sections. In the first section, we introduce the
issues relevant to the topic with an illustrative example. In the second section, we describe
briefly the activities of the topic. In the third section, we explain the basic concepts of the topic
with simple examples. In the fourth section, we detail the technical activities with examples
from real systems. Finally, we describe management activities and discuss typical trade-offs. In
Chapters 4–10, we present a running case study of a complex multi-user game management
system called ARENA. By repeating and elaborating on the same concepts in increasingly
complex examples, we hope to provide the reader with an operational knowledge of object-
oriented software engineering.

The courses
Building a large, complex system can be compared with climbing a big mountain. It is
good to have a route description, but the route can never be completely mapped out, as new
crevasses may open anytime. Even though we map out our software engineering knowledge in
this book, changes will occur and methods that we believe in now may be out of date soon.
How can we teach students to cope with such rapidly changing conditions? For us, the
most important thing to pass on to a student is not only knowledge of the map, but also the
ability to negotiate the terrain. Although it is wise to study the description of a route, there is no
substitute for the experience of actually traveling the route.
We wrote this book for a semester-long software engineering project course for senior or
graduate students. We assume that students have experience with a programming language such
as C, C++, C#, or Java. We expect that students have the necessary problem-solving skills to
attack technical problems, but we do not expect that they have been exposed to the complex or
Preface xiii

changing situations typical of system development. This book can also be used for other types of
courses, such as short, intensive professional courses.
Project and senior-level courses. A project course should include all the chapters of the
book, roughly in the order presented. An instructor may consider teaching more advanced
project management concepts from Chapter 14, Project Management, early in the course so that
students become familiar with planning and controlling.
Introductory-level course. An introductory course with homework should focus on the first
three sections of each chapter. The fourth section and the case study can be used as material for
homework and can simulate the building of a minisystem using paper for UML diagrams,
documents, and code.
Short technical course. The book can also be used for a short, intensive course geared
toward professionals. A technical course focusing on UML and object-oriented methods could
use the chapter sequence 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, covering all development phases from
requirements elicitation to testing. An advanced course would also include Chapter 12,
Rationale Management, and Chapter 13, Configuration Management.
Short management course. The book can also be used for a short, intensive course geared
toward managers. A management course focusing on managerial aspects such as
communication, risk management, rationale, maturity models, and UML could use the chapter
sequence 1, 2, 3, 14, 15, 16, 12, 13.

Changes since the second edition

This edition started as an upgrade of our book to UML 2 and to the latest advances in agile
methods. In the process, we also added new material about system design and testing. We thank
Tracy Dunkelberger, our publisher, for her patience. We made the following changes:

• Comprehensive upgrade to the latest UML and OCL standards. We revised most
diagrams in the book to take advantage of the latest advances of UML and OCL. In
particular, we use component diagrams with ball-and-socket notation during system
and object design.
• Expanded material on agile methods. In the second edition, we introduced coverage of
the XP methodology in Chapter 16. In this edition, we extended the material on agile
methods to Scrum and Rugby and consequently adapted the material on testing,
configuration management, and project management in Chapters 11, 13, and 14.
• New material on continuous integration. A practice of agile methods, used in other
contexts as well, is the continuous integration of software changes into main production
trunk. While this practice allows integration problems to be identified, and thus
resolved, much earlier, its realization presents initially many challenges. We present
this new material in Chapter 13, Software Configuration Management.
xiv Preface

• New material on U2TP and automated testing. In our teaching, we found the extensions
of the UML 2 Testing Profile facilitate the discussion of testing concepts, in particular,
the distinction between the testing system and the system under test. This also allowed
us to extend the material on testing to automated testing and automatic test generation.
• Improvements of the case study and examples throughout. Since the last edition, we
received a lot of feedback about the case study and the examples in this book. We are
grateful of this feedback and consequently implemented many suggestions, too
numerous to enumerate here in detail.

Typographical conventions
We use the following conventions throughout the book:

• A new term appears in bold when defined the first time.

• Book titles, chapter titles, and emphasized terms appear in italics.
• The names of systems and of modeling elements (e.g., class, attribute, operation, state,
variable) appear in monospaced font.
• The names of abstract classes appear in italics monospaced font.
• Object names appear underlined in figures.
• URLs appear in underlined roman.
• Source code appears in monospaced font, with reserved keywords in bold and
comments in italics.

Production notes
This book was written and composed using Adobe Framemaker. The final print images
were generated as PDF files using Adobe Acrobat Distiller.

About the authors

Dr. Bernd Bruegge has been studying and teaching Software Engineering at Carnegie
Mellon University for 20 years, where he received his masters and doctorate degrees. He
received his Diplom from the University of Hamburg. He is now a university professor of
Computer Science with a chair for Applied Software Engineering at the Technische Universität
München and an adjunct faculty member of Carnegie Mellon University. He has taught
object-oriented software engineering project courses on the text materials and website described
in this book for 15 years. He won the Herbert A. Simon Excellence in Teaching Award at
Carnegie Mellon University in 1995. Bruegge is also an international consultant and has used
the techniques in this book to design and implement many real systems, including an
engineering feedback system for DaimlerChrysler, an environmental modeling system for the
U.S. Environmental Protection Agency, and an accident management system for a municipal
police department, to name just a few.
Preface xv

Dr. Allen Dutoit works in the aerospace industry in the area of avionics software
development. He received his M.S. and Ph.D. from Carnegie Mellon University and his Diplôme
d’Ingénieur from the Swiss Federal Institute of Technology in Lausanne. He has taught software
engineering project courses with Professor Bruegge since 1993, both at Carnegie Mellon
University and the Technische Universität München, where they used and refined the methods
described in this book. Dutoit’s research covered several areas of software engineering and
object-oriented systems, including requirements engineering, rationale management, distributed
development, and prototype-based systems. He was previously affiliated with the Software
Engineering Institute and the Institute for Complex Engineered Systems at Carnegie Mellon
University.

Opener Pictures
The pictures at the beginning of each chapter are from an Alpine-style ascent of the West
Rib of Denali (6,193 m) made by one of the authors before starting to work on this book. During
this trip, the analogy between software development and mountaineering became more than
obvious. The pictures chronicle the climb, showing our expedition car on the Alaskan Canadian
Highway, a view of Mt. Robson with the Kain Face (Chapter 1), a view of Denali from the plane
(Chapters 2 and 4), the beginning of the West Rib (Chapter 3), a look 1000 meters down from
the top of the West Rib showing our foot tracks on the East Kahiltna Glacier (Chapter 5), Mt.
Foraker from Camp 5 (Chapter 6), a beautiful but difficult edge around 5,000m (Chapter 7), the
Base Camp of the normal route where we reused the remains of an igloo (Chapter 8), the landing
area for Doug Geeting’s plane (Chapter 9), a bivouac place at the top of the West Rib named
“Hotel Crux,” because one cannot dig an area big enough for a tent (Chapter 10), crossing the
Bergschrund (Chapter 11), a fresh avalanche area (Chapter 12), Denali with the Cassin Ridge
(Chapter 13), plans for different routes to the summit (Chapter 14), a “horizontal” sunrise at the
start of the Cassin Ridge (Chapter 15), and the summit of Denali (Chapter 16).
The cover picture shows the summit of K2.
This page intentionally left blank
Acknowledgments

T his book has witnessed much complexity and change during its development. In 1989, the
first author (B.B.) originally set out to teach software engineering in a single-project course
format. The goal was to expose students to the important issues in software engineering by
solving real problems described by real clients with real tools under real constraints. The first
course, listed as 15-413 in the Carnegie Mellon catalog of courses, had 19 students, used SA/SD,
and produced 4,000 lines of code. Heavily influenced by the book by James Rumbaugh and his
colleagues on object-oriented modeling and design, we have used object-oriented methods since
then. We taught several distributed versions of the course involving up to 100 students from
Carnegie Mellon and Technische Universität München, resulting in systems with up to 500
pages of documentation and 50,000 lines of code. We currently are teaching a distributed course
involving students from University of Otago in New Zealand and Technische Universität
München.
The drawback of project courses is that instructors do not escape the complexity and
change that their students experience. Instructors quickly become participants in the
development themselves, often acting as project managers. We hope that this book will help both
instructors and students conquer this level of complexity and change.
Somehow, in spite of much energy spent on the course, we found time to write and
complete this textbook and its subsequent revision, thanks to the help and patience of numerous
students, clients, teaching assistants, support staff, coinstructors, reviewers, Prentice Hall staff,
and most of all, our families. Some have contributed to improving the course, others have
provided constructive feedback on successive drafts, and yet others were simply there when the
going got tough. Over the past 20 years, we have indebted ourselves to many people whom we
acknowledge here.

xvii
xviii Acknowledgments

The participants of the project courses. Workstation Fax (1989), Interactive Maps (1991),
Interactive Pittsburgh (1991), FRIEND (1992, 1993, 1994), JEWEL, GEMS (1991, 1994, 1995),
DIAMOND (1995, 1996), OWL (1996, 1997), JAMES (1997, 1998), PAID (1998, 1999),
STARS (1999, 2000, 2001), TRAMP (2001, 2002), ARENA (2002, 2003), CampusTV (2004,
2005), Virtual Symphony Orchester (2005), WALOS (2006), and DOLLI (2007, 2008).
The people who supported the projects. For their commitment, for their kindness, and for
getting us out of trouble when we needed it: Martin Bauer, Ulrich Bauer, Catherine Copetas,
Oliver Creighton, Ava Cruse, Barry Eisel, Luca Girardo, Dieter Hege, Mariss Jansons, Joyce
Johnstone, SiegfriedKiese, Siegfried Klinkhammer, Rafael Kobylinski, Marc Lindike, Asa
MacWilliams, Monika Markl, Key Maerkl and his Aritus Quartet, Pat Miller, Martin Ott, Ralf
Pfleghar, Martin Pittenauer, Harald Ranner, Joachim Reichel, Max Reiss, Barbara Sandling,
Christian Sandor, Ralph Schiessl, Arno Schmackpfeffer, Helma Schneider, Stephan Schoenig,
Steffen Schwarz, Martin Wagner, Uta Weber, Timo Wolf, and Michael Zaddach.
The collegues, coinstructors, and friends who influenced us. Mario Barbacci, Len Bass,
Ben Bennington, Elizabeth Bigelow, Roberto Bisiani, Naoufel Boulila, Harry Q Bovik, Andreas
Braun, Manfred Broy, Sharon Burks, Marvin Carr, Mike Collins, Robert Coyne, Douglas
Cunningham, Michael Ehrenberger, Kim Faught, Peter Feiler, Allen Fisher, Laura Forsyth, Eric
Gardner, Helen Granger, Thomas Gross, Volker Hartkopf, Bruce Horn, David Kauffer, Gudrun
Klinker, Kalyka Konda, Suresh Konda, Rich Korf, Birgitte Krogh, Sean Levy, Frank Mang, K.
C. Marshall, Dick Martin (“Tang Soo”), Horst Mauersberg, Roy Maxion, Russ Milliken, Ira
Monarch, Rhonda Moyer, Robert Patrick, Brigitte Pihulak, Mark Pollard, Martin Purvis, Raj
Reddy, Yoram Reich, James Rumbaugh, Johann Schlichter, Mary Shaw, Jane Siegel, Daniel
Siewiorek, Asim Smailagic, Mark Stehlik, Eswaran Subrahmanian, Stephanie Szakal, Tara
Taylor, Michael Terk, Günter Teubner, Marc Thomas, Walter Tichy, Jim Tomayko, Blake Ward,
Alex Waibel, Art Westerberg, Jeannette Wing, and Tao Zhang.
Reviewers who gave us constructive feedback and who helped us get many details right:
Martin Barrett, Brian Berenbach, Alex Borgida, Ramsey Bualuan, Dave Chesney, Andrea De
Lucia, Debora East, Thomas Eichhorn, Henry Etlinger, Ray Ford, Jim Helm, Jonas Helming,
Korbinian Herrmann, Allen Holliday, John Keklak, Robert Lechner, Max Koegel, Jonathan
Maletic, Jeff McKinstry, Bruce Maxim, Gerhard Mueller, Michael Nagel, Helmut Naughton,
Barbara Paech, Dennis Pagano, Daniel Paulish, Joan Peckham, Gary Pollice, David Rine,
Florian Schneider, Ingo Schneider, Anthony Sullivan, Damla Turgut, and the many anonymous
reviewers for their constructive and detailed comments. All remaining errors are ours.
Everybody at Prentice Hall who helped us making this book a reality, in particular Alan Apt,
our first publisher, for never losing faith; Lakshmi Balasubramanian, Toni Holm, Patrick
Lindner, Camille Trentacoste, Jake Warde, and, for this edition, Tracy Dunkelberger, Scott
Disanno, and many others who worked hard toward the completion of this book, but whom we
did not have the opportunity and pleasure to meet personally.
And finally, our families, to whom we dedicate this book and without whose infinite love and
patience this enterprise would never have been possible.
Contents at a Glance
Foreword v
Preface vii
Acknowledgments xvii

PART I Getting Started 1

Chapter 1 Introduction to Software Engineering 3
Chapter 2 Modeling with UML 29
Chapter 3 Project Organization and Communication 77

PART II Dealing with Complexity 119

Chapter 4 Requirements Elicitation 121
Chapter 5 Analysis 173
Chapter 6 System Design: Decomposing the System 223
Chapter 7 System Design: Addressing Design Goals 259
Chapter 8 Object Design: Reusing Pattern Solutions 307
Chapter 9 Object Design: Specifying Interfaces 349
Chapter 10 Mapping Models to Code 393
Chapter 11 Testing 437

PART III Managing Change 491

Chapter 12 Rationale Management 493
Chapter 13 Configuration Management 537
Chapter 14 Project Management 575
Chapter 15 Software Life Cycle 621
Chapter 16 Methodologies: Putting It All Together 651

PART IV Appendices 707

This page intentionally left blank
Table of Contents

Foreword v
Preface vii
Acknowledgments xvii

PART I Getting Started 1

Chapter 1 Introduction to Software Engineering 3

1.1 Introduction: Software Engineering Failures 4
1.2 What Is Software Engineering? 5
1.2.1 Modeling 6
1.2.2 Problem Solving 8
1.2.3 Knowledge Acquisition 8
1.2.4 Rationale 9
1.3 Software Engineering Concepts 10
1.3.1 Participants and Roles 11
1.3.2 Systems and Models 12
1.3.3 Work Products 13
1.3.4 Activities, Tasks, and Resources 13
1.3.5 Functional and Nonfunctional Requirements 14
1.3.6 Notations, Methods, and Methodologies 15
1.4 Software Engineering Development Activities 16

xxi
xxii Table of Contents

1.4.1 Requirements Elicitation 16

1.4.2 Analysis 16
1.4.3 System Design 19
1.4.4 Object Design 19
1.4.5 Implementation 20
1.4.6 Testing 20
1.5 Managing Software Development 21
1.5.1 Communication 21
1.5.2 Rationale Management 22
1.5.3 Software Configuration Management 22
1.5.4 Project Management 23
1.5.5 Software Life Cycle 23
1.5.6 Putting It All Together 23
1.6 ARENA Case Study 23
1.7 Further Reading 25
1.8 Exercises 25
Chapter 2 Modeling with UML 29
2.1 Introduction 30
2.2 An Overview of UML 31
2.2.1 Use Case Diagrams 31
2.2.2 Class Diagrams 32
2.2.3 Interaction Diagrams 32
2.2.4 State Machine Diagrams 33
2.2.5 Activity Diagrams 33
2.3 Modeling Concepts 35
2.3.1 Systems, Models, and Views 35
2.3.2 Data Types, Abstract Data Types, and Instances 37
2.3.3 Classes, Abstract Classes, and Objects 38
2.3.4 Event Classes, Events, and Messages 40
2.3.5 Object-Oriented Modeling 41
2.3.6 Falsification and Prototyping 43
2.4 A Deeper View into UML 43
2.4.1 Use Case Diagrams 44
2.4.2 Class Diagrams 50
2.4.3 Interaction Diagrams 59
2.4.4 State Machine Diagrams 62
2.4.5 Activity Diagrams 65
Table of Contents xxiii

2.4.6 Diagram Organization 68

2.4.7 Diagram Extensions 70
2.5 Further Readings 71
2.6 Exercises 72
Chapter 3 Project Organization and Communication 77
3.1 Introduction: A Rocket Example 78
3.2 An Overview of Projects 79
3.3 Project Organization Concepts 83
3.3.1 Project Organizations 83
3.3.2 Roles 86
3.3.3 Tasks and Work Products 88
3.3.4 Schedule 90
3.4 Project Communication Concepts 92
3.4.1 Planned Communication 92
3.4.2 Unplanned Communication 99
3.4.3 Communication Mechanisms 102
3.5 Organizational Activities 109
3.5.1 Joining a Team 109
3.5.2 Joining the Communication Infrastructure 109
3.5.3 Attending Team Status Meetings 110
3.5.4 Organizing Client and Project Reviews 113
3.6 Further Readings 114
3.7 Exercises 115

PART II Dealing with Complexity 119

Chapter 4 Requirements Elicitation 121

4.1 Introduction: Usability Examples 122
4.2 An Overview of Requirements Elicitation 123
4.3 Requirements Elicitation Concepts 125
4.3.1 Functional Requirements 125
4.3.2 Nonfunctional Requirements 126
4.3.3 Completeness, Consistency, Clarity, and Correctness 128
4.3.4 Realism, Verifiability, and Traceability 129
4.3.5 Greenfield Engineering, Reengineering, and
Interface Engineering 129
xxiv Table of Contents

4.4 Requirements Elicitation Activities 130

4.4.1 Identifying Actors 130
4.4.2 Identifying Scenarios 132
4.4.3 Identifying Use Cases 135
4.4.4 Refining Use Cases 138
4.4.5 Identifying Relationships among Actors and
Use Cases 140
4.4.6 Identifying Initial Analysis Objects 143
4.4.7 Identifying Nonfunctional Requirements 146
4.5 Managing Requirements Elicitation 148
4.5.1 Negotiating Specifications with Clients:
Joint Application Design 148
4.5.2 Maintaining Traceability 150
4.5.3 Documenting Requirements Elicitation 151
4.6 ARENA Case Study 153
4.6.1 Initial Problem Statement 153
4.6.2 Identifying Actors and Scenarios 155
4.6.3 Identifying Use Cases 159
4.6.4 Refining Use Cases and Identifying Relationships 161
4.6.5 Identifying Nonfunctional Requirements 166
4.6.6 Lessons Learned 168
4.7 Further Readings 168
4.8 Exercises 169
Chapter 5 Analysis 173
5.1 Introduction: An Optical Illusion 174
5.2 An Overview of Analysis 174
5.3 Analysis Concepts 176
5.3.1 Analysis Object Models and Dynamic Models 176
5.3.2 Entity, Boundary, and Control Objects 177
5.3.3 Generalization and Specialization 178
5.4 Analysis Activities: From Use Cases to Objects 179
5.4.1 Identifying Entity Objects 180
5.4.2 Identifying Boundary Objects 182
5.4.3 Identifying Control Objects 184
5.4.4 Mapping Use Cases to Objects with
Sequence Diagrams 185
Table of Contents xxv

5.4.5
Modeling Interactions among Objects with
CRC Cards 189
5.4.6 Identifying Associations 190
5.4.7 Identifying Aggregates 192
5.4.8 Identifying Attributes 193
5.4.9 Modeling State-Dependent Behavior of
Individual Objects 194
5.4.10 Modeling Inheritance Relationships between Objects 195
5.4.11 Reviewing the Analysis Model 196
5.4.12 Analysis Summary 197
5.5 Managing Analysis 199
5.5.1 Documenting Analysis 199
5.5.2 Assigning Responsibilities 200
5.5.3 Communicating about Analysis 201
5.5.4 Iterating over the Analysis Model 203
5.5.5 Client Sign-Off 204
5.6 ARENA Case Study 206
5.6.1 Identifying Entity Objects 206
5.6.2 Identifying Boundary Objects 211
5.6.3 Identifying Control Objects 212
5.6.4 Modeling Interactions Among Objects 212
5.6.5 Reviewing and Consolidating the Analysis Model 213
5.6.6 Lessons Learned 217
5.7 Further Readings 218
5.8 Exercises 219
Chapter 6 System Design:
Decomposing the System 223
6.1 Introduction: A Floor Plan Example 224
6.2 An Overview of System Design 226
6.3 System Design Concepts 228
6.3.1 Subsystems and Classes 228
6.3.2 Services and Subsystem Interfaces 230
6.3.3 Coupling and Cohesion 230
6.3.4 Layers and Partitions 235
6.3.5 Architectural Styles 238
6.4 System Design Activities: From Objects to Subsystems 247
xxvi Table of Contents

6.4.1 Starting Point: Analysis Model for a

Route Planning System 247
6.4.2 Identifying Design Goals 249
6.4.3 Identifying Subsystems 253
6.5 Further Readings 255
6.6 Exercises 255
Chapter 7 System Design:
Addressing Design Goals 259
7.1 Introduction: A Redundancy Example 260
7.2 An Overview of System Design Activities 261
7.3 Concepts: UML Deployment Diagrams 262
7.4 System Design Activities: Addressing Design Goals 264
7.4.1 Mapping Subsystems to Processors and Components 264
7.4.2 Identifying and Storing Persistent Data 266
7.4.3 Providing Access Control 269
7.4.4 Designing the Global Control Flow 275
7.4.5 Identifying Services 277
7.4.6 Identifying Boundary Conditions 279
7.4.7 Reviewing System Design 282
7.5 Managing System Design 284
7.5.1 Documenting System Design 284
7.5.2 Assigning Responsibilities 286
7.5.3 Communicating about System Design 287
7.5.4 Iterating over the System Design 288
7.6 ARENA Case Study 290
7.6.1 Identifying Design Goals 290
7.6.2 Identifying Subsystems 291
7.6.3 Mapping Subsystems to Processors and Components 292
7.6.4 Identifying and Storing Persistent Data 294
7.6.5 Providing Access Control 295
7.6.6 Designing the Global Control Flow 296
7.6.7 Identifying Services 297
7.6.8 Identifying Boundary Conditions 299
7.6.9 Lessons Learned 302
7.7 Further Readings 302
7.8 Exercises 303
Table of Contents xxvii

Chapter 8 Object Design:

Reusing Pattern Solutions 307
8.1 Introduction: Bloopers 308
8.2 An Overview of Object Design 309
8.3 Reuse Concepts: Solution Objects, Inheritance, and
Design Patterns 313
8.3.1 Application Objects and Solution Objects 313
8.3.2 Specification Inheritance and Implementation
Inheritance 313
8.3.3 Delegation 316
8.3.4 The Liskov Substitution Principle 317
8.3.5 Delegation and Inheritance in Design Patterns 317
8.4 Reuse Activities: Selecting Design Patterns and Components 320
8.4.1 Encapsulating Data Stores with the Bridge Pattern 321
8.4.2 Encapsulating Legacy Components with the Adapter
Pattern 323
8.4.3 Encapsulating Context with the Strategy Pattern 325
8.4.4 Encapsulating Platforms with the Abstract Factory
Pattern 326
8.4.5 Encapsulating Control Flow with the Command
Pattern 329
8.4.6 Encapsulating Hierarchies with the Composite
Design Pattern 330
8.4.7 Heuristics for Selecting Design Patterns 332
8.4.8 Identifying and Adjusting Application Frameworks 332
8.5 Managing Reuse 337
8.5.1 Documenting Reuse 338
8.5.2 Assigning Responsibilities 340
8.6 ARENA Case Study 341
8.6.1 Applying the Abstract Factory Design Pattern 341
8.6.2 Applying the Command Design Pattern 342
8.6.3 Applying the Observer Design Pattern 342
8.6.4 Lessons Learned 344
8.7 Further Readings 344
8.8 Exercises 345
xxviii Table of Contents

Chapter 9 Object Design:

Specifying Interfaces 349
9.1 Introduction: A Railroad Example 350
9.2 An Overview of Interface Specification 351
9.3 Interface Specification Concepts 352
9.3.1 Class Implementor, Class Extender, and Class User 353
9.3.2 Types, Signatures, and Visibility 354
9.3.3 Contracts: Invariants, Preconditions, and
Postconditions 356
9.3.4 Object Constraint Language 357
9.3.5 OCL Collections: Sets, Bags, and Sequences 361
9.3.6 OCL Quantifiers: forAll and exists 365
9.4 Interface Specification Activities 365
9.4.1 Identifying Missing Attributes and Operations 366
9.4.2 Specifying Types, Signatures, and Visibility 368
9.4.3 Specifying Pre- and Postconditions 369
9.4.4 Specifying Invariants 371
9.4.5 Inheriting Contracts 374
9.5 Managing Object Design 375
9.5.1 Documenting Object Design 375
9.5.2 Assigning Responsibilities 381
9.5.3 Using Contracts During Requirements Analysis 382
9.6 ARENA Case Study 382
9.6.1 Identifying Missing Operations in TournamentStyle
and Round 383
9.6.2 Specifying the TournamentStyle and Round
Contracts 384
9.6.3 Specifying the KnockOutStyle and KnockOutRound
Contracts 386
9.6.4 Lessons Learned 387
9.7 Further Readings 388
9.8 Exercises 389
Chapter 10 Mapping Models to Code 393
10.1 Introduction: A Book Example 394
10.2 An Overview of Mapping 395
10.3 Mapping Concepts 396
Table of Contents xxix

10.3.1 Model Transformation 397

10.3.2 Refactoring 398
10.3.3 Forward Engineering 400
10.3.4 Reverse Engineering 401
10.3.5 Transformation Principles 401
10.4 Mapping Activities 402
10.4.1 Optimizing the Object Design Model 402
10.4.2 Mapping Associations to Collections 406
10.4.3 Mapping Contracts to Exceptions 412
10.4.4 Mapping Object Models to a Persistent Storage
Schema 416
10.5 Managing Implementation 422
10.5.1 Documenting Transformations 422
10.5.2 Assigning Responsibilities 424
10.6 ARENA Case Study 424
10.6.1 ARENA Statistics 424
10.6.2 Mapping Associations to Collections 426
10.6.3 Mapping Contracts to Exceptions 428
10.6.4 Mapping the Object Model to a Database Schema 430
10.6.5 Lessons Learned 431
10.7 Further Readings 432
10.8 Exercises 432
Chapter 11 Testing 437
11.1 Introduction: Testing The Space Shuttle 438
11.2 An Overview of Testing 440
11.3 Testing Concepts 444
11.3.1 Faults, Erroneous States, and Failures 445
11.3.2 Test Cases 448
11.3.3 Test Stubs and Drivers 450
11.3.4 Corrections 451
11.4 Testing Activities 451
11.4.1 Component Inspection 452
11.4.2 Usability Testing 453
11.4.3 Unit Testing 455
11.4.4 Integration Testing 465
11.4.5 System Testing 471
11.5 Managing Testing 476
xxx Table of Contents

11.5.1 Planning Testing 476

11.5.2 Documenting Testing 478
11.5.3 Assigning Responsibilities 480
11.5.4 Regression Testing 481
11.5.5 Automating Testing 482
11.5.6 Model-Based Testing 484
11.6 Further Readings 487
11.7 Exercises 488

PART III Managing Change 491

Chapter 12 Rationale Management 493

12.1 Introduction: Slicing Ham 494
12.2 An Overview of Rationale 495
12.3 Rationale Concepts 497
12.3.1 Centralized Traffic Control 498
12.3.2 Defining the Problem: Issues 499
12.3.3 Exploring the Solution Space: Proposals 500
12.3.4 Evaluating the Solution Space: Criteria and
Arguments 502
12.3.5 Collapsing the Solution Space: Resolutions 504
12.3.6 Implementing Resolutions: Action Items 504
12.3.7 Examples of Issue-Based Models and Systems 505
12.4 Rationale Activities: From Issues to Decisions 510
12.4.1 CTC System Design 510
12.4.2 Capturing Rationale in Meetings 511
12.4.3 Capturing Rationale Asynchronously 519
12.4.4 Capturing Rationale when Discussing Change 520
12.4.5 Reconstructing Rationale 524
12.5 Managing Rationale 526
12.5.1 Documenting Rationale 526
12.5.2 Assigning Responsibilities 528
12.5.3 Heuristics for Communicating about Rationale 529
12.5.4 Issue Modeling and Negotiation 530
12.5.5 Conflict Resolution Strategies 531
12.6 Further Readings 533
12.7 Exercises 533
Table of Contents xxxi

Chapter 13 Configuration Management 537

13.1 Introduction: An Aircraft Example 538
13.2 An Overview of Configuration Management 540
13.3 Configuration Management Concepts 541
13.3.1 Configuration Items and CM Aggregates 542
13.3.2 Versions and Configurations 543
13.3.3 Change Requests 544
13.3.4 Promotions and Releases 544
13.3.5 Repositories and Workspaces 545
13.3.6 Version Identification Schemes 545
13.3.7 Changes and Change Sets 548
13.3.8 Configuration Management Tools 548
13.4 Configuration Management Activities 550
13.4.1 Configuration Item and CM Aggregate Identification 552
13.4.2 Promotion Management 554
13.4.3 Release Management 555
13.4.4 Branch Management 557
13.4.5 Variant Management 562
13.4.6 Change Management 565
13.5 Managing Configuration Management 566
13.5.1 Documenting Configuration Management 567
13.5.2 Assigning Configuration Management
Responsibilities 568
13.5.3 Planning Configuration Management Activities 568
13.5.4 Continuous Integration: Testing and Promotion
Management 569
13.6 Further Readings 571
13.7 Exercises 572
Chapter 14 Project Management 575
14.1 Introduction: The STS-51L Launch Decision 576
14.2 An Overview of Project Management 577
14.3 Project Management Concepts 584
14.3.1 Tasks and Activities 584
14.3.2 Work Products, Work Packages, and Roles 585
14.3.3 Work Breakdown Structure 586
14.3.4 Task Model 586
xxxii Table of Contents

14.3.5 Skill Matrix 588

14.3.6 The Software Project Management Plan 589
14.4 Classical Project Management Activities 592
14.4.1 Planning the Project 592
14.4.2 Organizing the Project 598
14.4.3 Controlling the Project 603
14.4.4 Terminating the Project 609
14.5 Agile Project Management Activities 611
14.5.1 Planning the Project: Create Product and Sprint
Backlogs 611
14.5.2 Organizing the Project 612
14.5.3 Controlling the Project: Daily Scrums and
Burn Down Charts 613
14.5.4 Terminating the Project: Sprint Reviews 614
14.6 Further Readings 616
14.7 Exercises 617
Chapter 15 Software Life Cycle 621
15.1 Introduction: Polynesian Navigation 622
15.2 IEEE 1074: Standard for Developing Life Cycle Processes 626
15.2.1 Processes and Activities 626
15.2.2 Life Cycle Modeling 628
15.2.3 Project Management 628
15.2.4 Pre-Development 629
15.2.5 Development 630
15.2.6 Post-Development 631
15.2.7 Integral Processes (Cross-Development) 632
15.3 Characterizing the Maturity of Software Life Cycle Models 633
15.4 Life Cycle Models 636
15.4.1 Sequential Activity-Centered Models 637
15.4.2 Iterative Activity-Centered Models 639
15.4.3 Entity-Centered Models 644
15.5 Further Readings 647
15.6 Exercises 648
Chapter 16 Methodologies:
Putting It All Together 651
16.1 Introduction: The First Ascent of K2 652
Table of Contents xxxiii

16.2 Project Environment 655

16.3 Methodology Issues 657
16.3.1 How Much Planning? 657
16.3.2 How Much Reuse? 658
16.3.3 How Much Modeling? 659
16.3.4 How Much Process? 661
16.3.5 How Much Control and Monitoring? 661
16.3.6 When to Redefine Project Goals? 662
16.4 A Spectrum of Methodologies 662
16.4.1 Royce’s Methodology 663
16.4.2 Extreme Programming 669
16.4.3 Rugby Methodologies 673
16.5 Case Studies 680
16.5.1 XP Project: ATRACT 681
16.5.2 Local King Client: FRIEND 684
16.5.3 Distributed Project: JAMES 691
16.5.4 Case Studies Summary 698
16.6 Further Readings 703
16.7 Exercises 703

PART IV Appendices 707

Appendix A Design Patterns 709

A.1 Abstract Factory: Encapsulating Platforms 710
A.2 Adapter: Wrapping Around Legacy Code 711
A.3 Bridge: Allowing for Alternate Implementations 712
A.4 Command: Encapsulating Control Flow 713
A.5 Composite: Representing Recursive Hierarchies 714
A.6 Facade: Encapsulating Subsystems 715
A.7 Observer: Decoupling Entities from Views 716
A.8 Proxy: Encapsulating Expensive Objects 717
A.9 Strategy: Encapsulating Algorithms 718
A.10 Heuristics for Selecting Design Patterns 719
Appendix B Glossary 721
Appendix C Bibliography 753
Index 767
This page intentionally left blank
PART I
Getting Started
1

1.1 Introduction: Software Engineering Failures 4

1.2 What Is Software Engineering? 5
1.2.1 Modeling 6
1.2.2 Problem Solving 8
1.2.3 Knowledge Acquisition 8
1.2.4 Rationale 9
1.3 Software Engineering Concepts 10
1.3.1 Participants and Roles 11
1.3.2 Systems and Models 12
1.3.3 Work Products 13
1.3.4 Activities, Tasks, and Resources 13
1.3.5 Functional and Nonfunctional Requirements 14
1.3.6 Notations, Methods, and Methodologies 15
1.4 Software Engineering Development Activities 16
1.4.1 Requirements Elicitation 16
1.4.2 Analysis 16
1.4.3 System Design 19
1.4.4 Object Design 19
1.4.5 Implementation 20
1.4.6 Testing 20
1.5 Managing Software Development 21
1.5.1 Communication 21
1.5.2 Rationale Management 22
1.5.3 Software Configuration Management 22
1.5.4 Project Management 23
1.5.5 Software Life Cycle 23
1.5.6 Putting It All Together 23
1.6 ARENA Case Study 23
1.7 Further Reading 25
1.8 Exercises 25
References 27

2
 1
Introduction to
Software Engineering
The amateur software engineer is always in search of magic,
some sensational method or tool whose application promises to
render software development trivial. It is the mark of the
professional software engineer to know that no such panacea
exists.

—Grady Booch, in Object-Oriented Analysis and Design

T he term software engineering was coined in 1968 as a response to the desolate state of the
art of developing quality software on time and within budget. Software developers were not able
to set concrete objectives, predict the resources necessary to attain those objectives, and manage
the customers’ expectations. More often than not, the moon was promised, a lunar rover built,
and a pair of square wheels delivered.
The emphasis in software engineering is on both words, software and engineering. An
engineer is able to build a high-quality product using off-the-shelf components and integrating
them under time and budget constraints. The engineer is often faced with ill-defined problems
and partial solutions, and has to rely on empirical methods to evaluate solutions. Engineers
working in such application domains as passenger aircraft design and bridge construction have
successfully met similar challenges. Software engineers have not been as successful.
The problem of building and delivering complex software systems on time has been
actively investigated and researched. Everything has been blamed, from the customer (“What do
you mean I can’t get the moon for $50?”) to the “soft” in software (“If I could add that one last
feature ...”) to the youth of this discipline. What is the problem?

Complexity and change

Useful software systems are complex. To remain useful they need to evolve with the end users’
need and the target environment. In this book, we describe object-oriented techniques for
conquering complex and changing software systems. In this chapter, we provide a motivation for
object-oriented techniques and define the basic concepts used throughout this book.

3
4 Chapter 1 • Introduction to Software Engineering

1.1 Introduction: Software Engineering Failures

Consider the following examples [Neumann, 1995]:

Year 1900 bug

In 1992, Mary from Winona, Minnesota, received an invitation to attend a kindergarten. Mary
was 104 at the time.
Leap-year bug
A supermarket was fined $1000 for having meat around 1 day too long, on February 29, 1988.
The computer program printing the expiration date on the meat labels did not take into account
that 1988 was a leap year.
Interface misuse
On April 10, 1990, in London, an underground train left the station without its driver. The driver
had taped the button that started the train, relying on the system that prevented the train from
moving when doors were open. The train operator had left his train to close a door which was
stuck. When the door was finally shut, the train simply left.
Security
CERT (Computer Emergency Response Team) at the Software Engineering Institute is a
government-funded organization for assisting the community in dealing with security incidents,
vulnerabilities, and security know-how. The number of security incidents reported to CERT from
the United States increased from 252 incidents in 1990 to 21,756 in 2000, and more than 40,000
incidents were reported in 2001.
Late and over budget
In 1995, bugs in the automated luggage system of the new Denver International Airport caused
suitcases to be chewed up. The airport opened 16 months late, $3.2 billion over budget, with a
mostly manual luggage system.
Late and over budget (2)
In 2002, the Swanick Air Traffic Control system covers all the enroute air traffic over England
and Wales. The system was delivered substantially over budget (cost £623 million, originally
planned at £350 million) and 6 years late. Two major upgrades of the system were delivered after
training of the traffic controllers had started.
On-time delivery
After 18 months of development, a $200-million system was delivered to a health insurance
company in Wisconsin in 1984. However, the system did not work correctly: $60 million in
overpayments were issued. The system took 3 years to fix.
Unnecessary complexity
The C-17 cargo plane by McDonnell Douglas ran $500 million over budget because of problems
with its avionics software. The C-17 included 19 onboard computers, 80 microprocessors, and 6
different programming languages.
What Is Software Engineering? 5

Each of the failures described above resulted from a software-related problem. In some cases,
developers did not anticipate seldom-occurring situations (a person living more than 100 years,
leap years impacting expiration dates). In other cases, developers did not anticipate the user
actively misusing the system (taping down a button, exploiting security holes in network
software). In yet other cases, system failures resulted from management failures (late and over-
budget delivery, on-time delivery of an incorrect system, unnecessary complexity).
Software systems are complex creations. They perform many functions; they are built to
achieve many different, and often conflicting, objectives. They comprise many components;
many of their components are custom made and complex themselves. Many participants from
different disciplines take part in the development of these components. The development process
and the software life cycle often spans many years. Finally, complex systems are difficult to
understand completely by any single person. Many systems are so hard to understand, even
during their development phase, that they are never finished: these are called vaporware.
Software development projects are subject to constant change. Because requirements are
complex, they need to be updated when errors are discovered and when the developers have a
better understanding of the application. If the project lasts many years, the staff turn-around is
high, requiring constant training. The time between technological changes is often shorter than
the duration of the project. The widespread assumptions of a software project manager that all
changes have been dealt with and that the requirements can be frozen will lead to the
deployment of an irrelevant system.
In the next section, we present a high-level view of software engineering. We describe
software engineering from the perspective of science, engineering, and knowledge acquisition
and formalization. In Section 1.3, we describe in more detail the main terms and concepts we
use in this book. In Section 1.4, we provide an overview of the development activities of
software engineering. In Section 1.5, we provide an overview of the managerial activities of
software engineering.

1.2 What Is Software Engineering?

Software engineering is a modeling activity. Software engineers deal with complexity through
modeling, by focusing at any one time on only the relevant details and ignoring everything else.
In the course of development, software engineers build many different models of the system and
of the application domain.
Software engineering is a problem-solving activity. Models are used to search for an
acceptable solution. This search is driven by experimentation. Software engineers do not have
infinite resources and are constrained by budget and deadlines. Given the lack of a fundamental
theory, they often have to rely on empirical methods to evaluate the benefits of different
alternatives.
Software engineering is a knowledge acquisition activity. In modeling the application and
solution domain, software engineers collect data, organize it into information, and formalize it
6 Chapter 1 • Introduction to Software Engineering

into knowledge. Knowledge acquisition is not sequential, as a single piece of additional data can
invalidate complete models.
Software engineering is a rationale-driven activity. When acquiring knowledge and
making decisions about the system or its application domain, software engineers also need to
capture the context in which decisions were made and the rationale behind these decisions.
Rationale information, represented as a set of issue models, enables software engineers to
understand the implication of a proposed change when revisiting a decision.
In this section, we describe in more detail software engineering from the perspectives of
modeling, problem solving, knowledge acquisition, and rationale. For each of these activities,
software engineers have to work under people, time, and budget constraints. In addition, we
assume that change can occur at any time.

1.2.1 Modeling
The purpose of science is to describe and understand complex systems, such as a system of
atoms, a society of human beings, or a solar system. Traditionally, a distinction is made between
natural sciences and social sciences to distinguish between two major types of systems. The
purpose of natural sciences is to understand nature and its subsystems. Natural sciences include,
for example, biology, chemistry, physics, and paleontology. The purpose of the social sciences is
to understand human beings. Social sciences include psychology and sociology.
There is another type of system that we call an artificial system. Examples of artificial
systems include the space shuttle, airline reservation systems, and stock trading systems. Herbert
Simon coined the term sciences of the artificial to describe the sciences that deal with artificial
systems [Simon, 1970]. Whereas natural and social sciences have been around for centuries, the
sciences of the artificial are recent. Computer science, for example, the science of understanding
computer systems, is a child of the twentieth century.
Many methods that have been successfully applied in the natural sciences and humanities
can be applied to the sciences of the artificial as well. By looking at the other sciences, we can
learn quite a bit. One of the basic methods of science is modeling. A model is an abstract
representation of a system that enables us to answer questions about the system. Models are
useful when dealing with systems that are too large, too small, too complicated, or too expensive
to experience firsthand. Models also allow us to visualize and understand systems that either no
longer exist or that are only claimed to exist.
Fossil biologists unearth a few bones and teeth preserved from some dinosaur that no one
has ever seen. From the bone fragments, they reconstruct a model of the animal, following rules
of anatomy. The more bones they find, the clearer their idea of how the pieces fit together and
the higher the confidence that their model matches the original dinosaur. If they find a sufficient
number of bones, teeth, and claws, they can almost be sure that their model reflects reality
accurately, and they can guess the missing parts. Legs, for example, usually come in pairs. If the
left leg is found, but the right leg is missing, the fossil biologists have a fairly good idea what the
What Is Software Engineering? 7

missing leg should look like and where it fits in the model. This is an example of a model of a
system that no longer exists.
Today’s high-energy physicists are in a position similar to that of a fossil biologist who has
found most of the bones. Physicists are building a model of matter and energy and how they fit
together at the most basic, subatomic level. Many years of experiments with particle accelerators
have given high-energy physicists enough confidence that their models reflect reality and that
the remaining pieces that are not yet found will fit into the so-called standard model. This is an
example of a model for a system that is claimed to exist.
Both system modelers, fossil biologists and high-energy physicists, deal with two types of
entities: the real-world system, observed in terms of a set of phenomena, and the application
domain model, represented as a set of interdependent concepts. The system in the real world is a
dinosaur or subatomic particles. The application domain model is a description of those aspects
of the real-world system that are relevant to the problem under consideration.
Software engineers face similar challenges as fossil biologists and high-energy physicists.
First, software engineers need to understand the environment in which the system has to operate.
For a train traffic control system, software engineers need to know train signaling procedures.
For a stock trading system, software engineers need to know trading rules. The software
engineer does not need to become a fully certified train dispatcher or a stock broker; they only
need to learn the application domain concepts that are relevant to the system. In other terms,
they need to build a model of the application domain.
Second, software engineers need to understand the systems they could build, to evaluate
different solutions and trade-offs. Most systems are too complex to be understood by any one
person, and most systems are expensive to build. To address these challenges, software
engineers describe important aspects of the alternative systems they investigate. In other terms,
they need to build a model of the solution domain.
Object-oriented methods combine the application domain and solution domain modeling
activities into one. The application domain is first modeled as a set of objects and relationships.
This model is then used by the system to represent the real-world concepts it manipulates. A
train traffic control system includes train objects representing the trains it monitors. A stock
trading system includes transaction objects representing the buying and selling of commodities.
Then, solution domain concepts are also modeled as objects. The set of lines used to depict a
train or a financial transaction are objects that are part of the solution domain. The idea of
object-oriented methods is that the solution domain model is a transformation of the application
domain model. Developing software translates into the activities necessary to identify and
describe a system as a set of models that addresses the end user’s problem. We describe in more
detail modeling and the concepts of objects in Chapter 2, Modeling with UML.
8 Chapter 1 • Introduction to Software Engineering

1.2.2 Problem Solving

Engineering is a problem-solving activity. Engineers search for an appropriate solution, often
by trial and error, evaluating alternatives empirically, with limited resources and incomplete
knowledge. In its simplest form, the engineering method includes five steps:

1. Formulate the problem.

2. Analyze the problem.
3. Search for solutions.
4. Decide on the appropriate solution.
5. Specify the solution.

Software engineering is an engineering activity. It is not algorithmic. It requires experi-

mentation, the reuse of pattern solutions, and the incremental evolution of the system toward a
solution that is acceptable to the client.
Object-oriented software development typically includes six development activities:
requirements elicitation, analysis, system design, object design, implementation, and testing.
During requirements elicitation and analysis, software engineers formulate the problem with the
client and build the application domain model. Requirements elicitation and analysis correspond
to steps 1 and 2 of the engineering method. During system design, software engineers analyze
the problem, break it down into smaller pieces, and select general strategies for designing the
system. During object design, they select detail solutions for each piece and decide on the most
appropriate solution. System design and object design result in the solution domain model.
System and object design correspond to steps 3 and 4 of the engineering method. During
implementation, software engineers realize the system by translating the solution domain model
into an executable representation. Implementation corresponds to step 5 of the engineering
method. What makes software engineering different from problem solving in other sciences is
that change occurs in the application and the solution domain while the problem is being solved.
Software development also includes activities whose purpose is to evaluate the
appropriateness of the respective models. During the analysis review, the application domain
model is compared with the client’s reality, which in turn might change as a result of modeling.
During the design review, the solution domain model is evaluated against project goals. During
testing, the system is validated against the solution domain model, which might be changed by
the introduction of new technologies. During project management, managers compare their
model of the development process (i.e., the project schedule and budget) against reality (i.e., the
delivered work products and expended resources).

1.2.3 Knowledge Acquisition

A common mistake that software engineers and managers make is to assume that the acquisition
of knowledge needed to develop a system is linear. This mistake is not made by software
managers alone; it can be found in other areas as well. In the 17th century, a book was published
What Is Software Engineering? 9

that offered to teach all the German poems by pouring them into the student’s head in 6 hours
with a funnel.1 The idea of using a funnel for learning is based on the widespread assumption
that our mind is a bucket that is initially empty and can be filled in a linear fashion. Material
enters through our senses, accumulates, and is digested. Popper calls this linear acquisition
model for knowledge “the bucket theory of the mind.” Among the many other things that are
wrong with this theory (described in [Popper, 1992]) is the assumption that knowledge is
conceived as consisting of things that can fill a bucket; that is, the fuller the bucket, the more we
know.
Knowledge acquisition is a nonlinear process. The addition of a new piece of information
may invalidate all the knowledge we have acquired for the understanding of a system. Even if
we had already documented this understanding in documents and code (“The system is 90%
coded, we will be done next week”), we must be mentally prepared to start from scratch. This
has important implications on the set of activities and their interactions we define to develop the
software system. The equivalent of the bucket theory of the mind is the sequential waterfall
model for software development, in which all steps of the engineering method are accomplished
sequentially.
There are several software processes that deal with this problem by avoiding the sequential
dependencies inherent in the waterfall model. Risk-based development attempts to anticipate
surprises late in a project by identifying the high-risk components. Issue-based development
attempts to remove the linearity altogether. Any development activity—analysis, system design,
object design, implementation, testing, or delivery—can influence any other activity. In issue-
based development, all these activities are executed in parallel. The difficulty with nonsequential
development models, however, is that they are difficult to manage.

1.2.4 Rationale
When describing the acquisition or evolution of knowledge, we are even less well equipped than
when describing the knowledge of an existing system. How does a mathematician derive a
proof? Mathematical textbooks are full of proofs, but rarely provide hints about the proof
derivation. This is because mathematicians do not think this background is important. Once the
axioms and the rules of deduction have been stated, the proof is timeless.
For software engineers, the situation is different. Assumptions that developers make about
a system change constantly. Even though the application domain models eventually stabilize
once developers acquire an adequate understanding of the problem, the solution domain models
are in constant flux. Design and implementation faults discovered during testing and usability
problems discovered during user evaluation trigger changes to the solution models. Changes can
also be caused by new technology. The availability of a long-life battery and of high-bandwidth
wireless communication, for example, can trigger revisions to the concept of a portable terminal.

1. G. P. Harsdoerfer (1607–1658), “Poetischer Trichter, die teutsche Dicht- und Reimkunst, ohn Behuf der lateinischen
Sprache, in 6 Stunden einzugießen,” Nuernberg, 1630.
10 Chapter 1 • Introduction to Software Engineering

Change introduced by new technology often allows the formulation of new functional or
nonfunctional requirements. A typical task of software engineers is to change a currently
operational software system to incorporate this new enabling technology. To change the system,
it is not enough to understand its current components and behavior. It is also necessary to
capture and understand the context in which each design decision was made. This additional
knowledge is called the rationale of the system.
Capturing and accessing the rationale of a system is not trivial. First, for every decision
made, several alternatives may have been considered, evaluated, and argued. Consequently,
rationale represents a much larger amount of information than do the solution models. Second,
rationale information is often not explicit. Developers make many decisions based on their
experience and their intuition, without explicitly evaluating different alternatives. When asked to
explain a decision, developers may have to spend a substantial amount of time recovering its
rationale. In order to deal with changing systems, however, software engineers must address the
challenges of capturing and accessing rationale.

1.3 Software Engineering Concepts

So far, we have presented a high-level view of software engineering from the perspectives of
modeling, problem solving, knowledge acquisition, and rationale. In this section, we describe
the main terms and concepts we use throughout the book.2 A Project, whose purpose is to
develop a software system, is composed of a number of Activities. Each Activity is in turn
composed of a number of Tasks. A Task consumes Resources and produces a WorkProduct. A
WorkProduct can be either a System, a Model, or a Document. Resources are either
Participants, Time, or Equipment. A graphical representation of these concepts is shown in
Figure 1-1. Each rectangle represents a concept. The lines among the rectangles represent
different relationships between the concepts. For example, the diamond shape indicates
aggregation: a Project includes a number of Activities, which includes a number of Tasks.
The triangle shape indicates a generalization relationship; Participants, Time, and Equipment
are specific kinds of Resources. Figure 1-1 is represented in the Unified Modeling Language
(UML) notation. We use UML throughout the book to represent models of software and other
systems. Intuitively, you should be able to understand this diagram without full knowledge of the
UML semantics. Similarly, you can also use UML diagrams when interacting with a client or a
user, even though they may not have any knowledge of UML. We describe the semantics of
these diagrams in detail in Chapter 2, Modeling with UML.

2. As much as possible, we follow the definitions of the IEEE standards on Software Engineering [IEEE Std. 610.12-
1990].
Software Engineering Concepts 11

Project

Activity

is produced by * consumes
* *
WorkProduct Task Resources

System Participant

Model Time

Document Equipment

Figure 1-1 Software engineering concepts depicted as a UML class diagram [OMG, 2009].

1.3.1 Participants and Roles

Developing a software system requires the collaboration of many people with different
backgrounds and interests. The client orders and pays for the system. The developers construct
the system. The project manager plans and budgets the project and coordinates the developers
and the client. The end users are supported by the system. We refer to all the persons involved in
the project as participants. We refer to a set of responsibilities in the project or the system as a
role. A role is associated with a set of tasks and is assigned to a participant. The same
participant can fill multiple roles.
Consider a TicketDistributor system:

TicketDistributor is a machine that distributes tickets for trains. Travelers have the option of
selecting a ticket for a single trip or for multiple trips, or selecting a time card for a day or a week. The
TicketDistributor computes the price of the requested ticket based on the area in which the trip will
take place and whether the traveler is a child or an adult. The TicketDistributor must be able to
handle several exceptions, such as travelers who do not complete the transaction, travelers who attempt
to pay with large bills, and resource outages, such as running out of tickets, change, or power.

Treating the development of this TicketDistributor as a software engineering project,

Table 1-1 provides examples of roles for this example.
12 Chapter 1 • Introduction to Software Engineering

Table 1-1 Examples of roles in software engineering for the TicketDistributor project.

Role Responsibilities Examples

Client The client is responsible for providing the high- Train company that
level requirements on the system and for defining contracts the
the scope of the project (delivery date, budget, TicketDistributor.
quality criteria).

User The user is responsible for providing domain Travelers

knowledge about current user tasks. Note that the
client and the user are usually filled by different
persons.

Manager A manager is responsible for the work Alice (boss)

organization. This includes hiring staff, assigning
them tasks, monitoring their progress, providing
for their training, and generally managing the
resources provided by the client for a successful
delivery.

Human Factors A human factors specialist is responsible for the Zoe (Human Computer
Specialist usability of the system. Interaction specialist)

Developer A developer is responsible for the construction of John (analyst), Marc

the system, including specification, design, (programmer), & Zoe
implementation, and testing. In large projects, the (tester)a
developer role is further specialized.

Technical Writer The technical writer is responsible for the John

documentation delivered to the client. A technical
writer interviews developers, managers, and users
to understand the system.

a. As TicketDistributor is a small project, Zoe fills both the human factor specialist and the tester roles,
and John fills the analyst and the technical writer roles.

1.3.2 Systems and Models

We use the term system as a collection of interconnected parts. Modeling is a way to deal with
complexity by ignoring irrelevant details. We use the term model to refer to any abstraction of
the system. A TicketDistributor for an underground train is a system. Blueprints for the
TicketDistributor, schematics of its electrical wiring, and object models of its software are
models of the TicketDistributor. Note that a development project is itself a system that can be
modeled. The project schedule, its budget, and its planned deadlines are models of the
development project.
Software Engineering Concepts 13

1.3.3 Work Products

A work product is an artifact that is produced during the development, such as a document or a
piece of software for other developers or for the client. We refer to a work product for the
project’s internal consumption as an internal work product. We refer to a work product that
must be delivered to a client as a deliverable. Deliverables are generally defined prior to the
start of the project and specified by a contract binding the developers with the client. Table 1-2
describes examples of work products for the TicketDistributor example.
Table 1-2 Examples of work products for the TicketDistributor project.

Work product Type Description

Specification Deliverable The specification describes the system from the user’s point of
view. It is used as a contractual document between the project
and the client. The TicketDistributor specification
describes in detail how the system should appear to the traveler.

Operation Deliverable The operation manual for the TicketDistributor is used by

manual the staff of the train company responsible for installing and
configuring the TicketDistributor. Such a manual describes,
for example, how to change the price of tickets and the
structure of the network into zones.

Status report Internal work A status report describes at a given time the tasks that have
product been completed and the tasks that are still in progress. The
status report is produced for the manager, Alice, and is usually
not seen by the train company.

Test manual Internal work The test plans and results are produced by the tester, Zoe. These
product documents track the known defects in the prototype
TicketDistributor and their state of repair. These documents
are usually not shared with the client.

1.3.4 Activities, Tasks, and Resources

An activity is a set of tasks that is performed toward a specific purpose. For example,
requirements elicitation is an activity whose purpose is to define with the client what the system
will do. Delivery is an activity whose purpose is to install the system at an operational location.
Management is an activity whose purpose is to monitor and control the project such that it meets
its goals (e.g., deadline, quality, budget). Activities can be composed of other activities. The
delivery activity includes a software installation activity and an operator training activity.
Activities are also sometimes called phases.
14 Chapter 1 • Introduction to Software Engineering

A task represents an atomic unit of work that can be managed: A manager assigns it to a
developer, the developer carries it out, and the manager monitors the progress and completion of
the task. Tasks consume resources, result in work products, and depend on work products
produced by other tasks.
Resources are assets that are used to accomplish work. Resources include time,
equipment, and labor. When planning a project, a manager breaks down the work into tasks and
assigns them to resources.
Table 1-3 describes examples of activities, tasks, and resources in software engineering.
Table 1-3 Examples of activities, tasks, and resources for the TicketDistributor project.

Example Type Description

Requirements elicitation Activity The requirements elicitation activity includes

obtaining and validating requirements and domain
knowledge from the client and the users. The
requirements elicitation activity produces the
specification work product (Table 1-2).

Develop “Out of Change” Task This task, assigned to Zoe (the tester) focuses on
test case for verifying the behavior of the ticket distributor
TicketDistributor when it runs out of money and cannot give the
correct change back to the user. This activity
includes specifying the environment of the test, the
sequence of inputs to be entered, and the expected
outputs.

Review “Access Online Task This task, assigned to John (the human factors
Help” use case for usability specialist) focuses on detecting usability issues in
accessing the online help features of the system.

Tariff Database Resource The tariff database includes an example of tariff

structure with a train network plan. This example
is a resource provided by the client for
requirements and testing.

1.3.5 Functional and Nonfunctional Requirements

Requirements specify a set of features that the system must have. A functional requirement is a
specification of a function that the system must support, whereas a nonfunctional requirement
is a constraint on the operation of the system that is not related directly to a function of the
system.
For example, The user must be able to purchase tickets and The user must be able to
access tariff information are functional requirements. The user must be provided feedback in less
than one second and The colors used in the interface should be consistent with the company
Software Engineering Concepts 15

colors are nonfunctional requirements. Other nonfunctional requirements may include using
specific hardware platform for the system, security requirements, how the system should deal
with failures and faults, and how to provide backward compatibility with an old system that the
client is unwilling to retire.

1.3.6 Notations, Methods, and Methodologies

A notation is a graphical or textual set of rules for representing a model. The Roman alphabet is
a notation for representing words. UML (Unified Modeling Language [OMG, 2009]), the
notation we use throughout this book, is a notation for representing object-oriented models. The
use of notations in software engineering is common and predates object-oriented concepts. Data
flow diagrams [De Marco, 1978] is a notation for representing systems in terms of data sources,
data sinks, and data transformations. Z [Spivey, 1989] is a notation for representing systems
based on set theory.
A method is a repeatable technique that specifies the steps involved in solving a specific
problem. A recipe is a method for cooking a specific dish. A sorting algorithm is a method for
ordering elements of a list. Rationale management is a method for justifying change.
Configuration management is a method for tracking change.
A methodology is a collection of methods for solving a class of problems and specifies
how and when each method should be used. A seafood cookbook with a collection of recipes is
a methodology for preparing seafood if it also contains advice on how ingredients should be
used and what to do if not all ingredients are available. Royce’s methodology [Royce, 1998], the
Object Modeling Technique (OMT [Rumbaugh et al., 1991]), the Booch methodology [Booch,
1994], and Catalysis [D’Souza & Wills, 1999] are object-oriented methodologies for developing
software.
Software development methodologies decompose the process into activities. OMT
provides methods for three activities: Analysis, which focuses on formalizing the system
requirements into an object model, System Design, which focuses on strategic decisions, and
Object Design, which transforms the analysis model into an object model that can be
implemented. The OMT methodology assumes that requirements have already been defined and
does not provide methods for eliciting requirements. The Unified Software Development
Process also includes an Analysis activity and treats System Design and Object Design as a
single activity called Design. The Unified Process, unlike OMT, includes a Requirements
Capture activity for eliciting and modeling requirements. Catalysis, while using the same
notations as the Unified Process, focuses more on reuse of design and code using patterns and
frameworks. All of these methodologies focus on dealing with complex systems.
In this book, we present a methodology for developing complex and changing systems.
During the course of our teaching and research ([Bruegge, 1992], [Bruegge & Coyne, 1993],
[Bruegge & Coyne, 1994], [Coyne et al., 1995]), we have adapted and refined methods from a
variety of sources. For activities modeling the application domain, such as requirements
elicitation and analysis, we describe methods similar to those of OOSE [Jacobson et al., 1992].
 Another Random Document on
Scribd Without Any Related Topics
fellow doubtless intends to use them, and will, if he isn’t prevented
at once, they will bring anguish to a great many people. Finally, the
fact that they have fallen into unscrupulous hands will work me more
harm than anything else could possibly do.”
His anger against Griswold had cooled while he was speaking,
however.
“But, fortunately,” he went on in a calmer tone. “We have every
reason to believe that your gold is in the same hands as my papers;
therefore, the trail isn’t likely to fork.”
“That’s it,” Griswold agreed eagerly. “I beg your pardon again,
Carter. I didn’t realize what this loss meant to you and others. It
gives you a supreme incentive, however, to go after the fellow.”
Before he could add more, the desk phone rang, and Chick
answered it.
“Yes, this is Mr. Carter’s house,” the young detective said. “You
are speaking from Mr. Griswold’s office? Yes, Mr. Griswold is here. Do
you wish to speak to him?... All right, I understand. I’ll tell him at
once. Good-by.”
The receiver clicked back into its place, and Chick turned to the
expectant listeners.
“They say that the doctor has phoned from Simpson’s house, at
New Pelham, Mr. Griswold,” he said. “Cray is conscious at last.”
“Good!” ejaculated Nick. “You and I will go there at once, Chick.
How about you, Mr. Griswold? Will you come along?”
“Certainly,” was the prompt answer.
 CHAPTER XXXIX.
CRAY’S LIPS ARE UNSEALED.

Despite his eagerness to see his friend Cray, and to get on the
fugitive’s trail, Nick remained at the house long enough to draft a
telegram to the warden of Clinton Prison, asking for further details
concerning the supposed death of Green-eye Gordon, and the
escape of one of the prisoners on the night of the fire.
The message was given to the butler, who was asked to phone it
at once to the telegraph office.
“They may have facts up there which they have been keeping
from the public,” Nick explained. “Even seemingly valueless facts
may assume great importance in the light of what has happened
down here, for that matter.”
Meanwhile, one of Nick’s fastest cars had been ordered around,
and now the familiar honk-honk was heard.
“There’s the machine,” Nick announced. “Come on.”
It was plain to be seen that both Nick and his assistant were
laboring under unusual excitement. The chauffeur was instructed to
push the car to the lawful limit, and although he did so, with his
usual skill, the detective seemed to think the car was creeping.
For miles and miles they had to traverse the streets of the city
which stretched out northward to the confines of the Bronx, and not
until these were passed, did they feel free to risk a faster pace—and
even then they had to slow down through the frequent villages.
It was not in reality a long drive, however, and in less time than
Griswold had made the trip the morning before, they had covered
the distance.
 The chauffeur had slowed down considerably before entering the
village of New Pelham, but they were still going at a rapid rate, and
Griswold was obliged to raise his voice for his final instructions to the
chauffeur.
“The top of the hill!” he called out, leaning forward and pointing,
while he held his hat on with the other hand.
The usually easy-going millionaire was having some unusual
experiences, and had been pretty thoroughly shaken up in more
ways than one.
Straight up the hill that led from the heart of the village, the
great car raced, and Griswold added that it was the last house. A
few moments later the machine came to an abrupt, but quiet, stop
in front of No. 31 Floral Avenue.
Quickly the three men alighted and hurried through the gate. The
door was opened almost immediately by the maid, and behind her
stood Doctor Lord, who had evidently been impatiently awaiting
Griswold’s arrival.
The doctor looked inquiringly at the others.
“Carter, shake hands with Doctor Lord,” he said informally.
“Doctor, this is Nick Carter and this is Chick Carter, his assistant.”
“I’m very glad,” the young physician said heartily, as he
acknowledged the detective’s greeting. “Frequently during the
patient’s long stupor, Mr. Carter, he mumbled your name.”
“Just how is he?” Nick asked eagerly, and, for the moment,
concern for his friend weighed with him more than anything else.
“He’s better,” was the reply. “He has taken the turn that I hoped
for, and now, although he may be laid up for some time, I think I
may safely say that the danger is over. You must not see him for
long, however, and you had better come at once. I’ve been afraid
that he might lapse into unconsciousness again before Mr. Griswold
could get here.”
“You have questioned him as I suggested?” the millionaire put in,
as they moved toward the door of the room in which Cray was lying.
 “Yes,” was the answer, “but he’s stubborn. He refuses to tell me
anything—said he would do so if he felt himself losing consciousness
again, but that he wanted to say what he had to say directly to Mr.
Griswold, if possible.”
They had reached the door of the room by that time, and Lord
stepped aside to allow the others to enter.
A nurse in a trim, crisp uniform was sitting beside the couch, but
rose and effaced herself quietly, thus giving Nick his first
unobstructed view of his friend.
The burly detective seemed to fill the narrow couch, and yet he
appeared, somehow, shrunken. His face was still very pale, and the
big, hairy hand that lay on his chest had a suggestion of
helplessness about it.
Cray turned his head slowly, and looked toward the door. Instead
of seeing merely the millionaire, as he had anticipated, he beheld
two other visitors, and identified them after a moment or two.
“Mr. Carter!” he exclaimed weakly. “And Chick, too! Is it really you
this time, Carter? This is more than I hoped for.”
He tried to raise himself on one elbow, but sank back faintly.
“Lie still, old fellow!” Nick said, quietly stepping forward and
taking Cray’s hand. “You are gaining, and must hold on to what you
have gained. Take your time, though, about——”
“I can’t take my time, Carter,” Cray said, feverishly clutching at
his friend’s hand with both of his. “This isn’t the worst yet. It was
Gordon—Green-eye Gordon—who did this to me, and he’s made off
with two suit cases crammed full of gold coins.”
Nick saw that it would be necessary to cut the interview short,
but he wished to test Cray, if possible. It might be that Jack had
forgotten about the fire and the reports of Gordon’s death. If he
were reminded of that, he might not be so sure about the identity of
his assailant.
“But Gordon is dead, you know—burned to death in prison,” Nick
said quietly.
 “No, no! Don’t you believe it, Carter!” the patient insisted.
“There’s no mistake about it. I forgot about all those reports when
he struck me; they don’t cut any ice. I have thought about them
since I woke up, and I’m just as sure as ever that it was Gordon.”
“What makes you so sure?” inquired Nick.
“He forgot himself when he cursed me,” was the reply, “and I
thought I recognized the voice; then I caught a glimpse of his eyes,
and I was sure. There’s only one man with eyes like that—cat’s eyes.
They looked green as he glared at me. He knows I recognized him,
because I said his name just before I got my knock-out. Probably he
thought he had killed me, for I don’t believe he would have left me
to tell the tale.”
He paused for a moment, and one hand wandered weakly to his
injured head.
“I’ll never get over the way I was taken in,” he went on, more
faintly. “Most humiliating. Must say, he’s a wonder, though. Never
imagined anybody could pull off a stunt like that. The car is an
electric—a coupé, two or three years old, I should say. The gold was
in a couple of suit cases which had been buried in the ground. Can’t
tell you any more, I’m afraid—just about all in, you see.”
He looked about helplessly, and in a frightened sort of way, then,
with a sigh, lapsed into unconsciousness once more.
 CHAPTER XL.
NICK OUTLINES HIS CAMPAIGN.

In a moment Doctor Lord and the nurse were back at the

patient’s side.
“I must ask you gentlemen to go,” the physician said crisply.
“This has been too much for him, as it is, and any further excitement
might cause serious complications, if nothing worse.”
There was nothing for it but to withdraw, and to hope that the
effect of the interview would not be as serious as the doctor
suggested.
Fortunately, the detective instinct had been strong in Cray,
notwithstanding his condition, and he had covered the ground pretty
thoroughly—surprisingly so, in view of the few words he had spoken.
His statement about the suit case, and his description of the car
might prove particularly valuable.
Nick took pains to interview Simpson, his wife, and the servant
before leaving the house and then paid a visit to the garage.
He smiled as he noted the subterfuge of the underground
gasoline tank.
“Quite clever, on the surface,” he remarked, “but Simpson seems
to be a queer mixture. He impresses you at one time with his
cleverness, at another with stupidity.”
“I don’t see anything stupid about this,” Griswold objected. “It
strikes me as very ingenious. It permitted him to dig up the ground
to his heart’s content without arousing suspicion.”
“True,” conceded the detective. “The ordinary person would have
seen nothing strange about it; but doesn’t the presence of a
gasoline tank underground, or any other kind, strike you as a little
peculiar when a man owns an electric?”
The millionaire looked very sheepish. “I’m afraid I must plead
guilty to stupidity as well,” he confessed. “That didn’t occur to me,
and I doubt if it ever would.”
The two detectives made a thorough examination of the little
garage, the ground about it, and the pile of lumber, as well as the
road at the rear.
They found some finger prints, and photographed them carefully,
after bringing out other details by artificial means. They were
inclined to believe that some of them belonged to Gordon, and if so,
their discovery would prove valuable. Beyond that, however, they
learned little.
“Well, we had better part company here, Chick,” Nick told his
assistant. “I’m going to let you pick up the trail of the electric car
and follow it, if you can. See if you can locate the machine. Probably
it has been abandoned long before this, for it would have to be
recharged before it could go very far. Doubtless, Green Eye
remembered that, and deserted it before such attention was
necessary. Still, if you can find where he dispensed with it, you can
get a clew to his subsequent movements, especially as he was
burdened with a couple of very heavy suit cases.”
“Consider me on the job,” was Chick’s ready reply. “I’ll start work
right away, and keep going as long as the going is good. How about
you, though? What are you going to tackle?”
“I shall return home at once,” Nick replied, “and go through the
safe. I must find out which records are missing, and when I have
learned that, I ought to be able to catch the rascal sooner or later.”
“You mean that he’ll be sure to visit some of the people
interested, or write to them, and that you can nab him in that way?”
his assistant asked.
“That’s the idea. If Green Eye hasn’t learned of our return—and I
sincerely hope he hasn’t—he won’t lose much time in getting to
work at the blackmailing business, and you may be sure he’ll choose
some of the most tempting of the local people for his first victims.”
Chick held up his hand. “I get you,” he said. “That’s just what will
happen, unless he’s scared off, and he’ll work quickly, for fear you
may return earlier than you had expected, and get wind of the
whole thing. Alongside of that, my job seems pretty punk, but you’re
the general.”
“Your job is a necessary one, and we may need all the dope on
Green Eye’s movements that we can get,” Nick told him.
Very shortly afterward they separated, Chick remaining behind,
while Nick and the millionaire reëntered the car and started back to
the city.
Very little was said on the journey. To be sure, Griswold seemed
willing enough to keep the conversational ball rolling, but he soon
found that Nick was of a different mind. He was glad, therefore,
when the detective’s house was reached, and Nick stepped out of
the machine, after instructing the chauffeur to take Griswold
wherever he wished to go.
“You think you can catch him, then?” the millionaire asked in
parting.
Nick gave him a strange look. “If I fail in this, I’ll shut up shop,”
he replied.
It was said rather lightly, but Griswold was a shrewd student of
character, and knew that famous Nemesis of criminals was in deadly
earnest.
 CHAPTER XLI.
WAITING FOR A NIBBLE.

Nick Carter hardly knew what to do about the members of his

household. They had not yet been informed of the way in which they
had been taken in, and it was difficult to decide whether they should
be or not. After some reflection, however, the detective decided to
say nothing about it, for the present.
They accepted his presence as a matter of course, just as they
had done in the case of the impostor, and if he told them the truth,
they would be plunged into a state bordering on panic.
Moreover, if Gordon should take a notion to return to the house,
after such a revelation, it would be almost impossible for the butler,
housekeeper, and the rest to be their natural selves in his presence.
If they betrayed their knowledge, they might scare him off just when
Nick wished him to be most at his ease.
Nick entered his study, and, after walking up and down for a few
minutes, seated himself in his desk chair.
There was a tenseness about his look and every movement he
made. He was like a perfectly trained athlete, crouched for a start of
some record-breaking dash.
The famous detective was well acquainted with danger, and to
risk his life was an easy matter of everyday occurrence. He took up
the most serious and dangerous cases without a thought of the
possible consequences to himself. Here, however, was something
different.
This came nearer home, perhaps, than anything else had ever
done, for, through him the honor and peace of mind of numbers of
persons—conspicuous targets, all of them—were threatened.
Too late the detective recognized that his reputation was not
enough to protect his house and his private safe from violence, and
that he had no right to keep such records there. They should all be
in a safe-deposit vault.
The reports of his ordinary cases might continue to be kept in his
steel filing cabinets, where they were available for ready reference,
but those concerning persons of wealth and position—men and
women who were tempting prey, and whose secrets, if revealed in
the newspapers, would cause a widespread sensation—must be
better protected in future.
That, however, would not help the present situation which Nick
was now forced to face.
He actually shrank from going over the disarranged papers which
Green Eye had left behind, but after a little delay he forced himself
to open the safe, empty the remaining pigeonholes, et cetera, and
dump their contents on the desk. That done, he sat himself down
and went to work.
Fortunately, there was a comparatively small number of papers of
that description in the safe, therefore it did not take very long to go
through them and check off those which remained—for the
methodical detective had a list of all of them.
In this way, by a process of elimination, Nick quickly learned the
ones which had been stolen, and his expression grew grimmer than
ever as he realized the shrewdness of Gordon’s choice.
Most of the missing papers concerned individuals or families in
and around New York, which seemed to imply that a quick clean-up
was contemplated. Some few, though, involved persons farther
away, and these appeared to have been selected because they had
offered particularly tempting bait to the blackmailer.
It needed only the brief entries in the index to bring back to
Nick’s mind all of the important details of each case, and he ground
his teeth as he pictured the scoundrel gloating over those same
details, and cleverly scheming to demand the top price for their
suppression.
“What a haul!” he murmured aloud. “All those papers, and
seventy-five or eighty thousand in gold, to boot! If it’s really Ernest
Gordon with whom we have to deal—and I’m morally certain it is—
he must be drunk with joy, for he has made blackmailing an art, and
he could not ask anything bigger or more promising of that sort. In
his calmer moments, though, he must realize that he won’t have the
chance to hold up many of these people.
“Doesn’t he know that the first man he approaches will in all
probability come running to me to demand an explanation, if nothing
more? And hasn’t it occurred to him that I would receive an urgent
summons home under such circumstances? Well, if it has, he’ll see
all the more reason for striking while the iron is hot.”
He had put the papers away temporarily, intending to find a safer
place for them at the earliest opportunity, when the butler entered
the study with a telegram. It proved to be from the warden at
Clinton prison, and was a long one—sent “collect,” of course.
It contained certain new and significant, though minor, details
concerning the supposed death of Green-eye Gordon, and the
escape of the yegg from Buffalo, which served to confirm Nick’s
suspicions, but the most striking thing about the message was the
tone of it. It gave the impression that the warden had been doubtful,
or was doubtful now concerning the identity of the man who had
been burned. He did not say so, of course, but Nick could read
doubt between the lines.
Obviously, the identification had been a very careless one, or else
the prison authorities had deliberately winked at the misleading
statement which had found their way into the newspapers. Very
likely they took it for granted at first that the partially burned body
was that of Gordon, and afterward preferred to hush the thing up
rather than let it be known that there was any reason to believe that
the redoubtable Green Eye had escaped.
 “Well, that settles it, I think, for all practical purposes,” the
detective told himself. “Cray’s identification was a very hasty one,
made under very unfavorable circumstances, but when it’s taken in
connection with this transparent telegram, and especially in
connection with the nature, daring, and adroitness of the crime
itself, it seems safe enough to conclude that Ernest Gordon is the
man I must look for—and find.”
Which would be the best course, though? To warn those who
might be expected to be approached by the criminal, or to wait until
they came to the detective?
After some thought, Nick decided on the latter course. Naturally,
he did not wish that every one concerned should know what had
happened, for that seemed unnecessary. He believed that Gordon
would concentrate on a few intended victims at first, and if the
detective could discover who those persons were, he ought to be
able to trap the rascal without allowing the others to know what had
threatened them.
It was his confident belief that practically every one who might
be visited or written to by the blackmailer would try to get in touch
with him—Nick Carter—at once. That made him willing to play this
waiting game—at least, for a time.
“The first one who communicates with me,” he thought, “should
give me a line on the fellow’s methods and plans. No one is likely to
yield to his demands on the spot, and if I can learn of a proposed
rendezvous or two, the rest should be fairly plain sailing—unless the
scoundrel learns of my return and plays dead for a while.”
He had reached this point in his musings when he heard a furious
ring at the doorbell.
“Possibly that’s the first of the victims now,” he thought. “If it is, I
must prepare myself for some more or less well-grounded
reproaches. I can stand them, though, if in addition I’m put on the
track of the man I want to lay my hands on more than I ever wanted
to lay them on any one else.”
 CHAPTER XLII.
THE FIRST VICTIM.

Shortly afterward the butler knocked at the study door and

opened it.
“Mr. Chester J. Gillespie to see you, sir,” he announced.
Before Nick could reply, or the butler could get out of the way, for
that matter, the young man named pushed into the room, his face
pale with agitation.
“You must help me, Mr. Carter!” he cried excitedly. “I——”
He paused as Nick motioned the butler to withdraw and close the
door. When the servant had complied, Nick said quietly:
“Sit down, Mr. Gillespie. I’m very sorry to learn that some one
has attempted to blackmail you, but there’s no necessity for such
great haste.”
His caller had started to take a chair, but paused with his hand on
the back of it, and stared at Nick in the greatest amazement.
Presently, a spot of angry red appeared in each pale cheek, and his
rather weak jaw thrust out aggressively.
“By Heaven!” he breathed. “I believe you are in league with the
fellow. I’ll swear I do! How otherwise could you know that——”
“That will be about enough of that, Gillespie!” the detective said
sternly. He had heard too many such accusations in the last few
hours. “If you have come to me for help, as your rather abrupt
opening words would seem to indicate, let me warn you that you are
not furthering your case by insulting me.”
“I—I beg your pardon, Mr. Carter,” the bewildered young man
stammered. “I didn’t mean it, of course, but you are positively
uncanny, and I could not understand how——”
“It’s very simple, though,” Nick told him. “I’ve been robbed of
some papers, unfortunately, and those dealing with your case are
among them. Naturally, therefore, when you rushed in in that
fashion, I concluded that the thief had tried to bleed you.”
“Oh! So that was it?” Gillespie murmured somewhat sheepishly.
Again his anger and sense of injury got the upper hand. “Then it’s
you I have to thank for this, after all!” he cried. “I supposed my
secret safe with you, as safe as if it were buried with me. Now, you
calmly announce that it has been stolen from you. This is too much,
Carter! Can’t you keep your papers where they will be safe? What
right have you got to preserve such records, anyway? Why don’t you
destroy them for the sake of your clients? It’s unbearable! This will
be the ruin of me! If Florence finds out about it, she will refuse to
marry me, and——”
The detective held up his hand commandingly, and the young
man—he did not appear to be over twenty-five—lapsed into silence.
“I have already told you, Gillespie, that I profoundly regret what
has happened. You are forgetting yourself, though, and wasting
time. I already know who made away with those papers, and, with
your assistance, I hope to lay a trap for him that will bring his
schemes to an end very quickly. I think I can promise you that there
will be no publicity, and that nothing need interfere with your
approaching marriage. Now, tell me precisely what has happened.”
Young Gillespie was several times a millionaire, having inherited a
large fortune from his father a year or two before. The responsibility
thus imposed upon him had sobered him down in a remarkable
manner, and he was looked upon in certain quarters as one of the
coming leaders in the financial world. Before his father’s death,
however, he had sown a lot of wild oats of one sort or another, and
it was in connection with one of these youthful escapades that Nick
had been called in about four years previously.
The affair threatened to be very serious, for the time, but the
detective’s skill had been brought to bear in a surprising manner,
with the result that everything had been smoothed out as well as
possible without the vaguest rumor having got abroad.
The young man fumbled in his pocket with a gloved hand, and
produced a sheet of notepaper, the top of which had obviously been
cut away.
“That was found under the door when the house was opened up
this morning,” he said. “Here’s the envelope. It was not stamped, of
course.”
Nick smoothed out the sheet of paper and looked at the
sprawling, uncertain writing that covered it. He read:
“I know all about the affair of four years ago. My price for silence
is one hundred thousand dollars. Have it ready when I call, or pay it
to any one who may present an order from me. Don’t think you can
stop this by trying to have me arrested. You will fail, and the whole
story will come out. I have fully arranged for its publication, no
matter what happens to me. The money is the only thing that will
buy my silence. Pay it, and your secret is safe. What is more, you
will never hear from me again. Refuse to pay it, and—ruin!”
It was a bold letter, but Nick saw that it was nothing but a bluff.
He said as much.
“I hope you haven’t been deceived by this,” he remarked, tapping
the sheet. “This fellow is working alone, you may be sure, and,
therefore, it isn’t at all likely that he has ‘arranged’ anything of the
sort in case he should be arrested. By this, as you ought to know,
the newspapers would not publish a story about you without
warning. You have too much money and too many friends. You
would have an opportunity to bring your influence to bear, and the
story would be killed.”
“That sounds plausible enough,” Gillespie admitted. “That’s what
I would tell any one else in my position, if he were similarly
threatened. When this sort of thing comes home to a fellow, though,
it makes a lot of difference.”
“I know,” the detective replied, with a nod. “That’s the sort of
mood such a scoundrel counts on.”
 He paused and thoughtfully fingered the letter.
“I must confess that this is a disappointment,” he resumed
slowly. “I had hoped that the blackmailer would set a definite time
for his call, or ask you to take the money to some specified place.
This, however, avoids anything of that sort, and leaves me nothing
definite to go on. All it tells us is that he expects to call at some
unnamed hour—perhaps to-day, perhaps to-morrow, perhaps not for
several days. I think we need not bother about the hint that he may
send some one with a written order, for if such a person presented
himself, I feel sure it would be the blackmailer, and no other. This
absence of details, however, makes it rather difficult to know just
what to do.”
“How would this do?” Gillespie said hesitatingly. “You are a
genius at make-up. Why don’t you pass yourself off for me? Go to
my place on Fifth Avenue and wait for this fellow, whoever he is, to
call? The chances are that he won’t put it off very long, and even if
you had to remain there a couple of days, you would not mind,
would you, if you could nab your man at the end of your wait?”
 CHAPTER XLIII.
AN ASTOUNDING RUSE.

Gillespie went on more confidently: “It ought to give him the

shock of his life to think he’s dealing merely with me, and then to
have you reveal yourself to him. Of course, we could both stay
there, and you could walk in and collar him while he was holding me
up, but I’m afraid he may be watching the house. In that case, he
would be suspicious if he saw any one else going in and not coming
out again, no matter whether he recognized you or not.”
Nick smiled slightly. “You must have been reading detective
stories lately, Gillespie,” he commented. “However, it isn’t a bad idea,
and I’m inclined to try it. There are certain other advantages about it
which make it appeal to me. How about you, though? You would
have to remain here as long as I found it necessary to stay at your
place.”
“Oh, that’s all right. I don’t mind. I’ll promise to keep out of
sight, and if I have to stay overnight, I suppose I can find a bunk
somewhere, if you’ll explain my presence to your servants.”
“You certainly can,” Nick assured him; “and let’s hope that you
won’t have to kick your heels here very long.”
The detective conducted him into another room, and, seating him
in the light, proceeded to busy himself with his make-up materials
and appliances. At the end of half an hour, the transformation was
complete.
“Will this do?” asked Nick, turning from the glass and facing his
visitor.
 “By Jove, marvelous!” Gillespie cried enthusiastically. “By the time
you’ve got into my clothes, you’ll be able to pass for me anywhere.
Luckily, there’s only my old butler, Simms, and his wife, at the house,
as I’ve been abroad, and was not expected home as yet. The
chauffeur outside is a new man, and has never seen me before.”
“Good!” Nick answered. “Now for the clothes.”
Soon the disguise was complete, and after another careful
inspection of himself, Nick was ready to leave.
“I’ll explain matters to my people here as I go out,” he said.
“Come this way and I’ll show you the room you may occupy in my
absence. I hope you’ll find it comfortable. Don’t hesitate to ask for
anything you want, and I’ll let you know as soon as there’s anything
to report.”
After conducting his guest to one of the spare bedrooms, the
detective parted with Gillespie, and ascended the stairs. Five
minutes later he stepped into the waiting car as if he owned it.
“Home!” he ordered, and the machine whirled away in the
direction of upper Fifth Avenue.
Meanwhile, from behind one of the curtains at the front of the
detective’s house, the young man had seen the car drive off, and as
it passed out of sight, a remarkable change came over him. He
threw back his head and laughed in a curiously noiseless way that
many an ex-convict has.
He laughed until the tears rolled down his cheeks, and at last
flung himself into a chair and fairly panted for breath. At length, he
recovered himself and wiped his eyes. Simultaneously, his face took
on harsher lines.
The fresh complexion of youth seemed singularly out of place
now, for age and experience—and evil—peered through the veneer.
Had there ever been any doubt about Green-eye Gordon’s daring,
there could be none any longer, for this was the criminal himself.
In some manner best known to himself, he had managed to learn
of Nick’s return, and had taken this extraordinary means of fooling
the detective—an example of supreme audacity, in which he was
manifestly taking the greatest delight.
He expected to kill more than two birds with the one stone.
“Oh, what a sell!” he thought. “How are the mighty fallen! You
don’t happen to know, my dear Carter, that the real Chester Gillespie
is still abroad, and that while you are waiting for your bird in that
gloomy old mansion across from the park, your enterprising little
friend Ernest will be tapping the various other sources of income as
rapidly as he can.”
Nevertheless, when the first flush of triumph had passed, there
seemed to be an undercurrent of uneasiness in the scoundrel’s mood
and manner. Doubtless, he knew that in boldness lay his only hope,
but perhaps he allowed himself to fear for the time being, that even
boldness would be insufficient in the long run against such an
antagonist.
Apparently, the great detective had been completely taken in by
this latest astounding ruse, but very likely Gordon realized that he
was in the lion’s mouth, and that there was no knowing when the
jaws might close with a snap.
Some time after Green Eye returned to Nick’s study, the door
opened, and Chick entered. He did not look any too well satisfied
with his work thus far.
“I beg your pardon,” he said, halting at sight of the supposed
Gillespie. “I didn’t know any one was here. Are you alone?”
“Yes,” Gordon answered coolly. “Mr. Carter has gone out. I think
he left word for you with the butler, but I might as well explain that
he’s absent on an errand for me, and that I’m to remain in more or
less close confinement here until he returns.”
And in response to a look of surprise on Chick’s face, he
explained a little further: “If you wish to call him up——”
“No, not now,” Nick’s assistant interrupted quietly. “I have
nothing to report as yet.”
 That was good news to Gordon, for he felt sure that Chick had
been trying to pick up some clew to the whereabouts of the electric
car, and if so, it was plain that he had failed to make any headway.
“Well, I’ll leave you in possession here and go into the room Mr.
Carter placed at my command,” Green Eye remarked easily, rising to
his feet and helping himself to another of Nick’s cigars. “If there’s no
objection, I shall appropriate some writing materials.”
Chick supplied him with paper, envelopes, et cetera, and assured
him that the study was his to use if he wished, but the visitor would
not consent to “be in the way.” Three minutes later, he was in the
bedroom, with the door closed.
Quickly he removed the tapestry cover and droplight from the
small table between the windows, and, drawing up a chair, set to
work.
It was clear that his desire to write some letters was genuine
enough, and the fact that he cut the engraved headings from several
sheets of paper suggested that the privacy of the room was
welcome.
At the end of an hour he was still writing, and beside him were
several sealed and stamped envelopes addressed to a number of
well-known names. The campaign was going forward.
“I shall have to find some means of getting rid of this man Chick
Carter, though,” Green Eye told himself, as he finished one of the
letters and leaned back in a chair. “These fellows I have written to
will come flocking here before long, and I must be Nick Carter again,
in order to receive them properly.”
 CHAPTER XLIV.
NICK’S SUSPICIONS CONFIRMED.

If the criminal could have read Nick Carter’s mind about that
time, he would have been still more uneasy—and with good reason.
Ernest Gordon had not been the only one who had played a part
during the interview which had ended in the detective’s act of
copying his caller’s features, and borrowing his clothes.
For the first few minutes, it must be confessed that the detective
was completely deceived. He knew Green Eye to be a master of
surprises, but it had not occurred to him to suspect that the clever
rascal would resort to anything so spectacular.
Besides, Gordon had placed himself so that the light did not fall
strongly.
It was not until the caller suggested a change of identities that
the detective began to question. It was very seldom that a client
presumed to offer such assistance, and Nick’s knowledge of Chester
Gillespie had not prepared him for such a proposition. He gave no
evidence, however, that the seed of suspicion had been planted, but
fell in with the suggestion, knowing that in carrying it out, he would
have the best possible opportunity of studying his visitor.
He noted a slight hesitation on the latter’s part when he had
asked him to take his place in the brightest light obtainable, and the
subsequent scrutiny had soon confirmed his suspicions. “Gillespie”
was plainly Ernest Gordon.
No make-up could have stood that test—at least, with Nick Carter
at the observer’s end.
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookball.com