1 / 26

Aspect-Oriented Software Design

Aspect-Oriented Software Design. Karl Lieberherr Theo Skotiniotis. AOSD and AOP. Emerging Addresses crosscutting concerns Current technologies: ad-hoc, decrease the benefits of encapsulation, modularization and ease of extensibilty. Crosscutting Concerns. Concern = system property

temima
Download Presentation

Aspect-Oriented Software Design

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

More Related