An Introduction to AOP Original slides developed by Julie Waterhouse and Mik Kersten for OOPSLA 2004 AspectJ Tutorial (kerstens.org/mik/publications/aspectj- tutorial-oopsla2004.ppt) Adapted by Peter Kim for Spring 2007 SE2 classes, University of Waterloo
47
Embed
An Introduction to AOP Original slides developed by Julie Waterhouse and Mik Kersten for OOPSLA 2004 AspectJ Tutorial ( kerstens.org/mik/publications/aspectj-
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
An Introduction to AOP
Original slides developed by Julie Waterhouse and Mik Kersten for OOPSLA 2004 AspectJ
• “move” is an abstraction capturing characteristic runtime events
Pointcut Pointcut descriptor (PCD)
CASCON '0418
Pointcut wildcards
pointcut move():
call(void FigureElement.moveBy(int, int)) ||
call(void Line.set*(..)) ||
call(void Point.set*(..));
• Wildcards should be used with caution: unintended join points may be captured (e.g. a new method introduced “setID” may have nothing to do with “move” pointcut)
CASCON '0419
Advice
a Line• Specifies action to take after or before computation under join points
• after advice specifies action to take after each “move” join point
class Point extends FigureElement{ void setX(int x) { ... display.update(this); }}
Point p = new Point(); p.setDisplay(new Display());
DisplayUpdating.aspectOf().
setDisplay(p, new Display());
CASCON '0434
Overview
• Motivation• AspectJ language
– First example– Basic language constructs– Joinpoint data retrieval– Restrictive mechanisms– Types of advice– Inter-type declarations
• Applications• Key ideas• Misconceptions• State of the art
CASCON '0435
• Java code base with 10,000 files and 500 developers• AspectJ captured logging, error handling, and profiling policies
– Packaged as extension to Java language– Compatible with existing code base and platform
AspectJ applied to a large middleware system
existing policy implementations
• affect every file– 5-30 page policy documents– applied by developers
• affect every developer– must understand policy document
• repeat for new code assets• awkward to support variants
– complicates product line• don’t even think about
changing the policy
policies implemented with AspectJ
• one reusable crosscutting module– policy captured explicitly– applies policy uniformly for all time
• written by central team– no burden on other 492 developers
• automatically applied to new code• easy plug and unplug
– simplifies product line issues• changes to policy happen in one
place
CASCON '0436
Other applications
• GUI– Design patterns
• Distributed systems– Data marshalling– Synchronization– Concurrency
• System-level software– OS kernels
• Debugging and testing• Monitoring• Optimization
– Loop fusion
CASCON '0437
Overview
• Motivation• AspectJ language
– First example– Basic language constructs– Joinpoint data retrieval– Restrictive mechanisms– Types of advice– Inter-type declarations
• Applications• Key ideas• Misconceptions• State of the art
CASCON '0438
Obliviousness
• Ideally, application code should evolve independently of aspects that apply to it and vice versa
// evolution makes computation offline, not requiring an update window.setVisible(false); …
line.moveBy(dx, dy);Display.update(); // woven by aspect
• In reality, understanding evolutionary relationship between between aspect and application code (i.e. how does change in one affect the other) is more practical– E.g. Tool support can notify aspect when application code
changes and application code when aspect changes
CASCON '0439
Quantification
• Eliminating redundancy is one of the biggest benefits of AOP– So redundancy must exist
• Homogeneous advice: uniform (e.g. Display.update()) to all joinpoints– But how often does this really happen?
• Heterogeneous advice: depends on context (e.g. repainting a large image different from repainting a piece of text)– Unless commonalities (redundancy) can be found between
multiple joinpoints, an aspect that applies to these multiple joinpoints cannot be written
• E.g. Without thisJoinPoint, impossible to write a quantifying aspect that logs a method call name
– By understanding how to group joinpoints more meaningfully, we can make aspects more applicable
• But can an aspect apply to a single join point?
CASCON '0440
Separation of concerns
• Another major benefit of AOP is separation of secondary concerns from the primary concern
void animate()
{
line1.moveBy(2, 2);
Display.update();
line2.moveBy(3, 4);
Display.update();
}
Display.update() should be separated.
• But is Display.update() always a secondary concern? It seems to be an integral part of repairing screen (repainting)
• Are aspects just about physical separation?
void repairScreen()
{
displayRectangle.set(0, 0, WIDTH, LENGTH);
Display.update();
}
Should Display.update() be separated?
CASCON '0441
Viewpoints
• AOP has a strong connection to viewpoints in software engineering• E.g. when an Action is registered for extension, it must be also
• Although AspectJ permits only one perspective (asymmetric), languages like HyperJ permit multiple perspectives (symmetric)
CASCON '0442
Overview
• Motivation• AspectJ language
– First example– Basic language constructs– Joinpoint data retrieval– Restrictive mechanisms– Types of advice– Inter-type declarations
• Applications• Key ideas• Misconceptions• State of the art
CASCON '0443
AOP vs. metaprogramming
• AOP has strong roots in metaprogramming, but is quite different from it
• Metaprogramming: focus on representing code as manipulative data– E.g. “upon execution of methods called set*,
execute the method Display.update”
• AOP: focus on runtime events– E.g. “whenever change occurs, update display”– thisJoinPoint is the closest thing to
metaprogramming
CASCON '0444
AOP vs. program transformation
• An aspect transforms a program without “Display.update” to a program with it
• But imagining how the transformed program would look is like imagining what method would be dispatched for each method call– This defeats essential features of AOP (quantification)
and OOP (polymorphism)
• Another danger is that there are infinitely many ways to transform an AOP program into an OO program– How transformation occurs is the business of the
compiler, not the developer
• One should think of AOP in terms of meaningful pointcuts and advices
CASCON '0445
Overview
• Motivation• AspectJ language
– First example– Basic language constructs– Joinpoint data retrieval– Restrictive mechanisms– Types of advice– Inter-type declarations
• Applications• Key ideas• Misconceptions• State of the art
CASCON '0446
Research in AOP
• Application– When is AOP more suitable than other techniques?
• Mining and refactoring– Find crosscutting concerns in normal applications and transform them
into aspects
• Expressivity of languages– E.g. What does “after” mean? Immediately after or sometime after?
When a file is opened, it must be closed after.
• Performance– AOP programs are slower due to weaving overhead. How can we
advance compiler technology here?
• Early aspects– Like objects, do aspects exist at other abstraction levels, such as
requirements and design artifacts?
• Generative Software Development– How can aspects be used to model product lines from requirements to
code?
CASCON '0447
Conclusion
• Aspects modularize crosscutting concerns that cannot be captured cleanly using primary constructs
• Aspects specify what actions to take (advice) “whenever” something happens (pointcut)
• Aspects eliminate redundancy, separate concerns, and provide different viewpoints on the same program
• Aspects are abstractions like objects, rather than metaprogramming or program transformation mechanisms
• There is exciting research going on in AOP (for over 10 years now) so join in!