up
Up: The DRE Project

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

Reusability Presentation

A detailed Presentation on our reusability framework is available.

Project Meeting Presentations

The project as funded by Electric Boat, Inc., has had a number of presentations since its inception in Summer 2000.

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:

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.


Last Modified: 25 July 2001