SE 510 Principles and Applications of Software Design

1
SE 510Principles and Applications of Software
Design

• Aspect Oriented Programming
• October 5, 2005
• Jeff Webb

2
Aspect-Oriented Programming

• Gregor Kiczales, John Lamping, Anurag Mendhekar,
  Chris Maeda, Cristina Lopes, Jean-Marc Loingtier
  and John Irwin
• 1997
• Xerox Palo Alto Research Center

3
Background Information

• The process of functional decomposition breaks a
  system down into smaller and smaller parts.
• Units of behavior or function.
• Programming languages provide mechanisms that
  allow us to define abstractions for these small
  parts and then compose them into systems.

4
Generalized Procedure Based Languages

• Procedural
• OO
• Functional

5

• It feels comfortable to talk about what is
  encapsulated as a functional unit of the overall
  system.
• ..
• We will be considering units of decomposition
  that are not functional.

6
The Problem

• There are many programming problems for which
  neither procedural nor object-oriented techniques
  are sufficient to clearly capture some of the
  important design decisions the program must
  implement.
• Examples
• Error detection and handling
• Security issues
• Logging

7
Without AOP

• The implementation of those design decisions will
  be scattered throughout the code, resulting in
  tangled code.

8
The Problem

• AOPs core idea is separating the business logic
  in an application from the common services that
  support it.

9

• The issues that make these design decisions so
  hard to clearly capture in code are called
  ASPECTS
• The problem is that they CROSS-CUT the systems
  basic functionality.

10
Example

• LISP
• Image processing functions
• Some primitive functions are developed and some
  compound functions
• Requirements
• Easy to develop and maintain
• Efficient use of memory

11
A primitive image function or!

• Public Image or! (Image a, Image b)
• Image result new Image()
• For i from 1 to width do
• For j from 1 to height do
• set-pixel (result i j)
• or ((get-pixel a i j)
• (get-pixel b i j))
• Return result

12
More functions

• Functionality Implementation
• pixelwise logical operations written using loop
  primitive as
• or!, and!, not! above.
• shift image up, down written using loop
  primitives
• slightly different loop structure.
• difference of two images Function remove! (a b)
• and!( a (not! b))
• pixels _at_ top edge of a region Function
  top-edge! (a)
• remove!(a (down! a))
• pixels _at_ bottom edge of a region Function
  bottom-edge! (a)
• remove!( a (up! a))

13
Easy to develop and maintain

• High level function to return horizontal edge
  pixels
• Function horizontal-edge! (a)
• Return or! (top-edge!(a) bottom-edge!(a))

14
Hierarchical structure
15
Not memory efficient

• Each procedure loops over a number of images
• Many output images are created frequently, only
  to be quickly consumed by another loop
• Results in excessively frequent memory references
  and storage allocation
• Leads to cache misses, page faults and terrible
  performance

16
Solution to this problem

• Take a more global approach and hand code the
  entire process into one, efficient piece of code.

17
Memory efficient

• Public Image horizontal-edge! (a)
• Image result, a-up, a-down new Image()
• a-up up!(a) a-down down!(a)
• For i from 1 to width do
• For j from 1 to height do
• set-pixel(result i j)
• or (and( (get-pixel a i j)
• (not (get-pixel a-up i j)))
• and (get-pixel a i j)
• (not (get-pixel a-down i j))
• )
• // j for
• // i for
• Return result

18
Problems

• Tangled code
• Difficult to maintain
• Destroyed the original clear functional structure

19
Hierarchical structure
20
Data Flow Diagram
or!
and!
and!
not!
not!
up!
up!
a
21
Memory efficient

• Public Image horizontal-edge! (a)
• Image result, a-up, a-down new Image()
• a-up up!(a) a-down down!(a)
• For i from 1 to width do
• For j from 1 to height do
• set-pixel(result i j)
• or (and( (get-pixel a i j)
• (not (get-pixel a-up i j)))
• and (get-pixel a i j)
• (not (get-pixel a-down i j))
• )
• // j for
• // i for
• Return result

22
Crux of the problem

• Two properties are being implemented
• 1 Functionality
• 2 Loop fusion ( for the sake of memory )
• Both properties originate from primitive filters
• They must compose differently as filters are
  composed

23
Cross-Cutting

• Functionality composes hierarchically in the
  traditional way
• Loop fusion composes by fusing the loops of those
  primitive filters that
• have the same loop structure
• end up in a producer/consumer relationship at
  runtime
• The properties cross-cut one another
• This cross-cutting phenomena results in the
  tangled code

24
Problem with GP languages

• Only provide one composition mechanism
• Programmer must do the co-composition manually
• Leads to complexity and tangling

Solution

• Use two different languages, One for the
  components and one for the aspects.

25
Component

• Can be cleanly encapsulated in a generalized
  procedure (i.e. object, method, procedure, API)
• By cleanly, we mean well-localized, and easily
  accessed and composed as necessary.

26
Aspect

• Can not be cleanly encapsulated in a generalized
  procedure.
• 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.
• Examples of aspects include memory access
  patterns and synchronization of concurrent
  objects.

27
Goal of AOP

• 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.

28
Programming with Aspects

• Rewrite the components so they can be read by the
  weaver
• Create an aspect program
• Weave the two together to produce optimal
  intermediate code

29
Component Re-write

• Public iterater Image pixelwise (Image a, Image
  b, operator MyOp)
• Image result new Image()
• For i from 1 to width do
• For j from 1 to height do
• set-pixel (result i j)
• MyOp ((get-pixel a i j)
• (get-pixel b i j))
• Return result
• Function or! (a a)
• pixelwise( a b or)

30
Component weaving

• Weaver reads the component program and builds a
  data graph, noting the nodes and edges

or!
and!
and!
not!
not!
31
Aspect Language program

• cond
• if (loop-shape(currentNode) pointwise
• and
• loop-shape(nextNode) pointwise)
• fuse (currentNode, nextNode, pointwise)
• // end if
• // end cond
• Where pointwise is an iterator function that
  takes 2 image parameters and an operator
  paramater.

32
Aspect weaving

• Checks whether two nodes, that are connected by a
  data flow edge, both have a similar loop
  structure,
• and if so it fuses them into a single loop that
  also has the particular structure,
• and that has the appropriate merging of the
  inputs, loop variables and body of the two
  original loops.

33
Weaving output

• Produces an optimally structured C program
• Note that the real system required about a dozen
  or so aspects.
• Program analysis and understanding are to
  significant for a compiler to be able to use

34
Results

• Hand coding the basic functionality of original
  program required 768 loc (LISP)
• The hand coded, optimized version implements
• Fusion optimization
• Memoization of intermediate results
• Compile time memory allocation
• Specialized intermediate data structures
• 35213 loc
• The tangled code is extremely difficult to
  maintain, since small changes to the
  functionality require mentally untangling and
  then re-tangling it.

35
Results

• Base implementation and three aspect programs
  1039 loc
• Time efficiency was comparable to hand coded
  version
• Space efficiency was better than hand coded
  version.

36

• Questions ?

37
References

• Gregor Kiczales, John Lamping, Anurag Mendhekar,
  Chris Maeda, Cristina Lopes, Jean-Marc Loingtier
  and John Irwin. Aspect Oriented Programming,
  Proceedings of the ECOOP, Volume 32, issue 1ess,
  March 1997, pages 220-242
• http//jroller.com/page/colyer/20040531
• http//www.builderau.com.au/architect/0,39024564,3
  9183763,00.htm
• Memoization http//dictionary.reference.com/searc
  h?qmemo20function

38
Additional Example
Person Owns Dog
Taken from http//jroller.com/page/colyer/20040
531
39
Person Owns Dog

• class Person
• attribute numOfDogsOwned
• simple accessor method getNumDogsOwned()

Person
numOfDogsOwned
GetNumDogsOwned()
40
Person Owns Dog

• /
• not a dog in sight...
• /
• public class Person
• private String lastName
• private Address address
• ...
• public String getLastName()
• return lastName
• ...

41
Person Owns Dog

• /
• not a person in sight...
• /
• public aspect DogOwnership
• public interface IDogOwner
• private int IDogOwner.numDogsOwned
• public int IDogOwner.getNumDogsOwned()
• return numDogsOwned

42
Person Owns Dog

• - We want to create a dog-owning person
• We could do this by creating a DogOwningPerson
  class
• However dog-owning isn't limited to people
• maybe an Organization can own dogs too?

43
Keep the concept of dog ownership independent of
any one kind of dog owner

• public aspect PersonOwnsDog
• declare parents
• Person implements DogOwnership.IDogOwner

- Now, Person and DogOwnership are independently
reusable
44
Now you can call the getNumDogsOwned method on a
Person

• Person person new Person()
• person.getNumDogsOwned()