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.
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
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
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().
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.
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
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.
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.
}
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
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.
Notes de l'éditeur
Hello, my name is Raffi Khatchadourian and today I&#x2019;m going to be discussing a rely-guarantee approach to reasoning about Aspect-Oriented Programs, which is joint work at The Ohio State University with my advisor, Neelam Soundarajan.
We all know how AOP can help us write modular implementations of cross-cutting concerns but what may not be as obvious is the tradeoffs that are presented in respect to the so-called '-ilities' &#x2014; comprehensibility, evolvability, modularity, and analyzability&#x2014; of such programs. In fact, analyzing AO programs can be a non-trivial task and consequently present some key challenges.
To set up some motivation for this notion, let&#x2019;s take a look at a common, yet perhaps unfortunate, design process and architectural style for AOP systems. In fact, Kevin Sullivan and his colleges used this description to motivate their approach on AOP system design in their FSE 2005 paper.
Let&#x2019;s set up an example to demonstrate our proposed approach. In the spirit of previous reasoning papers on AOP, we use a very simplified version of the classic example inspired by JHotDraw. Here, we will consider just a Point class consisting of two coordinates, x and y.
<click>
We also have corresponding accessor methods for these coordinates that return a potentially modified version of the values. That is, objects of the point class are intended to be drawn on a canvas and we can imagine that the designer of the Point class has built in an optional scaling functionality.
<click>
The coordinate values are therefore returned scaled to the factor &#x2018;s&#x2019;, an instance variable of class Point, which is initially set to 1 thus having no net affect.
<click>
Now let&#x2019;s say that figure scaling is considered a cross-cutting concern in the enclosing system and we have a suitable aspect that encapsulates this cross-cutting functionality. It is considered that points too close to the origin (5 in this example) should be scaled accordingly in order preserve visibility. This is precisely what the adjustScale aspect does. In this simplified example, the aspect advises execution of the method move of class Point (which sets the coordinates to the values provided by its parameters). If after execution of this method
<click>
the coordinates come within a threshold, the scale factor is set accordingly.
<click>
10 in this example. Internally, the point retains its intended position but through its accessor methods getX and getY it is painted on the canvas according to the rule we have presented.
Let&#x2019;s set up an example to demonstrate our proposed approach. In the spirit of previous reasoning papers on AOP, we use a very simplified version of the classic example inspired by JHotDraw. Here, we will consider just a Point class consisting of two coordinates, x and y.
<click>
We also have corresponding accessor methods for these coordinates that return a potentially modified version of the values. That is, objects of the point class are intended to be drawn on a canvas and we can imagine that the designer of the Point class has built in an optional scaling functionality.
<click>
The coordinate values are therefore returned scaled to the factor &#x2018;s&#x2019;, an instance variable of class Point, which is initially set to 1 thus having no net affect.
<click>
Now let&#x2019;s say that figure scaling is considered a cross-cutting concern in the enclosing system and we have a suitable aspect that encapsulates this cross-cutting functionality. It is considered that points too close to the origin (5 in this example) should be scaled accordingly in order preserve visibility. This is precisely what the adjustScale aspect does. In this simplified example, the aspect advises execution of the method move of class Point (which sets the coordinates to the values provided by its parameters). If after execution of this method
<click>
the coordinates come within a threshold, the scale factor is set accordingly.
<click>
10 in this example. Internally, the point retains its intended position but through its accessor methods getX and getY it is painted on the canvas according to the rule we have presented.
Let&#x2019;s set up an example to demonstrate our proposed approach. In the spirit of previous reasoning papers on AOP, we use a very simplified version of the classic example inspired by JHotDraw. Here, we will consider just a Point class consisting of two coordinates, x and y.
<click>
We also have corresponding accessor methods for these coordinates that return a potentially modified version of the values. That is, objects of the point class are intended to be drawn on a canvas and we can imagine that the designer of the Point class has built in an optional scaling functionality.
<click>
The coordinate values are therefore returned scaled to the factor &#x2018;s&#x2019;, an instance variable of class Point, which is initially set to 1 thus having no net affect.
<click>
Now let&#x2019;s say that figure scaling is considered a cross-cutting concern in the enclosing system and we have a suitable aspect that encapsulates this cross-cutting functionality. It is considered that points too close to the origin (5 in this example) should be scaled accordingly in order preserve visibility. This is precisely what the adjustScale aspect does. In this simplified example, the aspect advises execution of the method move of class Point (which sets the coordinates to the values provided by its parameters). If after execution of this method
<click>
the coordinates come within a threshold, the scale factor is set accordingly.
<click>
10 in this example. Internally, the point retains its intended position but through its accessor methods getX and getY it is painted on the canvas according to the rule we have presented.
Let&#x2019;s set up an example to demonstrate our proposed approach. In the spirit of previous reasoning papers on AOP, we use a very simplified version of the classic example inspired by JHotDraw. Here, we will consider just a Point class consisting of two coordinates, x and y.
<click>
We also have corresponding accessor methods for these coordinates that return a potentially modified version of the values. That is, objects of the point class are intended to be drawn on a canvas and we can imagine that the designer of the Point class has built in an optional scaling functionality.
<click>
The coordinate values are therefore returned scaled to the factor &#x2018;s&#x2019;, an instance variable of class Point, which is initially set to 1 thus having no net affect.
<click>
Now let&#x2019;s say that figure scaling is considered a cross-cutting concern in the enclosing system and we have a suitable aspect that encapsulates this cross-cutting functionality. It is considered that points too close to the origin (5 in this example) should be scaled accordingly in order preserve visibility. This is precisely what the adjustScale aspect does. In this simplified example, the aspect advises execution of the method move of class Point (which sets the coordinates to the values provided by its parameters). If after execution of this method
<click>
the coordinates come within a threshold, the scale factor is set accordingly.
<click>
10 in this example. Internally, the point retains its intended position but through its accessor methods getX and getY it is painted on the canvas according to the rule we have presented.
Let&#x2019;s set up an example to demonstrate our proposed approach. In the spirit of previous reasoning papers on AOP, we use a very simplified version of the classic example inspired by JHotDraw. Here, we will consider just a Point class consisting of two coordinates, x and y.
<click>
We also have corresponding accessor methods for these coordinates that return a potentially modified version of the values. That is, objects of the point class are intended to be drawn on a canvas and we can imagine that the designer of the Point class has built in an optional scaling functionality.
<click>
The coordinate values are therefore returned scaled to the factor &#x2018;s&#x2019;, an instance variable of class Point, which is initially set to 1 thus having no net affect.
<click>
Now let&#x2019;s say that figure scaling is considered a cross-cutting concern in the enclosing system and we have a suitable aspect that encapsulates this cross-cutting functionality. It is considered that points too close to the origin (5 in this example) should be scaled accordingly in order preserve visibility. This is precisely what the adjustScale aspect does. In this simplified example, the aspect advises execution of the method move of class Point (which sets the coordinates to the values provided by its parameters). If after execution of this method
<click>
the coordinates come within a threshold, the scale factor is set accordingly.
<click>
10 in this example. Internally, the point retains its intended position but through its accessor methods getX and getY it is painted on the canvas according to the rule we have presented.
Let&#x2019;s set up an example to demonstrate our proposed approach. In the spirit of previous reasoning papers on AOP, we use a very simplified version of the classic example inspired by JHotDraw. Here, we will consider just a Point class consisting of two coordinates, x and y.
<click>
We also have corresponding accessor methods for these coordinates that return a potentially modified version of the values. That is, objects of the point class are intended to be drawn on a canvas and we can imagine that the designer of the Point class has built in an optional scaling functionality.
<click>
The coordinate values are therefore returned scaled to the factor &#x2018;s&#x2019;, an instance variable of class Point, which is initially set to 1 thus having no net affect.
<click>
Now let&#x2019;s say that figure scaling is considered a cross-cutting concern in the enclosing system and we have a suitable aspect that encapsulates this cross-cutting functionality. It is considered that points too close to the origin (5 in this example) should be scaled accordingly in order preserve visibility. This is precisely what the adjustScale aspect does. In this simplified example, the aspect advises execution of the method move of class Point (which sets the coordinates to the values provided by its parameters). If after execution of this method
<click>
the coordinates come within a threshold, the scale factor is set accordingly.
<click>
10 in this example. Internally, the point retains its intended position but through its accessor methods getX and getY it is painted on the canvas according to the rule we have presented.
Let&#x2019;s set up an example to demonstrate our proposed approach. In the spirit of previous reasoning papers on AOP, we use a very simplified version of the classic example inspired by JHotDraw. Here, we will consider just a Point class consisting of two coordinates, x and y.
<click>
We also have corresponding accessor methods for these coordinates that return a potentially modified version of the values. That is, objects of the point class are intended to be drawn on a canvas and we can imagine that the designer of the Point class has built in an optional scaling functionality.
<click>
The coordinate values are therefore returned scaled to the factor &#x2018;s&#x2019;, an instance variable of class Point, which is initially set to 1 thus having no net affect.
<click>
Now let&#x2019;s say that figure scaling is considered a cross-cutting concern in the enclosing system and we have a suitable aspect that encapsulates this cross-cutting functionality. It is considered that points too close to the origin (5 in this example) should be scaled accordingly in order preserve visibility. This is precisely what the adjustScale aspect does. In this simplified example, the aspect advises execution of the method move of class Point (which sets the coordinates to the values provided by its parameters). If after execution of this method
<click>
the coordinates come within a threshold, the scale factor is set accordingly.
<click>
10 in this example. Internally, the point retains its intended position but through its accessor methods getX and getY it is painted on the canvas according to the rule we have presented.
Let&#x2019;s set up an example to demonstrate our proposed approach. In the spirit of previous reasoning papers on AOP, we use a very simplified version of the classic example inspired by JHotDraw. Here, we will consider just a Point class consisting of two coordinates, x and y.
<click>
We also have corresponding accessor methods for these coordinates that return a potentially modified version of the values. That is, objects of the point class are intended to be drawn on a canvas and we can imagine that the designer of the Point class has built in an optional scaling functionality.
<click>
The coordinate values are therefore returned scaled to the factor &#x2018;s&#x2019;, an instance variable of class Point, which is initially set to 1 thus having no net affect.
<click>
Now let&#x2019;s say that figure scaling is considered a cross-cutting concern in the enclosing system and we have a suitable aspect that encapsulates this cross-cutting functionality. It is considered that points too close to the origin (5 in this example) should be scaled accordingly in order preserve visibility. This is precisely what the adjustScale aspect does. In this simplified example, the aspect advises execution of the method move of class Point (which sets the coordinates to the values provided by its parameters). If after execution of this method
<click>
the coordinates come within a threshold, the scale factor is set accordingly.
<click>
10 in this example. Internally, the point retains its intended position but through its accessor methods getX and getY it is painted on the canvas according to the rule we have presented.
Let&#x2019;s set up an example to demonstrate our proposed approach. In the spirit of previous reasoning papers on AOP, we use a very simplified version of the classic example inspired by JHotDraw. Here, we will consider just a Point class consisting of two coordinates, x and y.
<click>
We also have corresponding accessor methods for these coordinates that return a potentially modified version of the values. That is, objects of the point class are intended to be drawn on a canvas and we can imagine that the designer of the Point class has built in an optional scaling functionality.
<click>
The coordinate values are therefore returned scaled to the factor &#x2018;s&#x2019;, an instance variable of class Point, which is initially set to 1 thus having no net affect.
<click>
Now let&#x2019;s say that figure scaling is considered a cross-cutting concern in the enclosing system and we have a suitable aspect that encapsulates this cross-cutting functionality. It is considered that points too close to the origin (5 in this example) should be scaled accordingly in order preserve visibility. This is precisely what the adjustScale aspect does. In this simplified example, the aspect advises execution of the method move of class Point (which sets the coordinates to the values provided by its parameters). If after execution of this method
<click>
the coordinates come within a threshold, the scale factor is set accordingly.
<click>
10 in this example. Internally, the point retains its intended position but through its accessor methods getX and getY it is painted on the canvas according to the rule we have presented.
Let&#x2019;s set up an example to demonstrate our proposed approach. In the spirit of previous reasoning papers on AOP, we use a very simplified version of the classic example inspired by JHotDraw. Here, we will consider just a Point class consisting of two coordinates, x and y.
<click>
We also have corresponding accessor methods for these coordinates that return a potentially modified version of the values. That is, objects of the point class are intended to be drawn on a canvas and we can imagine that the designer of the Point class has built in an optional scaling functionality.
<click>
The coordinate values are therefore returned scaled to the factor &#x2018;s&#x2019;, an instance variable of class Point, which is initially set to 1 thus having no net affect.
<click>
Now let&#x2019;s say that figure scaling is considered a cross-cutting concern in the enclosing system and we have a suitable aspect that encapsulates this cross-cutting functionality. It is considered that points too close to the origin (5 in this example) should be scaled accordingly in order preserve visibility. This is precisely what the adjustScale aspect does. In this simplified example, the aspect advises execution of the method move of class Point (which sets the coordinates to the values provided by its parameters). If after execution of this method
<click>
the coordinates come within a threshold, the scale factor is set accordingly.
<click>
10 in this example. Internally, the point retains its intended position but through its accessor methods getX and getY it is painted on the canvas according to the rule we have presented.
Let&#x2019;s set up an example to demonstrate our proposed approach. In the spirit of previous reasoning papers on AOP, we use a very simplified version of the classic example inspired by JHotDraw. Here, we will consider just a Point class consisting of two coordinates, x and y.
<click>
We also have corresponding accessor methods for these coordinates that return a potentially modified version of the values. That is, objects of the point class are intended to be drawn on a canvas and we can imagine that the designer of the Point class has built in an optional scaling functionality.
<click>
The coordinate values are therefore returned scaled to the factor &#x2018;s&#x2019;, an instance variable of class Point, which is initially set to 1 thus having no net affect.
<click>
Now let&#x2019;s say that figure scaling is considered a cross-cutting concern in the enclosing system and we have a suitable aspect that encapsulates this cross-cutting functionality. It is considered that points too close to the origin (5 in this example) should be scaled accordingly in order preserve visibility. This is precisely what the adjustScale aspect does. In this simplified example, the aspect advises execution of the method move of class Point (which sets the coordinates to the values provided by its parameters). If after execution of this method
<click>
the coordinates come within a threshold, the scale factor is set accordingly.
<click>
10 in this example. Internally, the point retains its intended position but through its accessor methods getX and getY it is painted on the canvas according to the rule we have presented.
Let&#x2019;s set up an example to demonstrate our proposed approach. In the spirit of previous reasoning papers on AOP, we use a very simplified version of the classic example inspired by JHotDraw. Here, we will consider just a Point class consisting of two coordinates, x and y.
<click>
We also have corresponding accessor methods for these coordinates that return a potentially modified version of the values. That is, objects of the point class are intended to be drawn on a canvas and we can imagine that the designer of the Point class has built in an optional scaling functionality.
<click>
The coordinate values are therefore returned scaled to the factor &#x2018;s&#x2019;, an instance variable of class Point, which is initially set to 1 thus having no net affect.
<click>
Now let&#x2019;s say that figure scaling is considered a cross-cutting concern in the enclosing system and we have a suitable aspect that encapsulates this cross-cutting functionality. It is considered that points too close to the origin (5 in this example) should be scaled accordingly in order preserve visibility. This is precisely what the adjustScale aspect does. In this simplified example, the aspect advises execution of the method move of class Point (which sets the coordinates to the values provided by its parameters). If after execution of this method
<click>
the coordinates come within a threshold, the scale factor is set accordingly.
<click>
10 in this example. Internally, the point retains its intended position but through its accessor methods getX and getY it is painted on the canvas according to the rule we have presented.
The following questions arise:
<click>
how to reason about the behaviors of the methods getX(), getY(), and move() of the Point class in isolation of any applicable advice and how to develop reasoning robust to environmental influence.
<click>
In the rely-guarantee context, what rely() condition that will be applicable to any aspect that may act on the methods of Point should we assume?
<click>
Then, how do we show that the behavior of the advice defined in the adjustScale aspect is consistent with the rely() condition imposed by the Point class?
<click>
Also, does the correct functioning of advice require us to impose any conditions on the behaviors of the methods of Point? And if so, how do we go about specifying those conditions?
<click>
Once we have established that, how do we check that the actual behavior of the Point class satisfies the guar() clause?
<click>
And finally, how do we arrive at the resulting behavior that the combined system will exhibit?
The following questions arise:
<click>
how to reason about the behaviors of the methods getX(), getY(), and move() of the Point class in isolation of any applicable advice and how to develop reasoning robust to environmental influence.
<click>
In the rely-guarantee context, what rely() condition that will be applicable to any aspect that may act on the methods of Point should we assume?
<click>
Then, how do we show that the behavior of the advice defined in the adjustScale aspect is consistent with the rely() condition imposed by the Point class?
<click>
Also, does the correct functioning of advice require us to impose any conditions on the behaviors of the methods of Point? And if so, how do we go about specifying those conditions?
<click>
Once we have established that, how do we check that the actual behavior of the Point class satisfies the guar() clause?
<click>
And finally, how do we arrive at the resulting behavior that the combined system will exhibit?
The following questions arise:
<click>
how to reason about the behaviors of the methods getX(), getY(), and move() of the Point class in isolation of any applicable advice and how to develop reasoning robust to environmental influence.
<click>
In the rely-guarantee context, what rely() condition that will be applicable to any aspect that may act on the methods of Point should we assume?
<click>
Then, how do we show that the behavior of the advice defined in the adjustScale aspect is consistent with the rely() condition imposed by the Point class?
<click>
Also, does the correct functioning of advice require us to impose any conditions on the behaviors of the methods of Point? And if so, how do we go about specifying those conditions?
<click>
Once we have established that, how do we check that the actual behavior of the Point class satisfies the guar() clause?
<click>
And finally, how do we arrive at the resulting behavior that the combined system will exhibit?
The following questions arise:
<click>
how to reason about the behaviors of the methods getX(), getY(), and move() of the Point class in isolation of any applicable advice and how to develop reasoning robust to environmental influence.
<click>
In the rely-guarantee context, what rely() condition that will be applicable to any aspect that may act on the methods of Point should we assume?
<click>
Then, how do we show that the behavior of the advice defined in the adjustScale aspect is consistent with the rely() condition imposed by the Point class?
<click>
Also, does the correct functioning of advice require us to impose any conditions on the behaviors of the methods of Point? And if so, how do we go about specifying those conditions?
<click>
Once we have established that, how do we check that the actual behavior of the Point class satisfies the guar() clause?
<click>
And finally, how do we arrive at the resulting behavior that the combined system will exhibit?
The following questions arise:
<click>
how to reason about the behaviors of the methods getX(), getY(), and move() of the Point class in isolation of any applicable advice and how to develop reasoning robust to environmental influence.
<click>
In the rely-guarantee context, what rely() condition that will be applicable to any aspect that may act on the methods of Point should we assume?
<click>
Then, how do we show that the behavior of the advice defined in the adjustScale aspect is consistent with the rely() condition imposed by the Point class?
<click>
Also, does the correct functioning of advice require us to impose any conditions on the behaviors of the methods of Point? And if so, how do we go about specifying those conditions?
<click>
Once we have established that, how do we check that the actual behavior of the Point class satisfies the guar() clause?
<click>
And finally, how do we arrive at the resulting behavior that the combined system will exhibit?
The following questions arise:
<click>
how to reason about the behaviors of the methods getX(), getY(), and move() of the Point class in isolation of any applicable advice and how to develop reasoning robust to environmental influence.
<click>
In the rely-guarantee context, what rely() condition that will be applicable to any aspect that may act on the methods of Point should we assume?
<click>
Then, how do we show that the behavior of the advice defined in the adjustScale aspect is consistent with the rely() condition imposed by the Point class?
<click>
Also, does the correct functioning of advice require us to impose any conditions on the behaviors of the methods of Point? And if so, how do we go about specifying those conditions?
<click>
Once we have established that, how do we check that the actual behavior of the Point class satisfies the guar() clause?
<click>
And finally, how do we arrive at the resulting behavior that the combined system will exhibit?