a parameterized interpreter for modeling different aop mechanisms
Download
Skip this Video
Download Presentation
A Parameterized Interpreter for Modeling Different AOP Mechanisms

Loading in 2 Seconds...

play fullscreen
1 / 34

A Parameterized Interpreter for Modeling Different AOP Mechanisms - PowerPoint PPT Presentation


  • 56 Views
  • Uploaded on

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)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' A Parameterized Interpreter for Modeling Different AOP Mechanisms' - inga-kirby


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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

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

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

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

  • Logging
  • Error handling
  • Synchronization
  • Performance optimization
what is the essence of aop
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)

example aspectj like jpm
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

but current aop languages
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 !!

three part modeling framework
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)

three part modeling framework1
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

problem to be tackled
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.
our approach contribution
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.
x asb extensible asb
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

architecture
effect-b

effect-a

lookup-b

lookup-a

computation-at-jp

XJP

(define weave

(lambda (pgm-a pgm-b)

(register-jp)

(eval-program pgm-a pgm-b)))

(define eval-program

(lambda (pgm-a pgm-b)

(

- get the next program element

- generate a join point

- call computation-at-jp> )))

(define computation-at-jp

(lambda (jp)

(effect-a (lookup-a jp))

(effect-b (lookup-b jp))))

... other definitions

Architecture

weave (= interpreter)

register-jp

eval-program

base (core part)

parser

common library

parameters
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

interpreter construction steps
Interpreter construction steps
  • Step1: Design a join point type using the register-jpparameter.
  • 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.
step1 design a join point type
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-methodexecute-method

lookup-adviceexecute-advice

mname target args)))))

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

join point

name

META

(computation-strategy)

join point

generator

step2 coordinate the computation at a join point
effect-b

effect-a

lookup-b

lookup-a

computation-at-jp

XJP

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

step3 design a weaving process
Step3: Design a weaving process

weaving process

Example: PA

(define eval-program

( )

(define eval-exp

(lambda (exp env)

(cond

((method-call-exp? exp) (call-method …)

)))

(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

design of the four jpms
Design of the four JPMs

PA

TRAV

OC

COMPOSITOR

what is the essence of modeling aop mechanisms
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?
loc for developing each jpm
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.
loc for extending pa
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 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.
software evolution in aop
Software evolution in AOP

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

crosscutting

concerns

added

concern

space

removed

core

concerns

core

concerns

core

concerns

evolution

slide27
But, …

Software evolution would be restricted if newcrosscutting 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

evolution of jpms
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.

from our experience
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.

metaobject protocols for aop
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

related work
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]
conclusion
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.
ad