AspectOriented Programming with AspectJ

1
Aspect-Oriented Programmingwith AspectJ

• Jorrit N. Herder
• jnherder_at_cs.vu.nl
• Vrije Universiteit, Amsterdam
• November 19, 2002

2
Without AOP
3
With AOP
4
Talk outline

• OOP benefits and shortcomings
• Different kinds of software properties
• What is AOP and what are the benefits?
• How does AOP actually work?
• An example application in AspectJ
• Design Patterns and AOP

5
OOP benefits

• OOP builds on existing paradigms
• Elegant programming solutions
• Inheritance (specialized classes)
• Dynamic binding (polymorphic behavior)
• Maintenance becomes easier
• Object model is rather stable
• Reuse of components is easy
• OOAD can be used as design method

6
OOP shortcomings

• OOP allows to decompose a system into units of
  function or behavior
• Certain software properties cannot be isolated in
  single functional unit, instead they crosscut
  multiple components
• Such crosscutting concerns result in tangled code
  that is hard to develop and maintain

7
interface Observer / ... the observer
design pattern requires that every
observer implements this interface .../
public void update(Subject s) class
ConcreteObserver implements Observer ...
public void update(Subject s) // ...
get new state from the subject ...
8
Software properties (1/2)

• Components properties that can be cleanly
  encapsulated in a unit of function or behavior
  like a procedure or object
• Aspects cross-cutting concerns that cannot be
  captured in a functional decomposition
  properties affecting the performance or semantics
  of components

9
Software properties (2/2)

• Components
• GUI elements
• Readers and writers
• Database
• Aspects
• Debugging
• Logging
• Synchronization

10
Aspect-Oriented Programming

• Definition ''... to support the programmer in
  cleanly separating components and aspects from
  each other, by providing mechanisms that allow to
  abstract and compose them to produce the overal
  system.''

11
AOP Benefits

• All benefits of OOP discussed before
• Separation of components and aspects
• Better understanding of software because of high
  level of abstraction
• Easier development and maintenance because
  tangling of code is prevented
• Increased potential for reuse for both components
  as well as aspects

12
How does AOP work?
13
AOP mechanisms

• Abstraction mechanism An aspect description
  language is used to encapsulate crosscutting
  concerns into modules according to the join
  point model
• Composition mechanismA weaver is used to merge
  the aspects and components into an application
  that only contains traditional language
  constructs

14
Join point model (1/2)

• Identify join points
• Points in the execution of components where
  aspects should be applied
• E.g method invocation or object construction
• Describe behavior at join points
• Wrap join points with extra code just before or
  just after execution
• E.g. lock and unlock shared data

15
Join point model (2/2)

• A method call join point

16
Weaving

• Aspect description languages cannot be processed
  by tradional compilers
• Therefore, aspects and components are woven into
  intermediate source code
• Weaving is no longer needed if there is an
  aspect-oriented compiler available
• This can be compared to preprocessing of C code
  to generate a C representation

17
Illustration of AOP

• The concepts presented will now be illustrated by
  an example application in the aspect-oriented
  language AspectJ
• Any questions sofar?

18
AspectJ

• Is a general-purpose aspect-oriented extension to
  Java, which is freely available from
  http//www.aspectj.org/
• Java defines components as before
• by encapsulating data and behavior in objects
• AspectJ defines aspect modules
• by describing join points and behavior

19
Problem description

• Question ''How to enforce synchronization
  policies with AOP?''
• Suppose multiple objects are concurrently working
  on some shared data and exclusive access is
  needed for modification
• All objects that are working on the data must be
  synchronized, for example by locking the shared
  data temporarily

20
class SharedData / ... apply singleton
design pattern ... / private SharedData
instance private SharedData() //
... initialize shared data object
public static SharedData getInstance()
if (instance null) instance new
SharedData() return instance
...
21
class Worker extends Thread / ...
multithreading allows concurrent access ... /
private SharedData data
SharedData.getInstance() public void
modify() / modify
data / // ... needs exclusive access!
public void run()
/ start thread / // ...
schedule actions to modify() // ...
according to external circumstances
... ...
22
Problem analysis

• Synchronization is a crosscutting concern that
  affects all components that are working on the
  shared data
• Components readers, writers, and data
• Aspect the locking literally cross-cuts all
  components that are working on the data

23
Observation

• Without AOP
• Every component that works on the shared data
  must take care of the locking itself, leading to
  tangled and complex code
• With AOP
• The locking aspect is separated from the
  components by means of an aspect module,
  resulting in usual benefits of modularization

24

• aspect ExclusiveAccess
• private boolean locked /
  private to aspect /
• pointcut access() /
  method call join point /
• call( void Worker.modify() )
• before(Worker worker) access()
  this(worker)
• while( ! acquireLock() ) /
  synchronization point /
• try
  
• worker.sleep()
• catch(InterruptedException e)

25
// ... rest of aspect ExclusiveAccess
after() access() releaseLock()
/ nothing special /
private synchronized boolean acquireLock()
if (locked) return false locked
true return locked private
void releaseLock() locked false

26
Conclusions sofar ...

• Today's programming languages have problems
  capturing cross-cuttings
• AOP languages, like AspectJ, provide mechanisms
  to cleanly abstract from components and aspects
• Improved modularity allows simpler code that is
  easier to develop and maintain, and that has
  greater potential for reuse

27
Design Patterns

• Design patterns are proven solutions that provide
  elegant ways for solving frequently occuring
  problems
• Effects of AOP on design patterns were studied by
  analysing Java and AspectJ implementations of
  Observer, Composite, Visitor, Proxy, Decorator

28
Observations

• Existing design patterns may be replaced by
  aspect-oriented patterns that provide a different
  solution for the same problem
• Existing object-oriented design patterns may be
  implemented more modular with aspect-oriented
  technologies

29
AspectJ constructs

• Assigning roles to participants
• declare parents Participant implements Role
• Attaching pattern functionality
• public void Node.accept(Visitor v)
  v.visit(this)
• Event handling (join points advice)
• abstract pointcut event(Subject s)
• after(Subject s) event(s) ... notify
  observers ...

30
Observer

• GoF ''Define one-to-many dependency between
  objects so that when one object changes state,
  all its dependents are notified and updated
  automatically.''
• Decouple components
• Retain a consistent state

31
abstract aspect ObserverProtocol
protected interface Subject /
defines role / protected interface Observer
/ defines role / private
WeakHashMap perSubjectObservers public
void addObserver(Subject s, Observer o)
// ... register observer o of subject s
getObservers(s).add(o) public void
removeObserver(Subject s, Observer o)
getObservers(s).remove(o) ...
32
// ... rest of aspect ObserverProtocol
/ abstract join points after which to do update
/ protected abstract poincut
subjectChange(Subject s) / abstract
method that does actual observer update /
protected abstract void update(Subject s,
Observer o) / abstract method that does
actual observer update / after(Subject s)
subjectChange(s) Iterator i
getObservers(s).iterator() while
(i.hasNext() ) update( s,
((Observer) i.next()) )
33
aspect ColorObserver extends ObserverProtocol
/ superimpose roles on participating
classes / declare parents Points implements
Subject declare parents Screen implements
Observer / concretize abstract join points
of interest / protected pointcut
subjectChange(Subject s) call(void
Point.setColor(Color) target(s) /
concretize behavior if event occurs /
protected void update(Subject s, Observer o)
((Screen) o).display(''Color changed, screen
updated'')
34
Visitor

• GoF ''Represent an operation to be performed on
  the elements of an object structure. Visitor lets
  you define a new operation without changing the
  classes of the elements on which it operates.''
• Node classes independent of operations
• Easily define new operations

35
abstract aspect VisitorProtocol / define
roles for elements in object structure /
public interface VisitorNode protected
interface VRegularNode extends VisitorNode
protected interface VLeafNode extends
VisitorNode / role interface to be
implemented by concrete visitors / public
interface NodeVisitor // ...
call-back methods for concrete visitors
public void visitRegularNode(VisitorNode node)
public void visitLeafNode(VisitorNode
node) ...
36
// ... rest of aspect VisitorProtocol
/ attachment of the double-dispatch protocol /
public void VisitorNode.accept(NodeVisitor v)
public void VRegularNode.accept(NodeVisit
or v) v.visitRegularNode(this)
public void VLeafNode.accept(NodeVisitor v)
v.visitLeafNode(this)
37
aspect ConcreteVisitor extends VisitorProtocol
/ superimpose roles on participating
classes / declare parents Node implements
VisitorNode declare parents RegularNode
implements VRegularNode declare parents
LeafNode implements VLeafNode class MyVisitor
implements VP.NodeVisitor ... public
void visitRegularNode(VP.VisitorNode node)
// do some operation on a regular node...
public void visitLeafNode(VP.VisitorNode
node) // do some operation on a leaf
node...
38
Decorator

• GoF ''Attach additional responsibility to an
  object dynamically. Decorators provide a flexible
  alternative to sub classing for extending
  functionality.''
• Add extra responsibility or functionality
• Control decoration of individual objects based
  on the context they are in

39
class ConcreteOutput public void
print(String s) System.out.println(s)
aspect StarDecorator dominates
BracketDecorator / identify the execution
points of interest / protected pointcut
printCall(String s) call( void
ConcreteOutput.print(String)) args(s) /
parameter s is the string to be decorated /
protected void around(String s) printCall(s)
s '' '' s '' ''
proceed(s)
40
(No Transcript)
41
Bachelor Project Results

• Patterns with only superimposed roles benefit
  most from AspectJ, in contrast to patterns with
  only defining roles
• Although AspectJ improves modularity of many
  patterns, sometimes the AspectJ implementation
  has negative points
• AspectJ allows separating the mechanism and
  policy of some design patterns

42
Any Questions?

• This presentation as well as the bachelor project
  report with the analysis of pattern
  implementations in Java and AspectJ can be
  downloaded from the course website at
  http//www.cs.vu.nl/ralf/poosd/