Object Oriented Software Construction - Bertrand Meyer

Prévia do material em texto

Object-Oriented
Software
Construction
SECOND EDITION
Bertrand Meyer
ISE Inc.
Santa Barbara (California)
Author’s address:
Bertrand Meyer
Interactive Software Engineering Inc. (ISE)
270 Storke Road, Suite 7
Santa Barbara, CA 93117
USA
805-685-1006, fax 805-685-6869
<meyer
@tools.com>, http://www.tools.com
Preface
B orn in th
aberration of
explanation) 
typhoon, by 
hitting the sh
“Object
“structured” 
is used by dif
three-step seq
principle: (1)
(The order m
Let us h
approach to h
not trivial (al
believe it is n
techniques th
many softwa
potential for 
Finally, I hop
excitement ab
“Avenu
oriented meth
the methods
environments
applying object-oriented principles to such areas as exploratory programming and
artificial intelligence. Although the presentation does not exclude these applications, they
are not its main emphasis. Our principal goal in this discussion is to study how practicing
software developers, in industrial as well as academic environments, can use object
technology to improve (in some cases dramatically) the quality of the software they
produce.
e ice-blue waters of the festooned Norwegian coast; amplified (by an
 world currents, for which marine geographers have yet to find a suitable
along the much grayer range of the Californian Pacific; viewed by some as a
some as a tsunami, and by some as a storm in a teacup — a tidal wave is
ores of the computing world. 
-oriented” is the latest in term, complementing and in many cases replacing
as the high-tech version of “good”. As is inevitable in such a case, the term
ferent people with different meanings; just as inevitable is the well-known
uence of reactions that meets the introduction of a new methodological
 “it’s trivial”; (2) “it cannot work”; (3) “that’s how I did it all along anyway”.
ay vary.) 
ave this clear right away, lest the reader think the author takes a half-hearted
is topic: I do not see the object-oriented method as a mere fad; I think it is
though I shall strive to make it as limpid as I can); I know it works; and I
ot only different from but even, to a certain extent, incompatible with the
at most people still use today — including some of the principles taught in
re engineering textbooks. I further believe that object technology holds the
fundamental changes in the software industry, and that it is here to stay.
e that as the reader progresses through these pages, he will share some of my
out this promising avenue to software analysis, design and implementation. 
e to software analysis, design and implementation”. To present the object-
od, this books resolutely takes the viewpoint of software engineering — of
, tools and techniques for developing quality software in production
. This is not the only possible perspective, as there has also been interest in
PREFACEvi
Structure, reliability, epistemology and classification
Object technology is at its core the combination of four ideas: a structuring method, a
reliability discipline, an epistemological principle and a classification technique. 
The str
systems perfo
systems, it is
resulting con
which in obje
structure and
The reli
that does wh
components w
defining expl
The epi
classes. In ob
can do with 
operations (th
types, covere
going beyond
“object” borr
systems mod
it; for the obj
exist indepen
not is an irre
something is 
The cl
intellectual w
taxonomies f
oriented meth
Simple bu
The four con
a number of q
manipulate c
are the possib
that may exis
engineering c
Answer
producing re
binding; a 
s 
e 
te-
ucturing method applies to software decomposition and reuse. Software
rm certain actions on objects of certain types; to obtain flexible and reusable
 better to base their structure on the object types than on the actions. The
cept is a remarkably powerful and versatile mechanism called the class,
ct-oriented software construction serves as the basis for both the modular
 the type system. 
ability discipline is a radical approach to the problem of building software
at it is supposed to do. The idea is to treat any system as a collection of
hich collaborate the way successful businesses do: by adhering to contracts
icitly the obligations and benefits incumbent on each party.
stemological principle addresses the question of how we should describe the
ject technology, the objects described by a class are only defined by what we
them: operations (also known as features) and formal properties of these
e contracts). This idea is formally expressed by the theory of abstract data
d in detail in a chapter of this book. It has far-reaching implications, some
 software, and explains why we must not stop at the naïve concept of
owed from the ordinary meaning of that word. The tradition of information
eling usually assumes an “external reality” that predates any program using
ect-oriented developer, such a notion is meaningless, as the reality does not
dently of what you want to do with it. (More precisely whether it exists or
levant question, as we only know what we can use, and what we know of
defined entirely by how we can use it.) 
assification technique follows from the observation that systematic
ork in general and scientific reasoning in particular require devising
or the domains being studied. Software is no exception, and the object-
od relies heavily on a classification discipline known as inheritance.
t powerful
cepts of class, contract, abstract data type and inheritance immediately raise
uestions. How do we find and describe classes? How should our programs
lasses and the corresponding objects (the instances of these classes)? What
le relations between classes? How can we capitalize on the commonalities
t between various classes? How do these ideas relate to such key software
oncerns as extendibility, ease of use and efficiency? 
s to these questions rely on a small but powerful array of techniques for
usable, extendible and reliable software: polymorphism and dynamic
new view of types and type checking; genericity, constrained and
Abstract data type
are discussed in 
chapter 6, which 
also addresses som
of the related epis
mological issues. 
PREFACE vii
unconstrained; information hiding; assertions; safe exception handling; automatic garbage
collection. Efficient implementation techniques have been developed which permit
applying these ideas successfully to both small and large projects under the tight
constraints of commercial software development. Object-oriented techniques have also
had a conside
possible to pr
important ide
immediately a
Organizat
In the pages 
software cons
Part A i
of software q
characteristic
object-oriente
Part B i
describe the m
modularity: w
construction. 
object techno
inclined read
provides the 
principles and
Part C is
components o
management 
inheritance, t
many exciting
Part D 
Through seve
covers such c
and how to 
intellectual re
review of th
discussion of
Part E
development 
databases; the
Chapters 1 to 2.
Chapters 3 to 6.
Chapters 7 to 18.
Chapters 19 to 29.
Chapters 30 to 32.
rable impact on user interfaces and development environments, making it
oduce much better interactive systems than was possible before. All these
as will be studied in detail, so as to equip the reader with tools that are
pplicable to a wide range of problems. 
ion of the text
that follow we will review the methods and techniques of object-oriented
truction. The presentation has been divided into six parts. 
s an introduction and overview. It starts by exploring the fundamental issue
uality and continues with a brief survey of the method’s main technical
s. This part is almost a little book by itself, providing a first view of the
d approach for hurried readers. 
s not hurried. Entitled “The road to object orientation”,it takes the time to
ethodological concerns that lead to the central O-O concepts. Its focus is on
hat it takes to devise satisfactory structures for “in-the-large” system
It ends with a presentation of abstract data types, the mathematical basis for
logy. The mathematics involved is elementary, and less mathematically
ers may content themselves with the basic ideas, but the presentation
theoretical background that you will need for a full understanding of O-O
 issues. 
 the technical core of the book. It presents, one by one, the central technical
f the method: classes; objects and the associated run-time model; memory
issues; genericity and typing; design by contract, assertions, exceptions;
he associated concepts of polymorphism and dynamic binding, and their
 applications. 
discusses methodology, with special emphasis on analysis and design.
ral in-depth case studies, it presents some fundamental design patterns, and
entral questions as how to find the classes, how to use inheritance properly,
design reusable libraries. It starts with a meta-level discussion of the
quirements on methodologists and other advice-givers; it concludes with a
e software process (the lifecycle model) for O-O development and a
 how best to teach the method in both industry and universities.
 explores advanced topics: concurrency, distribution, client-server
and the Internet; persistence, schema evolution and object-oriented
 design of interactive systems with modern (“GUI”) graphical interfaces.
PREFACEviii
Part F is a review of how the ideas can be implemented, or in some cases emulated,
in various languages and environments. This includes in particular a discussion of major
object-oriented languages, focusing on Simula, Smalltalk, Objective-C, C++, Ada 95 and
Java, and an assessment of how to obtain some of the benefits of object orientation in such
non-O-O lang
Part G (
and provides 
As com
library classe
A Book-W
It can be amu
books, somet
any attention,
however, to s
had in mind f
real reader, a
The ans
that the Mode
to avoid the m
mathematical
explicitly. Th
later developm
that reason be
the material a
Because
topics are tig
Book-Wide W
Reader is to i
some stage ar
not want any 
cheating on th
Both th
useful in sub
oriented con
components. 
it possible to 
The CD
convenient w
have been pre
Chapters 33 to 35.
-
uages as Fortran, Cobol, Pascal, C and Ada. 
doing it right) describes an environment which goes beyond these solutions
an integrated set of tools to support the ideas of the book.
plementary reference material, an appendix shows some important reusable
s discussed in the text, providing a model for the design of reusable software. 
ide Web
sing to see authors taking pains to describe recommended paths through their
imes with the help of sophisticated traversal charts — as if readers ever paid
 and were not smart enough to map their own course. An author is permitted,
ay in what spirit he has scheduled the different chapters, and what path he
or what Umberto Eco calls the Model Reader — not to be confused with the
lso known as “you”, made of flesh, blood and tastes.
wer here is the simplest possible one. This book tells a story, and assumes
l Reader will follow that story from beginning to end, being however invited
ore specialized sections marked as “skippable on first reading” and, if not
ly inclined, to ignore a few mathematical developments also labeled
e real reader, of course, may want to discover in advance some of the plot’s
ents, or to confine his attention to just a few subplots; every chapter has for
en made as self-contained as possible, so that you should be able to intake
t the exact dosage which suits you best.
 the story presents a coherent view of software development, its successive
htly intertwined. The margin notes offer a subtext of cross references, a
eb linking the various sections back and forth. My advice to the Model
gnore them on first reading, except as a reassurance that questions which at
e left partially open will be fully closed later on. The real reader, who may
advice, might use the cross references as unofficial guides when he feels like
e prearranged order of topics.
e Model Reader and the real reader should find the cross references mostly
sequent readings, to make sure that they have mastered a certain object-
cept in depth, and understood its connections with the method’s other
Like the hyperlinks of a WWW document, the cross references should make
follow such associations quickly and effectively.
-ROM that accompanies this book and contains all of its text provides a
ay to follow cross references: just click on them. All the cross references
served.
Chapter 36.
Appendix A.
See “About the 
accompanying CD
ROM”, page xiv.
PREFACE ix
The notation
In software perhaps even more than elsewhere, thought and language are closely
connected. As we progress through these pages, we will carefully develop a notation for
expressing o
implementati
Here an
author”: as in
other words 
involved in th
This ass
started readin
that as we exp
supporting no
feel that you 
This exp
is in fact sup
company (ISE
the text, and 
method for re
language is an
In addit
support for t
language at a
method: to le
top of the con
from historica
with older fo
course you m
perhaps faire
syntax has be
What counts 
you understan
Most so
language or a
reader in the 
and discuss th
explaining th
resolved. I of
designers had
what alternat
hope, provide
construction, 
bject-oriented concepts at all levels: modeling, analysis, design,
on, maintenance. 
d everywhere else in this book, the pronoun “we” does not mean “the
 ordinary language, “we” means you and I — the reader and the author. In
I would like you to expect that, as we develop the notation, you will be
e process. 
umption is not really true, of course, since the notation existed before you
g these pages. But it is not completely preposterous either, because I hope
lore the object-oriented method and carefully examine its implications the
tation will dawn on you with a kind of inevitability, so that you will indeed
helped design it. 
lains why although the notation has been around for more than ten years and
ported by several commercial implementations, including one from my
), I have downplayed it as a language. (Its name does appear in one place in
several times in the bibliography.) This book is about the object-oriented
using, analyzing, designing, implementing and maintaining software; the
 important and I hope natural consequence of that method, not an aim in itself. 
ion, the language is straightforward and includes very little else than direct
he method. First-year students using it have commented that it was “no
ll” — meaning that the notation is in one-to-one correspondence with the
arn one is to learn the other, and there is scant extra linguistic decoration on
cepts. The notation indeed shows few of the peculiarities (often stemming
l circumstances, machine constraints or the requirement to be compatible
rmalisms) that characterize most of today’s programming languages. Of
ay disagree with the choice of keywords (why do rather than begin or
?), or would like to add semicolon terminators after each instruction. (The
en designed so as to make semicolons optional.) But these are side issues.
is the simplicity of the notation and how directly it maps to the concepts. If
d object technology, you almost know it already. 
ftware books take the language for granted, whether it is a programming
 notation for analysis or design. Here the approach is different; involving the
design means that one must not only explain the language but also justify it
e alternatives. Most of the chapters of part C include a “discussion” section
e issues encountered during the design of the notation,and how they were
ten wished, when reading descriptions of well-known languages, that the
 told me not only what solutions they chose, but why they chose them, and
ives they rejected. The candid discussions included in this book should, I
 you with insights not only about language design but also about software
as the two tasks are so strikingly similar. 
PREFACEx
Analysis, design and implementation
It is always risky to use a notation that externally looks like a programming language, as
this may suggest that it only covers the implementation phase. This impression, however
wrong, is har
of metaphys
underworld o
Well-un
the essential u
of abstraction
contributions
for analysis a
Unfortu
through two e
• Object-o
in gener
• Object-o
are adve
an admi
Such ap
contrast, both
applicable th
high-level de
techniques an
The envir
Software con
method is at t
in a while we
obvious reaso
oriented envi
The env
concepts prac
other object-o
other O-O a
descriptions g
anything else
O and non O-
 
-
30.
6, 
d to correct, so frequently have managers and developers been told that a gap
ical proportions exists between the ether of analysis-design and the
f implementation. 
derstood object technology reduces the gap considerably by emphasizing
nity of software development over the inevitable differences between levels
. This seamless approach to software construction is one of the important
 of the method and is reflected by the language of this book, which is meant
nd design as well as for implementation. 
nately some of the recent evolution of the field goes against these principles,
qually regrettable phenomena: 
riented implementation languages which are unfit for analysis, for design and
al for high-level reasoning. 
riented analysis or design methods which do not cover implementation (and
rtized as “language-independent” as if this were a badge of honor rather than
ssion of failure). 
proaches threaten to cancel much of the potential benefit of the approach. In
 the method and the notation developed in this book are meant to be
roughout the software construction process. A number of chapters cover
sign issues; one is devoted to analysis; others explore implementation
d the method’s implications on performance. 
onment
struction relies on a basic tetralogy: method, language, tools, libraries. The
he center of this book; the language question has just been mentioned. Once
 will need to see what support they may require from tools and libraries. For
ns of convenience, such discussions will occasionally refer to ISE’s object-
ronment, with its set of tools and associated libraries.
ironment is used only as an example of what can be done to make the
tically usable by software developers. Be sure to note that there are many
riented environments available, both for the notation of this book and for
nalysis, design and implementation methods and notations; and that the
iven refer to the state of the environment at the time of writing, subject, as
 in our industry, to change quickly — for the better. Other environments, O-
O, are also cited throughout the text.
“SEAMLESSNESS
AND REVERSIBIL
ITY”, 28.6, page 9
The last chapter, 3
summarizes the 
environment.
PREFACE xi
Acknowledgments (quasi-absence thereof)
The first edition of this book contained an already long list of thanks. For a while I kept
writing down the names of people who contributed comments or suggestions, and then at
some stage I 
ideas has now
some importa
So these
make my gra
source of inv
advice. The 
improvement
I have sent h
clarification o
of an attributi
Web page; th
ready they w
comments (an
Dubois, Jam
corrections). 
about the top
enjoyed the w
sabbaticals at
Milano provi
first-year stud
should be tau
The larg
others have c
the Algol lin
seminal work
Mills-Gries) s
techniques, in
nineteen-seve
and Cliff Jon
Ichbiah’s Ad
Simula 67, w
right, bringin
improvement
A few notes in the 
margin or in chap-
ter-end biblio-
graphic sections give 
credit for some spe-
cific ideas, often 
unpublished.
lost track. The roster of colleagues from whom I have had help or borrowed
 grown so long that it would run over many pages, and would inevitably omit
nt people. Better then offend everyone a little than offend a few very much.
 acknowledgments will for the most part remain collective, which does not
titude less deep. My colleagues at ISE and SOL have for years been a daily
aluable help. The users of our tools have generously provided us with their
readers of the first edition provided thousands of suggestions for
. In the preparation of this new edition (I should really say of this new book)
undreds of e-mail messages asking for help of many different kinds: the
f a fine point, a bibliographical reference, a permission to quote, the details
on, the origin of an idea, the specifics of a notation, the official address of a
e answers have invariably been positive. As draft chapters were becoming
ere circulated through various means, prompting many constructive
d here I must cite by name the referees commissioned by Prentice Hall, Paul
es McKim and Richard Wiener, who provided invaluable advice and
In the past few years I have given countless seminars, lectures and courses
ics of this book, and in every case I learned something from the audience. I
it of fellow panelists at conferences and benefited from their wisdom. Short
 the University of Technology, Sydney and the Università degli Studi di
ded me with a influx of new ideas — and in the first case with three hundred
ents on whom to validate some of my ideas about how software engineering
ght.
e bibliography shows clearly enough how the ideas and realizations of
ontributed to this book. Among the most important conscious influences are
e of languages, with its emphasis on syntactic and semantic elegance; the
 on structured programming, in the serious (Dijkstra-Hoare-Parnas-Wirth-
ense of the term, and systematic program construction; formal specification
 particular the inexhaustible lessons of Jean-Raymond Abrial’s original (late
nties) version of the Z specification language, his more recent design of B,
es’s work on VDM; the languages of the modular generation (in particular
a, Liskov’s CLU, Shaw’s Alphard, Bert’s LPG and Wirth’s Modula); and
hich introduced most of the concepts many years ago and had most of them
g to mind Tony Hoare’s comment about Algol 60: that it was such an
 over most of its successors. 
Foreword to the second edition
M any eve
OOSC
 (as the
alluded to in t
expanded for
and conferen
devoted to th
concurrency 
formal speci
relevant to m
the Web is af
This is 
occurring in t
of object tech
the obligatory
compared to 
There is no re
uses software
no reason to b
It is the ambi
This sec
paragraph of 
Countless ne
distribution, 
and databases
and impleme
which little is
it; discussion
presentation o
indispensable
detail by tex
bibliographic
development 
enjoyment) a
explanations,
The rea
expectations.
Santa Barbara
nts have happened in the object-oriented world since the first edition of
 book came to be known) was published in 1988. The explosion of interest
he Preface to the first edition, reproduced in the preceding pages in a slightly
m, was nothing then as compared to what we have seen since. Many journals
ces now cover object technology; Prentice Hall has an entire book series
e subject; breakthroughs have occurred in such areas as user interfaces,
and databases; entire new topics have emerged, such as O-O analysis and
fication; distributed computing, once a specialized topic, is becoming
ore and more developments, thanks in part to the growth of the Internet; and
fecting everyone’s daily work.
not the only exciting news. It is gratifying to see how much progress is
he softwarefield — thanks in part to the incomplete but undeniable spread
nology. Too many books and articles on software engineering still start with
 lament about the “software crisis” and the pitiful state of our industry as
true
 engineering disciplines (which, as we all know, never mess things up).
ason for such doom. Oh, we still have a long, long way to go, as anyone who
 products knows all too well. But given the challenges that we face we have
e ashamed of ourselves as a profession; and we are getting better all the time.
tion of this book, as it was of its predecessor, to help in this process.
ond edition is not an update but the result of a thorough reworking. Not a
the original version has been left untouched. (Hardly a single line, actually.)
w topics have been added, including a whole chapter on concurrency,
client-server computing and Internet programming; another on persistence
; one on user interfaces; one on the software lifecycle; many design patterns
ntation techniques; an in-depth exploration of a methodological issue on
 available in the literature, how to use inheritance well and avoid misusing
s of many other topics of object-oriented methodology; an extensive
f the theory of abstract data types — the mathematical basis for our subject,
 to a complete understanding of object technology yet seldom covered in
tbooks and tutorials; a presentation of O-O analysis; hundreds of new
 and Web site references; the description of a complete object-oriented
environment (also included on the accompanying CD-ROM for the reader’s
nd of the underlying concepts; and scores of new ideas, principles, caveats,
 figures, examples, comparisons, citations, classes, routines.
ctions to OOSC-1 have been so rewarding that I know readers have high
 I hope they will find OOSC-2 challenging, useful, and up to their standards.
B.M.
January 1997
PREFACExiv
About the accompanying CD-ROM
The CD-ROM that comes with this book contains the entire hyperlinked text in Adobe
Acrobat format. It also includes Adobe’s Acrobat Reader software, enabling you to read
that format; 
have Acroba
The author a
associated to
book, and an
Adobe abou
To get starte
directory, w
open that fi
computer, ex
directory.
The presenc
take advanta
Wide Web”
to follow the
the book alll
and forth. Th
you may wi
All links (c
above (but n
If the refere
Acrobat Rea
minus-sign (
Acrobat Rea
Bibliograph
form, so tha
bibliography
The CD-RO
• Library
• A cha
mathem
In addition,
oriented de
chapter 36, 
throughout t
system requ
the versions provided cover major industry platforms. If you do not already
t Reader on your computer, you can install it by following the instructions.
nd the publisher make no representations as to any property of Acrobat and
ols; the Acrobat Reader is simply provided as a service to readers of this
y Acrobat questions should be directed to Adobe. You may also check with
t any versions of the Reader that may have appeared after the book.
d with the CD-ROM, open the Acrobat file README.pdf in the OOSC-2
hich will direct you to the table of contents and the index. You can only
le under Acrobat Reader; if the Reader has not been installed on your
amine instead the plain-text version in the file readme.txt in the top-level
e of an electronic version will be particularly useful to readers who want to
ge of the thousands of cross-references present in this book (see “A Book-
, page viii). Although for a first sequential reading you will probably prefer
 paper version, having the electronic form available on a computer next to
ows you to follow a link once in a while without having to turn pages back
e electronic form is particularly convenient for a later reading during which
sh to explore links more systematically.
ross-references) appear in blue in the Acrobat form, as illustrated twice
ot visible in the printed version). To follow a link, just click on the blue part.
nce is to another chapter, the chapter will appear in a new window. The
der command to come back to the previous position is normally Control-
that is, type – while holding down the CONTROL key). Consult the on-line
der documentation for other useful navigational commands.
ical references also appear as links, such as [Knuth 1968], in the Acrobat
t you can click on any of them to see the corresponding entry in the
 of appendix E.
M also contains:
 components providing extensive material for Appendix A.
pter from the manual for a graphical application builder, providing
atical complements to the material of chapter 32.
 the CD-ROM includes a time-limited version of an advanced object-
velopment environment for Windows 95 or Windows NT, as described in
providing an excellent hands-on opportunity to try out the ideas developed
he book. The “Readme” file directs you to the installation instructions and
irements.
Acknowledgments: The preparation of the hyperlinked text was made possible by the help of several people
at Adobe Inc., in particular Sandra Knox, Sarah Rosenbaum and the FrameMaker Customer Support Group.
PREFACE xvii
On the bibliography, Internet sources and 
exercises
This book re
discussion of
“Bibliographi
to understand
Referen
and refer to th
not intended t
Name denote
of the bibliog
Aside fr
the paragraph
bibliography 
and related to
not imply an
assessment of
Although ele
years from no
Internet-relate
Usenet newsg
Electron
of the quoted
several years.
difficulty, no
tools can help
Most chapter
providing solu
may regret th
three reasons
realization tha
answer; and th
book as a tex
The bibliography 
starts on page 
1203.
lies on earlier contributions by many authors. To facilitate reading, the
 sources appears in most cases not in the course of the discussion, but in the
cal notes” sections at chapter end. Make sure you read these sections, so as
 the origin of many ideas and results and find out where to learn more. 
ces are of the form [Name 19xx], where Name is the name of the first author,
e bibliography in appendix E. This convention is for readability only and is
o underrate the role of authors other than the first. The letter M in lieu of a
s publications by the author of this book, listed separately in the second part
raphy. 
om the bibliography proper, some references appear in the margin, next to
s which cite them. The reason for this separate treatment is to make the
usable by itself, as a collection of important references on object technology
pics. Appearance as a margin reference rather than in the bibliography does
y unfavorable judgment of value; the division is simply a pragmatic
 what belongs in a core list of object-oriented references. 
***
ctronic references will undoubtedly be considered a matter of course a few
w, this must be one of the first technical books (other than books devoted to
d topics) to make extensive use of references to World-Wide-Web pages,
roups and other Internet resources.
ic addresses are notoriously volatile. I have tried to obtain from the authors
 sources some reassurance that the addresses given would remain valid for
 Neither they nor I, of course, can provide an absolute guarantee. In case of
te that on the Net more things move than disappear: keyword-based search
.
***
s include exercises of various degrees of difficulty. I have refrained from
tions, although many exercises do contain fairly precise hints. Some readers
e absence of full solutions; I hope, however, that they will appreciate the
 that led to this decision: the fear of spoiling the reader’s enjoyment; the
t many exercises are design problems, for which there is more than one good
e desire to provide a source of ready-made problems to instructors using this
t.
***
PREFACExviii
For brevity and simplicity, the text follows the imperfect but long-established tradition of
using words such as“he” and “his”, in reference to unspecified persons, as shortcuts for
“he or she” and “his or her”, with no intended connotation of gender.
A modest soul is shocked by objects of such kind
And all the nasty thoughts that they bring to one's mind.
Molière, Tartuffe, Act III.
Contents
Preface
Foreword t
About the a
On the bibl
Contents
PART A:
Chapter 
1.1 EX
1.2 A R
1.3 AB
1.4 KE
1.5 BIB
Chapter 
2.1 ON
2.2 ME
2.3 IMP
2.4 LIB
2.5 FO
2.6 BIB
PART B:
Chapter 
3.1 FIV
3.2 FIVE RULES 46
3.3 FIVE PRINCIPLES 53
3.4 KEY CONCEPTS INTRODUCED IN THIS CHAPTER 64
3.5 BIBLIOGRAPHICAL NOTES 64
EXERCISES 65
v
o the second edition xiii
ccompanying CD-ROM xiv
iography, Internet sources and exercises xv
xvii
 THE ISSUES 1
1: Software quality 3
TERNAL AND INTERNAL FACTORS 3
EVIEW OF EXTERNAL FACTORS 4
OUT SOFTWARE MAINTENANCE 17
Y CONCEPTS INTRODUCED IN THIS CHAPTER 19
LIOGRAPHICAL NOTES 19
2: Criteria of object orientation 21
 THE CRITERIA 21
THOD AND LANGUAGE 22
LEMENTATION AND ENVIRONMENT 31
RARIES 33
R MORE SNEAK PREVIEW 34
LIOGRAPHICAL NOTES AND OBJECT RESOURCES 34
 THE ROAD TO OBJECT ORIENTATION 37
3: Modularity 39
E CRITERIA 40
CONTENTSxviii
Chapter 4: Approaches to reusability 67
4.1 THE GOALS OF REUSABILITY 68
4.2 WHAT SHOULD WE REUSE? 70
4.3 REPETITION IN SOFTWARE DEVELOPMENT 74
4.4 NO
4.5 TH
4.6 FIV
4.7 TR
4.8 OV
4.9 KE
4.10 BI
Chapter 
5.1 TH
5.2 FU
5.3 OB
5.4 OB
5.5 ISS
5.6 KE
5.7 BIB
Chapter 
6.1 CR
6.2 IMP
6.3 TO
6.4 FO
6.5 FRO
6.6 BE
6.7 SU
6.8 KE
6.9 BIB
EXERC
PART C:
Chapter 
7.1 OB
7.2 AV
7.3 TH
7.4 A U
7.5 A S
7.6 BA
N-TECHNICAL OBSTACLES 74
E TECHNICAL PROBLEM 81
E REQUIREMENTS ON MODULE STRUCTURES 83
ADITIONAL MODULAR STRUCTURES 89
ERLOADING AND GENERICITY 93
Y CONCEPTS INTRODUCED IN THIS CHAPTER 98
BLIOGRAPHICAL NOTES 99
5: Towards object technology 101
E INGREDIENTS OF COMPUTATION 101
NCTIONAL DECOMPOSITION 103
JECT-BASED DECOMPOSITION 114
JECT-ORIENTED SOFTWARE CONSTRUCTION 116
UES 117
Y CONCEPTS INTRODUCED IN THIS CHAPTER 119
LIOGRAPHICAL NOTES 119
6: Abstract data types 121
ITERIA 122
LEMENTATION VARIATIONS 122
WARDS AN ABSTRACT VIEW OF OBJECTS 126
RMALIZING THE SPECIFICATION 129
M ABSTRACT DATA TYPES TO CLASSES 142
YOND SOFTWARE 147
PPLEMENTARY TOPICS 148
Y CONCEPTS INTRODUCED IN THIS CHAPTER 159
LIOGRAPHICAL NOTES 160
ISES 161
 OBJECT-ORIENTED TECHNIQUES 163
7: The static structure: classes 165
JECTS ARE NOT THE SUBJECT 165
OIDING THE STANDARD CONFUSION 166
E ROLE OF CLASSES 169
NIFORM TYPE SYSTEM 171
IMPLE CLASS 172
SIC CONVENTIONS 177
CONTENTS xix
7.7 THE OBJECT-ORIENTED STYLE OF COMPUTATION 181
7.8 SELECTIVE EXPORTS AND INFORMATION HIDING 191
7.9 PUTTING EVERYTHING TOGETHER 194
7.10 DISCUSSION 203
7.11 KE
7.12 BI
EXERC
Chapter 
8.1 OB
8.2 OB
8.3 MA
8.4 CR
8.5 MO
8.6 OP
8.7 CO
8.8 AT
8.9 DE
8.10 DI
8.11 KE
8.12 BI
EXERC
Chapter 
9.1 WH
9.2 TH
9.3 RE
9.4 PRO
9.5 TH
9.6 AU
9.7 RE
9.8 GA
9.9 PRA
9.10 AN
9.11 KE
9.12 BI
EXERC
Chapter 
10.1 HO
10.2 TH
10.3 GE
Y CONCEPTS INTRODUCED IN THIS CHAPTER 213
BLIOGRAPHICAL NOTES 215
ISES 216
8: The run-time structure: objects 217
JECTS 218
JECTS AS A MODELING TOOL 228
NIPULATING OBJECTS AND REFERENCES 231
EATION PROCEDURES 236
RE ON REFERENCES 240
ERATIONS ON REFERENCES 242
MPOSITE OBJECTS AND EXPANDED TYPES 254
TACHMENT: REFERENCE AND VALUE SEMANTICS 261
ALING WITH REFERENCES: BENEFITS AND DANGERS 265
SCUSSION 270
Y CONCEPTS INTRODUCED IN THIS CHAPTER 276
BLIOGRAPHICAL NOTES 277
ISES 277
9: Memory management 279
AT HAPPENS TO OBJECTS 279
E CASUAL APPROACH 291
CLAIMING MEMORY: THE ISSUES 293
GRAMMER-CONTROLLED DEALLOCATION 294
E COMPONENT-LEVEL APPROACH 297
TOMATIC MEMORY MANAGEMENT 301
FERENCE COUNTING 302
RBAGE COLLECTION 304
CTICAL ISSUES OF GARBAGE COLLECTION 309
 ENVIRONMENT WITH MEMORY MANAGEMENT 312
Y CONCEPTS INTRODUCED IN THIS CHAPTER 315
BLIOGRAPHICAL NOTES 315
ISES 316
10: Genericity 317
RIZONTAL AND VERTICAL TYPE GENERALIZATION 317
E NEED FOR TYPE PARAMETERIZATION 318
NERIC CLASSES 320
CONTENTSxx
10.4 ARRAYS 325
10.5 THE COST OF GENERICITY 328
10.6 DISCUSSION: NOT DONE YET 329
10.7 KEY CONCEPTS INTRODUCED IN THIS CHAPTER 329
10.8 BI
EXERC
Chapter 
11.1 BA
11.2 AB
11.3 EX
11.4 IN
11.5 PR
11.6 CO
11.7 W
11.8 CL
11.9 W
11.10 T
11.11 A
11.12 L
11.13 U
11.14 D
11.15 K
11.16 B
EXERC
POSTSC
Chapter 
12.1 BA
12.2 HA
12.3 AN
12.4 EX
12.5 TH
12.6 AD
12.7 DI
12.8 KE
12.9 BI
EXERC
Chapter 
13.1 IN
13.2 AR
BLIOGRAPHICAL NOTES 330
ISES 330
11: Design by Contract: building reliable software 331
SIC RELIABILITY MECHANISMS 332
OUT SOFTWARE CORRECTNESS 333
PRESSING A SPECIFICATION 334
TRODUCING ASSERTIONS INTO SOFTWARE TEXTS 337
ECONDITIONS AND POSTCONDITIONS 338
NTRACTING FOR SOFTWARE RELIABILITY 341
ORKING WITH ASSERTIONS 348
ASS INVARIANTS 363
HEN IS A CLASS CORRECT? 369
HE ADT CONNECTION 373
N ASSERTION INSTRUCTION 378
OOP INVARIANTS AND VARIANTS 380
SING ASSERTIONS 389
ISCUSSION 398
EY CONCEPTS INTRODUCED IN THIS CHAPTER 406
IBLIOGRAPHICAL NOTES 407
ISES 408
RIPT: THE ARIANE 5 FAILURE 410
12: When the contract is broken: exception handling 411
SIC CONCEPTS OF EXCEPTION HANDLING 411
NDLING EXCEPTIONS 414
 EXCEPTION MECHANISM 419
CEPTION HANDLING EXAMPLES 422
E TASK OF A RESCUE CLAUSE 427
VANCED EXCEPTION HANDLING 431
SCUSSION 435
Y CONCEPTS INTRODUCED IN THIS CHAPTER 437
BLIOGRAPHICAL NOTES 438
ISES 438
13: Supporting mechanisms 439
TERFACING WITH NON-O-O SOFTWARE 439
GUMENT PASSING 444
CONTENTS xxi
13.3 INSTRUCTIONS 447
13.4 EXPRESSIONS 452
13.5 STRINGS 456
13.6 INPUT AND OUTPUT 457
13.7 LE
13.8 KE
EXERC
Chapter 
14.1 PO
14.2 PO
14.3 TY
14.4 DY
14.5 DE
14.6 RE
14.7 TH
14.8 TH
14.9 DI
14.10 K
14.11 B
EXERC
Chapter 
15.1 EX
15.2 FE
15.3 FL
15.4 RE
15.5 DI
15.6 KE
15.7 BI
EXERC
Chapter 
16.1 IN
16.2 TH
16.3 FR
16.4 CO
16.5 AS
16.6 TY
16.7 AN
16.8 IN
16.9 KE
XICAL CONVENTIONS 457
Y CONCEPTS INTRODUCED IN THIS CHAPTER 458
ISES 458
14: Introduction to inheritance 459
LYGONS AND RECTANGLES 460
LYMORPHISM 467
PING FOR INHERITANCE 472
NAMIC BINDING 480
FERRED FEATURES AND CLASSES 482
DECLARATION TECHNIQUES 491
E MEANING OF INHERITANCE 494
E ROLE OF DEFERRED CLASSES 500
SCUSSION 507
EY CONCEPTS INTRODUCED IN THIS CHAPTER 516
IBLIOGRAPHICAL NOTES 517
ISES 517
15: Multiple inheritance 519
AMPLES OF MULTIPLE INHERITANCE 519
ATURE RENAMING 535
ATTENING THE STRUCTURE 541
PEATED INHERITANCE 543
SCUSSION 563
Y CONCEPTS INTRODUCED IN THIS CHAPTER 566
BLIOGRAPHICAL NOTES 567
ISES 567
16: Inheritance techniques 569
HERITANCE AND ASSERTIONS 569
E GLOBAL INHERITANCE STRUCTURE 580
OZEN FEATURES 583
NSTRAINED GENERICITY 585
SIGNMENT ATTEMPT 591
PING AND REDECLARATION 595
CHORED DECLARATION 598
HERITANCE AND INFORMATION HIDING 605
Y CONCEPTS INTRODUCED IN THIS CHAPTER 609
CONTENTSxxii
16.10 BIBLIOGRAPHICAL NOTE 610
EXERCISES 610
Chapter 17: Typing 611
17.1 THE TYPING PROBLEM 611
17.2 ST
17.3 CO
17.4 FI
17.5 RE
17.6 GL
17.7 BE
17.8 AN
17.9 TH
17.10 K
17.11 B
Chapter 
18.1 CO
18.2 US
18.3 CO
18.4 AP
18.5 CO
18.6 UN
18.7 DI
18.8 KE
18.9 BI
EXERC
PART D:
Chapter 
19.1 SO
19.2 DE
19.3 ON
19.4 TH
19.5 BI
EXERC
Chapter 
20.1 M
20.2 A 
ATIC TYPING: WHY AND HOW 615
VARIANCE AND DESCENDANT HIDING 621
RST APPROACHES TO SYSTEM VALIDITY 628
LYING ON ANCHORED TYPES 630
OBAL ANALYSIS 633
WARE OF POLYMORPHIC CATCALLS! 636
 ASSESSMENT 639
E PERFECT FIT 640
EY CONCEPTS STUDIED IN THIS CHAPTER 641
IBLIOGRAPHICAL NOTES 641
18: Global objects and constants 643
NSTANTS OF BASIC TYPES 643
E OF CONSTANTS 645
NSTANTS OF CLASS TYPES 646
PLICATIONS OF ONCE ROUTINES 648
NSTANTS OF STRING TYPE 653
IQUE VALUES654
SCUSSION 656
Y CONCEPTS INTRODUCED IN THIS CHAPTER 659
BLIOGRAPHICAL NOTES 660
ISES 660
 OBJECT-ORIENTED METHODOLOGY:
APPLYING THE METHOD WELL 661
19: On methodology 663
FTWARE METHODOLOGY: WHY AND WHAT 663
VISING GOOD RULES: ADVICE TO THE ADVISORS 664
 USING METAPHORS 671
E IMPORTANCE OF BEING HUMBLE 673
BLIOGRAPHICAL NOTES 674
ISES 674
20: Design pattern: multi-panel interactive systems 675
ULTI-PANEL SYSTEMS 675
SIMPLE-MINDED ATTEMPT 677
CONTENTS xxiii
20.3 A FUNCTIONAL, TOP-DOWN SOLUTION 678
20.4 A CRITIQUE OF THE SOLUTION 682
20.5 AN OBJECT-ORIENTED ARCHITECTURE 684
20.6 DISCUSSION 693
20.7 BI
Chapter 
21.1 PE
21.2 FI
21.3 M
21.4 IM
21.5 A 
21.6 DI
21.7 BI
EXERC
Chapter 
22.1 ST
22.2 DA
22.3 GE
22.4 OT
22.5 RE
22.6 TH
22.7 KE
22.8 BI
Chapter 
23.1 SI
23.2 HO
23.3 CL
23.4 AC
23.5 SE
23.6 DE
23.7 CL
23.8 DO
23.9 KE
23.10 B
EXERC
BLIOGRAPHICAL NOTE 694
21: Inheritance case study: “undo” in an interactive 
system 695
RSEVERARE DIABOLICUM 695
NDING THE ABSTRACTIONS 699
ULTI-LEVEL UNDO-REDO 704
PLEMENTATION ASPECTS 707
USER INTERFACE FOR UNDOING AND REDOING 711
SCUSSION 712
BLIOGRAPHICAL NOTES 715
ISES 715
22: How to find the classes 719
UDYING A REQUIREMENTS DOCUMENT 720
NGER SIGNALS 726
NERAL HEURISTICS FOR FINDING CLASSES 731
HER SOURCES OF CLASSES 735
USE 740
E METHOD FOR OBTAINING CLASSES 741
Y CONCEPTS INTRODUCED IN THIS CHAPTER 743
BLIOGRAPHICAL NOTES 744
23: Principles of class design 747
DE EFFECTS IN FUNCTIONS 748
W MANY ARGUMENTS FOR A FEATURE? 764
ASS SIZE: THE SHOPPING LIST APPROACH 770
TIVE DATA STRUCTURES 774
LECTIVE EXPORTS 796
ALING WITH ABNORMAL CASES 797
ASS EVOLUTION: THE OBSOLETE CLAUSE 802
CUMENTING A CLASS AND A SYSTEM 803
Y CONCEPTS INTRODUCED IN THIS CHAPTER 806
IBLIOGRAPHICAL NOTES 806
ISES 807
CONTENTSxxiv
Chapter 24: Using inheritance well 809
24.1 HOW NOT TO USE INHERITANCE 809
24.2 WOULD YOU RATHER BUY OR INHERIT? 812
24.3 AN APPLICATION: THE HANDLE TECHNIQUE 817
24.4 TA
24.5 US
24.6 ON
24.7 SU
24.8 IM
24.9 FA
24.10 M
24.11 H
24.12 A
24.13 K
24.14 B
24.15 A
EXERC
Chapter 
25.1 DE
25.2 CL
25.3 IN
Chapter 
26.1 CO
26.2 CH
26.3 US
26.4 HE
26.5 TE
26.6 FO
26.7 BI
EXERC
Chapter 
27.1 TH
27.2 TH
27.3 TH
27.4 PR
27.5 EX
27.6 AN
27.7 TH
27.8 BI
XOMANIA 820
ING INHERITANCE: A TAXONOMY OF TAXONOMY 822
E MECHANISM, OR MORE? 833
BTYPE INHERITANCE AND DESCENDANT HIDING 835
PLEMENTATION INHERITANCE 844
CILITY INHERITANCE 847
ULTIPLE CRITERIA AND VIEW INHERITANCE 851
OW TO DEVELOP INHERITANCE STRUCTURES 858
 SUMMARY VIEW: USING INHERITANCE WELL 862
EY CONCEPTS INTRODUCED IN THIS CHAPTER 863
IBLIOGRAPHICAL NOTES 863
PPENDIX: A HISTORY OF TAXONOMY 864
ISES 869
25: Useful techniques 871
SIGN PHILOSOPHY 871
ASSES 872
HERITANCE TECHNIQUES 873
26: A sense of style 875
SMETICS MATTERS! 875
OOSING THE RIGHT NAMES 879
ING CONSTANTS 884
ADER COMMENTS AND INDEXING CLAUSES 886
XT LAYOUT AND PRESENTATION 891
NTS 900
BLIOGRAPHICAL NOTES 901
ISES 902
27: Object-oriented analysis 903
E GOALS OF ANALYSIS 903
E CHANGING NATURE OF ANALYSIS 906
E CONTRIBUTION OF OBJECT TECHNOLOGY 907
OGRAMMING A TV STATION 907
PRESSING THE ANALYSIS: MULTIPLE VIEWS 914
ALYSIS METHODS 917
E BUSINESS OBJECT NOTATION 919
BLIOGRAPHY 922
CONTENTS xxv
Chapter 28: The software construction process 923
28.1 CLUSTERS 923
28.2 CONCURRENT ENGINEERING 924
28.3 STEPS AND TASKS 926
28.4 TH
28.5 GE
28.6 SE
28.7 W
28.8 KE
28.9 BI
Chapter 
29.1 IN
29.2 IN
29.3 OT
29.4 TO
29.5 AN
29.6 KE
29.7 BI
PART E: 
Chapter 
30.1 A 
30.2 TH
30.3 FR
30.4 IN
30.5 SY
30.6 AC
30.7 W
30.8 RE
30.9 EX
30.10 T
30.11 A
30.12 D
30.13 K
30.14 B
EXERC
E CLUSTER MODEL OF THE SOFTWARE LIFECYCLE 926
NERALIZATION 928
AMLESSNESS AND REVERSIBILITY 930
ITH US, EVERYTHING IS THE FACE 933
Y CONCEPTS COVERED IN THIS CHAPTER 934
BLIOGRAPHICAL NOTES 934
29: Teaching the method 935
DUSTRIAL TRAINING 935
TRODUCTORY COURSES 937
HER COURSES 941
WARDS A NEW SOFTWARE PEDAGOGY 942
 OBJECT-ORIENTED PLAN 946
Y CONCEPTS STUDIED IN THIS CHAPTER 948
BLIOGRAPHICAL NOTES 948
 ADVANCED TOPICS 949
30: Concurrency, distribution, client-server and
the Internet 951
SNEAK PREVIEW 951
E RISE OF CONCURRENCY 953
OM PROCESSES TO OBJECTS 956
TRODUCING CONCURRENT EXECUTION 964
NCHRONIZATION ISSUES 977
CESSING SEPARATE OBJECTS 982
AIT CONDITIONS 990
QUESTING SPECIAL SERVICE 998
AMPLES 1003
OWARDS A PROOF RULE 1022
 SUMMARY OF THE MECHANISM 1025
ISCUSSION 1028
EY CONCEPTS INTRODUCED IN THIS CHAPTER 1032
IBLIOGRAPHICAL NOTES 1033
ISES 1035
CONTENTSxxvi
Chapter 31: Object persistence and databases 1037
31.1 PERSISTENCE FROM THE LANGUAGE 1037
31.2 BEYOND PERSISTENCE CLOSURE 1039
31.3 SC
31.4 FR
31.5 OB
31.6 OB
31.7 O-
31.8 DI
31.9 KE
31.10 B
EXERC
Chapter 
32.1 NE
32.2 PO
32.3 GR
32.4 IN
32.5 HA
32.6 A 
32.7 BI
PART F: 
Chapter 
33.1 A 
33.2 PA
33.3 A 
33.4 HI
33.5 EX
33.6 TA
33.7 FR
33.8 KE
33.9 BI
EXERC
HEMA EVOLUTION 1041
OM PERSISTENCE TO DATABASES 1047
JECT-RELATIONAL INTEROPERABILITY 1048
JECT-ORIENTED DATABASE FUNDAMENTALS 1050
O DATABASE SYSTEMS: EXAMPLES 1055
SCUSSION: BEYOND O-O DATABASES 1058
Y CONCEPTS STUDIED IN THIS CHAPTER 1060
IBLIOGRAPHICAL NOTES 1061
ISES 1062
32: Some O-O techniques for graphical interactive 
applications 1063
EDED TOOLS 1064
RTABILITY AND PLATFORM ADAPTATION 1066
APHICAL ABSTRACTIONS 1068
TERACTION MECHANISMS 1071
NDLING THE EVENTS 1072
MATHEMATICAL MODEL 1076
BLIOGRAPHICAL NOTES 1076
 APPLYING THE METHOD IN VARIOUS 
LANGUAGES AND ENVIRONMENTS 1077
33: O-O programming and Ada 1079
BIT OF CONTEXT 1079
CKAGES 1081
STACK IMPLEMENTATION 1081
DING THE REPRESENTATION: THE PRIVATE STORY 1085
CEPTIONS 1088
SKS 1091
OM ADA TO ADA 95 1092
Y CONCEPTS INTRODUCED IN THIS CHAPTER 1097
BLIOGRAPHICAL NOTES 1097
ISES 1098
CONTENTS xxvii
Chapter 34: Emulating object technology in non-O-O
environments 1099
34.1 LEVELS OF LANGUAGE SUPPORT 1099
34.2 OB
34.3 FO
34.4 OB
34.5 BI
EXERC
Chapter 
35.1 SI
35.2 SM
35.3 LI
35.4 C 
35.5 JA
35.6 OT
35.7 BI
EXERC
PART G:
Chapter 
36.1 CO
36.2 TH
36.3 TH
36.4 TO
36.5 LI
36.6 IN
36.7 BI
Epilogue
JECT-ORIENTED PROGRAMMING IN PASCAL? 1100
RTRAN 1102
JECT-ORIENTED PROGRAMMING AND C 1106
BLIOGRAPHICAL NOTES 1112
ISES 1112
35: Simula to Java and beyond: major O-O languages
and environments 1113
MULA 1113
ALLTALK 1126
SP EXTENSIONS 1130
EXTENSIONS 1131
VA 1136
HER O-O LANGUAGES 1137
BLIOGRAPHICAL NOTES 1138
ISES 1139
 DOING IT RIGHT 1141
36: An object-oriented environment 1143
MPONENTS 1143
E LANGUAGE 1144
E COMPILATION TECHNOLOGY 1144
OLS 1148
BRARIES 1150
TERFACE MECHANISMS 1152
BLIOGRAPHICAL NOTES 1160
, In Full Frankness Exposing the Language 1161
PART H: APPENDICES 1163
Appendix A: Extracts from the Base libraries 1165
Appendix B: Genericity versus inheritance 1167
B.1 GE
B.2 INH
B.3 EM
B.4 EM
B.5 CO
B.6 KE
B.7 BIB
EXERC
Appendix
Appendix
Appendix
E.1 WO
E.2 WO
Index
NERICITY 1168
ERITANCE 1173
ULATING INHERITANCE WITH GENERICITY 1175
ULATING GENERICITY WITH INHERITANCE 1176
MBINING GENERICITY AND INHERITANCE 1184
Y CONCEPTS INTRODUCED IN THIS APPENDIX 1187
LIOGRAPHICAL NOTES 1188
ISES 1188
 C: Principles, rules, precepts and definitions 1189
 D: A glossary of object technology 1193
 E: Bibliography 1203
RKS BY OTHER AUTHORS 1203
RKS BY THE AUTHOR OF THE PRESENT BOOK 1221
1225
1 
Software
E ngineerin
This book in
improvement
Before 
best describe
factors, show
where we sha
1.1 EXTE
We all want 
structured an
On one
presence or a
may be called
Under “u
products
purchaseof acquir
with whi
this discu
it may no
Other q
are internal 
actual softwa
In the end, only external factors matter. If I use a Web browser or live near a
computer-controlled nuclear plant, little do I care whether the source program is readable
or modular if graphics take ages to load, or if a wrong input blows up the plant. But the
key to achieving these external factors is in the internal ones: for the users to enjoy the
visible qualities, the designers and implementers must have applied internal techniques
that will ensure the hidden qualities. 
 quality
g seeks quality; software engineering is the production of quality software.
troduces a set of techniques which hold the potential for remarkable
s in the quality of software products. 
studying these techniques, we must clarify their goals. Software quality is
d as a combination of several factors. This chapter analyzes some of these
s where improvements are most sorely needed, and points to the directions
ll be looking for solutions in the rest of our journey. 
RNAL AND INTERNAL FACTORS 
our software systems to be fast, reliable, easy to use, readable, modular,
d so on. But these adjectives describe two different sorts of qualities.
 side, we are considering such qualities as speed or ease of use, whose
bsence in a software product may be detected by its users. These properties
 
external
 quality factors.
sers” we should include not only the people who actually interact with the final
, like an airline agent using a flight reservation system, but also those who
 the software or contract out its development, like an airline executive in charge
ing or commissioning flight reservation systems. So a property such as the ease
ch the software may be adapted to changes of specifications — defined later in
ssion as extendibility — falls into the category of external factors even though
t be of immediate interest to such “end users” as the reservations agent.
ualities applicable to a software product, such as being modular, or readable,
factors, perceptible only to computer professionals who have access to the
re text. 
SOFTWARE QUALITY §1.24
The following chapters present of a set of modern techniques for obtaining internal
quality. We should not, however, lose track of the global picture; the internal techniques
are not an end in themselves, but a means to reach external software qualities. So we must
start by looking at external factors. The rest of this chapter examines them.
1.2 A RE
Here are the 
object-oriente
Correctnes
Correctness i
everything el
But this
we must be a
challenging t
Method
system, even 
impossible to
a single level
In the c
each layer is 
realistic techn
stage on a lim
level languag
implements X
simply that y
correctness o
In the 
development 
different appl
Correc
as defi
VIEW OF EXTERNAL FACTORS 
most important external quality factors, whose pursuit is the central task of
d software construction.
s
s the prime quality. If a system does not do what it is supposed to do,
se about it — whether it is fast, has a nice user interface… — matters little. 
 is easier said than done. Even the first step to correctness is already difficult:
ble to specify the system requirements in a precise form, by itself quite a
ask. 
s for ensuring correctness will usually be conditional. A serious software
a small one by today’s standards, touches on so many areas that it would be
 guarantee its correctness by dealing with all components and properties on
. Instead, a layered approach is necessary, each layer relying on lower ones:
onditional approach to correctness, we only worry about guaranteeing that
correct on the assumption that the lower levels are correct. This is the only
ique, as it achieves separation of concerns and lets us concentrate at each
ited set of problems. You cannot usefully check that a program in a high-
e X is correct unless you are able to assume that the compiler on hand
 correctly. This does not necessarily mean that you trust the compiler blindly,
ou separate the two components of the problem: compiler correctness, and
f your program relative to the language’s semantics. 
method described in this book, even more layers intervene: software
will rely on libraries of reusable components, which may be used in many
ications.
Definition: correctness
tness is the ability of software products to perform their exact tasks,
ned by their specification. 
Layers in 
software 
development
Application system
Compiler
 
Operating System
Hardware 
§1.2 A REVIEW OF EXTERNAL FACTORS 5
The con
correct and, s
Many p
about testing 
a number of t
that is correct
testing remain
It is po
construction. 
terms “check
Yet many of 
mathematical
way towards 
Robustnes
Robustness c
cases covere
that specifica
Robust
abnorm
Application system
Application library 
… More libraries …
Layers in a 
development 
process that 
includes reuse
Robustness 
versus 
correctness
ditional approach will also apply here: we should ensure that the libraries are
eparately, that the application is correct assuming the libraries are.
ractitioners, when presented with the issue of software correctness, think
and debugging. We can be more ambitious: in later chapters we will explore
echniques, in particular typing and assertions, meant to help build software
 from the start — rather than debugging it into correctness. Debugging and
 indispensable, of course, as a means of double-checking the result. 
ssible to go further and take a completely formal approach to software
This book falls short of such a goal, as suggested by the somewhat timid
”, “guarantee” and “ensure” used above in preference to the word “prove”.
the techniques described in later chapters come directly from the work on
 techniques for formal program specification and verification, and go a long
ensuring the correctness ideal. 
s
omplements correctness. Correctness addresses the behavior of a system in
d by its specification; robustness characterizes what happens outside of
tion. 
Definition: robustness
ness is the ability of software systems to react appropriately to
al conditions. 
Operating System
Base library
Kernel library
Hardware 
Compiler
SPECIFICATION
Correctness
Robustness
SOFTWARE QUALITY §1.26
As reflected by the wording of its definition, robustness is by nature a more fuzzy
notion than correctness. Since we are concerned here with cases not covered by the
specification, it is not possible to say, as with correctness, that the system should “perform
its tasks” in such a case; were these tasks known, the abnormal case would become part
of the specifi
This def
handling
certain s
specifica
normal —
prefer no
“planned
erroneou
subjectiv
There w
of the robustn
not cause cata
execution cle
Extendibil
Software is s
change a prog
The pro
not a difficult
A large softw
pulling out an
We nee
phenomenon 
Information S
invalidate the
computation,
the next, our 
Traditio
change, relyin
stage freezes
building a sol
was to develo
worry about w
Extend
specifi
cation and we would be back in the province of correctness.
inition of “abnormal case” will be useful again when we study exception
. It implies that the notions of normal and abnormal case are always relative to a
pecification; an abnormal case is simply a case that is not covered by the
tion. If you widen the specification, cases that used to be abnormal become
 even if they correspond to events such as erroneous user input that you would
t to happen. “Normal” in this sense does not mean “desirable”, but simply
 for in the design of the software”. Although it may seem paradoxical at first that
s input should be called a normal case, any other approach would have to rely on
e criteria, and sowould be useless.
ill always be cases that the specification does not explicitly address. The role
ess requirement is to make sure that if such cases do arise, the system does
strophic events; it should produce appropriate error messages, terminate its
anly, or enter a so-called “graceful degradation” mode. 
ity
upposed to be soft, and indeed is in principle; nothing can be easier than to
ram if you have access to its source code. Just use your favorite text editor. 
blem of extendibility is one of scale. For small programs change is usually
 issue; but as software grows bigger, it becomes harder and harder to adapt.
are system often looks to its maintainers as a giant house of cards in which
y one element might cause the whole edifice to collapse. 
d extendibility because at the basis of all software lies some human
and hence fickleness. The obvious case of business software (“Management
ystems”), where passage of a law or a company’s acquisition may suddenly
 assumptions on which a system rested, is not special; even in scientific
 where we may expect the laws of physics to stay in place from one month to
way of understanding and modeling physical systems will change.
nal approaches to software engineering did not take enough account of
g instead on an ideal view of the software lifecycle where an initial analysis
 the requirements, the rest of the process being devoted to designing and
ution. This is understandable: the first task in the progress of the discipline
p sound techniques for stating and solving fixed problems, before we could
hat to do if the problem changes while someone is busy solving it. But now
Definition: extendibility
ibility is the ease of adapting software products to changes of
cation. 
On exception 
handling see 
chapter 12.
§1.2 A REVIEW OF EXTERNAL FACTORS 7
with the basic software engineering techniques in place it has become essential to
recognize and address this central issue. Change is pervasive in software development:
change of requirements, of our understanding of the requirements, of algorithms, of data
representation, of implementation techniques. Support for change is a basic goal of object
technology an
Althoug
small exampl
projects. Two
• Design 
than a c
• Decentr
a simple
than trig
The obj
which helps 
large systems
in the discuss
Reusability
The need for 
similar patter
solutions to p
reusable softw
Reusabi
reusability pr
more effort m
as correctness
Here ag
properly reco
problem befo
growth of sof
become a pre
Reusabi
of which is in
concrete bene
Reusab
of man
Chapter 4.
d a running theme through this book.
h many of the techniques that improve extendibility may be introduced on
es or in introductory courses, their relevance only becomes clear for larger
 principles are essential for improving extendibility: 
simplicity: a simple architecture will always be easier to adapt to changes
omplex one. 
alization: the more autonomous the modules, the higher the likelihood that
 change will affect just one module, or a small number of modules, rather
gering off a chain reaction of changes over the whole system. 
ect-oriented method is, before anything else, a system architecture method
designers produce systems whose structure remains both simple (even for
) and decentralized. Simplicity and decentralization will be recurring themes
ions leading to object-oriented principles in the following chapters.
reusability comes from the observation that software systems often follow
ns; it should be possible to exploit this commonality and avoid reinventing
roblems that have been encountered before. By capturing such a pattern, a
are element will be applicable to many different developments.
lity has an influence on all other aspects of software quality, for solving the
oblem essentially means that less software must be written, and hence that
ay be devoted (for the same total cost) to improving the other factors, such
 and robustness.
ain is an issue that the traditional view of the software lifecycle had not
gnized, and for the same historical reason: you must find ways to solve one
re you worry about applying the solution to other problems. But with the
tware and its attempts to become a true industry the need for reusability has
ssing concern.
lity will play a central role in the discussions of the following chapters, one
 fact devoted entirely to an in-depth examination of this quality factor, its
fits, and the issues it raises. 
Definition: reusability
ility is the ability of software elements to serve for the construction
y different applications.
SOFTWARE QUALITY §1.28
Compatibility 
Compatibility
they need to i
they make co
variety of inc
directly use a
Lack of
DALLAS
on its sw
handle c
AMR cut
supposed
Hotels C
translate
company
As far ba
200 prog
main pie
develope
each oth
Different
bridge.
AMR Info
[…] In la
The ke
standardized 
• Standar
sequenc
• Standar
well, ar
• Standar
where a
standard
More ge
important ent
and the obje
CORBA and 
Definition: compatibility
Compatibility is the ease of combining software elements with others. 
 
uly 
 in 
” 
p, 
. 
.
 
r 6.
 is important because we do not develop software elements in a vacuum:
nteract with each other. But they too often have trouble interacting because
nflicting assumptions about the rest of the world. An example is the wide
ompatible file formats supported by many operating systems. A program can
nother’s result as input only if the file formats are compatible. 
 compatibility can yield disaster. Here is an extreme case:
 — Last week, AMR, the parent company of American Airlines, Inc., said it fell
ord trying to develop a state-of-the-art, industry-wide system that could also
ar and hotel reservations.
 off development of its new Confirm reservation system only weeks after it was
 to start taking care of transactions for partners Budget Rent-A-Car, Hilton
orp. and Marriott Corp. Suspension of the $125 million, 4-year-old project
d into a $165 million pre-tax charge against AMR’s earnings and fractured the
’s reputation as a pacesetter in travel technology. […]
ck as January, the leaders of Confirm discovered that the labors of more than
rammers, systems analysts and engineers had apparently been for naught. The
ces of the massive project — requiring 47,000 pages to describe — had been
d separately, by different methods. When put together, they did not work with
er. When the developers attempted to plug the parts together, they could not.
 “modules” could not pull the information needed from the other side of the
rmation Services fired eight senior project members, including the team leader.
te June, Budget and Hilton said they were dropping out.
y to compatibility lies in homogeneity of design, and in agreeing on
conventions for inter-program communication. Approaches include: 
dized file formats, as in the Unix system, where every text file is simply a
e of characters. 
dized data structures, as in Lisp systems, where all data, and programs as
e represented by binary trees (called lists in Lisp). 
dized user interfaces, as on various versions of Windows, OS/2 and MacOS,
ll tools rely on a single paradigm for communication with the user, based on
 components such as windows, icons, menus etc. 
neral solutions are obtained by defining standardized access protocols to all
ities manipulated by the software. This is the idea behind abstract data types
ct-oriented approach, as well as so-called middleware protocols such as
Microsoft’s OLE-COM (ActiveX).
San Jose (Calif.)
Mercury News, J
20, 1992. Quoted
the “comp l risks
Usenet newsgrou
13.67, July 1992
Slightly abridged
On abstract data
types see chapte
§1.2 A REVIEW OF EXTERNAL FACTORS 9
Efficiency
Almost synon
showstwo typ
• Some de
a lot of 
• But a ge
such in
compute
It is not 
times, as in a 
Where i
micro-optimiz
not correct (s
close to the 
efficiency mu
optimizations
Furthermore,
relaxed attitud
All this,
wait for the re
a program. So
is so slow or 
important” w
This issu
not likely to 
requires taki
correctness, a
and bound to 
For som
engineers, it i
must reconcil
of correct com
and from lim
well as the be
Definition: efficiency
Efficie
possibl
interna
ymous with efficiency is the word “performance”. The software community
ical attitudes towards efficiency: 
velopers have an obsession with performance issues, leading them to devote
efforts to presumed optimizations. 
neral tendency also exists to downplay efficiency concerns, as evidenced by
dustry lore as “make it right before you make it fast” and “next year’s
r model is going to be 50% faster anyway”. 
uncommon to see the same person displaying these two attitudes at different
software case of split personality (Dr. Abstract and Mr. Microsecond). 
s the truth? Clearly, developers have often shown an exaggerated concern for
ation. As already noted, efficiency does not matter much if the software is
uggesting a new dictum, “do not worry how fast it is unless it is also right”,
previous one but not quite the same). More generally, the concern for
st be balanced with other goals such as extendibility and reusability; extreme
 may make the software so specialized as to be unfit for change and reuse.
 the ever growing power of computer hardware does allow us to have a more
e about gaining the last byte or microsecond. 
 however, does not diminish the importance of efficiency. No one likes to
sponses of an interactive system, or to have to purchase more memory to run
 offhand attitudes to performance include much posturing; if the final system
bulky as to impede usage, those who used to declare that “speed is not that
ill not be the last to complain. 
e reflects what I believe to be a major characteristic of software engineering,
move away soon: software construction is difficult precisely because it
ng into account many different requirements, some of which, such as
re abstract and conceptual, whereas others, such as efficiency, are concrete
the properties of computer hardware.
e scientists, software development is a branch of mathematics; for some
s a branch of applied technology. In reality, it is both. The software developer
e the abstract concepts with their concrete implementations, the mathematics
putation with the time and space constraints deriving from physical laws
itations of current hardware technology. This need to please the angels as
asts may be the central challenge of software engineering.
ncy is the ability of a software system to place as few demands as
e on hardware resources, such as processor time, space occupied in
l and external memories, bandwidth used in communication devices.
SOFTWARE QUALITY §1.210
The constant improvement in computer power, impressive as it is, is not an excuse
for overlooking efficiency, for at least three reasons: 
• Someone who purchases a bigger and faster computer wants to see some actual
benefit from the extra power — to handle new problems, process previous problems
faster, o
time. U
of time 
• One of t
the lead
fast as th
n that ca
in O (n)
you to h
new ma
certain c
much of
• In some
compute
example
from th
between
thought
that take
Another 
a window
that the m
the keybo
In this ca
of correc
conseque
mail mes
broken, e
Because
not on imple
performance 
discussion pre
solution is n
mechanism, b
object-oriente
so based on th
time and in sp
of the techniq
r process bigger versions of the previous problems in the same amount of
sing the new computer to process the previous problems in the same amount
will not do! 
he most visible effects of advances in computer power is actually to increase
 of good algorithms over bad ones. Assume that a new machine is twice as
e previous one. Let n be the size of the problem to solve, and N the maximum
n be handled by a certain algorithm in a given time. Then if the algorithm is
, that is to say, runs in a time proportional to n, the new machine will enable
andle problem sizes of about 2 ∗ N for large N. For an algorithm in O (n2) the
chine will only yield a 41% increase of N. An algorithm in O (2n), similar to
ombinatorial, exhaustive-search algorithms, would just add one to N — not
 an improvement for your money.
 cases efficiency may affect correctness. A specification may state that the
r response to a certain event must occur no later than a specified time; for
, an in-flight computer must be prepared to detect and process a message
e throttle sensor fast enough to take corrective action. This connection
 efficiency and correctness is not restricted to applications commonly
 of as “real time”; few people are interested in a weather forecasting model
s twenty-four hours to predict the next day’s weather.
example, although perhaps less critical, has been of frequent annoyance to me:
 management system that I used for a while was sometimes too slow to detect
ouse cursor had moved from a window to another, so that characters typed at
ard, meant for a certain window, would occasionally end up in another.
se a performance limitation causes a violation of the specification, that is to say
tness, which even in seemingly innocuous everyday applications can cause nasty
nces: think of what can happen if the two windows are used to send electronic
sages to two different correspondents. For less than this marriages have been
ven wars started. 
 this book is focused on the concepts of object-oriented software engineering,
mentation issues, only a few sections deal explicitly with the associated
costs. But the concern for efficiency will be there throughout. Whenever the
sents an object-oriented solution to some problem, it will make sure that the
ot just elegant but also efficient; whenever it introduces some new O-O
e it garbage collection (and other approaches to memory management for
d computation), dynamic binding, genericity or repeated inheritance, it will do
e knowledge that the mechanism may be implemented at a reasonable cost in
ace; and whenever appropriate it will mention the performance consequences
ues studied.
§1.2 A REVIEW OF EXTERNAL FACTORS 11
Efficiency is only one of the factors of quality; we should not (like some in the
profession) let it rule our engineering lives. But it is a factor, and must be taken into
consideration, whether in the construction of a software system or in the design of a
programming language. If you dismiss performance, performance will dismiss you.
Portability
Portability ad
hardware-so
operating sys
rest of this bo
machine; an e
Many o
observer the o
in general an
makes portab
Ease of use
The definition
poses one of t
to provide de
users who jus
As with
of use is stru
thought-out s
condition is n
difficult and 
terms), but it 
This is o
many O-O te
yield powerfu
several exam
Portab
and sof
Ease o
qualifi
problem
 
dresses variations not just of the physical hardware but more generally of the
ftware machine, the one that we really program, which includes the
tem, the window system if applicable, and other fundamental tools. In the
ok the word “platform” will be used to denote a type of hardware-software
xample of platform is “Intel X86 with Windows NT” (known as “Wintel”).
f the existing platform incompatibilities are unjustified, and to a naïve
nly explanation sometimes seems to be a conspiracy to victimize humanity
d programmers in particular. Whatever its causes, however, this diversity
ility a major concern for both developers and users of software. 
 insists on the various levels of expertise of potential users. This requirementhe major challenges to software designers preoccupied with ease of use: how
tailed guidance and explanations to novice users, without bothering expert
t want to get right down to business. 
 many of the other qualities discussed in this chapter, one of the keys to ease
ctural simplicity. A well-designed system, built according to a clear, well
tructure, will tend to be easier to learn and use than a messy one. The
ot sufficient, of course (what is simple and clear to the designer may be
obscure to users, especially if explained in designer’s rather than user’s
helps considerably. 
ne of the areas where the object-oriented method is particularly productive;
chniques, which appear at first to address design and implementation, also
l new interface ideas that help the end users. Later chapters will introduce
ples. 
Definition: portability
ility is the ease of transferring software products to various hardware
tware environments. 
Definition: ease of use
f use is the ease with which people of various backgrounds and
cations can learn to use software products and apply them to solve
s. It also covers the ease of installation, operation and monitoring. 
SOFTWARE QUALITY §1.212
Software designers preoccupied with ease of use will also be well-advised to
consider with some mistrust the precept most frequently quoted in the user interface
literature, from an early article by Hansen: know the user. The argument is that a good
designer must make an effort to understand the system’s intended user community. This
view ignores 
audience. (Tw
problem of th
and Unix, me
group will rel
Good u
assumptions 
may expect t
mouse, click 
specialized ap
basic concept
Functional
One of the 
functionality 
featurism (of
internal proje
worse for com
review is ofte
Featuris
other. The ea
new features,
“bells and w
comments sh
come out of n
What to me lo
The sol
product, tryin
based on a sm
should all be 
be visible, an
F
See Wilfred J. 
Hansen, “User 
Engineering Princi-
ples for Interactive 
Systems”, Proceed-
 
.
 
one of the features of successful systems: they always outgrow their initial
o old and famous examples are Fortran, conceived as a tool to solve the
e small community of engineers and scientists programming the IBM 704,
ant for internal use at Bell Laboratories.) A system designed for a specific
y on assumptions that simply do not hold for a larger audience. 
ser interface designers follow a more prudent policy. They make as limited
about their users as they can. When you design an interactive system, you
hat users are members of the human race and that they can read, move a
a button, and type (slowly); not much more. If the software addresses a
plication area, you may perhaps assume that your users are familiar with its
s. But even that is risky. To reverse-paraphrase Hansen’s advice:
ity
most difficult problems facing a project leader is to know how much
is enough. The pressure for more facilities, known in industry parlance as
ten “creeping featurism”), is constantly there. Its consequences are bad for
cts, where the pressure comes from users within the same company, and
mercial products, as the most prominent part of a journalist’s comparative
n the table listing side by side the features offered by competing products.
m is actually the combination of two problems, one more difficult than the
sier problem is the loss of consistency that may result from the addition of
 affecting its ease of use. Users are indeed known to complain that all the
histles” of a product’s new version make it horrendously complex. Such
ould be taken with a grain of salt, however, since the new features do not
owhere: most of the time they have been requested by users — other users.
oks like a superfluous trinket may be an indispensable facility to you.
ution here is to work again and again on the consistency of the overall
g to make everything fit into a general mold. A good software product is
all number of powerful ideas; even if it has many specialized features, they
explainable as consequences of these basic concepts. The “grand plan” must
d everything should have its place in it.
User Interface Design principle
Do not pretend you know the user; you don’t.
Definition: functionality
unctionality is the extent of possibilities provided by a system. 
ings of FJCC 39,
AFIPS Press, 
Montvale (NJ), 
1971, pp 523-532
§1.2 A REVIEW OF EXTERNAL FACTORS 13
The more difficult problem is to avoid being so focused on features as to forget the
other qualities. Projects commonly make such a mistake, a situation vividly pictured by
Roger Osmond in the form of two possible paths to a project’s completion:
The bott
the developm
right at last, c
forced to rele
the outcome m
What O
techniques of
project for a
extendibility a
the features y
This me
mentioned, b
end. Even if 
sooner (althou
that the decis
squares in the
assessment of
set to attract p
enough?” (as 
As any 
advice than to
by the better o
in a later chap
Osmond’s 
curves; after 
[Osmond 1995]
early
releases
Envisaged
om curve (black) is all too common: in the hectic race to add more features,
ent loses track of the overall quality. The final phase, intended to get things
an be long and stressful. If, under users’ or competitors’ pressure, you are
ase the product early — at stages marked by black squares in the figure —
ay be damaging to your reputation.
smond suggests (the color curve) is, aided by the quality-enhancing
 O-O development, to maintain the quality level constant throughout the
ll aspects but functionality. You just do not compromise on reliability,
nd the like: you refuse to proceed with new features until you are happy with
ou have.
thod is tougher to enforce on a day-to-day basis because of the pressures
ut yields a more effective software process and often a better product in the
the final result is the same, as assumed in the figure, it should be reached
gh the figure does not show time). Following the suggested path also means
ion to release an early version — at one of the points marked by colored
 figure — becomes, if not easier, at least simpler: it will be based on your
 whether what you have so far covers a large enough share of the full feature
rospective customers rather than drive them away. The question “is it good
in “will it not crash?”) should not be a factor.
reader who has led a software project will know, it is easier to approve such
 apply it. But every project should strive to follow the approach represented
ne of the two Osmond curves. It goes well with the cluster model introduced
ter as the general scheme for disciplined object-oriented development.
Other qualities
Functionality
Common
Desirable
Debugging
SOFTWARE QUALITY §1.214
Timeliness
Timeliness is
appears too la
evolve as qui
Timelin
announced th
making, wou
(at the top of 
page headline
Other qual
Other qualitie
people who p
• Verifia
procedu
operatio
• Integrit
(program
• Repaira
• Econom
or below
About doc
In a list of s
documentatio
the need for d
may distingu
• The nee
of a syst
• The ne
understa
extendib
• The nee
understa
implem
extendib
whether
Definition: timeliness
Timeliness is the ability of a software system to be released when or before
its use
r-
. 
 one of the great frustrations of our industry. A great software product that
te might miss its target altogether. This is true in other industries too, but few
ckly as software.
ess is still, for large projects, an uncommon phenomenon. When Microsoft
at the latest release of its principal operating system, several years in the
ld be delivered one month early, the event was newsworthy enough to make
an article recalling the lengthy delays that affected earlier projects) the front-