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
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.,
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.
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.
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.
Last Modified: 25 July 2001