Preventive Program Maintenance in Demeter/Java Karl J. Lieberherr, Doug Orleans
Northeastern University, College of Computer Science, 161 CN Boston, MA 02115-9959 USA (617) 373 2077 Fax: (617) 373 5121 flieberherr,
[email protected] Demeter home page: http://www.ccs.neu.edu/research/demeter Published in the Proceedings of ICSE' 97, Copyright 1997 ACM Press.
ABSTRACT
Demeter/Java is an implementation of Adaptive Programming (AP) for Java. Demeter/Java programs consist of Java code together with programs in a small language to express traversals, visitor methods, and class diagrams. Demeter/Java programs are typically written in a preventive maintenance style using traversal strategies for expressing traversals. The resulting programs are very robust under changes to the class diagrams and visitors. This preventive maintenance style also leads to simpler programs, making both software development and maintenance easier.
Keywords
software evolution, separation of concerns, aspectoriented programming
INTRODUCTION
Adaptive Programming (AP) has been described in several papers, theses and a book [5]. The idea of AP is to write programs in terms of traversal strategies, and to customize into detailed traversals using speci c class diagrams. The traversal strategies are simpler than the detailed traversals, leading to more exible and simpler programs. Demeter/Java is an implementation of AP for Java in the form of an eciently executable design language. In Demeter/Java we add an innovation to AP: an improved form of the Visitor pattern from [2] is provided by the design language. The Visitor pattern allows one to express a traversal through objects de ned by a class diagram and to reuse the traversal with several visitor objects. The visitor objects de ne the behavior which needs to be implemented on top of the traversal. The Visitor pattern has the disadvantage that the traversal code is spread out across the class diagram, and changes to the class diagram lead to many tedious updates of the traversals and visitors. In Demeter/Java, the Visitor pattern is improved by not writing the traversals explicitly in an object-oriented language, but by using a traversal speci cation lan-
guage. This leads to a separation of behaviors and interconnections between them. The visitor objects describe the important behavior, and traversal speci cations approximately specify how visitors are connected. Finally, a UML (Uni ed Modeling Language) [1] class diagram provides all the details to customize a traversal speci cation into a detailed traversal expressed in an objectoriented language.
TRAVERSALS
Traversals are ubiquitous in object-oriented applications. A traversal is a navigation through a group of related objects with the purpose of accomplishing some task. A single method is a degenerate traversal which visits only one object. But most of the time, a task needs the collaboration of several objects which know about each other. The way the objects know about each other is bound to change as a project evolves. For example, suppose another task requires di erent object relationships which need to be integrated with the current object relationships. But then many of the tasks which used the old object relationships need to be updated. This problem of fragile object relationships is called the small methods problem or structural anomaly [8, 6]. While each class has minimal coupling and works on its private data, the implementation of a task is usually spread across many classes. The implementation assumes a particular class organization that hard-wires structural knowledge paths into the program. This leads to a weakening of encapsulation and a signi cant maintenance problem. This demonstration presents a solution to the structural anomaly for Java software developers. The idea is to let the programmers express a traversal strategy instead of a detailed traversal. Writing the traversal strategy is a form of preventive maintenance since it simpli es maintenance later. Preventive maintenance sounds like more initial work for the programmer, but indeed the opposite is true since the programs become simpler. The simplest form of a traversal speci cation is: from Company to Salary, where Company and Salary are classes in some class diagram. Given a Company-object,
the traversal will nd all Salary-objects reachable from the Company object. We recognize the strategic nature of a traversal speci cation: not all the detailed traversal steps, such as go from Company to Divisions to Departments to Employees to Salary, are expressed but only the overall strategy to reach all Salary-objects. When a class diagram is given, we can automatically expand the strategy into a detailed set of traversal methods. AP offers a little language to express traversal speci cations allowing one to constrain traversals in both positive and negative ways. The semantics of traversals is de ned formally in [5].
VISITORS
The purpose of a visitor is to augment the behavior of traversals. Several visitor objects may be attached to the same traversal. When the traversal reaches a certain object, the visitors will do their work. Visitor objects are like ordinary objects and contain visitor methods which express what needs to be done when certain objects are reached. Visitors are often composed of subvisitors. For example, if we want to compute the average salary paid by a company, we would de ne a SummingVisitor which adds together all salaries and a CountingVisitor which counts the number of Salary-objects encountered during the traversal. An AverageVisitor would contain both the SummingVisitor and the CountingVisitor to compute the average. All three visitors are attached to the same traversal to accomplish their task simultaneously. Since visitor objects are just ordinary objects, they gain all the usual bene ts of object-oriented programming: encapsulation, inheritance, and polymorphism. This leads to greater re-use of the behavior embodied by each visitor object. Also, they themselves may be the subject of traversals, so that one may build up large collections of cooperating visitors and use AP to succinctly manage the data shared between them.
CLASS DIAGRAMS
Visitors de ne the interesting behavior of objects. Those behaviors need to be linked together and this is accomplished in two phases in Demeter/Java: we link visitors rst using traversal speci cations and then using UML class diagrams.
USE AND AVAILABILITY
Several companies see the bene t of both simpler and more maintainable programs as very important and have adopted AP for C++. Some use our tools and others use the ideas in a conventional C++ environment. Demeter/Java makes AP available to the Java community. Demeter/Java is implemented in Demeter/Java and is available as public domain software in Java source form from the Demeter home page where further information on use is available. Demeter/Java is a successful
OO teaching tool combined with [5].
RELATED WORK
Numerous references to related work are in [5]. Recently, aspect-oriented programming from Xerox PARC has emerged as an area related to AP [4, 3]. See also http://www.parc.xerox.com/aop. The work on context objects is a generalization of visitors [7].
ACKNOWLEDGEMENTS
This work is supported by DARPA and Rome Laboratory under agreement F30602-96-0239 and NSF under grant CCR-9402486 and a grant from Xerox PARC. We thank Jens Palsberg, Boaz Patt-Shamir, Linda Seiter, Mitchell Wand for their input to Demeter/Java and to Kedar Patankar, Binoy Samuel, Lars Hansen, and Johan Ovlinger, for their design/implementation help.
REFERENCES
[1] G. Booch, J. Rumbaugh, and I. Jacobson. The uni ed modeling language for object-oriented development. Technical report, Rational Software Corporation, 1996. http://www.rational.com/ot/uml.html. [2] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [3] R. Guerraoui. Strategic research directions in object-oriented programming. ACM Computing Surveys, 28(4), December 1996. [4] G. Kiczales. Aspect-oriented programming. ACM Computing Surveys, 28A(4), December 1996. [5] K. J. Lieberherr. Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns. PWS Publishing Company, Boston, 1996. ISBN 0-534-94602-X. [6] C. V. Lopes and K. Lieberherr. AP/S++: casestudy of a MOP for purposes of software evolution. In Re ection '96, S. Francisco, CA, April 1996. [7] L. M. Seiter, J. Palsberg, and K. J. Lieberherr. Evolution of Object Behavior using Context Relations. In D. Garlan, editor, Symposium on Foundations of Software Engineering, San Francisco, 1996. ACM Press. [8] N. Wilde and R. Huitt. Maintenance support for object-oriented programs. IEEE Transactions on Software Engineering, 18(12):1038{1044, December 1992.
