% 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.

Composition reconciles any differences in the structural concerns, in addition to controlling the resulting interface of the composed collaboration.
Interaction between concerns can be both explicit (via deferred features) or implicit, by attaching methods from one collaboration around methods of the other.

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 [NU technical report, 1999 on aspectual components]
are a generalization of adaptive plug-and-play components
(AP\&PC, OOPSLA 1998) with around methods. Recently, Clarke and Walter proposed a very similar
construct called Composition Patterns [ICSE 2001]. There is also a strong connection to HyperJ.

%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 Hyper/J.

\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 nad AP libraries and the DemeterJ code generators.
\end{enumerate}

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

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

%\bibliographystyle{plain}
%\bibliography{biblio}


\end{document}