EBERARD@ADA20.ISI.EDU (Edward V. Berard) (06/22/87)
This is response to an honest question by Craig Wylie. Wylie asks a
series of general questions about software reuse. He has also
inadvertently tripped over one of my pet peeves. Let me quietly
explain, and then I will get on with my answer to his questions.
******************** Personal tirade -- Can be ignored ************
We often ignore the technical nature of software engineering. By that
I mean that we assume there is little to software engineering other
than writing code and opinion. Concepts which are accepted as normal
practice in other technical disciplines (e.g., literature searches,
the application of mathematical and engineering disciplines, and
quantitative metrics) are not yet accepted by the masses as being
relevant for software engineering.
Take the issue of software reuse. Ignoring any work in this area prior
to Doug McIlroy's article at the 1968 NATO Conference on Software
Engineering, software reusability has a history of almost two decades
of research and implementation. This research and implementation knows
no geographical or political bounds. For example, the Japanese have an
organization called SIGMA to deal with software reuse.
The IEEE has recently published and entire tutorial on software reuse.
A number of recent issues of IEEE Software have carried articles on
software reuse. Two entire issues of the IEEE Transactions on Software
Engineering were devoted to software reusability. Even a feeble search
of the software engineering literature would turn up hundreds of
articles on the topic. (The quality of these articles ranges from
dismal to excellent.) Many of these articles offer definitions,
metrics, taxonomies, and reusability systems.
Some of the items which we now know about software reusability are:
- Much more than source code can be reused. In fact, designs,
plans, test data, and documentation (among others) can be
reused. The smallest gains in productivity, reliability, etc.,
are obtained by only reusing source code. Reusing the
documentation associated with "reusable source code" greatly
enhances any gains associated with merely reusing the source
code.
- Reusability is not a concept that is limited to the coding phase
of the software life-cycle. It must be a highly visible item
from requirements analysis to the retirement of the product.
- Research seems to indicate, and practice seems to show, that the
majority of many software products can be assembled from reusable
components.
- There are any number of metrics associated with software reuse.
They include metrics which measure the sheer bulk of source code
and documentation reused in an application, to metrics which
measure the affects of software reusability, e.g., software
productivity metrics.
My image of the current state-of-the-practice in software engineering
is one of a series of blind and deaf individuals surrounded by massive
amounts of software engineering technology. All too often when some of
this technology is brought to the attention of one of these
"handicapped" individuals, it is dismissed as "buzzwords," "academic,"
"theoretical," or "mere opinion."
*********************** End of tirade *******************************
Wylie asks if we know what software reuse is. There are two answers to
this question. The vast majority of today's software practitioners
either do not know what it is, or assume that it is "yet another
buzzword." There is a small minority of individuals and organizations
who are researching and implementing various aspects of software
reuse. [I am reminded of the anecdote about the monks in their abbies
who preserved the knowledge of mankind during the dark ages while "the
winds of ignorance howled outside."]
No, Ada's package concept is not enough. Grady Booch has been pointing
out for years that some higher level concept (e.g., Rational's
subsystems) is necessary. By the way, virtually all existing
programming languages (with the exception of some very high-level
fourth-generation languages) lack attributes which make them directly
applicable to programming-in-the-large.
Reuse in Ada is not "stuck at the level of the abstract data type."
However, few software engineers know how to go beyond this concept (in
any language).
There are a number of ways to derive the "what" from a piece of Ada
software, and to divorce this from the "how." The mechanisms for doing
this range from crude (e.g., include the "what" in the comments), to
innovative (e.g., consider David Luckham's ANNA). Further, the
recovery of reusable components can be handled in a number of ways:
- level 0: the use of a hierarchical file system
- level 1: the use of a relational DBMS (data base management
system) or a hypertext system
- level 2: the use of an expert system or some other artificial
intelligence tool
- level 3: incorporation of reusable components in an application
generator (a type of fourth-generation language)
These approaches have also been modified to include such things as
documentation, test data, designs, and plans as well as source code.
Software reusability technology is indeed a collection of things.
These things include reusable components, taxonomies, reusability
systems, composition concepts, methodologies, and others. This
technology is more coupled with the size of the software product than
it is with "the scale at which the reuse is to take place."
The issue of language suitability for reuse is an interesting one.
Stating that imperative languages are unsuitable for reuse shows a
lack of understanding of software reuse technology. (But then again, I
have heard any number of Ada people make similar misstatements about
languages such as LISP and most fourth-generation languages.) One
might re-phrase the observation by stating that the mere use of the
Ada language does not guarantee reuse. The language must be
accompanied by software reuse technology (e.g., tools and
methodologies).
One item which seems to have escaped the understanding of many in the
Ada community is that one of the primary motivations behind the Ada
language is "to build tools to build tools." Ada was designed with the
intention that it be used as a bootstrap. Specifically, it is to be
used to create libraries of reusable components (the first "tools").
These reusable components are to be used to create fourth-generation
languages and "software factories" (the second "tools"). Using the Ada
language as if it were Pascal, C, FORTRAN, COBOL, or assembly language
is tantamount to abuse.
Software design methodologies do play an important part in software
reuse. Some methodologies enhance software reuse, others discourage
it. We have known for some time that software designs should be
constructed so that they can easily be modified. We are only now
beginning to understand that by bringing software reusability issues
to the first phases of the software life-cycle, we can greatly enhance
the impact of software reusability. Finally, by studying the designs
of many systems within a particular application domain we are finding
designs are very much reusable, e.g., consider the basis for many
fourth-generation languages.
Nobody can force programmers to write good reusable code. However,
programmers, as a whole, want to do a good job and are very
goal-oriented. Getting programmers to write good reusable code is in
part a motivating and educational process.
Finally, in addition to the technical problems which must be
addressed, we have to consider many other connected issues. Political,
managerial, legal, cultural, financial, marketing, and productization
issues must also be considered.
-- Ed Berard
(301) 695-6960
-------