Figure 1: Taxonomy of Reusability Metrics
Jeffrey S. Poulin, Ph.D.
Lockheed Martin Federal Systems
Owego, New York
Many researchers have attempted to derive a general reusablity metric for software. Such a metric would quickly tell us the relative ease of using a given software component in new environments. However, deriving this metric requires an objective, repeatable, and quantifiable approach. The answer to this search eludes us because reusability inherently defies these requirements. The reasons for this include (1) the fact that researchers cannot agree on what makes software reusable, which leads to serious practical and theoretical barriers, and (2), the ability to use software depends on the environment as well as the internal characteristics of the software.
We would like a general reusability metric (1) to help us build new reusable components, and (2) to help us identify potentially useful components that already exist, for example, in legacy systems. However, determining what makes software reusable continues to elude researchers and practitioners alike. Most software experts agree that applying general software engineering principles will not only lead to better software, but they will also lead to more "reusable" software. These experts stress guidelines such as encapsulation of data and operations, low coupling, high functional cohesion, good documentation, and thorough testing. However, whereas many reusability researchers stress good software engineering, most also ignore the affects of the software environment on the ability to reuse individual components [Pou94, Pou96].
The search for a general reusability metric faces many of the same challenges as the search for metrics in other related fields. For example:
In the search for a general reusability metric, we must consider several issues that may conflict with our overall goals. For example, if research shows that reusers find small components easier to reuse, should we make all reusable components small? Does this mean we cannot reuse a large component? Would we not prefer to gain the benefits of reusing large components as opposed to small ones? Likewise, if research shows that reusable components have low complexity (as measured by the McCabe or Halstead metrics, for instance), should we limit the complexity of our reusable components? Would we not prefer to encapsulate our most difficult algorithms? Furthermore, how do we account for the situation when some of the reusability attributes we have identified have more importance in determining whether we can reuse a component? Or, more to the point, what happens when one attribute seems highly statistically correlated with our perception of reusability? Why continue our expensive search for a general reusability metric when an easily obtainable measure such as lines of code serves us just as well? Compounding these issues lies the underlying fact that no one really understands or agrees on what makes a component reusable. Many people have identified factors and attributes that tend to make software easier to reuse, but arriving at single, unifying metric that brings these attributes together continues to elude us.
After analyzing numerous methods, we have grouped the approaches into the taxonomy shown in Figure 1. First, we observed that most methods attempt to determine the reusability of a component by examining nothing but the component code. We call these module-oriented. Some methods look at additional pieces of information that have a relationship to the code, such as abstracts, usage instructions, and design documents. We call these component-oriented.
Figure 1: Taxonomy of Reusability Metrics
Second, we observed two major approaches to reusability. Empirical methods stress objective, numerical, and repeatable metrics, such as those obtained by observing the module complexity or size. Qualitative methods included (or even emphasized) subjective criteria, such as how well a module complies with a set of style, certification, quality guidelines, or simply agrees with the opinions of "experts."
Example: In a comprehensive statistical study of a NASA software production environment for unmanned spacecraft ground support software, Selby reports on numerous factors influencing the reuse of software components [Sel89], As part of this study, Selby collected and analyzed reusability attributes on 7188 FORTRAN modules from twenty-five moderate and large size software systems. We classify this as a module-oriented, empirical approach.
Each of the methods we examined identified a unique set of attributes to consider as part of a reusability assessment. Each of the methods then attempted to prove, via statistical analysis, experimentation, or other means, that the selected attributes contributed to reusability. We examined we observed some common elements in these searches for a general reusability metric. For example, most empirical methods identified the following reusability attributes:
Qualitative methods often used:
Tracz observed that for programmers to reuse software, they must first find it useful [Tra88]. We stress that the usefulness of a component depends as much on the framework in which it fits as it does on internal characteristics of the component.
Nearly every method we observed meticulously examined the contribution of low coupling, high cohesiveness, modularity, etc., to reusability. Although we agree that these attributes give indications as to the ease of use of a component, they cannot, by themselves, provide a general measure of reusability. Since reusability depends on context, any reusability assessment must consider the affects of factors such as the domain, framework, and software architecture in which the component must operate. Nearly all current reusability metrics fail to include any of these environmental factors.
Software metrics must produce values that preserve our observations about software. Unfortunately, the search for a general reusability metric seeks to put an empirical value on a poorly understood characteristic. To succeed, we need to first agree on what makes a component "reusable."
Most importantly, the ability to reuse software depends on environmental factors that fall completely out of the scope of individual software modules or components. The search for a general reusability metric must consider these environmental factors as well as factors derived from the software. We conclude that although we can determine empirical values for reusability attributes of software, we cannot establish an general reusability metric.