ASE 2005
20th IEEE/ACM International Conference on Automated Software Engineering
Long Beach, California, USA, November 7-11, 2005
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
1
Outline
1. Motivation
2. X-ASB: A parameterized interpreter
3. Modeling different AOP mechanisms
4. Discussion towards reflection for AOP
5. Related work
6. Conclusion
2
1. Motivation
3
AOP
Aspect-oriented programming (AOP) is a
programming paradigm in which crosscutting
concerns are modularized as aspects.
Logging
Error handling
Synchronization
Performance optimization
4
What is the essence of AOP ?
Join Point Model !
A mechanism for modularizing crosscutting concerns
pointcut
Join points (AspectJ)
Means of identifying the join points
Means of raising effects at the join points
advice
(AspectJ)
5
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 { Display updating
Point p1, p2;
int getP1() { return p1; } Pointcut
int getP2() { return p2; } after (FigureElement fe):
void setP1(Point p1) { this.p1 = p1; } (call(void set*(..)) && target(fe) {
void setP2(Point p2) { this.p2 = p2; } fe.display.update(fe); }
}
advice 6
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 !!
7
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)
[TRAV] visitor [COMPOSITOR] [OC]
class A class B class A
new fields
new methods
traverse an object tree merge classes insert crosscut concerns
(e.g. crosscutting concerns over AST) that crosscut each other (fields/methods) to classes
8
Three-part modeling framework
The framework models the process of
weaving as a tuple of nine parameters.
X A B
XJP BEFF
A
AID AEFF
AEFF
B AID BID
BID
Weave
BEFF XJP
META X 9
Problem to be tackled
Although 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.
10
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.
11
2. X-ASB:
A parameterized
interpreter
12
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.
interpreter for
provide param PA
parameters param TRAV
core part COMPOSITOR
OC
X-ASB
13
Architecture
(define weave
(lambda (pgm-a pgm-b)
(register-jp)
weave (= interpreter) (eval-program pgm-a pgm-b)))
register-jp (define eval-program
(lambda (pgm-a pgm-b)
eval-program ( )))
lookup-a lookup-b
(define computation-at-jp
computation-at-jp (lambda (jp)
XJP
(effect-a (lookup-a jp))
base (core part) (effect-b (lookup-b jp))))
parser
common library ... other definitions
14
Parameters
Three-part model X-ASB parameters Coordination
using a join
X eval-program point type
computation-at-jp
XJP register-jp
A Registration of
AID lookup-a a join point
AEFF effect-a type
B
BID lookup-b
BEFF effect-b
META (included in register-jp)
15
3. Modeling different
AOP mechanisms
16
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.
17
Step1: Design a join point type
Example: PA
(define-struct (call-jp jp) mname target args)
(define-struct jtype (jname generator))
lookup-a
(define register-jp
effect-a
(lambda ()
(register-one-jp lookup-b
join point effect-b
'call-jp
name (lambda (mname target args)
(make-call-jp
META 'b-control-a join point
(computation-strategy) lookup-method execute-method generator
lookup-advice execute-advice
mname target args)))))
18
Step2: Coordinate the
computation at a join point
Example: PA effect-b
effect-a
lookup-a lookup-b
computation-at-jp
(define computation-at-jp XJP
(lambda (jp)
(let* ((lookup-a (jp-lookup-a jp)) extract from a join point type
(effect-a (jp-effect-a jp))
lookup-method
(lookup-b (jp-lookup-b jp))
execute-method
(effect-b (jp-effect-b jp)))
lookup-advice
(effect-b (lookup-b jp) jp
execute-advice
(lambda ()
(effect-a (lookup-a jp) jp)))))) coordinate the computation
19
Step3: Design a weaving
process
weaving process
Example: PA
(define eval-program effect-b
( ) effect-a
lookup-a lookup-b
(define eval-exp base
(lambda (exp env) (parser) XJP
call computation-at-jp
(cond
((method-call-exp? exp) (call-method …)
))) effect-b
effect-a
(define call-method override lookup-a lookup-b
(lambda (mname obj args) parser
(computation-at-jp XJP
call computation-at-jp
(jtype-generator (lookup-jp 'call-jp))
mname obj args))) 20
Design of the four JPMs
PA TRAV
COMPOSITOR OC
21
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?
22
LOC for developing each JPM
Part PA TRAV COM. OC
1. register-jp 81 36 16 32
2. computation-at-jp 9 16 5 11
3. eval-program 64 131 238 28
4. base 537 537 537 537
A: sum of 1 – 3 154 183 259 71
B: sum of 1 – 4 691 720 796 608
A / B (%) 22.3 25.4 32.5 11.7
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.
23
LOC for extending PA
field-set field-get
join point join point
Part original PA add fset-jp add fget-jp
1. register-jp 81 44 38
2. computation-at-jp 9 (reused) (reused)
3. eval-program 64 4 4
sum of 1 – 3 A:154 B:48 B:42
B / (A+B) (%) 23.8 20.8
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.
24
4. Discussion Towards
reflection for AOP
25
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.
crosscutting
concerns added
concern removed
space
core core core
concerns concerns concerns
evolution 26
But, …
Software evolution would be restricted if new
crosscutting concerns cannot be described with
the existing JPMs.
new type of crosscutting concerns
cannot be added
crosscutting
concerns
concern
space
core core core
concerns concerns concerns
evolution 27
Evolution of JPMs
Evolution by language developers
The effectiveness in software evolution would be restricted if
language developers must extend JPMs whenever application
programmers need new kinds of JPMs.
Meta level
reify (implementatio
Reflection for AOP MOPs for JPM n of JPM)
extensions Base level
(program based reflect
on JPM)
Evolution by application developers
It would be better for application programmers to be able
to add new JPMs using MOPs within the base language.
28
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.
29
Metaobject protocols for AOP
JPM design layer
Layer Purpose Parameters
level 1 introduction eval-program
of new JPMs computation-at-jp
register-jp
level 2 extension computation-at-jp
of existing JPMs register-jp
extend
computation-at-jp
register-one-strategy
reflection MOP lookup-strategy
for AOP register-one-jp
lookup-jp
extract-jp
register-one-pcd extend
lookup-pcd register-jp
extract-ptc
30
5. Related Work
31
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]
32
6. Conclusion
33
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.
34