Visit https://ebooknice.

com to download the full version and

explore more ebooks

(Ebook) Object-oriented software engineering : using

UML, Patterns, and Java by Bruegge, Bernd; Dutoit,
Allen H. ISBN 9781292024011, 1292024011

_____ Click the link below to download _____

https://ebooknice.com/product/object-oriented-software-
engineering-using-uml-patterns-and-java-7113000

Explore and download more ebooks at ebooknice.com

Here are some recommended products that might interest you.
You can download now and explore!

(Ebook) Object-Oriented Software Engineering: Using UML,

Patterns and Java (2nd Edition) by Bernd Bruegge, Allen H.
Dutoit ISBN 9780130471109, 0130471100
https://ebooknice.com/product/object-oriented-software-engineering-
using-uml-patterns-and-java-2nd-edition-1407332

ebooknice.com

(Ebook) Biota Grow 2C gather 2C cook by Loucas, Jason;

Viles, James ISBN 9781459699816, 9781743365571,
9781925268492, 1459699815, 1743365578, 1925268497
https://ebooknice.com/product/biota-grow-2c-gather-2c-cook-6661374

ebooknice.com

(Ebook) Matematik 5000+ Kurs 2c Lärobok by Lena

Alfredsson, Hans Heikne, Sanna Bodemyr ISBN 9789127456600,
9127456609
https://ebooknice.com/product/matematik-5000-kurs-2c-larobok-23848312

ebooknice.com

(Ebook) SAT II Success MATH 1C and 2C 2002 (Peterson's SAT

II Success) by Peterson's ISBN 9780768906677, 0768906679

https://ebooknice.com/product/sat-ii-success-
math-1c-and-2c-2002-peterson-s-sat-ii-success-1722018

ebooknice.com
(Ebook) Master SAT II Math 1c and 2c 4th ed (Arco Master
the SAT Subject Test: Math Levels 1 & 2) by Arco ISBN
9780768923049, 0768923042
https://ebooknice.com/product/master-sat-ii-math-1c-and-2c-4th-ed-
arco-master-the-sat-subject-test-math-levels-1-2-2326094

ebooknice.com

(Ebook) Cambridge IGCSE and O Level History Workbook 2C -

Depth Study: the United States, 1919-41 2nd Edition by
Benjamin Harrison ISBN 9781398375147, 9781398375048,
1398375144, 1398375047
https://ebooknice.com/product/cambridge-igcse-and-o-level-history-
workbook-2c-depth-study-the-united-states-1919-41-2nd-edition-53538044

ebooknice.com

(Ebook) Object-Oriented Software Engineering: Practical

Software Development using UML and Java by Timothy
Lethbridge, Robert Laganiere ISBN 9780072834956,
0072834951
https://ebooknice.com/product/object-oriented-software-engineering-
practical-software-development-using-uml-and-java-2450308

ebooknice.com

(Ebook) Object-oriented software development using Java:

principles, patterns, and frameworks / by Xiaoping Jia.
ISBN 9780201737332, 0201737337
https://ebooknice.com/product/object-oriented-software-development-
using-java-principles-patterns-and-frameworks-12073598

ebooknice.com

(Ebook) Developing Software with UML: Object-Oriented

Analysis and Design in Practice (2nd Edition) by Bernd
Oestereich ISBN 9780201756036, 020175603X
https://ebooknice.com/product/developing-software-with-uml-object-
oriented-analysis-and-design-in-practice-2nd-edition-2391136

ebooknice.com
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
thread when contraction takes place after the web comes through
the press rolls.
The feature which is aimed at, and which is most desirable in the
appearance of such goods, is a clean cut prominent rib at the rubber
line, and the avoidance of a flat paper-like look and feel of the web
generally. The prominence of the rib varies, of course, according to
the size of the rubber thread used, and the binder warp employed in
dividing the same, but even the very best of conditions may be
spoiled if proper care is not taken to get all the prominence of rib
possible. Use as fine a binder warp as is practicable, compensating
for any loss of weight or excess of contraction by using a heavier
gut, which again of itself helps to fill in the rubber cavity and thereby
lends additional prominence to the rib. All the weight possible should
be carried on the binder warp up to a point of safety, and care should
be taken to get a very easy, uniform delivery of the warp from the
beam so as to avoid any erratic jerky movement of the warp lever.
The warp beams which are used on this delicate type of work
should be well balanced and true to center, and the flanges free from
any irregularity which would in any way interfere with the easy and
uniform operation of the warp lever.
The gut, which weaves in with the rubber thread, is used for the
two-fold purpose of giving additional body to the fabric and of
regulating in a measure the length of stretch in the goods. The more
gut there is used, the less becomes the power of contraction of the
rubber warp, and the shorter the stretch produced.
Aside from the fineness and body of the goods, the element of
stretch largely governs the market value of the fabric, so that good
judgment and great care must be exercised in the assembling of the
different sizes of yarns used. Weft, binder and gut all play their part
in the governing of the stretch, as also does the number of picks put
in the goods. Any excess of weight on the binder warp also
materially reduces the stretch. In fact, any one of these features,
wrongly adjusted, may result in the difference between the profit and
loss.
 In making the selvage of these goods a hard steel wire is used,
around which the filling passes at each pick. This wire, shown at W
in Fig. 6A, is highly tempered piano wire, of the very best quality
obtainable. Sharpened to a needle point at one end, with a loop
turned at the other end, it is fastened at the back of the loom by a
cord which has an adjustable slip knot, so as to be able easily and
quickly to regulate the length of wire running in the web. It is then
passed through a harness heddle eye on the rubber or gut shaft, and
through a reed space next outside the selvage rubber thread. The
constant wear of this wire on the reed dent makes it necessary to
have this dent of hardened steel so as to withstand the constant
wear of the wire, which is always being crowded against the dent by
the nipping action of the filling as it draws against the wire in the
process of weaving, and the repeated beat at the same place in the
dent at the weaving line. In any event, after a short time the dents in
the reed will be cut so that it becomes necessary to frequently
replace them with new ones, and for this reason it should be so
arranged that they can be easily and quickly removed from and
replaced in the reeds.

The Lisle Web

The lisle web, being perfectly plain, is similar in general character
to the loom web, except that it is made with high grade combed and
gassed yarns for the filling in place of cheaper stock used on the
loom webs, and is woven with four threads for the binder warp
between each strand of rubber, instead of two as in the loom web.
The harness draft of the one-half inch lisle web shown at Fig. 7,
together with the weave, is shown at Fig. 7A. The construction is as
follows: Binder, 36 ends 80/2; gut, 8 ends 40/2; rubber, 10 ends 32s;
reed, 21 dent; picks, 78 per inch; stretch, 75 per cent.
It will be seen that all the binder threads operate two up and two
down, but change at each pick in rotation, making the repeat every
four picks of the loom. In a weave of this character the changes of
the harness are distributed uniformly at each pick, thus making it
much easier to get uniform conditions on each selvage. It differs
from the loom web in this respect, where the alternating light and
heavy pick has to be contended with.
Like the loom webs, prominence of the rib over the rubber thread
is the main feature aimed at in the general appearance of the fabrics,
and therefore everything possible should be done which will
emphasize this. The binder warp must be of fine yarns, and the warp
must be weighted so as to cut the warp line down sharp and clear up
to a point of safety, being careful at the same time not to go to
excess so as to narrow in the goods or cause undue chafing of the
rubber warp. The yarn most generally used for filling is 26-2 comber
and gassed high grade stock, of about 15 turns per inch. It should be
a well-rounded lofty yarn so as to obtain all the covering property
possible. It should be spun with the utmost uniformity, as the
slightest irregularity in the yarn will be noticeable in the goods.
The dyeing and bleaching of the yarn used for filling is also of the
greatest importance. It is not an unusual occurrence to find
otherwise perfect goods made unmarketable as first class by the use
of a filling yarn which has not been properly processed. This faulty
condition of the yarn may be caused in a variety of ways; such as an
irregular boil, poor circulation of liquor in the kier, irregular drying,
etc. Even when the color appears to be perfect, poor processing will
often prevent the smooth running of the yarn from the shuttle,
causing it to drag and thus create irregular and crooked selvages
which result in the repeated breaking of the selvage rubber threads
and ruin the goods.
The many difficulties of this character which were encountered
when skein yarn was more generally used for filling led to the
introduction and almost general use of warp yarns for filling
purposes, inasmuch as the method of processing the warp yarns
gives results which are not nearly so variable. Furthermore the long
unbroken runs of thread obtainable by quilling avoid the many knots
which are present when using skein yarn. Knots are unsightly and
objectionable when appearing on the face of the goods.
Chafed and broken edge rubber threads, however, are not always
the result of the conditions named, by any means, but may be
caused by a variety of other things. Not infrequently the edge wire
may be weaving too long in the web so as not to draw out freely.
Sometimes it may be a bent wire that causes the trouble, or it may
be the rubber rolling around the wire. Many times defects are caused
by the edge wire having cut into the dent, so that it has a file-like
effect as the rubber thread passes by in weaving. All these things
require looking into, and when trouble comes the cause should be
found and not guessed at.

French Web or Railroad Weave

Another plain web which has attained considerable popularity, and
which is a kind of intermediate grade between the loom web and the
lisle, is what is known as the French web or railroad weave, shown
at Fig. 8. In almost all respects the general treatment of this web is
the same as already described, and it differs only in the draft, which
is shown at Fig. 8A. It allows for the use of a somewhat finer yarn
than is generally employed in the loom web, and the draft changes at
every two cords, which gives it a peculiar “rowey” appearance from
which it derives the name of railroad weave.
There is one feature associated with all these plain webs which it
might be well to speak of. The high tension at which it is necessary
to work the rubber warp, together with the light weight required on
the cotton warp and the crowding together of the picking, creates a
tendency for the goods to rebound at the front reed, accompanied by
a backward and forward sliding movement when passing over the
rod at the breast beam. This movement is liable to polish the goods,
which is an objectionable feature. To counteract this it is advisable to
let the web pass over a small, felt-covered wood tube, which
revolves and responds to the movement of the bounding web. In this
way there is no friction to glaze or polish the web and interfere with
the bloom of the yarn. The same polish will occur as the goods pass
through the press rolls, unless they are felt covered.

Cable Web
 The most popular web now made up into men’s garters is what is
known as the cable web, shown at Fig. 9. With the pronounced
prominence of the two-dent rib, which gives it a character peculiarly
different from the plain web, it is well adapted to this class of goods.
Simple in appearance, it nevertheless requires special care to
manufacture, particularly when we remember that it is not unusual to
be required to make a finished stretch of not less than 100 per cent.
The harness draft and weave are shown at Fig. 9A. The construction
is as follows: Binder, 34 ends 80/2; Gut, 24 ends 20/2; Rubber, 18
ends 28s; Reed, 20 dent; Picks, 80 per inch; Stretch, 100 per cent.
The filling, floating across the wide spaces under which lie the
rubber threads in pairs, is very easily thrown out of place, the result
of which may be an unsightly seersucker appearance, as shown in
Fig. 10, which the process of finishing aggravates rather than
corrects.
Trouble may manifest itself by the filling over the ribs opening up
and allowing the gut threads to prick through. To prevent this
objectionable feature it is necessary to use a good quality of
moderately soft yarn for the gut, not necessarily of high grade stock,
but a yarn which is uniformly spun and not at all hard or wiry. As
these goods are being woven and on full stretch, the gut threads, of
course, are perfectly straight and accurate in line, but when
contraction takes place, to probably one-half the former length, these
heavy threads, which form probably about 25 per cent. of the weight
of the entire web, should bend or fold uniformly and dispose of
themselves in such a manner as not to appear in any way on the
face of the web, snugly housed away in the several pockets or
cavities. If the yarn composing these gut threads is spotty or
irregularly spun, this uniformity of fold inside the pockets will be
broken up and the appearance of the face of the goods is likely to be
marred by unsightly specks of cotton pricking through, which can be
both seen and felt.
 Chapter IV.
Elaboration of Honeycomb Effects by Parti-Dyed and Printed Fillings
—Bandage and Surgical Webs Made with Plain and Covered
Rubber—Frill Web Woven on Cam Looms—Double Cloths—
Importance of Securing Balance Between Back and Face of Goods
Among the group of single cloth webs confined to the capacity of
plain looms, is what is commonly known as the honeycomb, shown
at Fig. 1 and Fig. 1A. This is generally made with silk, wood silk, or
schappe filling. The smooth filling floating over two cords gives the
web a smooth feel, there being no rib effect noticeable whatever,
making it well adapted for a fine trade. The warp lines are almost
entirely hidden by the filling, so that it is not practicable to introduce
any sharp stripe fancy effects, which can be done both in the plain
web and the cable. The honeycomb is thus confined to plain solid
colors or such elaboration as can be obtained from the filling.
Fancy effects are often secured by dyeing skein yarn in two or
more colors. Such yarns when woven in the goods produce
alternating effects at regular distances in different colors, such
distances being governed by the length of the dips and the width of
the goods. The effects which can be produced are quite varied. The
simplest way of accomplishing this is to use the regular 54-inch
skein, having white or some light shade as a base, and then dyeing
a given portion of the skein another color. This process is carried out
by hanging the skeins on sticks placed in a rack at the required
distance above the color liquor, and then lowering them into the vat
and dyeing the immersed part in the usual manner.
Where cotton is used for the filling and more elaborate effects are
desired, long reeled skeins are used, sometimes 108 or 216 inches,
which have been reeled on specially designed collapsible reels.
Such skeins are not practicable to handle in the dye house in the
manner already described. Sections of such skeins are wrapped in
heavy waterproof paper and tied tightly, so that the dye liquor cannot
penetrate that portion, and then the whole is put in the liquor, when
the exposed part only will be dyed.
Then again sometimes wood clamps are used, like that shown at
Fig. 2, having a recess into which part of the skein is laid after being
carefully folded. The two halves are clamped together tightly in such
a manner that the dye cannot penetrate the clamped part of the
skein while the part left outside the clamp is dyed when the whole is
immersed in the dye liquor.

Printed Filling
Another form of elaboration used in such goods is printing the
skein yarn used for the filling. This is done by using a machine
having a pair of fluted brass printing rolls, one of which is made to
open on a hinge like a gate so that a skein of yarn can be put around
it. This roller is then closed to its original position, so that with the
two rollers parallel and close together, and the skein of yarn hugged
tightly between them, the turning of the rollers imprints color on the
skein. The skein is then taken out and dryed before spooling.
Different sets of rolls are used so as to get fine and coarse effects
and various colors are used in printing.
Where plaid or printed fillings are used for the elaboration of webs
of the honeycomb type, it is not unusual to introduce a couple of
plain cords in the center of the web, or possibly on either side, so as
to break up the flatness of the weave. This opens up the opportunity
of using lines of a different color in the warp which properly arranged
will produce a plaid-like effect.
 Fig. 1.—Honeycomb

Fig. 1A.—Harness Draft and Weave for Honeycomb.

 Fig. 2.—Clamp Used for Dying Parti-Colored Skeins

Bandage Webs
There is quite a large demand for surgical and bandage webs, Fig.
3, in widths ranging from 2 to 4 inches. These webs are used for
binding the limbs and other purposes and are in the pure white or
natural yarns. They require to be made with a long soft easy stretch.
An open reed of about 12 dents per inch is employed. Four threads
are generally used for the binder, weaving two up and two down. The
goods are similar in construction to a regular lisle web, except that
the gut is omitted in order to get the easiest possible movement.
 Fig. 3.—Bandage Webs; Fabric at Left Made with Plain Rubber; Web at Right
Made With Covered Rubber

The yarn is generally the same quality and size for both warp and
filling, and is usually a soft spun 2-20s. The side of rubber is
generally about 38 or 40, with 40 picks per inch and a finished
stretch of 100 per cent. The use such webs are put to, necessitating
as we have already said a soft and sluggish stretch, prevents the
use of a heavy rubber thread, the result being that when the
bandage is kept in close contact with the warm body, the life of the
fine rubber is of short duration.
This condition, and the open weave necessary to get the easy
stretch, have made it expedient to use in many of these goods
strands of rubber which have been covered with cotton threads
before weaving. This process not only prolongs the life of the web,
but allows for even more open weaving, the use of different weaves
than would be possible where the uncovered rubber thread is used,
and the production of a fabric more suitable for the purpose.
In order to get the soft easy stretch which is the most desirable
characteristic of a bandage web, and yet have the necessary width,
it is not unusual to introduce a seersucker effect, as shown in Fig. 4,
in sections of the web so as to reduce the strong elasticity of the
whole. In an ordinary cotton cloth the seersucker or crinkle effect is
usually produced by the use of a separate warp of heavier yarn than
the rest of the fabric, which warp must be weighted differently and
often a different weave is employed to emphasize the contrast in the
puckered seersucker effect.
In the elastic web all this special preparation is unnecessary.
Wherever the seersucker stripe is desired, strands of rubber are left
out which of course takes away from these portions that element
which contracts the other part of the web, and a seersucker effect is
the result. Such stripes are often used for the ornamentation of some
webs by having narrow sections introduced for border effects, or
running down the center, and in fact they may be employed in a
variety of ways, inasmuch as they lend themselves effectively to
different forms of coloring, in relief to the main fabric.

Fig. 4.—Seersucker Effect

 Fig. 5.—Frill Web Made on Cam Loom

Fig. 6.—Plain Web

Fig. 6A.—Harness Draft and Weave for Fig. 6, Simplest Form of Double Cloth

In passing it might be well to note that where it is necessary to use

covered rubber threads special arrangements are required for
making the warps, as the covered thread cannot be handled like the
ordinary thread. The spools are placed in a rack which is required for
each warp. Arrangements have been made so that to each spool is
attached a special head, which can be weighted either by a lever
brake or weight attached to a cord running in a groove on the
auxiliary head. By this arrangement uniform delivery of the threads
can be made to the warp beam so as to avoid any puckering caused
by irregular warping.

Frill Web on Cam Loom

In single cloth webs as already stated, the scope for ornamental
effects is necessarily limited. The bulk of such webs, particularly
those made with a wire edge, are for the most part plain. There is a
type of garter web, however, characterized as “frill” and shown at
Fig. 5, which may be made within the narrow limitation of cam looms,
although the frill feature is more generally used in connection with
more elaborate fancy effects.
The frill part is practically a section of non-elastic of any desired
width woven on to a section of elastic, which likewise may be of
variable width. The strands of rubber used in the central section,
being woven under tension, contract this portion of the fabric after it
leaves the press rolls. The side sections having no rubber in them do
not contract, but frill up uniformly on either side of the web in regular
fluted folds. No wire is required for the selvage when a frill is made,
and the tension of the filling is adjusted so as to hug the outside
threads of the frill warp and make a neat selvage without narrowing it
in beyond the width of the reed space occupied by the warp.
The frill part must be on a separate warp, apart from the binder
threads which are used in the central section. The elastic section is
made in the regular manner already described for webs of four
harness capacity. The frill is likewise constructed from the same
harnesses, but the draft is so arranged that two of the harnesses are
used for one frill and two for the other. This arrangement is made in
order that the filling may only be bound in alternating picks on the frill
part, whereas in the body it is bound at every pick. This method
makes the frill soft and pliable, so that it readily responds to the
contraction which takes place in the body part, and thus makes for
regularity in the formation of the folds.
 Should an exceptionally fine frill be desired, the same two
harnesses are used for the frill at either side, and the filling is bound
or woven in at each passage of the shuttle. Wherever this method is
employed, however, it becomes necessary to use a much finer yarn
for the frill warp, or a fewer number of threads spread over the front
reed in the frill. If such precautions are not taken the frill will be harsh
and stiff and will not fold uniformly as the center contracts. It may
even retard the desired contraction of the body.
It is not advisable in making frill webs to use a regular front reed
having the same spacing of dents all across. There is a liability of
getting a coarse looking frill, showing up the marks of the reed dents.
The plan more desirable is to use a reed with the dents required for
the frill part of the fabric spaced very much finer than those used for
the body, generally in the ratio of two to one, so that the frill threads
may be evenly distributed in ribbon-like formation and not show the
coarse lines of the dents.
Occasional calls are made for webs having a frill on one selvage
only. In this case it becomes necessary to use an edge wire on the
side having no frill, and exceptional care must be taken in this class
of goods to produce the proper balance. A soft frill is required and a
limited contraction of the body part.

Double Cloth Webs

Our remarks so far have been confined exclusively to single cloth
webs of a simple character, where, apart from the rubber and gut
there is only one warp used, and where both back and face of the
web are alike. We will now turn our attention to what are known as
double cloth webs, where two distinct cloths are woven, one for the
face and one for the back, each working independently of the other,
but tied together by another warp known as the binder, or else the
two cloths interlock each other in such a manner as to bind them
together without the assistance of another warp.
By this method of weaving much thicker and heavier webs may be
produced with a limitation of elasticity which cannot be obtained by
the single cloth method. The weaves and materials employed in the
face and back of the goods may be identical, or weaves of a different
character and stock of different qualities, sizes and colors may be
used. Fancy effects may be used to embellish the face, while the
back may be perfectly plain and free from any coloring whatever.
There are certain features associated with the construction of
double cloth webs which make them entirely different to deal with.
The different weaves and the different stock employed necessitate
splitting up the warps into sections to accommodate such conditions.
A separate warp is required for both back and face and also one for
the binder, which delivers a much greater length of warp than either,
necessitated by the character of the weave used in binding the upper
and lower cloths together. A separate warp is also required for the
gut, which goes in the web perfectly straight and is shorter in length
than any of the other sections. Such goods also require a special
warp for the selvage, so that in the simplest form of such webs a
bank of five warps is necessary. On fancy goods the introduction of
fancy warps may add to this number.

Balance Between Back and Face

The element of a right balance between the back and face has to
be considered, and if care be not taken in the proper adjustment of
the stock the result may be that one side of the goods will assert
control over the other in such a manner as to prevent it lying flat and
even. When such a web is cut it will curl up so as to be almost
uncontrollable. Such a condition may arise from a variety of causes.
If the weaves of the face and back cloths are identical then it will be
necessary to have the face and back warps of the same size yarn or
its equivalent. For instance, should the face be a four-thread plain
and 40/2 is used, and the back only two threads, then the yarn used
for the back warp must be 20/2 so as to equal the four threads of
40/2 in the face. Should, however, the face be a more open weave
than the back, then an equal weight of yarn in both cloths will not be
right, and it will be necessary to use yarn of a heavier weight for the
face to compensate for the freedom of the more open weave and
effect a proper balance with the more tightly woven back. There can
be no fixed rule to apply to this, and only experience will indicate the
proper relationship between the two. In Figs. 6 and 6A are shown the
simplest form of double cloth, known as a plain web.
By carefully following the weave it will be seen that while the face
weaves 3 up and 1 down, and the back 1 up and 3 down, the filling
will appear both on the face and back of the goods as 1 up and 1
down. If the binder was not there it would be a tubular web, having
the same appearance all around. The binder, however, intersects the
upper and lower cloths at each pick and binds the two together in
one complete whole, while the rubber lies between the two, each
strand being separated by the interlocking binder threads.
It becomes necessary in order properly to connect the upper and
lower cloths at their extreme edges to use a selvage warp, which as
will be seen in Fig. 6A is drawn in on all four face and back
harnesses, and the threads of which are arranged so as to complete
the weave all around. To do this it will be seen that there is an odd
thread at one side, otherwise the weave at this point would show two
threads operating together next to each other, and would break up
the continuity of the weave.
 Fig. 7.—Method of Banking a Set of Warps for Double Cloth Webs

The selvage plays an important part in the structure and weaving

of the web. It forms the pocket for covering in which lies the outside
rubber threads, and it must be so arranged that these threads can
function properly so as to make a piece of goods that will lie flat. In
the first place the yarn must be of such a size that with the proper
number of threads employed the selvage will contract uniformly with
the body of the goods, so that the web will not “frill” on account of a
too heavy selvage, or “belly” because it is too light.

Care for Selvage

 The threads must be properly divided in the front reed so as to
make a good clearance for the filling, which otherwise would “nib” up
and make an unsightly selvage. Then again, a careful adjustment of
the weight carried on the selvage warp must be made so as to
accommodate it to the requisite tension of the filling as it is delivered
from the shuttle, otherwise the edge rubber threads will be liable to
chafe and cut off when strained out of proper alignment with the front
reed. It will be observed in the draft that two rubber threads are used
in each selvage, which is necessary in order to control the additional
yarn used in the construction of the selvage.
 Chapter V.
Three Leaf Twill or Satin Face Woven in Conjunction with Plain Back
—Position of Back Rolls in Relation to Harness Shed—Use of Four
Leaf Twill—Filling Fancy Effects and Stitch Figures—Interchanging
Figure and Face
Turning our attention from plain webs to combination weaves, we
will take up what is popularly known as the three-leaf twill, or satin
face, woven in conjunction with a plain back. This is a type of web
not only used for suspenders, but employed extensively for corset
garter attachments also. A web of this character when properly
constructed has a smooth velvet-like face. The threads are uniformly
distributed across the width without showing any of the “rowy” effect
from the binder warps, which are completely hidden by the heavy
pile produced by the float of the face threads. When the contraction
of the web takes place, these floating face threads mass together in
a velvet-like pile, not only producing a smooth handling web but
materially increasing the thickness. Such webs are generally
constructed with a six-thread face and a four-thread back, and have
what is termed a round edge, similar to the selvage used on a plain
web. This arrangement shows up the twill face by contrast and gives
the fabric a much finer appearance.

Harness and Chain Draft

Fig. 1 shows the harness and chain draft of such a web, together
with the construction of a properly balanced web for standard goods
of 1⅛ inches wide. It will be noticed that the face, consisting of 150
threads, is split up into two warps of 75 threads each. This
arrangement is necessary in order properly to weigh them so as to
get a good clearance in the shed. The warp has to be divided
likewise in the harnesses and put on six harness frames, although
the weave could be produced on three. It would not be practicable to
crowd 50 threads on one harness frame in the narrow space
available, as the harness eyes would shoulder and crowd too much
when changing.
In drawing-in this web, one face warp should be arranged so that
the threads are drawn on the first, third and fifth harnesses, and the
other face warp should be on the second, fourth and sixth. Such an
arrangement in the distribution of the warps makes it much easier on
the mechanism, and minimizes the risk of breakages. It is also
important to make proper divisions of the warps at the back rolls,
inasmuch as some of the warps have to be weighted heavily while
others are only lightly weighted, and also on account of the different
take-up of the varied weaves.
The back rolls should be set in a graded position so as to prevent
undue friction of one warp against another. The binder warp should
be worked under the front roll on account of the extremely light
weight this must carry. Fig. 2 shows the proper position of the back
rolls in relation to the harness shed.
In a web of this character where the warp stock is somewhat
crowded in the front reed, there is always a tendency for a fibrous
yarn to prevent a perfect clearance in the shed, with a liability of
producing occasional floats through the shuttle skipping these
threads. Such floats will pearl up when the web contracts and make
an imperfect face. This trouble may be prevented by setting the back
rolls a trifle higher than the breast beam rod, so that the stock in the
harness which is down will be slightly tighter than that which is in the
upper harness.
The chain draft is so arranged that the face harness will operate to
produce a twill which will be reverse to the twist of the yarn
employed, and thus reduce the prominence of the twill weave all
possible. The filling yarn should be soft, of about 15 turns per inch,
and of good uniform quality, in order to produce a nice selvage and
not cut the rubber. The reed dent inside the selvage rubber should
be carefully twisted at an angle to conform to the nipped in position
to the rubber thread, so that the outside edge of the dent will not cut
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!

ebooknice.com