Aspect-Oriented Software Design

1. Aspect-Oriented Software Design Karl Lieberherr Theo Skotiniotis AOSD

2. AOSD and AOP • Emerging • Addresses crosscutting concerns • Current technologies: ad-hoc, decrease the benefits of encapsulation, modularization and ease of extensibilty. AOSD

3. Crosscutting Concerns • Concern = system property • Functional property • Constraint of system behavior • Constraints on a system refer to conditions that need to be satisfied when the system runs • Logging of read/write operations on all pumps • Authorization • Synchronization AOSD

4. Crosscutting Concerns • Are those system concerns which take effect over multiple artifacts within a design or program. • Artifact = any tangible object at any level of the software development process. AOSD

5. Aspects • In the context of AOSD, are a new modularity mechanism with which crosscutting concerns can be expressed. • An aspect holds all the information (operations and data) that a crosscutting concern uses/manipulates. • An aspect is bound to a context. AOSD

6. Aspects • Better modularity. Crosscutting concerns are now localized in an aspect. • Easier understanding. The information about a concern is localized. It is less scattered and tangled with other information. • Easier modifiability. Look at one aspect and its binding. AOSD

7. Binding Model • Separating the operations and data which a crosscutting concern deals with is the first step: aspectual data type. • One needs to define at which points within your design implementation an aspect gets to execute its code. Binding of an aspect. • A join point model provides the glue between aspectual data types and the binding of them. AOSD

8. Join Point Models • We want to specify conditions under which methods should execute. Those methods that execute conditionally when an event happens are called advice. • However, there are AOP languages that unify methods and advice. Example: Fred: Doug Orleans, NEU PhD student. AOSD

9. Join Point Models • In this context: dynamic join points, e.g. call join points. • Need a mechanism to specify sets of join points. Use some primitives and the set operations. AOSD

10. OOSD and AOSD • Two common concepts: • Separation of concerns • Modularization • But OOSD does not handle well the crosscutting concerns. AOSD

11. Note on AspectJ • Binding of an aspect (which expresses the details of the crosscutting) is a part of an aspect itself. AOSD

12. HashMap targets = new HashMap(); Looks familiar? aspect Supplier { void add (Object target, String i) {} void around (Object target, String i): call(void Supplier.add(Object, String)) && args(target, i) { targets.put(target,i); } … AOSD

13. Development Aspects • LoD checker! • Tracing, Logging, and Profiling • Pre- and Post-Conditions AOSD

14. Development Aspects aspect SimpleTracing { pointcut tracedCall(): call(void FigureElement.draw(GraphicsContext)); before(): tracedCall() { System.out.println( "Entering: " + thisJoinPoint); } } AOSD

15. Development Aspects When debugging, programmers often invest considerable effort in figuring out a good set of trace points to use when looking for a particular kind of problem. When debugging is complete or appears to be complete it is frustrating to have to lose that investment by deleting trace statements from the code. The alternative of just commenting them out makes the code look bad, and can cause trace statements for one kind of debugging to get confused with trace statements for another kind of debugging. AOSD

16. Very Specific Profiling aspect SetsInRotateCounting { int rotateCount = 0; int setCount = 0; before(): call(void Line.rotate(double)) { rotateCount++; } before(): call(void Point.set*(int)) && cflow(call(void Line.rotate(double))) { setCount++; } } Shape: from LR to PS* We don’t care what is in between. AOSD

17. Pre- and Post- Conditions aspect PointBoundsChecking { pointcut setX(int x): (call(void FigureElement.setXY(int, int)) && args(x, *)) || (call(void Point.setX(int)) && args(x)); pointcut setY(int y): (call(void FigureElement.setXY(int, int)) && args(*, y)) || (call(void Point.setY(int)) && args(y)); before(int x): setX(x) { if ( x < MIN_X || x > MAX_X ) throw new IllegalArgumentException("x is out of bounds."); } before(int y): setY(y) { if ( y < MIN_Y || y > MAX_Y ) throw new IllegalArgumentException("y is out of bounds."); } } AOSD

18. Advice Precedence in AspectJ • Multiple pieces of advice may apply to the same join point. In such cases, the resolution order of the advice is based on advice precedence • If the two pieces of advice are defined in • different aspects, then there are three cases: • dominates, subaspect, undefined. • in the same aspect, then there are two cases: • Textual order: After-reverse and other-normal. AOSD

19. Different aspect rules • If aspect A is declared such that it dominates aspect B, then all advice defined in A has precedence over all advice defined in B. • Otherwise, if aspect A is a subaspect of aspect B, then all advice defined in A has precedence over all advice defined in B. So, unless otherwise specified with a dominates keyword, advice in a subaspect dominates advice in a superaspect. • Otherwise, if two pieces of advice are defined in two different aspects, it is undefined which one has precedence. AOSD

20. Same aspect rules • If the two pieces of advice are defined in the same aspect, then there are two cases: • If either are after advice, then the one that appears later in the aspect has precedence over the one that appears earlier. • Otherwise, then the one that appears earlier in the aspect has precedence over the one that appears later. AOSD

21. Circularity These rules can lead to circularity, such as aspect A { before(): execution(void main(String[] args)) {} after(): execution(void main(String[] args)) {} before(): execution(void main(String[] args)) {} } such circularities will result in errors signalled by the compiler. AOSD

22. Effects of precedence • At a particular join point, advice is ordered by precedence. • A piece of around advice controls whether advice of lower precedence will run by calling proceed. The call to proceed will run the advice with next precedence, or the computation under the join point if there is no further advice. AOSD

23. Effects of precedence • A piece of before advice can prevent advice of lower precedence from running by throwing an exception. If it returns normally, however, then the advice of the next precedence, or the computation under the join point if there is no further advice, will run. AOSD

24. Effects of precedence • Running after returning advice will run the advice of next precedence, or the computation under the join point if there is no further advice. Then, if that computation returned normally, the body of the advice will run. AOSD

25. Effects of precedence • Running after throwing advice will run the advice of next precedence, or the computation under the join point if there is no further advice. Then, if that computation threw an exception of an appropriate type, the body of the advice will run. AOSD

26. Effects of precedence • Running after advice will run the advice of next precedence, or the computation under the join point if there is no further advice. Then the body of the advice will run. AOSD