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

Object Oriented Software Construction - Bertrand Meyer


DisciplinaProgramação Orientada A Objetos3.307 materiais50.547 seguidores
Pré-visualização50 páginas
text of the component itself; tools for
n, indexing or retrieval can then process the component to extract the needed
rmation. Having the information included in each component is preferable
lsewhere, for example in a database of information about components. 
ntinuity
 is directly connected to the general goal of extendibility. As emphasized in
pter, change is an integral part of the software construction process. The
 will almost inevitably change as the project progresses. Continuity means
nges should affect individual modules in the structure of the system, rather
ture itself. 
 \u201ccontinuity\u201d is drawn from an analogy with the notion of a continuous
athematical analysis. A mathematical function is continuous if (informally)
e in the argument will yield a proportionally small change in the result. Here
considered is the software construction method, which you can view as a
r obtaining systems from specifications: 
e_construction_method: Specification \u2192 System
od satisfies Modular Continuity if, in the software architectures that
s, a small change in a problem specification will trigger a change of
e module, or a small number of modules.
See also, later in t
chapter, \u201cSelf-
Documentation\u201d,
page 54.
See \u201cExtendibility
page 6.
§3.1 FIVE CRITERIA 45
This ma
size for softw
measure of w
for the specifi
the concepts s
modular meth
\u2022 Exampl
from us
names, a
or Ada, 
the nota
constant
since co
\u2022 Exampl
should b
as data 
warrant
\u2022 Counter
designs 
that are 
\u2022 Counter
which d
time, ma
Modular pr
A meth
effect o
confine
module
Continuity
This will be one of 
our principles of 
style: Symbolic 
Constant Principle, 
page 884.
See \u201cUniform 
Access\u201d, page 55.
thematical term only provides an analogy, since we lack formal notions of
are. More precisely, it would be possible to define a generally acceptable
hat constitutes a \u201csmall\u201d or \u201clarge\u201d change to a program; but doing the same
cations is more of a challenge. If we make no pretense of full rigor, however,
hould be intuitively clear and correspond to an essential requirement on any
od. 
e 1: symbolic constants. A sound style rule bars the instructions of a program
ing any numerical or textual constant directly; instead, they rely on symbolic
nd the actual values only appear in a constant definition (constant in Pascal
preprocessor macros in C, PARAMETER in Fortran 77, constant attributes in
tion of this book). If the value changes, the only thing to update is the
 definition. This small but important rule is a wise precaution for continuity
nstants, in spite of their name, are remarkably prone to change. 
e 2: the Uniform Access principle. Another rule states that a single notation
e available to obtain the features of an object, whether they are represented
fields or computed on demand. This property is sufficiently important to
 a separate discussion later in this chapter. 
-example 1: using physical representations. A method in which program
are patterned after the physical implementation of data will yield designs
very sensitive to slight changes in the environment. 
-example 2: static arrays. Languages such as Fortran or standard Pascal,
o not allow the declaration of arrays whose bounds will only be known at run
ke program evolution much harder. 
otection
od satisfies Modular Protection if it yields architectures in which the
f an abnormal condition occurring at run time in a module will remain
d to that module, or at worst will only propagate to a few neighboring
s.
MODULARITY §3.246
The underlying issue, that of failures and errors, is central to software engineering. The
errors considered here are run-time errors, resulting from hardware failures, erroneous
input or exhaustion of needed resources (for example memory storage). The criterion does
not address the avoidance or correction of errors, but the aspect that is directly relevant to
modularity: th
\u2022 Exampl
module
modula
\u2022 Counter
C++ an
may be 
part of t
(Details
in this r
for norm
carefull
investig
3.2 FIVE
From the pr
modularity: 
\u2022 Direct M
\u2022 Few Int
\u2022 Small in
\u2022 Explicit
\u2022 Informa
The firs
systems with
modules wil
communicati
The question of how 
to handle abnormal 
cases is discussed in 
detail in chapter 12.
in 
t an 
h-
-
12. 
eir propagation.
e: validating input at the source. A method requiring that you make every
 that inputs data also responsible for checking their validity is good for
r protection. 
-example: undisciplined exceptions. Languages such as PL/I, CLU, Ada,
d Java support the notion of exception. An exception is a special signal that
\u201craised\u201d by a certain instruction and \u201chandled\u201d in another, possibly remote
he system. When the exception is raised, control is transferred to the handler.
 of the mechanism vary between languages; Ada or CLU are more disciplined
espect than PL/I.) Such facilities make it possible to decouple the algorithms
al cases from the processing of erroneous cases. But they must be used
y to avoid hindering modular protection. The chapter on exceptions will
ate how to design a disciplined exception mechanism satisfying the criterion.
 RULES 
eceding criteria, five rules follow which we must observe to ensure
apping. 
erfaces. 
terfaces (weak coupling). 
 Interfaces. 
tion Hiding. 
t rule addresses the connection between a software system and the external
 which it is connected; the next four all address a common issue \u2014 how
l communicate. Obtaining good modular architectures requires that
on occur in a controlled and disciplined way. 
Protection 
violation
More on this topic 
\u201cAssertions are no
input checking mec
anism\u201d, page 346
On exception han
dling, see chapter 
§3.2 FIVE RULES 47
Direct Mapping 
Any software system attempts to address the needs of some problem domain. If you have
a good model for describing that domain, you will find it desirable to keep a clear
correspondence (mapping) between the structure of the solution, as provided by the
software, and
This adv
\u2022 Continu
structur
\u2022 Decomp
structur
decomp
Few Interfa
The Few Inte
modules in a 
Commu
each other (if 
the number o
More p
intermodule c
in the figure, 
This rul
are too many
The m
should
of mod
Ev
Types of module 
interconnection 
structures
(
 the structure of the problem, as described by the model. Hence the first rule:
ice follows in particular from two of the modularity criteria: 
ity: keeping a trace of the problem\u2019s modular structure in the solution\u2019s
e will make it easier to assess and limit the impact of changes. 
osability: if some work has already been done to analyze the modular
e of the problem domain, it may provide a good starting point for the modular
osition of the software. 
ces
rfaces rule restricts the overall number of communication channels between
software architecture: 
nication may occur between modules in a variety of ways. Modules may call
they are procedures), share data structures etc. The Few Interfaces rule limits
f such connections.
recisely, if a system is composed of n modules, then the number of
onnections should remain much closer to the minimum,
 n\u20131, shown as (A)
than to the maximum, n (n \u2013 1) /2, shown as (B).
e follows in particular from the criteria of continuity and protection: if there
 relations between modules, then the effect of a change or of an error may
odular structure devised in the process of building a software system
 remain compatible with any modular structure devised in the process
eling the problem domain.
ery module should communicate with as few others as possible.
A) (B) (C)
MODULARITY §3.248
propagate to a large number of modules. It is also connected to composability (if you want
a module to be usable by itself in a new environment,