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

Object Oriented Software Construction - Bertrand Meyer


DisciplinaProgramação Orientada A Objetos3.487 materiais53.387 seguidores
Pré-visualização50 páginas
of ComputerWorld.
ities 
s beside the ones discussed so far affect users of software systems and the
urchase these systems or commission their development. In particular: 
bility is the ease of preparing acceptance procedures, especially test data, and
res for detecting failures and tracing them to errors during the validation and
n phases. 
y is the ability of software systems to protect their various components
s, data) against unauthorized access and modification. 
bility is the ability to facilitate the repair of defects. 
y, the companion of timeliness, is the ability of a system to be completed on
 its assigned budget.
umentation 
oftware quality factors, one might expect to find the presence of good
n as one of the requirements. But this is not a separate quality factor; instead,
ocumentation is a consequence of the other quality factors seen above. We
ish between three kinds of documentation: 
d for external documentation, which enables users to understand the power
em and use it conveniently, is a consequence of the definition of ease of use. 
ed for internal documentation, which enables software developers to
nd the structure and implementation of a system, is a consequence of the
ility requirement. 
d for module interface documentation, enabling software developers to
nd the functions provided by a module without having to understand its
entation, is a consequence of the reusability requirement. It also follows from
ility, as module interface documentation makes it possible to determine
 a certain change need affect a certain module. 
rs want it.
\u201cNT 4.0 Beats 
Clock\u201d, Compute
World, vol. 30, no
30, 22 July 1996.
§1.2 A REVIEW OF EXTERNAL FACTORS 15
Rather than treating documentation as a product separate from the software proper,
it is preferable to make the software as self-documenting as possible. This applies to all
three kinds of documentation: 
\u2022 By including on-line \u201chelp\u201d facilities and adhering to clear and consistent user
interfac
forms o
\u2022 A good
docume
requirem
\u2022 The no
assertio
then pos
from mo
All thes
we cannot exp
Tradeoffs 
In this review
may conflict w
How ca
will inevitabl
Optimal effic
environment,
where reusab
given. Timeli
techniques w
Althoug
conflicting fa
make these tr
and the vario
silent decision
clearly and m
Necessa
the rest: corre
sake of other 
rest is useless
Key concer
All the qualit
industry, four
e conventions, you alleviate the task of the authors of user manuals and other
f external documentation. 
 implementation language will remove much of the need for internal
ntation if it favors clarity and structure. This will be one of the major
ents on the object-oriented notation developed throughout this book. 
tation will support information hiding and other techniques (such as
ns) for separating the interface of modules from their implementation. It is
sible to use tools to produce module interface documentation automatically
dule texts. This too is one of the topics studied in detail in later chapters.
e techniques lessen the role of traditional documentation, although of course
ect them to remove it completely.
 of external software quality factors, we have encountered requirements that
ith one another.
n one get integrity without introducing protections of various kinds, which
y hamper ease of use? Economy often seems to fight with functionality.
iency would require perfect adaptation to a particular hardware and software
 which is the opposite of portability, and perfect adaptation to a specification,
ility pushes towards solving problems more general than the one initially
ness pressures might tempt us to use \u201cRapid Application Development\u201d
hose results may not enjoy much extendibility.
h it is in many cases possible to find a solution that reconciles apparently
ctors, you will sometimes need to make tradeoffs. Too often, developers
adeoffs implicitly, without taking the time to examine the issues involved
us choices available; efficiency tends to be the dominating factor in such
s. A true software engineering approach implies an effort to state the criteria
ake the choices consciously. 
ry as tradeoffs between quality factors may be, one factor stands out from
ctness. There is never any justification for compromising correctness for the
concerns such as efficiency. If the software does not perform its function, the
.
ns 
ies discussed above are important. But in the current state of the software
 stand out: 
SOFTWARE QUALITY §1.216
\u2022 Correctness and robustness: it is still too difficult to produce software without defects
(bugs), and too hard to correct the defects once they are there. Techniques for
improving correctness and robustness are of the same general flavors: more systematic
approaches to software construction; more formal specifications; built-in checks
throughout the software construction process (not just after-the-fact testing and
debuggi
memory
correctn
before t
issues, i
\u2022 Extendi
element
larger in
a new s
idea tha
are self
channel
As stud
significantly 
has significan
\u2022 Compat
module 
\u2022 Portabi
technolo
implem
polymo
automat
example
\u2022 Ease of
especial
other as
system 
\u2022 Efficien
first app
can ofte
\u2022 Timelin
them to 
and may
In spite 
is not a pana
Helping to ad
ng); better language mechanisms such as static typing, assertions, automatic
 management and disciplined exception handling, enabling developers to state
ess and robustness requirements, and enabling tools to detect inconsistencies
hey lead to defects. Because of this closeness of correctness and robustness
t is convenient to use a more general term, reliability, to cover both factors. 
bility and reusability: software should be easier to change; the software
s we produce should be more generally applicable, and there should exist a
ventory of general-purpose components that we can reuse when developing
ystem. Here again, similar ideas are useful for improving both qualities: any
t helps produce more decentralized architectures, in which the components
-contained and only communicate through restricted and clearly defined
s, will help. The term modularity will cover reusability and extendibility. 
ied in detail in subsequent chapters, the object-oriented method can
improve these four quality factors \u2014 which is why it is so attractive. It also
t contributions to make on other aspects, in particular: 
ibility: the method promotes a common design style and standardized
and system interfaces, which help produce systems that will work together. 
lity: with its emphasis on abstraction and information hiding, object
gy encourages designers to distinguish between specification and
entation properties, facilitating porting efforts. The techniques of
rphism and dynamic binding will even make it possible to write systems that
ically adapt to various components of the hardware-software machine, for
 different window systems or different database management systems. 
 use: the contribution of O-O tools to modern interactive systems and
ly their user interfaces is well known, to the point that it sometimes obscures
pects (ad copy writers are not the only people who call \u201cobject-oriented\u201d any
that uses icons, windows and mouse-driven input). 
cy: as noted above, although the extra power or object-oriented techniques at
ears to carry a price, relying on professional-quality reusable components
n yield considerable performance improvements. 
ess, economy and functionality: O-O techniques enable those who master
produce software faster and at less cost; they facilitate addition of functions,
 even of themselves suggest new functions to add.
of all these advances, we should keep in mind that the object-oriented method
cea, and that many of the habitual issues of software engineering remain.
dress a problem is