### SlideShare for iOS

by Linkedin Corporation

FREE - On the App Store

Over the last few years, the question of reasoning about aspect-oriented programs has been addressed by a number of authors. In this paper, we present a rely-guarantee approach to such reasoning. The ...

Over the last few years, the question of reasoning about aspect-oriented programs has been addressed by a number of authors. In this paper, we present a rely-guarantee approach to such reasoning. The rely-guarantee approach has proven extremely successful in reasoning about concurrent and distributed programs. We show that some of the key 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. We illustrate our approach with a simple example.

- Total Views
- 459
- Views on SlideShare
- 459
- Embed Views

- Likes
- 0
- Downloads
- 1
- Comments
- 0

No embeds

Uploaded via SlideShare as Apple Keynote

© All Rights Reserved

- 1. Rely-Guarantee Approach to Reasoning about Aspect-Oriented Programs Raffi Khatchadourian and Neelam Soundarajan The Ohio State University
- 2. Introduction • AOP enables modular implementation of cross- cutting concerns. • Reasoning about AOP presents some key challenges.
- 3. The Problem
- 4. The Problem • Addition of an aspect can change the behavior of the base code.
- 5. The Problem Desirable! • Addition of an aspect can change the behavior of the base code.
- 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. 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. 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. 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. Insight
- 11. Insight • Aspect-oriented weaving and concurrent execution present similar challenges for program analysis.
- 12. Insight • Aspect-oriented weaving and concurrent execution present similar challenges for program analysis. • AOP case much simpler (restricted interleaving)
- 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. 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. 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. 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. Notation the set of all variables of σ the program states in which each σi , σj , ... variable has a particular value
- 18. !1 !2 !3
- 19. !1 Aspect !2' !3
- 20. The Rely() Clause
- 21. The Rely() Clause • Identify a relation rely() that is a predicate over two states, σa and σb.
- 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. 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. !a Aspect !b
- 25. The state at a point in the execution of a class is σa. !a Aspect !b
- 26. The state at a point in the execution of a class is σa. !a Aspect !b The state when the class gets control back from an aspect is σb.
- 27. The state at a point in the execution of a class is σa. !a Aspect rely(σa, σb) !b The state when the class gets control back from an aspect is σb.
- 28. Rely-Guarantee Approach for AOP
- 29. Rely-Guarantee Approach for AOP A method M under the influence of advice satisfies an R/G specification denoted by
- 30. 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)
- 31. 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) if
- 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) if 1) M is invoked in a state which satisfies pre, and
- 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) if 1) M is invoked in a state which satisfies pre, and 2) all advice transitions satisfies rely,
- 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) if 1) M is invoked in a state which satisfies pre, and 2) all advice transitions satisfies rely, then
- 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) if 1) M is invoked in a state which satisfies pre, and 2) all advice transitions satisfies rely, then 3) all states prior to M being intercepted by advice will satisfy guar, and
- 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) if 1) M is invoked in a state which satisfies pre, and 2) all advice transitions satisfies rely, then 3) all states prior to M being intercepted by advice will satisfy guar, and 4) if the computation terminates, the final state will satisfy post.
- 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) if 1) M is invoked in a state which satisfies pre, and 2) all advice transitions satisfies rely, Pointcut then 3) all states prior to M being intercepted by advice will satisfy guar, and 4) if the computation terminates, the final state will satisfy post.
- 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) if 1) M is invoked in a state which satisfies pre, and 2) all advice transitions satisfies rely, Pointcut then 3) all states prior to M being intercepted by advice will satisfy guar, and for advice pre 4) if the computation terminates, the final state will satisfy post.
- 39. Rely() Example rely(σ, σ ) ≡ (σ = σ )
- 40. Rely() Example The entire state of C rely(σ, σ ) ≡ (σ = σ )
- 41. Rely() Example rely(σ, σ ) ≡ (σ = σ ) 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. Rely() Example This is “Harmless”[D&W POPL’06] rely(σ, σ ) ≡ (σ = σ )
- 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; } ha 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) 11 { x=nx; y=ny; } of 12 } po 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
- 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; } ha 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) of Coordinates { 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. 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; } ha 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) 11 { x=nx; y=ny; } of 12 } po 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
- 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; } ha 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) 11 { x=nx; y=ny; } of 12 } po 13 rel 14 aspect adjustScale { as 15 pointcut m(Point p): 16 execution(void Point.move(int,int)) cla 17 && target( p Too close! ); 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
- 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; } ha 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) 11 { x=nx; y=ny; } of 12 } po 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 Adjust ap the Figure 1. Point Class and Aspect on po
- 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; } ha 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) 11 { x=nx; y=ny; } of 12 } po 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
- 49. Questions
- 50. Questions • Isolated and robust reasoning?
- 51. Questions • Isolated and robust reasoning? • rely()?
- 52. Questions • Isolated and robust reasoning? • rely()? • Verification?
- 53. Questions • Isolated and robust reasoning? • rely()? • Verification? • guar()?
- 54. Questions • Isolated and robust reasoning? • rely()? • Verification? • guar()? • More verification?
- 55. Questions • Isolated and robust reasoning? • rely()? • Verification? • guar()? • More verification? • Composition?
- 56. A rely() for class Point rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]
- 57. A rely() for class Point rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]
- 58. A rely() for class Point rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)] (σ.s = σ .s)
- 59. A rely() for class Point rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)] • Not a fault of the reasoning approach!
- 60. 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.
- 61. 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 ...
- 62. 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.
- 63. The guar() Clause
- 64. The guar() Clause • Concurrent programs: the two processes act symmetrically.
- 65. The guar() Clause • Concurrent programs: the two processes act symmetrically. • AOP: base-code can’t intercept advice.
- 66. The guar() Clause • Concurrent programs: the two processes act symmetrically. • AOP: base-code can’t intercept advice. • guar() for AOP
- 67. 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.
- 68. 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.
- 69. 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.
- 70. 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.
- 71. 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 speciﬁed states that if the point p is 18 a sufﬁcientlyafter(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
- 72. 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 speciﬁed states that if the point p is 18 a sufﬁcientlyafter(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
- 73. 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 speciﬁed states that if the point p is 18 a sufﬁcientlyafter(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
- 74. 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 speciﬁed states that if the point p is 18 a sufﬁcientlyafter(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
- 75. 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): 16 execution(void Point.move(int,int)) 17 && target( p ); 18 19 after(Point p) : m(p) { 20 if ((p.x < 5) && (p.y < 5)) { p.s=1 21 }
- 76. 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. }
- 77. Post-condition of Point.move()
- 78. 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.
- 79. 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.
- 80. 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 differe 10 public void move(int nx, int ny) 11 { x=nx; y=ny; } of exp 12 } pointc 13 rely() 14 aspect adjustScale { as (1) 15 pointcut m(Point p): Ho 16 execution(void Point.move(int,int)) class a 17 && target( p ); that ap 18 advice 19 after(Point p) : m(p) { in whi 20 if ((p.x < 5) && (p.y < 5)) { p.s=10; } 21 } we wi 22 } will, t a pote the cla Figure 1. Point Class and Aspect one or possib
- 81. 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 differe 10 public void move(int nx, int ny) 11 { x=nx; y=ny; } of exp 12 } pointc 13 rely() 14 aspect adjustScale { as (1) 15 pointcut m(Point p): Ho 16 execution(void Point.move(int,int)) class a 17 && target( p ); that ap 18 advice 19 after(Point p) : m(p) { in whi 20 if ((p.x < 5) && (p.y < 5)) { p.s=10; } 21 } we wi 22 } will, t a pote the cla Figure 1. Point Class and Aspect one or possib
- 82. Conclusion and Future Work
- 83. Conclusion and Future Work • AO programmers already think implicitly about rely(), our proposed approach makes this explicit.
- 84. Conclusion and Future Work • AO programmers already think implicitly about rely(), our proposed approach makes this explicit. • Formally capture properties of we want AO programs to exhibit.
- 85. Conclusion and Future Work • AO programmers already think implicitly about rely(), our proposed approach makes this explicit. • Formally capture properties of 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.
- 86. Conclusion and Future Work • AO programmers already think implicitly about rely(), our proposed approach makes this explicit. • Formally capture properties of 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().
- 87. Conclusion and Future Work • AO programmers already think implicitly about rely(), our proposed approach makes this explicit. • Formally capture properties of 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.
- 88. Conclusion and Future Work • AO programmers already think implicitly about rely(), our proposed approach makes this explicit. • Formally capture properties of 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.
- 89. Conclusion and Future Work • AO programmers already think implicitly about rely(), our proposed approach makes this explicit. • Formally capture properties of 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.

Full NameComment goes here.