AOP Foundations Doug Orleans Karl Lieberherr

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

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.

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.

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

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

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.

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.

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

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.

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

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

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 old

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

Now focus on oo Primary concerns are classes.

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.

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.

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.

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.

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.

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 = "from System bypassing Body to Thing"; Visitor v = new Visitor(){ HashSet return_val = new HashSet(); void before(Thing v1){ return_val.add(cg.fetch(v1, id) );} public Object getReturnValue(){return return_val;}}; cg.traverse(this, definedThings, v); return (HashSet)v.getReturnValue(); } green: traversal black bold: structure purple: advice red: parameters repUndef is a modular unit of crosscutting implementation. Ad-hoc implementation may cut across 100 classes.

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

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?