Rely-Guarantee Approach toReasoning about Aspect-Oriented           Programs  Raffi Khatchadourian and Neelam Soundarajan ...
Introduction• AOP enables modular implementation of cross-  cutting concerns. • Removes scattering. • Prevents tangling.• ...
The Problem
The Problem• Addition of an aspect can change the behavior of  the base code.
The Problem                                  Desirable!• Addition of an aspect can change the behavior of  the base code.
The Problem                                  Desirable!• Addition of an aspect can change the behavior of  the base code.•...
The Problem                                   Desirable!• Addition of an aspect can change the behavior of  the base code....
The Problem                                   Desirable!• Addition of an aspect can change the behavior of  the base code....
Motivation• [Sullivan FSE’05]: 1. Separate base and crosscutting concerns. 2. Implement base concerns in an OO style ignor...
Insight
Insight• Aspect-oriented weaving and concurrent execution  present similar challenges for program analysis.
Insight• Aspect-oriented weaving and concurrent execution  present similar challenges for program analysis. • AOP case muc...
Insight• Aspect-oriented weaving and concurrent execution  present similar challenges for program analysis. • AOP case muc...
Insight• Aspect-oriented weaving and concurrent execution  present similar challenges for program analysis. • AOP case muc...
Insight• Aspect-oriented weaving and concurrent execution  present similar challenges for program analysis. • AOP case muc...
Insight• Aspect-oriented weaving and concurrent execution  present similar challenges for program analysis. • AOP case muc...
Notation                the set of all variables of     σ          the program                states in which eachσi , σj ...
!1!2!3
!1      Aspect!2!3
The Rely() Clause
The Rely() Clause• Identify a relation rely() that is a predicate over two  states, σa and σb.
The Rely() Clause• Identify a relation rely() that is a predicate over two  states, σa and σb.• rely() will not correspond...
The Rely() Clause• Identify a relation rely() that is a predicate over two  states, σa and σb.• rely() will not correspond...
!a     Aspect!b
The state at a point in the execution           of a class is σa.      !a                        Aspect      !b
The state at a point in the execution           of a class is σa.      !a                        Aspect      !bThe state w...
The state at a point in the execution           of a class is σa.      !a                        Aspect  rely(σa, σb)     ...
Rely-Guarantee Approach for AOP
Rely-Guarantee Approach for AOPA method M under the influence of advice satisfies        an R/G specification denoted by
Rely-Guarantee Approach for AOPA method M under the influence of advice satisfies        an R/G specification denoted by  ...
Rely-Guarantee Approach for AOPA method M under the influence of advice satisfies        an R/G specification denoted by  ...
Rely-Guarantee Approach for AOP  A method M under the influence of advice satisfies           an R/G specification denoted...
Rely-Guarantee Approach for AOP  A method M under the influence of advice satisfies            an R/G specification denote...
Rely-Guarantee Approach for AOP  A method M under the influence of advice satisfies            an R/G specification denote...
Rely-Guarantee Approach for AOP  A method M under the influence of advice satisfies            an R/G specification denote...
Rely-Guarantee Approach for AOP  A method M under the influence of advice satisfies            an R/G specification denote...
Rely-Guarantee Approach for AOP  A method M under the influence of advice satisfies            an R/G specification denote...
Rely-Guarantee Approach for AOP  A method M under the influence of advice satisfies            an R/G specification denote...
Rely() Examplerely(σ, σ ) ≡ (σ = σ )
Rely() Example         The entire state              of Crely(σ, σ ) ≡ (σ = σ )
Rely() Examplerely(σ, σ ) ≡ (σ = σ )                        ble ny                     ica g a                   pl in !  ...
Rely() Example      This is “Harmless”[D&W     POPL’06]rely(σ, σ ) ≡ (σ = σ )
1   class Point { 2     int x, y;                                      co 3     int s;                                    ...
1   class Point {  2     int x, y;                                      co  3     int s;                                  ...
1   class Point { 2     int x, y;                                      co 3     int s;                                    ...
1   class Point { 2     int x, y;                                      co 3     int s;                                    ...
1   class Point { 2     int x, y;                                      co 3     int s;                                    ...
1   class Point { 2     int x, y;                                      co 3     int s;                                    ...
A rely() for class Pointrely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]
A rely() for class Pointrely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]
A rely() for class Pointrely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]            (σ.s = σ .s)
A rely() for class Point rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]• Not a fault of the reasoning approach!
A rely() for class Point rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]• Not a fault of the reasoning approach!• Must be sure...
A rely() for class Point rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]• Not a fault of the reasoning approach!• Must be sure...
A rely() for class Point rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]• Not a fault of the reasoning approach!• Must be sure...
The guar() Clause
The guar() Clause• Concurrent programs: the two processes act  symmetrically.
The guar() Clause• Concurrent programs: the two processes act  symmetrically.• AOP: base-code can’t intercept advice.
The guar() Clause• Concurrent programs: the two processes act  symmetrically.• AOP: base-code can’t intercept advice.• gua...
The guar() Clause• Concurrent programs: the two processes act  symmetrically.• AOP: base-code can’t intercept advice.• gua...
The guar() Clause• Concurrent programs: the two processes act  symmetrically.• AOP: base-code can’t intercept advice.• gua...
The guar() Clause• Concurrent programs: the two processes act  symmetrically.• AOP: base-code can’t intercept advice.• gua...
The guar() Clause• Concurrent programs: the two processes act  symmetrically.• AOP: base-code can’t intercept advice.• gua...
9                                                                 d             public void move(int nx, int ny)          ...
9                                                                 d             public void move(int nx, int ny)          ...
9                                                                 d             public void move(int nx, int ny)          ...
9                                                                   d             public void move(int nx, int ny)        ...
4 5       public Point(int xi, int History Variable                                      yi) 6                    { x=xi; ...
4     5       public Point(int xi, int History Variable                                          yi)     6                ...
Post-condition of Point.move()
Post-condition of Point.move()• Post-condition of move() will state: • Values of x and y are equal to the values for the  ...
Post-condition of Point.move()• Post-condition of move() will state: • Values of x and y are equal to the values for the  ...
1   class Point {                                                         But 2     int x, y;                             ...
1   class Point {                                                         But 2     int x, y;                             ...
Conclusion and Future Work
Conclusion and Future Work• AO programmers already think implicitly about  rely(), our proposed approach makes this explic...
Conclusion and Future Work• AO programmers already think implicitly about  rely(), our proposed approach makes this explic...
Conclusion and Future Work• AO programmers already think implicitly about  rely(), our proposed approach makes this explic...
Conclusion and Future Work• AO programmers already think implicitly about  rely(), our proposed approach makes this explic...
Conclusion and Future Work• AO programmers already think implicitly about  rely(), our proposed approach makes this explic...
Conclusion and Future Work• AO programmers already think implicitly about  rely(), our proposed approach makes this explic...
Conclusion and Future Work• AO programmers already think implicitly about  rely(), our proposed approach makes this explic...
Modular Reasoning about Aspect-Oriented Programs: A Rely-Guarantee Approach
Modular Reasoning about Aspect-Oriented Programs: A Rely-Guarantee Approach
Modular Reasoning about Aspect-Oriented Programs: A Rely-Guarantee Approach
Modular Reasoning about Aspect-Oriented Programs: A Rely-Guarantee Approach
Upcoming SlideShare
Loading in …5
×

Modular Reasoning about Aspect-Oriented Programs: A Rely-Guarantee Approach

553 views
506 views

Published on

A number of authors have raised serious questions about the problems aspect-oriented programming (AOP) poses for modular reasoning. In this paper, we develop a formalism for such reasoning. The rely-guarantee approach has proven very useful in reasoning about concurrent and distributed programs. We show that some of the main problems encountered in reasoning about aspect-oriented programs are similar to those encountered in reasoning about concurrent programs; and that the rely-guarantee approach, appropriately modified, helps address these problems. At the same time, there are some key differences as well. One important difference is that while the various processes of a concurrent program are typically designed simultaneously, aspects may be added as an afterthought to a program to enrich its behavior in appropriate ways. The use of traces in our formalism enables us to reason about such enriched behaviors. We illustrate our formalism by applying it to a standard example.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
553
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Modular Reasoning about Aspect-Oriented Programs: A Rely-Guarantee Approach

  1. 1. Rely-Guarantee Approach toReasoning about Aspect-Oriented Programs Raffi Khatchadourian and Neelam Soundarajan The Ohio State University
  2. 2. Introduction• AOP enables modular implementation of cross- cutting concerns. • Removes scattering. • Prevents tangling.• Reasoning about AOP presents some key challenges.
  3. 3. The Problem
  4. 4. The Problem• Addition of an aspect can change the behavior of the base code.
  5. 5. The Problem Desirable!• Addition of an aspect can change the behavior of the base code.
  6. 6. The Problem Desirable!• Addition of an aspect can change the behavior of the base code.• Prior reasoning about the base code may no longer be valid.
  7. 7. The Problem Desirable!• Addition of an aspect can change the behavior of the base code.• Prior reasoning about the base code may no longer be valid.• May be forced to reason about the entire system again accounting for the interleaving.
  8. 8. The Problem Desirable!• Addition of an aspect can change the behavior of the base code.• Prior reasoning about the base code may no longer be valid.• May be forced to reason about the entire system again accounting for the interleaving.• Can we make base-code specifications more robust to aspectual changes?
  9. 9. Motivation• [Sullivan FSE’05]: 1. Separate base and crosscutting concerns. 2. Implement base concerns in an OO style ignoring crosscutting concerns. 3. Implement the crosscutting concerns as aspects that advise the base code directly. 4
  10. 10. Insight
  11. 11. Insight• Aspect-oriented weaving and concurrent execution present similar challenges for program analysis.
  12. 12. Insight• Aspect-oriented weaving and concurrent execution present similar challenges for program analysis. • AOP case much simpler (restricted interleaving).
  13. 13. Insight• Aspect-oriented weaving and concurrent execution present similar challenges for program analysis. • AOP case much simpler (restricted interleaving). • Well-defined join points, sequential programs, only aspect can intercept the base-code.
  14. 14. Insight• Aspect-oriented weaving and concurrent execution present similar challenges for program analysis. • AOP case much simpler (restricted interleaving). • Well-defined join points, sequential programs, only aspect can intercept the base-code. • Concurrent program reasoning generally requires knowledge of all processes.
  15. 15. Insight• Aspect-oriented weaving and concurrent execution present similar challenges for program analysis. • AOP case much simpler (restricted interleaving). • Well-defined join points, sequential programs, only aspect can intercept the base-code. • Concurrent program reasoning generally requires knowledge of all processes. • Not the case in AOP.
  16. 16. Insight• Aspect-oriented weaving and concurrent execution present similar challenges for program analysis. • AOP case much simpler (restricted interleaving). • Well-defined join points, sequential programs, only aspect can intercept the base-code. • Concurrent program reasoning generally requires knowledge of all processes. • Not the case in AOP.• An approach known from concurrent programming, rely-guarantee [Xu97], can be adapted and then used to make AO programs more analyzable.
  17. 17. Notation the set of all variables of σ the program states in which eachσi , σj , ... variable has a particular value
  18. 18. !1!2!3
  19. 19. !1 Aspect!2!3
  20. 20. The Rely() Clause
  21. 21. The Rely() Clause• Identify a relation rely() that is a predicate over two states, σa and σb.
  22. 22. The Rely() Clause• Identify a relation rely() that is a predicate over two states, σa and σb.• rely() will not correspond to the actual behavior of advice.
  23. 23. The Rely() Clause• Identify a relation rely() that is a predicate over two states, σa and σb.• rely() will not correspond to the actual behavior of advice. • specify the kinds of behavior acceptable to m().
  24. 24. !a Aspect!b
  25. 25. The state at a point in the execution of a class is σa. !a Aspect !b
  26. 26. The state at a point in the execution of a class is σa. !a Aspect !bThe state when the class gets control back from an aspect is σb.
  27. 27. The state at a point in the execution of a class is σa. !a Aspect rely(σa, σb) !bThe state when the class gets control back from an aspect is σb.
  28. 28. Rely-Guarantee Approach for AOP
  29. 29. Rely-Guarantee Approach for AOPA method M under the influence of advice satisfies an R/G specification denoted by
  30. 30. Rely-Guarantee Approach for AOPA method M under the influence of advice satisfies an R/G specification denoted by M sat (pre, rely, guar, post)
  31. 31. Rely-Guarantee Approach for AOPA method M under the influence of advice satisfies an R/G specification denoted by M sat (pre, rely, guar, post) if
  32. 32. Rely-Guarantee Approach for AOP A method M under the influence of advice satisfies an R/G specification denoted by M sat (pre, rely, guar, post) if1) M is invoked in a state which satisfies pre, and
  33. 33. Rely-Guarantee Approach for AOP A method M under the influence of advice satisfies an R/G specification denoted by M sat (pre, rely, guar, post) if1) M is invoked in a state which satisfies pre, and2) all advice transitions satisfy rely,
  34. 34. Rely-Guarantee Approach for AOP A method M under the influence of advice satisfies an R/G specification denoted by M sat (pre, rely, guar, post) if1) M is invoked in a state which satisfies pre, and2) all advice transitions satisfy rely, then
  35. 35. Rely-Guarantee Approach for AOP A method M under the influence of advice satisfies an R/G specification denoted by M sat (pre, rely, guar, post) if1) M is invoked in a state which satisfies pre, and2) all advice transitions satisfy rely, then3) all states prior to M being intercepted by advicewill satisfy guar, and
  36. 36. Rely-Guarantee Approach for AOP A method M under the influence of advice satisfies an R/G specification denoted by M sat (pre, rely, guar, post) if1) M is invoked in a state which satisfies pre, and2) all advice transitions satisfy rely, then3) all states prior to M being intercepted by advicewill satisfy guar, and4) if the computation terminates, the final state willsatisfy post.
  37. 37. Rely-Guarantee Approach for AOP A method M under the influence of advice satisfies an R/G specification denoted by M sat (pre, rely, guar, post) if1) M is invoked in a state which satisfies pre, and2) all advice transitions satisfy rely, Pointcut then3) all states prior to M being intercepted by advicewill satisfy guar, and4) if the computation terminates, the final state willsatisfy post.
  38. 38. Rely-Guarantee Approach for AOP A method M under the influence of advice satisfies an R/G specification denoted by M sat (pre, rely, guar, post) if1) M is invoked in a state which satisfies pre, and2) all advice transitions satisfy rely, Pointcut then3) all states prior to M being intercepted by advicewill satisfy guar, and for advice pre4) if the computation terminates, the final state willsatisfy post.
  39. 39. Rely() Examplerely(σ, σ ) ≡ (σ = σ )
  40. 40. Rely() Example The entire state of Crely(σ, σ ) ≡ (σ = σ )
  41. 41. Rely() Examplerely(σ, σ ) ≡ (σ = σ ) ble ny ica g a pl in ! y ap ak te an m m sta ds fro the bi e or ic s in F v ad ange ch
  42. 42. Rely() Example This is “Harmless”[D&W POPL’06]rely(σ, σ ) ≡ (σ = σ )
  43. 43. 1 class Point { 2 int x, y; co 3 int s; pa 4 qu 5 public Point(int xi, int yi) mi 6 { x=xi; y=yi; s=1; } hav 7 public int getX() { return (x*s); } on 8 public int getY() { return (y*s); } ma 9 dif10 public void move(int nx, int ny)11 { x=nx; y=ny; } of12 } po13 rel14 aspect adjustScale { as15 pointcut m(Point p):16 execution(void Point.move(int,int)) cla17 && target( p ); tha18 ad19 after(Point p) : m(p) { in20 if ((p.x < 5) && (p.y < 5)) { p.s=10; }21 } we22 } wi ap the Figure 1. Point Class and Aspect on po
  44. 44. 1 class Point { 2 int x, y; co 3 int s; pa 4 qu 5 public Point(int xi, int yi) mi 6 { x=xi; y=yi; s=1; } hav 7 public int getX() { return (x*s); } on 8 public int getY() { return (y*s); } ma 9 dif 10 public void move(int nx, int ny) ofCoordinates { x=nx; y=ny; } 11 po 12 } 13 rel 14 aspect adjustScale { as 15 pointcut m(Point p): 16 execution(void Point.move(int,int)) cla 17 && target( p ); tha 18 ad 19 after(Point p) : m(p) { in 20 if ((p.x < 5) && (p.y < 5)) { p.s=10; } 21 } we 22 } wi ap the Figure 1. Point Class and Aspect on po
  45. 45. 1 class Point { 2 int x, y; co 3 int s; pa qu 4 5 public Point(int xi, int yi) Scaled mi 6 { x=xi; y=yi; s=1; } hav 7 public int getX() { return (x*s); } on 8 public int getY() { return (y*s); } ma 9 dif10 public void move(int nx, int ny)11 { x=nx; y=ny; } of12 } po13 rel14 aspect adjustScale { as15 pointcut m(Point p):16 execution(void Point.move(int,int)) cla17 && target( p ); tha18 ad19 after(Point p) : m(p) { in20 if ((p.x < 5) && (p.y < 5)) { p.s=10; }21 } we22 } wi ap the Figure 1. Point Class and Aspect on po
  46. 46. 1 class Point { 2 int x, y; co 3 int s; pa 4 qu 5 public Point(int xi, int yi) mi 6 { x=xi; y=yi; s=1; } hav 7 public int getX() { return (x*s); } on 8 public int getY() { return (y*s); } ma 9 dif10 public void move(int nx, int ny)11 { x=nx; y=ny; } of12 } po13 rel14 aspect adjustScale { as15 pointcut m(Point p):16 execution(void Point.move(int,int)) cla17 && target( p Too close! ); tha18 ad19 after(Point p) : m(p) { in20 if ((p.x < 5) && (p.y < 5)) { p.s=10; }21 } we22 } wi ap the Figure 1. Point Class and Aspect on po
  47. 47. 1 class Point { 2 int x, y; co 3 int s; pa 4 qu 5 public Point(int xi, int yi) mi 6 { x=xi; y=yi; s=1; } hav 7 public int getX() { return (x*s); } on 8 public int getY() { return (y*s); } ma 9 dif10 public void move(int nx, int ny)11 { x=nx; y=ny; } of12 } po13 rel14 aspect adjustScale { as15 pointcut m(Point p):16 execution(void Point.move(int,int)) cla17 && target( p ); tha18 ad19 after(Point p) : m(p) { in20 if ((p.x < 5) && (p.y < 5)) { p.s=10; }21 } we22 } wi Adjust ap the Figure 1. Point Class and Aspect on po
  48. 48. 1 class Point { 2 int x, y; co 3 int s; pa 4 qu 5 public Point(int xi, int yi) mi 6 { x=xi; y=yi; s=1; } hav 7 public int getX() { return (x*s); } on 8 public int getY() { return (y*s); } ma 9 dif10 public void move(int nx, int ny)11 { x=nx; y=ny; } of12 } po13 rel14 aspect adjustScale { as15 pointcut m(Point p):16 execution(void Point.move(int,int)) cla17 && target( p ); tha18 ad19 after(Point p) : m(p) { in20 if ((p.x < 5) && (p.y < 5)) { p.s=10; }21 } we22 } wi ap the Figure 1. Point Class and Aspect on po
  49. 49. A rely() for class Pointrely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]
  50. 50. A rely() for class Pointrely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]
  51. 51. A rely() for class Pointrely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)] (σ.s = σ .s)
  52. 52. A rely() for class Point rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]• Not a fault of the reasoning approach!
  53. 53. A rely() for class Point rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]• Not a fault of the reasoning approach!• Must be sure not to impose stronger requirements than necessary on aspects that might be developed later.
  54. 54. A rely() for class Point rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]• Not a fault of the reasoning approach!• Must be sure not to impose stronger requirements than necessary on aspects that might be developed later.• Otherwise, we may be forced to redo the task of reasoning about the class ...
  55. 55. A rely() for class Point rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]• Not a fault of the reasoning approach!• Must be sure not to impose stronger requirements than necessary on aspects that might be developed later.• Otherwise, we may be forced to redo the task of reasoning about the class ...• BUT, it is only in these cases where we must redo our reasoning.
  56. 56. The guar() Clause
  57. 57. The guar() Clause• Concurrent programs: the two processes act symmetrically.
  58. 58. The guar() Clause• Concurrent programs: the two processes act symmetrically.• AOP: base-code can’t intercept advice.
  59. 59. The guar() Clause• Concurrent programs: the two processes act symmetrically.• AOP: base-code can’t intercept advice.• guar() for AOP
  60. 60. The guar() Clause• Concurrent programs: the two processes act symmetrically.• AOP: base-code can’t intercept advice.• guar() for AOP• The assertion is true in this case.
  61. 61. The guar() Clause• Concurrent programs: the two processes act symmetrically.• AOP: base-code can’t intercept advice.• guar() for AOP• The assertion is true in this case. • Aspect not available at time of construction.
  62. 62. The guar() Clause• Concurrent programs: the two processes act symmetrically.• AOP: base-code can’t intercept advice.• guar() for AOP• The assertion is true in this case. • Aspect not available at time of construction. • Need to consider many possible joinpoints.
  63. 63. The guar() Clause• Concurrent programs: the two processes act symmetrically.• AOP: base-code can’t intercept advice.• guar() for AOP• The assertion is true in this case. • Aspect not available at time of construction. • Need to consider many possible joinpoints. • guar() may not be strong enough for future.
  64. 64. 9 d public void move(int nx, int ny) o 10 11 { x=nx; y=ny; } The Reasoning Processp class Point {• r 12 } 1 Do not have information 13 2 int x, y; about the value of a Point.s s; 14 aspect int 3 adjustScale { 15 pointcut m(Point p): 4 c 16 public Point(int xi, int yi) 5 execution(void Point.move(int,int)) 17 6 && target( p {); x=xi; y=yi; s=1; } t 18 7 public int getX() { return (x*s); } a 19 after(Point p) : getY() { return (y*s); } 8 public int m(p) { i 20 9 if ((p.x < 5) && (p.y < 5)) { p.s=10; } w 21 } 10 public void move(int nx, int ny) w 22 } 11 { x=nx; y=ny; } a 12 } t 13 Figure 1. Point Class and Aspect o aspect adjustScale { 14 p 15 pointcut m(Point p): f execution(void Point.move(int,int)) That is, indeed, precisely what the adjustScale aspect does. 16 ( && target( to an The pointcut m() corresponds p ); execution of the move() 17 o method. The after advice specified states that if the point p is 18 a sufficientlyafter(Point p) then the scale factor is set equal to 19 close to the origin, : m(p) { P ten4 . 20 if ((p.x < the class Point, we see that the Thus, if we consider just5) && (p.y < 5)) { p.s=10; } r
  65. 65. 9 d public void move(int nx, int ny) o 10 11 { x=nx; y=ny; } The Reasoning Processp class Point {• r 12 } 1 Do not have information 13 2 int x, y; about the value of a Point.s s; 14 aspect int 3 adjustScale { 15 pointcut m(Point p): 4 c 16 public Point(int xi, int yi) 5 execution(void Point.move(int,int)) 17 6 && target( p {); x=xi; y=yi; s=1; } t 18 7 public int getX() { return (x*s); } a 19 after(Point p) : getY() { return (y*s); } 8 public int m(p) { i 20 9 if ((p.x < 5) && (p.y < 5)) { p.s=10; } w 21 } 10 public void move(int nx, int ny) w 22 } 11 { x=nx; y=ny; } a 12 } t 13 Figure 1. Point Class and Aspect o aspect adjustScale { 14 p 15 pointcut m(Point p): f execution(void Point.move(int,int)) That is, indeed, precisely what the adjustScale aspect does. 16 ( && target( to an The pointcut m() corresponds p ); execution of the move() 17 o method. The after advice specified states that if the point p is 18 a sufficientlyafter(Point p) then the scale factor is set equal to 19 close to the origin, : m(p) { P ten4 . 20 if ((p.x < the class Point, we see that the Thus, if we consider just5) && (p.y < 5)) { p.s=10; } r
  66. 66. 9 d public void move(int nx, int ny) o 10 11 { x=nx; y=ny; } The Reasoning Processp class Point {• r 12 } 1 Do not have information 13 2 int x, y; about the value of a Point.s s; 14 aspect int 3 adjustScale { 15 pointcut m(Point p): 4 c 16 public Point(int xi, int yi) 5 execution(void Point.move(int,int)) 17 6 && target( p {); x=xi; y=yi; s=1; } t 18 7 public int getX() { return (x*s); } a 19 after(Point p) : getY() { return (y*s); } 8 public int m(p) { i 20 9 if ((p.x < 5) && (p.y < 5)) { p.s=10; } w 21 } 10 public void move(int nx, int ny) w 22 } 11 { x=nx; y=ny; } a 12 } t 13 Figure 1. Point Class and Aspect o aspect adjustScale { 14 p 15 pointcut m(Point p): f execution(void Point.move(int,int)) That is, indeed, precisely what the adjustScale aspect does. 16 ( && target( to an The pointcut m() corresponds p ); execution of the move() 17 o method. The after advice specified states that if the point p is 18 a sufficientlyafter(Point p) then the scale factor is set equal to 19 close to the origin, : m(p) { P ten4 . 20 if ((p.x < the class Point, we see that the Thus, if we consider just5) && (p.y < 5)) { p.s=10; } r
  67. 67. 9 d public void move(int nx, int ny) o 10 11 { x=nx; y=ny; } The Reasoning Processp class Point {• r 12 } 1 Do not have information 13 2 int x, y; about the value of a Point.s s; 14 aspect int 3 adjustScale { 15 pointcut m(Point p): 4 c 16 public Point(int xi, int yi) 5 execution(void Point.move(int,int)) 17 6 && target( p {); x=xi; y=yi; s=1; } t 18 7 public int getX() { return (x*s); } a 19 after(Point p) : getY() { return (y*s); } 8 public int m(p) { i 20 9 if ((p.x < 5) && (p.y < 5)) { p.s=10; } w 21 } 10 public void move(int nx, int ny) w 22 } 11 { x=nx; y=ny; } a• History variable [Hoare78] 12 } Figure 1. Point Class and Aspect 13 t o • aspect adjustScale { Provides additional information required to 14 pointcut m(Point p): 15 p f establishexecution(voidof the combined system. the behavior Point.move(int,int)) That is, indeed, precisely what the adjustScale aspect does. 16 ( && target( to an The pointcut m() corresponds p ); execution of the move() 17 o method. The after advice specified states that if the point p is 18 a sufficientlyafter(Point p) then the scale factor is set equal to 19 close to the origin, : m(p) { P ten4 . 20 if ((p.x < the class Point, we see that the Thus, if we consider just5) && (p.y < 5)) { p.s=10; } r
  68. 68. 4 5 public Point(int xi, int History Variable yi) 6 { x=xi; y=yi; s=1; } 7 Consider intbehavior of Point.move(): } public the getX() { return (x*s); 8 public int getY() { return (y*s); } 910 public void move(int nx, int ny)11 { x=nx; y=ny; }12 }1314 aspect What’s the value{of Point.s? adjustScale15 pointcut m(Point p):16 execution(void Point.move(int,int))17 && target( p );1819 after(Point p) : m(p) {20 if ((p.x < 5) && (p.y < 5)) { p.s=121 }
  69. 69. 4 5 public Point(int xi, int History Variable yi) 6 { x=xi; y=yi; s=1; } 7 Consider intbehavior of Point.move(): } public the getX() { return (x*s); 8 public int getY() { return (y*s); } 9 10 public void move(int nx, int ny) 11 { x=nx; y=ny; } 12 } 13 14 aspect What’s the value{of Point.s? adjustScale 15 pointcut m(Point p): execution(void Point.move(int,int))• 16 From the && target( p ); know that it does not 17 body of move(), we change the value of s. 18 • 19 20 after(Point p) : m(p) { must have been due to aspectual (i.e., if ((p.x < 5) && (p.y < 5)) { p.s=1 21 environmental) influence. }
  70. 70. Post-condition of Point.move()
  71. 71. Post-condition of Point.move()• Post-condition of move() will state: • Values of x and y are equal to the values for the corresponding arguments received. • Value of s will be equal to whatever it was when the final advice to execute during the execution of move() completes.
  72. 72. Post-condition of Point.move()• Post-condition of move() will state: • Values of x and y are equal to the values for the corresponding arguments received. • Value of s will be equal to whatever it was when the final advice to execute during the execution of move() completes.• Can conclude that s will be 10 or what it was at the start of the method.
  73. 73. 1 class Point { But 2 int x, y; condit 3 int s; particu 4 questi 5 public Point(int xi, int yi) might 6 { x=xi; y=yi; s=1; } have t 7 public int getX() { return (x*s); } on an 8 public int getY() { return (y*s); } may h 9 differe10 public void move(int nx, int ny)11 { x=nx; y=ny; } of exp12 } pointc13 rely()14 aspect adjustScale { as (1)15 pointcut m(Point p): Ho16 execution(void Point.move(int,int)) class a17 && target( p ); that ap18 advice19 after(Point p) : m(p) { in whi20 if ((p.x < 5) && (p.y < 5)) { p.s=10; }21 } we wi22 } will, t a pote the cla Figure 1. Point Class and Aspect one or possib
  74. 74. 1 class Point { But 2 int x, y; condit 3 int s; particu 4 questi 5 public Point(int xi, int yi) might 6 { x=xi; y=yi; s=1; } have t 7 public int getX() { return (x*s); } on an 8 public int getY() { return (y*s); } may h 9 differe10 public void move(int nx, int ny)11 { x=nx; y=ny; } of exp12 } pointc13 rely()14 aspect adjustScale { as (1)15 pointcut m(Point p): Ho16 execution(void Point.move(int,int)) class a17 && target( p ); that ap18 advice19 after(Point p) : m(p) { in whi20 if ((p.x < 5) && (p.y < 5)) { p.s=10; }21 } we wi22 } will, t a pote the cla Figure 1. Point Class and Aspect one or possib
  75. 75. Conclusion and Future Work
  76. 76. Conclusion and Future Work• AO programmers already think implicitly about rely(), our proposed approach makes this explicit.
  77. 77. Conclusion and Future Work• AO programmers already think implicitly about rely(), our proposed approach makes this explicit. • Formally capture properties we want AO programs to exhibit.
  78. 78. Conclusion and Future Work• AO programmers already think implicitly about rely(), our proposed approach makes this explicit. • Formally capture properties we want AO programs to exhibit. • rely() specifies the kinds of aspectual influence the base-code is willing to tolerate so that it would not be adversely affected by advice.
  79. 79. Conclusion and Future Work• AO programmers already think implicitly about rely(), our proposed approach makes this explicit. • Formally capture properties we want AO programs to exhibit. • rely() specifies the kinds of aspectual influence the base-code is willing to tolerate so that it would not be adversely affected by advice.• Specifying rely().
  80. 80. Conclusion and Future Work• AO programmers already think implicitly about rely(), our proposed approach makes this explicit. • Formally capture properties we want AO programs to exhibit. • rely() specifies the kinds of aspectual influence the base-code is willing to tolerate so that it would not be adversely affected by advice.• Specifying rely().• Formal framework, obtaining richer behavior.
  81. 81. Conclusion and Future Work• AO programmers already think implicitly about rely(), our proposed approach makes this explicit. • Formally capture properties we want AO programs to exhibit. • rely() specifies the kinds of aspectual influence the base-code is willing to tolerate so that it would not be adversely affected by advice.• Specifying rely().• Formal framework, obtaining richer behavior.• Multiple applicable advice.
  82. 82. Conclusion and Future Work• AO programmers already think implicitly about rely(), our proposed approach makes this explicit. • Formally capture properties we want AO programs to exhibit. • rely() specifies the kinds of aspectual influence the base-code is willing to tolerate so that it would not be adversely affected by advice.• Specifying rely().• Formal framework, obtaining richer behavior.• Multiple applicable advice.• Tool-supported verification.

×