A Method for Software Reuse through Large Component Libraries. G. Sindre ... proach to producing cheaper and better software, the ... within a small company.
A Method for Software Reuse through Large Component Libraries G. Sindre
E A . Karlsson
T. Staalhane
Norwegian Institute of Technology Trondheim, Norway
E-P Telecom &-Labs Lund, Sweden
SINTEF-DELAB Trondheim, Norway
Abstract
the technical side, which is the focus of this paper, the following decisions have been made:
Although reuse is recognized as a promising approach to producing cheaper and better software, the industrial penetration of reuse methodology has not been impressive. Generally, reuse is restricted to localized contezts, i.e. within a project team o r potentially within a small company. The REBOOTproject addresses the problem of supporting massive inter-group reuse from a libmry with a large number of components, and in ihis paper we discuss in pariicular the specific technical problems resulting f ” the size of the libmry. The first prototype version of the REBOOT reuse environment is finished, and is now being evaluated.
we restrict ourselves t o component-based reuse [4, 9, 111.
0
we restrict ourselves to object-oriented components, and reuse shall be supported throughout the whole life-cycle.
The rest of the paper is structured as follows: Section 2 identifies some major technical problems of largescale component reuse, which are then discussed in sections 3-4. Section 5 describes the REBOOT environment. Finally, section 6 gives some concluding remarks.
Technical problems of large-scale, inter-group reuse
2
1 Introduction For a long time reuse has been promoted as a promising approach to improving quality and productivity in software engineering. Still, it largely fails to deliver, beyond low level function or class libraries for specific programming languages - or in the case of more complex and high-level components: beyond the limited context of the project team.- There are many reasons why reuse fails in a larger context [2,5]: both technical, such as inferior methods or tool support, or attempts t o reuse components of insufficient quality, and organizational, such as lack of education, skepticism towards reusable components (the “not invented here” syndrome), improper organizational structures or lack of incentives for reuse. The REBOOT’ project addreases both the organizational and technical problems concerning reuse. On
Intra-group reuse is the kind of reuse which goes on within a limited group where all the developers know each other, e.g. a project team, and where it is possible for people to remember similar components from earlier projects, and to talk to the person who developed a component to get more detailed information if one is uncertain whether a component is suitable for reuse in some specific situation. Inter-group reuse, on the other hand, is reuse beyond such groups, i.e. between teams, between divisions, or even between companies. Potentially, the library may be filled by long distance submission. Moreover, the reuser may be situated far away from developers and library managers. Thus, the communication between developers, reusers and library management is much looser than for small-scale, intra-group reuse. In addition, the number of components will be so large that no one can have a full overview of the library contents. This leads to three important problems:
IESPRIT-2 project # 5327 REBOOT (Rem by ObjectOriented Techniques)started September 1990 and has a duration of 4 years. The partners are Bull S.A. (prime, France), Cap Gemini Innovation (fiance), LGI at IMAG (fiance), SEMA GROUP S.A.E. (Spain), Siemens A.G. (Germany), E P Telecom Q-Labs (Sweden), TXT (Italy) and SINTEF/NTH (Norway). The total planned effort is 124 man-years.
0-81884212-2/93 803.00 0 1993 IEEE
0
0
464
How can the library management ensure the quality of the components in the library?
How can we facilitate component retrieval for the potential reuser? The software component domain is evolving quickly, and thus also the supply and demand t e wards the library. Thus, library maintenance is a major problem. In the following three sections we will present the R E BOOT approach to these three problems.
3
I
The REBOOT qualification model
An essential question for the qualification of a reusable component is what factors govern reusability. The factors used in the REBOOT model are defined as follows: Figure 1: The REBOOT reusability attribute
Portability: The ease with which software can be transferred from one computer system or environment to another [15].
metrics (e.g. [IS]). We have applied the Pareto principle [SI (the "20-80 rule") in order not too include too many metrics, since this would make the model impractical to use. The reusability metria can be collected automatically during component parsing, except for the observed reliability and the checklist scores. Since developers cannot generally be trusted to fill in the checklists correctly, these should be subject to inspection by library management. Still, the prevalence of automatic calculation has lifted some heavy burden off the shoulders of the librarians, and for a developer who has proved reliable, it might be sufficient with sample checks. Although the a-priori estimates will keep lots of dubious quality components out of the library, it is still likely that some will get in because the a-priori model evaluates them as better than they really are. It may also be the case that some components gets a score which is lower than deserved, which is almost equally bad, since it might prevent the reuse of a useful component. To reduce the errors due to weaknesses in the apriori estimation, the reusability score of a component will be adjusted when we have some experience with reusing it. This a-posteriori estimation is based on a logging of the observed productivity when the component is reused. The commonly used definition of productivity is:
Flexibility: The term flexibility is usually used to denote the existence of a range of choices available to the programmer or implementer - the more choices, the greater the flexibility. Flexibility is also referred to as "generality" or "useful complexity" [3]. Understandability: A software product is understandable to the extent that its purpose is clear to the inspector [3]. Confidence: The (subjective) probability that a module, program or system performs its defined purpose satisfactorily (without failure) over a specified time in an other environment than it was originally constructed and/or certified for (REBOOT Glossary definition). To prevent components of low reusability from entering the library we need some a-priori estimate of component reusability. In REBOOT, component qualification is based on a standard factor-criteriametria model, as shown in figure 1. The metrics used for a-priori reusability estimation were selected according to four sources: 1) results from other researchers, e.g. [8, 10, 11 2) expert opinions elicited through the use of questionnaires early in the project, 3) general statistical knowledge, and 4) experience with the use of metria in earlier software projects. The leap from criteria to metrics is based on the current state-of-the-art in the field of software
Productivity =
465
Lines of code developed Number of persondays used
Portability = 1
Flexibility =
-
4.1
Porting cost Development cost
- #h#htotounderstand develop
S O )
For portability, we thus estimate the effort of porting the component t o the required platform, relative to the effort of developing the component from scratch. The flexibility measure does the same for functional changes, and understandability for the mere effort of understanding the component. Our confidence estimate is dependent not only on the ratio of successful reuse, but also on the total number of reuses done. In order to include this into our estimate, we will introduce a prior belief plus the assumption that Confidence is Beta distributed. This gives us the estimator shown below. Confidence =
-
(#reuses with U.S. 2 (Max. 1)) Total #reuses 1
+
Abstraction: Usually a component can be characterized with a noun, e.g. stack, flight manager. Operations: Components have operations, and these are characterized in the Operation facet. Operates On: This facet describes the objects that this component acts on, e.g. integers, set, list, resource.
+ 0.5
Dependencies: These are non-functional dependencies and characteristics which makes reuse of the component more difficult, e.g. C++-based, Unixbased, Hood-based. If nothing else, this facet must at least indicate whether the component is an analysis, design or code component.
The User Satisfaction, “U.S.” ,is stated by the reuser simply by assigning a score to the component, and is thus a rather vague, subjective measure. “Max.” is the largest possible score for the User Satisfaction. As a component is reused, the original, a-priori estimates for portability, flexibility, understandability and confidence are checked against the observed estimates and the revised estimate will be a combination of the two - according to a formula such that after three reuses of a component, experience will have equal weight t o the a-priori estimates, and after subsequent reuses it becomes more and more dominant. The a-priori estimate has been given a weight of 3, in order to avoid making the result too sensitive to occasional luck or failure at reusing a component. On the other hand, if all experience points in the same direction, this will soon dominate an erroneous a-priori estimate. New est. =
(3 x Apriori est.
Faceted classification
With large libraries, reusers cannot know the contents by heart, and components must thus be described or classified in some way to make retrieval possible. For this, REBOOT uses a faceted classification scheme. Faceted classification was originally introduced in [13] to classify books. For software it was first used by Prieto-Dim [12]. Our scheme is similar to that of Prieto-Diaz. However, whereas he concentrated on functional components, we work with objectoriented components - thus we have adapted our set of facets t o this. We have decided t o use the following four facets:
Change productivity Development productivity
Understandability = max{ 1
The REBOOT classification scheme
4
With this definition of productivity, our a-posteriori estimators for the four factors for reusability have been defined a~ shown below:
As an example, we could have a stack (abstraction) of integer (operates on) written in C++ (dependencies) with operations push, pop, top, swap, i.e. it is possible to have more than one term for each facet. In addition to the facets, a component will have other attributes, such as who developed it, when it was developed, how big it is etc. The distinction between facets and other attributes is that the facets encode the component properties which are most relevant in connection with reuse.
4.2
+ Observed est.)
Term spaces and relaxed search
Faceted classification alone is not enough to ensure effective component retrieval for reuse.
4
The average experience will also be analyzed. If one finds that some factors are generally over- or underestimated, the computation of these can be analyzed and changed in order to give a more correct picture already from the a-priori estimate.
0
466
People use language differently, and thus, there may be a terminology mismatch between the person classifying a component and another person searching for it.
0
In development with reuse, one might be interested in a component even if it is not identical to the requirements. Besides, people might not know exactly what they are looking for.
to help the provider side when developing components, and the librarians when qualifying and inserting them, and the Reuse Assistant (RA), which helps the reuser side to retrieve, evaluate and adapt components for reuse in specific applications. Thus,
All these problems can be helped with related search, meaning that retrieval from the reuse library should not be restricted to exact matches with the users’ component requirements, but rather yield a list of the N closest components, where N can be specified by the user. The user can then evaluate the retrieved components more thoroughly afterwards. To support relaxed search, REBOOT uses sfrucfured term spaces for the facets, an approach similar to that of [ll]. In a term space, all the possible terms for a facet are related in a graph of weighted relations. The main structure is hierarchical, i.e. terms are related by generalization relations, forming a directed acyclic graph. In addition, non-hierarchical synonym edges relate terms which have more or less the same meaning. The REBOOT approach to weighted term spaces is described in [q. Since the structure of the term space will be rather ad hoc, one must expect to maintain it continuously, according to feedback from the clients of the library (both providers and reusers). REBOOT’S proposed heuristics for maintaining a term space are discussed in [14].
5
0
0
0
0
0
0
The REBOOT tool set
The Insertion tool (CBA) helps the producer of reusable components to insert the components into the REBOOT database. The Insertion tool will also support the evolution of the library, both with respect to components and term hierarchies. The Retrieval tool (RA) helps the reuser to select a suitable set of candidate components for reuse. The Qualification tool (CBA) quantifies the quality and reuse value of the components. The Evaluation tool (RA) helps the reuser to evaluate the components selected by the retrieval tool in order to find the best candidate for reuse. The Reengineering tool (CBA) helps the producer of components in order to analyze and restructure old applications t o identify, extract and reengineer new reusable components. The Adaptation tool (RA) helps the reuser to adapt the chosen component so that it can be reused in her system.
The work process is envisioned as follows: During development with reuse (right side), the application developers will try to retrieve components needed for their design. Candidate components are passed on to the evaluation tool, to identify the most appropriate one. This component is passed on to the adaptation tool, and adapted if necessary, whereby it is inserted into the application being developed. If, on the other hand, evaluation concludes that none of the candidates are suitable, a component request can be sent to “Development for reuse” (which will also be performed without specific component requests). Starting the reengineering tool, the input can either be components from the external world, or library components for which a need for improvement has been recognized, for instance during evaluation. REBOOT provides only the six tools shown in fig. 2. Development as such is supposed to be s u p ported by existing methods and CASEtools which the REBOOT environment can be integrated with. This will make industrial penetration much easier than if REBOOT had come up with a new development method and complete CASEtool of its own, since companies will be reluctant to change methods and
The REBOOT prototype environment for reuse support has been described in [5], and the first version of the prototype was demonstrated in April, 1992. The proposed way of working with the tool is shown in fig. 2.
Figure 2: The REBOOT tool set The environment has six tools, which can be considered as forming two mirror image groups, the Component Building Assistant (CBA), which is supposed
467
CASEtools in which they have already invested considerable resources.
Sanjiv Gossain and Bruce Anderson. An iterativedesign model for reusable object-oriented software. In Pm . ECOOP/OOPSLA’90, Esrez, UK,October 1990.
B. Gronquist, C. Viermain, and B. Bongard. A component approach for reuse. In Michel Galinier, editor, P m . 5th International Conference: Software Engineering d its Applications, TOULOUSE’92, Toulouse, France, December 1992. J. M. Juran. Quality Control Handbook. McGraw-Hill, New York, 1974. E.-A. Karlsson, G. Sindre, L. S. Serumgkd, and E. Tryjgeseth. Weighted term spaces for relaxed search. In P m . CIKM’92, Baltimore. ISMM, November 1992. Barbara Kitchenham. Towards a constructive quality model. part ii. Software Engineering Journal, July
Conclusion
6
We have discussed the special problems of largescale inter-group reuse and presented the REBOOT approach for solving these problems. To ensure the quality of the components in the library, we have developed a qualification tool encoding a metric-based computation of the quality and reusability of candidate library components. For component classification and retrieval, we have developed tools based on a faceted classification scheme with structured term spaces. All tools have been developed in the first prototype of the REBOOT reuse support environment. Although the results so far are promising, there is still much work to do: 0
1987.
John A. Lewis et al. An empirical study of the objectoriented paradigm and software reuse. In Proc. OOPSLA ’91, 1991.
So far, the qualification metrics only work for C++ source code components. Moreover, most of the metrics are standard software metrics, originally developed for procedural code. Thus, we want to do further investigation on specifically object-oriented metrics and extend our qualification model to deal also with analysis and design components.
James McCall and Mike Matsumoto. Software quality assurance, vol.ii. Technical report, Griffies AFB NY 13441-5700,April 1980. RADETR-80-109, ~01.11. Eduardo Ostertag et al. Computing Similarity in a Reuse Library System: An AI-Based Approach. ACM T~nsactionson Software Engineering and Methodology, 1(3):205-228, July 1992.
Ruben Prieto-Diaz and Peter Freeman. Classifying software for reusability. IEEE Software, pages 6-16, January 1987. S. R. Ranganathan. Prolegomena to library classification. Asian Publishing House, Bombay, 1967. Guttorm Sindre, Even-AndrC Karlsson, and Patricia Paul. Heuristics for maintaining a term space structure for relaxed search. In Proc. DEXA ’92, Valencia. Springer Verlag, 1992. IEEE Computer Society. IEEE Standard Glossary of Software Engineering Terminology. Technical report, 1983. ANSI/IEEE Std 729. IEEE Computer Society. Standard for a software quality metrics methodology. Technical report, April 1990. IEEE draft standard P-l061/D21. Lars S. S ~ r u m g t d ,Guttorm Sindre, and Frode Stokke. Experiences from the application of a faceted classification scheme. In Proc. 2nd International
We need more experimentation to check the feasibility of our classification scheme. Some studies have been done [lq, but so far, only code components have been classified, and there has been little experimentation with retrieval. In the REBOOT project we have an entire workpackage (120 man-months) devoted to the filling the database with reusable components. The second version of the prototype is due in mid1993.
References Thomas Bowen et al. Specifications of software quality attributes. Technical report, Griffigs AFB NY 13441-50,February 1985. RADC-TR-85-37, vol.11.
Workshop on Software Reuse (REUSE’93), Lucca, Italy. IEEE CS Press, March 1993.
William B. hakes. Reuse failure modes. In P m . 2nd Int’l workshop on roftware reuse, Dortmund, 1991.
Shirley GloskSoler. The DAGS Glossary. A Bibliography of Software Engineering Terms. Technical report, Rome Air Development Center, October 1979.
468
