Rely-Guarantee Approach to Reasoning about Aspect-Oriented Programs
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Rely-Guarantee Approach to Reasoning about Aspect-Oriented Programs

on

  • 459 views

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.

Statistics

Views

Total Views
459
Views on SlideShare
459
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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. <br />
  • 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 &apos;-ilities&apos; &#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. <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • 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. <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> 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 <br /> <br /> the coordinates come within a threshold, the scale factor is set accordingly. <br /> <br /> 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. <br />
  • 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> 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 <br /> <br /> the coordinates come within a threshold, the scale factor is set accordingly. <br /> <br /> 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. <br />
  • 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> 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 <br /> <br /> the coordinates come within a threshold, the scale factor is set accordingly. <br /> <br /> 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. <br />
  • 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> 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 <br /> <br /> the coordinates come within a threshold, the scale factor is set accordingly. <br /> <br /> 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. <br />
  • 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> 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 <br /> <br /> the coordinates come within a threshold, the scale factor is set accordingly. <br /> <br /> 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. <br />
  • 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> 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 <br /> <br /> the coordinates come within a threshold, the scale factor is set accordingly. <br /> <br /> 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. <br />
  • 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> 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 <br /> <br /> the coordinates come within a threshold, the scale factor is set accordingly. <br /> <br /> 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. <br />
  • 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> 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 <br /> <br /> the coordinates come within a threshold, the scale factor is set accordingly. <br /> <br /> 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. <br />
  • 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> 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 <br /> <br /> the coordinates come within a threshold, the scale factor is set accordingly. <br /> <br /> 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. <br />
  • 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> 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 <br /> <br /> the coordinates come within a threshold, the scale factor is set accordingly. <br /> <br /> 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. <br />
  • 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> 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 <br /> <br /> the coordinates come within a threshold, the scale factor is set accordingly. <br /> <br /> 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. <br />
  • 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> 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 <br /> <br /> the coordinates come within a threshold, the scale factor is set accordingly. <br /> <br /> 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. <br />
  • The following questions arise: <br /> <br /> 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. <br /> <br /> 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? <br /> <br /> 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? <br /> <br /> 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? <br /> <br /> Once we have established that, how do we check that the actual behavior of the Point class satisfies the guar() clause? <br /> <br /> And finally, how do we arrive at the resulting behavior that the combined system will exhibit? <br /> <br />
  • The following questions arise: <br /> <br /> 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. <br /> <br /> 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? <br /> <br /> 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? <br /> <br /> 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? <br /> <br /> Once we have established that, how do we check that the actual behavior of the Point class satisfies the guar() clause? <br /> <br /> And finally, how do we arrive at the resulting behavior that the combined system will exhibit? <br /> <br />
  • The following questions arise: <br /> <br /> 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. <br /> <br /> 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? <br /> <br /> 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? <br /> <br /> 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? <br /> <br /> Once we have established that, how do we check that the actual behavior of the Point class satisfies the guar() clause? <br /> <br /> And finally, how do we arrive at the resulting behavior that the combined system will exhibit? <br /> <br />
  • The following questions arise: <br /> <br /> 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. <br /> <br /> 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? <br /> <br /> 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? <br /> <br /> 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? <br /> <br /> Once we have established that, how do we check that the actual behavior of the Point class satisfies the guar() clause? <br /> <br /> And finally, how do we arrive at the resulting behavior that the combined system will exhibit? <br /> <br />
  • The following questions arise: <br /> <br /> 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. <br /> <br /> 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? <br /> <br /> 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? <br /> <br /> 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? <br /> <br /> Once we have established that, how do we check that the actual behavior of the Point class satisfies the guar() clause? <br /> <br /> And finally, how do we arrive at the resulting behavior that the combined system will exhibit? <br /> <br />
  • The following questions arise: <br /> <br /> 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. <br /> <br /> 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? <br /> <br /> 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? <br /> <br /> 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? <br /> <br /> Once we have established that, how do we check that the actual behavior of the Point class satisfies the guar() clause? <br /> <br /> And finally, how do we arrive at the resulting behavior that the combined system will exhibit? <br /> <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

Rely-Guarantee Approach to Reasoning about Aspect-Oriented Programs Presentation Transcript

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