Title: AOP Foundations
1AOP Foundations
- Doug Orleans
- Karl Lieberherr
2What 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 examplesAspectJ, DemeterJ, DJ, ATC,
AspectC, Aspectual Collaborations, D (COOL,
RIDL), BETA, RG
3Now 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.
4Relation 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.
5Measuring 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
6Crosscutting
cc(C2) concerns(methods( C2 )) - 1
C1,C2,C3,C4 - 1 3 cc(C2) image(C2 in
(R-1 ? R)) - 1 3
bipartite graph
concerns
methods
m1
C1
m2
C2
m3
C3
m4
m5
C4
7Concern-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.
8The 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.
9Scattering
- Two kinds of scattering
- method scattering ms
- primary concern scattering pcs
- ms(C) image(C in R)
- pcs(C) image(C in (PCofM ? R))
10Measuring 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) gt pcs(C)
scattering and crosscutting have a lot in common
they are two different uses of same function.
11Scattering
pcs(C) image(C in (PCofM ? R)) C1,C3 2
concerns
methods
primary
m1
C1
m2
C2
m3
C3
primary
m4
m5
C4
12Scattering
pcs(FC) image(FC in (PCofM ? R)) C1,C3
2
s(Structure Concern) 2
m1
C1
m2
FC
m3
C3
m4
m5
Structure Concern
13Measuring crosscutting of a concern
old
- 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
14Crosscutting 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. ??
15Now focus on oo
- Primary concerns are classes.
16Dougs 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.
17Class 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.
18Tangling 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.
19Question
- 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.
20Question
- 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.
21Java Program used but not defined
- class System
- String id from Thing to edu.neu.ccs.demeter.I
dent - 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()
-
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
- 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.")
- )
-
23Dougs 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?