Aspect

1
Aspect Component-Oriented Software Development
Divide et Impera, Quo Vadis?
2
AOP Background
What we have been doing all the time ...
Develop tools, techniques, and methods to manage
complexity...
To escape spaghetti-code
For a more effective software maintenance and
evolution ...
3
AOP Background
What we have been doing all the time ...
1 0 lines
123
Lets start small write a program for printing
the numbers 1 to 3 with the 64 technology
4
AOP Background
Print 1 2 3 with 1964 technology
i 1TEST if i lt 4 then goto BODY
else goto END BODY print(i) i i 1
goto TESTEND

• TEST, BODY and END
• but
• what happens when?
• At the beginning i1, how can it be gt 4?
• What the hell does this tangled thing do ?

forward, back, and all around
5
AOP Background
Print 1 2 3 with 1964 technology
Improving style
i 1LOOP print(i) i i 1
if i lt 4 then goto LOOP

• elegant Code
• a single loop
• no crossing gotos
• clear naming
• idiomatic

(actually, we can only encourage good style)
6
AOP Background
Language Support ...
Structured Programming (64 75)

• PS Designer makes the rules
• new words, new grammar
• explicit loop constructs while, do
• explicit tests
• if () then else , case

i 1while (i lt 4) print(i) i i 1

• You will write elegant code
• say while, if you mean it !
• Abstraction a while-loop instead of the
  details
• of loop execution
• code is easier to write, understand, and debug

7
AOP Background
What we have been doing all the time ...
Image Browser with structured programming
8
Simplified Implementation
AOP Background
Browser
main () draw_label(Art Browser) m
radio_menu( Whale, Eagle,
Dogfish) q button_menu(Quit)
while ( ! check_buttons(q) ) n
check_buttons(m) draw_image(n)
9
Improving Style Separation of Concerns
AOP Background
radio_button (n) draw_circle(get_x(),
get_y(), 3)
main () draw_label(Art Browser) m
radio_menu( Whale, Eagle,
Dogfish) q button_menu(Quit)
while ( ! check_buttons(q) ) n
check_buttons(m) draw_image(n)
draw_circle (x, y, r) primitive_oval(x,
y, 1, r)
button_menu(labels) i 0 while (i lt
labels.size) draw_label(labelsi)
set_y(get_y() BUTTON_H) i
draw_label (string) w
calculate_width(string) print(string,
WINDOW_PORT) set_x(get_x() w)
radio_menu(labels) i 0 while (i lt
labels.size) radio_button(i)
draw_label(labelsi) set_y(get_y()
RADIO_BUTTON_H) i
draw_image (img) w img.width h
img.height do (r 0 r lt h r) do
(c 0 c lt w c) WINDOWrc
imgrc
10
Improving Style Separation of Concerns
AOP Background
main () draw_label(Art Browser) m
radio_menu( Whale, Eagle,
Dogfish) q button_menu(Quit)
while ( ! check_buttons(q) ) n
check_buttons(m) draw_image(n)
menus
radio_menu(labels) ...
radio_button (n) ...
button_menu(labels) ...
browser
group by shared secrets common functionality
graphics
draw_image(img) ...
draw_label(string)...
draw_circle(x, y, r) ...

• module with
• clear, narrow interfaces
• no upcalls

11
AOP Background
Language Support
Modular Programming

• clear module interfaces
• explicit
• enforced
• only through front door
• cant read the mail
• type systems
• opacity

module menus exports radio_menu(labels)
button_menu(labels) check_buttons(menu)
abstractions mechanisms for modules
12
AOP Background
Language Support
Modular Programming
haida_browser
menus
graphics

• abstraction mechanisms
• from outside can only see abstraction of module
• enables architectural thinking
• treat the module as its interface
• 100 modules can feel like 1000 lines

13
thinking architecturally
AOP Background
Language Support
Modular Programming
haida_browser
menus
graphics

• abstraction lets us
• look at overall system structure

14
AOP Background
Language Support
thinking architecturally
Modular Programming
menus radio_menu(labels) button_menu(labels)
check_buttons(menu)
haida_browser
graphics

• abstraction lets us
• look at overall system structure
• zoom in on one part of the system at a time

15
AOP Background
Language Support
thinking architecturally
Modular Programming
haida_browser main () draw_label(Haida
Browser) m radio_menu( Whale,
Eagle, Dogfish) q button_menu(Quit
) while ( ! check_buttons(q) ) n
check_buttons(m) draw_image(n)
menus
graphics

• abstraction lets us
• look at overall system structure
• zoom in on one part of the system at a time
• more or less detail

16
Application Systems
AOP Background
What we have been doing all the time ...

• Powerpoint, Outlook, Browsers

17
Variations
AOP Background
pull-down menus
toolbars
toolbar buttons
combo text box und list
color choosers
even with modular programming
this appears to be extremely complex
tangling problems show up again
18
AOP Background
Managing Complexity

• Simula Dahl Nygaard 64, 68
• Smalltalk Alan Kay 70 80
• we cope with complexity all the time
• world has a diversity of complex objects
• abstraction, classification and specialization
• model programs after the world

19
OOP ist useful, powerful elegant
AOP Background
20
AOP Background
What we have been doing all the time ...
crosscutting ? Struktur
structured control constructs
i 1TEST if i lt 5 then goto
BODY else goto END BODY print(i) i
i 1 goto TESTEND
i 1while (i lt 5) print(i) i i 1
modules with narrow interfaces
radio_button (n) draw_circle(get_x(),
get_y(), 3)
main () draw_label(Art Browser) m
radio_menu( Whale, Eagle,
Dogfish) q button_menu(Quit)
while ( ! check_buttons(q) ) n
check_buttons(m) draw_image(n)
draw_circle (x, y, r) primitive_oval(x,
y, 1, r)
button_menu(labels) i 0 while (i lt
labels.size) draw_label(labelsi)
set_y(get_y() BUTTON_H) i
draw_label (string) w
calculate_width(string) print(string,
WINDOW_PORT) set_x(get_x() w)
radio_menu(labels) i 0 while (i lt
labels.size) radio_button(i)
draw_label(labelsi) set_y(get_y()
RADIO_BUTTON_H) i
draw_image (img) w img.width h
img.height do (r 0 r lt h r) do
(c 0 c lt w c) WINDOWrc
imgrc
object classification specialization
21
Crosscutting Concerns
AOP Motivation
Two concerns of a system are crosscutting if
(a) given a modular structure for modelling
one of the concerns,
(b) the other concern does not localizes well
22
Crosscutting Concerns in OO Systems
AOP Motivation
23
Crosscutting Concerns in OO Systems
AOP Motivation
The name of a class should reflect its intrinsic
nature and not a role that it plays in an
association. James Rumbaugh et.al.
Object-Oriented Modeling and Design, 1991.
When in doubt Follow the data! (anonymous )
Wait a minute! Whats normal for me might not
be so for Grady or James!
I know, lets just concentrate on the
basic behavior only for now...
24
Crosscutting Concerns in OO Systems
AOP Motivation
But what about the trainers and the feeders ?
25
Crosscutting Concerns in OO Systems
AOP Motivation
Possible Trainer Requirements
The show shall start with the pink pelicans and
the African geese flying across the stage. They
are to land at one end of the arena and then walk
towards a small door on the side. At the same
time, a killer whale should swim in circles and
jump just as the pelicans fly by. After the
jump, the sea lion should swim past the whale,
jump out of the pool, and walk towards the
center stage where the announcer is waiting for
him.
26
Crosscutting Concerns in OO Systems
AOP Motivation
Show boudBox time start() stop()
performers
Animal startPosition color type setPosition() setC
olor()
Trainers World
Walker prepare() moveFoot() stabilize() atBase() w
alk()
Flyer takeOff() ascend() flapTowards() descend() l
and() fly()
Swimmer jumpInWater() submerge() moveFin() rise()
jumpOutOfWater() swim()
Jumper checkDistance() sprintTO() liftOff() land()
jump()
...
...
...
...
27
Crosscutting Concerns in OO Systems
AOP Motivation
PlayShow concerncrosscuts the
modularstructure of the base concern
28
Crosscutting Concerns in OO Systems
AOP Motivation
Class Diagrams Use Cases
OO Analysis and Design
BO1
BO4
BO2
BO3
C8
BO5
C6
C10
C1
C4
C2
C3
C5
Implementation
C7
C9
29
Crosscutting Concerns in OO Systems
AOP Motivation

• ExpresSys An integrated SEE for expressions

• different tools
• create new expressions
• evaluate
• syntax check
• formatted printing
• optional persistency
• ...
• Different combinations of tools desired
• more than the mere sum of individual tools
• different tool-interaction-semantics

30
Crosscutting Concerns in OO Systems
AOP Motivation
Requirements

• Basic Representation
• Display
• Evaluation
• Testing

31
Crosscutting Concerns in OO Systems
AOP Motivation

• A crosscutting concern in a specific source code
  is a concern that is not well modularized
• Cross-application concerns (transaction,
  persistence, logging) are generally difficult to
  modularize
• Frequently application-specific concerns behave
  like a magic cube It is difficult to modularize
  all of them simultaneously

32
One-Dimensional Decomposition
Form data type Color functionality
Spaghetti-Code
33
One-Dimensional Decomposition
Functional Decomposition
Advantage new functionality easy to integrate
Form data type Color functionality
34
One-Dimensional Decomposition
Functional Decomposition
Disadvantage Integrating new data types requires
the modification of several functionalities
Form data type Color functionality
35
One-Dimensional Decomposition
Object Decomposition
Advantage New data types easy to integrate
Form data type Color functionality
36
One-Dimensional Decomposition
Object Decomposition
Disadvantage Integrating new functionality
requires modification of several classes
Form data type Color functionality
37
One-Dimensional Decomposition

• Artifact typically decomposed in only one way,
  often determined by the language

• Artifact typically decomposed in only one way,
  often determined by the language
• OO permits just data type decomposition

• Artifact typically decomposed in only one way,
  often determined by the language
• OO permits just data type decomposition
• procedural languages just functional decomposition

Training
SeaLeon.swim()
Whale.swim()
Swimmer
Whale.walk()
SeaLeon.walk()
Walker
Veterinary
SeaLeaon
Whale
38
One Dimensional Decomposition

• Concern structure is multi-dimensional
• Module structure is 1-dimensional
• Separation can be achieved only for one kind of
  concern
• Concerns in other dimensions are not separated
• Non-dominant concerns typically cut across
  modules encapsulating dominant concerns
• Scattering units affecting a single concern
  scattered across many modules
• Tangling a single module contains units
  affecting several concerns

39
AOP The Idea

• Crosscutting is an inherent feature of complex
  systems
• Crosscutting-Concerns
• have a clear goal
• have their own structure
• Involved abstractions, with their definitions
• inter-concern boundary crossings, also called
  join points
• Controll- and data flow
• Hence, lets capture the structure of
  crosscutting concerns explicitly...
• in a modular way
• with programming and tool support

40
AOP The Idea
class User private UserID id Library
theLibrary Printer thePrinter public
User(String n) id new UserID(n) public
boolean getBook (String title) BookID
aBooknull try aBook
theLibrary.getBook(id, title) catch
(RemoteException e) try
thePrinter.print(id, aBook) catch
(RemoteException e) return true
public UserID get_uid() return id class
UserID private String name public
UserID(String n) name n public String
get_name() return name
interface LibraryInterface extends Remote
public BookID getBook(UserID u, String title)
throws RemoteException public PostScript
getBookPS(BookID bid) throws RemoteException c
lass Library extends UnicastRemoteObject
implements LibraryInterface Hashtable
books Library() throws RemoteException
books new Hashtable(100) public BookID
getBook(UserID u, String title) throws
RemoteException System.out.println("REQUEST
TO GET BOOK " title) if(books.containsKey(t
itle)) Book b (Book)books.get(title)
System.out.println("getBook Found it"
b) if (b ! null) if
(b.get_borrower() null)
b.set_borrower(u) return b.get_bid()
return null public
PostScript getBookPS(BookID bid) throws
RemoteException if (books.containsKey(bid.ge
t_title())) Book b (Book)books.get(bid.g
et_title()) if (b ! null) return
b.get_ps() return null
class Book private BookID id
private PostScript ps private UserID
borrower public Book(String t, String a,
String i, PostScript p) id new
BookID(t,a,i) ps p public UserID
get_borrower() return borrower public void
set_borrower(UserID u) borrower u public
PostScript get_ps() return ps public
BookID get_bid() return id class BookID
private String title private
String author private String isbn public
BookID(String t, String a, String i) title
t author a isbn i public
String get_title() return title
interface PrinterInterface extends Remote
public boolean print (UserID u, BookID b) throws
RemoteException public class Printer extends
UnicastRemoteObject
implements PrinterInterface private Vector
jobs new Vector(10, 10) private Library
theLibrary public Printer() throws
RemoteException public boolean print (UserID
u, BookID b) throws RemoteException
PostScript psnull try ps
theLibrary.getBookPS(b) catch
(RemoteException e) Job newJob new Job
(ps, u) return queue(newJob) boolean
queue(Job j) //... return true
41
AOP The Idea
aspect UserRequestThreads introduce (Terminal
Library Printer) Thread thread
void interruption() thread.interrupt()
advise (Document search(String key)
void print(Document doc)) Terminal
catch (Exception e) System.out.println("Op
eration interrupted at user's request")
lib.interruption(thisJoinPoint.object)
advise (Terminal (Document search(String
key) void print(Document doc)))
(Library (Document search(Terminal t, String
key) String
quota(Terminal t, String username)
boolean print(Terminal t, Document
doc))) (Printer boolean
print(Document doc)) static before
thread Thread.currentThread()
advise Library (Document search(Terminal t,
String key) String
quota(Terminal t, String username)) static
catch (Exception e) System.out.println("Se
arch interrupted at user's request")
return null . . .
public class Library private Hashtable docs
new Hashtable() private Hashtable users new
Hashtable() private Printer printer
private class TerminalInfo Terminal
terminal TerminalInfo term
Library(Printer p) printer p for
(int i 0 i lt 100 i) Document doc
new Document("book" String.valueOf(i))
docs.put(doc, "book" String.valueOf(i))
for (int i 0 i lt 100 i) User
user new User("user" String.valueOf(i))
users.put(user, "user" String.valueOf(i))
public Document search(Terminal t,
String key) term.terminal t return
(Document)docs.get(key) public boolean
print(Terminal t, Document doc)
term.terminal t return printer.print(doc)
public String quota(Terminal t, String
username) . . . public static void
main(String args) . . .
class Document String name Document(String
n) name n
class User String name int quota
User(String n) name n
public class Terminal private Library lib
Terminal (Library l) lib l public void
logon() public void gui() public
Document search(String key) return
lib.search(this, key) public void
print(Document doc) lib.print(this,
doc) void run() termthread
Thread.currentThread() while (true)

public class Printer boolean print(Document
doc) System.out.println("Printing "
doc.name) try Thread.sleep(3000)
catch (InterruptedException e)
System.out.println("Print interrupted")
return false return true
42
Why does this all matters?
AOP The Idea

• to the computer?
• it doesnt, issues like this dont confuse the
  computer!
• but, 10x maintenance vs. original development
• programs always change
• debug
• add new functionality
• integrate with new systems
• programs must be readable by others
• have to tell a story
• have a coherent structure
• focus on the key points

programs must be well-written
43
Value of better structure
AOP The Idea

• dont spend 50 of resources on 10 of system
• resources go to other product improvements
• higher quality code
• fewer defects
• defects are fixed more easily
• ability to respond to market changes

44
Component Revolution
The Motivation
45
Component Revolution
Components and Objects
46
Component Revolution
Component Frameworks
Object Transaction Monitors (OTMs)

• If you play the OTM rules, your components
  become
• transaktional,
• robust,
• persistent,
• secure,
• ...
• OTM makes it so

Dont call us, we will call you
47
Components and AOSD

• Although independent developments they follow
• similar goals - divide et impera
• Does one of the approaches renders the other
• obsolete ?
• Do they complement each other? If yes, how?

48
Components and AOSD
Components Considered tangled

• Excessive coding conventions
• Object Creation
• Calls to other components
• Not integrated in a PL
• No enforcement of conventions
• Loss of static type checking

If you play OTM rules, your components ...
49
Components and AOSD
Components Considered tangled

• OK, I get transactions, access control, etc. for
  free (?)
• But what if, some control is desired?
• over the set of services provided?
• over the mechanisms, that are used for the
  services?

• Set of provided services useful (based on
  experience) but arbitrary
• Difficult to add new services
• Difficult to modify existing services

50
Components and AOSD
Components Considered tangled
An entity bean is better suited to represent a
coarse- grained business object that contains
complex behavior ... Suns Guidelines
No help regarding separation of
application-specific concerns
51
Components and AOSD
Am I saying AOP makes components obsolete?
NO !
52
Components and AOSD
ASOD Mechanisms

• Cope with crosscutting concerns at the language
  level
• Concerns can be added and removed freely (in
  contrast to a predefined set of services)
• Full programming language integration

53
ASOC Mechanisms violate important component
prerequisites
Components and AOSD
ASOD Mechanisms

• Black Box Reuse
• Often precise knowledge of the source required
• Independent Extensibility
• Difficult to resolve inter-concern dependencies
• Closed World Assumption / Separate Compilation
• Often global compilation required
• Binary Components
• Often source code required

54
Summary
Components and AOSD

• Component-based app-servers and ASOC models have
  a common goal effective separation of concerns
• Scope is different
• App-Servers focus on large-scale distributed
  components
• ASOC models enable fine-grained separation on the
  language level
• Both have different strengths and weaknesses

We should strive for a combination of both
technologies!
55
AOP Our Vision
Aspectual component
Aspectual component
56
AOP Our Vision
ExpresSys Basic-Representation
Expression type getType()
left
right
NumericExp value int getValue()int setValue
(int) void
BinaryExp getLeft() Expr getRight()
Expr setLeft(Expr) setRight(Expr)
UnaryExp getOperand()Expr setOperand(Expr)
UnaryMinus
Minus
Plus
Multiplication
Division
57
AOP Our Vision
ExpresSys - Display
Node displayType() display()
System.out.println(literal )
Leaf displayValue() displayType() display()
Composite children() NodeIterator display
()
super.display() System.out.println(lt ) for
all c in children() c.display() System.out.prin
tln(gt )
super.display() System.out.println(lt
) displayValue() System.out.println(gt )
58
AOP Our Vision
ExpresSys - SyntaxCheck
Expression errorNo int errorStatus Error
syntaxCheck() boolean getErrorNumber()int getEr
rors()Error
return true
Literal check()
UnaryExpression getOperand()
Expression syntaxCheck()
if getOperand() null // store error info
return true else return
getOperand().check()
BinaryExpression getOtherOperand()
Expression syntaxCheck()
59
AOP Our Vision
ExpresSys Evaluation
ltltinterfacegtgt Expression eval() int
Numeric getValue()int eval() int
BinaryExpression leftOperand()
Expression rightOperand() Expression
UnaryExpression getOperand()Expression
UnaryMinus eval()
Minus eval()
Plus eval()
Multiply eval()
Division eval()
60
Our Vision Integration via Contexts
Coarse-Grained Join Points
Representation
Display

Expression
Node
NumericExp
UnaryExp
BinaryExp
Leaf
Composite
UnaryMinus
Minus
Plus
Multiply

• Join points (JP) at the class level
• Subclasses can inherit join points of the
  superclass
• A subclass of B ? JP(A) subclass of JP(B)

61
Our Vision Integration via Contexts
Coarse-Grained Join Points
class DeployExpr E joins
structure.Expression, display.Node,
syntaxCheck.Expression void
displayType() System.out.println(
getType() ) U extends E joins
structure.UnaryExp, display.Composite,
syntaxCheck.UnaryExpression void
children() () return new Iterator(
getOperand() ) void
rightHand() return getOperand() . . .
62
Our Vision Integration via Contexts
Coarse-Grained Join Points
class DeployExpr E joins
structure.Expression, display.Node,
syntaxCheck.Expression void
displayType() System.out.println(
getType() ) U extends E joins
structure.UnaryExp, display.Composite,
syntaxCheck.UnaryExpression void
children() () return new Iterator(
getOperand() ) void
rightHand() return getOperand() . . .
63
Our Vision Integration via Contexts
Coarse-Grained Join Points
class DeployExpr E joins
structure.Expression, display.Node,
syntaxCheck.Expression void
displayType() System.out.println(
getType() ) U extends E joins
structure.UnaryExp, display.Composite,
syntaxCheck.UnaryExpression void
children() () return new Iterator(
getOperand() ) void
rightHand() return getOperand() . . .
Inherits the JP-definitions from the supertype
64
Our Vision Integration via Contexts
Coarse-Grained Join Points
public class Client public static void
main( String args ) Plus p new
Plus(new NumericExp(42),
new NumericExp(23)) Minus m new Minus(p,
new NumericExp(40)) p.display()
context (new DeployExpr()) Display_SyntaxCheck_
Minus m1 m m1.display()
m1.getLeft().display() boolean b
m1.syntaxCheck() m1.getErrorNumber()
p.setLeft(new PlusExp(m, null))

public class Client public static void
main( String args ) Plus p new
Plus(new NumericExp(42),
new NumericExp(23)) Minus m new Minus(p,
new NumericExp(40)) p.display()
context (new DeployExpr()) Display_SyntaxCheck_
Minus m1 m m1.display()
m1.getLeft().display() boolean b
m1.syntaxCheck() m1.getErrorNumber()
p.setLeft(new PlusExp(m, null))

public class Client public static void
main( String args ) Plus p new
Plus(new NumericExp(42),
new NumericExp(23)) Minus m new Minus(p,
new NumericExp(40)) p.display() //
compiler error context (new DeployExpr())
Display_SyntaxCheck_Minus m1 m
m1.display() m1.getLeft().display()
boolean b m1.syntaxCheck()
m1.getErrorNumber() p.setLeft(new
PlusExp(m, null))
public class Client public static void
main( String args ) Plus p new
Plus(new NumericExp(42),
new NumericExp(23)) Minus m new Minus(p,
new NumericExp(40)) p.display() //
compiler error context (new DeployExpr())
Display_SyntaxCheck_Minus m1 m
m1.display() m1.getLeft().display()
boolean b m1.syntaxCheck()
m1.getErrorNumber() p.setLeft(new
PlusExp(m, null))
public class Client public static void
main( String args ) Plus p new
Plus(new NumericExp(42),
new NumericExp(23)) Minus m new Minus(p,
new NumericExp(40)) p.display() //
compiler error context (new DeployExpr())
Display_SyntaxCheck_Minus m1 m
m1.display() // (42 23) - 40 displayed
m1.getLeft().display() boolean b
m1.syntaxCheck() m1.getErrorNumber()
p.setLeft(new PlusExp(m, null))

public class Client public static void
main( String args ) Plus p new
Plus(new NumericExp(42),
new NumericExp(23)) Minus m new Minus(p,
new NumericExp(40)) p.display() //
compiler error context (new DeployExpr())
Display_SyntaxCheck_Minus m1 m
m1.display() // (42 23) - 40 displayed
m1.getLeft().display() // 42 23 displayed
boolean b m1.syntaxCheck()
m1.getErrorNumber() p.setLeft(new
PlusExp(m, null))
public class Client public static void
main( String args ) Plus p new
Plus(new NumericExp(42),
new NumericExp(23)) Minus m new Minus(p,
new NumericExp(40)) p.display() //
compiler error context (new DeployExpr())
Display_SyntaxCheck_Minus m1 m
m1.display() // (42 23) - 40 displayed
m1.getLeft().display() // 42 23 displayed
boolean b m1.syntaxCheck()
m1.getErrorNumber() // 0 displayed
p.setLeft(new PlusExp(m, null))
public class Client public static void
main( String args ) Plus p new
Plus(new NumericExp(42),
new NumericExp(23)) Minus m new Minus(p,
new NumericExp(40)) p.display() //
compiler error context (new DeployExpr())
Display_SyntaxCheck_Minus m1 m
m1.display() // (42 23) - 40 displayed
m1.getLeft().display() // 42 23 displayed
boolean b m1.syntaxCheck()
m1.getErrorNumber() // 0 displayed
p.setLeft(new PlusExp(m, null)) //ok

65
Our VisionDecorating Objects within Contexts
42
23

40
-
m
p
aDeployExpr
main
66
Our VisionDecorating Objects within Contexts
42
23
m1.getLeft()

m1.getRight()
40
-
m
p
aDeployExpr
main
67
Our Vision Decorating Objects
Late Binding

• Static type of the variable within the context
  can be a
• supertype of the dynamic type of the incomming
  object.
• The most specific JP will be used

Plus p new Plus(new NumericExp(42),
new NumericExp(23)) context( ... ) E
e p e.eval()
68
Our Vision Decorating Objects
Late Binding

• Static type of the variable within the context
  can be a
• supertype of the dynamic type of the incomming
  object.
• The most specific JP will be used

Plus p new Plus(new NumericExp(42),
new NumericExp(23)) context( ... ) E
e p e.eval()
69
Our Vision Integration via Contexts
Fine-Grained Join Points
Key Points in the dynamic calling graph
a Plus
and returns or throws
dispatch
and returnsor throws
a Minus
dispatch
and a return or exception is received by this
method
70
Our Vision Integration via Contexts
Fine-Grained Join Points
a message is received by this object
a value is received or an exception is caught
by this object
Predefined JPs
a value is returned or an exception is thrown by
this object
a message is sent by this object
a value is returned or an exception is thrown by
this method
a message is sent from within this method
a method is executed
a value is received or an exceptionis caught
in this method
71
Our Vision Integration via Contexts
Fine-Grained Join Points
User Defined JPs
Each time, when a BinaryExp receives a call of
the method void setLeft(Exp) or void setRight(Exp)
executionPoint setters()
receptions(void BinaryExp.setLeft(Exp))
receptions(void BinaryExp.setRight(Exp))
72
after advice
Our Vision Integration via Contexts
Fine-Grained Join Points
Code will be executed on leaving the JPs
pointcut setters() receptions(void
BinaryExp.setLeft(Exp)) receptions(void
BinaryExp.setRight(Exp)) after() setters()
ltcode der nach den set-Aufrufe ausgeführt
wirdgt
73
Our Vision Integration via Contexts
Fine-Grained Join Points
// class DeployExpr (continued) . . .
executionPoint setters (Expression receiver,
Expression newValue) (
reception(receiver.set(Expression newValue))
( receiver instanceOf BinaryExp
receiver instanceOf UnaryExp ) before
setters(Expression e, Expression par) if
(par.syntaxCheck()) throw new
Exception(Trying to assign a
syntactically incorrect operand to
e.toString())
System.out.println( about to change )
e.display()
74
Our Vision Integration via Contexts
Fine-Grained Join Points
public class Client public static void main(
String args ) Plus p new Plus(new
NumericExp(42), new NumericExp(23))
Minus m new Minus(p, new NumericExp(40))
context (new DeployExpr())
Display_SyntaxCheck_Minus m1 m
m1.setRight(new PlusExp(new NumericExp(65),
null)) // exception Trying to assign a
syntactically // incorrect expression 65
m.setLeft(new PlusExp(new
NumericExp(65), null)) // OK
75
AOP Our Vision
State of the Art

• A simplified version of the model is
  prototypically
• realized in the language JADE
• Java ADapter Extension
• Automatic type dekoration of kooperating groups
  
• of Objects
• Only additive decoration via context -
  existing
• behavior will not be changed
• Fine-grained JPs are not yet supported

76
AOP Our Vision
State of the Art New OO Composition Model

• Complete decoration
• Declarative choice of composition semantics for
  
• decorater-decorated-relationship
• Conceptually already worked out
• paper at OOPSLA 2001
• Join work with K. Ostermann, Siemens / TUD
• Prototypical Realisation
• in the reflective language Lua
• Contexts as meta-programs, which influence the
  workings of
• the VM
• Join work with S. Herrmann, TU Berlin

77
AOP Our Vision
State of the Art In Progress

• Integration of the detailed JP model
• Complete model in a statically typed language
  (Java)
• Type system issues

78
AOP ...
Eureka!!! AOP is the solution !
79
Thank you for your attention!