Visit https://ebookfinal.

com to download the full version and

explore more ebooks

Object oriented software engineering using UML

Patterns and Java 3rd, intern. Edition Bruegge

_____ Click the link below to download _____

https://ebookfinal.com/download/object-oriented-
software-engineering-using-uml-patterns-and-java-3rd-
intern-edition-bruegge/

Explore and download more ebooks at ebookfinal.com

Here are some suggested products you might be interested in.
Click the link to download

Object Oriented Software Engineering Practical Software

Development using UML and Java Second Edition Timothy
Lethbridge
https://ebookfinal.com/download/object-oriented-software-engineering-
practical-software-development-using-uml-and-java-second-edition-
timothy-lethbridge/

Object Oriented Programming using Java 1st edition Edition

Kendal S.

https://ebookfinal.com/download/object-oriented-programming-using-
java-1st-edition-edition-kendal-s/

Object oriented and Classical Software Engineering 7th

Edition Stephen R. Schach

https://ebookfinal.com/download/object-oriented-and-classical-
software-engineering-7th-edition-stephen-r-schach/

Head First Design Patterns Building Extensible and

Maintainable Object Oriented Software 2nd Edition Eric
Freeman
https://ebookfinal.com/download/head-first-design-patterns-building-
extensible-and-maintainable-object-oriented-software-2nd-edition-eric-
freeman/
Practical Object Oriented Design with UML 2nd Edition Mark
Priestley

https://ebookfinal.com/download/practical-object-oriented-design-with-
uml-2nd-edition-mark-priestley/

Object oriented reengineering patterns 1st Edition Serge

Demeyer

https://ebookfinal.com/download/object-oriented-reengineering-
patterns-1st-edition-serge-demeyer/

Object Oriented Programming and Java Second Edition Danny

Poo

https://ebookfinal.com/download/object-oriented-programming-and-java-
second-edition-danny-poo/

Object oriented Design in Java 1st Edition Stephen Gilbert

https://ebookfinal.com/download/object-oriented-design-in-java-1st-
edition-stephen-gilbert/

Object oriented JavaScript 3rd Edition Ved Antani

https://ebookfinal.com/download/object-oriented-javascript-3rd-
edition-ved-antani/
Object oriented software engineering using UML
Patterns and Java 3rd, intern. Edition Bruegge Digital
Instant Download
Author(s): Bruegge, Bernd; Dutoit, Allen H.
ISBN(s): 9781292024011, 1292024011
Edition: 3rd, intern.
File Details: PDF, 4.83 MB
Year: 2014
Language: english
 Object-Oriented Software Engineering
Object-Oriented Software Engineering
Using UML, Patterns, and Java
Bernd Bruegge Allen H. Dutoit
Third Edition

Bruegge Dutoit
3e
ISBN 978-1-29202-401-1

9 781292 024011
Object-Oriented Software Engineering
Using UML, Patterns, and Java
Bernd Bruegge Allen H. Dutoit
Third Edition
Pearson Education Limited
Edinburgh Gate
Harlow
Essex CM20 2JE
England and Associated Companies throughout the world

Visit us on the World Wide Web at: www.pearsoned.co.uk

© Pearson Education Limited 2014

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted
in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without either the
prior written permission of the publisher or a licence permitting restricted copying in the United Kingdom
issued by the Copyright Licensing Agency Ltd, Saffron House, 6–10 Kirby Street, London EC1N 8TS.

All trademarks used herein are the property of their respective owners. The use of any trademark
in this text does not vest in the author or publisher any trademark ownership rights in such
trademarks, nor does the use of such trademarks imply any affiliation with or endorsement of this
book by such owners.

ISBN 10: 1-292-02401-1

ISBN 13: 978-1-292-02401-1

British Library Cataloguing-in-Publication Data

A catalogue record for this book is available from the British Library

Printed in the United States of America

 P E A R S O N C U S T O M L I B R A R Y

Table of Contents

Chapter 1. Introduction to Software Engineering

Bernd Bruegge/Allen H. Dutoit 1
Chapter 2. Modeling with UML
Bernd Bruegge/Allen H. Dutoit 27
Chapter 3. Project Organization and Communication
Bernd Bruegge/Allen H. Dutoit 73
Chapter 4. Requirements Elicitation
Bernd Bruegge/Allen H. Dutoit 115
Chapter 5. Analysis
Bernd Bruegge/Allen H. Dutoit 167
Chapter 6. System Design: Decomposing the System
Bernd Bruegge/Allen H. Dutoit 217
Chapter 7. System Design: Addressing Design Goals
Bernd Bruegge/Allen H. Dutoit 253
Chapter 8. Object Design: Reusing Pattern Solutions
Bernd Bruegge/Allen H. Dutoit 299
Chapter 9. Object Design: Specifying Interfaces
Bernd Bruegge/Allen H. Dutoit 341
Chapter 10. Mapping Models to Code
Bernd Bruegge/Allen H. Dutoit 385
Chapter 11. Testing
Bernd Bruegge/Allen H. Dutoit 427
Chapter 12. Rationale Management
Bernd Bruegge/Allen H. Dutoit 481
Chapter 13. Configuration Management
Bernd Bruegge/Allen H. Dutoit 525

I
 Chapter 14. Project Management
Bernd Bruegge/Allen H. Dutoit 563
Chapter 15. Software Life Cycle
Bernd Bruegge/Allen H. Dutoit 607
Chapter 16. Methodologies: Putting It All Together
Bernd Bruegge/Allen H. Dutoit 637
Appendix C: Bibliography
Bernd Bruegge/Allen H. Dutoit 693
Index 707

II
 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.

From Chapter 1 of Object-Oriented Software Engineering Using UML, Patterns, and Java, Third Edition.
Bernd Bruegge, Allen H. Dutoit. Copyright © 2010 by Pearson Education, Inc. All rights reserved.
1
 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.

2
What Is Software Engineering?

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

3
 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

4
What Is Software Engineering?

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.

5
 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

6
What Is Software Engineering?

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.

7
 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].

8
Software Engineering Concepts

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.

9
 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.

10
Software Engineering Concepts

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.

11
 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

12
Software Engineering Concepts

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].

13
 Chapter 1 • Introduction to Software Engineering

For solution domain modeling activities, such as system design and object design, we describe
object-oriented activities similar to those of OMT. For change-related activities, we focus on
rationale management, which originated from design rationale research [Moran & Carroll,
1996], and configuration management, which originated from the maintenance of large systems
[Babich, 1986].

1.4 Software Engineering Development Activities

In this section, we give an overview of the technical activities associated with object-oriented
software engineering. Development activities deal with the complexity by constructing and
validating models of the application domain or the system. Development activities include

• Requirements Elicitation (Section 1.4.1)

• Analysis (Section 1.4.2)
• System Design (Section 1.4.3)
• Object Design (Section 1.4.4)
• Implementation (Section 1.4.5)
• Testing (Section 1.4.6).

Figure 1-2 depicts an overview of the relationship among these activities and their
products. In Section 1.5, we give an overview of the managerial activities associated with
software engineering. In Chapter 14, Project Management, and in Chapter 15, Software Life
Cycle, we discuss in more detail the modeling, planning, and software engineering activities.

1.4.1 Requirements Elicitation

During requirements elicitation, the client and developers define the purpose of the system.
The result of this activity is a description of the system in terms of actors and use cases. Actors
represent the external entities that interact with the system. Actors include roles such as end
users, other computers the system needs to deal with (e.g., a central bank computer, a network),
and the environment (e.g., a chemical process). Use cases are general sequences of events that
describe all the possible actions between an actor and the system for a given piece of
functionality. Figure 1-3 depicts a use case for the TicketDistributor example we discussed
previously. We describe requirements elicitation, including use cases and nonfunctional
requirements, in detail in Chapter 4, Requirements Elicitation.

1.4.2 Analysis
During analysis, developers aim to produce a model of the system that is correct, complete,
consistent, and unambiguous. Developers transform the use cases produced during requirements
elicitation into an object model that completely describes the system. During this activity,
developers discover ambiguities and inconsistencies in the use case model that they resolve with
the client. The result of analysis is a system model annotated with attributes, operations, and

14
Software Engineering Development Activities

problem
statement

Requirements
elicitation (Ch.4)

nonfunctional functional
requirements model use case diagram

Analysis (Ch.5)

analysis object
class diagram state machine
model
diagram
dynamic model
System design
(Ch.6 & 7) sequence diagram
subsystem
decomposition
system design
object model

design goals
Object design
(Ch.8 & 9)

object design
class diagram model

Implementation
(Ch. 10)
source code

Test (Ch.11)

deliverable system

Figure 1-2 An overview of object-oriented software engineering development activities and their
products. This diagram depicts only logical dependencies among work products. Object-oriented software
engineering is iterative; that is, activities can occur in parallel and more than once.

15
 Chapter 1 • Introduction to Software Engineering

Use case name PurchaseOneWayTicket

Participating actor Initiated by Traveler

Flow of events 1. The Traveler selects the zone in which the destination station is located.
2. The TicketDistributor displays the price of the ticket.
3. The Traveler inserts an amount of money that is at least as much as the
price of the ticket.
4. The TicketDistributor issues the specified ticket to the Traveler and
returns any change.
Entry condition The Traveler stands in front of the TicketDistributor, which may be
located at the station of origin or at another station.
Exit condition The Traveler holds a valid ticket and any excess change.
Quality requirements If the transaction is not completed after one minute of inactivity, the
TicketDistributor returns all inserted change.

Figure 1-3 An example of use case, PurchaseOneWayTicket.

associations. The system model can be described in terms of its structure and its dynamic
interoperation. Figure 1-4 depicts an example of dynamic model for the TicketDistributor.
Figure 1-5 depicts an example of object model for the TicketDistributor.

:TicketDistributor :Zone :Balance

:Traveler
selectZone() getPrice()
amountDue

insertChange()
updateBalance()
amountDue

insertChange()
updateBalance()
acknowledgement
«create»
printedTicket :Ticket

Figure 1-4 A dynamic model for the TicketDistributor (UML sequence diagram). This diagram
depicts the interactions between the actor and the system during the PurchaseOneWayTicket use case and
the objects that participate in the use case.

16
Software Engineering Development Activities

Transaction Ticket Zone

results into valid for

Coin

Balance
amount paid
Bill

Figure 1-5 An object model for the TicketDistributor (UML class diagram). In the
PurchaseOneWayTicket use case, a Traveler initiates a transaction that will result in a Ticket. A Ticket
is valid only for a specified Zone. During the Transaction, the system tracks the Balance due by counting
the Coins and Bills inserted.

We describe analysis, including object models, in detail in Chapter 5, Analysis. We

describe in detail the UML notation for representing models in Chapter 2, Modeling with UML.

1.4.3 System Design

During system design, developers define the design goals of the project and decompose the
system into smaller subsystems that can be realized by individual teams. Developers also select
strategies for building the system, such as the hardware/software platform on which the system
will run, the persistent data management strategy, the global control flow, the access control
policy, and the handling of boundary conditions. The result of system design is a clear
description of each of these strategies, a subsystem decomposition, and a deployment diagram
representing the hardware/software mapping of the system. Whereas both analysis and system
design produce models of the system under construction, only analysis deals with entities that
the client can understand. System design deals with a much more refined model that includes
many entities that are beyond the comprehension (and interest) of the client. Figure 1-6 depicts
an example of system decomposition for the TicketDistributor. We describe system design
and its related concepts in detail in Chapter 6, System Design: Decomposing the System, and in
Chapter 7, System Design: Addressing Design Goals.

1.4.4 Object Design

During object design, developers define solution domain objects to bridge the gap between the
analysis model and the hardware/software platform defined during system design. This includes
precisely describing object and subsystem interfaces, selecting off-the-shelf components,
restructuring the object model to attain design goals such as extensibility or understandability,
and optimizing the object model for performance. The result of the object design activity is a
detailed object model annotated with constraints and precise descriptions for each element. We
describe object design and its related concepts in detail in Chapter 8, Object Design: Reusing
Pattern Solutions, and Chapter 9, Object Design: Specifying Interfaces.

17
 Chapter 1 • Introduction to Software Engineering

TravelerInterface Updater

LocalTariff CentralTariff

Figure 1-6 A subsystem decomposition for the TicketDistributor (UML class diagram, packages
represent subsystems, dashed lines represent dependencies). The TravelerInterface subsystem is
responsible for collecting input from the Traveler and providing feedback (e.g., display ticket price,
returning change). The LocalTariff subsystem computes the price of different tickets based on a local
database. The CentralTariff subsystem, located on a central computer, maintains a reference copy of the
tariff database. An Updater subsystem is responsible for updating the local databases at each
TicketDistributor through a network when ticket prices change.

1.4.5 Implementation

During implementation, developers translate the solution domain model into source code. This
includes implementing the attributes and methods of each object and integrating all the objects
such that they function as a single system. The implementation activity spans the gap between
the detailed object design model and a complete set of source code files that can be compiled.
We describe the mapping of UML models to code in Chapter 10, Mapping Models to Code. We
assume the reader is already familiar with programming concepts and knows how to program
data structures and algorithms using an object-oriented language such as Java or C++.

1.4.6 Testing

During testing, developers find differences between the system and its models by executing the
system (or parts of it) with sample input data sets. During unit testing, developers compare the
object design model with each object and subsystem. During integration testing, combinations
of subsystems are integrated together and compared with the system design model. During
system testing, typical and exception cases are run through the system and compared with the
requirements model. The goal of testing is to discover as many faults as possible such that they
can be repaired before the delivery of the system. The planning of test phases occurs in parallel
to the other development activities: System tests are planned during requirements elicitation and
analysis, integration tests are planned during system design, and unit tests are planned during
object design. We describe these issues in more detail in Chapter 11, Testing.

18
Managing Software Development

1.5 Managing Software Development

In this section, we briefly describe the activities involved in managing a software engineering
project. Management activities focus on planning the project, monitoring its status, tracking
changes, and coordinating resources such that a high-quality product is delivered on time and
within budget. Management activities not only involve managers, but also most of the other
project participants as well. Management activities include

• Communication (Section 1.5.1)

• Rationale Management (Section 1.5.2)
• Software Configuration Management (Section 1.5.3)
• Project Management (Section 1.5.4)
• Software Life Cycle (Section 1.5.5).

Software maintenance, which we do not cover in this book, includes the development
activities that occur after the delivery of the system to the client. Traditionally, software
maintenance has been distinguished from the other development activities as it is highly change
driven and is performed by a different team than the original development team. As modern
software engineering projects become more change driven, the distinction between construction
activities and maintenance activities is blurred. Many of the activities described in this book
can carry on to maintenance, including object design, implementation, testing, rationale
management, and software configuration management.

1.5.1 Communication
Communication is the most critical and time-consuming activity in software engineering.
Misunderstandings and omissions often lead to faults and delays that are expensive to correct
later in the development. Communication includes the exchange of models and documents about
the system and its application domain, reporting the status of work products, providing feedback
on the quality of work products, raising and negotiating issues, and communicating decisions.
Communication is made difficult by the diversity of participants’ backgrounds, by their
geographic distribution, and by the volume, complexity, and evolution of the information
exchanged.
To deal with communication issues, project participants have many tools available. The
most effective one is conventions: When participants agree on notations for representing
information, on tools for manipulating information, and on procedures for raising and resolving
issues, they already have eliminated substantial sources of misunderstanding. Examples of
notations include UML diagrams, templates for writing documents and meeting minutes, and
identification schemes for naming software components. Examples of tools include Computer
Aided Software Engineering (CASE) tools for maintaining models, word processors for
generating documents, and interchange formats for publishing information. Examples of
procedures include meeting procedures for organizing, conducting, and capturing a meeting,

19
 Chapter 1 • Introduction to Software Engineering

review procedures for reviewing documents and providing feedback, and inspection procedures
for detecting defects in models or source code. The selected conventions do not need to be the
best available; they only need to be shared and agreed on by everybody. We describe
communication issues in detail in Chapter 3, Project Organization and Communication.

1.5.2 Rationale Management

Rationale is the justification of decisions. Given a decision, its rationale includes the problem
that it addresses, the alternatives that developers considered, the criteria that developers used to
evaluate the alternatives, the debate developers went through to achieve consensus, and the
decision. Rationale is the most important information developers need when changing the
system. If a criterion changes, developers can reevaluate all decisions that depend on this
criterion. If a new alternative becomes available, it can be compared with all the other
alternatives that were already evaluated. If a decision is questioned, they can recover its rationale
to justify it.
Unfortunately, rationale is also the most complex information developers deal with during
development, and thus, the most difficult to update and maintain. To deal with this challenge,
developers capture rationale during meetings and on-line discussions, represent rationale with
issue models, and access rationale during changes. We describe these issues in detail in
Chapter 12, Rationale Management.

1.5.3 Software Configuration Management

Software configuration management is the process that monitors and controls changes in work
products. Change pervades software development. Requirements change as the client requests
new features and as developers improve their understanding of the application domain. The
hardware/software platform on which the system is built changes as new technology becomes
available. The system changes as faults are discovered during testing and are repaired. Software
configuration management used to be in the realm of maintenance, when improvements are
incrementally introduced in the system. In modern development processes, however, changes
occur much earlier than maintenance does. Thus, changes during development can be dealt with
using configuration management at all stages.
Configuration management enables developers to track changes. The system is
represented as a number of configuration items that are independently revised. For each
configuration item, its evolution is tracked as a series of versions. Selecting versions enables
developers to roll back to a well-defined state of the system when a change fails.
Configuration management also enables developers to control change. After a baseline has
been defined, any change needs to be assessed and approved before being implemented. This
enables management to ensure that the system is evolving according to project goals and that the
number of problems introduced into the system is limited. We describe these issues in detail in
Chapter 13, Configuration Management.

20
ARENA Case Study

1.5.4 Project Management

Project management does not produce any artifact of its own. Instead, project management
includes the oversight activities that ensure the delivery of a high-quality system on time and
within budget. This includes planning and budgeting the project during negotiations with the
client, hiring developers and organizing them into teams, monitoring the status of the project,
and intervening when deviations occur. Most project management activities are beyond the
scope of this book. We describe, however, the project management activities that are visible to
the developers and techniques that make the development–management communication more
effective. We describe these issues in detail in Chapter 14, Project Management.

1.5.5 Software Life Cycle

In this chapter, we describe software engineering as a modeling activity. Developers build
models of the application and solution domains to deal with their complexity. By ignoring
irrelevant details and focusing only on what is relevant to a specific issue, developers can more
effectively resolve issues and answer questions. The process of developing software can also be
viewed as a complex system with inputs, outputs, activities, and resources. It is not surprising,
then, that the same modeling techniques applied to software artifacts are used for modeling
software processes. A general model of the software development process is called a software
life cycle. We describe software life cycles in Chapter 15, Software Life Cycle.

1.5.6 Putting It All Together

After reading Chapters 1–15 in this book, you will have an overview of the current state-of-the-
art methods in object-oriented software engineering, which you can view as a thick cookbook of
recipes. In practice, however, a cookbook is rarely enough for the novice to cook a complete
meal. Moreover, not all ingredients are always available, and the cook has to improvise to bridge
the gaps.
Chapter 14, Project Management, focuses on planning and controlling projects.
Chapter 15, Software Life Cycle, focuses on modeling, improving, and repeating software life
cycle processes. Both chapters, because they focus on techniques and models, take an optimistic
view of project execution. In Chapter 16, Methodologies: Putting It All Together, we examine
what happens outside of textbook situations. We provide methodologies and heuristics for
adapting the building blocks presented in the other chapter to specific situations. In particular,
we describe several agile and heavier methodologies.

1.6 ARENA Case Study

In each chapter, we introduce concepts and activities using increasingly complex examples,
starting with toy examples from the classroom and moving to actual examples from project
courses or from real systems. Moreover, to put the activities of each chapter in the context of the
overall software engineering project, we also use a single, comprehensive case study throughout
the book, describing the development of a system called ARENA.

21
 Chapter 1 • Introduction to Software Engineering

ARENA is a multi-user, Web-based system for organizing and conducting tournaments.

ARENA is game independent in the sense that organizers can adapt a new game to the ARENA game
interface, upload it to the ARENA server, and immediately announce and conduct tournaments
with players and spectators located anywhere on the Internet. Organizers can also define new
tournament styles, describing how players are mapped to a set of matches and how to compute
an overall ranking of players by adding up their victories and losses (hence, figuring out who
won the tournament). To recoup their operational costs, organizers can also invite potential
sponsors to display advertisement banners during games.
In the section entitled “ARENA Case Study” located at the end of each chapter, we discuss
issues, design decisions, and trade-offs specific to the chapter in the context of ARENA. We also
relate these issues to the parts of the case study presented in previous chapters, thereby
emphasizing inter-chapter dependencies. For example:

• In Chapter 4, Requirements Elicitation, we describe how developers write an initial set

of use cases based on information provided by a client. We define in more detail how
tournaments should be organized and announced, and how players apply for new
tournaments. In the process, we generate more questions for the client and uncover
ambiguities and missing information about the system.
• In Chapter 5, Analysis, we describe how an object model and a behavior model are
constructed from the use case model. We also examine how the development of these
models leads to more refinements in the use case model and in the discovery of
additional requirements. For example, we define more formally the concept of
exclusive sponsorship, describe the workflow associated with deciding on the
sponsorship of a tournament, and consolidate the object model.
• In Chapter 7, System Design: Addressing Design Goals, we select a client server
architecture and a framework for realizing the system, and address issues such as data
storage and access control. We examine different mechanisms for authenticating users
on the Web, identify the persistent objects we need to store (e.g., game state,
tournament results, player profiles), and decompose ARENA into smaller subsystems that
can be handled by single programmers.
• In Chapter 8, Object Design: Reusing Pattern Solutions, and in Chapter 9, Object
Design: Specifying Interfaces, we identify additional solution domain objects to fill the
gap between the system design and the implementation. We reuse template solutions by
selecting design patterns for addressing specific issues. For example, a strategy pattern
is used to encapsulate different tournament styles.
• In Chapter 10, Mapping Models to Code, we translate the UML models we built so far
into Java code, and reexamine the object design as new optimization issues are
discovered. In this chapter, we illustrate the tight iteration between object design and
implementation.

22
Further Reading

The work products associated with the ARENA system, along with a demonstration, are available
from http://wwwbruegge.in.tum.de/OOSE/WebHome.

1.7 Further Reading

The fundamental issues associated with software engineering are not new and have been written
about for several decades.
In the Mythical Man Month [Brooks, 1995], first published in 1975, Frederick Brooks
reflects on his experience with developing an operating system for the IBM 360 mainframe, a
multi-million dollar, multi-year project that went over budget and schedule. Since then, different
techniques, tools, and methods have enabled software engineers to tackle more complex and
challenging problems, only to experience failures that are more expensive and more spectacular.
Many basic lessons of this landmark book are still applicable today.
In Computer-Related Risks [Neumann, 1995], Peter Neumann relates a collection of
computer-related failures, examine roots causes and effects of these failures, and discusses what
might be done to avoid them. Computer-Related Risks is a sobering account that should be read
by any software engineer who dreams of building and mastering complex systems.
Objective Knowledge: An Evolutionary Approach [Popper, 1992] is an essay about
knowledge construction. Karl Popper breaks from traditional knowledge theories dating back to
Aristotle and proposes that scientific knowledge, once stated in a human language, becomes a
separate entity that grows through selection. As software engineering is a collaborative
knowledge-gathering and construction activity, Popper’s book can be useful to stimulate critical
thinking and provide a different perspective on the field.
In this book, we focus on object-oriented software engineering and target senior-level
software engineering project courses. Consequently, we leave out several historical and
management topics that are traditionally included in software engineering books, such as
software metrics, cost estimation, and formal methods. An overview of these topics can be found
in more general software engineering textbooks, such as Software Engineering [Sommerville,
2006] and Software Engineering: A Practitioner’s Approach [Pressman, 2009].

1.8 Exercises
1-1 What is the purpose of modeling?
1-2 A programming language is a notation for representing algorithms and data structures.
List two advantages and two disadvantages of using a programming language as the
sole notation throughout the development process.
1-3 Consider a task you are not familiar with, such as designing a zero-emissions car. How
would you attack the problem?
1-4 What is meant by “knowledge acquisition is not sequential”? Provide a concrete
example of knowledge acquisition that illustrates this.
1-5 Hypothesize a rationale for the following design decisions:

23
 Chapter 1 • Introduction to Software Engineering

• “The TicketDistributor will be at most one and a half meters tall.”

• “The TicketDistributor will include two redundant computer systems.”
• “The TicketDistributor interface will consist of a touch screen for displaying
instructions and accessing commands and a single button for aborting transactions.”

1-6 Specify which of these statements are functional requirements and which are
nonfunctional requirements:

• “The TicketDistributor must enable a traveler to buy weekly passes.”

• “The TicketDistributor must be written in Java.”
• “The TicketDistributor must be easy to use.”
• “The TicketDistributor must always be available.”
• “The TicketDistributor must provide a phone number to call when it fails.”

1-7 Specify which of these decisions were made during requirements or system design:

• “The TicketDistributor is composed of a user interface subsystem, a subsystem

for computing tariff, and a network subsystem for managing communication with
the central computer.”
• “The TicketDistributor hardware uses PowerPC processor chips.”
• “The TicketDistributor provides the traveler with online help.”

1-8 In the following description, explain when the term account is used as an application
domain concept and when as a solution domain concept:

“Assume you are developing an online system for managing bank accounts for
mobile customers. A major design issue is how to provide access to the accounts
when the customer cannot establish an online connection. One proposal is that
accounts are made available on the mobile computer, even if the server is not up. In
this case, the accounts show the amounts from the last connected session.”

1-9 What is the difference between a task and an activity?

1-10 A passenger aircraft is composed of several millions of parts and requires thousands of
persons to assemble. A four-lane highway bridge is another example of complexity.
The first version of Word for Windows, a word processor released by Microsoft in
1989, required 55 person-years, resulted into 249,000 lines of source code, and was
delivered 4 years late. Aircraft and highway bridges are usually delivered on time and
within budget, whereas software is often not. Discuss what are, in your opinion, the
differences between developing an aircraft, a bridge, and a word processor that would
cause this situation.

24
References

References
[Babich, 1986] W. Babich, Software Configuration Management, Addison-Wesley, Reading, MA,
1986.
[Booch, 1994] G. Booch, Object-Oriented Analysis and Design with Applications, 2nd ed.
Benjamin/Cummings, Redwood City, CA, 1994.
[Brooks, 1995] F. P. Brooks, The Mythical Man Month: Anniversary Edition: Essays on Software
Engineering, Addison-Wesley, Reading, MA, 1995.
[Bruegge, 1992] B. Bruegge, “Teaching an industry-oriented software engineering course,” Software
Engineering Education, SEI Conference, Lecture Notes in Computer Sciences,
Vol. 640, pp. 65–87, Springer-Verlag, October 1992.
[Bruegge & Coyne, 1993] B. Bruegge & R. Coyne, “Model-based software engineering in larger scale project
courses,” IFIP Transactions on Computer Science and Technology, Vol. A-40,
pp. 273–287, Elsevier Science, Netherlands, 1993.
[Bruegge & Coyne, 1994] B. Bruegge & R. Coyne, “Teaching iterative object-oriented development: Lessons
and directions,” in J. L. Diaz-Herrera (ed.), 7th Conference on Software Engineering
Education, Lecture Notes in Computer Science, Vol. 750, pp. 413–427, Springer-
Verlag, 1994.
[Coyne et al., 1995] R. Coyne, B. Bruegge, A. Dutoit, & D. Rothenberger, “Teaching more comprehensive
model-based software engineering: Experience with Objectory’s use case approach,”
in L. Ibraham (ed.), 8th Conference on Software Engineering Education, Lecture
Notes in Computer Science, pp. 339–374, Springer-Verlag, April 1995.
[De Marco, 1978] T. De Marco, Structured Analysis and System Specification. Yourdon, New York,
1978.
[D’Souza & Wills, 1999] D. F. D’Souza & A. C. Wills, Objects, Components, and Frameworks with UML: The
Catalysis Approach, Addison-Wesley, Reading, MA, 1999.
[IEEE Std. 610.12-1990] IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer
Glossaries, New York, NY, 1990.
[Jacobson et al., 1992] I. Jacobson, M. Christerson, P. Jonsson, & G. Overgaard, Object-Oriented Software
Engineering—A Use Case Driven Approach, Addison-Wesley, Reading, MA, 1992.
[Moran & Carroll, 1996] T. P. Moran & J. M. Carroll (eds.), Design Rationale: Concepts, Techniques, and Use,
Lawrence Erlbaum Associates, Mahwah, NJ, 1996.
[Neumann, 1995] P. G. Neumann, Computer-Related Risks, Addison-Wesley, Reading, MA, 1995.
[OMG, 2009] Object Management Group, OMG Unified Modeling Language Specification. Version
2.2, 2009. http://www.omg.org.
[Popper, 1992] K. Popper, Objective Knowledge: An Evolutionary Approach, Clarendon, Oxford,
1992.
[Pressman, 2009] R. S. Pressman, Software Engineering: A Practitioner’s Approach, 7th ed., McGraw-
Hill, 2009.
[Royce, 1998] W. Royce, Software Project Management: A Unified Framework, Addison-Wesley,
Reading, MA, 1998.
[Rumbaugh et al., 1991] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, & W. Lorensen, Object-Oriented
Modeling and Design, Prentice Hall, Englewood Cliffs, NJ, 1991.
[Simon, 1970] H. A. Simon, The Sciences of the Artificial, MIT Press, Cambridge, MA, 1970.
[Sommerville, 2006] I. Sommerville, Software Engineering, 8th ed., Addison-Wesley, Reading, MA, 2006.
[Spivey, 1989] J. M. Spivey, The Z Notation, A Reference Manual, Prentice Hall, Hertfordshire, UK
1989.

25
26
 2
Modeling with UML

Every mechanic is familiar with the problem of the part you

can’t buy because you can’t find it because the
manufacturer considers it a part of something else.
—Robert Pirsig, in Zen and the Art of Motorcycle
Maintenance

N otations enable us to articulate complex ideas succinctly and precisely. In projects

involving many participants, often of different technical and cultural backgrounds, accuracy and
clarity are critical as the cost of miscommunication increases rapidly.
For a notation to enable accurate communication, it must come with a well-defined
semantics, it must be well suited for representing a given aspect of a system, and it must be well
understood among project participants. In the latter lies the strength of standards and
conventions: when a notation is used by a large number of participants, there is little room for
misinterpretation and ambiguity. Conversely, when many dialects of a notation exists, or when a
very specialized notation is used, the notation users are prone to misunderstandings as each user
imposes its own interpretation. We selected UML (Unified Modeling Language, [OMG, 2009])
as a primary notation for this book because it provides a spectrum of notations for representing
different aspects of a system and has been accepted as a standard notation in the industry.
In this chapter, we first describe the concepts of modeling in general and object-oriented
modeling in particular. We then describe five fundamental notations of UML that we use
throughout the book: use case diagrams, class diagrams, interaction diagrams, state machine
diagrams, and activity diagrams. For each of these notations, we describe its basic semantics and
provide examples. We revisit these notations in detail in later chapters as we describe the
activities that use them. Specialized notations that we use in only one chapter are introduced
later, such as UML deployment diagrams in Chapter 6, System Design: Decomposing the
System, and PERT charts in Chapter 14, Project Management.

From Chapter 2 of Object-Oriented Software Engineering Using UML, Patterns, and Java, Third Edition.
Bernd Bruegge, Allen H. Dutoit. Copyright © 2010 by Pearson Education, Inc. All rights reserved.
27
 Chapter 2 • Modeling with UML

2.1 Introduction
UML is a notation that resulted from the unification of OMT (Object Modeling Technique
[Rumbaugh et al., 1991]), Booch [Booch, 1994], and OOSE (Object-Oriented Software
Engineering [Jacobson et al., 1992]). UML has also been influenced by other object-oriented
notations, such as those introduced by Mellor and Shlaer [Mellor & Shlaer, 1998], Coad and
Yourdon [Coad et al., 1995], Wirfs-Brock [Wirfs-Brock et al., 1990], and Martin and Odell
[Martin & Odell, 1992].
The goal of UML is to provide a standard notation that can be used by all object-oriented
methods and to select and integrate the best elements of precursor notations. For example, UML
includes the use case diagrams introduced by OOSE and uses many features of the OMT class
diagrams. UML also includes new concepts that were not present in other major methods at the
time, such as extension mechanisms and a constraint language. UML has been designed for a
broad range of applications. Hence, it provides constructs for a broad range of systems and
activities (e.g., distributed systems, analysis, system design, deployment). System development
focuses on three different models of the system (see Figure 1-2):

• The functional model, represented in UML with use case diagrams, describes the
functionality of the system from the user’s point of view.
• The object model, represented in UML with class diagrams, describes the structure of
the system in terms of objects, attributes, associations, and operations. During
requirements and analysis, the object model starts as the analysis object model and
describes the application concepts relevant to the system. During system design, the
object model is refined into the system design object model and includes descriptions of
the subsystem interfaces. During object design, the object model is refined into the
object design model and includes detailed descriptions of solution objects.
• The dynamic model, represented in UML with interaction diagrams, state machine
diagrams, and activity diagrams, describes the internal behavior of the system.
Interaction diagrams describe behavior as a sequence of messages exchanged among a
set of objects, whereas state machine diagrams describe behavior in terms of states of
an individual object and the possible transitions between states. Activity diagrams
describe behavior in terms control and data flows.

In this chapter, we describe UML diagrams for representing these models. Introducing
these notations represents an interesting challenge: understanding the purpose of a notation
requires some familiarity with the activities that use it. However, it is necessary to understand
the notation before describing the activities. To address this issue, we introduce UML iteratively.
In the next section, we first provide an overview of the five basic notations of UML. In
Section 2.3, we introduce the fundamental ideas of modeling. In Section 2.4, we revisit the five
basic notations of UML in light of modeling concepts. In subsequent chapters, we discuss these
notations in even greater detail when we introduce the activities that use them.

28
An Overview of UML

2.2 An Overview of UML

In this section, we briefly introduce five UML notations:

• Use Case Diagrams (Section 2.2.1)

• Class Diagrams (Section 2.2.2)
• Interaction Diagrams (Section 2.2.3)
• State Machine Diagrams (Section 2.2.4)
• Activity Diagrams (Section 2.2.5).

2.2.1 Use Case Diagrams

Use cases are used during requirements elicitation and analysis to represent the functionality of
the system. Use cases focus on the behavior of the system from an external point of view. A use
case describes a function provided by the system that yields a visible result for an actor. An actor
describes any entity that interacts with the system (e.g., a user, another system, the system’s
physical environment). The identification of actors and use cases results in the definition of the
boundary of the system, that is, in differentiating the tasks accomplished by the system and the
tasks accomplished by its environment. The actors are outside the boundary of the system,
whereas the use cases are inside the boundary of the system.
For example, Figure 2-1 depicts a use case diagram for a simple watch. The WatchUser
actor may either consult the time on their watch (with the ReadTime use case) or set the time
(with the SetTime use case). However, only the WatchRepairPerson actor can change the
battery of the watch (with the ChangeBattery use case).

SimpleWatch

ReadTime

SetTime
WatchUser WatchRepairPerson

ChangeBattery

Figure 2-1 A UML use case diagram describing the functionality of a simple watch. The WatchUser actor
may either consult the time on her watch (with the ReadTime use case) or set the time (with the SetTime use
case). However, only the WatchRepairPerson actor can change the battery of the watch (with the
ChangeBattery use case). Actors are represented with stick figures, use cases with ovals, and the boundary
of the system with a box enclosing the use cases.

29
 Chapter 2 • Modeling with UML

2.2.2 Class Diagrams

Class diagrams are used to describe the structure of the system. Classes are abstractions that
specify the common structure and behavior of a set of objects. Objects are instances of classes
that are created, modified, and destroyed during the execution of the system. An object has state
that includes the values of its attributes and its links with other objects.
Class diagrams describe the system in terms of objects, classes, attributes, operations, and
their associations. For example, Figure 2-2 is a class diagram describing the elements of all the
watches of the SimpleWatch class. These watch objects all have an association to an object of the
PushButton class, an object of the Display class, an object of the Time class, and an object of
the Battery class. The numbers on the ends of associations denote the number of links each
SimpleWatch object can have with an object of a given class. For example, a SimpleWatch has
exactly two PushButtons, one Display, two Batteries, and one Time. Similarly, all
PushButton, Display, Time, and Battery objects are associated with exactly one SimpleWatch
object.

SimpleWatch
1 1 1 1
2 1 2 1
PushButton Display Battery Time

Figure 2-2 A UML class diagram describing the elements of a simple watch.

At the analysis level, associations represent existence relationships. For example, a

SimpleWatch requires the correct number of PushButtons, Displays, Batteries, and Time. In
this example, the association is symmetrical: PushButton cannot perform its function without a
SimpleWatch. UML also allows for one-directional relationships, which we describe in
Section 2.4.2. At the implementation level, associations are realized as references (i.e., pointers)
to objects.

2.2.3 Interaction Diagrams

Interaction diagrams are used to formalize the dynamic behavior of the system and to visualize
the communication among objects. They are useful for identifying additional objects that
participate in the use cases. We call objects involved in a use case participating objects. An
interaction diagram represents the interactions that take place among these objects. For example,
Figure 2-3 is a special form of interaction diagram, called a sequence diagram, for the SetTime
use case of our simple watch. The left-most column represents the WatchUser actor who initiates
the use case. Labeled arrows represent stimuli that an actor or an object sends to other objects. In
this case, the WatchUser presses button 1 twice and button 2 once to set her watch a minute
ahead. The SetTime use case terminates when the WatchUser presses both buttons
simultaneously.

30
An Overview of UML

:Watch :Display :Time

:WatchUser
pressButton1() blinkHours()
pressButton1() blinkMinutes()

pressButton2() incrementMinutes()
refresh()

pressButtons1And2() commitNewTime()
stopBlinking()

Figure 2-3 A UML sequence diagram for the Watch. The left-most column represents the timeline of the
WatchUser actor who initiates the use case. The other columns represent the timeline of the objects that
participate in this use case. Object names are underlined to denote that they are instances (as opposed to
classes). Labeled arrows are stimuli that an actor or an object sends to other objects.

2.2.4 State Machine Diagrams

State machine diagrams describe the dynamic behavior of an individual object as a number of
states and transitions between these states. A state represents a particular set of values for an
object. Given a state, a transition represents a future state the object can move to and the
conditions associated with the change of state. For example, Figure 2-4 is a state machine
diagram for the Watch. A small black circle initiates that BlinkHours is the initial state. A circle
surrounding a small black circle indicates that StopBlinking is a final state. Note that this
diagram represents different information than the sequence diagram of Figure 2-3. The sequence
diagram focuses on the messages exchanged between objects as a result of external events
created by actors. The state machine diagram focuses on the transitions between states as a result
of external events for an individual object.

2.2.5 Activity Diagrams

An activity diagram describes the behavior of a system in terms of activities. Activities are
modeling elements that represent the execution of a set of operations. The execution of an
activity can be triggered by the completion of other activities, by the availability of objects, or by
external events. Activity diagrams are similar to flowchart diagrams in that they can be used to
represent control flow (i.e., the order in which operations occur) and data flow (i.e., the objects
that are exchanged among operations). For example, Figure 2-5 is an activity diagram
representing activities related to managing an Incident. Rounded rectangles represent
activities; arrows between activities represent control flow; thick bars represent the

31
 Chapter 2 • Modeling with UML

button1&2Pressed button2Pressed
Increment
BlinkHours Hours

button1Pressed

button1&2Pressed button2Pressed
Increment
BlinkMinutes Minutes

button1Pressed

button1&2Pressed
button2Pressed
Increment
StopBlinking BlinkSeconds Seconds

Figure 2-4 A UML state machine diagram for SetTime use case of the Watch.

synchronization of the control flow. The activity diagram of Figure 2-5 depicts that the
AllocateResources, CoordinateResources, and DocumentIncident can be initiated only after
the OpenIncident activity has been completed. Similarly, the ArchiveIncident activity can be
initiated only after the completion of AllocateResources, Coordinate–Resources, and
DocumentIncident. These latter three activities, however, can occur concurrently.
This concludes our first walkthrough of the five basic notations of UML. Now, we go into
more detail: In Section 2.3, we introduce basic modeling concepts, including the definition of

Allocate
Resources

Open Coordinate Archive

Incident Resources Incident

Document
Incident

Figure 2-5 An example of a UML activity diagram. Activity diagrams represent behavior in terms of
activities and their precedence constraints. The completion of an activity triggers an outgoing transition,
which in turn may initiate another activity.

32
Modeling Concepts

systems, models, types, and instances, abstraction, and falsification. In Sections 2.4.1–2.4.5, we
describe in detail use case diagrams, class diagrams, sequence diagrams, state machine
diagrams, and activity diagrams. We illustrate their use with a simple example. Section 2.4.6
describes miscellaneous constructs, such as packages and notes, that are used in all types of
diagrams. We use these five notations throughout the book to describe software systems, work
products, activities, and organizations. By the consistent and systematic use of a small set of
notations, we hope to provide the reader with an operational knowledge of UML.

2.3 Modeling Concepts

In this section, we describe the basic concepts of modeling. We first define the terms system,
model, and view, and discuss the purpose of modeling. We explain their relationship to
programming languages and terms such as data types, classes, instances, and objects. Finally,
we describe how object-oriented modeling focuses on building an abstraction of the system
environment as a basis for the system model.

2.3.1 Systems, Models, and Views

A system is an organized set of communicating parts. We focus here on engineered systems,
which are designed for a specific purpose, as opposed to natural systems, such as a planetary
system, whose ultimate purpose we may not know. A car, composed of four wheels, a chassis, a
body, and an engine, is designed to transport people. A watch, composed of a battery, a circuit,
wheels, and hands, is designed to measure time. A payroll system, composed of a mainframe
computer, printers, disks, software, and the payroll staff, is designed to issue salary checks for
employees of a company. Parts of a system can in turn be considered as simpler systems called
subsystems. The engine of a car, composed of cylinders, pistons, an injection module, and many
other parts, is a subsystem of the car. Similarly, the integrated circuit of a watch and the
mainframe computer of the payroll system are subsystems. This subsystem decomposition can
be recursively applied to subsystems. Objects represent the end of this recursion, when each
piece is simple enough that we can fully comprehend it without further decomposition.
Many systems are made of numerous subsystems interconnected in complicated ways,
often so complex that no single developer can manage its entirety. Modeling is a means for
dealing with this complexity. Complex systems are generally described by more than one model,
each focusing on a different aspect or level of accuracy. Modeling means constructing an
abstraction of a system that focuses on interesting aspects and ignores irrelevant details. What is
interesting or irrelevant varies with the task at hand. For example, assume we want to build an
airplane. Even with the help of field experts, we cannot build an airplane from scratch and hope
that it will function correctly on its maiden flight. Instead, we first build a scale model of the air
frame to test its aerodynamic properties. In this scale model, we only need to represent the
exterior surface of the airplane. We can ignore details such as the instrument panel or the engine.
In order to train pilots for this new airplane, we also build a flight simulator. The flight simulator
needs to accurately represent the layout and behavior of flight instruments. In this case, however,

33
 Chapter 2 • Modeling with UML

details about the exterior of the plane can be ignored. Both the flight simulator and the scale
model are much less complex than the airplane they represent. Modeling allows us to deal with
complexity through a divide-and-conquer approach: For each type of problem we want to solve
(e.g., testing aerodynamic properties, training pilots), we build a model that only focuses on the
issues relevant to the problem. Generally, modeling focuses on building a model that is simple
enough for a person to grasp completely. A rule of thumb is that each entity should contain at
most 7 ± 2 parts [Miller, 1956].
Modeling also helps us deal with complexity by enabling us to incrementally refine simple
models into more detailed ones that are closer to reality. In software engineering, as in all
engineering disciplines, the model usually precedes the system. During analysis, we first build a
model of the environment and of the common functionality that the system must provide, at a
level that is understandable by the client. Then we refine this model, adding more details about
the forms that the system should display, the layout of the user interface, and the response of the
system to exceptional cases. The set of all models built during development is called the system
model. If we did not use models, but instead started coding the system right away, we would
have to specify all the details of the user interface before the client could provide us with
feedback. Thus we would lose much time and resources when the client then introduces
changes.
Unfortunately, even a model may become so complex that it is not easily understandable.
We can continue to use the divide-and-conquer method to refine a complex model into simpler
models. A view focuses on a subset of a model to make it understandable (Figure 2-6). For
example, all the blueprints necessary to construct an airplane constitute a model. Excerpts
necessary to explain the functioning of the fuel system constitute the fuel system view. Views
may overlap: a view of the airplane representing the electrical wiring also includes the wiring for
the fuel system.

Scale model

Electrical
All blueprints
Airplane
Fuel

Flight simulator

Figure 2-6 A model is an abstraction describing a subset of a system. A view depicts selected aspects of
a model. Views and models of a single system may overlap each other.

34
Modeling Concepts

Notations are graphical or textual rules for representing views. A UML class diagram is a
graphical view of the object model. In wiring diagrams, each connected line represents a
different wire or bundle of wires. In UML class diagrams, a rectangle with a title represents a
class. A line between two rectangles represents a relationship between the two corresponding
classes. Note that different notations can be used to represent the same view (Figure 2-7).

UML
1 *
Book Chapter
composed-of
Booch

N
Book Chapter
composed-of

Figure 2-7 Example of describing a model with two different notations. The model includes two classes,
Book and Chapter, with the relationship, Book is composed of Chapters. In UML, classes are depicted
by rectangles and aggregation associations by a line terminated with a diamond. In the Booch notation,
classes are depicted by clouds, and aggregation associations are depicted with a line terminated with a solid
circle.

In software engineering, there are many other notations for modeling systems. UML
describes a system in terms of classes, events, states, interactions, and activities. Data flow
diagrams [De Marco, 1978] depict how data is retrieved, processed, and stored. Z Schemes
[Spivey, 1992] represent the system in terms of invariants (conditions that never change) and in
terms of what is true before and after the execution of an operation. Each notation is tailored for
a different problem.
In the next sections, we focus in more detail on the process of modeling.

2.3.2 Data Types, Abstract Data Types, and Instances

A data type is an abstraction in the context of a programming language. A data type has a
unique name that distinguishes it from other data types. It denotes a set of values that are
members of the data type (i.e., the instances of the data type) and defines the structure and the
operations valid in all instances of the data type. Data types are used in typed languages to
ensure that only valid operations are applied to specific instances.
For example, the name int in Java corresponds to all the signed integers between –232 and
232 – 1. The valid operations on this type are all the integer arithmetic operations (e.g., addition,
subtraction, multiplication, division) and all the functions and methods that have parameters of
type int (e.g., mod). The Java run-time environment throws an exception if a floating point
operation is applied to an instance of the int data type (e.g., trunc or floor).

35
Exploring the Variety of Random
Documents with Different Content
“O an’ the little angel he is, ma’am!” she exclaimed. “O to have him
in me arrums but the oncet. Would he come to the likes of me, Miss
Anna?”
“Sure, Bell,” said Anna, though Mrs. Langley frowned upon the bold
request. But Big Bell held out her great strong arms, and, the baby
responding with unusual readiness, gathered him tenderly into them.
Mrs. Langley, who yielded him ungraciously, watched Bell
suspiciously as she marched about the room with him, showing him
the colleen on the parlour clock and the wee people on the silver
water-pitcher. But when Bell put a bright blue worsted mat with a
fringe of tassels on top of her head and cocked it at the baby,
winking one eye, and the baby actually and unmistakably smiled,
Mrs. Langley smiled, too. Nevertheless, she couldn’t endure it
another second and demanded that Joe, Junior, be returned to her
at once.
Bell was bold enough to ask her if she felt she was strong enough,
and then gave him up reluctantly. “I’ve a way with ’em same’s ever,”
she declared defiantly. “I brought up my sister’s babies till her man
married again, and when I first went into service it was as a nurse.”
She would have gone on, but suddenly her feelings overcame her
and she turned and fled.

On her way home, Anna prudently decided to say nothing of the

marvel of the baby’s talking until after he should have gone to sleep.
After that had happened she related the story dramatically to the
assembled family.
They were all greatly excited, but the boys were wild with
anticipation and could scarcely wait until morning. Though it was
Sunday and dark, they were up and dressed at six o’clock and had a
long, weary wait before the hero made his appearance. But the
instant Joe, Junior, finished his porridge, they fetched his picture
book. It was already open at L and Anna was as much delighted as
they when he promptly said Baa! to the lamb.
“Ask him something else, quick!” cried Freddy, as if there were not a
moment to lose.
“O Freddy, that’s no fair. He’s only a baby. You mustn’t expect too
much of him,” cautioned Anna.
“No, indeed, Fred Miller, don’t you dare turn that page,” added the
elder brother sternly. “You’ll get him mixed up and scared and then
he’ll never say baa again. Don’t you dare. We’ll practise him a while
on this now.”
Freddy snatched the book, opened it at random in his haste, and
before Frank could interfere demanded of the baby what that might
be. The choice was unfortunate, that being an hippopotamus with a
gaping red mouth.
“Moo moo!” cried the baby almost dramatically, and the boys
shouted for joy. Then alike unmindful of threats and warnings, they
went through the book, and the astonishing baby had an answer for
every question. He wasn’t always right, but he only appeared the
more clever. He said bow-wow for the camel but he gave a really
creditable roar for the cinnamon bear.
In truth, Joe, Junior, seemed to have come into his own. Not only
did Anna and the boys hang over him spell-bound and Seth Miller
seem glued to the spot, but Mrs. Miller left her work not only
patiently but eagerly whenever the boys summoned her, and once
she bent over the baby and kissed him.
Not long after the others had gone to service, Mrs. Lorraine came in.
She made Anna lie down on the sofa and sat beside her.
“I understand the baby has begun to talk,” she observed.
“O Mrs. Lorraine! Already? Who told you?” asked the girl eagerly.
“Your father and mother and Frank each told me separately, and
Frank and Freddy together. And Miss Penny told me last evening. Mr.
Langley told someone and Mr. Phelps heard it at the post office.”
“I’m glad ma told you,” Anna remarked. “She’s beginning to take to
him. She kissed him this morning.”
Mrs. Lorraine sighed. Anna had been pale when she came in. Now
her cheeks were crimson and her eyes too bright. She was always
thin, but to-day her face looked pinched. Anna was second only to
Alice herself in Mrs. Lorraine’s heart.
“Anna, I wish you would find a home for that baby or let some of
us,” she said anxiously. “The responsibility is too much for you. Many
people would be glad to take him, I am sure.”
“Glad! my goodness, they’d jump at the chance!” rejoined Anna.
“And well they might. I did think that I would give him away, but I
don’t believe now that I could part with him. And it’s different now.
The boys are crazy over him and so is pa. And now that ma——”
Mrs. Lorraine perceived that she had taken the wrong tack. She
must try again.
“But Anna, having him keeps you from so many things. They really
need you in the choir, you know.”
“Alice might sing in the choir. Her voice is better than mine and she
knows heaps more about music.”
“Alice wouldn’t go in without you, and her voice really isn’t so sweet.
And your mother needs you, Anna. Like most mothers, she has been
tied at home for years, and it seems a pity that just as she begins to
go about she should lose your companionship. And your school-
mates——”
As Anna sat up, suddenly she looked so distressed that Mrs.
Lorraine’s heart failed her. She had never been a very considerate
woman—hadn’t taken any thought to avoid hurting the feelings of
others. But she must have become more sensitive of late. Certainly it
hurt her to hurt the girl before her.
“You see, dear child, you are just the sort of person everyone wants
a share of, but little Joe quite monopolises you,” she went on more
gently. “You and Alice were reading Retaliation the other day, you
know. Well, you’re like the line on Burke. You give up to Joe, Junior,
what was meant for mankind.”
Anna laughed, though ruefully. She rose and made a movement to
smooth her hair, then remembered that her braid was gone and
shook her short locks. Seating herself in a straight chair, she folded
her hands over her knee.
“One reason why I hate to give him up, Mrs. Lorraine, is because
he’s Bessy’s baby and Joe’s,” she began wistfully. “He’s the only part
of them and of that life that I’ve got left, you see. Not that I want
ever to go back to it. I love the Hollow and Farleigh and all the
people, and yet there’s something that makes me feel I don’t want
to forget the other altogether. Bessy wore a pompadour that made
even me shiver and she chewed gum, and Joe would have looked
like a jumping-jack beside Reuben, and yet Bessy and Joe were both
true blue. Bessy got all run down while Joe was sick going without
things so that he could have milk and eggs, and when he got back
to work he went without lunches so that she would think his pay
was the same as it had been. And if Hazel or I or any of their friends
had had hard luck, they would have taken them in and done
everything for them the same as Hazel did for Bessy when the time
came.”
She looked entreatingly into Mrs. Lorraine’s dark eyes, which were
sympathetic but perplexed.
“You can’t understand how it is, unless you live right among them,
but if you once have, there’s something mighty precious in the
memory of that life that you wouldn’t lose hold of. If I didn’t want
Joe, Junior, myself, I should want him because he’s Bessy’s and
Joe’s,” she said earnestly.
The girl was very quiet all the rest of the day. She pondered sadly
over what Mrs. Lorraine had said and over what her words had
further implied. She had not realised that they had missed her, her
mother and the boys and Miss Penny and Alice—Alice most of all,
perhaps, though her mother didn’t dream that. Perhaps she could do
things for them that others couldn’t, while the baby would really be
better off with the Langleys. Mr. Langley and Bell Adams would be
wonderful with him and it began to look as if Mrs. Langley would
make a creditable mother. And Alice needed her; and Alice’s mother
needed something in Alice which perhaps only Anna could watch out
for. And Alice had never been really happy until she was twenty and
Mrs. Lorraine not until she was forty-five. And both had been so
frightfully unhappy. And there was that terrible black shadow of the
prison hanging over them for ten years to come.
Giving up Joe, Junior, was of course only what she had planned to
do in the first place. It was only what she had worked and struggled
for ever since she had returned with the baby. And even before that,
she had been longing to discover some means of repaying Mr.
Langley for all he had done for Rusty and her family in general and
to comfort him for losing his little Ella May after all the years. Yet
now that she had it within her power to give him something that
would be like his heart’s desire, she was grudging it. But O—that
darling baby! And he loved her as he cared for no one else.
On a sudden, Anna decided to go to evening service. She had kissed
the baby in his sleep and almost thought he smiled, and as she flew
over the frozen ground, her heart grew light again. Her own words
came back to her. “The baby loves me best.” They echoed in her
heart and she almost danced along to their melody. He loved her
best and therefore he belonged to her as he could belong to no
other. For, after all, there was nothing like love. Advantages and all
sorts of material goods couldn’t compete with it. She was going to
keep Joe, Junior, always.
 CHAPTER XVII
ANNA MILLER went forth exultantly, hugging the certainty to her
heart that Joe, Junior, loved her best and that she had, therefore, a
right to keep him to grow up in an household wherein everyone
loved and wanted him. But all her elation died out at the sight of Mr.
Langley’s face as it looked down from the pulpit. He looked as he
had never looked before, and the girl knew only too well that it was
all because of the baby’s visit to the parsonage yesterday. He looked
weary—at once wistfully and radiantly weary. He looked as if he had
been through floods and stood on mountain summits. He looked,
poor dear, as if he ought to have a darling, cuddling, prattling baby
at the parsonage all the time.
So the question was unsettled again and settled the other way,
though Anna lay awake for hours that night before she announced
the painful decision formally to herself. And even then she did not
dare trust herself until she had burned all her bridges behind her.
She hastened over to the parsonage late Monday afternoon.
At the door, Big Bell enquired eagerly though shyly for the blessed
baby. When Anna told her of his feats with the picture book, Bell
laughed and choked and got out of the way quickly to conceal her
tears. Anna’s eyes were moist as she entered Mrs. Langley’s room.
“O Mrs. Langley, what do you think now?” she cried, and proceeded
to relate the story of the pictures at greater length. And as she told
it, she and Mrs. Langley laughed and cried together in new intimacy.
“Why didn’t you bring him with you?” Mrs. Langley asked wistfully.
And the girl’s heart sank to feel how fatally easy it was to be to give
away the baby. She spoke very low in order to keep her voice
steady.
“Because—O, Mrs. Langley, I don’t think we’ll keep little Joe. We all
love him—even ma, but we don’t really need him and—don’t you
know someone who would like a baby boy that talks?”
Mrs. Langley stared at the girl. The blinds were raised to-day, though
not so high, and she wore the pretty gown and becoming
arrangement of her hair. She looked even more attractive than she
had on Saturday, for she seemed used to the change. It was almost
as if she had always let in the sunshine and the rich rosy afterglow
which prevailed now and had never resembled Red-Riding-Hood’s
wolf in her grandmother’s cap and gown. And Anna jumped at the
conclusion any young or immature person might have made that the
transformation within must be as complete and thorough.
“Wouldn’t you like him yourself—you and Mr. Langley?” she asked
gently. “If so, I’ll give him to you as a Christmas present.”
Mrs. Langley only stared the more blankly. The idea was absolutely
new and strange to her mind and therefore startling. Never in all her
life before had she been so surprised, so astounded.
Then suddenly a sharp twinge of neuralgia, zigzagging up her face
into her head converted her confusion into a sort of blind rage. As it
died away, it left her with a sensation of faintness and sickness.
“I don’t know what you are thinking of, Anna Miller, to—to—upset
me so!” she cried querelously. “Of course we couldn’t have him here
and I an invalid! It would kill me—break my heart.”
As for Anna, she was quite confounded. Absolutely unprepared for
the refusal of the precious gift it had cost her so much to proffer, the
repetition of that hateful, meaningless phrase irritated her keenly.
But for Mr. Langley’s sake, she spoke with measure.
“But Mrs. Langley, I thought you were better—a heap better,” she
protested. “Tell me, does your head ache at this very minute?”
Mrs. Langley considered, or tried to do so. “I can’t tell,” she
snapped. “I think it must, but I am so wrought up I’m sure I can’t
tell. But I know this. As soon as you go, I shall find myself suffering
torture, and it’s likely to keep up all night.”
“I am so sorry. I didn’t mean to excite you,” murmured Anna meekly.
“But Joe, Junior, wouldn’t excite you, not a bit. And he wouldn’t be
any trouble even to a worse invalid than you were when you were at
your very sickest. He isn’t at all like other babies. Big Bell would take
all the care of him—she knows how to handle ’em and she’s crazy
about him already. And Mr. Langley would play with him—he’d love
to, too—and then whenever you wanted to see him and hear the
little love talk, why all you’d have to do would be to have him
brought in—ask Bell for him.”
“And like as not Bell would have an excuse all ready. I know Bell
Adams better than you do, Anna Miller! She’d keep him to herself all
the time and when I wanted him, she’d say he was having a nap.
And he’d like Mr. Langley better than he would me and he wouldn’t
come to me from him. And—O dear, O dear, why did you come here
with your wild notions stirring me up so that I sha’n’t get a wink of
sleep all night!”
Anna looked desperately and forlornly at the big purple roses. A long
pause ensued which Mrs. Langley finally broke.
“Anna, I would like to have you bring the baby over here just as
often as you can,” she said in a conciliatory way. “Of course it
wouldn’t be wise for me to have him in the house all the time in my
delicate state of health, as you would know if you were older or had
had experience with illness. But I would dearly love to have you
bring him over every day besides all Saturday afternoons.”
Slow to anger as the girl was, she wasn’t proof against this. She
sprang to her feet.
“Not on your tintype!” she cried hotly. “That baby shall never come
to this house again unless he comes to stay—never! never! I’ve got
something else to do than tote him way over here every day, and if
you want to see him days you’ve got to shelter him nights. Not that
the darling has to go a begging for shelter, for I’m sure I don’t want
to give him away. But I’ll give you one more chance. Do you want
him to keep, or will you never look on his face again?”
Mrs. Langley began to remonstrate peevishly. Anna repeated her
demand fiercely.
“O Anna, I couldn’t think of doing that. It would break my heart,”
Mrs. Langley almost wailed. Anna turned at the door.
“Very well, then. It’s settled,” she cried, “and you shall never have
him, never! I wanted to keep him myself and now I will and there’ll
be no more fussing about it. I shall give up my life to him and never
marry. And, believe me, I shall never come near this house again!”
“I’m sure, I’m glad to hear that!” retorted Mrs. Langley. “Don’t flatter
yourself that it’s any favour to me your coming here and ordering
me round and stirring me all up in this fashion. I’ll thank you to pull
that curtain down and leave me alone.”
Anna yanked at the blind viciously and down it came, fixture and all,
with a sad crash. Startled out of her wrath, the girl was ashamed
and confused. She was sick at heart, too, with the significance of it,
the drawing down of the blind that had let in light for only a
fortnight out of twenty-odd years. But she fled precipitately, pausing
only to send Bell in to her mistress. And she believed herself to be
leaving the house forever.
 CHAPTER XVIII
ON the day following her second meeting with the stranger who
called himself John Converse, Alice Lorraine was in a sad state of
mind when she reached the lane. She had to see the man again.
She told herself that ordinary civility as well as her own desire
demanded that. Chance had brought them together and put upon
her the duty of aiding him so far as possible in looking up old
associations without making himself known in the village of his birth
and boyhood. She had somehow lost her head and become involved
in a warm dispute. That made it hard for her to act to-day. But she
told herself that she was not going back as the girl who had been
vehement over—nothing! She was simply going to meet John
Converse (for the last time, probably) in the odd little shop, give him
such information as she was able, and if he should wish, help him
plan his course of action. Then they would part in the polite way of
people who have become acquainted in the course of a long railway
journey and offered one another kindly civilities.
It would be simple enough, she told herself, if she could only
remember that he belonged to an older generation. He didn’t look
young and he couldn’t be, with a memory reaching back as far as his
did. It was only his sad eyes which could become so merry and the
whimsical smile that transformed his gaunt face that had made her
feel as if he were a companion of her own years.
As the girl stole around the cottage towards the path leading to the
shop, John Converse rose quickly from the step of the back porch
and joined her. He held out his hand eagerly and she put hers shyly
into it, her face expressing the relief she felt to find that he was not
resentful. She realised now that she had feared that if he were about
at all he would be stiff and cold.
“I was afraid you wouldn’t come,” he said with a frank smile. “I have
had a nasty night, I can tell you. And now I want to explain to you
right away what must have seemed to you inexcusable behaviour.
Shall we sit down here?”
Alice thought of his safety. And she suggested that they might as
well go into the shop. As they entered, she noted that there was a
fire and the same preparations for tea he had made the day before.
He took her jacket, made her comfortable, prepared the tea and
served her. Alice, with a sense of relief that was like happiness,
leaned back in her chair and watched him admiringly. She had never
known a man to be so deft, and gazing at his hands she noticed
that, though the skin was hard and rough and they must have done
the work of a labourer, they were the long, sensitive, slender hands
of the sculptor or musician—probably the latter. And suddenly her
lips puckered in an involuntary smile.
“What pleases you, if I may ask?” he said wonderingly. He himself
was very serious,—sad, almost. There was no hint now of the
whimsicality that made him so young—nor of the youthful
impulsiveness with which he had met her to-day.
Alice looked into his eyes ingenuously. “I wouldn’t dare tell anyone
else of the thought that came to me and made me smile,” she
declared. “They would mob me, I am quite sure. You see everyone
in this village—or everyone I happen to know—is simply mad about
Reuben Cartwright. Honestly, I believe they consider him perfect—
incapable of doing anything that’s not exactly the right thing. And I
have heard so much raving about him that I believe I am catching
the madness, or whatever you call it. Just now as you were handling
the cups so skilfully it came suddenly to me that your hands were
like Reuben’s—and mind you, I never saw the boy!”
He did not smile. He only looked at her curiously. Then he sat down
opposite her.
“It wouldn’t be strange if they were alike,” he said quietly. “It’s odd,
but you have led up to the explanation I was about to make. I feel,
Miss Lorraine, that I owe it to you to tell you who I really am. You
trusted me without a shred of evidence of my integrity, and you
granted my wish for secrecy. I ought to have told you, anyhow. But
having lost my temper and made shockingly uncivil remarks to you, I
cannot do otherwise. The reason I fired up when you were ready to
believe ill—the worst—of Dick Cartwright is the same reason that
Reuben Cartwright’s hands and mine may look alike, though I trust
his aren’t so calloused and generally bunged up. I am Reuben
Cartwright’s father.”
It wasn’t, of course, the same shock to Alice Lorraine the
announcement would have been to one who had known Richard
Cartwright or his son Reuben. But the girl paled.
“But I thought he was dead—you, I mean,” she said so naively that
he smiled.
“I may be lean and lank, but I am a right husky ghost for all that,”
he said. Then he grew serious. “You were right in thinking so. I
wanted everyone to believe me dead, and now I feel the same,
except for you. It wasn’t only because I wouldn’t seem so rude if
you understood that I wanted you to know, Miss Lorraine; but you
seemed to think I was such a bad lot that I wanted you to know the
truth. Not that I wasn’t a bad lot, you know, only I wasn’t quite such
a scoundrel as you apparently think. Do you mind telling me just
what impression Mr. Langley gave you of me? I believe under the
circumstances you have the right to speak freely.”
Alice complied briefly. Cartwright wiped his brow more than once.
“I went through a lot for nothing, then,” he said almost bitterly. “If I
had given my real name, I could have gotten off; but I feared the
notoriety for Reuben and took the name of a man that was killed, for
the sake of giving him mine and having Reuben’s father die a
comparatively decent death instead of being a convict. I was on that
train but the only thing wrong about my being there was that I
didn’t pay my fare. I was a tramp at that time and another tramp
and I were riding the bumpers—he initiated me into the mysteries of
the practise. He was killed and in the confusion of the wreck I was
arrested as one of the gang that was responsible for it and for the
deaths of the mail clerk and engineer. They couldn’t prove anything,
but circumstantial evidence implicated me as an accessory. My one
hope of clearing myself would have been to establish my identity as
Richard Cartwright, which, as I said, I did not choose to do.
Wherefore I landed in the penitentiary.”
The girl gave a little involuntary, startled, deprecating cry. Richard
Cartwright faced her almost sternly with folded arms.
“You have been there—not ever since?” she protested. He told her
that he had served two years of a sentence of five when the
confession of a member of the gang who died of consumption had
freed him.
“But why didn’t you come back here then?” she cried.
“If you could have seen me the day after I left the prison, you
wouldn’t ask,” he said bitterly. “I became a bum on the spot. I
deliberately took up the drink habit again and became a drunkard
and a tramp. I kept at it for three years—years that are almost a
blank to me now. Then something happened—I don’t know what it
was—that set me thinking of Reuben and Farleigh and Russell
Langley and I decided to stop long enough to put myself into shape
to come East and see if they were alive and how things were going
on and all that. That was nearly a year ago. I stopped drinking, went
to work, earned and saved money enough to clothe myself decently
and to take this sight-seeing trip, and—here I am.”
Again he wiped his damp brow with his pocket handkerchief and
looked at the girl—defiantly, bitterly, yet deprecatingly and wistfully.
“But why don’t you stay, now?” she cried. “And why don’t you see
Mr. Langley and Reuben? Though I know Reuben only by hearsay, I
know enough of him to know that he would be—crazy to see you.”
She smiled tremulously. “He’s the faithful sort, if I’m not,” she said.
“O Miss Lorraine, don’t hit a fellow who’s down,” he begged.
“But you will—you will stay and—you will see them, Reuben and Mr.
Langley?”
“No, Miss Lorraine, I cannot stay. And I’ll see them, but I won’t let
them see me and I will remain dead to everyone but you just the
same. I will roam about dear old Farleigh and see the changes, and I
won’t hurry, but—I’ll go back presently. This is only a vacation,—a
sight-seeing trip on the part of John Converse.”
“Back to what?” asked the girl imperiously.
“Back to being a good, honest day-labourer, if you say so, Miss
Lorraine,” he assured her.
“Well, but I don’t say so,” she retorted. “I want you to be a musician.
I want you to have your old house back and to build——”
Her voice broke. He was silent a little. Then he reached forth his
hard, beautifully shaped hands.
“Look at those—hoofs! On nearer view do they look like a
musician’s?” he asked.
“The hands do and you could easily soften the skin,” she declared.
“I learned cobbling in prison and did it for two years,” he remarked,
and the girl paled sensitively, and her eyes fell.
“And my job now is work in a shoe factory, and so it must be for
——”
“So it must not! No such thing!” she interrupted.
He smiled at her fire, and she thought he was ready to be
persuaded. And for some little time, Alice Lorraine urged him to alter
what she found to be a bitterly fixed determination. But she was still
shaken and confused by the excitement and emotion she had
undergone, and presently she gave over for the moment, feeling
that she could do better by waiting until she should have pondered
over the matter alone. However, she secured his promise not to
return to the West without letting her know nor without seeing her.
By that time it was late and agreeing to meet him the next day, she
took leave.
The next day Dick Cartwright told her that he had decided to remain
hereabouts for a fortnight if he was lucky enough to escape
detection, after which he would go to the town where Reuben was
attending college, preferring to see him there rather than in Farleigh
at the Christmas holidays. Then he would stop here and tell her
about it on his way West. He begged her earnestly not to try to
dissuade him. His purpose was fixed, and it only caused him intense
pain to have her attempt to alter it.
Warm-hearted Alice agreed to desist temporarily at least and to help
make his days in Farleigh successful whether they were only holidays
or, as she continued secretly to hope, the beginning of a second
residence. She learned all she could about Reuben to relate to his
father when she met him, which was daily except when Alice was
prevented from getting away, which happened only twice. She told
him something more of Mr. Langley almost every time she saw him
and learned the history of every person he mentioned any desire to
know about. She helped him plan his nightly wanderings about the
place, shared one of them and listened eagerly to what he told her
of his experiences. She even managed to get him into the church
one Sunday afternoon and to coax him to play a few bars on the
familiar organ, the sight of which brought tears to his eyes. At
moments when they were in good spirits they called themselves a
pair of conspirators and wondered at the success which attended
Dick Cartwright. For Alice assured him again and again that no one
dreamed of there being any stranger in the place.
The days flew over Alice Lorraine’s head, her only regret being that
she had no opportunity to plead with Dick Cartwright to reconsider
his resolve. At home, as was perhaps not unnatural, she appeared
nervous and was ready to be irritable as she had never been before.
She was careless of others and remiss in her duties. And yet she was
not utterly so. For a new feeling for her father had been aroused in
her, a pity and sympathy the girl could never have experienced
otherwise. She thought much of him and wrote him two long letters
in the fortnight that elapsed before Dick Cartwright left Farleigh to
go in search of Reuben.
On the night he was to leave, Alice, who was supposed to be in her
room whither she had withdrawn early, met him at a point in the
South Hollow which they had agreed upon. She entreated him to
make himself known to his son and let him help make the final
decision, but Cartwright was adamant.
“I couldn’t explain to Reuben without letting him know that I have
been in prison,” he finally explained reluctantly and quite as if that
ended the argument.
“Yes, but innocently!” she cried.
“That makes little difference. I would rather die than have Reuben
know he is the son of one who has been a prisoner,” he declared
proudly.
Alice withdrew her arm from his. “You think it so terrible a stigma as
all that, Mr. Cartwright?” she demanded.
“I would rather die than have Reuben know it,” he repeated warmly.
“My father is in prison now!” she cried. “And he—he is—he isn’t
innocent!”
 CHAPTER XIX
“WE’RE goin’ to have a green Christmas, sure’s you’re born,”
remarked the usually stolid and reticent Bell Adams. “I only hope the
rest of it don’t follow. Dear me, if that delicate motherless baby
should be took!”
“Bell Adams, I don’t know what you mean, talking like that to me,”
cried her mistress. “Just because I’ve forced myself to endure the
strong light and have changed a little outwardly, you treat me as if I
were as well and strong as anyone. You used to be so careful, Bell.”
That was quite true,—also that Bell had borne herself differently of
late. She had not, as a matter of fact, been the same woman since
the visit of Anna Miller and Joe, Junior, when she had held the baby
in her arms. And since she had in some manner come to understand
that the child had been offered to the household and refused by Mrs.
Langley, she had been so thoroughly indignant that she could
scarcely speak to her mistress. But silence being her usual role, it
was only when her anger had cooled into sulkiness that Mrs. Langley
felt and resented the strangeness of her demeanour.
“And why you should pick out that little innocent baby—” Mrs.
Langley went on in an aggrieved voice.
“I ain’t a-pickin’ of him out,” retorted Bell. “If anybody’s doin’ that it’s
the Lord, and if He’s marked him out for early death, why, there you
are. And anyways, the little mite hasn’t no real home, so to speak.
And he’s too bright to grow up. He ought to be tenderly cherished
with that bulgin’ forehead, and his speakin’ out so sudden and
complete wasn’t natural.”
Mrs. Langley was too affected to reply. Bell hastened back to the
kitchen, for it was the day before Christmas and she was deep in
preparation.
Ten minutes passed and a shadow fell across her table. Bell looked
up in amazement to see her mistress before her. Mrs. Langley had
not left her room for years, and Bell was really frightened.
“For the dear sake, Mis’ Langley, you out of your head?” she cried.
“No, Bell, but I felt upset. I wish you would come in and sit with me
for a little, but you must be quiet. I don’t want you to say a word.
You stirred me all up with your chatter about green Christmases.”
“But ma’am, I’m makin’ cranberry jell, and I must get this mince pie
into the oven for Mr. Langley’s Christmas dinner,” returned Bell.
She glanced at her mistress out of the tail of her eye, and,
apparently deciding that she could go further with impunity, added:
“It’s bad enough as it is, him a-eatin’ of it all alone.”
Mrs. Langley flushed. That woman was getting unbearable.
“If you pity Mr. Langley, I should like to know what you think of me,
Bell Adams?” she cried. “I must not only eat alone but I am forced
to remain alone all the time and to suffer constant pain.”
“Yes’m, I know,” Bell relented. “’Tis hard, dear knows. And yet, men
are different from we women, and sometimes I mistrust they suffer
as much from bein’ lonesome as we do from real pain. And then of
course he’s been as good as a widower all these years and——”
“Bell Adams——”
“O, ma’am, you ought not to be standin’ and in this hot kitchin and
like a summer day outside and the twenty-fourth day of December.
Now why don’t you go into the front room and set a spell and watch
the folks go by? They’s a lot of passin’ the day before Christmas, and
you can see way to the post office now that the leaves is off. Rusty
Miller’s home, they say, and you may see her. You’ll know her by her
red hair. Everybody mistrusted she’d come home from college with it
done up in a p’siky but it seems she ain’t.”
Mrs. Langley was tempted by her suggestion. It didn’t seem as if she
could go back to her room and think about green Christmases and
that over-bright baby and Mr. Langley’s having been like a widower
all these years. Wherefore, when Bell went before and led her to the
at once familiar and strange room, she followed and allowed herself
to be established comfortably in a big chair before the low window.
She had not been there ten minutes when she was secretly blaming
Bell for not having thought of this before. Indeed, if it had not been
for haunting thoughts of Anna and the baby, she would have been
quite comfortable. It occurred to her that Joe, Junior, would like to
be sitting on her lap looking out the window with her. There was a
Newfoundland dog—she wondered if he would know what it was
and say bow-wow?
As a matter of fact Joe, Junior, was saying bow-wow to every dog he
saw that afternoon, thereby nearly convulsing Freddy Miller who
walked at his side. The boys wheeled him all the way from the
Hollow to the post office in his new perambulator.
Rusty had brought it home with her as a Christmas present for her
sister. After she had gone away in the early autumn, Rusty had
begun to feel as if she had been less than fair to Anna. She had
been deeply impressed by her sister’s devotion to the baby and by
the sacrifice of her beautiful hair. It was like Rusty to desire to make
her atonement concrete, and she had saved all her pocket money
towards a Christmas present for Anna, expecting to get something
handsome in the way of jewelry or other personal adornment. But
when she had made secret enquiries of the family, no one knew of
anything that Anna really wanted, except that Frank suspected she
was saving her money for a perambulator for Joe, Junior.
Whereupon Rusty purchased an handsome carriage that was
convertible into a sleigh.
Anna had been overwhelmed with delight. The perambulator had
been placed in the parlour and covered by a sheet, that the baby
should not see it before Christmas day.
Against this, however, the boys had protested loudly. They declared
they wanted to be sure to use it before the runners should be put
on, and everyone said there was a storm due, and it would be too
mean for anything if they couldn’t try the wheels before April. The
baby was so little he wouldn’t know the difference, anyhow. But
Anna would not yield.
Reuben was to arrive at Wenham the day before Christmas, and
Rusty was to drive over to meet him with Miss Penny’s pony. It
occurred to her that morning to ask Anna to go with her.
Anna flushed to the roots of her dandelion hair, as Frank called it.
Then she remembered the baby and told Rusty she couldn’t leave
him.
“Ma’s got baking to do, and I couldn’t have her bothered, Rusty.”
“But he’ll sit on the floor and not be the least trouble,” urged her
sister.
“I don’t like to risk anything now, Rusty,” Anna confessed. “Ma didn’t
take to him at first, and now she’s begun to, I don’t want any
setback. I want him to live with us always, you see.”
“O, Anna, you’ll never have any more fun then,” protested Rusty.
“Junior’s all the fun I want,” returned Anna rather shyly.
“Well, anyhow, the boys can mind him this afternoon?”
“They could, but I don’t believe they will. Frank’s mad with me
because I won’t let him use the perambulator.”
Rusty appealed to her mother.
“I’m afraid it’s no use, Rusty,” returned Mrs. Miller. “Frank’s a good
boy, but when he gets a contrary streak, he isn’t to be coaxed. And I
shouldn’t like to make him mind the baby, for fear he might turn
against him, and it’s good for the boys to love him as they do now.
But I’ll look after him myself. He’s no trouble at all; he’s just
company for me.”
She sighed.
“I’m sorry I didn’t make more of him when he first came,” she
owned. “Anna won’t let me do anything for him except in school
hours, and I want her to get into the notion of leaving him to me
and getting out more herself. It was really for her sake that I sort of
hardened my heart against the baby in the first place,—I felt it was
too much for her.”
Rusty kissed her mother and said she would try to see what she
could do with Frank. She sought out her brother.
“Frank, you and Freddy’ll mind the baby while Anna goes to
Wenham with me to meet Reuben, won’t you?” she begged. “You
know I’ve been away so long you haven’t had a chance to do
anything for me for weeks and weeks.”
“Why Rusty Miller,” the boy exclaimed, “ain’t writing letters anything,
—with ink, too! It takes the whole evening, even if you begin the
minute the table cloth’s off.”
“Yes indeed, Frank, it’s a lot, and it’s a great comfort to get them,”
Rusty owned, “but answer me quick so that Anna can change her
dress before dinner. And I’ll tell Reuben how good you are.”
“Fred and me was going to the post office to see the Christmas mail
come in,” objected Frank. “Anna won’t let us haul Joe in our cart so
far as that on account of the bumps, but if you’ll let us take the
perambulator we’ll mind him dandy.”
Rusty argued with him but found that her mother was right, and
presently yielded.
“Well, do take it,” she said, “only wait until we’re out of the way. I’ll
tell Anna, but be sure she doesn’t know it to-morrow. Wipe the
wheels all off as soon as you get back.”
She and Anna went away directly after dinner in order to wander
about Wenham and see the Christmas decorations before time for
Reuben’s train. Shortly afterwards, Mrs. Miller got the baby into his
wraps and put him into the perambulator. The child looked at the
new equipage with interest and approval and settled himself
comfortably among the cushions with an expression that was almost
eager. Mrs. Miller kissed him.
“Frank, don’t you feel a little ashamed when Anna’s so good to you
to be doing just what she doesn’t want you to?” she asked.
Frank looked rather sheepish.
But Joe, Junior, was almost smiling.
“Well, perhaps one day won’t make any great difference,” Mrs. Miller
admitted indulgently.
“Say Go, baby,” urged Frank, and the child complied instantly.
“Now don’t hurry,” cautioned their mother. “And Freddy, don’t dance
up and down that way. It’s long enough there and back if you just
walk without any capers. And besides, if you jump about too much
that safety pin will give and your stocking will be all down around
your foot.”
Of course Freddy forgot the warning. Joe, Junior, repeating Go, go,
Freddy was in an ecstasy, and was hardly out of sight before his
stocking was trailing in the dust. The day being unseasonably warm
he rather liked it so, and didn’t mind the halting gait it induced. But
Frank objected to the latter, and drawing the stocking up over the
little boy’s trousers, fastened it securely if not elegantly with the
safety pin. Whereupon they rushed on and reached the post office
an hour before the mail was due.
After a little the elder brother went inside, cautioning the younger
not to wheel the carriage while he was gone. When Freddy grew
tired of waiting, he moved it, pushing it sidewise, and went in to tell
Frank that the sun was shining right into the baby’s eyes, and
couldn’t he just wheel him into the shade?
But when he entered, the post master was telling his brother how
many parcels had come on the stage a year ago on the twenty-
fourth of December, and what he calculated would have been their
combined weight in pounds. He put it to Frank how many ounces
that would be, and Freddy stood spell-bound while his brother
computed it ‘in his head.’ Further delay was occasioned by the fact
that Frank got his answer according to the avoirdupois scale and had
to be reminded that he should have used the Troy, and to multiply
all over by sixteen, which was more difficult than reckoning by the
dozen.
When finally the matter was settled, the little boy put his request.
“Of course, silly,” returned Frank, and went on talking with the post
master. Presently Freddy returned.
“He ain’t there,” he said in a dazed way.
“What you givin’ us?” demanded his brother.
Freddy burst into tears. “He ain’t there, cross my neck, Frank.
Nothin’ but a pillow,” he declared, “O, O, the bears must ’a eat him
up!”
Frank rushed out. The perambulator was indeed empty. For an
instant he stared at it in amazement. Then he decided it was a trick
of some of the boys in Farleigh and tiptoed about peering into all
possible and impossible corners and hiding-places. But there was no
one in sight.
 CHAPTER XX
SETH MILLER returned home shortly after the boys. Greatly alarmed,
he rushed over to Miss Penny’s and frightened her still more. But
Mrs. Lorraine spoke calmly and suggested that he get Walter Phelps
to drive him over to the post office, enquiring all the way, and if he
did not find the baby meantime, someone in the crowd collected for
the mail would be sure to have tidings of him.
The stage was late and they reached the post office just as it drove
up. Anna stepped out, white and anxious. She had learned the news
at Wenham just in time to catch the coach.
The girl did not lose an instant. She consulted the post master who
had enquired of everyone who had come in. He had no information
to offer. Her father had stopped at every house except the
parsonage, Miss Penny having cautioned him not to go there
because of the invalid. Wherefore Seth Miller supposed that they had
better be working over Wenham way.
But Anna decided otherwise. Asking Walter to remain at the post
office for possible tidings, she had her father drive her to the
parsonage. Three minutes after she had let herself quietly in, she
came running out to the buggy.
“Mrs. Langley’s gone, too,” she said. “Dear me, isn’t it great luck that
Mr. Langley’s way at the further end of the Hollow? We met him, and
I suppose he’s talking school business with Mr. Phillips. He’d be
perfectly crazy, you know.”
She climbed into the buggy.
“Did you look in the garret?” her father enquired.
“I don’t know about that, but Bell went everywhere else,” Anna
returned. Her father stared at her for she seemed less anxious.
“Anna, someone may have kidnapped the two of ’em,” he said
hoarsely. “I don’t know as you have heard, but they do say there’s a
strange man around the village peering in windows at night and the
like.”
Anna almost laughed. “They’d bring Mrs. Langley back when daylight
came,” she returned flippantly.
She directed her father to drive down the Wenham road, beyond the
house where they had lived when the boys were babies, to the
bridge and to watch from there, dropping her at a point she would
indicate.
“Give me your bandana,” she ordered. “Now, Pa, if you see me
waving it, you come straight towards it as far as you can come with
a horse and wait. I’m going cross lots but you may see me later
against the western sky line.”
“O Anna, I don’t dare have you go off alone away from beaten
tracks with strange men and kidnappers about,” he protested. “Let
me hitch the horse and go with you.”
But Anna laughed, reassured him, and disappeared. Making a bit of
detour to avoid being seen, she headed for the cemetery. Anxious
still, she was nevertheless relieved, and once on the direct path, ran
all the way, leaping ditches, pushing through underbrush and taking
the steepest part of the bank as if it were a plain. When she reached
the top, she was hot and breathless. Throwing her jacket on top of
the wall, she vaulted it lightly and made for a point whence she
could see the Langley lot. Even while she caught her breath and
wondered if she should dare look, she heard a little familiar sound.
The girl stopped short. For a second she could not move. The
complete relief from suspense was so great that she had to choke
back her tears. For there they were, just where she hard hardly
dared to think of them as being, Mrs. Langley wrapped in a gay old-
fashioned paisley shawl with her head uncovered, sitting on the
ground with Joe, Junior, in her lap. The baby was fondling the little
marble image and murmuring baa-baa, the while Mrs. Langley
looked on as if she were in Paradise.
As she stole towards the little group and stood before them, Anna
was unaware that tears were streaming down her cheeks. The baby
saw her first and smiled. “Baa-baa” he cried out stretching out his
hands, and Mrs. Langley looked up quickly. Her expression changed
instantly from beatitude to deep guilt.
“You said you would give him to me for a Christmas present,
anyhow, Anna,” she declared, half defiantly, half-entreatingly.
“Yes, but you didn’t—take him,” gasped Anna dropping down beside
them. She was hugging Joe, Junior, but she did not take him into her
arms.
“I’m sorry I didn’t. I’ve been sorry ever since. But you took me so by
surprise. Of course I really wanted him when I could straighten out
my thoughts.”
“We have all been frightened nearly to death thinking the little fellow
was lost,” Anna remarked reproachfully.
“I didn’t think of that,” Mrs. Langley returned meekly, stroking the
baby’s little hand. “I saw him go by and I wanted to see him so
badly that I got my shawl and followed as far as the post office. He
was all alone and so near the road that a horse might have run over
him if it shied. Really, Anna, I was just meaning to stand by him until
your brothers came out; but he reached out his little hands and I
had to take him—he knew me, you see. For he said Baa-baa, and it
seemed as if he was asking me to bring him to see this little lamb;
and as I wanted to see it myself, I brought him up here.”
“Brought him up here!” exclaimed Anna suddenly realizing the
magnitude of the action. “How in this world did you ever do it?”
“I don’t know, I’m sure, but he didn’t seem heavy. He’s so still, I
suppose. I didn’t mean to stay at all, but it is so warm and pleasant;
and baby has been so happy that I forgot everything else.”
Meanwhile, Seth Miller had driven out to the bridge and waited,
talking the while to the Phelps horse which, like most of the horses
in the village, was a great pet and like one of the family. Presently
he caught a flash of red among the pines on the hill, saw his
daughter waving to him, and drove on until he saw her waiting at
the lower gate of the cemetery with the baby and a strange, foreign-
looking woman whom he took to be a gypsy who had probably been
carrying the baby away when Anna caught her. Again and again that
night at home he exclaimed over his surprise to think that the old
and faded woman with the piercing black eyes who might have been
a gypsy crone was none other than the handsome Mr. Langley’s
wife. And yet he granted she was pleasant-spoken and the baby
seemed to take to her amazingly and he only hoped she wasn’t out
of her head.
Anna got out with Mrs. Langley at the parsonage and asked her
father to bring the baby in. Seth Miller held the baby close,
whispering to him and lengthening the inconsiderable distance by
crawling along, the while Anna explained that she would have to go
in for a little and asked him to stop at Miss Penny’s with the news
and have someone come for her with the pony later.
“And pa, if you see Mr. Langley, send him home right away,” she
added eagerly. “Or—if you happen to hear where he is, do go get
him and bring him home.”

Seth Miller did not meet Mr. Langley, however, nor could he learn
where he was except that he wasn’t in the Hollow. As a matter of
fact Mr. Langley was engaged in an affair of some moment.
He had left the parsonage early in the afternoon. Directly after
dinner, an informal, self-constituted committee of three men living in
the Farleigh end of the village had waited on the minister in his
study. Though not taken wholly by surprise, he had been shocked
and distressed by the nature of their errand, even while he could not
but feel, as he assured them, that they acted within their rights. He
would have persuaded them to wait until after Christmas, but he
could not insist upon it. And he was grateful to them for coming to
him and allowing him to forestall their action so that it should be less
shockingly abrupt to those who must suffer thereby.
Hastening from the parsonage, he met Rusty and Anna Miller in the
phaeton driving the fat pony. As he had already seen Rusty, he only
greeted them in passing. And realising at once that they were on
their way to Wenham to meet Reuben, he was thankful to have
them out of the way for a good measure of time. His business was
with Alice Lorraine, and the fewer people he saw besides the girl
herself, the quicker might he dispatch it.
Unhappily, he did not find Alice at home. He looked so concerned
when Miss Penny told him that the girl had gone away for the
afternoon that Mrs. Lorraine was startled.
“Is it something serious, Mr. Langley?” she asked.
“Yes, Mrs. Lorraine, it is indeed. May I ask if it would be possible to
get your daughter within half an hour?”
Mrs. Lorraine feared not. Miss Penny made an excuse and went out.
As Mr. Langley resumed his chair, Mrs. Lorraine turned to him
despairingly.
“I haven’t the slightest idea where Alice is, Mr. Langley. She left the
house an hour ago. Anna and Rusty Miller came over just as we
were finishing dinner, and when we looked for Alice she was not to
be found.”
“May I ask if she went in the direction of Farleigh?”
“I hardly think she did, Mr. Langley. As a matter of fact, she
practically always starts out in that direction, but I do not think she
did to-day for if she had we should have seen her. Miss Penny and I
both happened to be where we saw everyone who passed over that
way for half an hour before we discovered she wasn’t in the house.”
“Then I shall have to trouble you, Mrs. Lorraine,” he said gravely. “I
am sorry. I would spare you if I could, but even if I had seen Miss
Lorraine first, you would have had to know presently. May I ask you,
in the first place, whether you have allowed anyone to occupy the
cottage in the lane since you and your daughter have been at Miss
Penny’s?”
“O no, Mr. Langley,” she declared so decisively that he frowned
unconsciously. “We might as well have given it up, only Alice thought
we should keep it until after Christmas. I suppose——”
But she could not go on. His expression disconcerted her.
“And the little building in the rear that is called the shop?” he asked.
“We never used that, anyhow,—never even looked into it, though I
believe we have the key.”
He picked up his gloves and looked inside as if to determine the size.
Then he looked at her.
“Three men came to me this noon about a matter that has been
troubling the village for some little time and which now seems to
them to be approaching a crisis,” he began. “This is the situation,
Mrs. Lorraine. There has been a strange man around for—it must be
upwards of three weeks now. One person and another has caught
sight of him at night, and he seems to have looked into the windows
of nearly every house in Farleigh. It may be imagination in some
cases, but before I had heard anything about the stranger, I felt
quite sure one night that there was someone peering in at my study
window, and I certainly saw someone slink away from another
window at the parsonage about a fortnight since. Someone saw the
figure of a man pass across the window in the organ loft at the
church one Sunday afternoon, and there have been other similar
things—not of great moment when taken separately but which
collectively seem to these men and others to constitute a menace to
public safety.”
“But Mr. Langley, what has that to do with my—with the cottage in
the lane?” she enquired with a sharp note of pain in her voice.
“They seem to think that the man has hidden there the while.
Smoke has been seen a number of times coming from the chimney
of the little shop. At first people explained it by saying that Miss
Lorraine probably had gone down to fetch something and had made
a fire to take off the chill, but lately one thing and another has led
them to suspect that that isn’t the right explanation.”
“I have heard of tramps occupying deserted houses,” she remarked.
He had nothing to say. She grew very white. “Did you ask for Alice
simply to spare me, Mr. Langley?” she asked.
“No, Mrs. Lorraine,” he replied reluctantly, “it was because I hoped
she might be able to throw some light upon the matter. It appears
almost certain that she knows something about this mystery in our
midst. She has been seen more or less about the lane, and—I don’t
credit the particular rumor people have patched up, but——”
“And what is that, Mr. Langley?” she broke in breathlessly.
“They think Alice’s father—that Mr. Lorraine is hereabout—that he
has been staying in the shop behind the cottage and that his
daughter carries him food and visits him daily.”
For a few seconds, Mrs. Lorraine was too dazed to speak. Alice’s
strange conduct seemed to accord with this tale, and yet—she rallied
her forces. It was impossible.
“Alice hears from her father. She had a letter only a day or two ago,”
she declared. But even as she spoke, she realised that that wasn’t
valid evidence. She knit her brows, then looked up. “But Mr. Langley,
if Mr. Lorraine had escaped, why wouldn’t it have been in the
papers?” she demanded. “You say this has been going on over three
weeks, and—Mr. Lorraine was—well-known.”
“I said something of the sort to these gentlemen,” he returned.
“They claimed that such an escape is often kept secret for a time for
strategical reasons. But irrespective of that, there is no doubt that
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebookfinal.com