next up previous
Next: Usage-based cost models for Up: Perspective Previous: Relation with other approaches


Identifying components for reuse

Recalling the discussions on code scavenging as a technique for reuse (Section 1.2) and on forward engineering versus reverse engineering (Section 2.1), we observe that there are two approaches to define components for reuse: (i) the a priori definition of parameterized components, and (ii) the post facto recovery of components from existing code.

Parameterized data types, such as modules and components, have a long history in computer science and they have been applied successfully in many projects. Defining a parameterized data type anticipates the reuse of the data type by establishing which parts can vary (the parameters) and which parts are fixed (all other aspects of the data type). Depending on the context, type constraints may be imposed on the instantiation of the parameters. Parameterized data types correspond, for example, to generics in Ada, and templates in C++. Reuse of parameterized data types is hindered by the fixed parameters--the data type could lend itself to more forms of reuse than can be expressed by the fixed set of parameters--and by limitations of static type constraints that forbid dynamic forms of polymorphism.

Parameterized components can also be recovered from existing code. One approach is to analyze existing code and search for strong correlations between data and code (, 1997). The outcome of such an analysis can be either code restructuring or conversion of the existing code into class definitions in an object-oriented language. Mayrand et al. (1996) describe the use of metrics for finding function clones. Another approach is to manually ``frame'' existing code fragments into reusable components to which parameters are added as needed (Bassett, 1996). Various fragments from the original code can then be regenerated from a single, reusable, frame by means of formalized low-level editing operations. In this way the set of reusable frames can slowly grow, thus decreasing the size of the code base that has to be maintained.

We conclude that techniques stemming from research on parameterized data types (type constraints, syntax-directed view on modules) and from the reengineering field (clustering, framing) could be fruitfully combined to open new perspectives on finding and defining reusable components.


next up previous
Next: Usage-based cost models for Up: Perspective Previous: Relation with other approaches
Paul Klint 2001-06-12