A Parameterized Interpreter for Modeling Different AOP Mechanisms

1
A Parameterized Interpreter for Modeling
Different AOP Mechanisms
ASE 200520th IEEE/ACM International Conference
on Automated Software Engineering Long Beach,
California, USA, November 7-11, 2005

• 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

2
Outline

• Motivation
• X-ASB A parameterized interpreter
• Modeling different AOP mechanisms
• Discussion towards reflection for AOP
• Related work
• Conclusion

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

• Logging
• Error handling
• Synchronization
• Performance optimization

5
What is the essence of AOP ?
Join Point Model !
A mechanism for modularizing crosscutting concerns

• Join points
• Means of identifying the join points
• Means of raising effects at the join points

pointcut (AspectJ)
advice (AspectJ)
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
Pointcut
after (FigureElement fe) (call(void set(..))
target(fe) fe.display.update(fe)
advice
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)

visitor
TRAV
COMPOSITOR
OC
class A
class B
class A
new fields new methods
merge classes that crosscut each other
insert crosscut concerns (fields/methods) to
classes
traverse an object tree (e.g. crosscutting
concerns over AST)
9
Three-part modeling framework
The framework models the process of weaving as a
tuple of nine parameters.
A
B
X XJP A AID AEFF B BID BEFF META
BEFF
AEFF
BID
AID
Weave
XJP
X
10
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.

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

interpreter for PA TRAV COMPOSITOR OC
param
provide parameters
param
core part
X-ASB
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) ( ltiterate the following steps
- get the next program element - generate
a join point - call computation-at-jpgt
))) (define computation-at-jp (lambda (jp)
ltmediate the followinggt (effect-a (lookup-a
jp)) (effect-b (lookup-b jp)))) ... other
definitions
weave ( interpreter)
register-jp
eval-program
base (core part) parser common library
15
Parameters
Coordination using a join point type
Three-part model
X-ASB parameters
eval-program computation-at-jp
X XJP A AID AEFF B BID BEFF META
register-jp lookup-a effect-a
lookup-b effect-b (included in register-jp)
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)))))

• lookup-a
• effect-a
• lookup-b
• effect-b

join point name
join point generator
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))))))
extract from a join point type

• lookup-method
• execute-method
• lookup-advice
• execute-advice

coordinate the computation
20
Step3 Design a weaving process
weaving process
Example PA
(define eval-program ( ltevaluate exps by
calling eval-expgt ) (define eval-exp (lambda
(exp env) (cond ((method-call-exp? exp)
(call-method ) ltother expressionsgt
))) (define call-method (lambda (mname obj
args) (computation-at-jp
(jtype-generator (lookup-jp 'call-jp))
mname obj args)))
effect-b
effect-a
lookup-b
lookup-a
base (parser)
call computation-at-jp
XJP
effect-b
effect-a
override parser
lookup-b
lookup-a
call computation-at-jp
XJP
21
Design of the four JPMs
PA
TRAV
OC
COMPOSITOR
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
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.

24
LOC for extending PA
field-set join point
field-get 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 A154 B48
B42 B / (AB) () 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.

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.

crosscutting concerns
added
concern space
removed
core concerns
core concerns
core concerns
evolution
27
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 concerns
core concerns
core concerns
evolution
28
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 (implementation of JPM)
reify
Reflection for AOP
MOPs for JPM extensions
Base level (program based on JPM)
reflect
Evolution by application developers
It would be better for application programmers to
be able to add new JPMs using MOPs within the
base language.
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 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 lookup-strategy
MOP
reflection for AOP
register-one-jp lookup-jp extract-jp register-one-
pcd lookup-pcd extract-ptc
extend register-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.