Hi Macneil:

thank you for your paper:
On the Criteria to be used in Decomposing Systems into Aspects! 
by Kevin Sullivan and William Griswold et al.

Kevin also sent it to me but I could not 
read it due to an email glitch.

I found the paper very interesting.
The paper resumes a theme that Mira Mezini and I published in
our 1998 OOPSLA paper, namely the theme of
Interface-oriented Programming (IOP) for Aspects.
We did it for the AP case first. Some of this material was already in
my 1995 book on AP. 

@INPROCEEDINGS{mezini:oopsla98,
AUTHOR = "Mira Mezini and Karl J. Lieberherr",
TITLE = "Adaptive Plug-and-Play Components for
Evolutionary Software Development",
BOOKTITLE = "Object-Oriented Programming Systems, Languages and Applications
Conference, {\em in} Special Issue of SIGPLAN Notices",
YEAR = "1998",
MONTH = "October",
VOL = 33,
NUMBER = 10, 
ADDRESS = "Vancouver",
PAGES = "97-116",
EDITOR = "C. Chambers",
PUBLISHER = "ACM"
}

In the OOPSLA paper we did IOP for adaptive methods and
in a follow-on technical report with David Lorenz we 
generalized to IOP for aspects:

@TECHREPORT{aspectual:LLM,
AUTHOR       = "Karl J. Lieberherr and David Lorenz and Mira Mezini",
TITLE        = "{Programming with Aspectual Components}",
INSTITUTION  = "College of Computer Science, Northeastern University",
YEAR         = 1999,
MONTH        = "March",
NUMBER       = "{NU-CCS-99-01}",
ADDRESS      = "Boston, MA"
}

In the OOPSLA 98 paper we had IOP for adaptive methods:

adaptive methods = strategy graphs + visitors
written against interface class graph
mapping of interface class graph to class graph


In the Aspectual Components paper we did IOP for aspects:
Aspects are formulated against an interface class graph.

The motivation for the interface class graph was the
need to write programs before the implementation class graph is known.
The
interface class graph constrains the implementation class graph.

We did a formal study of what "constrains" should mean:

@INPROCEEDINGS{graph-refinement2:patt-shamir,
AUTHOR = "Karl J. Lieberherr and Boaz Patt-Shamir",
TITLE = "The Refinement Relation of Graph-Based Generic Programs",
BOOKTITLE = "1998 Schloss Dagstuhl Workshop on Generic Programming",
YEAR = "2000",
ADDRESS = "",
PAGES = "40--52",
EDITOR = "M. Jazayeri and R. Loos and David Musser",
PUBLISHER = "Springer",
NOTE =  "LNCS 1766"
}

The interface class graph is for
decoupling of implementation class graph from program.
The insight in the OOPSLA 98 paper was that
traversal strategies not good enough for doin the decoupling,
although they help already.

In your paper you repeat this argument: it is not good enough to
have pointcuts, we need pointcut interfaces.
In your paper you also 
decouple base design from aspect design using an interface.

In your paper you discuss the constraints imposed by the interface:

1. which nodes or edges must be exposed as join points. We use class-valued
   variables for this purpose.

2. how they are exposed through the JPM. I think here you mean how 
   the interface  information is mapped to a concrete system.

3. constraints on behavior across join points
   (pre and post conditions for the execution of advice conditions)
   This needs further development in our earlier work.

Now the question is: why did we not put this into DAJ or XAspects?
The reason is that I was afraid that another layer of abstraction
(the interface class graphs on top of the class graphs along with
name maps) would confuse my students.

When you look at our paper on strategies:

@article{973102,
author = {Karl Lieberherr and Boaz Patt-Shamir and Doug Orleans},
title = {Traversals of object structures: Specification and Efficient Implementa
tion},
journal = {ACM Trans. Program. Lang. Syst.},
volume = {26},
number = {2},
year = {2004},
issn = {0164-0925},
pages = {370--412},
doi = {http://doi.acm.org/10.1145/973097.973102},
publisher = {ACM Press}
}

you will see that name maps are treated for strategies.

But for building big systems, those interfaces are important.

-- Karl