"Untangle your code into cross-cutting, loosely coupled aspects" is the motto of Aspect-Oriented Programming (AOP) (AOP page at Xerox PARC). "Avoid overspecification in your programs" is another motto.

Aspect-Oriented Programming was named by Gregor Kiczales and his group and the Demeter team has used AOP ideas for several years before the name was coined. Early Definition of AOP at Northeastern. What is an aspect? 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

Early Works on Aspect-Oriented Programming

Connection between Aspect-Oriented and Adaptive Programming: Some history behind the names and concepts
Mehmet Aksit's History of AOP and SOC

Cristina Lopes Ph.D. thesis: The first Ph.D. thesis on Aspect-Oriented Programming . Is implemented for Demeter/Java (Northeastern) and AspectJ (Xerox PARC).

Northeastern Origins of AspectJ.

Talk on AOP and AP by Karl Lieberherr (Powerpoint source).

K. Czarnecki and U. Eisenecker. Generative Programming: Methods, Techniques, and Applications. Addison-Wesley.

David Lorenz on AOP and AP.

Programs are decomposed into suitable cross-cutting building blocks, i.e. a building block affects many parts of the combined program. Building blocks which contain redundant information are overspecified and need to be reduced to a description which removes the overspecification. The reduced description is expressed in an aspect description language. This 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 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: robust (change to one aspect should have a limited impact on other aspects), systemic (they affect the target program at many different places), cross-cutting each other (in the target program information about one aspect is mixed with information about other aspects), loosely coupled (an aspect should not know the details of other aspects), contain join points (which are used to combine the aspects).

It is difficult to give a precise definition of an aspect. See the four Xerox PARC reports from Gregor Kiczales' group: SPL-97-007 to SPL-97-010 which contain the following definition:

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. (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 as shown in the following table.

            components		aspects

before      {C}                 (A1,A2)
after       {C,W,A1}            {A2)

For example, by adding an appropriate weaver, 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.

From Transience to Persistence in Object-Oriented Programming: Patterns and Architectures gives further information on the relationship between AOP and AP. Adaptive Programming is the special case of Aspect-Oriented Programming where one of the aspects is expressible in terms of graphs and where the other aspects or components refer to the graphs using traversal strategies.

In other words: One special case of aspect-oriented programming is 'adaptive programming', in which one of the aspects is expressible in terms of graphs and the other aspects or components follow 'strategies' to control and interpret references to these graphs.

AOP is a generalization of AP. The following table shows four aspects which are the key aspects of Adaptive Programming. Each aspect has its own aspect description language. The grammar aspect defines the aspect description language for (tree) objects. Traversals are expressed in terms of a navigation strategy language and visitors by adding keywords like before and after to Java.

The four aspects are high-level aspects and can be viewed as aspect language mechanisms which can be used to program a variety of aspects.

Aspect Coupling Table

Aspects     |   Coupling to other aspects
-----------------------------------------------------------
            |			with AP		without AP
			     ------------------------------
grammar     |   visitors	low		moderate
-----------------------------------------------------------      
traversals  |   grammar		low		high	
            |	visitors	low		high
-----------------------------------------------------------      
object      |   grammar         low             high
descriptions
-----------------------------------------------------------      

High coupling implies larger program size.

We may view succinct subgraph specifications as sentences of a high-level aspect description language for the subgraph aspect which has different incarnations: the traversal aspect (defines traversal code) the persistence aspect (defines persistent parts) the communication aspect (defines parts to be shipped by copy), etc.

We may view visitor objects as a high-level aspect language to deal with the behavior modification aspect which has many different incarnations.

Crista Lopes asks: Why are visitors an aspect? In her thesis, she defines an aspect as "a property of a system which has an effect on the computation that doesn't necessarily align with functional modules." I view "visitors" as a very generic aspect. They are used to describe behavior modifications. The behavior modification aspect can be classified into subaspects: communication, coordination, exceptions etc. For example, the communication aspect as it relates to adaptive parameter passing, can be dealt with by providing a visitor for copying and a traversal for saying what to copy (and what to pass by oid). Certain kind of exception handling is elegantly expressed with visitors. So visitors are useful for expressing various kinds of aspects which have the flavor of behavior modification.

It should be noted that visitors are also used to express the core aspect in the form of behavior modifications to traversals.

Here is another way to carve AP into aspects, based on discussions with Crista Lopes. We have four aspects: The object functionality aspect, the object structure aspect, the object traversal aspect and the object description aspect. The object functionality aspect is expressed by visitors. The object structure aspect is expressed by class graphs, the traversal aspect by traversal strategies and the description aspect by grammars (annotated class graphs). The aspect weaver has two parts, a manual part 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.

The reason why we use the four aspects is that evolution of the adaptive programs is simplified. A change to one aspect might have implications to many places in the automatically woven program since the aspects cross-cut each other. Evolution of a program requires understanding of the aspects the program is made of. It is much easier to avoid extrication of the aspects from the woven program by representing the aspects directly in the program.

Research issues for AOP and AP

Visualization of Aspect-oriented programs and their transformation .

Ken Anderson's thoughts on AOP . Summarizes the work of Crista Lopes.

There is a connection between AOP and an application of Polya's Inventor's Paradox to programming. But AOP is more specific.

To Demeter home page

The AspectJ Primer