Aspect Oriented Programming

1
Aspect Oriented Programming

• The fun has begun Gregor Kiczales, Harold
  Ossher,

Charles Zhang Department of Electrical and
Computer Engineering University of Toronto
2
We will explore

• What is AOP?
• Problems and solutions
• AOP languages and tools
• Industry adoptions.
• AOP and Design patterns.
• Aspect oriented research at University of Toronto
  
• Aspect oriented middleware
• Aspect mining
• Runtime adaptation of aspects

3
Example of Crosscutting Problems -- Loop Fusion

• Consider designing a specialized filter for an
  image processing system to produce a new image
  given two images.
• A common design approach is to use functional
  decomposition decompose the complex filter into
  a set of primitive filters, such as AND, OR, XOR,
  etc.

4
Loop Fusion. A primitive filter

• Implementation of an OR filter
• Image OR ( Image image1, Image image2)
• Image result new Image(width,height)
• for(int i0iltwidthi)
• for(int j0jltheightj)
• resultijimage1ijimage2ij
  
• return result

5
Special filter easy to read, reason, maintain
and extend

• Image SpecialFilter(Image image1, Image image2)
• return AND(OR(image1, image2),
• XOR(OR(image1, image2),
• AND(image1,image2))

6
Problem With This Design

• Not memory efficient
• Increased computational complexity. Each
  primitive filter contains a double loop.

7
An alternative design goal Efficiency

• We can fuse the loops together
• Image AlphaFilter(Image image1, Image
  image2)
• Image result new Image(width, height)
• for(int i0iltwidthi)
• for(int j0jltheightj)
• resultij(image1ijimage2ij)
  ((image1ijimage2ij) (image1ijimage2
  ij))
• return result

8
Problem with this design

• Good in both memory management and reducing
  computational complexity
• 1 double loop, one image
• Bad in everything else
• Hard to read, reason and maintain. Error prone.
  Logic is tangled together. Referred as code
  tangling problem

9
The design dilemma

• Design goal one Modularity
• Good modularity. Easy to reason, manipulate ,
  reuse and maintain.
• Bad efficiency. Hiding information behind
  interface prevents optimization.
• Design goal two Efficiency
• Reduced computational complexity. Direct control
  of resource.
• Hard to understand, not modular.
• We want to have the cake and eat it too.

10
Solution to loop fusion

• Define primitive filter
• OR(Image i1, Image i2)
• //loop through the horizontal dimension
• //loop through the vertical dimension
• //perform OR operation on pixels

• Define a separate function
• FuseLoop()
• if( cflow(AND) cflow(OR))
• //fuse the loops in AND and OR
• //This is applied to all instances

11
Crosscutting problemFigure Editor

• Orthogonal concerns cut across class modularity

HistoryUpdating
12
More orthogonal concerns span across modules
13
a simple figure editor
class Line implements FigureElement private
Point p1, p2 Point getP1() return p1
Point getP2() return p2 void setP1(Point
p1) this.p1 p1 void setP2(Point p2)
this.p2 p2 void moveBy(int dx, int dy)
... class Point implements FigureElement
private int x 0, y 0 int getX() return
x int getY() return y void setX(int
x) this.x x void setY(int y) this.y
y void moveBy(int dx, int dy) ...
14
display updating

• collection of figure elements
• that move periodically
• must refresh the display as needed
• complex collection
• asynchronous events
• other examples
• session liveness
• value caching

we will initially assume just a single display
15
Design Dilemma

• Design alternative one Place the display
  updating code inside the corresponding methods.
• Pro. A natural approach. Direct control of
  updating behaviour.
• Cons. Updating code scatters. Multiple places
  need to be changed for new functionality
• Design alternative two Encapsulate display
  concern separately and use visitors or observers.
  
• Pro. Less code bloating. Cleaner modularization.
• Cons. Not flexible. Not easy to add new
  functionality. Original modularization is still
  broken
• We also want to eat the cake

16
Solution in AspectJ

• aspect DisplayUpdating
• pointcut move()
• call(void FigureElement.moveBy(int, int))
• call(void Line.setP1(Point))
• call(void Line.setP2(Point))
• call(void Point.setX(int))
• call(void Point.setY(int))
• after() returning move()
• Display.update()
• before()move()
• History.save()
• No code in the original architecture is touched.
• We add any new functionality as we desire.
• Dramatic coding reduction.

17
Cross-Cutting Concern

• Definition (Gregor Kiczales)
• In general, whenever two properties being
  programmed must compose differently and yet be
  coordinated, we say that they cross-cut each
  other.
• Due to
• The tyranny of the dominant decomposition. We
  are only thinking of decomposing problems along
  one dimension.

18
Aspect

• Definition (AoP, Kiczales, et al)
• Aspects tend not to be units of the systems
  functional decomposition, but rather to be
  properties that affect the performance or
  semantics of the components in systemic ways
• What could be an aspect?(Elrad, et al)
• synchronization, scheduling, resource
  allocation, performance optimizations, failure
  handling, persistence, communication,
  replication, coordination,memory management, and
  real-time constraints

19
Visualizing Aspects

• logging in org.apache.tomcat
• red shows lines of code that handle logging
• not in just one place
• not even in a small number of places

20
Aspect Oriented Programming

• Definition To support the programmer in
  cleanly separating components and aspects from
  each other by providing mechanisms that make it
  possible to abstract and compose them to produce
  the overall system
• Used when we have design goals OOP cannot
  capture.
• Capable of modulize pervasive properties of the
  system
• Complements OOP

21
Artifacts of AoP

• So far, we observe the following programming
  activities in solving our dilemmas.
• We write normal programs
• We write another set of programs seem to
  manipulate the normal programs.
• Two programs get merged together.
• Formally, aspect oriented programming generally
  utilizes the following artifacts, as in AspectJ
• A component language Java
• An aspect language AspectJ
• An aspect weaver AspectJ compiler

22
Overview of AOP

• Initially incepted by Gregor Kiczales in 96 and
  formally described in his ECOOP 97 paper.
• Current research focuses on the language and tool
  support.
• AspectJ Hyper/J Demeter/J Compositional
  filters JAC, and many others.
• Eclipse AJDT IBM Eclipse concern manager
• Industry adoption
• Early adoption at Verizon wireless, Boeing.

23
Other flavors of AOP Subject Oriented
Programming Adaptive Programming
24
Subject Oriented Programming

• Definition (IBM research)
• A program-composition technology that supports
  building object-oriented systems as compositions
  of subjects. A subject is a collection of classes
  or class fragments whose hierarchy models its
  domain in its own, subjective way.

25
SOP Personnel Application
Two teams are developing personnel
applications Team 1 payroll application Team 2
employee locator information

26
SOP Views of Two Teams

• Team one

• Team two

27
SOP The merge of two views

• Need to merge them together via a rule
• Merge Class
• equate(class composed.employee,
  ltlocator.employee, payroll.employeegt)
• Merge Attributes
• equate(variable omposed.employee.ID,
  ltlocator.employee.ID, payroll.employee.IDgt)
• Merge Operations
• equate(operation composed.GetID, ltlocator.GetID,
  payroll.GetID gt)

28
SOP Summary

• Enables separation of concerns.
• Enable parallel development and late integration
• Recognize aspects in AoP as subjects, which can
  be developed independently. Therefore, break down
  the tyranny of primary decomposition.

29
Adaptive ProgrammingA equation system

• Consider the following equations
• X1 (X2X3)
• X2(X5X3X1)
• X3(X575)
• Variable is defined if it appears on the left
• Variable is used if it appears on the right.
• Purpose is to collect all defined and used
  variables.

30
The class graph
EquationSystem
equations
Equation_List

Equation
rhs
lhs
Expression
Variable
Operator
Numerical
31
Traversal Strategies

• To collect Defined variables
• From EquationSystem bypassing Expression to
  Variable
• To collect Used variables
• From EquationSystem through Expression through
  rhs to Variable
• Lets refer them by the variable travspec

32
Adaptive Traversal

• Suppose cg represents the class graph of the
  system, v is the visitor instance.
• Then, traverse(cg, travspec, v) is adaptive as to
  which traversal strategy we use.
• The results are collected by V.

33
In relation to AOP

• The class graph is the component program.
• Nodes where the visitor visits contain join
  point.
• The behavior capsulated by visitors is the aspect
  program.
• It uses runtime weaving.

34
AOP and Design Pattern Design Pattern
Implementation in Java and AspectJ Jan Hannemann
and Gregor Kiczales, OOPSLA, 2002
35
Problem of Design Patterns

• Patterns are only conceptually reusable.
  Implementations are always tailored hence not
  reusable.
• Patterns always mingle with other classes.
  Difficult to add or remove.
• Role crosscuts all of its participants.
  Implementation is scattered.

36
AOP and Design Pattern Observers
FigureElement
Display
addObservers(Observer) removeObservers(Observer) n
otify()

Point
Line
getX()getY()setX(int)setY(int)setColor(Color)
addObservers(Observer) removeObservers(Observer) n
otify()
getP1()getP2()setP1(Point)setP2(Point)setColor
(Color) moveBy(int, int) addObservers(Observer) re
moveObservers(Observer) notify()
2
37
OO Implementation in Java
Observer
DisplayObserver
ColorObserver
CoordinateObserver

• In Point
• class Point extends FigureElement
• List colorObservers new Vector()
• void setX(int x) notify()
• void setY(int y) notify()
• void setColor(Color c) notifyColor()

• In Line
• class Line extends FigureElement
• Vector positionObservers new Vector()
• void setP1(Point x) notify()
• void setP2(Point y) notify()
• void setColor(Color c) notifyColor()

• In FigureElement
• abstract class FigureElement implements Subject
• addObserver(Observer o)
• Observers.add(o)

38
Reusable Modular Implementation of Observer
Pattern in AspectJ
21 public void addObserver(Subject s,Observer
o) 22 getObservers(s).add(o) 23 24
public void removeObserver(Subject s,Observer
o) 25 getObservers(s).remove(o) 26
27 28 abstract protected pointcut 29
subjectChange(Subject s) 30 31 abstract
protected void 32 updateObserver(Subject s,
Observer o) 33 34 after(Subject s)
subjectChange(s) 35 Iterator iter
getObservers(s).iterator() 36 while (
iter.hasNext() ) 37 updateObserver(s,
((Observer)iter.next())) 38 39 40

• 01 public abstract aspect ObserverProtocol
• 02
• 03 protected interface Subject
• 04 protected interface Observer
• 05
• 06 private WeakHashMap perSubjectObservers
• 07
• 08 protected List getObservers(Subject s)
• 09 if (perSubjectObservers null)
• 10 perSubjectObservers new WeakHashMap()
• 11
• 12 List observers
• 13 (List)perSubjectObservers.get(s)
• 14 if ( observers null )
• 15 observers new LinkedList()
• 16 perSubjectObservers.put(s, observers)
• 17
• 18 return observers
• 19

39
Concrete Instances of Observer Pattern
ColorObserver, CoordinateObserver
sub-aspecting

• 01 public aspect ColorObserver extends
  ObserverProtocol 16 public aspect
  CoordinateObserver extends
• 02
  17
  ObserverProtocol
• 03 declare parents Point implements Subject
  18
• 04 declare parents Line implements Subject
  19 declare parents Point
  implements Subject
• 05 declare parents Screen implements Observer
  20 declare parents Line
  implements Subject
• 06
  21
  declare parents Screen implements Observer
• 07 protected pointcut subjectChange(Subject s)
  22
• 08 (call(void Point.setColor(Color))
  23 protected pointcut
  subjectChange(Subject s)
• 09 call(void Line.setColor(Color)) )
  target(s) 24 (call(void
  Point.setX(int))
• 10
  25
  call(void Point.setY(int))
• 11 protected void updateObserver(Subject s,
  26 call(void
  Line.setP1(Point))
• 12 Observer o)
  27
  call(void Line.setP2(Point)) ) target(s)
• 13 ((Screen)o).display("Color change.")
  28
• 14
  29
  protected void updateObserver(Subject s,
• 15
  30
  Observer o)
• 
  
  31 ((Screen)o).display("Coordinate
  change.")
• 
  
  32
• 
  
  33

modify the inheritance hierarchy
Define places in the execution flow
Notification logic
40
Observations

• Observer pattern becomes reusable, locally
  modularized.
• No changes made to the original code. Observer
  pattern can be added and removed freely.
• Very easy to add new observable properties.

41
AOP Research _at_ University of Toronto
42
AOP Research At Home

• Primary research goal Develop fully aspect
  oriented middleware platform.
• Aspect mining Automatically discover aspects in
  legacy code bases.
• Adaptive middleware through dynamic aspect
  weaving C2 , a dynamic aspect language extension
  to C.

43
Current State of Research

• Quantifying aspects in middleware platforms ACM
  AOSD 2003, Boston, MA
• TinyC2 An effort towards dynamic weaving
  aspect language for C FOAL workshop, AOSD 2003,
  Boston, MA
• IBM Eclipse innovation grant for aspect mining.
• Participation wanted!!

44
Important References

• Aspect Oriented Programming, Gregor Kiczales,
  et al. ECOOP 1996
• General Info, http//www.aosd.net
• Languages
• AspectJ , http//www.eclipse.org/aspectj
• HyperJ, http//www.alphaworks.ibm.com/tech/hyperj