Introduction to Aspect-Oriented Programming and its Reasoning Problems

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

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

3. Outline • Background: • Crosscutting concerns • Scattering, tangling • Language mechanisms (AspectJ) • Solution Approaches • MAO: concern domains • Ptolemy: limit language mechanisms • Conclusions

4. Background: Crosscutting Concerns Some concerns cut across modules: • Reliability (logging, tracing) • Security (authentication, authorization) • Correctness (invariant maintenance) • Performance (buffering, pooling, caching) • Functionality (billing, taxes)

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

6. Background: Goals ofAspect-Oriented Software Development … • Goal:modularize crosscutting concerns • Avoid: • Scattering: repeating code in many modules • Tangling: mixing concern code with business logic

7. 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(…); … }

8. 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” …

9. 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)

10. 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)

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

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

13. Summary of Problems for AOP • Real modularity problems • Scattering • Tangling • Standard OO techniques don’t completely work

14. Language Mechanisms: AspectJ • Extends Java • Features: • Law enforcement (declare error/warning) • Intertype declarations (adding fields/methods) • Advice on dynamic execution events

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

16. 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; } }

17. 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++; } }

18. 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; }

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

20. 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; } } }

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

22. Call Verification: Control Effects public void testAdd(Tally t) { //@ assert t.val == 0; t.add(-10); //@ assert t.val == -10; }

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

24. Reasoning Problem Summary • How to reason efficiently with aspects? • How much of program? • What changes can be ignored? • Which changes need how much effort?

25. Approach 0: Functional Advice • Advice with no heap or control effects Benefits: • Base code reasoning unaffected Costs: • Useless

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

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

28. Approach 2: Behavioral Subtyping OO Analogy: • Around advice  overriding method • Proceed  super call Behavioral Subtyping: • Advice obeys specification of all it advises

29. 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)

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

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

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

33. Approach 4 (Idea): Weave Specifications • Specify: • Object state and methods • Aspect state and advice • Heap effects • Control effects • Weave specifications

34. 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?

35. More Detail on 2 approaches • Concern Domains: AspectJ with annotations • Ptolemy: Implicit Invocation with more power, not oblivious

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

37. Concern Domains Partition the Heap Domain of Main DomainofanotherAspect Domain of anAspect

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

39. 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); }

40. Ptolemy’s Event Types • Declared Event Types • Allow type checking of events • Point of indirection, decouples event signalers and handlers evtypevoid FigChanged { Figure changed; }

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

42. 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?

43. Ptolemy: Future work on Reasoning • Attach specifications to event types • Show modularity of reasoning • Event expressions rely on specification • Event handlers guarantee specification

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

45. 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/