Design Reuse Evaluations (DRE) - The Theory

DRE research was pioneered by Dr. Margie Price as part of her doctoral research ("Object-Oriented Design Methodology To Facilitate Reuse", UConn Ph.D., May 1998.) under the supervision of Professor Steven Demurjian at the University of Connecticut. It involves the user identifying special facets of software classes. Independent measurements of the software code, based on these user-specified classifications, are then used to measure the potenetial for reuse of the software components. A brief discussion of the ideas of the Design Reuse Evaluations is presented here, but the actual source papers and presentations are available as well.

Published Archival Papers

• Caballero, R. and Demurjian, S., "Towards the Formalization of a Reusability Framework for Refactoring", Proc. of 7th Intl. Conf. on Software Reuse, Austin, TX, Apr. 2002.
• Price, M., and Demurjian, S., "Analyzing and Measuring Reusability in Object-Oriented Designs", Proc. of 1997 OOPSLA Conference, Atlanta, GA, October 1997.
• Price, M., Demurjian, S., and Needham, D., "Reusability Measurement Framework and Tool for Ada95", Proc. of 1997 TriAda Conference, St. Louis MO, November 1997.
• Price, M., Needham, D. and Demurjian, S., "Producing Reusable Object-Oriented Components: A Domain-and-Organization-Specific Perspective", Proc. of 2001 Sympsium on Software Reusability, Toronto, Canada, May 2001.

Reusability Presentation

Project Meeting Presentations

Reusability Analysis for Shipbuilding Components Modeled in XML and Java
• October 2000 Status
• December 2000 Status
• June 2001 Status
• January 2002 Status

Software classes may or may not be intended on being reused. Some classes, such as GUI classes, may be intended specifically for the current application, and as such, are labelled as Specific classes. Other classes which may find a reason for reuse are labelled General. The first marking that the user of DRE must make is the Generality/Specificity of each class in the software system.

Classes' relationships to each other are also of importance when studying reuse. If a class is dependent on some function or variable of another class, then that second class must be used in any system that utilizes the first class. We define this as saying that the first class has a Relation to the second class, and any application which expects to use the first class must understand that the second class is to be used as well. Contrarily, any class that is completely independent of all other classes has no Relations. Each Relation that exists in the code must be identified by the user prior to the reuse calculations.

When all classes have been marked as General or Specific, and all Relations have been identified, the reusability calculations can begin. First, all Couplings in the code are identified. Couplings exist when code in one software class references code in another software class (by variable instantiation, method invocation, static variable reference, or any other way). Not all couplings are equal, however, and they are identified (based on the Generality and Relation information previously supplied) in one of four categories: good, bad, indifferent, or improvable.

The different coupling types:

• Good couplings (blue): Type 1 couplings are couplings that actually enhance the reuse potential of the classes. These couplings allow integrated classes to reuse functionality of each other, and as such, provide more powerful reusable components for future projects. Ideally, as many Type 1 couplings should exist in the system as possible.
• Bad couplings (red): Couplings of types 2, 3, and 4 are not good and will prevent proper reuse of classes. Type 2 couplings feature a dependency from a general class to another general class, but the classes are not meant to be reused together in the future; therfore, in order to reuse the source class, the entire coupled class must be integrated into the system, even though it should have no bearing on the first class. Type 3 and 4 couplings are dependencies from a general, reusable class to a specific, non-reusable class. All of these bad couplings should be removed from the design and code of the application in order to make the general classes reusable.
• Indifferent couplings (black): Type 6 and 8 couplings characterize dependencies that exist that are neither helpful or harmful toward reuse potential. These couplings originate at specific, non-reusable classes, and although they attempt to reference non-related classes, they do not impact the reuse of the general classes.
• Improvable couplings (green): Type 5 and 7 couplings do not hinder the reuse of any of the classes, but they could be restructured in such a way to improve the reuse potential of some of the other classes. In both of these types, dependencies exist between classes that are specified as related. The idea for improvement is in pushing these couplings up the hierarchy to more general classes, thereby creating more Type 1 couplings, and improving the reuse potential. Since these couplings are not harmful (originating from specific, non-reusable classes), they need not be improved in order to ensure that the reusable classes will be reusable, but are merely offered as a way to increase the reuse potential of the system.

When all couplings are identified, the different types of couplings are summed. High scores of good couplings suggest that the system is designed well, and large portions are reusable according to the identifications of the developer. All bad couplings should be examined and removed, so that the specified classes may indeed be reused. A high score of improvable couplings may signal that a large number of dependencies exist from specific classes to reusable classes, and these couplings may be improved by moving their sources to more general classes. A high score of indifferent couplings suggests that the application has a high number of dependencies between non-reusable classes that are unrelated, and nothing can be done to improve the reusability of them.