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

Object Oriented Software Construction - Bertrand Meyer


DisciplinaProgramação Orientada A Objetos3.913 materiais57.357 seguidores
Pré-visualização50 páginas
execute
instructions. A processor can be an actual processing unit (the CPU of a computer), a
process on a c
The act
actions that w
hardware lev
software mac
software syst
The obj
the data struc
while the co
persistent rep
Process
computation,
need to consi
chapter; for 
computations
This lea
what a system
A note o
word dat
follow co
The term
in at leas
subprogr
functions
The reaso
of having
has no c
\u201caction\u201d 
Any dis
aspects; so m
we must cho
finding the m
units of funct
From th
and other m
functional de
instead, build
e 
0.
onventional operating system, or a \u201cthread\u201d if the OS is multi-threaded.
ions are the operations making up the computation. The exact form of the
e consider will depend on the level of granularity of our analysis: at the
el, actions are machine language operations; at the level of the hardware-
hine, they are instructions of the programming language; at the level of a
em, we can treat each major step of a complex algorithm as a single action. 
ects are the data structures to which the actions apply. Some of these objects,
tures built by a computation for its own purposes, are internal and exist only
mputation proceeds; others (contained in the files, databases and other
ositories) are external and may outlive individual computations.
ors will become important when we discuss concurrent forms of
 in which several sub-computations can proceed in parallel; then we will
der two or more processors, physical or virtual. But that is the topic of a later
the moment we can limit our attention to non-concurrent, or sequential
, relying on a single processor which will remain implicit.
ves us with actions and objects. The duality between actions and objects \u2014
 does vs. what it does it to \u2014 is a pervasive theme in software engineering.
f terminology. Synonyms are available to denote each of the two aspects: the
a will be used here as a synonym for objects; for action the discussion will often
mmon practice and talk about the functions of a system.
 \u201cfunction\u201d is not without disadvantages, since software discussions also use it
t two other meanings: the mathematical sense, and the programming sense of
am returning a result. But we can use it without ambiguity in the phrase
 the
 of a system, which is what we need here.
n for using this word rather than \u201caction\u201d is the mere grammatical convenience
 an associated adjective, used in the phrase functional decomposition. \u201cAction\u201d
omparable derivation. Another term whose meaning is equivalent to that of
for the purpose of this discussion is operation.
cussion of software issues must account for both the object and function
ust the design of any software system. But there is one question for which
ose \u2014 the question of this chapter: what is the appropriate criterion for
odules of a system? Here we must decide whether modules will be built as
ional decomposition, or around major types of objects.
e answer will follow the difference between the object-oriented approach
ethods. Traditional approaches build each module around some unit of
composition \u2014 a certain piece of the action. The object-oriented method,
s each module around some type of objects.
Concurrency is th
topic of chapter 3
§5.2 FUNCTIONAL DECOMPOSITION 103
This book, predictably, develops the latter approach. But we should not just embrace
O-O decomposition because the title of the book so implies, or because it is the \u201cin\u201d thing
to do. The next few sections will carefully examine the arguments that justify using object
types as the basis for modularization \u2014 starting with an exploration of the merits and
limitations o
understanding
the full answe
We wil
formidable an
the War of th
slander again
praise for the
solution to th
objects \u2014 alt
we will need 
5.2 FUNC
We should fi
functions as a
appreciate wh
when we do m
operation ord
Continuity
A key elemen
or around da
continuity in 
criterion if 
commensurat
Continu
including not
evolution. Mo
of software d
ignores the s
novels which
knows, marks
To eval
should not ju
important to a
The tra
functional de
down design 
\u201cModular continu-
ity\u201d, page 44.
Top-down design 
was sketched in 
\u201cModular decom-
posability\u201d, page 40.
f traditional, non-O-O methods. Then we will try to get a clearer
 of what the word \u201cobject\u201d really means for software development, although
r, requiring a little theoretical detour, will only emerge in the next chapter.
l also have to wait until the next chapter for the final settlement of the
d ancient fight that provides the theme for the rest of the present discussion:
e Objects and the Functions. As we prepare ourselves for a campaign of
st the functions as a basis for system decomposition, and of corresponding
 objects, we must not forget the observation made above: in the end, our
e software structuring problem must provide space for both functions and
hough not necessarily on an equal basis. To discover this new world order,
to define the respective roles of its first-class and second-class citizens.
TIONAL DECOMPOSITION
rst examine the merits and limitations of the traditional approach: using
 basis for the architecture of software systems. This will not only lead us to
y we need something else \u2014 object technology \u2014 but also help us avoid,
ove into the object world, certain methodological pitfalls such as premature
ering, which have been known to fool even experienced O-O developers.
t in answering the question \u201cshould we structure systems around functions
ta?\u201d is the problem of extendibility, and more precisely the goal called
our earlier discussions. As you will recall, a design method satisfies this
it yields stable architectures, keeping the amount of design change
e with the size of the specification change.
ity is a crucial concern if we consider the real lifecycle of software systems,
 just the production of an acceptable initial version, but a system\u2019s long-term
st systems undergo numerous changes after their first delivery. Any model
evelopment that only considers the period leading to that delivery and
ubsequent era of change and revision is as remote from real life as those
 end when the hero marries the heroine \u2014 the time which, as everyone
 the beginning of the really interesting part.
uate the quality of an architecture (and of the method that produced it), we
st consider how easy it was to obtain this architecture initially: it is just as
scertain how well the architecture will weather change.
ditional answer to the question of modularization has been top-down
composition, briefly introduced in an earlier chapter. How well does top-
respond to the requirements of modularity?
TOWARDS OBJECT TECHNOLOGY §5.2104
Top-down development
There was a most ingenious architect who had contrived a new method
for building houses, by beginning at the roof, and working downwards
to the foundation, which he justified to me by the like practice of those
The top-down
of its abstrac
function, such
[C0]
\ufffd\ufffd\ufffdT
or:
[P0]
\u201cP
and continue
abstraction of
one or more 
compiler) cou
[C1]
\u201cR
\u201cP
\u201cD
\u201cG
or, using an al
is a sequence
[C'1]
fro
un
loo
en
\u201cF
two prudent insects, the bee and the spider. 
Jonathan Swift:
 Gulliver\u2019s Travels, Part III, A
Voyage to Laputa, etc., Chapter 5.
 approach builds a system by stepwise refinement, starting with a definition
t function. You start the process by expressing a topmost statement of this
 as
ranslate a C program to machine code\u201d
rocess a user command\u201d
 with a sequence of refinement steps. Each step must decrease the level of
 the elements obtained; it decomposes every operation into a combination of
simpler operations. For example, the next step in the first example (the C
ld produce the decomposition
ead program and produce sequence of tokens\u201d
arse sequence of