The document discusses the challenges of reasoning about aspect-oriented programming (AOP), particularly how adding aspects can alter base code behavior, rendering prior reasoning invalid. It introduces a rely-guarantee approach adapted from concurrent programming to enhance the analyzability of AOP by specifying acceptable behaviors and ensuring robust reasoning without imposing unnecessary constraints on future aspects. The reliance on clearly defined relations (rely and guar clauses) serves to maintain program correctness amidst interleaving concerns of base and aspect interactions.

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

19. !1
!2
!3

22. !1
Aspect
!2'
!3

23. The Rely() Clause

24. The Rely() Clause
• Identify a relation rely() that is a predicate over two
states, σa and σb.

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

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

28. !a
Aspect
!b

29. The state at a point in the execution
of a class is σa.
!a
Aspect
!b

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

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

32. Rely-Guarantee Approach for AOP

33. Rely-Guarantee Approach for AOP
A method M under the influence of advice satisfies
an R/G specification denoted by

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)

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

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

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,

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,
then

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

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

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

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

43. Rely() Example
rely(σ, σ ) ≡ (σ = σ )

44. Rely() Example
The entire state
of C
rely(σ, σ ) ≡ (σ = σ )

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

46. Rely() Example
This is
“Harmless”[D&W
POPL’06]
rely(σ, σ ) ≡ (σ = σ )

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

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

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

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

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

53. Questions

54. Questions
• Isolated and robust reasoning?

55. Questions
• Isolated and robust reasoning?
• rely()?

56. Questions
• Isolated and robust reasoning?
• rely()?
• Verification?

57. Questions
• Isolated and robust reasoning?
• rely()?
• Verification?
• guar()?

58. Questions
• Isolated and robust reasoning?
• rely()?
• Verification?
• guar()?
• More verification?

59. Questions
• Isolated and robust reasoning?
• rely()?
• Verification?
• guar()?
• More verification?
• Composition?

60. A rely() for class Point
rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]

61. A rely() for class Point
rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]

62. A rely() for class Point
rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]
(σ.s = σ .s)

63. A rely() for class Point
rely(σ, σ ) ≡ [(σ.x = σ .x) ∧ (σ.y = σ .y)]
• Not a fault of the reasoning approach!

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

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

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

67. The guar() Clause

68. The guar() Clause
• Concurrent programs: the two processes act
symmetrically.

69. The guar() Clause
• Concurrent programs: the two processes act
symmetrically.
• AOP: base-code can’t intercept advice.

70. The guar() Clause
• Concurrent programs: the two processes act
symmetrically.
• AOP: base-code can’t intercept advice.
• guar() for AOP

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

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

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

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

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

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

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

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

79. 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 }

80. 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.
}

81. Post-condition of Point.move()

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

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

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

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

86. Conclusion and Future Work

87. Conclusion and Future Work
• AO programmers already think implicitly about
rely(), our proposed approach makes this explicit.

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.

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.

90. 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().

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

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

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