\documentstyle[twocolumn,icse97]{article} \begin{document} \title{Preventive Program Maintenance in Demeter/Java} Door \author{ \parbox{3.5in} {\begin{center} {\authornamefont 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 \\ \{lieberherr,dougo\}@ccs.neu.edu \\ Demeter home page: http://www.ccs.neu.edu/research/demeter\\ \end{center} } } \maketitle \copyrightspace \section{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. \subsection{Keywords} software evolution, separation of concerns, aspect-oriented programming \section{INTRODUCTION} %what is AP? Adaptive Programming (AP) has been described in several papers, theses and a book \cite{karl:demeter}. The idea of AP is to write programs in terms of traversal strategies, and to customize into detailed traversals using specific class diagrams. The traversal strategies are simpler than the detailed traversals, leading to more flexible and simpler programs. %what is new in Demeter/Java: improving the Visitor Demeter/Java is an implementation of AP for Java in the form of an efficiently executable design language. In Demeter/Java we add an innovation to AP: an improved form of the Visitor pattern from \cite{gang-of-4} is provided by the design language. The Visitor pattern allows one to express a traversal through objects defined by a class diagram and to reuse the traversal with several visitor objects. The visitor objects define 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. %how to improve Visitor? In Demeter/Java, the Visitor pattern is improved by not writing the traversals explicitly in an object-oriented language, but by using a traversal specification language. This leads to a separation of behaviors and interconnections between them. The visitor objects describe the important behavior, and traversal specifications approximately specify how visitors are connected. Finally, a UML (Unified Modeling Language) \cite{grady-jim:95} class diagram provides all the details to customize a traversal specification into a detailed traversal expressed in an object-oriented language. \section{TRAVERSALS} % traversals are everywhere 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. % structural anomaly The way the objects know about each other is bound to change as a project evolves. For example, suppose another task requires different 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 \cite{wilde-etal:maint-support,LopesLieberherrReflection96}. 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 significant maintenance problem. % solving structural anomaly 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. %The traversal %strategy turns out to be much more robust under changing object %relationships and therefore simplifies the maintenance of %programs. Writing the traversal strategy is a form of preventive maintenance since it simplifies maintenance later. Preventive maintenance sounds like more initial work for the programmer, but indeed the opposite is true since the programs become simpler. % traversal example The simplest form of a traversal specification is: from Company to Salary, where Company and Salary are classes in some class diagram. Given a Company-object, the traversal will find all Salary-objects reachable from the Company object. We recognize the strategic nature of a traversal specification: 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 specifications allowing one to constrain traversals in both positive and negative ways. The semantics of traversals is defined formally in \cite{karl:demeter}. \section{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 define 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 benefits 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. \section{CLASS DIAGRAMS} Visitors define 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 first using traversal specifications and then using UML class diagrams. \section{USE AND AVAILABILITY} % sales pitch Several companies see the benefit 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. %It runs on any platform where Java is available. %It is also a convenient %tool to teach effective object-oriented design techniques. Demeter/Java is a successful OO teaching tool combined with \cite{karl:demeter}. \section{RELATED WORK} Numerous references to related work are in \cite{karl:demeter}. Recently, aspect-oriented programming from Xerox PARC has emerged as an area related to AP \cite{sdcr:aop,sdcr:acm}. See also http://www.parc.xerox.com/aop. The work on context objects is a generalization of visitors \cite{spl:context-conf}. \section{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. \bibliographystyle{abbrv} \begin{thebibliography}{1} \bibitem{grady-jim:95} G.~Booch, J.~Rumbaugh, and I.~Jacobson. \newblock The unified modeling language for object-oriented development. \newblock Technical report, Rational Software Corporation, 1996. \newblock http://www.rational.com/ot/uml.html. \bibitem{gang-of-4} E.~Gamma, R.~Helm, R.~Johnson, and J.~Vlissides. \newblock {\em Design Patterns: Elements of Reusable Object-Oriented Software}. \newblock Addison-Wesley, 1995. \bibitem{sdcr:acm} R.~Guerraoui. \newblock Strategic research directions in object-oriented programming. \newblock {\em ACM Computing Surveys}, 28(4), December 1996. \bibitem{sdcr:aop} G.~Kiczales. \newblock Aspect-oriented programming. \newblock {\em ACM Computing Surveys}, 28A(4), December 1996. \bibitem{karl:demeter} K.~J. Lieberherr. \newblock {\em Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns}. \newblock PWS Publishing Company, Boston, 1996. \newblock ISBN 0-534-94602-X. \bibitem{LopesLieberherrReflection96} C.~V. Lopes and K.~Lieberherr. \newblock {A}{P}/{S}++: case-study of a {M}{O}{P} for purposes of software evolution. \newblock In {\em Reflection '96}, S. Francisco, CA, April 1996. \bibitem{spl:context-conf} L.~M. Seiter, J.~Palsberg, and K.~J. Lieberherr. \newblock {Evolution of Object Behavior using Context Relations}. \newblock In D.~Garlan, editor, {\em Symposium on Foundations of Software Engineering}, San Francisco, 1996. ACM Press. \bibitem{wilde-etal:maint-support} N.~Wilde and R.~Huitt. \newblock Maintenance support for object-oriented programs. \newblock {\em IEEE Transactions on Software Engineering}, 18(12):1038--1044, December 1992. \end{thebibliography} \end{document}