introduction to aspect oriented programming and its reasoning problems n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Introduction to Aspect-Oriented Programming and its Reasoning Problems PowerPoint Presentation
Download Presentation
Introduction to Aspect-Oriented Programming and its Reasoning Problems

Loading in 2 Seconds...

play fullscreen
1 / 45

Introduction to Aspect-Oriented Programming and its Reasoning Problems - PowerPoint PPT Presentation


  • 180 Views
  • Uploaded on

Introduction to Aspect-Oriented Programming and its Reasoning Problems. Gary T. Leavens University of Central Florida (Orlando, Florida) School of Electrical Engineering and Computer Science Based on work with Curtis C. Clifton, James Noble, Hridesh Rajan July 21, 2008.

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 'Introduction to Aspect-Oriented Programming and its Reasoning Problems' - bernad


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
introduction to aspect oriented programming and its reasoning problems

Introduction to Aspect-Oriented Programmingand its Reasoning Problems

Gary T. Leavens

University of Central Florida (Orlando, Florida)

School of Electrical Engineering and Computer Science

Based on work with Curtis C. Clifton, James Noble, Hridesh Rajan

July 21, 2008

summary of aspect orientation
Summary of Aspect-Orientation
  • Crosscutting concerns causemodularity problems: scattering, tangling
  • Main mechanisms:
    • Extract each concern from business logic
    • Declare: how to weave them together
  • Global weaving makes modular reasoning hard
outline
Outline
  • Background:
    • Crosscutting concerns
    • Scattering, tangling
  • Language mechanisms (AspectJ)
  • Solution Approaches
    • MAO: concern domains
    • Ptolemy: limit language mechanisms
  • Conclusions
background crosscutting concerns
Background: Crosscutting Concerns

Some concerns cut across modules:

  • Reliability (logging, tracing)
  • Security (authentication, authorization)
  • Correctness (invariant maintenance)
  • Performance (buffering, pooling, caching)
  • Functionality (billing, taxes)
examples of crosscutting concerns
Examples of Crosscutting Concerns
  • Audit Trail:when messages sent/receivedrecord message summary and time
  • Pooling:when call DriverManager.getConnection()get connection from pool of connections.
  • Buffering:when call FileOutputSteam.write(),buffer the output
background goals of aspect oriented software development
Background: Goals ofAspect-Oriented Software Development

  • Goal:modularize crosscutting concerns
  • Avoid:
    • Scattering: repeating code in many modules
    • Tangling: mixing concern code with business logic
why avoid scattering and tangling
Why Avoid Scattering and Tangling?

Scattering:

  • Hard to find/change/audit/verify policies

Tangling:

  • Hard to read code

if (tpm.validUser()) {logger.put(…);o.send(…); … }

background claimed aspect oriented advantages
Background:Claimed Aspect-Oriented Advantages

  • Quantification (lack of scattering)
    • Code for each concern in one place
    • Eases maintenance
    • Ease of auditing/verification
  • Obliviousness (lack of tangling)
    • Code for each concern modularized, independent
    • Easier to read code for “business logic”

background uses of aspect oriented software
Background:Uses of Aspect-Oriented Software
  • Modularizing large programs (telecom)
  • Adding new behavior (e.g., authentication)
  • Software product lines
  • Performance improvements(special cases run faster)
background kinds of concerns
Background: Kinds of Concerns

Spectators – no control or heap effects:

  • Reliability (logging, tracing)

Curbing – only control effects:

  • Security (authentication, authorization)

Assistants – control and heap effects:

  • Correctness (invariant maintenance)
  • Performance (buffering, pooling, caching)
  • Functionality (billing, taxes)
background for spectators use observer pattern
Background: for SpectatorsUse Observer Pattern?

Each subject type adds:

  • Code for managing set of listeners/observers
  • Method, “notify” that callseach listener’s “actionPerformed” method
  • Calls to notify for each event

Problems:

  • Scattering and Tangling of:
    • Calls to notify
    • Calls to register listeners
  • Cost of notify calls, even if no listeners
background for assistants use proxy pattern
Background: for AssistantsUse Proxy Pattern?

Instead of direct reference to objectsuse a proxy that:

  • Contains the original object
  • Delegates to it for basic functions
  • Assists by intercepting calls to do caching, pooling, etc.

Problems:

  • Scattering of:
    • Code to do assistance (caching, pooling, etc.)among proxies for different types
  • Cost of indirection, even if no interception
summary of problems for aop
Summary of Problems for AOP
  • Real modularity problems
    • Scattering
    • Tangling
  • Standard OO techniques don’t completely work
language mechanisms aspectj
Language Mechanisms: AspectJ
  • Extends Java
  • Features:
    • Law enforcement (declare error/warning)
    • Intertype declarations (adding fields/methods)
    • Advice on dynamic execution events
aspectj advice weaving
AspectJ: Advice Weaving
  • Join point = dynamic event where can weave
    • Call of method / constructor
    • Execution of method / constructor body
    • Get / set of field
    • Execution of an exception handler
    • Etc.
  • Before advice – before join point
  • After advice – after join point
  • Around advice – replaces join point
tally class
Tally Class

public class Tally{

protected /*@ spec_public @*/ int val= 0;

/*@ requires true;

@ assignable this.val;

@ ensures this.val == \old(this.val+inc);

@*/

public void add(int inc) { this.val+=inc; }

}

example before advice with heap effects
Example: Before Advice with Heap Effects

public aspect C{

private/*@ spec_public @*/ int val = 0;

public pointcut tallyAddCalls() : call(* Tally+.add(..));

before() :tallyAddCalls() { this.val++; }

}

reasoning problem frame axiom invalid
Reasoning Problem: Frame Axiom Invalid?

public void testAddFrame(Tally t, C c) {

//@ assert t != c;

//@ assert t.val == 0 && c.val == 7;

t.add(-10);

//@ assert t.val == -10 && c.val == 7;

}

reasoning problem analysis
Reasoning Problem Analysis

With before / after advice:

  • Calls do more
    • Before advice
    • Call
    • After advice
  • Method specification not adequate for client
  • Modular verification not designed for it
example buffering calls
Example: Buffering Calls

public aspect BufferTally {

private int tallies = 0;

void around(int i) : call(* Tally+.add(..)) && args(i) {

this.tallies += i;

if (i == 0 || Math.abs(this.tallies) > 100) {

proceed(this.tallies);

this.tallies = 0;

} } }

oo analogy
OO Analogy
  • Around advice  overriding method
  • Proceed  super call
  • Differences:
    • Quantification:
      • Advice may replace many different join points
    • Not found in subclass
    • Different typical usage
call verification control effects
Call Verification: Control Effects

public void testAdd(Tally t) {

//@ assert t.val == 0;

t.add(-10);

//@ assert t.val == -10;

}

reasoning problem analysis1
Reasoning Problem Analysis

With advice:

  • Control effects:
    • Replacing call
    • Running it multiple times
    • Not returning (exception, abort)
  • Method specification not adequate for client
  • Modular verification not designed for it
reasoning problem summary
Reasoning Problem Summary
  • How to reason efficiently with aspects?
    • How much of program?
    • What changes can be ignored?
    • Which changes need how much effort?
approach 0 functional advice
Approach 0: Functional Advice
  • Advice with no heap or control effects

Benefits:

  • Base code reasoning unaffected

Costs:

  • Useless
approach 1 harmless advice dantas and walker popl 2006
Approach 1: “Harmless” AdviceDantas and Walker (POPL 2006)
  • No information flow from advice to base
  • Conservative static analysis
  • Base code assertionscan’t mention advice state
approach 1 harmless advice dantas and walker popl 20061
Approach 1: “Harmless” AdviceDantas and Walker (POPL 2006)

Benefits:

  • No annotations needed
  • No heap effects on base

Costs:

  • No help with control effects
  • Loss of expressiveness
    • Some aspects (assertions) can’t be written
  • No help with interference among advice
approach 2 behavioral subtyping
Approach 2: Behavioral Subtyping

OO Analogy:

  • Around advice  overriding method
  • Proceed  super call

Behavioral Subtyping:

  • Advice obeys specification of all it advises
approach 2 behavioral subtyping1
Approach 2: Behavioral Subtyping

Benefits:

  • Verification of base codeindependent of advice

Costs:

  • Quantification limits in practice
  • Re-verify advice when advise more
  • Much advice outside this paradigm(e.g., Buffering)
approach 2a rely guarantee khatchadourian et al foal 08
Approach 2a: Rely/Guarantee Khatchadourian, et al. (FOAL ‘08)
  • Base code specifies rely condition on advice
    • 2 states: before and after advice runs
  • Advice specifies what it guarantees
  • Limit advice application
  • Use globally computed pointcut interfaceto know where advice applies
approach 3 limits on advice
Approach 3: Limits on Advice
  • Gudmundson and Kiczales (2001)
  • Griswold et al.’s XPIs (2005-6)
  • Aldrich’s Open Modules (2005)

Idea:

  • Advice only on exported/declared joinpoints
approach 3 limits on advice1
Approach 3: Limits on Advice

Benefits:

  • Some code can’t be advised
  • Enables negotiation
  • No limits on expressive power

Costs:

  • Extra annotation / code
  • No help where advice can be applied
  • No help finding interference among advice
approach 4 idea weave specifications
Approach 4 (Idea): Weave Specifications
  • Specify:
    • Object state and methods
    • Aspect state and advice
      • Heap effects
      • Control effects
  • Weave specifications
approach 4 weave specifications
Approach 4: Weave Specifications

Potential Benefits:

  • More abstract than code
  • Allows changes in method and advice code

Potential Costs:

  • Lack of expressiveness?
  • Weaving specifications is hard / expensive
  • How to modularly find what advice may apply?
more detail on 2 approaches
More Detail on 2 approaches
  • Concern Domains: AspectJ with annotations
  • Ptolemy: Implicit Invocation with more power, not oblivious
concern domains clifton 05 clifton leavens noble 07
Concern Domains (Clifton 05) (Clifton, Leavens, Noble 07)
  • Declare concern domains (heap partitions)
  • Declare write effects (and control effects)
  • Uses readonly types
  • Type/effect analysis detects potential interference
  • Sound for checking possible interference
concern domains partition the heap
Concern Domains Partition the Heap

Domain of Main

DomainofanotherAspect

Domain of anAspect

mao future work
MAO: Future Work
  • Implement and do case studies
  • Integrate MAO’s concern domainsand JML’s data groups (Leino 98)
    • Problem: data groups can overlap
    • Benefit: less syntax, plug into other tools
ptolemy implicit invocation meets aop rajan leavens ecoop 2008
Ptolemy: Implicit Invocation meets AOPRajan & Leavens (ECOOP 2008)
  • Implicit invocation language
    • Explicit events (joinpoints)
    • No implicit joinpoints – not oblivious
    • Can tell when advice applies, when it doesn’t

Figure changed =circle;

event FigChanged { circle.smallerBy(2); }

ptolemy s event types
Ptolemy’s Event Types
  • Declared Event Types
    • Allow type checking of events
    • Point of indirection, decouples event signalers and handlers

evtypevoid FigChanged { Figure changed;

}

ptolemy s handlers
Ptolemy’s Handlers
  • Handlers are methods
  • “bind” declares association with event types
  • Run-time registration gives receiver
  • Handlers take a “proceed closure”as argument
  • “proceed” can run such closures
ptolemy comparison to ao langauges
Ptolemy: Comparison to AO Langauges
  • Not oblivious
  • Can tell where events cannot happen
  • Has rest of power of AO advice
    • Quantification
    • Replacement of events with other code

Future work:

  • How does this affect maintenance?
ptolemy future work on reasoning
Ptolemy: Future work on Reasoning
  • Attach specifications to event types
  • Show modularity of reasoning
    • Event expressions rely on specification
    • Event handlers guarantee specification
summary reasoning problems
Summary:Reasoning Problems

Goals:

  • Reasoning efficiency
  • Practicality

Approaches could be combined?

    • Applicability (AJDT)
    • Declared joinpoints (Ptolemy, XPIs, OMs)
    • Heap partitions / effects (MAO)
    • Specification of advice, weaving specifications
    • Other static analyses + annotations
summary of aspect orientation1
Summary of Aspect-Orientation
  • Crosscutting concerns causemodularity problems: scattering, tangling
  • Main mechanisms:
    • Extract each concern from business logic
    • Declare: how to weave them together
  • Global weaving makes modular reasoning hard
  • MAO, Ptolemy are possible approaches

See http://www.eecs.ucf.edu/~leavens/modular-aop/