1

A Parameterized Interpreter for Modeling Different AOP Mechanisms

Naoyasu Ubayashi (Kyushu Institute of Technology, Japan)Genki Moriyama (Kyushu Institute of Technology, Japan)Hidehiko Masuhara (University of Tokyo, Japan)Tetsuo Tamai (University of Tokyo, Japan)

November 10, 2005

ASE 200520th IEEE/ACM International Conference on Automated Software EngineeringLong Beach, California, USA, November 7-11, 2005

2

Outline

1. Motivation2. X-ASB: A parameterized interpreter3. Modeling different AOP mechanisms4. Discussion towards reflection for

AOP5. Related work6. Conclusion

3

1. Motivation

4

AOP

Aspect-oriented programming (AOP) is a programming paradigm in which crosscutting concerns are modularized as aspects.

LoggingError handlingSynchronizationPerformance optimization 　

5

What is the essence of AOP ?

Join pointsMeans of identifying the join pointsMeans of raising effects at the join points

Join Point Model !

pointcut(AspectJ

)

advice(AspectJ

)

A mechanism for modularizing crosscutting concerns

6

Example -- AspectJ-like JPM

class FigureElement { Display display; }

class Point extends FigureElement { int x, y; int getX() { return x; } int getY() { return y; } void setX(int x) { this.x = x; } void setY(int y) { this.y = y; }}

class Line extends FigureElement { Point p1, p2; int getP1() { return p1; } int getP2() { return p2; } void setP1(Point p1) { this.p1 = p1; } void setP2(Point p2) { this.p2 = p2; }}

Display updating

after (FigureElement fe): (call(void set*(..)) && target(fe) { fe.display.update(fe); }

advice

Pointcut

7

But, Current AOP languages …

Each of current AOP languages is based on a few fixed set of JPMs.

Many different JPMs have been proposed, and they are still evolving so that they better modularize various crosscutting concerns.

need to explore common mechanisms in major JPMs !!

8

Three-part modeling framework

A common structure in major four JPMs [Masuhara & Kiczales ECOOP2003].

PA - pointcuts and advice (as in AspectJ) TRAV - traversal specifications (as in Demeter,

Northeastern Univ.) COMPOSITOR - class merges (as in Hyper/J or CME, IBM) OC - open classes (as in AspectJ inter-type

declarations)

traverse an object tree (e.g. crosscutting concerns

over AST)

visitor[TRAV]class A class B

merge classesthat crosscut each other

[COMPOSITOR]class A

insert crosscut concerns(fields/methods) to classes

[OC]

new fieldsnew methods

9

Three-part modeling framework

A B

XJP

X

BID

Weave

AID

The framework models the process of weaving as a tuple of nine parameters.

AEFF

BEFF

XXJP

AAID

AEFF

BBID

BEFF

META

10

Problem to be tackledAlthough the three-part modeling

framework identified a common structure among different AOP mechanisms, the commonality is given in an informal manner.

There has been no single model that captures all the different AOP mechanisms.

11

Our approach & contribution

We present a single model that captures different AOP mechanisms, in the form of a parameterized interpreter that takes several parameters to cover different JPMs including PA, TRAV, COMPOSITOR, and OC.

The interpreter will be helpful in rapid-prototyping a new AOP mechanism or a reflective AOP system that supports different mechanisms.

12

2. X-ASB:A parameterized interpreter

13

X-ASB -- extensible ASB

Based on the three-part modeling framework.

Built on ASB (Aspect SandBox), a suite of interpreters written in Scheme. [C. Dutchyn et al.]

The interpreter consists of the core part and various sets of parameters.

X-ASB

param

param

core part

provideparameters

interpreter for PA TRAV COMPOSITOR OC

14

Architecture(define weave (lambda (pgm-a pgm-b) (register-jp) (eval-program pgm-a pgm-b)))

(define eval-program (lambda (pgm-a pgm-b) ( <iterate the following steps - get the next program element - generate a join point - call computation-at-jp> )))

(define computation-at-jp (lambda (jp) <mediate the following> (effect-a (lookup-a jp)) (effect-b (lookup-b jp))))

... other definitions

weave (= interpreter)

register-jp

eval-program

computation-at-jpXJP

effect-a

lookup-a lookup-b

effect-b

base (core part)parser

common library

15

Parameters

X

XJP

AAID

AEFF

BBID

BEFF

META

Three-part model X-ASB parameters

eval-programcomputation-at-jp

register-jp

lookup-a effect-a

lookup-b effect-b(included in register-jp)

Coordination using a join point type

Registration of a join point type

16

3. Modeling different AOP mechanisms

17

Interpreter construction steps

Step1: Design a join point type using the register-jp parameter.

Step2: Coordinate the computation at a join point using the computation-at-jp parameter.

Step3: Design a weaving process using the eval-program parameter in which the computation-at-jp is called.

18

Step1: Design a join point type

Example: PA

(define-struct (call-jp jp) mname target args)(define-struct jtype (jname generator))

(define register-jp (lambda () (register-one-jp 'call-jp (lambda (mname target args) (make-call-jp 'b-control-a lookup-method execute-method lookup-advice execute-advice mname target args)))))

join pointname

join pointgenerator

lookup-aeffect-alookup-beffect-b

META(computation-strategy)

19

Step2: Coordinate the computation at a join point

Example: PA

(define computation-at-jp (lambda (jp) (let* ((lookup-a (jp-lookup-a jp)) (effect-a (jp-effect-a jp)) (lookup-b (jp-lookup-b jp)) (effect-b (jp-effect-b jp))) (effect-b (lookup-b jp) jp (lambda () (effect-a (lookup-a jp) jp))))))

lookup-methodexecute-methodlookup-adviceexecute-advice

computation-at-jpXJP

effect-a

lookup-a lookup-b

effect-b

extract from a join point type

coordinate the computation

20

Step3: Design a weaving process

Example: PA

call computation-at-jpXJP

effect-a

lookup-a lookup-b

effect-b

call computation-at-jpXJP

effect-a

lookup-a lookup-b

effect-b

weaving process

(define eval-program ( <evaluate exps by calling eval-exp> )

(define eval-exp (lambda (exp env) (cond ((method-call-exp? exp) (call-method …) <other expressions> )))

(define call-method (lambda (mname obj args) (computation-at-jp (jtype-generator (lookup-jp 'call-jp)) mname obj args)))

base(parser)

overrideparser

21

Design of the four JPMsPA TRAV

COMPOSITOR OC

22

What is the essence of modeling AOP mechanisms ?

It is important for JPM developers to make the following design decisions:

What kinds of join points are needed?

What kinds of coordination should be defined at the join points?

23

LOC for developing each JPM

We have only to add 10 - 30 % new code to develop a new JPM.

However, it is not necessarily easy to design the eval-program parameter.

Part PA TRAV COM. OC1. register-jp 81 36 16 322. computation-at-jp 9 16 5 113. eval-program 64 131 238 284. base 537 537 537 537A: sum of 1 – 3 154 183 259 71B: sum of 1 – 4 691 720 796 608A / B (%) 22.3 25.4 32.5 11.7

24

LOC for extending PA

We have only to add about 20 % new code to add a new kind of join point.

It is easy to extend an existing JPM.

Part original PA add fset-jp add fget-jp1. register-jp 81 44 382. computation-at-jp 9 (reused) (reused)3. eval-program 64 4 4sum of 1 – 3 A:154 B:48 B:42B / (A+B) (%) 23.8 20.8

field-setjoin point

field-getjoin point

25

4. Discussion Towards reflection for AOP

26

Software evolution in AOP

AOP is effective in unanticipated software evolution because crosscutting concerns can be added or removed without making invasive modifications to original programs.

coreconcerns

added

removed

coreconcerns

coreconcerns

concernspace

evolution

crosscuttingconcerns

27

But, …

Software evolution would be restricted if new crosscutting concerns cannot be described with the existing JPMs.

coreconcerns

new type of crosscutting concernscannot be added

coreconcerns

coreconcerns

concernspace

evolution

crosscuttingconcerns

28

Evolution of JPMs

Evolution by language developers

Evolution by application developers

The effectiveness in software evolution would be restricted if language developers must extend JPMs whenever application programmers need new kinds of JPMs.

Reflection for AOP

It would be better for application programmers to be ableto add new JPMs using MOPs within the base language.

Base level(program based on

JPM)

Meta level(implement

ation of JPM)

reify

reflect

MOPs for JPM extensions

29

From our experience

It is relatively easy to design the register-jp parameter and the computation-at-jp parameter.

It is not easy to design the eval-program parameter

Reflection for AOP should be limited to adding new kinds of join point types and computation strategies.

30

Metaobject protocols for AOP

JPM design layerLayer Purpose Parameterslevel 1 introduction eval-program

of new JPMs computation-at-jp

register-jplevel 2 extensioncomputation-at-jp

of existing JPMs register-jp

reflectionfor AOP

MOPregister-one-strategylookup-strategyregister-one-jplookup-jpextract-jpregister-one-pcdlookup-pcdextract-ptc

extendcomputation-

at-jp

extendregister-jp

31

5. Related Work

32

Related Work

Versatile AOP kernel [E.Tanter et al., 2005]

XAspect [M.Shonle et al., 2003]

CME [IBM]

Josh [S.Chiba and K.Nakagawa, 2004]

abc: AspectBench Compiler [P.Avgustinov et al., 2005]

33

6. Conclusion

34

Conclusion

We proposed the parameterized interpreter X-ASB for modeling different JPMs.

X-ASB will be helpful in rapid-prototyping a new AOP mechanism or a reflective AOP system that supports multiple JPMs.

X-ASB guides language developers in modular JPM designs.