% Big thanks to doug for much 
% text. Karl, if you have any time, there is a comment at the very end
% about what is needed, IMO. Johan

\documentclass{acm_proc_article-sp}
%\documentclass{sig-alternate}
%\documentclass[10pt]{article}
%\documentclass[11pt]{article}
%\RequirePackage{paper}


%\addtolength{\voffset}{-0.5in}
%\addtolength{\textheight}{1in}
%\addtolength{\hoffset}{-0.5in}
%\addtolength{\textwidth}{1in}

\begin{document}

\title{Demeter Aspects}
\subtitle{[Extended Abstract]}

\numberofauthors{3}


\author{
\alignauthor Karl Lieberherr\\
Johan Ovlinger\\
   \affaddr{College of Computer Science}\\
   \affaddr{Northeastern University}\\
   \affaddr{Boston, MA~~02115}\\
\alignauthor David Lorenz\\
Mitchell Wand\\
   \affaddr{College of Computer Science}\\
   \affaddr{Northeastern University}\\
   \affaddr{Boston, MA~~02115}\\
\alignauthor Doug Orleans\\
Pengcheng Wu\\
   \affaddr{College of Computer Science}\\
   \affaddr{Northeastern University}\\
   \affaddr{Boston, MA~~02115}\\
}


\maketitle

% 50 words
\begin{abstract}
The Demeter group at Northeastern University has several interrelated research efforts in the aspect-oriented programming field.
A motivating goal is sketched, and each research area is related to reaching that goal.
% 32 words 

{\bf Keywords:} Advanced Separation of Concerns, Object Orientation, Aspectual Collaborations, Predicate Dispatching 
\end{abstract}

\section{Motivating Goal}

Programming language design is very goal oriented, and the goal is constant: to 
deliver high quality applications in a reasonable time frame. 
Programmers want to write large, complex applications quickly. 

The thesis of the group is that this can be achieved if the
programming language explicitly supports the following three principles:

\begin{enumerate}
\item {\bf Separation}  
Large applications cannot be monolithic. 
In order to be maintainable by teams of multiple programmers, 
the program must be separated into smaller 
pieces which can be owned by separate groups.
The difficulty comes in choosing the unit of separation. 
In the OO world, classes are both too small and too large; several teams will want to add behavior to intersecting sets of classes. 
The concept of concerns has been introduced by the aspect-oriented community to capture a slice of behavior scattered over several methods or classes.

\item {\bf Interaction} 
Complex interactions between concerns are needed in order to implement even relatively simple behaviors; caching methods' return values would seem to be a classical generic behavior, but the need to invalidate the cache at the right place couples the generic behavior to the underlying application.
By controlling interaction of concerns in the programming language, it is possible to replace explicit tangling with implicit advice, allowing the caching behavior to be more completely separated from the computation it caches.

\item {\bf Composition} 
In order to write applications quickly, it is important to be able to reuse code; this applies to concerns as well.
Specifically, we feel that it is important to be able to construct new concerns by composing existing ones. 
Flexibility must be balanced against static checking.
For example, allowing small differences in class graphs would seem to be a requirement to achieve a significant amount of reuse, while it would seem imprudent to allow two concerns that make incompatible assumptions about the structure of the heap to be composed.

\end{enumerate}

\section{Projects}

\begin{enumerate}
\item
{\bf Aspectual Collaborations (AC)} capture both structural and behavioral concerns in a single unit.
AC are modular building blocks that can be composed to construct AC with 
complex sharing between the constituent collaborations.
We address the issues discussed in \cite{OssherTarr:2001}.

Aspectual features are provided by allowing advice to be attached to methods.
The advice can be {\em generic} -- attachable to any signature method -- 
or {\em precise} -- attachable
to only precisely matching signatures, 
but able to access and modify arguments and return values.
In both cases, if and when the host method is invoked 
and whether exceptions are handled can be controlled by the aspectual method.

Deferred features allow AC to be declaratively 
complete, enough to be separately compiled, yet allow generic behaviors 
to access as-yet unprovided behavior.
Interaction between concerns can be both 
explicit (via deferred features) or implicit (via aspectual methods).

Composition is used to attach aspectual methods, 
provide deferred features, and control the interface of
the resulting collaboration.
Collaborations with differing structural assumptions 
can be composed by reconciling any differences 
in the composition declaration, greatly increasing 
the scope for reuse of concerns.

AC have been implemented ontop of AspectJ, 
and a separate bytecode-rewriting implementation is underway.
We apply AC to both real-time embedded applications with BBN and
banking applications with UBS.

Aspectual Collaborations \cite{aspectual:LLM} 
are a generalization of adaptive plug-and-play components
(AP\&PC, \cite{mezini:oopsla98}) with around methods. 
Recently, Clarke and Walker proposed a very similar
construct called Composition Patterns \cite{clarke-walker:cp2001,composition-patterns-impl}. 
There is also a strong connection to HyperJ \cite{tarr:n-degrees}.
Further work on AC is \cite{aspectual-collabs}.


%say something about sharing, scoping, complete attachments... but I hae to leave.


%\section{Predicate Dispatch Extension}

\item 
{\bf Predicate Dispatch Extension.}
In order to separate behavioral concerns, programming languages allow
behavioral units (such as procedures or methods) to be defined such
that dispatching between units is handled implicitly: the definition
of the behavioral unit includes a specification of when that behavior
should be executed, and the language arranges for the right unit to be
executed when the corresponding condition occurs.  For example, a
method definition in a typical object-oriented language specifies that
it should be run whenever a message matching the method name is sent
to an instance of the class it is attached to.  Predicate dispatching
generalizes this notion so that a method can specify that it
should be executed whenever an arbitrary predicate expression over the
message arguments is true.  By making the "when to execute" part of a
behavioral unit definition more flexible, we can better separate
behavioral concerns that would otherwise need to be tangled together
in an explicit dispatch expression.

We are developing an extension to predicate dispatching that can lead
to separation of cross-cutting behavioral concerns, by allowing
methods to specify that they modify other methods (around methods), as well as by
allowing their predicates to take into account other parts of a
message send context such as the control flow history.  These
extensions build a bridge between method dispatch research and
aspect-oriented programming research, by unifying the mechanisms
underlying both.

A common feature of the predicate dispatch work and the aspectual collaborations work 
is that they basically add around methods to achieve AOP capability.

%\section*{Semantics}

\item
{\bf Semantics.}
In order to better understand and precisely specify the mechanisms for
modularizing cross-cutting concerns, we are building up a set of
formal semantics for aspect-oriented programming.  We have started
with a denotational semantics for the basic building blocks of dynamic
join points and advice as embodied by AspectJ, using a variant of
store-passing monads to model computations and modeling
advice as procedure transformers.  Our goal is to develop a theory of
AOP that accounts for other models such as Demeter and HyperJ.

\item
{\bf Adaptive Programming (AP)} is a technology that helps to free
the programmer from the structural concern. We actively use and improve
this technology
in the form of the DJ and AP libraries and the DemeterJ code generators.
Recently, we developed a simplified, object based semantics for 
AP \cite{mitch:karl-2000}.
\end{enumerate}

The home page for our project is at:\\
www.ccs.neu.edu/research/demeter/
and further information about this poster is 
in the subdirectory
/papers/2001-poster.

%say something about sharing, scoping, complete attachments... but I hae to leave.

\section{Acknowledgments}
This work is supported by DARPA under agreement F33615-00-C-1694
and SKYVA International, Medford, MA.

\bibliographystyle{plain}
\bibliography{biblio}


\end{document}