AOP Foundations

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 concernm: a method

Crosscutting

C1

C3

C2

m1

m2

m3

m4

m5C4

cc(C2) = |concerns(methods( C2 ))| - 1 = |{C1,C2,C3,C4}| - 1 = 3cc(C2) = |image(C2 in (R-1 R))| - 1 = 3

concerns methods

bipartitegraph

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 crosscuttinghave a lot in common: they are two different uses of samefunction.

Scattering

C1

C3

C2

m1

m2

m3

m4

m5C4

pcs(C) = |image(C in (PCofM R))| = |{C1,C3}| = 2

concerns methods

primary

primary

Scattering

C1

C3

FC

m1

m2

m3

m4

m5Structure 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 definedclass 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: traversalblack bold: structurepurple: advicered: parameters

repUndef is a modular unitof crosscutting implementation. Ad-hoc implementation maycut 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?