aspect-oriented software design

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

Upload: temima

Post on 14-Jan-2016

46 views

Category:

Documents


0 download

DESCRIPTION

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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Aspect-Oriented Software Design

AOSD 1

Aspect-Oriented Software Design

Karl Lieberherr

Theo Skotiniotis

Page 2: Aspect-Oriented Software Design

AOSD 2

AOSD and AOP

• Emerging

• Addresses crosscutting concerns

• Current technologies: ad-hoc, decrease the benefits of encapsulation, modularization and ease of extensibilty.

Page 3: Aspect-Oriented Software Design

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

Page 4: Aspect-Oriented Software Design

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.

Page 5: Aspect-Oriented Software Design

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.

Page 6: Aspect-Oriented Software Design

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.

Page 7: Aspect-Oriented Software Design

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.

Page 8: Aspect-Oriented Software Design

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.

Page 9: Aspect-Oriented Software Design

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.

Page 10: Aspect-Oriented Software Design

AOSD 10

OOSD and AOSD

• Two common concepts:– Separation of concerns– Modularization

• But OOSD does not handle well the crosscutting concerns.

Page 11: Aspect-Oriented Software Design

AOSD 11

Note on AspectJ

• Binding of an aspect (which expresses the details of the crosscutting) is a part of an aspect itself.

Page 12: Aspect-Oriented Software Design

AOSD 12

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);

} …

HashMap targets = new HashMap();

Page 13: Aspect-Oriented Software Design

AOSD 13

Development Aspects

• LoD checker!

• Tracing, Logging, and Profiling

• Pre- and Post-Conditions

Page 14: Aspect-Oriented Software Design

AOSD 14

Development Aspects

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

Page 15: Aspect-Oriented Software Design

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.

Page 16: Aspect-Oriented Software Design

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.

Page 17: Aspect-Oriented Software Design

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."); } }

Page 18: Aspect-Oriented Software Design

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.

Page 19: Aspect-Oriented Software Design

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.

Page 20: Aspect-Oriented Software Design

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.

Page 21: Aspect-Oriented Software Design

AOSD 21

Circularity

These rules can lead to circularity, such asaspect 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.

Page 22: Aspect-Oriented Software Design

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.

Page 23: Aspect-Oriented Software Design

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.

Page 24: Aspect-Oriented Software Design

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.

Page 25: Aspect-Oriented Software Design

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.

Page 26: Aspect-Oriented Software Design

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.