Object Oriented Software Construction - Bertrand Meyer
1370 pág.

Object Oriented Software Construction - Bertrand Meyer


DisciplinaProgramação Orientada A Objetos3.307 materiais50.532 seguidores
Pré-visualização50 páginas
for
ook, which became a full-fledged discussion of object technology for
 starts with a short technical presentation couched in business terms and
h an analysis of management issues (lifecycle, project management, reuse
nother management-oriented book, [Goldberg 1995], provides a
ry perspective on many important topics. [Baudoin 1996] stresses lifecycle
 importance of standards.
 back to technical presentations, three influential books on object-oriented
ritten by the designers of these languages, contain general methodological
at make them of interest to readers who do not use the languages or might
al of them. (The history of programming languages and books about them
signers are not always the best to write about their own creations, but in these
re.) The books are:
BEGIN [Birtwistle 1973]. (Here two other authors joined the language
rs Nygaard and Dahl.)
lk-80: The Language and its Implementation [Goldberg 1983].
+ Programming Language, second edition [Stroustrup 1991].
cently, some introductory programming textbooks have started to use object-
 right from the start, as there is no reason to let \u201contogeny repeat phylogeny\u201d,
 take the poor students through the history of the hesitations and mistakes
h their predecessors arrived at the right ideas. The first such text (to my
as [Rist 1995]. Another good book covering similar needs is [Wiener
next level \u2014 textbooks for a second course on programming, discussing data
 algorithms based on the notation of this book \u2014 you will find [Gore 1996]
1997]; [Jézéquel 1996] presents the principles of object-oriented software
net newsgroup comp.object, archived on several sites around the Web, is the
m of discussion for many issues of object technology. As with all such
repared for a mixture of the good, the bad and the ugly. The Object
epartment of Computer (IEEE), which I have edited since it started in 1995,
nvited columns by leading experts.
es devoted to Object Technology include:
CRITERIA FOR OBJECT ORIENTATION §2.636
\u2022 The Journal of Object-Oriented Programming (the first journal in the field,
emphasizing technical discussions but for a large audience), Object Magazine (of a
more general scope, with some articles for managers), Objekt Spektrum (German),
Object Currents (on-line), all described at http://www.sigs.com.
\u2022 Theory 
\u2022 L\u2019OBJE
The ma
http://www.a
http://www.s
Systems), org
home page at
and the topics
and Practice of Object Systems, an archival journal.
T (French), described at http://www.tools.com/lobjet.
jor international O-O conferences are OOPSLA (yearly, USA or Canada, see
cm.org); Object Expo (variable frequency and locations, described at
igs.com); and TOOLS (Technology of Object-Oriented Languages and
anized by ISE with three sessions a year (USA, Europe, Pacific), whose
 http://www.tools.com also serves as a general resource on object technology
 of this book.
3 
Modularit
From the g
introduced in
autonomous 
modularity to
Modula
assemblies of
extendibility 
resulting pie
architectures.
A softw
software sys
structure. Th
what precise 
focus will be
construction 
implementati
As it tu
software qual
introduces a s
of modularity
modular desi
For the
important as 
mutually inde
violating som
principles follow from the rules. 
You might expect this chapter to begin with a precise description of what a module
looks like. This is not the case, and for a good reason: our goal for the exploration of
modularity issues, in this chapter and the next two, is precisely to analyze the properties
which a satisfactory module structure must satisfy; so the form of modules will be a
conclusion of the discussion, not a premise. Until we reach that conclusion the word
y 
oals of extendibility and reusability, two of the principal quality factors
 chapter 1, follows the need for flexible system architectures, made of
software components. This is why chapter 1 also introduced the term
 cover the combination of these two quality factors. 
r programming was once taken to mean the construction of programs as
 small pieces, usually subroutines. But such a technique cannot bring real
and reusability benefits unless we have a better way of guaranteeing that the
ces \u2014 the modules \u2014 are self-contained and organized in stable
 Any comprehensive definition of modularity must ensure these properties. 
are construction method is modular, then, if it helps designers produce
tems made of autonomous elements connected by a coherent, simple
e purpose of this chapter is to refine this informal definition by exploring
properties such a method must possess to deserve the \u201cmodular\u201d label. The
 on design methods, but the ideas also apply to earlier stages of system
(analysis, specification) and must of course be maintained at the
on and maintenance stages. 
rns out, a single definition of modularity would be insufficient; as with
ity, we must look at modularity from more than one viewpoint. This chapter
et of complementary properties: five criteria, five rules and five principles
 which, taken collectively, cover the most important requirements on a
gn method. 
 practicing software developer, the principles and the rules are just as
the criteria. The difference is simply one of causality: the criteria are
pendent \u2014 and it is indeed possible for a method to satisfy one of them while
e of the others \u2014 whereas the rules follow from the criteria and the
MODULARITY §3.140
\u201cmodule\u201d will denote the basic unit of decomposition of our systems, whatever it actually
is. If you are familiar with non-object-oriented methods you will probably think of the
subroutines present in most programming and design languages, or perhaps of packages
as present in Ada and (under a different name) in Modula. The discussion will lead in a
later chapter 
you have enco
to understand
well.
3.1 FIVE
A design me
requirements
\u2022 Decomp
\u2022 Compos
\u2022 Underst
\u2022 Continu
\u2022 Protecti
Modular de
The process 
enough to req
A soft
helps i
less co
enough
il-
to the O-O form of module \u2014 the class \u2014 which supersedes these ideas. If
untered classes and O-O techniques before, you should still read this chapter
 the requirements that classes address, a prerequisite if you want to use them
 CRITERIA 
thod worthy of being called \u201cmodular\u201d should satisfy five fundamental
, explored in the next few sections: 
osability. 
ability. 
andability. 
ity. 
on. 
composability
will often be self-repeating since each subproblem may still be complex
uire further decomposition.
ware construction method satisfies Modular Decomposability if it
n the task of decomposing a software problem into a small number of
mplex subproblems, connected by a simple structure, and independent
 to allow further work to proceed separately on each of them
Decomposab
ity
§3.1 FIVE CRITERIA 41
A corollary of the decomposability requirement is division of labor: once you have
decomposed a system into subsystems you should be able to distribute work on these
subsystems among different people or groups. This is a difficult goal since it limits the
dependencies that may exist between the subsystems: 
\u2022 You mu
of each s
\u2022 The dep
subsyste
appear t
satisfyin
The mo
criterion is to
description of
decomposing
until all the re
implementati
A typic
software syst
system will n
or the initializ
its first direct
all modules o
module will e
same stage o
would endang
authorization
the system an
initialization 
other modul
decomposabi
In the ob
its own d
As discussed below, 
top-down design is 
not as well suited to 
other modularity 
criteria.
A top-down 
hierarchy
C1
The term \u201ctemporal 
cohesion\u201d comes 
from the method 
known as structured 
design; see the bib-
liographical notes.
st keep such dependencies to the bare minimum; otherwise the