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

Object Oriented Software Construction - Bertrand Meyer


DisciplinaProgramação Orientada A Objetos3.319 materiais50.737 seguidores
Pré-visualização50 páginas
and the factors requiring more decentralized software
tures: reusability and extendibility, together known as modularity. 
e maintenance, which consumes a large portion of software costs, is
d by the difficulty of implementing changes in software products, and by the
pendence of programs on the physical structure of the data they manipulate. 
IOGRAPHICAL NOTES 
rs have proposed definitions of software quality. Among the first articles on
in particular remain valuable today: [Hoare 1972], a guest editorial, and
], the result of one of the first systematic studies, by a group at TRW. 
tinction between external and internal factors was introduced in a 1977
tric study commissioned by the US Air Force [McCall 1977]. McCall uses
ctors\u201d and \u201ccriteria\u201d for what this chapter has called external factors and
rs. Many (although not all) of the factors introduced in this chapter
o some of McCall\u2019s; one of his factors, maintainability, was dropped,
plained, it is adequately covered by extendibility and verifiability. McCall\u2019s
es not only external factors but also a number of internal factors (\u201ccriteria\u201d),
SOFTWARE QUALITY §1.520
as well as metrics, or quantitative techniques for assessing satisfaction of the internal
factors. With object technology, however, many of that study\u2019s internal factors and
metrics, too closely linked with older software practices, are obsolete. Carrying over this
part of McCall\u2019s work to the techniques developed in this book would be a useful project;
see the biblio
The arg
complexity o
On eas
[Shneiderman
Web page of
bibliographic
The Osm
[Osmond 199
more direct v
alternative cu
Osmond\u2019s ori
The cha
based on a m
[Boehm 1979
by now obsol
of 23,000 ins
still applicab
maintenance;
The ex
introduced by
For a ge
Jazayeri and 
same authors
discussed in t
graphy and exercises to chapter 3.
ument about the relative effect of machine improvements depending on the
f the algorithms is derived from [Aho 1974].
e of use, a standard reference is [Shneiderman 1987], expanding on
 1980], which was devoted to the broader topic of software psychology. The
 Shneiderman\u2019s lab at http://www.cs.umd.edu/projects/hcil/ contains many
 references on these topics.
ond curves come from a tutorial given by Roger Osmond at TOOLS USA
5]. Note that the form given in this chapter does not show time, enabling a
iew of the tradeoff between functionality and other qualities in the two
rves, but not reflecting the black curve\u2019s potential for delaying a project.
ginal curves are plotted against time rather than functionality.
rt of maintenance costs is derived from a study by Lientz and Swanson,
aintenance questionnaire sent to 487 organizations [Lientz 1980]. See also
]. Although some of their input data may be considered too specialized and
ete (the study was based on batch-type MIS applications of an average size
tructions, large then but not by today\u2019s standards), the results generally seem
le. The Software Management Association performs a yearly survey of
 see [Dekleva 1992] for a report about one of these surveys. 
pressions programming-in-the-large and programming-in-the-small were
 [DeRemer 1976].
neral discussion of software engineering issues, see the textbook by Ghezzi,
Mandrioli [Ghezzi 1991]. A text on programming languages by some of the
, [Ghezzi 1997], provides complementary background for some of the issues
he present book.
2 
Criteria o
In the previ
preparation f
method, it is 
development.
One of 
object-oriente
need a list of
that its propo
This cha
you cannot ex
of the rest of t
Actually
what film buf
step-by-step 
for object tec
solutions. If y
this chapter i
unfold and of
will not need
2.1 ON T
Let us first ex
How dogm
Warning: 
SPOILER! 
The list presented below includes all the facilities which I believe to be essential for the
production of quality software using the object-oriented method. It is ambitious and may
appear uncompromising or even dogmatic. What conclusion does this imply for an
environment which satisfies some but not all of these conditions? Should one just reject
such a half-hearted O-O environment as totally inadequate? 
f object orientation
ous chapter we explored the goals of the object-oriented method. As a
or parts B and C, in which we will discover the technical details of the
useful to take a quick but wide glance at the key aspects of object-oriented
 Such is the aim of this chapter. 
the benefits will be to obtain a concise memento of what makes a system
d. This expression has nowadays become so indiscriminately used that we
 precise properties under which we can assess any method, language or tool
nents claim to be O-O.
pter limits its explanations to a bare minimum, so if this is your first reading
pect to understand in detail all the criteria listed; explaining them is the task
he book. Consider this discussion a preview \u2014 not the real movie, just a trailer.
 a warning is in order because unlike any good trailer this chapter is also
fs call a spoiler \u2014 it gives away some of the plot early. As such it breaks the
progression of this book, especially part B, which patiently builds the case
hnology by looking at issue after issue before deducing and justifying the
ou like the idea of reading a broad overview before getting into more depth,
s for you. But if you prefer not to spoil the pleasure of seeing the problems
 discovering the solutions one by one, then you should simply skip it. You
 to have read it to understand subsequent chapters.
HE CRITERIA
amine the choice of criteria for assessing objectness.
atic do we need to be?
CRITERIA FOR OBJECT ORIENTATION §2.222
Only you, the reader, can answer this question relative to your own context. Several
reasons suggest that some compromises may be necessary: 
\u2022 \u201cObject-oriented\u201d is not a boolean condition: environment A, although not 100%
O-O, may be \u201cmore\u201d O-O than environment B; so if external constraints limit your
choice t
\u2022 Not eve
\u2022 Object o
solution
All this
constraints im
provided by t
Categories
The set of cri
\u2022 Method
process
that (es
program
used for
\u2022 Implem
properti
\u2022 Librarie
this cat
needed 
This div
the categorie
classified un
automatic gar
category; the 
2.2 MET
The first set o
Seamlessne
The object-or
When exami
language, as
implementati
thought whic
o A and B you will have to pick A as the least bad object-oriented choice. 
ryone will need all of the properties all the time. 
rientation may be just one of the factors guiding your search for a software
, so you may have to balance the criteria given here with other considerations. 
 does not change the obvious: to make informed choices, even if practical
pose less-than-perfect solutions, you need to know the complete picture, as
he list below. 
 
teria which follows has been divided into three parts: 
 and language: these two almost indistinguishable aspects cover the thought
es and the notations used to analyze and produce software. Be sure to note
pecially in object technology) the term \u201clanguage\u201d covers not just the
ming language in a strict sense, but also the notations, textual or graphical,
 analysis and design. 
entation and environment: the criteria in this category describe the basic
es of the tools which allow developers to apply object-oriented ideas. 
s: object technology relies on the reuse of software components. Criteria in
egory cover both the availability of basic libraries and the mechanisms
to use libraries and produce new ones. 
ision is convenient but not absolute, as some criteria straddle two or three of
s. For example the criterion labeled \u201cmemory management\u201d has been
der method and language because a language can support or prevent
bage collection, but it also belongs to the implementation and environment
\u201cassertion\u201d criterion