Karl J. Lieberherr Demeter and Aspect-Oriented Programming ABSTRACT The objective of the Demeter method and tools is to improve the productivity of software developers by an order of magnitude. We hope to achieve this through a methodology and tools supported by a theory of adaptive and aspect- oriented programming. To make our results practically useful, we want to leverage existing commercial technology such as Java, the Unified Modeling Language (UML [GRB97]) and design patterns. Our recent work has focused on rethinking our Demeter/C++ tools and the corresponding theory and to implement the new results in Demeter/Java. 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 also includes the coordination aspect Cool and the remote invocation aspect Ridl. Demeter/Java programs are typically written in a preventive maintenance style using traversal strategies for expressing object navigation. 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, adaptive programming, aspect-oriented programming DEMETER Adaptive Programming (AP) has been described in several papers, theses and a book (see Demeter home page [DEMpage] and [Lie96]). The idea of AP is to consider structure and navigation through structures and other issues as loosely coupled aspects which are woven together by a weaver [Ki96, G96]. However the details of how to carry out this idea are constantly being refined. In this paper we highlight some of the recent developments and we show the relationship to aspect-oriented programming. Demeter provides new ways to modularize your programs. Instead of having only classes as modular units we also use, for example, modular units for expressing object traversals. Adaptive programs are written in terms of traversal strategies, and they are customized into detailed traversals using specific class diagrams. The traversal strategies are simpler than the detailed traversals, leading to more flexible and simpler programs. The key idea behind traversal strategies is to make programs structure-shy so that they can be used with many different object structures. RECENT WORK In the following we highlight recent developments. Demeter/Java Demeter/Java [LO97] is an implementation of AP for Java extended with an efficiently executable design language based on [SPL96 and LP97]. In Demeter/Java we add several innovations to AP including an improved form of the Visitor pattern from [GANG4] provided by the design language. Fig. 1 summarizes the impact of AP on the coupling between aspects. We have four aspects: Functionality, Structure, Traversal and Object Description. The Functionality aspect is expressed by visitors. The Structure aspect is expressed by class graphs, the Traversal aspect by strategies and the Object Description aspect by grammars (annotated class graphs). The aspect weaver has two parts, a manual and an automatic part. The manual weaver specifies how traversals and visitors are combined into adaptive methods and the automatic weaver knows how to combine the four aspects into a running program. In Fig. 1 the entries in parentheses indicate how strong is the coupling with (first entry in parentheses) and without AP (second entry in parentheses). The table holds for both Java and C++. For example, without AP, traversals and functionality, expressed with visitors, are highly coupled: The visitor must have a method for each class in the traversal scope. With AP, the coupling between traversals and visitors is low since both traversal strategies and visitors mention only the interesting classes. Aspects Coupling to other aspects Structure Functionality (low, moderate) Traversal Structure (low, high) Functionality (low, high) Object Description Structure (low, high) Figure 1: Some aspects of AP Demeter/Java is much closer to Java than Demeter/C++ is to C++. Much of the syntax for propagation and transportation patterns was eliminated from the core of the system (The propagation pattern idea still exists in the form of syntactic sugar for more experienced users.). The most important generalization is probably the use of visitors instead of wrappers and the use of traversal strategies that generalize the earlier directives and their implementation. While Demeter/C++ uses a home-grown generic parser, Demeter/Java uses a commercial parser and scanner generator, namely the Java Compiler Compiler (JavaCC) [JavaCC]. JavaCC is used to create objects from robust object descriptions and an annotated UML class diagram which represents an LL(k) grammar. Demeter uses an improved form of the Interpreter design pattern [GANG4]: class definition and grammar definition are integrated. While in Demeter/C++ propagation patterns play a central role, in Demeter/Java they are only syntactic sugar to express certain commonly occurring traversals and visitors. The insight we gained was that propagation patterns were too big of an abstraction that is better decomposed into traversals and visitors with an attachment mechanism of visitors to traversals [SPL96]. While in Demeter/C++ traversals are static, in Demeter/Java with the TAO (traversal as objects) extension, traversals may be computed at run-time. While in Demeter/C++ generic behavior for copying, printing, etc. was hard coded for entire objects, in Demeter/Java you can selectively copy, print, etc. partial objects. This is accomplished by providing a CopyVisitor, PrintVisitor, etc. which is attached to a traversal selecting the subobjects of interest. While in Demeter/C++ conditional traversals were expressed in a not elegant way, Demeter/Java supports around methods. They provide for easier composition and provide also the foundation for dealing with exceptions in an aspect-oriented way. AP Studio Adaptive programming is a graphical programming technique and therefore we add a graphical user interface to Demeter/Java. The graphical nature comes from the three-tiered approach with graphs prominent at each level. At the first level strategy graphs describe task-based abstractions of class graph. At the second level, class graphs describe families of object graphs and at the third level object graphs are abstractions of objects. AP Studio currently allows to visualize class dictionaries and to create them graphically. AP Studio allows to visually design traversal strategies with immediate visual feedback regarding the selected paths. AP Studio is extended into a tool for developing adaptive programs. Traversal Strategies One of the improvements of AP to the Visitor design pattern is the use of traversal strategies. In earlier papers traversal strategies were called propagation directives or traversal specifications. Traversal strategies improve on traversal specifications by a better, more general model and a better compilation algorithm [LP97]. USE AND AVAILABILITY Several companies view the benefit of both simpler and more maintainable programs as very important and have adopted AP for C++. Some use our tools and others (for example, Hewlett Packard, see [DEMpage]) 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 distributed in Java source form from the Demeter home page where further information on use is available. The software is copyrighted but freely redistributable. It runs on any platform where Java is available. Demeter/Java is a successful teaching tool combined with [Lie96]. It is used in software design and development classes using Java. ASPECT-ORIENTED PROGRAMMING Aspect-oriented programming (AOP) has several roots including reflection, open implementation, composition filters, and object-oriented design methods such as Demeter. Gregor Kiczales and his group coined the term [AOPpage] and they stress in their work that AOP applies to other paradigms than the object-oriented paradigm. "Untangle your code into loosely coupled aspects" and "Avoid over-specification in your programs" are the mottoes of AOP. In AOP, programs are decomposed into suitable cross-cutting building blocks, i.e. building blocks that affect many parts of the combined program. Building blocks which contain redundant information are over- specified and need to be reduced to a description which removes the over-specification. The reduced description is expressed in an aspect description language. Avoiding over-specification leads to a solution of a more general problem while at the same time removing the redundancy from the program. The reduced building blocks need to be compiled together (or woven together by a weaver) into the original or an improved form of the original program. An important issue is how the reduced descriptions collaborate. They need to refer to a common vocabulary (join points) so that the compiler can regenerate the original program. To understand a program, we need to understand the aspects underlying the program. To avoid manual aspect extrication and to ease evolution, it is better to express the aspects directly. Evolution is simplified, since changes to aspects are localized to an aspect description rather than spread out through a program. Aspects should have the following properties: 1. Robust (change to one aspect should have a limited impact on other aspects), 2. Systemic (they affect the target program at many different places), 3. Cross-cutting each other (in the target program information about one aspect is mixed with information about other aspects), 4. Loosely-coupled (an aspect should not know the details of other aspects). Gregor Kiczales' and his group define aspects as follows [Ki97b]: With respect to a system and its implementation using a generalized procedure language, a property that must be implemented is (1) a component, if its implementation can be cleanly encapsulated in a generalized procedure (i.e. object, method, procedure, API). By cleanly, we mean well-localized, and easily accessed and composed as necessary or (2) an aspect, if its implementation cannot be cleanly encapsulated in a generalized procedure. This definition allows for the situation where adding a component makes an aspect a component. For example, we might start with components {C} and aspects {A1, A2}. By adding a suitable component W, we might get components {C, W, A1} and aspects {A2}. For example, by adding an appropriate weaver W, we can represent something which was an aspect as an object. Indeed, sometimes it is useful to have run-time objects representing aspects rather than weaving the aspects away at compile-time. The aspect definition demonstrates that being an aspect is relative to the components which are available. Consider an object-oriented program for a library application which is modularized into several classes, such as Library, Book, User, Printer. The problem with such a decomposition is that the code for multi-class collaboration will have to be distributed across multiple classes. This code is not nicely localized and therefore hard to understand and maintain. Cross cutting code is factored out into an aspect descriptions in AOP. For example, code that deals with object- marshaling in a distributed application is factored into aspect descriptions of the form: From Library to Printer send the book information described by strategy PRINTABLE. A similar solution is taken by the aspect description language Ridl [Lopes97, Lopes96]. Code that deals with synchronization is best factored out into a separate aspect descriptions of the form: This set of methods must be mutually exclusive. A similar solution is taken by the aspect description language Cool [Lopes97, LL94]. What is the relationship between adaptive (AP) and aspect-oriented programming (AOP)? AOP is a generalization of AP. In both cases a program is split into a core behavior and several loosely coupled aspect descriptions. But in AP we have the additional restriction that core behavior or some aspect descriptions must be expressed in terms of strategy graphs. The strategy graphs can often be used to describe the structure of emergent program entities (see [AOPpage]) at a high level of abstraction and therefore AP is a particularly useful form of AOP. However, there are many applications of AOP that do not fall into the AP category. One of them is the image processing application at Xerox PARC that does loop folding based on an aspect description language. For further related work on software composition, see [Mezini97]. SUMMARY AOP moves away from using a single composition mechanism for building software. AOP supports multiple composition mechanisms which are expressed in terms of aspect modules and their semantics. This leads to new forms of modularity which have a very positive effect on simplifying software evolution. Demeter/C++ as an application of AOP has already proven itself in commercial projects [DEMpage]. Several successful applications of AOP have been developed at Xerox PARC. We see a bright future for AOP because it introduces abstractions which help to eliminate some of the accidental difficulties of software development. 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. Many thanks to Gregor Kiczales and the Demeter Research group for their input. References [AOPpage] G. Kiczales et al., AOP home page, www.parc.xerox.com/aop. [BRG96] G. Booch, J. Rumbaugh, and I. Jacobson, The unified modeling language for object-oriented development. Technical report, Rational Software Corporation, 1996, www.rational.com/ot/uml.html. [DEMpage] Demeter home page www.ccs.neu.edu/research/demeter. [GANG4] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object- Oriented Software . Addison-Wesley, 1995. [G96] R. Guerraoui, Strategic Research Directions in Object-Oriented Programming, ACM Computing Surveys , 28(4), December 1996. [JavaCC] http://www.suntest.com/JavaCC [Ki96] G. Kiczales. Aspect-oriented programming. ACM Computing Surveys, 28A(4), December 1996. [Ki97b] G. Kiczales et al., Four technical reports on AOP, SPL-97-007 to SPL-97-010, Xerox PARC 1997. [LP97] Karl J. Lieberherr and Boaz Patt-Shamir, Traversal of Object Structures: Specification and Efficient Implementation, submitted for publication, 1997. [LO97] K. J. Lieberherr and D. Orleans. Preventive program maintenance in Demeter/Java (research demonstration). In International Conference on Software Engineering (ICSE ’97) , Boston, MA, 1997. [Lie96] K. J. Lieberherr. Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns PWS Publishing Company, Boston, 1996. ISBN 0-534-94602-X. [LL94] Cristina Videira Lopes and Karl J. Lieberherr, Abstracting Process-to-Function Relations in Concurrent Object-Oriented Applications, European Conference on Object-Oriented Programming 1994, Bologna, Italy, pp 81-99, editors Remo Pareschi and Mario Tokoro, Springer Verlag Lecture Notes. [Lopes96] Cristina Videira Lopes, Adaptive parameter passing, 2nd International Symposium on Object Technologies for Advanced Software, 1996, Springer-Verlag, Kanazawa, Japan, March, pp 118-136. [Lopes97] C.V. Lopes, D: A Language Framework for Distributed Programming, Ph.D. thesis in preparation, Northeastern University, 1997. [Mezini97] Mira Mezini, Variation-oriented Programming: Beyond classes and inheritance, Ph.D. thesis in preparation, Universitaet-Gesamthochschule Siegen, Germany. [SPL96] 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. An extended version will appear in IEEE Transactions on Software Engineering. Author: Karl J. Lieberherr, Northeastern University, College of Computer Science, 161 Cullinane Hall, Boston, MA 02115- 9959 USA lieberherr@ccs.neu.edu Demeter home page: www.ccs.neu.edu/research/demeter