Specifying Reusable Aspects

636 views

Published on

Talk at the 5th Asian Workshop on Aspect-Oriented and Modular Software Development (AOAsia \'09) at the 24th International Conference on Automated Software Engineering (ASE \'09), Auckland, New Zealand, November 17, 2009.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
636
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Hello. My name is Raffi Khatchadourian and today I will be presenting joint work done with my advisor at Ohio State University on Specifying Reusable aspects.
  • We all know that programmers can create reusable components in object-oriented system via means such as inheritance, polymorphism, late binding, etc. With inheritance, for example, common functionality is placed in a super class and specific functionality to individual systems is placed in subclasses. Moreover, there are well known and proven techniques available to reason about programs that utilize such mechanisms. In a way, this is OOPs way of separating concerns, and corresponding reasoning techniques include behavioral subtyping, separation logic, etc. If you are not familiar with behavioral subtyping, behavioral subtypes not only extend classes in the syntactic sense, but also override methods in a way that the original specifications are preserved. That way, a call to a method on a super class reference variable results in acceptable behavior even if the reference indeed points to a subclass.
  • We all know that programmers can create reusable components in object-oriented system via means such as inheritance, polymorphism, late binding, etc. With inheritance, for example, common functionality is placed in a super class and specific functionality to individual systems is placed in subclasses. Moreover, there are well known and proven techniques available to reason about programs that utilize such mechanisms. In a way, this is OOPs way of separating concerns, and corresponding reasoning techniques include behavioral subtyping, separation logic, etc. If you are not familiar with behavioral subtyping, behavioral subtypes not only extend classes in the syntactic sense, but also override methods in a way that the original specifications are preserved. That way, a call to a method on a super class reference variable results in acceptable behavior even if the reference indeed points to a subclass.
  • We all know that programmers can create reusable components in object-oriented system via means such as inheritance, polymorphism, late binding, etc. With inheritance, for example, common functionality is placed in a super class and specific functionality to individual systems is placed in subclasses. Moreover, there are well known and proven techniques available to reason about programs that utilize such mechanisms. In a way, this is OOPs way of separating concerns, and corresponding reasoning techniques include behavioral subtyping, separation logic, etc. If you are not familiar with behavioral subtyping, behavioral subtypes not only extend classes in the syntactic sense, but also override methods in a way that the original specifications are preserved. That way, a call to a method on a super class reference variable results in acceptable behavior even if the reference indeed points to a subclass.
  • As we all know, many systems must deal with crosscutting concerns. Furthermore, many crosscutting concerns, for example, synchronization, authentication, persistence, seem to appear in multiple systems. How these particular concerns are manifested in individual systems vary, but certainly common portions exist.
  • As we all know, many systems must deal with crosscutting concerns. Furthermore, many crosscutting concerns, for example, synchronization, authentication, persistence, seem to appear in multiple systems. How these particular concerns are manifested in individual systems vary, but certainly common portions exist.
  • As we all know, many systems must deal with crosscutting concerns. Furthermore, many crosscutting concerns, for example, synchronization, authentication, persistence, seem to appear in multiple systems. How these particular concerns are manifested in individual systems vary, but certainly common portions exist.
  • As we all know, many systems must deal with crosscutting concerns. Furthermore, many crosscutting concerns, for example, synchronization, authentication, persistence, seem to appear in multiple systems. How these particular concerns are manifested in individual systems vary, but certainly common portions exist.
  • As we all know, many systems must deal with crosscutting concerns. Furthermore, many crosscutting concerns, for example, synchronization, authentication, persistence, seem to appear in multiple systems. How these particular concerns are manifested in individual systems vary, but certainly common portions exist.
  • As we all know, many systems must deal with crosscutting concerns. Furthermore, many crosscutting concerns, for example, synchronization, authentication, persistence, seem to appear in multiple systems. How these particular concerns are manifested in individual systems vary, but certainly common portions exist.
  • AOP, in particular, AspectJ, also has facilities to build reusable aspect-oriented components. For example, AspectJ allows developers to declare aspects as abstract. Like abstract classes, abstract aspects are never instatiated. Abstract aspects can mark either pointcuts or advice to be abstract, and these are then filled in by concrete aspects which extend the abstract aspects. Any aspect that declares a method or pointcut to be abstract must itself be abstract. Like base and subclasses, common functionality is captured in abstract aspects and specific functionality in concrete aspects. For example, a system may utilize a library of abstract aspects, each corresponding to various crosscutting concerns, and the system would provide concrete aspects for each crosscutting concern it must deal with.
  • AOP, in particular, AspectJ, also has facilities to build reusable aspect-oriented components. For example, AspectJ allows developers to declare aspects as abstract. Like abstract classes, abstract aspects are never instatiated. Abstract aspects can mark either pointcuts or advice to be abstract, and these are then filled in by concrete aspects which extend the abstract aspects. Any aspect that declares a method or pointcut to be abstract must itself be abstract. Like base and subclasses, common functionality is captured in abstract aspects and specific functionality in concrete aspects. For example, a system may utilize a library of abstract aspects, each corresponding to various crosscutting concerns, and the system would provide concrete aspects for each crosscutting concern it must deal with.
  • AOP, in particular, AspectJ, also has facilities to build reusable aspect-oriented components. For example, AspectJ allows developers to declare aspects as abstract. Like abstract classes, abstract aspects are never instatiated. Abstract aspects can mark either pointcuts or advice to be abstract, and these are then filled in by concrete aspects which extend the abstract aspects. Any aspect that declares a method or pointcut to be abstract must itself be abstract. Like base and subclasses, common functionality is captured in abstract aspects and specific functionality in concrete aspects. For example, a system may utilize a library of abstract aspects, each corresponding to various crosscutting concerns, and the system would provide concrete aspects for each crosscutting concern it must deal with.
  • AOP, in particular, AspectJ, also has facilities to build reusable aspect-oriented components. For example, AspectJ allows developers to declare aspects as abstract. Like abstract classes, abstract aspects are never instatiated. Abstract aspects can mark either pointcuts or advice to be abstract, and these are then filled in by concrete aspects which extend the abstract aspects. Any aspect that declares a method or pointcut to be abstract must itself be abstract. Like base and subclasses, common functionality is captured in abstract aspects and specific functionality in concrete aspects. For example, a system may utilize a library of abstract aspects, each corresponding to various crosscutting concerns, and the system would provide concrete aspects for each crosscutting concern it must deal with.
  • AOP, in particular, AspectJ, also has facilities to build reusable aspect-oriented components. For example, AspectJ allows developers to declare aspects as abstract. Like abstract classes, abstract aspects are never instatiated. Abstract aspects can mark either pointcuts or advice to be abstract, and these are then filled in by concrete aspects which extend the abstract aspects. Any aspect that declares a method or pointcut to be abstract must itself be abstract. Like base and subclasses, common functionality is captured in abstract aspects and specific functionality in concrete aspects. For example, a system may utilize a library of abstract aspects, each corresponding to various crosscutting concerns, and the system would provide concrete aspects for each crosscutting concern it must deal with.
  • AOP, in particular, AspectJ, also has facilities to build reusable aspect-oriented components. For example, AspectJ allows developers to declare aspects as abstract. Like abstract classes, abstract aspects are never instatiated. Abstract aspects can mark either pointcuts or advice to be abstract, and these are then filled in by concrete aspects which extend the abstract aspects. Any aspect that declares a method or pointcut to be abstract must itself be abstract. Like base and subclasses, common functionality is captured in abstract aspects and specific functionality in concrete aspects. For example, a system may utilize a library of abstract aspects, each corresponding to various crosscutting concerns, and the system would provide concrete aspects for each crosscutting concern it must deal with.
  • AOP, in particular, AspectJ, also has facilities to build reusable aspect-oriented components. For example, AspectJ allows developers to declare aspects as abstract. Like abstract classes, abstract aspects are never instatiated. Abstract aspects can mark either pointcuts or advice to be abstract, and these are then filled in by concrete aspects which extend the abstract aspects. Any aspect that declares a method or pointcut to be abstract must itself be abstract. Like base and subclasses, common functionality is captured in abstract aspects and specific functionality in concrete aspects. For example, a system may utilize a library of abstract aspects, each corresponding to various crosscutting concerns, and the system would provide concrete aspects for each crosscutting concern it must deal with.
  • As James had mentioned in his keynote, there is indeed a large body of work on studying how to decipher the effects of aspects on base-code and vice-versa. Particularly, using aspects generally requires global knowledge as previously derived results of the behavior of system components may be invalidated due to an addition of an aspect.

    But what about the case of aspects extending abstract aspects?

    How can we specify these kinds of aspects?

    Moreover, what is the semantic relationship between abstract and concrete aspects? Sure, a concrete abstract can easily syntactically extend a abstract aspect and provide the proper definitions of abstract methods and pointcuts. But, do these concrete aspects provide these definitions in a way that corresponds to the original intent of the abstract aspect designer?
  • As James had mentioned in his keynote, there is indeed a large body of work on studying how to decipher the effects of aspects on base-code and vice-versa. Particularly, using aspects generally requires global knowledge as previously derived results of the behavior of system components may be invalidated due to an addition of an aspect.

    But what about the case of aspects extending abstract aspects?

    How can we specify these kinds of aspects?

    Moreover, what is the semantic relationship between abstract and concrete aspects? Sure, a concrete abstract can easily syntactically extend a abstract aspect and provide the proper definitions of abstract methods and pointcuts. But, do these concrete aspects provide these definitions in a way that corresponds to the original intent of the abstract aspect designer?
  • As James had mentioned in his keynote, there is indeed a large body of work on studying how to decipher the effects of aspects on base-code and vice-versa. Particularly, using aspects generally requires global knowledge as previously derived results of the behavior of system components may be invalidated due to an addition of an aspect.

    But what about the case of aspects extending abstract aspects?

    How can we specify these kinds of aspects?

    Moreover, what is the semantic relationship between abstract and concrete aspects? Sure, a concrete abstract can easily syntactically extend a abstract aspect and provide the proper definitions of abstract methods and pointcuts. But, do these concrete aspects provide these definitions in a way that corresponds to the original intent of the abstract aspect designer?
  • As James had mentioned in his keynote, there is indeed a large body of work on studying how to decipher the effects of aspects on base-code and vice-versa. Particularly, using aspects generally requires global knowledge as previously derived results of the behavior of system components may be invalidated due to an addition of an aspect.

    But what about the case of aspects extending abstract aspects?

    How can we specify these kinds of aspects?

    Moreover, what is the semantic relationship between abstract and concrete aspects? Sure, a concrete abstract can easily syntactically extend a abstract aspect and provide the proper definitions of abstract methods and pointcuts. But, do these concrete aspects provide these definitions in a way that corresponds to the original intent of the abstract aspect designer?






  • So, let’s take a look at a popular example, namely, the Observer pattern, which is commonly used in GUI applications. If you not already familiar with the details of this pattern, I will provide a brief overview here. Basically, the situation is such that many objects are interested in changes to the state of a particular object. We call this a subject. Note that in the general case, the same observer may be interested in multiple subjects, but we’ll consider the general case here.

    To express its interest, an object registers itself with a subject as an observer. This means that it will receive notifications upon “significant” modifications to the state of the subject. The term significant is used here in the general sense, significant modifications may vary between systems and even subjects. The end idea is that the observer is not responsible itself for deciding when a subject has changed.

    This protocol consistutes a crosscutting concern as state changes to the subject may be scattered throughout the source code, and moreover, notifications of state changes may be tangled with the core functionality of the subject.

    Once the subject is notified of significant changes being made to it, it proceeds to update registered observers, so they may update their own state to be consistent with that of the subject.
  • So, let’s take a look at a popular example, namely, the Observer pattern, which is commonly used in GUI applications. If you not already familiar with the details of this pattern, I will provide a brief overview here. Basically, the situation is such that many objects are interested in changes to the state of a particular object. We call this a subject. Note that in the general case, the same observer may be interested in multiple subjects, but we’ll consider the general case here.

    To express its interest, an object registers itself with a subject as an observer. This means that it will receive notifications upon “significant” modifications to the state of the subject. The term significant is used here in the general sense, significant modifications may vary between systems and even subjects. The end idea is that the observer is not responsible itself for deciding when a subject has changed.

    This protocol consistutes a crosscutting concern as state changes to the subject may be scattered throughout the source code, and moreover, notifications of state changes may be tangled with the core functionality of the subject.

    Once the subject is notified of significant changes being made to it, it proceeds to update registered observers, so they may update their own state to be consistent with that of the subject.
  • So, let’s take a look at a popular example, namely, the Observer pattern, which is commonly used in GUI applications. If you not already familiar with the details of this pattern, I will provide a brief overview here. Basically, the situation is such that many objects are interested in changes to the state of a particular object. We call this a subject. Note that in the general case, the same observer may be interested in multiple subjects, but we’ll consider the general case here.

    To express its interest, an object registers itself with a subject as an observer. This means that it will receive notifications upon “significant” modifications to the state of the subject. The term significant is used here in the general sense, significant modifications may vary between systems and even subjects. The end idea is that the observer is not responsible itself for deciding when a subject has changed.

    This protocol consistutes a crosscutting concern as state changes to the subject may be scattered throughout the source code, and moreover, notifications of state changes may be tangled with the core functionality of the subject.

    Once the subject is notified of significant changes being made to it, it proceeds to update registered observers, so they may update their own state to be consistent with that of the subject.
  • So, let’s take a look at a popular example, namely, the Observer pattern, which is commonly used in GUI applications. If you not already familiar with the details of this pattern, I will provide a brief overview here. Basically, the situation is such that many objects are interested in changes to the state of a particular object. We call this a subject. Note that in the general case, the same observer may be interested in multiple subjects, but we’ll consider the general case here.

    To express its interest, an object registers itself with a subject as an observer. This means that it will receive notifications upon “significant” modifications to the state of the subject. The term significant is used here in the general sense, significant modifications may vary between systems and even subjects. The end idea is that the observer is not responsible itself for deciding when a subject has changed.

    This protocol consistutes a crosscutting concern as state changes to the subject may be scattered throughout the source code, and moreover, notifications of state changes may be tangled with the core functionality of the subject.

    Once the subject is notified of significant changes being made to it, it proceeds to update registered observers, so they may update their own state to be consistent with that of the subject.
  • So, let’s take a look at a popular example, namely, the Observer pattern, which is commonly used in GUI applications. If you not already familiar with the details of this pattern, I will provide a brief overview here. Basically, the situation is such that many objects are interested in changes to the state of a particular object. We call this a subject. Note that in the general case, the same observer may be interested in multiple subjects, but we’ll consider the general case here.

    To express its interest, an object registers itself with a subject as an observer. This means that it will receive notifications upon “significant” modifications to the state of the subject. The term significant is used here in the general sense, significant modifications may vary between systems and even subjects. The end idea is that the observer is not responsible itself for deciding when a subject has changed.

    This protocol consistutes a crosscutting concern as state changes to the subject may be scattered throughout the source code, and moreover, notifications of state changes may be tangled with the core functionality of the subject.

    Once the subject is notified of significant changes being made to it, it proceeds to update registered observers, so they may update their own state to be consistent with that of the subject.
  • So, let’s take a look at a popular example, namely, the Observer pattern, which is commonly used in GUI applications. If you not already familiar with the details of this pattern, I will provide a brief overview here. Basically, the situation is such that many objects are interested in changes to the state of a particular object. We call this a subject. Note that in the general case, the same observer may be interested in multiple subjects, but we’ll consider the general case here.

    To express its interest, an object registers itself with a subject as an observer. This means that it will receive notifications upon “significant” modifications to the state of the subject. The term significant is used here in the general sense, significant modifications may vary between systems and even subjects. The end idea is that the observer is not responsible itself for deciding when a subject has changed.

    This protocol consistutes a crosscutting concern as state changes to the subject may be scattered throughout the source code, and moreover, notifications of state changes may be tangled with the core functionality of the subject.

    Once the subject is notified of significant changes being made to it, it proceeds to update registered observers, so they may update their own state to be consistent with that of the subject.
  • So, let’s take a look at a popular example, namely, the Observer pattern, which is commonly used in GUI applications. If you not already familiar with the details of this pattern, I will provide a brief overview here. Basically, the situation is such that many objects are interested in changes to the state of a particular object. We call this a subject. Note that in the general case, the same observer may be interested in multiple subjects, but we’ll consider the general case here.

    To express its interest, an object registers itself with a subject as an observer. This means that it will receive notifications upon “significant” modifications to the state of the subject. The term significant is used here in the general sense, significant modifications may vary between systems and even subjects. The end idea is that the observer is not responsible itself for deciding when a subject has changed.

    This protocol consistutes a crosscutting concern as state changes to the subject may be scattered throughout the source code, and moreover, notifications of state changes may be tangled with the core functionality of the subject.

    Once the subject is notified of significant changes being made to it, it proceeds to update registered observers, so they may update their own state to be consistent with that of the subject.
  • So, let’s take a look at a popular example, namely, the Observer pattern, which is commonly used in GUI applications. If you not already familiar with the details of this pattern, I will provide a brief overview here. Basically, the situation is such that many objects are interested in changes to the state of a particular object. We call this a subject. Note that in the general case, the same observer may be interested in multiple subjects, but we’ll consider the general case here.

    To express its interest, an object registers itself with a subject as an observer. This means that it will receive notifications upon “significant” modifications to the state of the subject. The term significant is used here in the general sense, significant modifications may vary between systems and even subjects. The end idea is that the observer is not responsible itself for deciding when a subject has changed.

    This protocol consistutes a crosscutting concern as state changes to the subject may be scattered throughout the source code, and moreover, notifications of state changes may be tangled with the core functionality of the subject.

    Once the subject is notified of significant changes being made to it, it proceeds to update registered observers, so they may update their own state to be consistent with that of the subject.
  • As the observer pattern can be applied to many kinds of systems, we will encapsulate common portions of the pattern in a abstract aspect. This example was derived from one provided in a Clarke & Walker article in the AOSD book.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • First, we will declare a few types that pertain to the observer pattern, specifically, a subject interface, which is used as a marker, and an observer interface, which contains a single method called update. This method will be called when the subject is notified of its changes.

    Next, we will introduce a list of observers to a particular subject. You can do this in AspectJ as displayed.

    For completeness, we’ll add back pointers from Observers to the subjects they are interested in.

    We’ll also introduce a notify method for subjects and also provide an implementation. Basically, when the subject is notified of changes, it will in turn call update on all registered observers.
  • Next, we’ll declare an abstract pointcut called subjectModified, which is meant to capture all join points following significant changes to the subject’s state.

    We’ll also declare an attach abstract pointcut, which is meant to capture the points where observers register themselves with the subject.

    For completeness, we would also have a detach or unregister method to be called when particular observers are no longer interested in their subjects. Note that the definitions of these pointcuts are not provided here but instead will be provide in the concrete aspects tailored for individual systems as these concepts may vary in those systems.
  • Next, we’ll declare an abstract pointcut called subjectModified, which is meant to capture all join points following significant changes to the subject’s state.

    We’ll also declare an attach abstract pointcut, which is meant to capture the points where observers register themselves with the subject.

    For completeness, we would also have a detach or unregister method to be called when particular observers are no longer interested in their subjects. Note that the definitions of these pointcuts are not provided here but instead will be provide in the concrete aspects tailored for individual systems as these concepts may vary in those systems.
  • Next, we’ll declare an abstract pointcut called subjectModified, which is meant to capture all join points following significant changes to the subject’s state.

    We’ll also declare an attach abstract pointcut, which is meant to capture the points where observers register themselves with the subject.

    For completeness, we would also have a detach or unregister method to be called when particular observers are no longer interested in their subjects. Note that the definitions of these pointcuts are not provided here but instead will be provide in the concrete aspects tailored for individual systems as these concepts may vary in those systems.
  • Next, we’ll declare an abstract pointcut called subjectModified, which is meant to capture all join points following significant changes to the subject’s state.

    We’ll also declare an attach abstract pointcut, which is meant to capture the points where observers register themselves with the subject.

    For completeness, we would also have a detach or unregister method to be called when particular observers are no longer interested in their subjects. Note that the definitions of these pointcuts are not provided here but instead will be provide in the concrete aspects tailored for individual systems as these concepts may vary in those systems.
  • Abstract aspects in AspectJ are allowed to declare concrete advice. As such, we will have an advice body that following points where the subject is modified, will notify the subject of the change. Moreover, following points where observers are to be registered with the subjects, we’ll go ahead an add the particular observer to the subject’s list of registered observers.
  • Abstract aspects in AspectJ are allowed to declare concrete advice. As such, we will have an advice body that following points where the subject is modified, will notify the subject of the change. Moreover, following points where observers are to be registered with the subjects, we’ll go ahead an add the particular observer to the subject’s list of registered observers.
  • Abstract aspects in AspectJ are allowed to declare concrete advice. As such, we will have an advice body that following points where the subject is modified, will notify the subject of the change. Moreover, following points where observers are to be registered with the subjects, we’ll go ahead an add the particular observer to the subject’s list of registered observers.
  • Abstract aspects in AspectJ are allowed to declare concrete advice. As such, we will have an advice body that following points where the subject is modified, will notify the subject of the change. Moreover, following points where observers are to be registered with the subjects, we’ll go ahead an add the particular observer to the subject’s list of registered observers.
  • Abstract aspects in AspectJ are allowed to declare concrete advice. As such, we will have an advice body that following points where the subject is modified, will notify the subject of the change. Moreover, following points where observers are to be registered with the subjects, we’ll go ahead an add the particular observer to the subject’s list of registered observers.
  • So how would we go about specifying this abstract abstract? The insight is as follows.

    Many reusable aspects correspond to implementations of design pattern, like the observer pattern being discussed here. In fact, there is a fair amount of literature in using AOP to implement design patterns, and since design patterns are meant to be in a way reusable, usually an abstract aspect is involved in the implementation.

    In general, design patterns are descriptions of widely accepted solutions to common problems.

    When you apply a pattern to the system, you tailor it to the specific needs of that system.

    This sounds a lot like the situation we have with reusable aspects. Our idea is then to adopt reasoning techniques for design patterns to reason about reusable aspects.
  • So how would we go about specifying this abstract abstract? The insight is as follows.

    Many reusable aspects correspond to implementations of design pattern, like the observer pattern being discussed here. In fact, there is a fair amount of literature in using AOP to implement design patterns, and since design patterns are meant to be in a way reusable, usually an abstract aspect is involved in the implementation.

    In general, design patterns are descriptions of widely accepted solutions to common problems.

    When you apply a pattern to the system, you tailor it to the specific needs of that system.

    This sounds a lot like the situation we have with reusable aspects. Our idea is then to adopt reasoning techniques for design patterns to reason about reusable aspects.
  • So how would we go about specifying this abstract abstract? The insight is as follows.

    Many reusable aspects correspond to implementations of design pattern, like the observer pattern being discussed here. In fact, there is a fair amount of literature in using AOP to implement design patterns, and since design patterns are meant to be in a way reusable, usually an abstract aspect is involved in the implementation.

    In general, design patterns are descriptions of widely accepted solutions to common problems.

    When you apply a pattern to the system, you tailor it to the specific needs of that system.

    This sounds a lot like the situation we have with reusable aspects. Our idea is then to adopt reasoning techniques for design patterns to reason about reusable aspects.
  • So how would we go about specifying this abstract abstract? The insight is as follows.

    Many reusable aspects correspond to implementations of design pattern, like the observer pattern being discussed here. In fact, there is a fair amount of literature in using AOP to implement design patterns, and since design patterns are meant to be in a way reusable, usually an abstract aspect is involved in the implementation.

    In general, design patterns are descriptions of widely accepted solutions to common problems.

    When you apply a pattern to the system, you tailor it to the specific needs of that system.

    This sounds a lot like the situation we have with reusable aspects. Our idea is then to adopt reasoning techniques for design patterns to reason about reusable aspects.
  • Now that we have seen the abstract aspect corresponding to the observer pattern, as well as the syntactic requirements a concrete aspect must follow, e.g., providing the concrete definition of the attach() pointcut, what would be the semantic requirements for an aspect extending the observing aspect? Are there any semantic restrictions what would need to be placed on the pointcut definitions?
  • Well, let’s revisit our initial description of the design pattern. We said that following the subjectModified pointcut should capture significant changes to subjects. Well, what a significant change means can vary between applications of the pattern, so …

    We will create an abstract predicate called modified with takes two arguments, namely, two subjects and evaluates to true iff subject 1 is significantly different than subject 2. Like abstract methods and pointcuts, the definition of this predicate will be provided by the specifications of concrete aspects (as we’ll see later).
  • Well, let’s revisit our initial description of the design pattern. We said that following the subjectModified pointcut should capture significant changes to subjects. Well, what a significant change means can vary between applications of the pattern, so …

    We will create an abstract predicate called modified with takes two arguments, namely, two subjects and evaluates to true iff subject 1 is significantly different than subject 2. Like abstract methods and pointcuts, the definition of this predicate will be provided by the specifications of concrete aspects (as we’ll see later).
  • Well, let’s revisit our initial description of the design pattern. We said that following the subjectModified pointcut should capture significant changes to subjects. Well, what a significant change means can vary between applications of the pattern, so …

    We will create an abstract predicate called modified with takes two arguments, namely, two subjects and evaluates to true iff subject 1 is significantly different than subject 2. Like abstract methods and pointcuts, the definition of this predicate will be provided by the specifications of concrete aspects (as we’ll see later).
  • Well, let’s revisit our initial description of the design pattern. We said that following the subjectModified pointcut should capture significant changes to subjects. Well, what a significant change means can vary between applications of the pattern, so …

    We will create an abstract predicate called modified with takes two arguments, namely, two subjects and evaluates to true iff subject 1 is significantly different than subject 2. Like abstract methods and pointcuts, the definition of this predicate will be provided by the specifications of concrete aspects (as we’ll see later).
  • Well, let’s revisit our initial description of the design pattern. We said that following the subjectModified pointcut should capture significant changes to subjects. Well, what a significant change means can vary between applications of the pattern, so …

    We will create an abstract predicate called modified with takes two arguments, namely, two subjects and evaluates to true iff subject 1 is significantly different than subject 2. Like abstract methods and pointcuts, the definition of this predicate will be provided by the specifications of concrete aspects (as we’ll see later).
  • Well, let’s revisit our initial description of the design pattern. We said that following the subjectModified pointcut should capture significant changes to subjects. Well, what a significant change means can vary between applications of the pattern, so …

    We will create an abstract predicate called modified with takes two arguments, namely, two subjects and evaluates to true iff subject 1 is significantly different than subject 2. Like abstract methods and pointcuts, the definition of this predicate will be provided by the specifications of concrete aspects (as we’ll see later).
  • OK, we also said that observers are updated to be consistent with the state of the subject once a significant change has been made. Consistency may also vary between applications of the pattern. For example, observers may only be interest in a portion of the subject’s state.

    For this, we will also provide an abstract predicate, this time one taking a subject and an observer. This will also be provided by the concrete aspects.

    We’ll next use this predicate to more or less formalize our informal description of the pattern. To do so, we’ll provide pre- and post-conditions for the subjModified advice which assert properties about the system that must be true before and after the advice executes, respectively. We don’t need to make any assumptions prior to the advice execution, so we’ll leave the precondition are true, meaning to restrictions are necessarly.

    However, we will assert that after a subject has been modified that each attached or registered observer is indeed Consistent with the subject. The definition of what consistency means for the specific system utilizing this reusable aspect will be more or less plugged in here. Also note that I have taken the liberty to utilize a pseudo-code for the examples. A formal assertion language is the subject of future work.
  • OK, we also said that observers are updated to be consistent with the state of the subject once a significant change has been made. Consistency may also vary between applications of the pattern. For example, observers may only be interest in a portion of the subject’s state.

    For this, we will also provide an abstract predicate, this time one taking a subject and an observer. This will also be provided by the concrete aspects.

    We’ll next use this predicate to more or less formalize our informal description of the pattern. To do so, we’ll provide pre- and post-conditions for the subjModified advice which assert properties about the system that must be true before and after the advice executes, respectively. We don’t need to make any assumptions prior to the advice execution, so we’ll leave the precondition are true, meaning to restrictions are necessarly.

    However, we will assert that after a subject has been modified that each attached or registered observer is indeed Consistent with the subject. The definition of what consistency means for the specific system utilizing this reusable aspect will be more or less plugged in here. Also note that I have taken the liberty to utilize a pseudo-code for the examples. A formal assertion language is the subject of future work.
  • OK, we also said that observers are updated to be consistent with the state of the subject once a significant change has been made. Consistency may also vary between applications of the pattern. For example, observers may only be interest in a portion of the subject’s state.

    For this, we will also provide an abstract predicate, this time one taking a subject and an observer. This will also be provided by the concrete aspects.

    We’ll next use this predicate to more or less formalize our informal description of the pattern. To do so, we’ll provide pre- and post-conditions for the subjModified advice which assert properties about the system that must be true before and after the advice executes, respectively. We don’t need to make any assumptions prior to the advice execution, so we’ll leave the precondition are true, meaning to restrictions are necessarly.

    However, we will assert that after a subject has been modified that each attached or registered observer is indeed Consistent with the subject. The definition of what consistency means for the specific system utilizing this reusable aspect will be more or less plugged in here. Also note that I have taken the liberty to utilize a pseudo-code for the examples. A formal assertion language is the subject of future work.
  • OK, we also said that observers are updated to be consistent with the state of the subject once a significant change has been made. Consistency may also vary between applications of the pattern. For example, observers may only be interest in a portion of the subject’s state.

    For this, we will also provide an abstract predicate, this time one taking a subject and an observer. This will also be provided by the concrete aspects.

    We’ll next use this predicate to more or less formalize our informal description of the pattern. To do so, we’ll provide pre- and post-conditions for the subjModified advice which assert properties about the system that must be true before and after the advice executes, respectively. We don’t need to make any assumptions prior to the advice execution, so we’ll leave the precondition are true, meaning to restrictions are necessarly.

    However, we will assert that after a subject has been modified that each attached or registered observer is indeed Consistent with the subject. The definition of what consistency means for the specific system utilizing this reusable aspect will be more or less plugged in here. Also note that I have taken the liberty to utilize a pseudo-code for the examples. A formal assertion language is the subject of future work.
  • OK, we also said that observers are updated to be consistent with the state of the subject once a significant change has been made. Consistency may also vary between applications of the pattern. For example, observers may only be interest in a portion of the subject’s state.

    For this, we will also provide an abstract predicate, this time one taking a subject and an observer. This will also be provided by the concrete aspects.

    We’ll next use this predicate to more or less formalize our informal description of the pattern. To do so, we’ll provide pre- and post-conditions for the subjModified advice which assert properties about the system that must be true before and after the advice executes, respectively. We don’t need to make any assumptions prior to the advice execution, so we’ll leave the precondition are true, meaning to restrictions are necessarly.

    However, we will assert that after a subject has been modified that each attached or registered observer is indeed Consistent with the subject. The definition of what consistency means for the specific system utilizing this reusable aspect will be more or less plugged in here. Also note that I have taken the liberty to utilize a pseudo-code for the examples. A formal assertion language is the subject of future work.
  • OK, we also said that observers are updated to be consistent with the state of the subject once a significant change has been made. Consistency may also vary between applications of the pattern. For example, observers may only be interest in a portion of the subject’s state.

    For this, we will also provide an abstract predicate, this time one taking a subject and an observer. This will also be provided by the concrete aspects.

    We’ll next use this predicate to more or less formalize our informal description of the pattern. To do so, we’ll provide pre- and post-conditions for the subjModified advice which assert properties about the system that must be true before and after the advice executes, respectively. We don’t need to make any assumptions prior to the advice execution, so we’ll leave the precondition are true, meaning to restrictions are necessarly.

    However, we will assert that after a subject has been modified that each attached or registered observer is indeed Consistent with the subject. The definition of what consistency means for the specific system utilizing this reusable aspect will be more or less plugged in here. Also note that I have taken the liberty to utilize a pseudo-code for the examples. A formal assertion language is the subject of future work.
  • OK, we also said that observers are updated to be consistent with the state of the subject once a significant change has been made. Consistency may also vary between applications of the pattern. For example, observers may only be interest in a portion of the subject’s state.

    For this, we will also provide an abstract predicate, this time one taking a subject and an observer. This will also be provided by the concrete aspects.

    We’ll next use this predicate to more or less formalize our informal description of the pattern. To do so, we’ll provide pre- and post-conditions for the subjModified advice which assert properties about the system that must be true before and after the advice executes, respectively. We don’t need to make any assumptions prior to the advice execution, so we’ll leave the precondition are true, meaning to restrictions are necessarly.

    However, we will assert that after a subject has been modified that each attached or registered observer is indeed Consistent with the subject. The definition of what consistency means for the specific system utilizing this reusable aspect will be more or less plugged in here. Also note that I have taken the liberty to utilize a pseudo-code for the examples. A formal assertion language is the subject of future work.









































  • Specifying Reusable Aspects

    1. 1. Specifying Reusable Aspects Neelam Soundarajan and Raffi Khatchadourian Department of Computer Science & Engineering Ohio State University Columbus, OH USA
    2. 2. Reuse in Object-Oriented Programming
    3. 3. Reuse in Object-Oriented Programming • Object-Oriented Programming promotes reuse through mechanisms such as inheritance and polymorphism.
    4. 4. Reuse in Object-Oriented Programming • Object-Oriented Programming promotes reuse through mechanisms such as inheritance and polymorphism. • Well-known, proven techniques exist to effectively reason about OOP.
    5. 5. Reuse in Object-Oriented Programming • Object-Oriented Programming promotes reuse through mechanisms such as inheritance and polymorphism. • Well-known, proven techniques exist to effectively reason about OOP. Behavioral subtyping, separation logic, etc.
    6. 6. Common Crosscutting Concerns
    7. 7. Common Crosscutting Concerns • Many systems must deal with crosscutting concerns.
    8. 8. Common Crosscutting Concerns • Many systems must deal with crosscutting concerns. • Many crosscutting concerns appear in multiple systems.
    9. 9. Common Crosscutting Concerns Synchronization, authentication, etc. • Many systems must deal with crosscutting concerns. • Many crosscutting concerns appear in multiple systems.
    10. 10. Common Crosscutting Concerns • Many systems must deal with crosscutting concerns. • Many crosscutting concerns appear in multiple systems. • Application of these concerns vary in individual systems.
    11. 11. Common Crosscutting Concerns • Many systems must deal with crosscutting concerns. • Many crosscutting concerns appear in multiple systems. • Application of these concerns vary in individual systems. Many portions are similar.
    12. 12. Reuse in Aspect-Oriented Programming
    13. 13. Reuse in Aspect-Oriented Programming • AOP also promotes reuse through abstract aspects.
    14. 14. Reuse in Aspect-Oriented Programming Limited form of inheritance • AOP also promotes reuse through abstract aspects.
    15. 15. Reuse in Aspect-Oriented Programming • AOP also promotes reuse through abstract aspects. • Common portions of crosscutting concern implementations are localized in aspects that are declared as abstract.
    16. 16. Reuse in Aspect-Oriented Programming • AOP also promotes reuse through abstract aspects. • Common portions of crosscutting concern implementations are localized in aspects that are declared as abstract. Can be used in many systems
    17. 17. Reuse in Aspect-Oriented Programming • AOP also promotes reuse through abstract aspects. • Common portions of crosscutting concern implementations are localized in aspects that are declared as abstract. • Portions specific to individual systems are localized in concrete aspects that extend the abstract aspects.
    18. 18. Reasoning about Reusable Aspects
    19. 19. Reasoning about Reusable Aspects • Large body of work on reasoning about how base- code is affected by aspects and vice-versa.
    20. 20. Reasoning about Reusable Aspects • Large body of work on reasoning about how base- code is affected by aspects and vice-versa. • What if an aspect extends an abstract aspect?
    21. 21. Reasoning about Reusable Aspects • Large body of work on reasoning about how base- code is affected by aspects and vice-versa. • What if an aspect extends an abstract aspect? • What should behavioral specifications of abstract aspects look like?
    22. 22. Reasoning about Reusable Aspects • Large body of work on reasoning about how base- code is affected by aspects and vice-versa. • What if an aspect extends an abstract aspect? • What should behavioral specifications of abstract aspects look like? • What is the relationship between specifications of abstract aspects and that of concrete aspects?
    23. 23. Motivating Example: Observer Protocol
    24. 24. Motivating Example: Observer Protocol • Many objects are interested in changes to the state of a subject object.
    25. 25. Motivating Example: Observer Protocol • Many objects are interested in changes to the state of a subject object. • Each object registers itself with a subject as an observer.
    26. 26. Motivating Example: Observer Protocol • Many objects are interested in changes to the state of a subject object. • Each object registers itself with a subject as an observer. • Following significant state modifications, the subject notifies registered observers.
    27. 27. Motivating Example: Observer Protocol • Many objects are interested in changes to the state of a subject object. • Each object registers itself with a subject as an observer. Scattered • Following significant state modifications, the subject notifies registered observers.
    28. 28. Motivating Example: Observer Protocol • Many objects are interested in changes to the state of a subject object. • Each object registers itself with a subject as an observer. Scattered • Following significant state modifications, the subject notifies registered observers. Tangled
    29. 29. Motivating Example: Observer Protocol • Many objects are interested in changes to the state of a subject object. • Each object registers itself with a subject as an observer. • Following significant state modifications, the subject notifies registered observers. • Observers are then updated to be consistent with the state of the subject.
    30. 30. Motivating Example: Observer Protocol public abstract aspect Observing
    31. 31. Motivating Example: Observer Protocol public abstract aspect Observing
    32. 32. Motivating Example: Observer Protocol public abstract aspect Observing { }
    33. 33. Motivating Example: Observer Protocol public abstract aspect Observing { interface Subject {} Type declarations }
    34. 34. Motivating Example: Observer Protocol public abstract aspect Observing { interface Subject {} Type interface Observer { declarations } }
    35. 35. Motivating Example: Observer Protocol public abstract aspect Observing { interface Subject {} Type interface Observer { declarations public void update(); } }
    36. 36. Motivating Example: Observer Protocol public abstract aspect Observing { interface Subject {} interface Observer { public void update(); Introductions } List<Observer> Subject.observers; }
    37. 37. Motivating Example: Observer Protocol public abstract aspect Observing { interface Subject {} interface Observer { public void update(); Introductions } List<Observer> Subject.observers; List<Subject> Observer.subjects; }
    38. 38. Motivating Example: Observer Protocol public abstract aspect Observing { interface Subject {} interface Observer { public void update(); } List<Observer> Subject.observers; List<Subject> Observer.subjects; private void Subject.notify() { } }
    39. 39. Motivating Example: Observer Protocol public abstract aspect Observing { interface Subject {} interface Observer { public void update(); } List<Observer> Subject.observers; List<Subject> Observer.subjects; private void Subject.notify() { for (Observer obs : observers) obs.update(); } }
    40. 40. Motivating Example: Observer Protocol public abstract aspect Observing { }
    41. 41. Motivating Example: Observer Protocol public abstract aspect Observing { Pointcuts abstract pointcut subjMod(Subject s); }
    42. 42. Motivating Example: Observer Protocol public abstract aspect Observing { Pointcuts abstract pointcut subjMod(Subject s); abstract pointcut attach(Observer o, Subject s); }
    43. 43. Motivating Example: Observer Protocol public abstract aspect Observing { Pointcuts abstract pointcut subjMod(Subject s); abstract pointcut attach(Observer o, Subject s); detach is similar }
    44. 44. Motivating Example: Observer Protocol public abstract aspect Observing { }
    45. 45. Motivating Example: Observer Protocol public abstract aspect Observing { Advice after(Subject s): subjMod(s){ } }
    46. 46. Motivating Example: Observer Protocol public abstract aspect Observing { Advice after(Subject s): subjMod(s){ s.notify(); } }
    47. 47. Motivating Example: Observer Protocol public abstract aspect Observing { Advice after(Subject s): subjMod(s){ s.notify(); } after(Observer o, Subject s) : attach(o, s){ } }
    48. 48. Motivating Example: Observer Protocol public abstract aspect Observing { Advice after(Subject s): subjMod(s){ s.notify(); } after(Observer o, Subject s) : attach(o, s){ s.observers.add(o); } }
    49. 49. Specifying Reusable Aspects
    50. 50. Specifying Reusable Aspects • Many reusable aspects correspond to design patterns.
    51. 51. Specifying Reusable Aspects • Many reusable aspects correspond to design patterns. • Design patterns are general descriptions of widely accepted software practices for common problems.
    52. 52. Specifying Reusable Aspects • Many reusable aspects correspond to design patterns. • Design patterns are general descriptions of widely accepted software practices for common problems. • Patterns are customized for specific systems.
    53. 53. Specifying Reusable Aspects • Many reusable aspects correspond to design patterns. • Design patterns are general descriptions of widely accepted software practices for common problems. • Patterns are customized for specific systems. • Adopt techniques for reasoning about design patterns to reasoning about reusable aspects.
    54. 54. What are the behavioral requirements for a concrete aspect to correctly extend the Observing aspect?
    55. 55. What are the behavioral requirements for a concrete aspect to correctly extend the Observing aspect?
    56. 56. What are the behavioral requirements for a concrete aspect to correctly extend the Observing aspect? • Following significant state modifications, the subject notifies registered observers.
    57. 57. What are the behavioral requirements for a concrete aspect to correctly extend the Observing aspect? • Following significant state modifications, the subject notifies registered observers. /∗@ abstract boolean Modified(Subject s1, Subject s2); @∗/
    58. 58. What are the behavioral requirements for a concrete aspect to correctly extend the Observing aspect?
    59. 59. What are the behavioral requirements for a concrete aspect to correctly extend the Observing aspect?
    60. 60. What are the behavioral requirements for a concrete aspect to correctly extend the Observing aspect? • Observers are then updated to be consistent with the state of the subject.
    61. 61. What are the behavioral requirements for a concrete aspect to correctly extend the Observing aspect? • Observers are then updated to be consistent with the state of the subject. /∗@abstract boolean Consistent(Subject s, Observer o); @∗/
    62. 62. What are the behavioral requirements for a concrete aspect to correctly extend the Observing aspect? • Observers are then updated to be consistent with the state of the subject. /∗@abstract boolean Consistent(Subject s, Observer o); @∗/ after(Subject s) : subjMod(s);
    63. 63. What are the behavioral requirements for a concrete aspect to correctly extend the Observing aspect? • Observers are then updated to be consistent with the state of the subject. /∗@abstract boolean Consistent(Subject s, Observer o); @∗/ /*@pre: true *@/ after(Subject s) : subjMod(s);
    64. 64. What are the behavioral requirements for a concrete aspect to correctly extend the Observing aspect? • Observers are then updated to be consistent with the state of the subject. /∗@abstract boolean Consistent(Subject s, Observer o); @∗/ /*@pre: true *@/ after(Subject s) : subjMod(s); /∗@post: ∀ob ∈ s.observers :
    65. 65. What are the behavioral requirements for a concrete aspect to correctly extend the Observing aspect? • Observers are then updated to be consistent with the state of the subject. /∗@abstract boolean Consistent(Subject s, Observer o); @∗/ /*@pre: true *@/ after(Subject s) : subjMod(s); /∗@post: ∀ob ∈ s.observers : Consistent(s, ob)@∗/
    66. 66. A Concrete Aspect: Library Observing public aspect LibraryObserving
    67. 67. A Concrete Aspect: Library Observing public aspect LibraryObserving
    68. 68. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { }
    69. 69. A Concrete Aspect: Library Observing public aspect LibraryObserving Inter-type extends Observing { declarations declare parents: BookCopy implements Subject; }
    70. 70. A Concrete Aspect: Library Observing public aspect LibraryObserving Inter-type extends Observing { declarations declare parents: BookCopy implements Subject; declare parents: BookMan implements Observer; }
    71. 71. A Concrete Aspect: Library Observing public aspect LibraryObserving Inter-type extends Observing { declarations declare parents: BookCopy implements Subject; declare parents: BookMan implements Observer; public void BookMan.update() {...} }
    72. 72. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { declare parents: BookCopy implements Subject; declare parents: BookMan implements Observer; public void BookMan.update() {...} }
    73. 73. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { }
    74. 74. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { Pointcuts pointcut subjMod(Subject copy): }
    75. 75. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { Pointcuts pointcut subjMod(Subject copy): (execution(* BookCopy.bkBorrow(..))|| }
    76. 76. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { Pointcuts pointcut subjMod(Subject copy): (execution(* BookCopy.bkBorrow(..))|| execution(* BookCopy.bkReturn(..)))&& }
    77. 77. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { Pointcuts pointcut subjMod(Subject copy): (execution(* BookCopy.bkBorrow(..))|| execution(* BookCopy.bkReturn(..)))&& target(copy) && args(..); }
    78. 78. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { Pointcuts pointcut subjMod(Subject copy): (execution(* BookCopy.bkBorrow(..))|| execution(* BookCopy.bkReturn(..)))&& target(copy) && args(..); pointcut attach(): //... }
    79. 79. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { Pointcuts pointcut subjMod(Subject copy): (execution(* BookCopy.bkBorrow(..))|| execution(* BookCopy.bkReturn(..)))&& target(copy) && args(..); pointcut attach(): //... pointcut detach(): //... }
    80. 80. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { Pointcuts pointcut subjMod(Subject copy): (execution(* BookCopy.bkBorrow(..))|| execution(* BookCopy.bkReturn(..)))&& target(copy) && args(..); pointcut attach(): //... Predicate pointcut detach(): //... definitions /∗@ Modified(s1,s2): ... @∗/ }
    81. 81. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { Pointcuts pointcut subjMod(Subject copy): (execution(* BookCopy.bkBorrow(..))|| execution(* BookCopy.bkReturn(..)))&& target(copy) && args(..); pointcut attach(): //... Predicate pointcut detach(): //... definitions /∗@ Modified(s1,s2): ... @∗/ /∗@ Consistent(s,o): ... @∗/ }
    82. 82. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { pointcut subjMod(Subject copy): (execution(* BookCopy.bkBorrow(..))|| execution(* BookCopy.bkReturn(..)))&& target(copy) && args(..); pointcut attach(): //... pointcut detach(): //... /∗@ Modified(s1,s2): ... @∗/ /∗@ Consistent(s,o): ... @∗/ }
    83. 83. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { pointcut subjMod(Subject copy): (execution(* BookCopy.bkBorrow(..))|| execution(* BookCopy.bkReturn(..)))&& target(copy) && args(..); }
    84. 84. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { pointcut subjMod(Subject copy): (execution(* BookCopy.bkBorrow(..))|| execution(* BookCopy.bkReturn(..)))&& target(copy) && args(..); What if we forgot this? }
    85. 85. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { pointcut subjMod(Subject copy): (execution(* BookCopy.bkBorrow(..))|| execution(* BookCopy.bkReturn(..)))&& target(copy) && args(..); What if /*@pre: true we forgot after(Subject s) : subjMod(s); this? /∗@post: ∀ob ∈ s.observers : Consistent(s, ob)@∗/ }
    86. 86. A Concrete Aspect: Library Observing public aspect LibraryObserving extends Observing { pointcut subjMod(Subject copy): (execution(* BookCopy.bkBorrow(..))|| execution(* BookCopy.bkReturn(..)))&& target(copy) && args(..); What if /*@pre: true we forgot after(Subject s) : subjMod(s); this? /∗@post: ∀ob ∈ s.observers : Consistent(s, ob)@∗/ Would fail! }
    87. 87. Conclusion
    88. 88. Conclusion • AOP promotes reuse through abstract aspects.
    89. 89. Conclusion • AOP promotes reuse through abstract aspects. • Abstract aspects localize common functionality, while concrete aspects localize specific functionality.
    90. 90. Conclusion • AOP promotes reuse through abstract aspects. • Abstract aspects localize common functionality, while concrete aspects localize specific functionality. • Likewise, specifications of abstract aspects can be written abstractly.
    91. 91. Conclusion • AOP promotes reuse through abstract aspects. • Abstract aspects localize common functionality, while concrete aspects localize specific functionality. • Likewise, specifications of abstract aspects can be written abstractly. • Concrete aspects provide predicate definitions specific to the needs of individual systems.
    92. 92. Conclusion • AOP promotes reuse through abstract aspects. • Abstract aspects localize common functionality, while concrete aspects localize specific functionality. • Likewise, specifications of abstract aspects can be written abstractly. • Concrete aspects provide predicate definitions specific to the needs of individual systems. • Abstract aspects can specify acceptable behavior of subaspects.
    93. 93. Conclusion • AOP promotes reuse through abstract aspects. • Abstract aspects localize common functionality, while concrete aspects localize specific functionality. • Likewise, specifications of abstract aspects can be written abstractly. • Behavioral Concrete aspects provide predicate definitions subaspects? specific to the needs of individual systems. • Abstract aspects can specify acceptable behavior of subaspects.
    94. 94. Future Work and Obstacles
    95. 95. Future Work and Obstacles • Formal reasoning framework (possible automation).
    96. 96. Future Work and Obstacles • Formal reasoning framework (possible automation). • How to deal with singleton aspects?
    97. 97. Future Work and Obstacles • Formal reasoning framework (possible automation). • How to deal with singleton aspects? • Traces?
    98. 98. Future Work and Obstacles • Formal reasoning framework (possible automation). • How to deal with singleton aspects? • Traces? • Aspect invariants?
    99. 99. Future Work and Obstacles • Formal reasoning framework (possible automation). • How to deal with singleton aspects? • Traces? • Aspect invariants? • JUnit integration.
    100. 100. Future Work and Obstacles • Formal reasoning framework (possible automation). • How to deal with singleton aspects? • Traces? • Aspect invariants? • JUnit integration. • Transform specifications to unit tests.
    101. 101. Questions?

    ×