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

Object Oriented Software Construction - Bertrand Meyer

DisciplinaProgramação Orientada A Objetos3.960 materiais57.718 seguidores
Pré-visualização50 páginas
its many services,
will perform error detection, program formating, some configuration
 logging, report generation.
Another example is a typesetting program, taking input in some text processing
format \u2014 TEX, Microsoft Word, FrameMaker \u2026 \u2014 and generating output in HTML,
Postscript or Adobe Acrobat format. Again we may view it at first as just an input-to-
output filter. But most likely it will perform a number of other services as well, so it seems
more interest
to consider t
paragraphs, li
The see
Functions a
Not only is th
it may also, a
top-down de
continuity req
handles every
a session is 
a big chunk o
and see the re
The top
[B0] -- 
[B1] -- 
and so on. Th
in the followi
ing, when we are trying to characterize the system in the most general way,
he various types of data it manipulates: documents, chapters, sections,
nes, words, characters, fonts, running heads, titles, figures and others.
mingly obvious starting point of top-down design \u2014 the view that each new
fulfills a request for a specific function \u2014 is subject to doubt:
nd evolution
e main function often not the best criterion to characterize a system initially:
s the system evolves, be among the first properties to change, forcing the
signer into frequent redesign and defeating our attempts to satisfy the
r the example of a program that has two versions, a \u201cbatch\u201d one which
 session as a single big run over the problem, and an interactive one in which
a sequence of transactions, with a much finer grain of user-system
on. This is typical of large scientific programs, which often have a \u201clet it run
f computation for the whole night\u201d version and a \u201clet me try out a few things
sults at once then continue with something else\u201d version.
-down refinement of the batch version might begin as
Top-level abstraction
\u201cSolve a complete instance of the problem\u201d
First refinement
ead input values\u201d
ompute results\u201d
utput results\u201d
e top-down development of the interactive version, for its part, could proceed
ng style:
Real systems have no top.
\u201cProcess one transaction\u201d
down approa
different ver
This ex
down approac
batch and inte
actions will b
System archi
tends to use th
for its structu
The foc
system do for
most external
\u201cNew information provided by the user\u201d then
\u201cInput information\u201d
\u201cStore it\u201d
eif \u201cRequest for information previously given\u201d then 
\u201cRetrieve requested information\u201d
\u201cOutput it\u201d
eif \u201cRequest for result\u201d then 
if \u201cNecessary information available\u201d then 
\u201cRetrieve requested result\u201d
\u201cOutput it\u201d
\u201cAsk for confirmation of the request\u201d
if Yes then
\u201cObtain required information\u201d
\u201cCompute requested result\u201d
\u201cOutput result\u201d
this way, the development will yield an entirely different result. The top-
ch fails to account for the property that the final programs are but two
sions of the same software system \u2014 whether they are developed
or one has evolved from the other.
ample brings to light two of the most unpleasant consequences of the top-
h: its focus on the external interface (implying here an early choice between
ractive) and its premature binding of temporal relations (the order in which
e executed).
and software design
tecture should be based on substance, not form. But top-down development
e most superficial aspect of the system \u2014 its external interface \u2014 as a basis
us on external interfaces is inevitable in a method that asks \u201cWhat will the
 the end user?\u201d as the key question: the answer will tend to emphasize the
The user interface is only one of the components of a system. Often, it is also among
the most volatile, if only because of the difficulty of getting it right the first time; initial
versions may be of the mark, requiring experimentation and user feedback to obtain a
satisfactory solution. A healthy design method will try to separate the interface from the
rest of the sys
It is in f
using one of
interfaces, of
almost irrelev
The precedi
piece of the 
order in whic
ordering cons
are subject to
Recall t
As in th
Each is defin
followed by a
elements of t
design is not
considering s
tem, using more stable properties as the basis for system structuring.
act often possible to build the interface separately from the rest of the system,
 the many tools available nowadays to produce elegant and user-friendly
ten based on object-oriented techniques. The user interface then becomes
ant to the overall system design.
ng examples illustrate another drawback of top-down functional
n: premature emphasis on temporal constraints. Each refinement expands a
abstract structure into a more detailed control architecture, specifying the
h various functions (various pieces of the action) will be executed. Such
traints become essential properties of the system architecture; but they too
he two alternative candidate structures for the first refinement of a compiler:
ead program and produce sequence of tokens\u201d
arse sequence of tokens into abstract syntax tree\u201d
ecorate tree with semantic information\u201d
enerate code from decorated tree\u201d
\u201cInitialize data structures\u201d
\u201cAll function definitions processed\u201d
\u201cRead in next function definition\u201d
\u201cGenerate partial code\u201d
ill in cross references\u201d
e preceding example we start with two completely different architectures.
ed by a control structure (a sequence of instructions in the first case, a loop
n instruction in the second), implying strict ordering constraints between the
he structure. But freezing such ordering relations at the earliest stages of
 reasonable. Issues such as the number of passes in a compiler and the
of various activities (lexical analysis, parsing, semantic processing,
 have many possible solutions, which the designers must devise by
pace-time tradeoffs and other criteria which they do not necessarily master
Chapter 32 dis-
cusses techniques
and tools for use
at the beginning of a project. They can perform fruitful design and implementation work
on the components long before freezing their temporal ordering, and will want to retain
this sequencing freedom for as long as possible. Top-down functional design does not
provide such flexibility: you must specify the order of executing operations before you
have had a ch
Some d
top-down des
is the case, am
and with Mer
designer stud
the effect of 
execution. Th
operations tha
the software c
Ordering a
The observat
because even
of the least un
into the old t
misuse of the
The pro
system that it 
if it later tur
\u201cshopping lis
rather than te
book; we can
three operatio
a method foc
In the sh
too much imp
operations: y
being!) you h
rather than te
See the bibliogra-
phical notes for
references on the 
methods cited.
Chapter 11 pre-
sents assertions.
ance to understand properly what these operations will do.
esign methods that attempt to correct some of the deficiencies of functional
ign also suffer from this premature binding of temporal relationships. This
ong others, with the dataflow-directed method known as structured analysis
ise (a method popular in some European countries).
riented development, for its part, stays away from premature ordering. The
ies the various operations applicable to a certain kind of data, and specifies
each, but defers for as long as possible specifying the operations\u2019