Connections between Demeter/Adaptive Programming and Aspect-Oriented Programming (AOP)

The involvement of our team with AOP-related technology comes from the Law of Demeter. In order to write code that follows the Law of Demeter in an ideal way, we noticed that methods whose ad-hoc implementation is scattered across several classes, should and could be cleanly localized. This resulted in a clean separation of various behavioral concerns and of those concerns from the structural information (class graph). Crista Lopes, one of my former Ph.D. students, took this idea a step further to separating synchronization concerns in the form of synchronization patterns (ECOOP '94) and separating marshaling concerns in her work on adaptive parameter passing. Usage of the basic aspect-oriented idea in Demeter. Applications of Traversal Strategies.

So, clean separation of concerns was the interest of my research group, even before AOP existed as such. Crista pushed our approach in other directions. After her ECOOP'94 paper, she and Walter Huersch from our Demeter research group wrote in 1995 a technical report on Separation of Concerns. identifying several techniques (including composition filters, open implementation and adaptive programming) to deal with concerns that had scattered and tangled implementations. This report identified the general theme of concerns that had scattered and tangled implementations and proposed this as an important problem in software design/implementation. Afterwards, Crista joined the Xerox PARC team while still being a PhD student at Northeastern University and Gregor Kiczales became a coadvisor.

Several research groups have been working on ideas surrounding Aspect-Oriented Programming before the name was given by Gregor Kiczales and his research group. The work on Demeter/Adaptive Programming at Northeastern University is one such early instance of AOP. We also attempted an early general definition of AOP by abstracting from the AOP instances we knew. Adaptive Programming(AP) as a name was introduced around 1991. In adaptive programming, programs are decomposed into several crosscutting building blocks. Initially we separated out object representation as a separate building block. Then we added structure-shy behavior and class structure as crosscutting building blocks. Cristina Lopes proposed synchronization and remote invocation (data transport) as additional building blocks.

In her Northeastern University Thesis Project description of August 23, 1993, Cristina Lopes writes:

... The ability to distinguish structure from functionality is the basic 
ground for application development, and Demeter takes that separation in a
systematic way ... Moreover, distribution and configuration should 
be seen as two other dimensions of an application: although dependent
on the structure and functionality of the specific application, their control
should be as independent as possible.

In an email message to Andrew Black in 1993, Cristina Lopes explains the problem of scattering and tangling in software. From Lopes to Black, October 1993.

In a paper by Cristina Lopes of January 12, 1994, we read:

.. distribution and configuration must be seen as two 
other dimensions of an application, and must be separated from the first 
two (structure and functionality).
Cristina Lopes introduced the synchronization aspect in an ECOOP '94 paper. Separation of structure and behavior was introduced in an OOPSLA '91 tutorial and in a IFIP World Congress '92 paper. Cristina Lopes introduced the remote invocation aspect in an I-WOOOS'95 paper. Demeter papers

An early definition of AOP from Northeastern without using the AOP terminology is in the AP book. The 93/94 annual report of the Demeter Research Group contains an even earlier description of AOP without using the AOP terminology. This report was influenced by the Demeter Team members at that time who are all mentioned in the reports appearing in the references. The ECOOP '94 paper with Cristina Lopes on the synchronization aspect was influential on the report.

An early paper from Northeastern on AOP:

Walter Hürsch and Cristina Videira Lopes, Separation of Concerns. Northeastern University technical report NU-CCS-95-03, Boston, February 1995.
Separation of Concerns.

Cristina Lopes and myself then started a collaboration with Gregor Kiczales and his group. Cristina and Gregor and his team did not like the name "adaptive programming" and they introduced a better term: Aspect-oriented Programming. They also provided their own general definition and many more examples of AOP.

The new separate term is a very good one since it allows to distinguish two key ideas: "tangling control" (key idea behind AOP) and "structure-shyness" (key idea behind AP). Before the naming of AOP the concept of Adaptive Programming tried to fill both roles.

Given the new term of Aspect-oriented Programming we reworded our definition of Adaptive Programming in terms of Aspect-oriented Programming. The reason is to avoid confusion and to have a clear distinction between AP and AOP: In the following paragraph only, we use "building block" for "aspect" or "component".

Adaptive Programming (AP) is the special case of Aspect-Oriented Programming (AOP) where some of the building blocks are expressible in terms of graphs and where the other building blocks refer to the graphs using traversal strategies. A traversal strategy may be viewed as a partial specification of a graph pointing out a few cornerstone nodes and edges. A traversal strategy crosscuts the graphs it is intended for, only mentioning a few isolated nodes and edges. Traversal strategies may be viewed as regular expressions specifying a traversal through a graph. (Formally, a traversal strategy for a graph G is a subgraph of the transitive closure of G with some bypassing information added.) In summary: AP = AOP with graphs and traversal strategies. As an application of the above distinction, we can say that AP is a special case of AOP where some of the crosscutting is expressed adaptively using strategies to embed small graphs into large graphs. A key feature of this embedding is that it is specified by hiding the details of the large graphs which makes the graph embeddings 'adaptive' in that they work for a large family of large graphs.

(Latest paper on Traversal Strategies)

The Xerox PARC team and the Northeastern team agreed on such a definition through numerous email exchanges. ACM Computing Surveys

It is important to note that both AOP and AP are not tied to objects.

The definition of AP in terms of AOP is intentionally general. Since traversal strategies have at least a dozen applications (, it is likely that many incarnations of AOP will qualify as AP.

For example, an instance of the AspectJ tool from Xerox PARC with the remote invocation aspect added (as a library) becomes an AP tool. The remote invocation aspect uses a simple form of traversal strategies to express object-marshalling in a structure-shy way.

Aspect-oriented technology is developed further as part of Demeter/Java which is using a weaver for Java. See the weaver description in the Demeter/Java user manual: Both COOL and RIDL (from Crista Lopes PhD thesis) are a part of Demeter/Java.

This page links you to a new world of more flexible software. If you like what you found here, we appreciate your feedback and we would like to hear about your use of the technology. Please tell your software friends about this page.

Aspect-Oriented Programming (AOP)

Search Engine. Use if to find information with keywords (CCS site).

Karl J. Lieberherr
College of Computer Science, Northeastern University
Cullinane Hall, Boston, MA 02115
Fax: (617) 373 5121