Abstract: This position statement presents the concept of Aspect-Oriented Programming as a promising area of research in programming languages and software engineering.
Categories and Subject Descriptors: D.2.10 [Software Engineering] Design; D.3.2 [Programming Languages] Languages
General Terms: Programming, Abstraction, Software Engineering, Separation of Concerns.
Additional Key Words and Phrases: abstractions, programming languages
To date, the primary idea for organizing software systems has been to break the system down into modular units such as subroutines, procedures, objects, clients and servers, etc. We note that all of these correspond relatively directly to blocks of executable code.
But consider an extremely complex system, such as the ``Smart Dust'' some MEMS researchers have proposed. Briefly speaking, this is a collection of thousands of tiny sensor-processor-communication units that can be distributed randomly over a large area to collectively perform some data-gathering function. (Other researchers have proposed similar systems, sometimes referred to as ``gunk'' or ``amorphous computing''.)
We claim that such a system cannot be built using the traditional style of modularity. What module do the distribution aspects go in? The power consumption aspects? Information combination? Failure handling? Communication strategy? Interaction of changing geometry and topology?
These system aspects fundamentally cut across both one another and the final executable code. An act of communication is also inherently distributed, consumes power, may fail and may require synchronization. The various aspects can be thought about relatively separately, but at the implementation level they must be combined.
But because modules correspond so directly to blocks of executable code and because the different aspects of concern cross-cut the executable code, the modules themselves end up being a tangled mess of aspects. We believe this TANGLING-OF-ASPECTS phenomenon is at the heart of much of the complexity in existing software systems. Further, we believe that adjusting the scale of modules (or the level of programming languages) won't help without addressing this root cause of the tangling. Instead what is needed is to be able to work with abstractions that correspond more directly to aspects of concern than to blocks of executable code.
We are working on a new programming paradigm, Aspect-Oriented Programming (AOP), that does just this. AOP works by allowing programmers first to express each of a system's aspects of concern in a separate and natural form, and then automatically combine those separate descriptions into a final executable form using a tool called an Aspect Weaver™.
The notion of ASPECTUAL decomposition is subtly but profoundly different from prevailing notions of modularity. By enabling engineers to reason and program using the natural aspects of concern for a system, even when those cross-cut both one another and the resulting executable code, AOP will make it possible to program systems as complex as Smart Dust and Gunk. It will also allow us to simplify a number of more near-term (even present and past) systems.
Like other programming paradigms, Aspect-Oriented Programming uses abstraction and decomposition to break large problems down into manageable sub-problems. But in AOP, the principles for decomposing (and abstracting) a problem are different. Other paradigms use a notion of functional decomposition -- they break problems down into units like procedures, objects, modules, clients, servers and the like, and then make abstractions of those units that expose their functionality but hide their implementation. An important property of all these units is that they correspond relatively directly to blocks of executable code. A module in the source program ends up being a (relatively) cohesive block of binary code in the output of the compiler.
In AOP, large problems are broken down in a different
way, using aspectual decomposition rather than functional decomposition.
Examples of the kinds of aspects we believe AOP should allow
programmers to think and program in terms of are shown in Table 1.
An important difference between aspects and functional units
is that aspects fundamentally cross-cut both each other and the
resulting executable code. So a cohesive aspect of concern in
the source program ends up being spread about and mixed in with
other aspects in the output of the weaver. This crucial difference
between programming paradigms based on functional decomposition
(i.e. procedural programming, object-oriented programming, modular
programming) and AOP, which is based on aspectual decomposition,
is captured in Figure 1.
| Domain: | distributed computing | image processing | operating systems |
| Aspects: | what the objects do | operations on pixel maps | resource utilization |
| their location | control structure | caching | |
| communication | memory usage | security | |
| synchronization | sharing |
Note that programming in terms of aspectual decomposition requires much more than just identifying the different aspects of concern. It requires being able to express those aspects of concern in a way that is precise and that makes the RELATIONS among the aspects of concern precise. This is what enables the Aspect Weaver to work, and is also what makes possible reasoning about the code, debugging the code, and all other parts of the program lifecycle.
As a first example of AOP, we present a small part
of one of the projects we have been working on-using AOP to handle
a representative class of distributed applications. The decomposition
we are working with in this domain focuses on three main aspects:
(i) what the objects do; (ii) how the objects communicate; and
(iii) synchronization. In working with this decomposition, we
use a C++-like language for the first aspect (i.e. what the objects
do). Two additional languages make it possible to express the
remaining aspects in a natural way. The figure below shows the
aspect-oriented program for a queue that can be accessed concurrently
by clients on different machines.
This example shows the power of the aspectual decomposition and AOP. The aspectually decomposed program is easy to write, maintain and reason about. Design and implementation of the weaver is moderately straightforward. The output of the weaver, that is the automatically tangled code, is quite efficient. (The tangled code is shown in Appendix 4.)
In this example, the aspect weaving is tightly connected to object invocations. This makes the weaver relatively straightforward to design and implement. In other examples of AOP, the weaving is more complex, because the points at which the different aspects cross-cut each other are more subtle.
We believe that a number of systems, new and old, include intuitions similar to those underlying Aspect-Oriented Programming. Among these are several of the systems developed by attendees of this workshop, including (at least): adaptive programming, composition filters, Synthetix, reflective systems and open implementation.
The contribution of our present work is in making the notion of AOP explicit and providing an initial set of concepts with which to discuss it. We are also developing, for the first time, systems constructed with AOP as an explicit guiding principle. In the rest of this very short position paper we present an example of AOP, and discuss a couple of important related points. A somewhat longer position paper (15 pages) is available at http://www.parc.xerox.com/aop for those who would like more details.
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation of the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or permissions@acm.org.