Software Reusability: We Know More Than You Think

By Edward V. Berard (The Object Agency, Inc.)

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:

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:

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.

[TOA Home Page] [HTML
Documents] [Contact TOA]