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
not the same as solving the problem. 
§1.3 ABOUT SOFTWARE MAINTENANCE 17
1.3 ABOUT SOFTWARE MAINTENANCE 
The list of factors did not include a frequently quoted quality: maintainability. To
understand why, we must take a closer look at the underlying notion, maintenance. 
Mainten
Discussions o
introductory 
software is de
neglects this a
What do
to be a misnom
not be \u201cmaint
people to de
modification:
external worl
removing erro
The abo
light on what
installations 
publications c
costs going in
More th
modifications
the inevitable
could spare if 
legitimately e
Breakdown of 
maintenance 
costs. Source: 
[Lientz 1980]
ance is what happens after a software product has been delivered.
f software methodology tend to focus on the development phase; so do
programming courses. But it is widely estimated that 70% of the cost of
voted to maintenance. No study of software quality can be satisfactory if it
spect. 
es \u201cmaintenance\u201d mean for software? A minute\u2019s reflection shows this term
er: a software product does not wear out from repeated usage, and thus need
ained\u201d the way a car or a TV set does. In fact, the word is used by software
scribe some noble and some not so noble activities. The noble part is
 as the specifications of computer systems change, reflecting changes in the
d, so must the systems themselves. The less noble part is late debugging:
rs that should never have been there in the first place.
ve chart, drawn from a milestone study by Lientz and Swanson, sheds some
 the catch-all term of maintenance really covers. The study surveyed 487
developing software of all kinds; although it is a bit old, more recent
onfirm the same general results. It shows the percentage of maintenance
to each of a number of maintenance activities identified by the authors.
an two-fifths of the cost is devoted to user-requested extensions and
. This is what was called above the noble part of maintenance, which is also
 part. The unanswered question is how much of the overall effort the industry
it built its software from the start with more concern for extendibility. We may
xpect object technology to help. 
12.4%9%6.2%5.5%
4%
3.4%
Emergency
FixesRoutine
Fixes
Hardware
changes
Documen-
tation
Effic
ienc
y
imp
rov
em
en
ts
Other
41.8%
Changes in User Requirements
17.6% Changesin Data
Formats
SOFTWARE QUALITY §1.318
The second item in decreasing order of percentage cost is particularly interesting:
effect of changes in data formats. When the physical structure of files and other data items
change, programs must be adapted. For example, when the US Postal Service, a few years
ago, introduced the \u201c5+4\u201d postal code for large companies (using nine digits instead of
five), numero
exactly five d
hundreds of m
Many rea
single ev
problem\u201d
authors n
The zip c
the idea:
this must
has been
The issu
this is inevita
traditional de
system, caus
changes \u2014 as
or dates requi
codes or the d
of the exact le
will cause pro
the specificat
The the
programs to a
Another
of documenta
The observati
that a project
at all. We wil
embedded in 
The nex
relevant to th
that the prog
way) cost mo
performed un
delivering ne
small percent
For another 
example, see \u201cHow 
long is a middle 
initial?\u201d, page 125.
 
es 
us programs that dealt with addresses and \u201cknew\u201d that a postal code was
igits long had to be rewritten, an effort which press accounts estimated in the
illions of dollars. 
ders will have received the beautiful brochures for a set of conferences \u2014 not a
ent, but a sequence of sessions in many cities \u2014 devoted to the \u201cmillennium
: how to go about upgrading the myriads of date-sensitive programs whose
ever for a moment thought that a date could exist beyond the twentieth century.
ode adaptation effort pales in comparison. Jorge Luis Borges would have liked
 since presumably few people care about what will happen on 1 January 3000,
 be the tiniest topic to which a conference series, or for that matter a conference,
 or will ever be devoted in the history of humanity: a single decimal digit.
e is not that some part of the program knows the physical structure of data:
ble since the data must eventually be accessed for internal handling. But with
sign techniques this knowledge is spread out over too many parts of the
ing unjustifiably large program changes if some of the physical structure
 it inevitably will. In other words, if postal codes go from five to nine digits,
re one more digit, it is reasonable to expect that a program manipulating the
ates will need to be adapted; what is not acceptable is to have the knowledge
ngth of the data plastered all across the program, so that changing that length
gram changes of a magnitude out of proportion with the conceptual size of
ion change. 
ory of abstract data types will provide the key to this problem, by allowing
ccess data by external properties rather than physical implementation. 
 significant item in the distribution of activities is the low percentage (5.5%)
tion costs. Remember that these are costs of tasks done at maintenance time.
on here \u2014 at least the speculation, in the absence of more specific data \u2014 is
 will either take care of its documentation as part of development or not do it
l learn to use a design style in which much of the documentation is actually
the software, with special tools available to extract it. 
t items in Lientz and Swanson\u2019s list are also interesting, if less directly
e topics of this book. Emergency bug fixes (done in haste when a user reports
ram is not producing the expected results or behaves in some catastrophic
re than routine, scheduled corrections. This is not only because they must be
der heavy pressure, but also because they disrupt the orderly process of
w releases, and may introduce new errors. The last two activities account for
ages: 
Chapter 6 covers
abstract data typ
in detail.
§1.4 KEY CONCEPTS INTRODUCED IN THIS CHAPTER 19
\u2022 One is efficiency improvements; this seems to suggest that once a system works,
project managers and programmers are often reluctant to disrupt it in the hope of
performance improvements, and prefer to leave good enough alone. (When
considering the \u201cfirst make it right, then make it fast\u201d precept, many projects are
probabl
\u2022 Also acc
interpre
are two
program
others a
that dev
1.4 KEY
\u2022 The pur
\u2022 Rather t
a set of 
\u2022 Externa
internal
\u2022 What m
internal
\u2022 A list o
software
method 
together
architec
\u2022 Softwar
penalize
over-de
1.5 BIBL
Several autho
subject, two 
[Boehm 1978
The dis
General Elec
the terms \u201cfa
internal facto
correspond t
because, as ex
study discuss
y happy enough to stop at the first of these steps.) 
ounting for a small percentage is \u201ctransfer to new environments\u201d. A possible
tation (again a conjecture in the absence of more detailed data) is that there
 kinds of program with respect to portability, with little in-between: some
s are designed with portability in mind, and cost relatively little to port;
re so closely tied to their original platform, and would be so difficult to port,
elopers do not even try. 
 CONCEPTS INTRODUCED IN THIS CHAPTER 
pose of software engineering is to find ways of building quality software. 
han a single factor, quality in software is best viewed as a tradeoff between
different goals. 
l factors, perceptible to users and clients, should be distinguished from
 factors, perceptible to designers and implementors. 
atters is the external factors, but they can only be achieved through the
 factors. 
f basic external quality factors was presented. Those for which current
 is most badly in need of better methods, and which the object-oriented
directly addresses, are the safety-related factors correctness and robustness,
 known as reliability,