1. More on AspectJ

2. aspect MoveTracking { private static boolean _flag = false; public static boolean testAndClear() { boolean result = _flag; _flag = false; return result; } pointcut moves(): execution(void Line.setP1(Point)) || execution (void Line.setP2(Point)) || execution (void Point.setX(int)) || execution (void Point.setY(int)); static after(): moves() { _flag = true; } multi-class aspect aspect defines a special class that can crosscut other classes

3. multi-class aspect with context aspect MoveTracking { private static Set _movees = new HashSet(); public static Set getMovees() { Set result = _movees; _movees = new HashSet(); return result; } pointcut moves (): execution(void Line.setP1(Point)) || execution (void Line.setP2(Point)) || execution (void Point.setX(int)) || execution (void Point.setY(int)); pointcut movesWhat(FigureElement figElt): this(figElt) && moves(); after(FigureElement fe): movesWhat(fe) { _movees.add(fe); } }

4. Advice Composition Ordering Advice that applies to the same join point is executed sequentially Precedence rules: if advice A has precedence over advice B, A can be executed before B. explicit declaration: " declare precedence: AspectA, AspectB; "

5. Advice Composition 2 If advice comes from different aspects: follow declare precedence rules subaspects have precedence over superaspects otherwise undefined If advice comes from the same aspect: the one that appears earlier in the aspect specification has precedence over others further: around1  before  body  after returning  after throwing  after  around2

6. Inter-type declarations Previously called static model introduction Aspects make declarations that relate to other types (classes): inter-type member declarations methods & fields (but can be seen as local to the aspect) no full pointcuts can be used declare parents: change inheritance/interface hierarchy declare error/warning: when a certain join point is encountered.

7. Aspect Instantiation advice always executes in the context of an aspect instance by default, each aspect is a singleton; the same instance used throughout the program aspects may be declared as: perthis(Pointcut): for each executing object pertarget(Pointcut): for each target object percflow(Pointcut): for each entrance to a cflow...

8. Operational Semantics of weaving A model of execution, not necessarily what the compiler will really do At compilation, all of the base system and the aspects are available. Mark all potential join points in the code (called shadow join points ) Begin executing until first shadow is reached, check if it is a real joinpoint If so, continue executing the advice code, until the next shadow is reached, etc…

9. Operational semantics (cont.) A rolling semantics of aspects Can’t identify all real joinpoints in advance, even if we have the state execution graph of the underlying system Can even have joinpoints of an aspect within its own advice! Sometimes, simplifications are possible, but general analysis is difficult

10. Summary of AspectJ Dynamic execution model (joinpoints) pointcutsbehavior (advice) Base level Aspect Level Classes (objects) Aspects (aspect instances) (binding)

11. AspectJ Concepts what are the join points points in runtime call graph class members means of identifying join points pointcuts member signatures (plus …) means of specifying semantics at join points advice define members dynamic JPM (points in execution) static JPM (intertype decls)

12. Evaluation of AspectJ Strong points + well-integrated in Java (including typing) + single language (not multiple ADLs) + many powerful constructs + addresses crosscutting concerns ‘semantic-based’ queries wildcards + offers imposition of behavior + pointcut composition is supported + advice composition is possible, but...

13. Evaluation of AspectJ Limitations NB: in programming language design, a limitation is not always a drawback! - Advice constructs and ordering are complicated but limited - Reuse of aspects is primitive/restricted - Aspects are statically applied - No (few) joinpoints in advice I.e. mostly an ‘a-symmetrical model' - Composability of aspects is sole responsibility of the programmer(s) !! due to the full expression power within advice

14. Categories of Aspects Not all aspects are equally problematic Usually, aspects do not add joinpoints within their advice, especially recursively Often syntactic checks can determine the category, using dataflow Interesting properties of systems hold automatically for augmented systems with some categories of aspects

15. Spectative aspects Do not affect values of variables/fields, or the continuation of execution of the underlying system to which they are woven Can add local fields, use values from the underlying system for internal computation Must properly terminate with no exceptions Examples: Logging, monitoring for debugging, performance evaluation, gathering statistics, GUI updating (when the GUI is local to the aspect)

16. Identification of Spectative Use dataflow to see that no assignments are made to parameters that correspond to fields/variables of the underlying system Determine that the advice terminates (usually straight-line code) Claim: Almost all properties of the underlying system still hold in the augmented one Exceptions: real-time and next-state properties

17. Regulative aspects Do not change values of underlying, but can prevent some continuations Otherwise like spectative Strengthen conditions for some operations Examples: password authorization, restrict some methods to classes of users, impose scheduling conditions that restrict orderings Safety properties are maintained after weaving

18. Weakly invasive aspects CAN change values of underlying fields/variables, CAN redirect control, skip BUT, will return to a state already reachable in the underlying system (when the aspect variables are ignored) Means that the continuation will be one previously possible (until the next pointcut) Examples: Rollback of transactions, a discount policy, …

19. Strongly invasive Most general aspects…like weakly invasive, but CAN return to a state never possible in the underlying system Means that the underlying code now executes in a new context, and may do unexpected things Makes modular analysis/verification more difficult Examples: Semaphores extended to negative values, breaking invariants of the underlying system