AOP Foundations

1. AOP Foundations Doug Orleans Karl Lieberherr

2. What we did earlier • AOP languages have the following main elements: • a join point model (JPM) wrt base PL • a specification language for expressing sets of join points (JPS) • a means of specifying behavior involving join points (BJP) • encapsulated units combining JPS and BJP (CSB) • method of attachment of units to base program (AU) • Nine examples:AspectJ, DemeterJ, DJ, ATC, AspectC, Aspectual Collaborations, D (COOL, RIDL), BETA, RG

3. Now we go to a higher level • Concerns • Methods: any artifact (oo method, function, statement) used to describe/implement some concern. • Definition of relation R(Concern, Method): A method m is related to a concern C (abbreviated as R(C,m)), if m is used to describe/implement some concern.

4. Relation R • Definition is intentionally left vague. We simply assume a relation between concerns and methods. • For example, we could define: R(C,m) if m contains a join point relevant to concern C. But this assumes the definition of a join point model.

5. Measuring crosscutting of a concern • cc(C) = |concerns(methods( C ))| - 1 • methods(C) = {m | R(C,m)} • concerns(m) = {C | R(C,m)} • concerns(m’)=m in m’ concerns( m ), m’ a set of methods • cc(C) = |image(C in (R-1  R))| - 1 C: a concern m: a method

6. cc(C2) = |concerns(methods( C2 ))| - 1 = |{C1,C2,C3,C4}| - 1 = 3 cc(C2) = |image(C2 in (R-1  R))| - 1 = 3 Crosscutting bipartite graph concerns methods m1 C1 m2 C2 m3 C3 m4 m5 C4

7. Concern-Oriented Analysis Graph (COA Graph) • Doug: cross-cutting not something we want to tune but a quantity that exists in nature. That is what Gregor thinks: cross-cutting is a deep property of concerns. • But also: Doug: there are good and bad analyses.

8. The Primary Concern of a Method PCofM • We add more information to the COA graph: some of the edges of R are used to create a mapping from methods to concerns that partitions the methods into disjoint sets. • PCofM(C,m) maps m to primary concern C • A primary concern may be a class or a generic function, etc.

9. Scattering • Two kinds of scattering: • method scattering: ms • primary concern scattering: pcs • ms(C) = |image(C in R)| • pcs(C) = |image(C in (PCofM  R))|

10. Measuring scattering and crosscutting of a concern • pcs(C) = |image(C in (PCofM  R))| • cc(C) = |image(C in (R-1  R))| - 1 • f(C,T) = image(C in (T  R)) • pcs(C) = f(C, PCofM) • cc(C) = f(C, R-1) • Note: |cc(C)| >= |pcs(C)| scattering and crosscutting have a lot in common: they are two different uses of same function.

11. pcs(C) = |image(C in (PCofM  R))| = |{C1,C3}| = 2 Scattering concerns methods primary m1 C1 m2 C2 m3 primary C3 m4 m5 C4

12. pcs(FC) = |image(FC in (PCofM  R))| = |{C1,C3}| = 2 Scattering s(Structure Concern) = 2 m1 C1 m2 FC m3 C3 m4 m5 Structure Concern

13. old Measuring crosscutting of a concern • cc(C) = |concerns(methods( C ))| - 1 • methods(C) = {m | R(C,m)} • concerns(m) = {C | R(C,m)} • concerns(m’)=m in m’ concerns( m ), m’ a set of methods • methods(C’)=C in C’ methods( C ), C’ a set of concerns

14. Crosscutting concerns • A concern C1 crosscuts a concern C2 if C2 in concerns(methods( C1 )). • A concern C1 crosscuts a concern C2 if C2 in image(C1 in (R-1  R)). • Define the crosscutting graph of concerns as follows: there is an edge between two concerns C1, C2 iff C1 crosscuts C2. ??

15. Now focus on oo • Primary concerns are classes.

16. Doug’s view: Good view • The graph of concerns and methods needs to be turned into a program. • Some of the concerns are turned into • classes • adaptive methods • polytypic functions (Patrik?) • AspectJ aspects • generic functions • aspectual collaborations, personalities • etc.

17. Class selection • partition methods. Concerns that are not classes are aspects. • once we have classes, we can measure scattering in an ad-hoc implementation of aspects. • our goal is to avoid ad-hoc implementation and put information about aspects into a module.

18. Tangling in aspects • But keeping information about an aspect in a module leads to tangling in the module. But that is better than the scattered ad-hoc implementation. We trade bad scattering and tangling for good tangling.

19. Question • Working with aspects trades scattered code spread over several classes with modularized, but tangled code in the aspects. Why is this an improvement? • Answer: • The modularized code is easier to understand. • The tangling in the module cannot be avoided because we need to talk about hooks where the aspect will influence the behavior.

20. Question • References to the hooks will be scattered throughout the module. Scattering inside one module is better than scattering across primary concerns. • Abstraction • use abstract aspects or aspectual collaborations. Reuse them multiple times.

21. Java Program: used but not defined class System{ String id = “from Thing to edu.neu.ccs.demeter.Ident”; void repUndef(ClassGraph cg){ checkDefined(cg, getDefThings(cg));} HashSet getDefThings(ClassGraph cg){ String definedThings = "fromSystembypassingBodytoThing"; Visitor v = new Visitor(){ HashSet return_val = new HashSet(); void before(Thingv1){ return_val.add(cg.fetch(v1, id) );} public Object getReturnValue(){return return_val;}}; cg.traverse(this,definedThings, v); return (HashSet)v.getReturnValue(); } repUndef is a modular unit of crosscutting implementation. Ad-hoc implementation may cut across 100 classes. green: traversal black bold: structure purple: advice red: parameters

22. void checkDefined(ClassGraph cg, final HashSet classHash){ String usedThings = ”fromSystemthroughBodytoThing"; cg.traverse(this, usedThings, new Visitor(){ void before(Thingv){ Ident vn = cg.fetch(v, vi); if (!classHash.contains(vn)){ System.out.println("The object "+ vn + " is undefined."); }}});} }

23. Doug’s observations • Three kinds of aspects: • partition methods • primary concerns, classes • traversals, generic functions • not method partitioning aspects • those aspects may crosscut each other • where do adaptive methods fit in? in both?