beyond oop - dcc.uchile.cletanter/courses/cc72q/tanter-asoc-june05… · Éric tanter – u.chile...
TRANSCRIPT
Éric Tanter – U.Chile [june | 2005] 1
Beyond OOPAdvanced Separation of Concerns
MetaprogrammingReflection
Aspect-Oriented Programming
Eric TanterDCC/CWR University of Chile
Éric Tanter – U.Chile [june | 2005] 2
Contents
● A brief history of programming
● Advanced modularization problems
● Reflection and metaprogramming
● Aspect-oriented programming
Éric Tanter – U.Chile [june | 2005] 3
Part I
A Quick History of Programming
Adapted from Brian Hayes, “The Post-OOP Paradigm”,American Scientist, 91(2), March-April 2003, pp. 106-110
Éric Tanter – U.Chile [june | 2005] 4
Software?
● Real challenge: building the machine
● Software was not important as such
● First programs (40's)
● Written in pure binary: 0s and 1s
● Explicit memory address management
Éric Tanter – U.Chile [june | 2005] 5
Then came the assembly...
● Assembly language
● No more raw binary codes
● Symbols: load, store, add, sub
● Converted to a binary program by an assembler
● Calculates memory addresses
● First program to help programming
Éric Tanter – U.Chile [june | 2005] 6
...and then, compilers
● Assembly required knowledge of the specificcomputer instruction set
● Higher-level languages (e.g. Fortran)
● Think in terms of variables/equations
● Not registers/addresses
● 60's: big projects = late/costly/buggy
Éric Tanter – U.Chile [june | 2005] 7
Structured Programming
● Manifesto by Edsger W. Dijkstra:
“Go to statement considered harmful” [1968]
● Build programs out of sub-units
● Single entrance point, single exit
● 3 constructs:
● Sequencing, alternation, and iteration
● Proof that these 3 idioms are sufficient to expressall programs by Bohm & Jacopini [1966]
Éric Tanter – U.Chile [june | 2005] 8
Structured Programming
● Early programming principles
● Top-down design and stepwise refinement
● Dijkstra [1968]
● Introduction of the notion of modularity and theprinciple of Separation of Concerns (SOC)
● Self-contained units with interfaces between them
● Parnas [1972]
● Notion of encapsulation (data hiding)
● Internal working of modules kept private
Éric Tanter – U.Chile [june | 2005] 9
Variety of Paradigms
● Different ways of structuring programs
● Functional, declarative, logic, procedural, object-oriented...
● Ways to solve a problem
● through divide-and-conquer
● Decompose – solve – recompose
Éric Tanter – U.Chile [june | 2005] 10
Object orientation
● Problem with procedural programs
● Procedures and data structures are separate butinterdependent
● Changing implementation
● Changing representation
● Contribution of OOP
● Pack data and procedures together
● Objects communicate through messages
Éric Tanter – U.Chile [june | 2005] 11
Object orientation
● Key mechanisms
● Instantiation (or cloning)
● Inheritance
● Polymorphism
● Aggregation and delegation
Éric Tanter – U.Chile [june | 2005] 12
Object-oriented languages
● Origins
● SIMULA by Dahl and Nygaard (60s)
● SIMULA I (62-65), SIMULA 67 (inheritance)
● Parnas ideas on encapsulation
● Smalltalk (70s)
● Alan Kay & Co. at Xerox PARC
● Introduce GUI and interactive program execution
● Then
● C++, Smalltalk-80, Java, ...
● OO versions of older languages, e.g. CLOS
Éric Tanter – U.Chile [june | 2005] 13
Part II
Advanced Modularization Problemsin (OO) Programs
Éric Tanter – U.Chile [june | 2005] 14
OOP Promises
● Major objectives
● Evolution, extension
● Maintenance
● Reuse
● Additional mechanisms
● Frameworks
● Design Patterns [GoF95]
● “the quality without a name” [Alexander,1979]
Éric Tanter – U.Chile [june | 2005] 15
Apache Tomcat case study
● Realized by AspectJ folks
● eclipse.org/aspectj
● Illustrates modularization problems in the ApacheTomcat engine
Éric Tanter – U.Chile [june | 2005] 16
XML Parsing in Tomcat
● Cleanly modularized in one class
Éric Tanter – U.Chile [june | 2005] 17
URL Pattern matching inTomcat
● Cleanly modularized
● one abstract class/interface and one class
Éric Tanter – U.Chile [june | 2005] 18
Logging in Tomcat
● Is this modularized???
Éric Tanter – U.Chile [june | 2005] 19
Session Expiration in Tomcat
● Is this modularized???
Éric Tanter – U.Chile [june | 2005] 20
Problem: decomposition
● Challenge in OOP
● The right decomposition into classes/objects
● e.g., modeling polygons, animals, ...
● Tyranny of the dominant decomposition
● Some issues are not easily arranged in a tree-like hierarchy
● Multiple inheritance (C++)
● Complex semantics due to merging conflicts
Éric Tanter – U.Chile [june | 2005] 21
Problem: modularization
● Fact: code scattering
● Code replication = same code repeated in differentplaces
● Code tangling = code for different concerns in thesame place
● Why?
● Nature of concerns
Éric Tanter – U.Chile [june | 2005] 22
Nature of concerns
● Some concerns are not related to applicationlogic
● exception handling, security, persistence, distri-bution, concurrency, etc.
● Such non-functional concerns are often mixedwith the application logic
Éric Tanter – U.Chile [june | 2005] 23
Nature of concerns
● Some concerns do not fit in the global decomposi-tion scheme
● They crosscut the application's structure
● Usually handle interactions between modules
● e.g., display update in graphic editor
Éric Tanter – U.Chile [june | 2005] 24
Example
public void withdraw (double amount)throws NotAllowedException {
if(!authorized(Thread.currentThread())throw new NotAllowedException();
try {checkAmount(amount); doWithdraw(amount);notifyListeners();
}catch(LimitAmountExceeded e){
doWithdraw(e.getMaxAmount());}
}
This is code tangling
Éric Tanter – U.Chile [june | 2005] 25
Example
boolean search(Object e){boolean found = false;Enumeration elems = this.elements();while(!found && (elems.hasMoreElements()))
found = e.equals(elems.nextElement())return found; }
● Should be located in many classes (that under-stand the elements() message)
● Such classes are not located in the same classhierarchy: this is a crosscutting concern
Éric Tanter – U.Chile [june | 2005] 26
Example
● Design patterns
● Provide design reuse, but no code reuse
● Some patterns lead to tangled code
SubjectObserver 1
Observer 2
register(this)
stateChanged(this)
notifyObservers()
Éric Tanter – U.Chile [june | 2005] 27
Summary of Issues
● Tangled code
● Readability is decreased
● Detecting/resolving errors
● Reusability is killed
● Replicated code
● Hard to evolve, extend, maintain
● Crosscutting concerns
● No explicit structure
● Hard to reason about, have a global vision
Éric Tanter – U.Chile [june | 2005] 28
“Post-OOP”
● Address modularization issues further
● Extend OOP rather than replace it
● Program generation
● Metaprogramming and reflection
● Aspect-oriented programming
● Etc...
● Adaptive programming, composition filters, hyper-spaces, subject-oriented programming, ...
Éric Tanter – U.Chile [june | 2005] 29
Generative Programming
● Transform high-level specs into a ready-to-runprogram
● Old dream
● Area of success: compiler compilers
● Take grammar as input and generate compilers
● Generative Programming
● Idem for other domains
● Manufacturing, product-line engineering
● Create families of tailored programs
Éric Tanter – U.Chile [june | 2005] 30
Modularity Requirements
● Concerns in their own modules
● “Connect” them at appropriate places
● Issues
● Intrusiveness, obliviousness
● Symmetry of the approach
● Genericity, degree of coupling
● Expressive power given to modules
Éric Tanter – U.Chile [june | 2005] 31
Part III
Reflection and Metaprogramming
Éric Tanter – U.Chile [june | 2005] 32
Introduction
History and concepts
Éric Tanter – U.Chile [june | 2005] 33
Programs and Data
● Distinction data/program
● appears in 1830s, by Charles Babbage
● Difference Engine No.2
● The store with data and the mill with programs
● 1958, von Neumann
● Architecture of numerical computer
● Idea: store programs in memory, that same wheredata is stored
● Perspective: a program could alter its own in-structions!
Éric Tanter – U.Chile [june | 2005] 34
Programs and Data
● From computing theory
● Lambda calculus (Church)
● Universal Turing Machine
● Metaprogram
● A program that affects a program
● Metaprogramming
● Developing metaprograms
Éric Tanter – U.Chile [june | 2005] 35
Reflection
● Philosophy (Brian Cantwell Smith)
● Study on psychology and human experiences
● Foundations of consciousness
● Varieties of self-references
● Varietes of self-descriptions
● Definition of reflection:
“A process' integral ability to represent, operate on, andotherwise deal with itself in the same way that it represents,operates on and deals with its primary subject matter”
Éric Tanter – U.Chile [june | 2005] 36
Reflection in Computer Science
● Artificial intelligence: self-reasoning systems
● Brian Smith [1982]
● “reflection and semantics in a procedural language”
● 3LISP with Jim Des Rivieres
● Pattie Maes [1987]
● “computational reflection”
● Merging OOP languages and reflective architectures
● Smalltalk, Scheme, Loops, ObjVLisp,...
Éric Tanter – U.Chile [june | 2005] 37
Concepts [Maes87]
● Computational System (CS)
● Act and reason about a domain
● Causal connection
● Changes in the domain are reflected in the CS, and vice-versa
● Metasystem
● CS whose domain is another CS
● Reflective system
● Metasystem causally connected to itself
Éric Tanter – U.Chile [june | 2005] 38
A Computational System
data
program
executer
worldreason and act upon
causal connection
Éric Tanter – U.Chile [june | 2005] 39
A Metasystem
data
program
executer
world
data
program
executer
metasystem base system
Éric Tanter – U.Chile [june | 2005] 40
A Reflective System
data
program
executer
world
Éric Tanter – U.Chile [june | 2005] 41
Metalevels and towers
● Relation between base and meta systems
● Tower of interpreters vs. metalevels
base program
interpreter 1
interpreter n
...
interpretation
base levels
metalevel 1
reification reflection
metalevel n
...
Éric Tanter – U.Chile [june | 2005] 42
Reification and Reflection
● Reification
● intercept event at the base level (implicit)
● provide a manipulable representation of it at themetalevel (called reification)
● Reflection
● changes made to the reification imply changes tothe base level computation (causal link)
Éric Tanter – U.Chile [june | 2005] 43
Dealing with recursivity
● A metaprogram is itself a program
● Controlled by a metaprogram, which is itself aprogram, etc...
● Solutions
● Fixed number of metalevels
● e.g., ApertOS reflective operating system
● Lazy creation of metalevels
● only when required
Éric Tanter – U.Chile [june | 2005] 44
Introspection and Intercession
introspection intercession
behavioral behavioralintercession
behavioralintrospection
structural structuralintrospection
structuralintercession
● Introspection = “read access”
● Intercession = “write access”
Éric Tanter – U.Chile [june | 2005] 45
Introspection and Intercession
(a) (b)
(c) (d)
Éric Tanter – U.Chile [june | 2005] 46
Reflection in OOP
MetaobjectsMetaobject ProtocolsOpen Implementations
Éric Tanter – U.Chile [june | 2005] 47
Ex1: Classes & Metaclasses
● A class
● Is a generator ofinstances
● Defines structure andbehavior of instances
● But is itself an object
● A metaclass
● Defines structure andbehavior of a class
● ...
p
Point
MetaPoint
p := Point x:2 y:3p color: #blue
x:y:color:
newx:y:
Éric Tanter – U.Chile [june | 2005] 48
Ex2: Calling Methodsusing Metaobjects
a b
self metasend: #foo to: b
b meta invoke: #foo
m := self base classmethod: #foo
m apply: self base
(In practice, a more efficient route isused!)
Éric Tanter – U.Chile [june | 2005] 49
Metaobjects
● Metaclasses are metaobjects
● Control the behavior and structure of classes
● Classes are also metaobjects
● Control their instances
● Method call metaobjects
● Control the semantics of message passing
● Normally taken care of by the language runtimesupport
Éric Tanter – U.Chile [june | 2005] 50
Examples of use ofmetaobjects
● Distributed system with migration among nodes(load balancing)
● Metaobjects take care of object localization
● Persistence
● Metaobjects take care of load/store operations
Éric Tanter – U.Chile [june | 2005] 51
Metaobjects and SOC
● Distinction base/meta
● Base: what to do
● Meta: how to do it
● Base objects do not need to bother about thehow
● Metaobjects are (may be) reusable with otherbase objects
Éric Tanter – U.Chile [june | 2005] 52
Metaprogrammingor Reflection?
● Metaobjects reason about application objects
● What if metaobjects are part of “the application”?
● Metalevel is no more a separate sphere of control
● The application can control the way it is executed(itself)
● Fuzz in litterature, fuzzy distinction
Éric Tanter – U.Chile [june | 2005] 53
MOP
MetaObject Protocols
Éric Tanter – U.Chile [june | 2005] 54
MetaObject Protocols
● “rules determining the format and transmissionof data” [wordnet]
● Strictly speaking, the interface of an object istherefore its protocol
● Network protocols, stack of protocols, ...
● MOP = Interface(s) of metaobject(s)
● Explicit MOPs
● Implicit MOPs
● Inter-metaobject protocols
Éric Tanter – U.Chile [june | 2005] 55
Explicit MOPs
● Used by base objects to communicate withmetaobjects
● Tochange the behavior of base object(s)
● Examples
● Explicitly change the status of an object from volat-ile to persistent
● Explicitly change the way an object is passed overthe network (by copy, by reference, ...)
Éric Tanter – U.Chile [june | 2005] 56
Implicit MOPs
● Take place transparently
● Base object does not know about the “jump tothe metalevel”
● Examples
● Each time an object is created: retrieve its statefrom storage
● Each time an object is destroyed: store its state
● Each time a message is sent: localize receiveracross the network
Éric Tanter – U.Chile [june | 2005] 57
Implicit MOPs
● How are they provided?
● The ordinary calling mechanism is not sufficient
● Base object is not aware
● Need to provide MLIs (MetaLevel Interceptions)
● Implementation depends on the language envir-onment
● Interpreted OO languages (Self): directly in the in-terpreter
● Compiled languages (C++): altering some lan-guage constructs via preprocessing
Éric Tanter – U.Chile [june | 2005] 58
Inter-Metaobject Protocols
● For metaobjects to communicate with eachother
● e.g., in the call example,
● Sender metaobject locates receiver metaobject
● Passes the message via invoke: and wait for theresult
● It is also explicit (standard method call)
● Usually not visible to base objects
Éric Tanter – U.Chile [june | 2005] 59
Open Implementations
I found a large number of programs performpoorly because of the language's tendencyto hide “what is going on” with the mis-
guided intention of “not bothering the pro-grammer with details”
N. Wirth, “On the Design of ProgrammingLanguages”, Information Processing 1974
Éric Tanter – U.Chile [june | 2005] 60
Why Open Implementations?
● High-level abstractions are meant to hide theirimplementation, however
● Any implementation of a high-level system requiresfixing a number of tradeoffs
● Implementation decisions are locked behind
● e.g., influence on the overall performance
● Not possible to provide a single system that pleasesall users
“Open up the implementation, but in a principled way”[Kiczales,1992]
Éric Tanter – U.Chile [june | 2005] 61
Work on Open Implementations
● Language design
● The CLOS MOP [KdRB91]
● Need to support variants of CLOS while being efficient
● Need to support extensions for exploring OO concepts
● OO concurrent reflective programming [MWY89,...]
● Different models for managing coordination amongconcurrent processes
● Open compilers [LKRR92], parallel compilers [Rod92],operating systems [ApertOS], window systems [Silica], ...
Éric Tanter – U.Chile [june | 2005] 62
Open Implementations
● Example: a performance problem [KdRB91]
● Instance implementation strategy in CLOS
(defclass position ()(x y))
(defclass person ()(name age address ...))
many instances,both slots always used
many instances,only a few slots used in any one instance
array-like representation hashtable-like representation
Éric Tanter – U.Chile [june | 2005] 63
The Dual-interface Framework
● Adjustment interface = “meta”-interface
● Gives access to the “internal how” of the system
openimplementation
traditional interface adjustment interface
[Kiczales,1992]
Éric Tanter – U.Chile [june | 2005] 64
MOPs andOpen Implementations
● Using OO techniques to structure the meta interfacebrings a number of benefits
● Conceptual separation, localized behaviors
● Incremental definition of new implementations usingsubclass specialization (extend defaults)
● Different levels of details (different protocols)
● Metaobjects ensure consistency
● Use metaobjects to tailor/extend open implementationsto specific application requirements
Éric Tanter – U.Chile [june | 2005] 65
The CLOS MOP
● Three generic functions related to instances
(allocate-instance class)(get-value class instance slot-name)(set-value class instance slot-name new-value)
● Standard classes are instances of std-class
● Define new metaclass for new kind of classes
(defclass hashtable-class (std-class) ())(defmethod allocate-instance ((c hashtable-class))...allocate a hashtable to store the slots...
(defmethod get-value ...)(defmethod set-value ...)
(defclass person()(name age address ...)
(:metaclass hashtable-class))
[KdRB91]
Éric Tanter – U.Chile [june | 2005] 66
MOPs for SOC
Satisfying Non-Functional Requirements
Taken from “Using Metaobject Protocols to Satisfy Non-Functional Requirements”, R. Stroud and Z. Wu, 1996
Éric Tanter – U.Chile [june | 2005] 67
System-based Approaches
● Typical non-functional requirements
● Persistent data storage, data sharing, distributedprogramming
● Persistent programming, concurrent programming,fault tolerance
● Directly provided by the OS
● Efficient, but cannot be adapted/customized
Éric Tanter – U.Chile [june | 2005] 68
Language-based Approaches
● Extend the semantics of the language byproviding a range of building blocks
● Adding semantics to the programming language
● Extending the runtime support mechanisms
● Adding object definitions to the object library
● No need to modify compiler/interpreter
● Tools: preprocessors, interpreters, reusable objects
Éric Tanter – U.Chile [june | 2005] 69
Language-based Approaches
● Examples
● Arjuna [91]: persistence and atomicity by inherit-ance, distribution transparency by preprocessor
● PC++ [95]: atomic data types via inheritanceand preprocessing
● Avalon [88]: complete OO system on top ofdistributed transaction facilities
● Argus [88]: linguistic support for atomic datatypes
● SOS [89]: adds persistence and migration to C++objects with a compiler and a runtime OMS
Éric Tanter – U.Chile [june | 2005] 70
Language-based Approaches
● Limitations
● Require 'stylised' code that obscures base func-tionality
● e.g., explicit lock manipulation in Arjuna
● Not transparent
● Require specialized implementation of a lan-guage that is hard to customize
● e.g., PC++ preprocessor generated code
● Not flexible (changing scheme = changing preproc.)
Éric Tanter – U.Chile [june | 2005] 71
MOP-based Approaches
● Provide both transparency and flexibility
● Change the behavior of an object by definingnew kinds of metaobjects
● Non-functional requirements are implemented asmetaobjects (by system developers)
● Add non-functional properties to objects bybinding them to appropriate metaobjects
● e.g, replication metaobject, atomicity metaobject,persistence metaobject, ...
● Reuse: metaobjects may be reusable (generic)
key: flexible approach to reification
Éric Tanter – U.Chile [june | 2005] 72
Building Reflective Systems
Characteristics of reflective systems
Éric Tanter – U.Chile [june | 2005] 73
Building a Reflective System
● What model to use? [McAffer96]
● At the metalevel, “metaobjects” reason and actupon “reifications” of the base level
● Structural, “top-down” approach
● Classes and metaclasses
● Not flexible enough for behavioral reflection
metaclasses are not “meta” in the computational sense, al-though they are “meta” in the structural sense [Ferber89]
● Behavioral, “bottom-up” approach
● Operations defining computational behavior
● Reifications = operation occurrences
Éric Tanter – U.Chile [june | 2005] 74
Building a Reflective System
● What is reified?
● Set of reifiable operations (implicit MOP)
● Abstraction level & granularity of reifications
● What is the causal connection between levels?
● Type(s) of MOP, e.g.:
● Base objects use an explicit MOP to change their execution
● This change is realized by an implicit MOP
● When does a shift to the metalevel occur?
● Time
● compile/load: static approaches
● Runtime: dynamic approaches => only when needed
[Zim96]
Éric Tanter – U.Chile [june | 2005] 75
Building a Reflective System
● How are levels synchronized?
● Synchronous or asynchronous?
● Metaobjects are thread-local or global?
● How is a base entity reified and reflected back?
● What is the exact representation? interface?
● Impact on efficiency
● How are metacircularity & regression ad-ressed?
● Number of metalevels, lazy creation, etc.
● Bootstrapping issues
Éric Tanter – U.Chile [june | 2005] 76
Reflection in Java
Standard APIand Reflective Extensions
Éric Tanter – U.Chile [june | 2005] 77
Java Reflection API
“The Java Reflection API provides a small, typesafe,and secure API that supports introspection overclasses and objects in the actual virtual machine.If allowed by the security policy, this API can beused to:
● Create new instances of classes
● Access and modify fields of objects and classes
● Access and modify elements of arrays
● Invoke methods on objects and classes”
Éric Tanter – U.Chile [june | 2005] 78
Main Applications
● Automatic documentation
● IDEs: browsers, inspectors, debuggers
● Augmented by the Java Debugging Interface
● Serialization and deserialization
● Binary representation of an object
● Re-creation of an object based on such representa-tion
● Used in persistency and RMI
● Componentes
● Dynamic discovery of properties (JavaBeans)
● Application servers (EJBs)
Éric Tanter – U.Chile [june | 2005] 79
Classes and Interfaces
● java.lang.Object
● java.lang.Class
● java.lang.reflect.Member (I)
● java.lang.reflect.Field
● java.lang.reflect.Method
● java.lang.reflect.Constructor
● java.lang.reflect.AccessibleObject
Éric Tanter – U.Chile [june | 2005] 80
The Java Class Model
ClassF
^FieldF ^MethodF^Object^Point
p1 p2
instanceOf
subclassOf
Éric Tanter – U.Chile [june | 2005] 81
java.lang.Class
● Introspection
● String getName()
● Class getSuperclass()
● Class[] getInterfaces()
● int getModifiers()
● Method getDeclaredMethod(String, Class[])
● Field getDeclaredField(String)
● Get class object
● Class.forName(“A”); p1.-getClass(); A.-class; int.class
public abstract class A extends B implements C, D { ... }
InvocationObject newInstance()
Éric Tanter – U.Chile [june | 2005] 82
java.lang.reflect.Method
● Introspection
● String getName()
● Class getDeclaringClass()
● int getModifiers()
● Class getReturnType()
● Class[] getParameterTypes()
● Class[] getExceptionTypes()
● Invocation
● Object invoke(Object, Object[])
public synchronized A foo(B b, C c) throws Ex1, Ex2 {...}
Éric Tanter – U.Chile [june | 2005] 83
Dynamic Programming
if(name.equals(“A”))
return new A();
if(name.equals(“B”))
return new B();
...
Class c = Class.forName(name);
return c.newInstance();
if(o instanceof Person)
return ((Person)o).getName();
if(o instanceof House)
return ((House)o).getName();
...
Class c = o.getClass();
Method nameGetter =
c.getMethod(“getName”,null);
return nameGetter.invoke(o,null);
Éric Tanter – U.Chile [june | 2005] 84
More Reflection (since JDK1.3)● Reflection API as just presented is limited to:
● Introspection
● Explicit MOP (no implicit interceptions)
● Dynamic Proxies
● Small implicit MOP for behavioral reflection
● Based on interceptors (automatically generated)
aPointaTracer
aPointProxy
IPoint
InvocationHandlerObject invoke(Object p, Method m,
Object[] args)getX()setX()
IPointgetX()setX()
Éric Tanter – U.Chile [june | 2005] 85
Extending Java
Reflective Extensions for Java
Éric Tanter – U.Chile [june | 2005] 86
Why extensions?
● Standard reflection API is very limited
● Even dynamic proxies suffer limitations
● Research community
● Various extensions of Java that add reflectiveabilities, in particular
● Full structural reflection
● OpenJava, Javassist
● Full behavioral reflection
● Guarana, MetaXa, Kava, Reflex
Éric Tanter – U.Chile [june | 2005] 87
Structural Reflection
● OpenJava: a compile-time structural MOP [Chi98]
● Preprocessor: pp(source, meta) = source'
● Reifies elements of the program (syntax tree)
● Declarations of classes, methods, variables...
● Method invocations, field accesses...
● Javassist: a load-time structural MOP [Chi00]
● Bytecode translator: t(bc, meta) = bc'
● Same principle than OpenJava
● 2 different levels of abstraction: source / bytecode
● Widely used: JBoss 4 (AOP framework)
Éric Tanter – U.Chile [june | 2005] 88
Javassist Example: BCAclass Calendar implements Writable {
void write(PrintStream s){...}
}
class Calendar implements Printable {
void write(PrintStream s){...}
void print(){ write(System.out); }
}
frameworkchanges
Use Javassist to:
● Add print() method
● Change implemented interface
Can be done
● Statically (new .class file)
● On-the-fly (when load-ing)
Éric Tanter – U.Chile [june | 2005] 89
Behavioral Reflection
● Static: base and meta merged before runtime
● OpenJava or Javassist can be used
● Dynamic: metaobjects exist at runtime
● Based on code transformation (to add MLIs)
● e.g., Kava, Reflex (uses Javassist to add hooks)
● Portable, but less dynamic and efficient
● Based on modified runtime environment (VM, JIT)
● e.g., Guarana, MetaXa
● More dynamic and efficient, but not portable
Éric Tanter – U.Chile [june | 2005] 90
Example: SOM
● Sequential Object Monitors
[CMT04]
user-definedscheduling policy
generic schedulermetaobject
unsynchronizedJava object(e.g. buffer)
if(buffer.isEmpty())scheduleOldest(“put”);
else if(buffer.isFull())scheduleOldest(“get”);
else scheduleOldest();
(t1, put)
(tn, get)
...
Éric Tanter – U.Chile [june | 2005] 91
Reflex
● Open implementation of a reflective system
● Extensible set of supported operations
● Platform for defining tailored MOPs (implicit/explicit)
● New model for behavioral reflection
● Hooksets (add crosscutting support)
● Highly configurable metalink
● Scope, activation, control, initialization, etc.
● MOP descriptors
[TNCC03]
www.dcc.uchile.cl/~etanter/Reflex
Éric Tanter – U.Chile [june | 2005] 92
Conclusions
Reflection and Metaprogramming
Éric Tanter – U.Chile [june | 2005] 93
Achievements● Powerful conceptual framework
● For SOC
● Modularize concerns: metaobjetos, metaprogramas
● Connect such modules: MLIs (hooks) + metalink
● Expressive power: reifications + reflection
● Reuse
● Base program not (much) aware
● Metaprogram (quite) generic
● Very adequate for system software
● Languages, operating systems, middleware, etc.
Éric Tanter – U.Chile [june | 2005] 94
Limitations● Complexity! Danger!
● Powerful => dangerous
● Hard to formalize
● Extremely generic (meta viewpoint)
● Too broad scope/locality
● Based on (low-level) language abstractions
● Costly
● Partial reflection
● Partial evaluation of reflection
● Not adequate for “standard” software
● Definitely not for standard programmers!
Éric Tanter – U.Chile [june | 2005] 95
Part IV
Aspect-Oriented Programming
Éric Tanter – U.Chile [june | 2005] 96
AOP: the vision
● Kiczales, 1992
“Towards a New Model of Abstraction in Software Engineering”
● “very often, the concepts that are most natural to use at themetalevel cross-cut those provided at the base level”
● “allow users to use natural base level concepts and naturalmetalevel concepts”
● “we are, in essence, trying to find a way to provide twoeffective views of a system through cross-cutting“localities””
● “it is natural for people to make this jump from one localityto another, and we have to find a way to support that”
Éric Tanter – U.Chile [june | 2005] 97
AOP background
● Kiczales et al. (Xerox PARC)
Aspect-Oriented Programming – ECOOP 97
“software design processes and programminglanguages exist in a mutually supporting relationship”
“a design process and a programming language workwell together when the programming languageprovides abstraction and composition mechanismsthat cleanly support the kinds of units the design pro-cess breaks the system into”
Éric Tanter – U.Chile [june | 2005] 98
Introducing crosscutting
● Example: image processing system
● An image passes through a series of filters
● Objectives
● 1. clean design (easy to develop and maintain)
● 2. efficient memory usage (images are large)
● Issues
● In a clean design, looping over the image is doneonce for each filter
● In an efficient implementation, looping is done onceonly, fusioning filters
[Kic+97]
Éric Tanter – U.Chile [june | 2005] 99
Introducing crosscutting
● Two properties
● Functionality
● Loop fusion
● Compose differently
● Functionality: hierarchically
● Loop fusion: fusing loops of primitive filters that havesame loop structure and neighbours in data flow graph
● This is crosscutting: leads to code tangling
● Procedure call (single composition mechanism) doesnot help for composing functionality and loop fusion
[Kic+97]
Éric Tanter – U.Chile [june | 2005] 100
Definitions
● Crosscutting properties
● Whenever two properties being programmed mustcompose differently and yet be coordinated
● Using a GP-based language, a property is:
● A component if it can be cleanly encapsulated in ageneralized procedure (object, method, procedure, ...)
● An aspect if it cannot
● Aspects tend to be properties that affect the performanceor semantics of the components in systemic ways
[Kic+97]
Éric Tanter – U.Chile [june | 2005] 101
Examples of Aspects
● Performance-related issues
● “performance optimizations often exploit inform-ation about the execution context that spanscomponents”
● Error and failure handling
● “the different dynamic contexts that can lead toa failure, or that bear upon how a failure shouldbe handled, crosscut the functionality of sys-tems”
[Kic+97]
Éric Tanter – U.Chile [june | 2005] 102
An AOP Implementation
● Language
● A component language to program components
● One or more aspect languages to program theaspects
● Compiler
● An aspect weaver for the combined languages
● Program
● A component program implementing components
● One or more aspect programs implementing theaspects
[Kic+97]
Éric Tanter – U.Chile [june | 2005] 103
Component Language& Program
● Designing an AOP system involves understanding
● What must go in the component language
● What must go in the aspect languages
● What must be shared among languages
● Component programs
● Must not preempt anything the aspect programsneed to control
● Must not address issues that are handled by aspectprograms
[Kic+97]
Éric Tanter – U.Chile [june | 2005] 104
Aspect Language& Programs
● Aspect languages
● Support implementation of desired aspects, in anatural and concise way
● Avoid/mask the power/danger/difficulty of reflection
● Have different abstraction and composition mech-anisms, but have common terms
“proper use of AOP means that users are expressingimplementation strategies at an appropriatelyabstract level, through an appropriate aspectlanguage, with appropriate locality”
[Kic+97]
Éric Tanter – U.Chile [june | 2005] 105
Aspect Weaving● An aspect weaver
● Must process the component and aspect languages,co-composing them properly
● Can operate at compile or runtime
● An aspect weaver is NOT a “smart” compiler
“The weaver's job is integration, rather than inspiration”
● Essential notion: join points
● Elements of the component language semantics thataspect programs coordinate with
● Not necessarily explicit constructs
● e.g., nodes in dataflow graph, runtime method invoca-tions
[Kic+97]
Éric Tanter – U.Chile [june | 2005] 106
AspectJ Quick Overview
Good slides on AspectJ can be obtained at:
http://www.cs.chalmers.se/~giese/AOP.html
look at:course2.pdfcourse3.pdfcourse4.pdf
Éric Tanter – U.Chile [june | 2005] 107
Aspect Languages
● First experiments and motivation of AOP:
● Aspect-specific languages (ASLs, aka. DSALs)
● Restrict users, provide guarantees, etc.
● Issue of interaction/composition with ASLs
● How to specify composition?
● e.g. Encryption and Trace
● Much research shifted to general-purpose ALs
● AspectJ and others
Éric Tanter – U.Chile [june | 2005] 108
AOP and Reflection/MOPs
● Deep connection
● Birth of AOP through iterative MOP prototyping
● Meta-languages crosscut base level computation
● Provide a view on computation that is not availableat the base level
● Aspect languages whose join points are the “hooks”the reflective system provides
“AOP is a goal, for which reflection is one powerful tool”
[Kic+97]
Éric Tanter – U.Chile [june | 2005] 109
Perspective: AOP Kernels
● Partial reflection as underlying model for AOP
● Unified model whereby metalink is reified
● Partial behavioral reflection for behavioral part [TNCC03]
● Class-object model for structural part
● Interactions between links are detected by kernel
● Expressive means for composition and collaboration
● Open support for aspect languages (plugin architecture)
[TN05]
api
BS
comp
AL1
ALn
...
application
P1(L
1)
Pi(L
1)
Pk(L
n)
Éric Tanter – U.Chile [june | 2005] 110
Conclusion on AOP
● New paradigm, very promising
● Lots of attention in research
● Massive industry investments (IBM, JBoss, BEA, etc.)
● But still young (compare to OOP in the 80's)
● Challenges
● Tool support (IDEs)
● Technical issues
● Weaving time, composition, multiple ASL support
● Standardization, compliance
● Development Process
● Aspect Mining, AO Analysis and Design, AO Testing
Éric Tanter – U.Chile [june | 2005] 111
Conclusions
OOP and the Post-OOP paradigm
Éric Tanter – U.Chile [june | 2005] 112
Conclusion
● Limitations of OOP (and previous paradigms)
● Clean modularization in complex systems
● Non-functional concerns, crosscutting concerns
● “Advanced Separation of Concerns”
● Program transformation
● Reflection and metaprogramming
● AOP
● AOLMP, hyperspaces, composition filters, adaptiveprogramming, ...
● Many open issues, at all levels of developmentprocess