Ralph D. (Butch) Neal
NASA/WVU Software Research Laboratory
100 University Dr., Fairmont, WV 26554
Tel: (304)367-8355
Fax: (304)367-8211
Email:
rneal@research.ivv.nasa.gov
Before a product can be reused effectively it must first be evaluated. In software measurement, it is well known that the product (or process) that cannot be measured cannot be controlled. That is, the evaluation of the product (or process) consists of designing and validating measures of the product (or process). If this maxim of software measurement is applied to software reuse, it then becomes: The product that cannot be measured (evaluated) cannot be reused effectively.
Keywords: measurement, product engineering.
Workshop Goals: Identify the measurements of various software artifacts that need to be taken in order to facilitate reuse of the artifacts.
Working Groups: Reuse of the Earliest Life-Cycle Artifacts; Rigorous Behavioral Specification as an Aid to Reuse.
I am new to the field of software reuse. My research background is in software measurement. I am interested in connecting the practice of software product measurement to the practice of software component reuse. I am a working member of the Joint Logistics Commanders Joint Group on Systems Engineering which is undertaking a major research effort concentrated on measurement of the software product. This group is a loose collection of software metrics professionals from the defense industry and academia.
Frakes and Gandel[1] looked at methods of recognizing reusable software. They identified two methods but found problems with each. The first method they called knowledge-based. This method requires the software engineer to study an existing computer system component item (CSCI) until the functionality of the CSCI is understood. The functionality of the existing CSCI is then compared to the functionallity needed in the new CSCI. Frakes and Gandel[1] concluded that the knowledge acquisition necessary for knowledge-based methods may be too difficult or too expensive to be useful, i.e., it may take longer to understand the existing CSCI than to develop the new CSCI. The second method that they identified consists of indexing CSCIs according to functionality much as a book is indexed by subject matter in a library. They found the less expensive librarian type indexes to be less descriptive and only useful in finding families of CSCIs, i.e., not useful in finding specific CSCIs to fill a given need.
Frakes and Terry [2] looked at the use of metrics to indicate
the likelihood that a CSCI is reusable (reuasbility metrics). They
inquired whether there are measureable attributes that indicate the
potential reusability of a software component and cited [3]
who found six ordinal measures to be statistically signifiant in
suggesting reusable modules. The measures found by [3] allow
only the comparison of CSCIs to help select the CSCI most likely to be
reusable. Selby's measures are based on code structure. The measures do
not allow a CSCI to be selected by functionality. Frakes and Terry
[2] state that the attributes of reusability are often
specific to given types of reusable components and to the languages in
which they are implemented. They see this as a difficulty in searching
out attributes that indicate the likelihood that a CSCI is reusable. We
should not, however, give up because the attributes may be specific and,
therefore, the determination of these attributes difficult.
Dusink and van Katwijk [4] describe components-based reuse as a series of actions: find a component, select a component, understand the component selected, and (if required) adapt the component. Emphasis is usually placed on finding and selecting the appropriate reusable component [4]. The current literature suggests higher level descriptions either in formal language, informal language or keyword form [4]. This approach resembles a combination of the two approaches studied by Frakes and Gandel [1]. First higher level descriptions (the librarian type indexes found to be only useful in finding families of software components) are used to narrow the CSCI selection to a more managable number. Then, knowledge-based methods are employed to further understand the component selected, and (if required) adapt the component. This approach has all of the advantages and disadvantages of the methods cited in [1].
If we can identify the attributes of CSCIs that are indicators of functionality, we may be able to develop measures that will allow us to match the functionality written into the requirements statement to the functionality written into existing design documents and existing code. In order to truly understand software, the software development process, and ultimately CSCI reuse, software measurement must be better understood. Many measurements will be necessary to fully define a CSCI. The Joint Logistics Commanders Joint Group on Systems Engineering has defined a framework for software product engineering (SPE) research.
I.Define the criteria for categories of
measures.
A.Technical adequacy
B.Functionality
C.Quality
II.Define the viewpoints of the different
stakeholders.
A.Different views may require
different measures.
B.Measures may have to be
weighted or tailored
differently for different
stakeholders.
III.Define measurement artifacts
A.Requirements
B.Design
C.Code
D.Documentation
Measures must be defined to measure at a minimum technical adequacy, functionality, and quality. Technical adequacy includes such things as making sure that the reusable artifact takes advantage of the technology available in the platform. Functionality includes such things as reliability and calculation precision. Quality includes such things as maintainability, portability, and adaptability.
There are two types of measurement: direct measurement of a dimension requires only that dimension; indirect measurement of a dimension requires that one or more other dimensions be measured. Because the dimensions of greatest interest, e.g., quality, are often external to the entity being measured, and therefore very hard to measure directly, indirect measurement usually achieves more useful results [5]; [6]. That is, internal dimensions e.g., verbal skills, are measured, to assess external dimensions, e.g., IQ. Or in the case of software, the number of known defects are counted to assess quality. Much more needs to be known about the affect of CSCI attributes on the functionality and quality of the CSCI. SPE is just beginning to explore the internal dimensions of CSCIs. To date, most research in software measurement has concentrated on identifying measures of code. I have identified fourteen dimensions of object-oriented code that have measures defined for them in the literature [7]. Much more work has to be done toward identifying requirements measures and design measures.
Because people observe things differently (and often intuitively feel differently about things), a model is usually defined for the entities and dimensions to be measured. The model requires everyone to look at the subject from the same viewpoint. Fenton [8] uses the example of human height. Should posture be taken into consideration when measuring human height? Should shoes be allowed? Should the measurement be made to the top of the head or the top of the hair? The model forces a reasonable consensus upon the measurers. This idea needs to be applied to software reuse.
In order to measure object-oriented software the measurer will need to be aware of the characteristics of O-O software and of the different levels of granularity inherent in the O-O paradigm (see Table 1). The Object-Oriented Space (OOS) model parses the object-oriented space into understandable, unambiguous segments and allows the measurer to reason about the object-oriented space in a meaningful way. The software dimensions that help make up the OOS model are dimensions of Object-oriented software quality. Although some of the measures used to populate the model may have a connection to functionality, that connection has not as yet been established.
I believe that the world of reuse can benefit from the world of measurement and that software measurements should be designed with reuse in mind. When we can define models of the artifacts that we wish to utilize and design measures that reflect the models, it should become easier to match existing CSCIs to developing systems.
If we wish to reuse an artifact in the physical sciences the measures that we take depend on the artifact but, for the most part, we know what to measure. If we wish to reuse a bolt, for instance, we need to know the required length, diameter, depth of thread, density of thread, and perhaps the type of head. However, although we may wish to reuse a software artifact, we have not yet defined the dimensions that describe the software artifact. When we talk about reuse of object-oriented code, we usually talk about classes (or objects). For the purposes of this paper, I have included the measures that have been defined in the literature for object-oriented classes (see Table 2).
1. fewer module calls per source line, fewer I/O parameters per source line, fewer read/write statements per line, higher comment to code ratios, more utility function calls per source line, and fewer source lines
Butch Neal is a research associate at the NASA/WVU Software Research Laboratory. Dr. Neal has 20+ years experience in data processing. As a researcher, he specializes in software measurement. Dr. Neal earned bachelors and masters degrees from West Virginia University and the PhD degree in Information Systems from Virginia Commonwealth University.