aop foundations doug orleans karl lieberherr. what we did earlier aop languages have the following...
TRANSCRIPT
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?