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

Object Oriented Software Construction - Bertrand Meyer


DisciplinaProgramação Orientada A Objetos3.976 materiais57.899 seguidores
Pré-visualização50 páginas
must be a direct correspondence
 specification, design and implementation modules. 
apping: to maintain a clear correspondence between the structure of the
and the structure of the solution, you must have a clear syntactical
ation of the conceptual units on both sides, reflecting the division suggested
 development method.
osability: to divide system development into separate tasks, you need to
ure that every task results in a well-delimited syntactic unit; at the
entation stage, these units must be separately compilable. 
ability: how could we combine anything other than modules with
guous syntactic boundaries? 
on: you can only hope to control the scope of errors if modules are
cally delimited. 
entation
 of Information Hiding, the Self-Documentation principle governs how we
ent modules:
is precludes is the common situation in which information about the module
arate project documents.
mentation under review here is internal documentation about components of
are, not user documentation about the resulting product, which may require
products, whether paper, CD-ROM or Web pages \u2014 although, as noted in the
n of software quality, one may see in the modern trend towards providing more
 on-line help a consequence of the same general idea.
st obvious justification for the Self-Documentation principle is the criterion
nderstandability. Perhaps more important, however, is the role of this
Self-Documentation principle
signer of a module should strive to make all information about the
e part of the module itself.
\u201cAbout documen-
tation\u201d, page 14. 
§3.3 FIVE PRINCIPLES 55
principle in helping to meet the continuity criterion. If the software and its documentation
are treated as separate entities, it is difficult to guarantee that they will remain compatible
\u2014 \u201cin sync\u201d \u2014 when things start changing. Keeping everything at the same place,
although not a guarantee, is a good way to help maintain this compatibility.
Innocuo
software eng
practices. The
engineers, ne
for every gram
construction 
documentatio
Such an
comes back in
you risk findi
and the softw
documentatio
A major 
software,
Departm
Institute.
tend to sp
on softwa
case of la
This bo
documenting 
includes the d
its documenta
as documenta
should contai
In this a
One view, su
abstract inter
client module
rule of Inform
We wil
document the
Uniform Ac
Although it m
principle is in
and the suppo
it as a special
\u201cUsing assertions 
for documentation: 
the short form of a 
class\u201d, page 390. See 
also chapter 23 and 
its last two exercises.
Also known as the 
Uniform Reference 
principle. 
us as this principle may seem at first, it goes against much of what the
ineering literature has usually suggested as good software development
 dominant view is that software developers, to deserve the title of software
ed to do what other engineers are supposed to: produce a kilogram of paper
 of actual deliverable. The encouragement to keep a record of the software
process is good advice \u2014 but not the implication that software and its
n are different products. 
 approach ignores the specific property of software, which again and again
 this discussion: its changeability. If you treat the two products as separate,
ng yourself quickly in a situation where the documentation says one thing
are does something else. If there is any worse situation than having no
n, it must be having wrong documentation.
advance of the past few years has been the appearance of quality standards for
 such as ISO certification, the \u201c2167\u201d standard and its successors from the US
ent of Defense, and the Capability Maturity Model of the Software Engineering
 Perhaps because they often sprang out of models from other disciplines, they
ecify a heavy paper trail. Several of these standards could have a stronger effect
re quality (beyond providing a mechanism for managers to cover their bases in
ter trouble) by enforcing the Self-Documentation principle.
ok will draw on the Self-Documentation principle to define a method for
classes \u2014 the modules of object-oriented software construction \u2014 that
ocumentation of every module in the module itself. Not that the module is
tion: there is usually too much detail in the software text to make it suitable
tion (this was the argument for information hiding). Instead, the module
n its documentation.
pproach software becomes a single product that supports multiple views.
itable for compilation and execution, is the full source code. Another is the
face documentation of each module, enabling software developers to write
s without having to learn the module\u2019s own internals, in accordance with the
ation Hiding. Other views are possible.
l need to remember this rule when we examine the question of how to
 classes of object-oriented software construction.
cess 
ay at first appear just to address a notational issue, the Uniform Access
 fact a design rule which influences many aspects of object-oriented design
rting notation. It follows from the Continuity criterion; you may also view
 case of Information Hiding. 
MODULARITY §3.356
Let x be a name used to access a certain data item (what will later be called an object)
and f the name of a feature applicable to x. (A feature is an operation; this terminology will
also be defined more precisely.) For example, x might be a variable representing a bank
account, and f the feature that yields an account\u2019s current balance. Uniform Access
addresses the
does not mak
In most
of f to x depe
feature f: is t
Both techniqu
A1 \u2022 You ma
account
the bala
A2 \u2022 Or you 
record, 
this tech
comput
A comm
case A1 and f
Choosin
economizes o
of one of the 
at least once 
feature acces
charge of x\u2019s 
to change the
n deposit
withdrawal
ba
(A1)
(A2)
depos
withdrawa
 question of how to express the result of applying f to x, using a notation that
e any premature commitment as to how f is implemented.
 design and programming languages, the expression denoting the application
nds on what implementation the original software developer has chosen for
he value stored along with x, or must it be computed whenever requested?
es are possible in the example of accounts and their balances:
y represent the balance as one of the fields of the record describing each
, as shown in the figure. With this technique, every operation that changes
nce must take care of updating the balance field.
may define a function which computes the balance using other fields of the
for example fields representing the lists of withdrawals and deposits. With
nique the balance of an account is not stored (there is no balance field) but
ed on demand.
on notation, in languages such as Pascal, Ada, C, C++ and Java, uses x l f in
 (x) in case A2.
g between representations A1 and A2 is a space-time tradeoff: one
n computation, the other on storage. The resolution of this tradeoff in favor
solutions is typical of representation decisions that developers often reverse
during a project\u2019s lifetime. So for continuity\u2019s sake it is desirable to have a
s notation that does not distinguish between the two cases; then if you are in
implementation and change your mind at some stage, it will not be necessary
 modules that use f. This is an example of the Uniform Access principle.
Two 
representatio
for a bank 
account
s_list
s_list
lance
its_list
ls_list
§3.3 FIVE PRINCIPLES 57
In its general form the principle may be expressed as:
Few lan
the function c
should satisfy
in both cases.
The Open-C
Another requ
Closed princi
The con
of a different 
\u2022 A modu
be possi
\u2022 A modu
that the 
sense of
implies 
for othe
a modul
official 
publishi
The nee
different reas
it is almost im
need in its lif
changes and 
project manag
some others; 
command tex
Uniform Access