1 / 22

Automating Crosscutting Modification

Automating Crosscutting Modification. By Michael Kleyman. When AOP is Used?. It is usually said that aspects represent crosscutting concerns. No clear definition of such a concern. AOP can be dangerous when overused. Trivial Examples. Logging Authorization. Telecom Example.

zoey
Download Presentation

Automating Crosscutting Modification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Automating Crosscutting Modification By Michael Kleyman

  2. When AOP is Used? • It is usually said that aspects represent crosscutting concerns. • No clear definition of such a concern. • AOP can be dangerous when overused.

  3. Trivial Examples • Logging • Authorization

  4. Telecom Example • Calls, messaging etc. are the core concepts • Represented by classes, such as Call or Connection • Billing is the crosscutting concern, represented by an aspect. • Payment calculation initiated in advices to methods of the core classes.

  5. When AOP is helpful, but not used • Corporate policies do not allow use of experimental, immature technologies • An aspect allows rapid modification of existing code, but the resulting program structure is not the best possible structure • Crosscutting modification as opposed to crosscutting concern

  6. Example: Object Pooling • Goal: reuse objects instead of creating new ones • Can be represented by a factory class. • Introducing object pooling into existing system is difficult. • AspectJ allows an easy but controversial solution

  7. What is ACME • Convert AspectJ solution to pure Java • Prove of concept • Based on specific examples • Additional examples may be covered later

  8. Key Goals • Java code must produce exactly the same results as the aspect code. • Java code should not be significantly longer than the aspect code. • The produced code should be easily modified and used.

  9. Key Goals (Continued) • The generated code must look similar to code written by a human programmer. • Based on commonly used patterns and idioms.

  10. ACME vs. AspectJ Compiler • Must not support the entire language • Must generate meaningful names (possibly with user’s help) • May not use some complicated structures used in the compiler.

  11. Workflow with ACME • Implement the required modification using aspects • Test the implementation • When the result is satisfactory, run ACME to generate pure Java code with same functionality

  12. Creating Singleton Class • Aspect interacts with other code through pointcuts on functions of a single class. • Aspect is converted to a class automatically. • All calls that are advised by the aspect are replaced by calls to the singleton. • Example: object pooling.

  13. Inlining Aspect Code • Aspect may be used to modify both interface and behavior of an existing class. • Involves both advises and inter-type member declarations. • Example: modification of the Point class. • Example: introduction of transactions

  14. Automatic Modification • Add the member introduced by the inter-type declaration to the class • Add a function for each advice • Replace all calls advised by the aspect by calls to the new functions

  15. Aspect Hierarchies • Allow code reuse in several aspects • Typically involve abstract pointcuts and concrete implementation of the advices • Transformed into hierarchies of classes where the leaves are implemented as singletons.

  16. When ACME helps? • Evolution aid: test before changing the system. • Refactoring • Eases adoption of aspect technology

  17. When not? • Aspect represent crosscutting concerns • Aspects used as a configuration tool for different application of the system

  18. Unsupported Language Features • Wildcards • Type-dependent pointcut definitions • Implicit type casting • Compile-time applications of aspects, such as “declare error” • Execution pointcuts

  19. More on execution join points • Require replacing the implementation of functions, not the calls to them. • With inheritance require replacing several functions for each advice. • Anything but the simplest around advice must be transformed to very complicated code • Very limited benefit

  20. Case Study • ACME was applied to Shay Raz’s work on system scaling with aspects. • Some aspects required cosmetic changes before processing. • Some can not be processed because they involve implicit type casting. • Possible solution: rewrite the aspects, removing abstract pointcuts from the base aspect.

  21. Implementation Details • Built as an Eclipse plugin • Uses JDT library for Java source manipulation • There is no such library for AspectJ code

  22. Algorithm Steps • Parse the AspectJ files • Create new classes for “singleton” aspects. • Add new members to existing classes • Find advised function calls (using JDT) • Replace these calls by calls to generated functions

More Related