Early Definition of Aspect-Oriented Programming

The purpose of this note is to compare the definition of aspect-oriented programming as described by Gregor Kiczales and John Lamping and other Xerox PARC researchers with the most general definition of adaptive programming found in the AP book (Adaptive Object-Oriented Software, PWS, published August 1995, available from the Demeter home page).

The material described here is also treated in PowerPoint viewgraphs at Early AOP referred to as [Early AOP]. There are several graphical illustrations demonstrating the idea of crosscutting.

The AP book uses different words as follows:

book		Xerox PARC
Adaptive 	Aspect-oriented
View		Component or Aspect

The AP book contains the following definition: "Adaptive software is specified in terms of complementary, collaborating views, each one addressing a different concern of the application." The meaning of complementary, collaborating views is explained for the special case of two views V1 and V2: "An element v1 of V1 is formulated in terms of partial information about elements of V2." The meaning of complementary is that each view adds unique information to the program that is not covered by other views. The views are not simply users of each other but they are information providers. (Notation: with capital letters V1 and V2 we denote view types that describe sets of views and with small letters v1 and v2 we describe individual views. Sometimes we call both views.) The examples used in the book include a synchronization view, a structural architecture view, an object copying view, a distribution view, an error handling view etc.

The above definition of AP was influenced by interactions with my PhD students, primarily Cristina Lopes and Walter Huersch. They had all those nice examples collected from open implementation, composition filters, synchronization patterns, adaptive programming with traversal specifications to reflective programming and I tried to distill out what is common to them. The technical report

Walter Hürsch and Cristina Videira Lopes, Separation of Concerns. Northeastern University technical report NU-CCS-95-03, Boston, February 1995.
Abstract. Full paper was an inspiration for the distillation.

The crucial observation was that for the software to be expressive enough it needs to be split into building blocks that I called views and that those views only refer to partial information in other views. It is important that the partial information may be any subset of "important" information of a view. At another place in the book, I call the partial information "hooks". Later, after the book was finised, this partial information was called "join points".

The Xerox PARC definition distinguishes components and aspects. We call both components and aspects views. A component is considered a “behavioral view”.

The Xerox PARC definition of AOP stresses the importance of “croscutting”. The word "crosscut" does not show up in my book but it is implied: The partial information used from one view V may be spread out all over V. The following definition of "using partial information" is not contained in the book but is a natural way to make the definition precise. It is important to notice however that the informal definition covers more cases such as when the references are indirect. We have a view v1 consisting of words A1, ... ,An over some alphabet for view type V1. We have a view v2 consisting of words B1, ... ,Bm over some alphabet for view type V2. v1 uses partial information from v2 means that a subset of words in v2 appear in v1. In other words, some of the Ai are Bj.

A pictorial representation of the "partial information" definition of AOP is in [Early AOP, viewgraph 6]. From the picture and the above definition, it becomes clear that crosscutting is another good word to say the same thing. "v1 uses partial information from v2" implies that v1 crosscuts v2 except when the information referred to in v2 is contiguous. But even that can be viewed as a special case of crosscutting. v1 provides additional information for v2 each time v1 uses partial information from v2 and this additional information crosscuts v2.

The AP book contains many examples of crosscutting. The favorite style of example is where an adaptive program crosscuts a class graph by referring to some of the edges and nodes in the class graph.

An application of this scenario is where we have a component view describing a generalized procedure organization of a program. A second view (an aspect) is needed to express something that crosscuts the functional decomposition, for example the second view could express the synchronization.

On page 79/80 of my book there is another look at AP that comes closer to the generalized procedure case: An adaptive program consists of three parts: a graph C, an initial behavior specification expressed in terms of C and behavior enhancements expressed in terms of C. And elsewhere there is a description of a mapping of C into a bigger graph. Here the graph C and initial behavior correspond to components (generalized procedures) and the behavior enhancements are the aspects that add behavior. The concept of enhancement is present in AspectJ where you can add code before and after methods specified by a crosscut.

It is worthwhile to note that the Xerox PARC definition of AOP has evolved over time. For a while, AOP was meant to be only for systemic aspects like synchronization, distribution, failure handling, etc. Crosscutting collaborations like visitors or APPCs were for a while not considered aspects. In the meantime, the Xerox PARC definition has evolved and has actually come closer to the definition in the AP book.

For example, the following constructs were not included under AOP for a while, but now they are:

propagation patterns (Demeter/C++)
http://www.ccs.neu.edu/research/demeter/biblio/prop-pat1.html
IFIP '92

context objects
http://www.ccs.neu.edu/research/demeter/biblio/context.html
FSE '96

adjustments
http://www.ccs.neu.edu/home/mira/rondo.html

visitor objects (Demeter/Java)
http://www.ccs.neu.edu/research/demeter/biblio/demjava.html
http://www.ccs.neu.edu/research/demeter/DemeterJava/UserManual/
ICSE '97

adaptive plug-and-play components
http://www.ccs.neu.edu/research/demeter/biblio/components.html
OOPSLA '98

personalities
http://www.ccs.neu.edu/research/demeter/biblio/personalities.html

interaction graphs
http://www.ccs.neu.edu/research/demeter/biblio/interaction-graphs.html
OOPSLA '98 (demo)

In summary, the definition of AOP in the AP book stresses the importance of the coexistence of multiple organizations (views). Those views are composed by referring to each other but the references may be to internal parts of other views leading to crosscutting. The referenced internal parts may be spread over the entire referenced view. The generalization is rooted in several examples that show the need for multiple views.

The AP book contains the following definition of AOP but using a different terminology: Aspect-oriented programs consist of complementary, collaborating views, each one addressing a different concern of the application. Two views V1 and V2 are complementary, collaborating views if an element v1 of V1 is formulated in terms of partial information about elements of V2 and V1 adds information to V2 not provided by another view. The partial information in V2 is called join points and provides the range of an insertion mapping. The join points may be spread through V2 effectively crosscutting V2 with information from V1. The domain of the insertion mapping is in V1 and consists of weaves that refer to the join points. The weaves describe enhancements to V2. The goal is to separate views by minimizing dependencies between them (loose coupling) so that a large class of modifications in one view has a minimum impact on the other views.

Loose coupling may be achieved by writing each view in terms of constraints on the other views (constraints are formulated in terms join points). This leads to a parameterized program with crosscutting parameters P(V1, V2, ...) where the actual parameters must satisfy the constraints. The parameters are dependent on each other; e.g., when v1 in V1 is selected then v2 is constrained by v1.

Views form a directed graph, called a graph of views. The nodes are views and if there is an insertion mapping from v1 to v2 then there is an edge from v1 to v2. The view graph must be acyclic. The views without outgoing edges are called "components" and the other views are called "aspects".

Each edge in the graph of views has a tangling measure associated with it: It is the number of join points in V2 that are not contiguous plus the number of times those join points are referenced in V1. (Notation: with capital letters V1 and V2 we denote view types that describe sets of views and with small letters v1 and v2 we describe individual views. Sometimes we call both views. Good alternative names for "view" are: "building block" or "model" or "unit").

Currently under revision: Please read our new paper: Programming with Aspectual Components that presents our current view of AOP.

To Demeter home page

AOP home page at Northeastern

The AspectJ Primer

Professor Karl J. Lieberherr
College of Computer Science, Northeastern University
Cullinane Hall, Boston, MA 02115
Internet: lieber@ccs.neu.edu
Fax: (617) 373 5121