vol. 9, no. 1, january–february 2010 how aspectj is used ... · vol. 9, no. 1, january–february...

Vol. 9, No. 1, January–February 2010

How AspectJ is Used: An Analysis of ElevenAspectJ Programs

Sven Apel, Department of Informatics and Mathematics, University of Passau,Germany

While it is well-known that crosscutting concerns occur in many software projects, littleis known on how aspect-oriented programming, and in particular AspectJ, have beenused. In this paper, we analyze eleven AspectJ programs by different authors to answerthe questions: which mechanisms are used, to what extent, and for what purpose. Wefound the code of these programs to be on average 86 % object-oriented, 12 % basiccrosscutting mechanisms (introductions and method extensions), and 2 % advancedcrosscutting mechanisms (homogeneous advice or advanced dynamic advice). Basedon these results we initiate a discussion on the trade-off between expressiveness andsimplicity of languages that support the modularization of crosscutting concerns.

1 INTRODUCTION

While many studies have explored the capabilities of aspect-oriented programming(AOP) [36] to improve the modularity, customization, and evolution of software [19,63,18,40,27,26,29], little is known on how AOP has been used. As AspectJ1 is themost widely used AOP language, we want to know which AspectJ mechanisms areused, to what extent, and for what kinds of crosscutting concerns.

Although the first versions of AspectJ were released over seven years ago andthere have been a large number of downloads of the ajc tool (25,300 downloads ofaspectj-1.6.x.jar and 33,547 downloads of aspectj-1.5.x.jar – status March 2, 2009),we and others [55] have noted that there are only a few published, non-trivial pro-grams using AspectJ in open literature. With the help of colleagues, we have beenable to locate eleven different AspectJ programs authored at different universities,deliberately excluding our own case studies [33, 3, 39, 42]. These programs range insize from small programs of 1KLOC to larger programs of almost 130KLOC.

AspectJ offers a variety of programming mechanisms [35]. Basic crosscuttingmechanisms are simple introductions (a.k.a. inter-type declarations) and methodextensions; advanced crosscutting mechanisms include pieces of advice that advisewhole sets of join points and that are triggered by runtime events [2, 4]. But howoften are basic and advanced mechanisms actually used? In this paper, we definemetrics to answer this question.

Our analysis of the eleven AspectJ programs shows on average 86% of the code

1http://www.eclipse.org/aspectj/

Cite this article as follows: Sven Apel: How AspectJ is Used: An Analysis of Eleven AspectJPrograms, in Journal of Object Technology, vol. 9, no. 1, January–February 2010, pages117–142,http://www.jot.fm/issues/issue 2010 01/article2/

http://www.eclipse.org/aspectj/

http://www.jot.fm/issues/issue_2010_01/article2/

HOW ASPECTJ IS USED: AN ANALYSIS OF ELEVEN ASPECTJ PROGRAMS

is object-oriented, 12% uses basic crosscutting mechanisms, and 2% uses advancedcrosscutting mechanisms. This is the first time to our knowledge that a reasonablenumber of AspectJ programs has been analyzed and actual percentages reported.

Based on these findings we want to initiate a discussion on the trade-off betweenexpressiveness and simplicity of languages that support the modularization of cross-cutting concerns. On the one hand, there are languages like AspectJ that provide awide variety of sophisticated language constructs, such as pointcuts and advice, thatallow programmers to modularize concerns that crosscut the dynamic computationof a program and that affect many join points [45]. On the other hand, there is awide variety of languages that support only basic crosscutting mechanisms, such astraits [22], mixins [25, 15], and virtual classes [43, 49], which can be used to extendsingle classes and methods. These languages are simpler but also less expressive asthey do not support dynamic and homogeneous crosscutting. In current languagedesign, there seems to be a trade-off between expressiveness and simplicity, whichwe will discuss here.

Several researchers have criticized the advanced crosscutting mechanisms of lan-guages like AspectJ. Mechanisms like pointcuts and advice violate the principle ofinformation hiding and hamper program comprehension, maintenance, and evolu-tion [54, 1]. Looking at the usage distribution of crosscutting mechanisms in theanalyzed AspectJ programs (12% basic crosscutting mechanisms and 2% advancedcrosscutting mechanisms) the question arises whether or not a simpler languagewould have been more appropriate – a language that is less expressive, but sufficientfor 98% of the code of the analyzed programs (86% object-oriented mechanismsplus 12% basic crosscutting mechanisms). Recently, there has been an advent ofprogramming languages that are simpler than AspectJ but still support basic cross-cutting mechanisms, e.g., Jak [11], FeatureC++ [5], ContextL [31], Scala [49], Ji-azzi [46], Classbox/J [14], and Jx [48], so that it is worth analyzing and discussingtheir relation to languages like AspectJ and their relative benefits and drawbacks.

Furthermore, a significant volume of prior work in the areas of programminglanguages [11,5,31,49,46,14,48], generative programming [62,39,58,12,9,8,10], andsoftware design [52,59,32] has shown that programs can be created largely withoutadvanced crosscutting mechanisms. The statistics that we report on AspectJ usageare consistent with this observation and fertilizes the discussion of the trade-offbetween language expressiveness and simplicity. We document and discuss theseand other findings in this paper. We begin with a classification of crosscuttingconcerns.

2 CLASSIFICATION OF CROSSCUTS

In the literature crosscutting concerns (a.k.a. crosscuts) have been classified alongthree dimensions (homogeneous/heterogeneous) [20], (static/dynamic) [47], and (ba-sic/advanced) [4]. We use an example to illustrate them all.

118 JOURNAL OF OBJECT TECHNOLOGY VOL 9, NO. 1

2 CLASSIFICATION OF CROSSCUTS

1 package BasicGraph;

2 class Graph {

3 Vector nv = new Vector(); Vector ev = new Vector();

4 Edge add(Node n, Node m) {

5 Edge e = new Edge(n, m);

6 nv.add(n); nv.add(m); ev.add(e);

7 e.weight = new Weight();

8 return e;

9 }

10 Edge add(Node n, Node m, Weight w) {



13 e.weight = w; return e;

14 }

15 void print() {

16 for(Edge edge : ev) { edge.print(); }

17 }

18 }

19 class Edge {

20 Node a, b;

21 Color color = new Color();

22 Weight weight;

23 Edge(Node _a, Node _b) { a = _a; b = _b; }

24 void print() {

25 Color.setDisplayColor(color);

26 a.print(); b.print();

27 weight.print();

28 }

29 }

30 class Node {

31 int id = 0;


33 void print() {


35 System.out.print(id);

36 }

37 }

38 class Color { static void setDisplayColor(Color c) { ... } }39 class Weight { void print() { ... } }

Figure 1: A simple graph implementation.

An Example

Consider a program that implements a graph data structure (Fig. 1). It consistsof a base program BasicGraph plus two features Color and Weight, whichcrosscut the implementation of BasicGraph. BasicGraph refers to the graphimplementation without code implementing Weight and Color. The code ofColor is underlined and black and the code of Weight is slanted and red.

Classifying Crosscuts

Homogeneous and Heterogeneous Crosscuts

A homogeneous crosscut extends a program at multiple join points by adding thesame piece of code at each join point. In our example, the Color feature is homo-

VOL 9, NO. 1 JOURNAL OF OBJECT TECHNOLOGY 119


geneous since it introduces the same piece of code to Edge (Lines 21, 25) and Node

(Lines 32, 34).

A heterogeneous crosscut extends multiple join points each with a unique pieceof code. The Weight feature is heterogeneous since it extends Graph and Edge atdifferent join points with different pieces of code (Lines 7, 10–14, 22, 27).

Static and Dynamic Crosscuts

A static crosscut extends the structure of a program statically, i.e., it adds newclasses and interfaces and injects new fields, methods, and interfaces, etc. Overall,the features Color and Weight introduce 2 classes (Lines 38, 39) and inject amethod (Lines 10–14) to Graph and 3 fields (Lines 21, 22, 32) to Edge and Node.

A dynamic crosscut affects the runtime control flow of a program and can beunderstood and defined in terms of an event-based model [61,47]: a dynamic crosscutexecutes additional code when predefined events occur during program execution.An example construct that implements a dynamic crosscut is an extension of amethod, as we explain shortly. Overall, the features Color and Weight extend3 methods (Lines 7, 25, 27, 34).

Basic and Advanced Dynamic Crosscuts

The most primitive crosscut in AspectJ is a piece of advice that advises executionsof a single method. Object-oriented languages express such advice as method ex-tensions via subclassing (virtual classes or mixins), method overriding, and relatedmechanisms [43, 15, 25, 11, 48, 14, 23]. Dynamic crosscutting mechanisms in AspectJtranscend object-oriented mechanisms when they effect events other than singletonmethod executions (e.g., [50, 44]). Hence, we distinguish two classes of dynamiccrosscuts, basic dynamic crosscuts and advanced dynamic crosscuts. Basic dynamiccrosscuts:

1. affect executions of a single method,

2. access only runtime variables that are related to a method execution, i.e.,arguments, result value, and enclosing object instance, and

3. affect a program control flow unconditionally.

All other dynamic crosscuts are advanced. A rule of thumb is that the join pointsof basic dynamic crosscuts can be determined statically; the join points of advanceddynamic crosscuts are determined at runtime. With AspectJ, an advanced dynamiccrosscut is implemented by advanced advice and a basic dynamic crosscut by basicadvice. This distinction helps identify which pieces of advice make use of advancedAspectJ mechanisms and which pieces merely implement simple method extensions.


3 CODE METRICS

3 CODE METRICS

To see how programmers use AspectJ, we define five metrics that distinguish theuse of aspects in terms of the classifications discussed in the last section. For eachmetric, we count the number of lines of code (LOC) for different categories anddetermine the fraction of the program’s source for each category.

While using LOC (eliminating blank and comment lines) as a metric might becontroversial (e.g., how are ‘if’ statements counted?), we will argue that the yieldedstatistics would be no different than, say, using a metric that counts statements.At the end, we compare just fractions of a program’s code base associated with ourcategories. The essential results would remain valid.

Classes, Interfaces, and Aspects (CIA)

With the CIA metric we measure the fraction of classes, interfaces, and aspects ofa program. It tells us whether aspects implement a significant or insignificant partof the code base (as opposed to classes and interfaces).

We simply traverse all source files included in a given AspectJ project and countthe LOC of aspects, classes, and interfaces. Upfront we eliminate blank lines andcomments.

Heterogeneous and Homogeneous Crosscuts (HHC)

The HHC metric explores to what extent aspects implement heterogeneous andhomogeneous crosscuts. Specifically, we determine the fractions of the LOC associ-ated with advice and inter-type declarations (introductions) that are heterogeneousand homogeneous. The HHC metric tells us whether the implemented aspects takeadvantage of the advanced pattern-matching mechanisms of AspectJ.

We analyze each piece of advice and inter-type declaration: if its number of joinpoints is greater than one it is a homogeneous crosscut; otherwise it is heterogeneous.

Code Replication Reduction (CRR)

Homogeneous advice and homogeneous inter-type declarations are useful for reduc-ing code replication in a program. Suppose an aspect that advises 100 join pointsand executes at each join point 10 lines of code encapsulated in one piece of advice.This aspect would reduce the code base by approximately 990 lines of code. In orderto quantify this benefit, the CRR metric counts the LOC that could be reduced inan aspect-oriented version compared to an object-oriented equivalent.2

2We do not consider the fact that tangled code in the analyzed programs could be refactoredfirst using the ‘extract method’ refactoring before using aspects, thus, decreasing the CRR. For abetter comparability, we analyze the programs as they are.



We multiply the number of LOC of each homogeneous advice and inter-typedeclaration with the number of join points it affects (minus one).

Static and Dynamic Crosscuts (SDC)

The SDC metric determines the code fraction associated with static and dynamiccrosscuts. That is, it counts the LOC of inter-type declarations (static crosscut-ting) and pieces of advice (dynamic crosscutting). Note that heterogeneous andhomogeneous crosscuts can be either static or dynamic. The SDC metric tells us towhat extend aspects crosscut the dynamic computation of a program or the staticstructure of a program.

In AspectJ, we calculate the fraction of static and dynamic crosscuts by countingthe LOC associated with inter-type declarations and pieces of advice and comparingthem with the overall code base.

Basic and Advanced Dynamic Crosscuts (BAC)

The BAC metric determines the LOC associated with pieces of basic and advancedadvice. The BAC metric tells us to what extent the aspects of a program takeadvantage of the advanced capabilities of AspectJ for dynamic crosscutting. Basicpieces of advice implement simple method extensions.

In AspectJ, we consider a piece of advice to be advanced if its pointcut involvesmore than simply a combination of execution (or call3), target, and args.4

Tool Support

We have developed the AJStats5 tool to calculate general statistics such as thenumber of LOC of classes, aspects, advice, inter-type declarations, etc. To identifyhomogeneous crosscuts and the number of affected join points we have used theAJDTStats6 tool [33]. We are not aware of a tool that identifies advanced advice.In order to do so, we had to examine the code by hand.

4 CASE STUDIES

We have analyzed a diverse selection of AspectJ programs (see Table 1). The first 7are small programs (< 20KLOC); the last 4 are larger (≥ 20KLOC). In our tables

3Although the semantics of call is to advise the client side invocations of a method, it can beimplemented as method extension – provided that all calls to the target method are advised.

4execution can be combined with this, within, and withincode.5http://wwwiti.cs.uni-magdeburg.de/iti db/ajstats/6http://wwwiti.cs.uni-magdeburg.de/iti db/ajdtstats/


http://wwwiti.cs.uni-magdeburg.de/iti_db/ajstats/

http://wwwiti.cs.uni-magdeburg.de/iti_db/ajdtstats/

4 CASE STUDIES

� ��

��

� � � � � � � � � �� ! " � # � � � � � � �Figure 2: Fractions of aspect code and object-oriented code of the overall code base.

and figures, the programs are listed from smallest (Tetris) to largest (Abacus). Wealso indicate in Table 1 if the program was developed from scratch (Type S), or ifit was an AOP refactoring of an existing application (Type R).

The percentages that we report are averaged over the individual percentagesof the eleven programs and rounded to the nearest integer, unless a fraction of apercent is reported. We use a ± s to mean average a with standard deviation s.So 14 ± 10 % means an average of 14% was observed with a standard deviation of10. In certain situations, we will consider only a subset of the eleven programs, e.g.,large-sized programs only, in order to explore the specific properties of an individualprogram or subset of programs.

Note that we do not consider development aspects, i.e., aspects that had beenused during program development and removed before deployment. The reason isthat the aspects are typically not available or no longer exist. Our statistics andresults should be interpreted with this fact in mind. A comparison of developmentaspects and aspects actually deployed could be a topic of further research.

Statistics and Interpretation

The raw data that our statistics are based on can be requested from the authors.We begin with presenting the statistics and subsequently we interpret them.

CIA Metric

Figure 2 shows that aspect code occupies on average 14± 10% of a program’s codebase; the bulk are classes and interfaces. Aspects account for more of the code basein small programs (20± 6%) than in larger programs (3± 4%).



Table 1: Overview of the AspectJ programs analyzed.

Name LOC Source Description Typel

Tetris 1,030 Blekinge Inst.of Technologya

Implementation of the populargame

S

OAS 1,623 LancasterUniversityb

Online auction system S

Prevayler 3,964 University ofTorontoc

Main memory database system R

AODP 3,995 University ofBritishColumbiad

AspectJ implementation of 23design patterns

R

FACET 6,364 WashingtonUniversitye

CORBA event channelimplementation

S

ActiveAspect 6,664 University ofBritishColumbiaf

Crosscutting structurepresentation tool

S

HealthWatcher 6,949 LancasterUniversityg

Web-based information system S

AJHotDraw 22,104 open sourceprojecth

2D Graphics Framework R

Hypercast 67,260 University ofVirginiai

Protocol for multicast overlaynetworks

R

AJHSQLDB 75,556 University ofPassauj

SQL relational database engine R

Abacus 129,897 University ofTorontok

CORBA MiddlewareFramework

R

ahttp://www.guzzzt.com/coding/aspecttetris.shtml

bThe sources were kindly released by A. Rashid.

chttp://www.msrg.utoronto.ca/code/RefactoredPrevaylerSystem/

dhttp://www.cs.ubc.ca/˜jan/AODPs/

ehttp://www.cs.wustl.edu/ doc/RandD/PCES/facet/

fThe sources were kindly released by W. Coelho and G. Murphy.

gThe sources were kindly released by A. Garcia.

hhttp://sourceforge.net/projects/ajhotdraw/

iThe sources were kindly released by Y. Song and K. Sullivan.

jhttp://sourceforge.net/projects/ajhsqldb/

kThe sources were kindly released by C. Zhang and H.-A. Jacobsen.

lDeveloped from scratch (S) or refactored an existing program (R)


4 CASE STUDIES

� ��

�� ! � ! � � � " � # � #� $ �� % & � # �' � � ! � � � � $ #� $ �Figure 3: Fractions of homogeneous and heterogeneous crosscuts of the overall codebase.

HHC Metric

Figure 3 reveals the fractions of homogeneous and heterogeneous crosscuts. Wefound 1± 1% of the code base implements homogeneous advice and homogeneousinter-type declarations. In contrast, heterogeneous advice and heterogeneous inter-type declarations occupy a larger fraction 7± 6%. The remaining 6% of the total14% of aspect code deals with local members in aspects. In general, homogeneouscrosscuts are used infrequently.

Homogeneous advice and homogeneous inter-type declarations occupy a largerpart in small programs (2± 1%) than in larger programs (0.2± 0.3%).

CRR Metric

Figure 4 shows the different percentages of code reduction, i.e., cloned code thatwas eliminated by homogeneous advice and homogeneous inter-type declarations(6± 9%). On average, the small programs achieve a slightly larger reduction (7± 8%)than larger programs (6± 11%). Notice, the smallest program (Tetris) had no re-duction, while the second largest program (AJHSQLDB) had the highest 23%.

SDC Metric

Figure 5 shows the fractions of inter-type declarations (static) and pieces of advice(dynamic). We found 3± 3% implements inter-type declarations and 5± 5% imple-ments advice. The remaining 6% of the total 14% of aspect code deals with localmembers in aspects. On average, inter-type declarations and pieces of advice havebeen used to similar extents.

Since aspects have been used to a lesser extent in larger programs, also advice(1± 2%) and inter-type declarations (1± 2%) account for a smaller fraction of the



� ��

��

� � �� !" #� $ � � % �� & ' � �" � � � Figure 4: Code reduction achieved by aspects.

� ��

��

� �� ! �" # � � �� $ � � � �% � & � ' � �� ( � & # �� % � �% ) * �� ! % � �� % � �Figure 5: Fractions of static and dynamic crosscuts of the overall code base.

code base of large programs. In smaller programs advice (7± 5 %) accounts for aslightly larger fraction that inter-type declarations (4± 4 %).

BAC Metric

Figure 6 shows the fractions of basic and advanced advice. We found 1± 1 % of thecode base implements advanced advice. In contrast, basic advice occupies a largerfraction of 4± 4%. The remaining 9% of the 14% that aspects occupy deals withinter-type declarations and local members in aspects.

As with the HCC metric, we observed that advanced advice is used more fre-quently in small programs (1± 1%) than in larger programs (0.2± 0.3%).

Discussion

Figure 7 depicts the fractions of the code base of the AspectJ programs that ex-ploit advanced crosscutting mechanisms (i.e., homogeneous advice and homogeneous


4 CASE STUDIES

� ��

��

� �� ! � � " � � # � $ � �$ � % � � #& $ � � � � # � � � $ � �Figure 6: Fractions of basic and advance advice of the overall code base.

� ��

�� ! � � " � � # � ! �$ � � # � �� ! � � " � � # � ! �% $ & � � �' % ( # � � � � � � % � �Figure 7: Fractions of basic AspectJ and advanced AspectJ mechanisms of theoverall code base.

introductions, and advanced advice) and basic crosscutting mechanisms (heteroge-neous basic advice and heterogeneous introductions). On average, only a minorfraction of 2± 2% of the analyzed code exploits the advanced capabilities of As-pectJ; 12± 9% implements basic aspects, and the remaining 86% is object-orientedcode.

Our use of percentages of the overall code base does not tell the whole story.An alternative is to examine the use of advanced AspectJ mechanisms within theaspect code of a program, which could be argued as the fraction of the program’sbase that has been ‘factored-out’. This too does not tell the whole story, as entireclasses and interfaces may be (a potentially large) part of a concern implementationthat is ignored. Thus, percentages based only on aspect code would provide an over-estimation. Nevertheless, we show in Figure 8 that even with this overestimation,only 15± 9% of the aspect code accounts for advanced crosscutting mechanisms;the rest is basic crosscutting mechanisms.

The 6± 9% code reduction that we have observed is in line with prior work on



� ��

�� ! � � " � � # � ! �$ � � # � �� ! � � " � � # � ! �

Figure 8: Fractions of AspectJ and advanced AspectJ mechanisms of a program’saspect code.

clone detection that conjectures that 5–15% of large software projects are clones,i.e., replicated code fragments [13]. So there might be an untapped potential (further9%=15%-6%) of AspectJ to reduce code replication further because not all cloneshave been discovered. Also, some clones are not exact matches [7], so 5–15% maybe an upper bound that aspects can not reach.

5 EXTENDED OBJECT-ORIENTED LANGUAGES

In this section, we illustrate how languages that support only basic crosscuttingmechanisms can be used to implement most of the aspects found in the elevenAspectJ programs, namely 85% of all aspect code. We call these languages extendedobject-oriented languages since they add only a few new concepts to the standardrepertoire of object-oriented languages. Of course, we could have named them alsobasic aspect-oriented languages, although they do not support quantification [24].

Collaborations and Refinements

Like mainstream object-oriented languages, extended object-oriented languages, e.g.,Jak [11], FeatureC++ [5], ContextL [31], Scala [49], Jiazzi [46], Classbox/J [14], andJx [48], provide abstractions like classes, objects, and methods. Additionally, ex-tended object-oriented languages allow a programmer to extend a given class withoutmodifying it source code. This is also called the open class pattern [17] and thereis a wide variety of mechanisms to implement this pattern, e.g., traits [22], mix-ins [25, 15], virtual classes [43, 49], nested inheritance [48], refinements [11]. Forsimplicity, we call such extensions refinements.

A further crosscutting mechanism of extended object-oriented languages is theability to group multiple classes and refinements into an enclosing module. For



1 package Weight;

2 import BasicGraph.Graph; import BasicGraph.Edge;

3 refine class Graph {

4 Edge add(Node n, Node m) {

5 Edge e = original.add(n, m);

6 e.weight = new Weight(); return e;

7 }

8 Edge add(Node n, Node m, Weight w) {



11 e.weight = w; return e;

12 }

13 }

14 refine class Edge {

15 Weight weight;

16 void print() { original.print(); weight.print(); }

17 }

18 class Weight { void print() { ... } }

Figure 9: Implementing Weight with a collaboration module in Classbox/J.

example, with Jx’s nested inheritance we can introduce multiple new classes andrefine multiple existing classes in almost the same way as in with classboxes inClassbox/J, abstract types in Scala, components in Jiazzi, or layers in ContextL.For simplicity, we call such an enclosing module a collaboration module, inspired bythe work on collaboration-based design [60, 53]. A collaboration module containingmultiple classes and refinements crosscuts several places in a base program, so it isa basic crosscutting mechanism [53].

The BasicGraph program and the Weight feature of Section 2 can be im-plemented with collaboration modules and refinements. Weight extends Basic-Graph at several points by different pieces of code and it extends methods only.Figure 9 depicts a modular implementation of Weight based on classboxes writ-ten in Classbox/J. The classbox Weight extends the base program BasicGraph.It introduces the class Weight (Line 16) and extends the imported classes Graph

(Lines 1–11) and Edge (Lines 12–15) by refinements, which are declared by thekeyword refine. These refinements introduce new fields and methods and extendexisting methods. Within a method extension the keyword original refers to themethod that is being refined (Lines 5, 16).

Advanced Aspects

Not all concerns can be compactly expressed just by simple introductions andmethod extensions (e.g., by basic crosscutting mechanisms such as collaborationmodules and refinements). Sometimes there is a redundancy in the introductions orin the method extensions implementing a concern, which makes the crosscut homo-geneous. Consider the Color feature of the BasicGraph program of Section 2.Its representation in Classbox/J is shown in Figure 10.



1 package Color;

2 import BasicGraph.Node; import BasicGraph.Edge;

3 interface Colored { ... }

4 class Color { ... }

5 refine class Node implements Colored {


7 void print() {


9 original.print();10 }

11 }

12 refine class Edge implements Colored {


14 void print() {


16 original.print();17 }

18 }

Figure 10: Implementing Color with a collaboration module in Classbox/J.

1 aspect AddColor {

2 interface Colored { ... }

3 declare parents: (Node || Edge) implements Colored;

4 Color Node.color = new Color();

5 Color Edge.color = new Color();

6 before(Colored c) : execution(void print()) &&

7 this(c) { Color.setDisplayColor(c.color); }

8 static class Color { ... }

9 }

Figure 11: Implementing Color with an aspect in AspectJ.

Homogeneous Crosscuts

Note that the print methods of both Node and Edge are extended identically (Fig-ure 10; Lines 7–10 and 14–17), and also an identical field color is added to eachclass (Lines 6 and 13). Color could be expressed as an advanced aspect taking ad-vantage of the advanced pattern-matching mechanisms of AspectJ (see Figure 11).The aspect AddColor defines an interface Colored (Line 2) and it declares that Nodeand Edge implement that interface (Line 3); it introduces a field color (Lines 4–5),and it advises the execution of the method print of Edge and Node (Lines 6–7); theclass Color is introduced as static inner class (Line 8).

Advanced Dynamic Crosscuts

Occasionally concerns can use dynamic crosscuts, such as a collaboration moduleapplying a refinement to a class that is dependent on the program control flow,which is an advanced dynamic crosscut. For example, when implementing a newfeature of our graph example that modifies the routine of printing graph structures(PrintHeader) we can take advantage of the advanced mechanisms of AspectJfor dynamic crosscutting. Suppose the print methods of the participants of the



1 aspect PrintHeaderAspect {

2 before() : execution(void print())&&

3 !cflowbelow(execution(void print())) { header(); }

4 void header() { System.out.print("header: "); }

5 }

Figure 12: Implementing PrintHeader with an aspect in AspectJ.

1 package PrintHeader;

2 import BasicGraph.Node;

3 refine class Node {

4 static int count = 0;

5 void print() {

6 if(count == 0) printHeader();

7 count++; original.print(); count- -;

8 }

9 void printHeader() { /∗ ... ∗/ }

10 }

Figure 13: Implementing PrintHeader with a collaboration module in Class-box/J.

graph implementation call each other (especially, composite nodes that call printof their inner nodes). To make sure that we do not advise all calls to print, butonly the top-level calls, i.e., calls that do not occur in the dynamic control flow ofother executions of print, we can use the cflowbelow pointcut as a conditional(Fig. 12).

Figure 13 depicts an excerpt and approximation of the behavior of Print-Header implemented using Classbox/J; the complete implementation would bemore complex. Omitting advanced AspectJ mechanisms results in a workaround(underlined and green) for tracing the control flow and executing the actual exten-sion conditionally (Lines 6, 7).

While AspectJ code can be more compact, it is debatable whether the resultis easier to understand and maintain [54, 1], especially in situations where few joinpoints are affected (e.g., compare Figure 12 with Figure 13) [33]. Regardless, wefound that such dynamic crosscuts occur rarely (1%).

Corroborating Evidence

A review of the eleven AspectJ programs reveals that aspects often extend multipleobjects by multiple pieces of advice and inter-type declarations. In other words, theextensions an aspect typically makes to a base program are heterogeneous. Further-more, we have observed that aspects seldom used advanced AspectJ mechanismsbut mainly extended the static program structure by inter-type declarations andthe execution of methods by pieces of basic advice.

Other researchers that examined some of the eleven AspectJ programs came to



the same conclusion. For example, Liu et al. noted that the aspect refactoring ofPrevalyer corresponds closely to a version written in Jak, a extended object-orientedlanguage [39]. Also, Xin et al. observed that the Jiazzi version of FACET is closeto the aspect-oriented version [62].

Furthermore, we contacted the developers of the eleven AspectJ programs toask about their experience with the occurences and useability of basic and advancedcrosscutting mechanisms and their relationship to mechanisms of collaboration mod-ules and refinements, as explained above:

• The developer of Abacus (C. Zhang) confirmed that his aspect compositionwas driven by superimposition of views (collaboration modules). He extendedexisting classes by using AspectJ-style mixins (refinements) and implementedthe methods declared by interfaces.

• The developer of FACET (R. Pratap) answered that he definitely had to thinkof collaboration-style extensions while implementing features in FACET.

• The developer of ActiveAspect (W. Coehlo) said that the individual extensionsof classes applied by his aspect were heterogeneous. Generally, he did not thinkin terms of crosscutting dynamic computation.

• The developer of AJHotDraw (M. Marin) explained that there are a numberof refactored concerns in AJHotDraw whose implementations consist of classeswith multiple different refinements and that interact in various ways.

• The developer of Prevayler (I. Godil) confirmed that there are aspects that usebasic crosscutting mechanisms and that correspond to collaboration modules,which is in line with [39].

• K. Sullivan reported that his work on Hypercast was not intended (and didnot) explore the use basic and advanced crosscutting mechanisms, but ratherto take some easy/classical applications of aspects, such as logging, and to usethem to evaluate the notion of ‘obliviousness’.

• The developer of HealthWatcher (S. Soares) was unfamiliar with the conceptof basic and advanced crosscutting mechanisms as well as of the mechanismsof collaboration modules and refinements. He was unable to say whether hisaspects are related to collaboration modules and refinements or not.

We did not receive responses from the Tetris, OAS, and AJHSQLDB developers.The majority of responses indicate that the developers noticed the relationship andresemblance of aspect mechanisms to collaboration modules and refinements in theirwork – although not all were aware of the concept or the term.



Validity Discussions

The statistics of our study should be interpreted with the fact in mind that we limitedour attention to AspectJ. That is, we could not consider development aspects andother kinds of aspects such as used in container-based AOP.7 Furthermore, thereare three validity issues to our study: construct, internal, and external.

Construct

The distinctions between different concern classifications – homogeneous/heteroge-neous, static/dynamic, and basic/advanced – are both fundamental and well-recog-nized in the literature [20,19,47,2]. Our use of LOC (eliminating blank and commentlines) as a metric yielded statistics that would be different than, say, a metric thatcounts statements. Although any metric has problems (e.g., how are ‘if’ statementscounted?), the essential result of our paper, namely that advanced and homogeneouscrosscuts are used infrequently in our case studies, would remain valid.

Internal

There are always problems drawing significant conclusions from a small samplesize. This is a problem with any such study with AspectJ: there are only fewpublished, non-trivial programs using AspectJ in open literature. Moreover, theeleven programs have been mainly developed for academic purposes. A discussionin the AOSD.NET mailing list8 reveals that there are only a few published industrialprojects that use AspectJ, none of them available for download.

Furthermore, we were unable to contact authors of three of the programs. Evenassuming negative responses, a majority of the authors indicated that they wereaware of resemblance of their aspects with collaboration modules.

Another possible issue is that because the term ‘collaboration’ is overloaded andthe terms ‘basic’ and ‘advanced crosscutting mechanisms’ are unclear, there couldbe misunderstandings between the developers and us. To minimize this, we definedthe terms in our correspondences with authors, as explained in the previous sections.

External

We believe our results are representative of AspectJ usage. We explicitly omittedour own internal case studies, whose statistics are nevertheless consistent with thosewe reported [33,3,39,42]. We cite in related work additional corroborating evidence.

7Examples of container-based AOP are JBossAOP (http://jboss.com/products/aop) andSpringAOP (http://www.springframework.org/).

8http://aosd.net/pipermail/discuss aosd.net/2007-May/002163.html


http://jboss.com/products/aop

http://www.springframework.org/

http://aosd.net/pipermail/discuss_aosd.net/2007-May/002163.html


And finally, we and others have been building systems for years by composing col-laboration modules and refinements without using advanced AspectJ mechanisms;AspectJ might have helped in the cases where advanced aspects could be used (e.g.,to reduce code replication). We are aware of only a few such cases in our own code.

The trade-off between language expressiveness and simplicity in software devel-opment is addressed in the next section.

6 DISCUSSION: EXPRESSIVENESS VS. SIMPLICITY

In the 2% of the code base, where advanced crosscutting mechanisms are used, let usassume that the use of AspectJ is appropriate. For the remaining 98%, an extendedobject-oriented language is appropriate. The question is, on the one hand, whetherone could not simply use an extended object-oriented language for all crosscuttingconcerns, emulating advanced crosscutting mechanisms (2% of the code base) andaccepting a certain amount of boiler plate code and code replication, as explainedin Section 5. On the other hand, one could simply use an (AspectJ-like) aspect-oriented language for all crosscutting concerns, as it has been done in the elevenAspectJ programs. Is there a difference between the two options?

We argue that there is indeed a difference. The two options reveal a trade-off between expressiveness and simplicity of programming languages that supportthe modularization of crosscutting concerns. Clearly, AspectJ-like languages arevery powerful and expressive but this comes at a cost. It has been argued thatthe advanced crosscutting mechanisms violate the principle of information hidingand hamper program comprehension, maintenance, and evolution [54,1]. Extendedobject-oriented languages are simpler but cannot express all kinds of crosscuttingconcern concisely.

We believe that our findings in the analysis of the eleven AspectJ programs can(re)initiate a discussion on this issue. The result of our study is that only 2% of thecode base have been implemented with advanced crosscutting mechanisms. Is thisfraction worth of using AspectJ and inviting many problems caused by its advancedmechanisms? Or is this fraction relevant and justifies the use of AspectJ?

A compromise may be to use the basic crosscutting mechanisms of extendedobject-oriented languages (collaboration modules and refinements) for heterogeneousand basic dynamic crosscutting concerns and the advanced crosscutting mechanismsof aspect-oriented languages (pointcuts and advice) for homogeneous and advanceddynamic crosscutting concerns? Previous work in support of this position is [56, 6,38,30,4].


7 RELATED WORK

7 RELATED WORK

Collaborations and Refinements

Although the concept of collaboration modules predates AOP by quite some time [52,10, 60], mainstream programming languages have been very slow to support them.AspectJ has filled the vacuum [45]. The weak support of collaboration modules inaspect and non-aspect mainstream languages has contributed to a general confu-sion regarding their relationship to, importance to, and frequency in crosscuttingconcerns. Nevertheless, several studies demonstrate that extended object-orientedlanguages suffice in implementing large applications [10,12,8, 9, 11,58].

There are many languages that incorporate the concept of refinements and collab-orations in its language design, although sometimes called differently, e.g., Jak [11],FeatureC++ [5], ContextL [31], Scala [49], Jiazzi [46], Classbox/J [14], Jx [48].While the capabilities and mechanisms of these languages differ considerably, theiraim at aggregating classes that collaborate in modules and extending or overridingexisting classes is very similar. For example, with Jx’s nested inheritance we canintroduce and refine existing classes in almost the same way as in with classboxesin Classbox/J, abstract types in Scala, components in Jiazzi, or layers in ContextL.

Several approaches even combine collaboration modules and advanced AspectJmechanisms to benefit from both worlds, e.g., Relationship Aspects [51], CaesarJ [6],FeatureC++ [5], Aspectual Collaborations [38], and Object Teams [30], but theiruse has not been extensive.

Representative AOP Case Studies

Colyer and Clement refactored an application server using AspectJ (3 homogeneousand 1 heterogeneous crosscuts) [19]. While the number of aspects is marginal, thesize of the case study is impressively high (millions of LOC). Although they drawpositive conclusions, they admit (but did not explore) a strong relationship of theiraspects to collaboration modules and refinements.

Coady and Kiczales undertook a retroactive study of aspect evolution in the codeof the FreeBSD operating system (200–400KLOC) [18]. They factored 4 crosscuttingconcerns into AspectC aspects; inherent properties of concerns were not explainedin detail.

Lohmann et al. examine the applicability of AspectC++ to embedded systems(2 homogeneous and 1 heterogeneous crosscuts) [40]. Tesanovic et al. implemented10 AspectC++ aspects for quality-of-service management in database systems [57];the aspects implement predominantly heterogeneous and basic dynamic crosscuttingconcerns, which is in line with our study.

Lopez-Herrejon et al. analyzed an AspectJ implementation of the AHEAD ToolSuite [42]. They found 1% of the code base associated with advice; the rest consists



of introductions. They did not consider advanced advice.

Greenwood et al. conducted a quantitative case study exploring the effects of anaspectual decomposition on design stability [29]. They implemented 8 crosscuts inthe HealthWatcher system with AspectJ, but they did not say whether these arebasic or advanced. Although they used AspectJ and CaesarJ they did not explorethe relationship of basic and advanced crosscutting mechanisms

Classification Schemes

Alternative classification schemes of aspects and the crosscutting concerns they im-plement have been proposed in the literature. For example, spectative, regulative,and invasive aspects [34], harmless and harmful advice [21], or observers and assis-tants [16], that all classify aspects based on the invasiveness of their effects on thebase program. Our distinction between heterogeneous and homogeneous as well asstatic, basic and advanced dynamic is orthogonal to these previous proposals. Ourclassification has been shown useful to compare two different lines of research inprogramming languages.

AOP Metrics

Zhang and Jacobson use a set of object-oriented metrics to quantify the programcomplexity reduction when applying AOP to middleware systems [63]. They showthat refactoring a middleware system (23KLOC code base) into aspects reduces thecomplexity and leads to a code reduction of 2–3%, which is in line with our results.

Garcia et al. analyzed several aspect-oriented programs (4–7KLOC code base)and their object-oriented counterparts [27,37]. They observe that the AOP variantshave fewer lines of code than their object-oriented equivalents (12% code reduction).

Zhao and Xu propose several metrics for aspect cohesion based on aspect de-pendency graphs [64]. Gelinas et al. discuss previous work on cohesion metrics andpropose an approach based on dependencies between aspect members [28].

All of the above proposals and case studies take neither the structure of cross-cutting concerns nor the difference between basic and advanced crosscutting mech-anisms into account.

Lopez-Herrejon et al. propose a set of code metrics for analyzing the crosscut-ting structure of aspect-based product lines [41]. They do not consider elementarycrosscuts but analyze crosscutting properties of entire subsystems (features), whichmay have a substantial size. Thus, the crosscutting structure of a feature can behomogeneous, heterogeneous, or any value in between the spectrum of both. Theydo not distinguish between basic and advanced dynamic crosscuts.


8 CONCLUSION

8 CONCLUSION

We have analyzed eleven AspectJ programs of different sizes and complexity. Wefound that on average 2% of the code base is associated with advanced crosscuttingmechanisms; 12% is associated with basic crosscutting mechanisms; and 86% isobject-oriented. These numbers indicate that languages that provide only basiccrosscutting mechanisms are appropriate to implement a large extent of the analyzedprograms. Instead, AspectJ, a more powerful language, has been used. Since voiceshave been raised that advanced crosscutting mechanisms, like the ones provided byAspectJ, may be too powerful, we initiated a discussion on the trade-off betweenexpressiveness and simplicity. Currently, it is not clear if the advanced crosscuttingmechanisms provided by AspectJ outweigh the problems caused by the violation ofthe principle of information hiding. Our studies can help to expedite the academicdiscussion and to conduct further case studies on this issue.

ACKNOWLEDGEMENTS

We thank D. Batory, K. Fisler, M. Grechanik, C. Kastner, P. Kim, S. Krishnamurthi,C. Lengauer, D. Perry, and C. T. Shepherd for their helpful comments on earlierdrafts of this paper. The author’s research is sponsored by the German ScienceFoundation (DFG), # AP 206/2-1.

REFERENCES

[1] R. Alexander. The Real Costs of Aspect-Oriented Programming. IEEE Soft-ware, 20(6), 2003.

[2] S. Apel. The Role of Features and Aspects in Software Development. PhDthesis, School of Computer Science, University of Magdeburg, 2007.

[3] S. Apel and D. Batory. When to Use Features and Aspects? A Case Study.In Proc. Int’l. Conf. Generative and Component-Based Software Engineering,2006.

[4] S. Apel, T. Leich, and G. Saake. Aspectual Feature Modules. IEEE Trans.Software Engineering, 34(2), 2008.

[5] S. Apel, M. Rosenmuller, T. Leich, and G. Saake. FeatureC++: On the Sym-biosis of Feature-Oriented and Aspect-Oriented Programming. In Proc. Int’l.Conf. Generative and Component-Based Software Engineering, 2005.

[6] I. Aracic, V. Gasiunas, M. Mezini, and K. Ostermann. An Overview of CaesarJ.Trans. Aspect-Oriented Software Development, 1(1), 2006.



[7] B. S. Baker. On Finding Duplication and Near-Duplication in Large SoftwareSystems. In Proc. Work. Conf. Reverse Engineering, 1995.

[8] D. Batory, L. Coglianese, M. Goodwin, and S. Shafer. Creating Reference Ar-chitectures: An Example from Avionics. In Proc. Int’l. Symp. Software Reuse,1995.

[9] D. Batory, C. Johnson, B. MacDonald, and D. v. Heeder. Achieving Extensi-bility Through Product-Lines and Domain-Specific Languages: A Case Study.ACM Trans. Software Engineering and Methodology, 11(2), 2002.

[10] D. Batory and S. O’Malley. The Design and Implementation of HierarchicalSoftware Systems with Reusable Components. ACM Trans. Software Engineer-ing and Methodology, 1(4), 1992.

[11] D. Batory, J. N. Sarvela, and A. Rauschmayer. Scaling Step-Wise Refinement.IEEE Trans. Software Engineering, 30(6), 2004.

[12] D. Batory and J. Thomas. P2: A Lightweight DBMS Generator. J. Intell. Inf.Syst., 9(2), 1997.

[13] I. D. Baxter, A. Yahin, L. Moura, M. Sant’Anna, and L. Bier. Clone DetectionUsing Abstract Syntax Trees. In Proc. Int’l. Conf. Software Maintenance, 1998.

[14] A. Bergel, S. Ducasse, and O. Nierstrasz. Classbox/J: Controlling the Scope ofChange in Java. In Proc. Int’l. Conf. Object-Oriented Programming, Systems,Languages, and Applications, 2005.

[15] G. Bracha and W. R. Cook. Mixin-Based Inheritance. In Proc. Europ. Conf.Object-Oriented Programming and Int’l. Conf. Object-Oriented Programming,Systems, Languages, and Applications, 1990.

[16] C. Clifton and G. Leavens. Observers and Assistants: A Proposal for ModularAspect-Oriented Reasoning. In Proc. Int’l. Workshop Foundations of Aspect-Oriented Languages, 2002.

[17] C. Clifton, G. Leavens, C. Chambers, and T. Millstein. MultiJava: ModularOpen Classes and Symmetric Multiple Dispatch for Java. In Proc. Int’l. Conf.Object-Oriented Programming, Systems, Languages, and Applications, pages130–145. ACM Press, 2000.

[18] Y. Coady and G. Kiczales. Back to the Future: A Retroactive Study of AspectEvolution in Operating System Code. In Proc. Int’l. Conf. Aspect-OrientedSoftware Development, 2003.

[19] A. Colyer and A. Clement. Large-Scale AOSD for Middleware. In Proc. Int’l.Conf. Aspect-Oriented Software Development, 2004.


8 CONCLUSION

[20] A. Colyer, A. Rashid, and G. Blair. On the Separation of Concerns in Pro-gram Families. Technical Report COMP-001-2004, Computing Department,Lancaster University, 2004.

[21] D. S. Dantas and D. Walker. Harmless Advice. In Proc. Int’l. Symp. Principlesof Programming Languages, 2006.

[22] S. Ducasse, O. Nierstrasz, N. Scharli, R. Wuyts, and A. Black. Traits: AMechanism for Fine-Grained Reuse. ACM Trans. Programming Languages andSystems, 28(2), 2006.

[23] E. Ernst. Higher-Order Hierarchies. In Proc. Europ. Conf. Object-OrientedProgramming, 2003.

[24] R. Filman and D. Friedman. Aspect-Oriented Programming Is Quantificationand Obliviousness. In Aspect-Oriented Software Development, pages 21–35.Addison-Wesley, 2005.

[25] R. Bruce Findler and M. Flatt. Modular Object-Oriented Programming withUnits and Mixins. In Proc. Int’l. Conf. Functional Programming, 1998.

[26] A. Garcia, C. Sant’Anna, C. Chavez, V. Silva, A. v. Staa, and C. Lucena.Separation of Concerns in Multi-Agent Systems: An Empirical Study. In Soft-ware Engineering for Multi-Agent Systems II, Research Issues and PracticalApplications, 2003.

[27] A. Garcia, C. Sant’Anna, E. Figueiredo, U. Kulesza, C. Lucena, and A. v. Staa.Modularizing Design Patterns with Aspects: A Quantitative Study. In Proc.Int’l. Conf. Aspect-Oriented Software Development, 2005.

[28] J. F. Gelinas, M. Badri, and L. Badri. A Cohesion Measure for Aspects. J.Object Technology, 5(7), 2006.

[29] P. Greenwood, T. Bartolomei, E. Figueiredo, M. Dosea, A. Garcia, N. Cacho,C. Santa-Anna, S. Soares, P. Borba, U. Kulesza, and A. Rashid. On the Impactof Aspectual Decompositions on Design Stability: An Empirical Study. In Proc.Europ. Conf. Object-Oriented Programming, 2007.

[30] S. Herrmann. Object Teams: Improving Modularity for Crosscutting Collabo-rations. In Proc. Int’l. Net.ObjectDays Conf., 2002.

[31] R. Hirschfeld, P. Costanza, and O. Nierstrasz. Context-Oriented Programming.J. Object Technology, 7(3), 2008.

[32] R. Johnson and B. Foote. Designing Reusable Classes. J. Object-OrientedProgramming, 1(2), 1988.

[33] C. Kastner, S. Apel, and D. Batory. A Case Study Implementing Features usingAspectJ. In Proc. Int’l. Software Product Line Conf., 2007.



[34] S. Katz. Aspect Categories and Classes of Temporal Properties. Trans. Aspect-Oriented Software Development, 1(1), 2006.

[35] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W. G. Griswold.An Overview of AspectJ. In Proc. Europ. Conf. Object-Oriented Programming.Springer, 2001.

[36] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes, J.-M. Lo-ingtier, and J. Irwin. Aspect-Oriented Programming. In Proc. Europ. Conf.Object-Oriented Programming, 1997.

[37] U. Kulesza, C. Sant’Anna, A. Garcia, R. Coelho, A. v. Staa, and C. Lu-cena. Quantifying the Effects of Aspect-Oriented Programming: A MaintenanceStudy. In Proc. Int’l. Conf. Software Maintenance, 2006.

[38] K. J. Lieberherr, D. Lorenz, and J. Ovlinger. Aspectual Collaborations – Com-bining Modules and Aspects. Computer J., 46(5), 2003.

[39] J. Liu, D. Batory, and C. Lengauer. Feature-Oriented Refactoring of LegacyApplications. In Proc. Int’l. Conf. Software Engineering, 2006.

[40] D. Lohmann, F. Scheler, R. Tartler, O. Spinczyk, and W. Schroder-Preikschat.A Quantitative Analysis of Aspects in the eCos Kernel. In Proc. Int’l. EuroSysConf., 2006.

[41] R. Lopez-Herrejon and S. Apel. Measuring and Characterizing Crosscutting inAspect-Based Programs: Basic Metrics and Case Studies. In Proc. Int’l. Conf.Fundamental Approaches to Software Engineering, 2007.

[42] R. Lopez-Herrejon and D. Batory. From Crosscutting Concerns to ProductLines: A Function Composition Approach. Technical Report TR-06-24, De-partment of Computer Sciences, The University of Texas at Austin, 2006.

[43] O. L. Madsen and B. Moller-Pedersen. Virtual Classes: A Powerful Mecha-nism in Object-Oriented Programming. In Proc. Int’l. Conf. Object-OrientedProgramming, Systems, Languages, and Applications, 1989.

[44] H. Masuhara and K. Kawauchi. Dataflow Pointcut in Aspect-Oriented Pro-gramming. In Proc. Asian Symp. Programming Languages and Systems, 2003.

[45] H. Masuhara and G. Kiczales. Modeling Crosscutting in Aspect-Oriented Mech-anisms. In Proc. Europ. Conf. Object-Oriented Programming, 2003.

[46] S. McDirmid, M. Flatt, and W. C. Hsieh. Jiazzi: New-Age Components for Old-Fashioned Java. In Proc. Int’l. Conf. Object-Oriented Programming, Systems,Languages, and Applications, 2001.

[47] M. Mezini and K. Ostermann. Variability Management with Feature-OrientedProgramming and Aspects. In Proc. Int’l. Symp. Foundations of Software En-gineering, 2004.


8 CONCLUSION

[48] N. Nystrom, S. Chong, and A. C. Myers. Scalable Extensibility via NestedInheritance. In Proc. Int’l. Conf. Object-Oriented Programming, Systems, Lan-guages, and Applications, 2004.

[49] M. Odersky and M. Zenger. Scalable Component Abstractions. In Proc. Int’l.Conf. Object-Oriented Programming, Systems, Languages, and Applications,2005.

[50] K. Ostermann, M. Mezini, and C. Bockisch. Expressive Pointcuts for IncreasedModularity. In Proc. Europ. Conf. Object-Oriented Programming, 2005.

[51] D. J. Pearce and J. Noble. Relationship Aspects. In Proc. Int’l. Conf. Aspect-Oriented Software Development, 2006.

[52] T. Reenskaug, E. Andersen, A. Berre, A. Hurlen, A. Landmark, O. Lehne,E. Nordhagen, E. Ness-Ulseth, G. Oftedal, A. Skaar, and P. Stenslet. OORASS:Seamless Support for the Creation and Maintenance of Object-Oriented Sys-tems. J. Object-Oriented Programming, 5(6), 1992.

[53] Y. Smaragdakis and D. Batory. Mixin Layers: An Object-Oriented Imple-mentation Technique for Refinements and Collaboration-Based Designs. ACMTrans. Software Engineering and Methodology, 11(2), 2002.

[54] F. Steimann. The Paradoxical Success of Aspect-Oriented Programming. InProc. Int’l. Conf. Object-Oriented Programming, Systems, Languages, and Ap-plications, 2006.

[55] M. Storzer. Impact Analysis for AspectJ – A Critical Analysis and Tool-basedApproach to AOP. PhD thesis, School of Computer Science and Mathematics,University of Passau, 2007.

[56] P. Tarr, H. Ossher, W. Harrison, and S. M. Sutton, Jr. N Degrees of Separa-tion: Multi-Dimensional Separation of Concerns. In Proc. Int’l. Conf. SoftwareEngineering, 1999.

[57] A. Tesanovic, M. Amirijoo, M. Bjork, and J. Hansson. Empowering Config-urable QoS Management in Real-Time Systems. In Proc. Int’l. Conf. Aspect-Oriented Software Development, 2005.

[58] S. Trujillo, D. Batory, and O. Diaz. Feature Refactoring a Multi-RepresentationProgram into a Product Line. In Proc. Int’l. Conf. Generative and Component-Based Software Engineering, 2006.

[59] M. VanHilst and D. Notkin. Decoupling Change from Design. In Proc. Int’l.Symp. Foundations of Software Engineering, 1996.

[60] M. VanHilst and D. Notkin. Using Role Components in ImplementCollaboration-based Designs. In Proc. Int’l. Conf. Object-Oriented Program-ming, Systems, Languages, and Applications, 1996.



[61] M. Wand, G. Kiczales, and C. Dutchyn. A Semantics for Advice and DynamicJoin Points in Aspect-Oriented Programming. ACM Trans. Programming Lan-guages and Systems, 26(5), 2004.

[62] B. Xin, S. McDirmid, E. Eide, and W. C. Hsieh. A Comparison of Jiazziand AspectJ for Feature-Wise Decomposition. Technical Report UUCS-04-001,School of Computing, The University of Utah, 2004.

[63] C. Zhang and H.-A. Jacobsen. Resolving Feature Convolution in MiddlewareSystems. In Proc. Int’l. Conf. Object-Oriented Programming, Systems, Lan-guages, and Applications, 2004.

[64] J. Zhao and B. Xu. Measuring Aspect Cohesion. In Proc. Int’l. Conf. Funda-mental Approaches to Software Engineering, 2004.

ABOUT THE AUTHORS

Sven Apel is a post-doctoral associate at the Chair of Program-ming at the University of Passau, Germany. He received a Ph. D.in Computer Science from the University of Magdeburg, Germanyin 2007. His research interests include advanced programmingparadigms, software product lines, and algebra for software con-struction. He can be reached at [email protected]. See alsohttp://www.infosun.fim.uni-passau.de/cl/staff/apel/.


mailto:[email protected]

http://www.infosun.fim.uni-passau.de/cl/staff/apel/

vol. 9, no. 1, january–february 2010 how aspectj is used ... · vol. 9, no. 1, january–february...

Documents