@inproceedings{XAspects:SLS-oopsla-03,
AUTHOR = "Macneil Shonle and Karl Lieberherr and Ankit Shah",
TITLE = "XAspects: An Extensible System for Domain Specific Aspect Languages",
booktitle = "OOPSLA '2003, Domain-Driven Development Track",
YEAR = 2003,
MONTH = "October"
}
@TECHREPORT{XAspects:SLS03,
AUTHOR = "Macneil Shonle and Karl Lieberherr and Ankit Shah",
TITLE = "XAspects: An Extensible System for Domain Specific Aspect Languages",
INSTITUTION = "Northeastern University",
YEAR = 2003,
MONTH = "April",
NUMBER = "NU-CCS-03-6"
}
Feedback is appreciated.
March 30, 2004: How would Treecc fit into XAspects?
XAspects is a tool for experimenting with multiple AOSD solutions simultaneously. For example, we want to prototype key capabilities of ABB's Aspect System and use them simultaneously with other Aspect-Oriented techniques.
Viewgraphs related to this paper are in: Demeter Seminar April 7, 2003.
Notes:
Additional Related Work:
@article{ hudak96building,
author = "Paul Hudak",
title = "Building domain-specific embedded languages",
journal = "ACM Computing Surveys",
volume = "28",
number = "4es",
pages = "196--196",
year = "1996",
url = "citeseer.nj.nec.com/hudak96building.html" }
Paul Hudak, in a position paper [hudak96building], writes:
"A domain-specific language is the ultimate abstraction".
He makes the point that we should start with a general purpose
programming language and then embed several domain specific languages
in it. We agree with this view but believe that a general purpose
aspect-oriented language like
Fred, now called Socrates [doug:aosd-2002] (an extension of Scheme) or
AspectJ (an extension of Java) is a better host language.
@INPROCEEDINGS{doug:aosd-2002,
AUTHOR = "Doug Orleans",
TITLE = "Incremental Programming with Extensible Decisions",
BOOKTITLE = "First International Conference
on Aspect-Oriented Software Development",
YEAR = "2002",
ADDRESS = "Enschede, The Netherlands",
PAGES = "",
EDITOR = "Gregor Kiczales",
PUBLISHER = "ACM Press",
NOTE="http://www.ccs.neu.edu/home/dougo/papers/aosd02/"
}
Hudak also proposes a semi-automated approach to partial evaluation because
using a general purpose approach was painful. XAspects takes this approach.
For example, to freeze the class graph and the visitor in the XAspect program
declare traversal: void visitBooks(): everyBook (MyBookVisitor);
(see section 1.2) we freeze first the class graph into the everyBook
strategy and then we freeze the MyBookVisitor into the traversal code.
A general purpose partial evaluator would have difficulty performing those
partial evaluations as efficiently.
====== next topic
How far can a general purpose aspect-oriented language go?
From the point of view of Demeter,
what is missing from AspectJ is to have more powerful inter-type declarations.
Instead of a simple
A.foo() { /* fixed */ } we would like to have
parameterized declaration let X in from A to B { code(X); }
which would create multiple inter-type declarations.
In XAspects we use the notation:
declare strategy: down: "from * bypassing -> *,parent,* to *";
declare strategy: eachFile: "intersect(from CompoundFile to File, down)";
declare traversal: void listAll(): eachFile(FileLister);
Giving AspectJ the capability to express families of inter-type declarations
would give it better separation of concerns capabilities.
But would it be useful for something else than traversals?
[See: Parametric Introductions by Hanenberg/Unland, AOSD 2003, page 80]
====== next topic
Limitation of traversals:
A simple binary tree could be coded using
traversals. But I found using the traversals didn't add much value,
because insertion and deletion would need to deal directly with the
structure anyway.
In general, when the class graph is small and specific to one task, traversal strategies don't help because the visitor method implementations have to deal with the structure anyway.
Traversal strategies help when the class graph is large and used for many tasks. Each task is typically using only an abstraction of the class graph (expressed by a traversal strategy).
====== next topic
Configuration plug-ins
Comparing XAspect plug-ins to UNIX commands is a useful analogy.
Like a UNIX command, a plug-in should have one clear purpose.
Like a UNIX command, a plug-in should have configuration options.
For example, the class dictionary plug-in should be configurable to
generate getters and setters and constructors in a certain format.
A generic visitor plug-in should have configuration options for selecting
the subset of visitors that is desired.
A composition of the class dictionary plug-in and the visitor plug-in
is like an enhanced class dictionary plug-in that produces useful code
from a class dictionary. This is similar to an alias command in UNIX.
======= next topic
The Java 1.5 metadata facility (JSR 175) is useful for
expressing certain aspects. We should have guidelines about when using
the metadata facility and when using a plug-in.
======= next topic
An important issue in XAspects is how much information each aspect A
needs to have about other aspects for A to function properly.
Many aspects depend on each other by using common names and those common names
might indicate constraints that must hold between aspects.
Consider the Traversal aspect in Fig. 3 which depends on the ClassDictionary
aspect. The statement "from AudioLib to CD" in the Traversal aspect
makes the assumption about the ClassDictionary aspect that there there is
a "path" "from AudioLib to CD". If there is no such path it would be
impossible to ever find a CD in the audio library.
It is the responsibility of the plug-in designers to check
for those dependencies.
All properties of the code that the Traversal aspect would
need from "the other aspects" will be available in the first bytecodes
generated. It is important that intertype declarations are added by all
plug-ins in the first compilation phase. The intertype declarations
might modify the class graph and the complete class graph is needed for
computing the traversals in the second phase. It is interesting to notice
that the Traversal aspect is dependent on all aspects that create intertype
declarations for additional parameterless methods (all to be included
in the class graph by DJ). So one aspect may
be dependent on many other aspects. The addition of one intertype declaration
might break many traversals and requires the testing of all traversals whose
TraversalGraph changes because of the new intertype declaration.
The alternative of not using the traversal aspect would even be
worse because then we would have to maintain all navigation code manually
rather than using an automatic tool.
We can generalize from this traversal example to other aspects:
All properties of the code that an aspect would
need from "the other aspects" will be available in the first bytecodes
generated.
Remark about current constraints in XAspect:
Even though the current system does sound a bit too constrained it so far
seems likely RIDL, COOL, DemeterJ/DAJ, and AspectJ styles are all
supported, and multi-methods shouldn't be difficult either. To obtain
HyperJ level features we should probably allow plug-ins to create new
packages, with which they can create anything.
FUTURE WORK:
------------
An interesting future project would be to reimplement a
subset of Java Web Services (JAX*) using XAspects.
@misc{web-services
,title={{Java Web Services}}
,howpublished={{ http://java.sun.com/webservices/ }}
,xauthor={SUN Microsystems}
,note={Continuously updated}
}
JAX* uses many sublanguages and some of them are aspectual.
For example, JAX* contains
JAXB (Java Architecture for XML Binding)
and
JAXP (Java API for XML Processing).
It seems that the two don't work ideally together but the
intent is similar: We need schemas and their translation to Java
(this is the purpose of JAXB) and we need a high-level language
for processing the Java objects. JAXP uses XPath as the navigation language
and XPath has similar capabilities as traversal specifications.
An interesting question is: how would we reengineer the Web Services Pack using
XAspects? How would JAXB, JAXP, JAX-PRC, JAXM, JAXR look like
if reimplemented in XAspects?
We already have a beginning: A subset of
JAXB corresponds to the class dictionary plug-in and a subset of JAXP
corresponds (at least in intent) to the Traversal plug-in.
RELATED WORK:
-------------
This goes to the beginning of the related work section.
XAspects builds on Crista Lopes work on domain-specific aspect languages.
She proposed COOL and RIDL
@INPROCEEDINGS{sync-patts:ecoop94,
AUTHOR = "Cristina Videira Lopes and Karl J. Lieberherr",
TITLE = "Abstracting Process-to-Function Relations in Concurrent
Object-Oriented Applications",
BOOKTITLE = ecoop,
YEAR = "1994",
ADDRESS = "Bologna, Italy",
PAGES = "81-99",
EDITOR = "Remo Pareschi and Mario Tokoro",
PUBLISHER = spcs
}
@InProceedings{Lopes95b,
author = "Cristina Videira Lopes",
title = "Graph-based optimizations for parameter passing in
remote invocations",
editor = "Luis-Felipe Cabrera and Marvin Theimer",
pages = "179-182",
booktitle = "4th International Workshop on Object Orientation in
Operating Systems",
year = "1995",
organization = "IEEE",
publisher = "Computer Society Press",
address = "Lund, Sweden",
month = "August",
annote = "IWOOOS'95, short version"
}
which she developed further in her thesis:
@PHDTHESIS{crista:thesis,
AUTHOR = "Cristina Isabel Videira Lopes",
TITLE = "{D: A Language Framework for Distributed Programming}",
SCHOOL = "Northeastern University",
YEAR = 1997,
NOTE = "274 pages"
}
COOL and RIDL were also the crystallization point for AspectJ.
XAspects combines all those innovations into an integrated whole using the
powerful features of AspectJ to implement COOL and RIDL
and many other aspect languages using a plug-in approach.
@BOOK{CE00:gp,
AUTHOR = "Krysztof Czarnecki and Ulrich Eisenegger",
TITLE = "Generative Programming: Methods, Tools and Applications",
PUBLISHER = "Addison-Wesley",
YEAR = "2000",
SERIES = "",
VOLUME = ""
}
Czarnecki and Eisenegger also propagate the
idea of domain-specific aspect languages.
In section 5.5,
an aspectual DSL is defined as a
language that influences the semantics of other languages.
The section goes on "Implementing modularly composable
DSLs requires a common language implementation
platform providing all the infrastructure for implementing language plug-ins."
XAspects uses AspectJ and the XAspects compilation architecture
as the implementation platform.
In section 8.7 the point is made that the
model of modular language extensions is very appropriate for AOP.
A modular language extension can be
plugged into whatever configuration of language extensions we currently use.
Advantages of modular language extensions
are enumerated (they all apply to XAspects):
declarative representation,
simpler analysis and reasoning,
domain-level error checking,
domain-level optimizations.
In section 11.6 the point is made that Intentional Programming
@TECHREPORT{simonyi:95,
AUTHOR = "Charles Simonyi",
TITLE = "The Death of Computer Languages",
INSTITUTION = "Mircosoft Research",
YEAR = 1995,
MONTH = ,
NUMBER = "",
NOTE = "ftp://ftp.research.microsoft.com/pub/tech-reports/Summer95/TR-95-52.doc"
}
is a suitable technology for implementing modular language extensions.
We find that an XAspects-based approach that builds on AspectJ is more
promising because it is easier to implement crosscutting abstractions
when AspectJ is available as the underlying "assembly" language.