Beyond OOP Advanced Separation of Concerns
Metaprogramming Reflection Aspect-Oriented Programming
Eric Tanter DCC/CWR University of Chile
Éric Tanter – U.Chile [june | 2005] 1 Contents
● A brief history of programming ● Advanced modularization problems ● Reflection and metaprogramming ● Aspect-oriented programming
Éric Tanter – U.Chile [june | 2005] 2 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] 3 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] 4 Then came the assembly...
● 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] 5 ...and then, compilers
● Assembly required knowledge of the specific computer 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] 6 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 express all programs by Bohm & Jacopini [1966]
Éric Tanter – U.Chile [june | 2005] 7 Structured Programming
● Early programming principles
● Top-down design and stepwise refinement
● Dijkstra [1968]
● Introduction of the notion of modularity and the principle 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] 8 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] 9 Object orientation
● Problem with procedural programs
● Procedures and data structures are separate but interdependent
● Changing implementation
● Changing representation
● Contribution of OOP
● Pack data and procedures together
● Objects communicate through messages
Éric Tanter – U.Chile [june | 2005] 10 Object orientation
● Key mechanisms
● Instantiation (or cloning)
● Inheritance
● Polymorphism
● Aggregation and delegation
Éric Tanter – U.Chile [june | 2005] 11 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] 12 Part II
Advanced Modularization Problems in (OO) Programs
Éric Tanter – U.Chile [june | 2005] 13 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] 14 Apache Tomcat case study
● Realized by AspectJ folks
● eclipse.org/aspectj
● Illustrates modularization problems in the Apache Tomcat engine
Éric Tanter – U.Chile [june | 2005] 15 XML Parsing in Tomcat
● Cleanly modularized in one class
Éric Tanter – U.Chile [june | 2005] 16 URL Pattern matching in Tomcat
● Cleanly modularized
● one abstract class/interface and one class
Éric Tanter – U.Chile [june | 2005] 17 Logging in Tomcat
● Is this modularized???
Éric Tanter – U.Chile [june | 2005] 18 Session Expiration in Tomcat
● Is this modularized???
Éric Tanter – U.Chile [june | 2005] 19 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] 20 Problem: modularization
● Fact: code scattering
● Code replication = same code repeated in different places
● Code tangling = code for different concerns in the same place
● Why?
● Nature of concerns
Éric Tanter – U.Chile [june | 2005] 21 Nature of concerns
● Some concerns are not related to application logic
● exception handling, security, persistence, distri- bution, concurrency, etc.
● Such non-functional concerns are often mixed with the application logic
Éric Tanter – U.Chile [june | 2005] 22 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] 23 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] 24 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 class hierarchy: this is a crosscutting concern
Éric Tanter – U.Chile [june | 2005] 25 Example
● Design patterns
● Provide design reuse, but no code reuse
● Some patterns lead to tangled code
register(this) Observer 1 Subject stateChanged(this)
notifyObservers() Observer 2
Éric Tanter – U.Chile [june | 2005] 26 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] 27 “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] 28 Generative Programming
● Transform high-level specs into a ready-to-run program
● 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] 29 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] 30 Part III
Reflection and Metaprogramming
Éric Tanter – U.Chile [june | 2005] 31 Introduction
History and concepts
Éric Tanter – U.Chile [june | 2005] 32 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 where data is stored
● Perspective: a program could alter its own in- structions!
Éric Tanter – U.Chile [june | 2005] 33 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] 34 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, and otherwise 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] 35 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] 36 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] 37 A Computational System
causal connection
data
reason and act upon world program
executer
Éric Tanter – U.Chile [june | 2005] 38 A Metasystem
data data
world program program
executer executer metasystem base system
Éric Tanter – U.Chile [june | 2005] 39 A Reflective System
data
world program
executer
Éric Tanter – U.Chile [june | 2005] 40 Metalevels and towers
● Relation between base and meta systems
● Tower of interpreters vs. metalevels
interpreter n metalevel n
......
interpreter 1 metalevel 1 interpretation reification reflection base program base levels
Éric Tanter – U.Chile [june | 2005] 41 Reification and Reflection
● Reification
● intercept event at the base level (implicit)
● provide a manipulable representation of it at the metalevel (called reification)
● Reflection
● changes made to the reification imply changes to the base level computation (causal link)
Éric Tanter – U.Chile [june | 2005] 42 Dealing with recursivity
● A metaprogram is itself a program
● Controlled by a metaprogram, which is itself a program, 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] 43 Introspection and Intercession
● Introspection = “read access” ● Intercession = “write access”
introspection intercession structural structural structural introspection intercession behavioral behavioral behavioral introspection intercession
Éric Tanter – U.Chile [june | 2005] 44 Introspection and Intercession
(a) (b)
(c) (d)
Éric Tanter – U.Chile [june | 2005] 45 Reflection in OOP
Metaobjects Metaobject Protocols Open Implementations
Éric Tanter – U.Chile [june | 2005] 46 Ex1: Classes & Metaclasses
● A class new ● Is a generator of MetaPoint x:y: instances
● Defines structure and behavior of instances x:y: color: Point ● But is itself an object
● A metaclass ● Defines structure and p p := Point x:2 y:3 behavior of a class p color: #blue ● ...
Éric Tanter – U.Chile [june | 2005] 47 Ex2: Calling Methods using Metaobjects
b meta invoke: #foo
self meta m := self base class send: #foo to: b method: #foo m apply: self base a b
(In practice, a more efficient route is used!)
Éric Tanter – U.Chile [june | 2005] 48 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 runtime support
Éric Tanter – U.Chile [june | 2005] 49 Examples of use of metaobjects
● 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] 50 Metaobjects and SOC
● Distinction base/meta
● Base: what to do
● Meta: how to do it
● Base objects do not need to bother about the how ● Metaobjects are (may be) reusable with other base objects
Éric Tanter – U.Chile [june | 2005] 51 Metaprogramming or 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] 52 MOP
MetaObject Protocols
Éric Tanter – U.Chile [june | 2005] 53 MetaObject Protocols
● “rules determining the format and transmission of data” [wordnet]
● Strictly speaking, the interface of an object is therefore 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] 54 Explicit MOPs
● Used by base objects to communicate with metaobjects
● To change 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 over the network (by copy, by reference, ...)
Éric Tanter – U.Chile [june | 2005] 55 Implicit MOPs
● Take place transparently
● Base object does not know about the “jump to the metalevel”
● Examples
● Each time an object is created: retrieve its state from storage
● Each time an object is destroyed: store its state
● Each time a message is sent: localize receiver across the network
Éric Tanter – U.Chile [june | 2005] 56 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] 57 Inter-Metaobject Protocols
● For metaobjects to communicate with each other
● e.g., in the call example,
● Sender metaobject locates receiver metaobject
● Passes the message via invoke: and wait for the result
● It is also explicit (standard method call)
● Usually not visible to base objects
Éric Tanter – U.Chile [june | 2005] 58 Open Implementations
I found a large number of programs perform poorly because of the language's tendency to hide “what is going on” with the mis- guided intention of “not bothering the pro- grammer with details”
N. Wirth, “On the Design of Programming Languages”, Information Processing 1974
Éric Tanter – U.Chile [june | 2005] 59 Why Open Implementations?
● High-level abstractions are meant to hide their implementation, however
● Any implementation of a high-level system requires fixing a number of tradeoffs
● Implementation decisions are locked behind
● e.g., influence on the overall performance
● Not possible to provide a single system that pleases all users
“Open up the implementation, but in a principled way” [Kiczales,1992]
Éric Tanter – U.Chile [june | 2005] 60 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 among concurrent processes
● Open compilers [LKRR92], parallel compilers [Rod92], operating systems [ApertOS], window systems [Silica], ...
Éric Tanter – U.Chile [june | 2005] 61 Open Implementations
● Example: a performance problem [KdRB91]
● Instance implementation strategy in CLOS
(defclass position () (defclass person () (x y)) (name age address ...))
many instances, many instances, both slots always used only a few slots used in any one instance
array-like representation hashtable-like representation
Éric Tanter – U.Chile [june | 2005] 62 The Dual-interface Framework [Kiczales,1992] traditional interface adjustment interface
open implementation
● Adjustment interface = “meta”-interface
● Gives access to the “internal how” of the system
Éric Tanter – U.Chile [june | 2005] 63 MOPs and Open Implementations
● Using OO techniques to structure the meta interface brings a number of benefits
● Conceptual separation, localized behaviors
● Incremental definition of new implementations using subclass specialization (extend defaults)
● Different levels of details (different protocols)
● Metaobjects ensure consistency
● Use metaobjects to tailor/extend open implementations to specific application requirements
Éric Tanter – U.Chile [june | 2005] 64 The CLOS MOP [KdRB91] ● 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))
Éric Tanter – U.Chile [june | 2005] 65 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] 66 System-based Approaches
● Typical non-functional requirements
● Persistent data storage, data sharing, distributed programming
● Persistent programming, concurrent programming, fault tolerance ● Directly provided by the OS
● Efficient, but cannot be adapted/customized
Éric Tanter – U.Chile [june | 2005] 67 Language-based Approaches
● Extend the semantics of the language by providing 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] 68 Language-based Approaches
● Examples
● Arjuna [91]: persistence and atomicity by inherit- ance, distribution transparency by preprocessor
● PC++ [95]: atomic data types via inheritance and preprocessing
● Avalon [88]: complete OO system on top of distributed transaction facilities
● Argus [88]: linguistic support for atomic data types
● SOS [89]: adds persistence and migration to C++ objects with a compiler and a runtime OMS
Éric Tanter – U.Chile [june | 2005] 69 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] 70 MOP-based Approaches
● Provide both transparency and flexibility
● Change the behavior of an object by defining new kinds of metaobjects
● Non-functional requirements are implemented as metaobjects (by system developers)
● Add non-functional properties to objects by binding 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] 71 Building Reflective Systems
Characteristics of reflective systems
Éric Tanter – U.Chile [june | 2005] 72 Building a Reflective System
● What model to use? [McAffer96]
● At the metalevel, “metaobjects” reason and act upon “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] 73 Building a Reflective System [Zim96] ● 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 Éric Tanter – U.Chile [june | 2005] 74 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] 75 Reflection in Java
Standard API and Reflective Extensions
Éric Tanter – U.Chile [june | 2005] 76 Java Reflection API
“The Java Reflection API provides a small, typesafe, and secure API that supports introspection over classes and objects in the actual virtual machine. If allowed by the security policy, this API can be used 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] 77 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] 78 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] 79 The Java Class Model
ClassF
^Point ^Object ^FieldF ^MethodF
p1 p2 instanceOf subclassOf
Éric Tanter – U.Chile [june | 2005] 80 java.lang.Class public abstract class A extends B implements C, D { ... }
● Introspection
● String getName()
● Class getSuperclass()
● Class[] getInterfaces()
● int getModifiers()
● Method getDeclaredMethod(String, Class[])
● Field getDeclaredField(String) ● Get class object Invocation Object newInstance() ● Class.forName(“A”); p1.- getClass(); A.- class; int.class
Éric Tanter – U.Chile [june | 2005] 81 java.lang.reflect.Method public synchronized A foo(B b, C c) throws Ex1, Ex2 {...}
● Introspection
● String getName()
● Class getDeclaringClass()
● int getModifiers()
● Class getReturnType()
● Class[] getParameterTypes()
● Class[] getExceptionTypes() ● Invocation
● Object invoke(Object, Object[])
Éric Tanter – U.Chile [june | 2005] 82 Dynamic Programming
Class c = Class.forName(name); if(name.equals(“A”)) return c.newInstance(); return new A(); if(name.equals(“B”)) return new B(); Class c = o.getClass(); ... Method nameGetter = c.getMethod(“getName”,null); if(o instanceof Person) return nameGetter.invoke(o,null); return ((Person)o).getName(); if(o instanceof House) return ((House)o).getName(); ...
Éric Tanter – U.Chile [june | 2005] 83 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)
IPoint InvocationHandler getX() Object invoke(Object p, Method m, IPoint setX() Object[] args) getX() setX()
aTracer aPointProxy aPoint Éric Tanter – U.Chile [june | 2005] 84 Extending Java
Reflective Extensions for Java
Éric Tanter – U.Chile [june | 2005] 85 Why extensions?
● Standard reflection API is very limited
● Even dynamic proxies suffer limitations ● Research community
● Various extensions of Java that add reflective abilities, in particular
● Full structural reflection
● OpenJava, Javassist
● Full behavioral reflection
● Guarana, MetaXa, Kava, Reflex
Éric Tanter – U.Chile [june | 2005] 86 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] 87 Javassist Example: BCA class Calendar implements Writable { void write(PrintStream s){...} }
framework Use Javassist to: changes ● Add print() method
● Change implemented interface class Calendar implements Printable { Can be done void write(PrintStream s){...} ● Statically (new .class file) void print(){ write(System.out); } ● On-the-fly (when load- } ing)
Éric Tanter – U.Chile [june | 2005] 88 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] 89 Example: SOM [CMT04]
● Sequential Object Monitors
generic scheduler user-defined metaobject scheduling policy
if(buffer.isEmpty()) (t , put) 1 scheduleOldest(“put”); ... else if(buffer.isFull()) (t , get) scheduleOldest(“get”); n else scheduleOldest();
unsynchronized Java object (e.g. buffer)
Éric Tanter – U.Chile [june | 2005] 90 www.dcc.uchile.cl/~etanter/Reflex
Reflex [TNCC03]
● 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
Éric Tanter – U.Chile [june | 2005] 91 Conclusions
Reflection and Metaprogramming
Éric Tanter – U.Chile [june | 2005] 92 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] 93 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] 94 Part IV
Aspect-Oriented Programming
Éric Tanter – U.Chile [june | 2005] 95 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 the metalevel cross-cut those provided at the base level”
● “allow users to use natural base level concepts and natural metalevel concepts”
● “we are, in essence, trying to find a way to provide two effective views of a system through cross-cutting “localities””
● “it is natural for people to make this jump from one locality to another, and we have to find a way to support that”
Éric Tanter – U.Chile [june | 2005] 96 AOP background
● Kiczales et al. (Xerox PARC) Aspect-Oriented Programming – ECOOP 97
“software design processes and programming languages exist in a mutually supporting relationship”
“a design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design pro- cess breaks the system into”
Éric Tanter – U.Chile [june | 2005] 97 Introducing crosscutting [Kic+97]
● 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 done once for each filter
● In an efficient implementation, looping is done once only, fusioning filters
Éric Tanter – U.Chile [june | 2005] 98 Introducing crosscutting [Kic+97]
● Two properties
● Functionality
● Loop fusion ● Compose differently
● Functionality: hierarchically
● Loop fusion: fusing loops of primitive filters that have same loop structure and neighbours in data flow graph ● This is crosscutting: leads to code tangling
● Procedure call (single composition mechanism) does not help for composing functionality and loop fusion
Éric Tanter – U.Chile [june | 2005] 99 Definitions [Kic+97]
● Crosscutting properties
● Whenever two properties being programmed must compose differently and yet be coordinated ● Using a GP-based language, a property is:
● A component if it can be cleanly encapsulated in a generalized procedure (object, method, procedure, ...)
● An aspect if it cannot
● Aspects tend to be properties that affect the performance or semantics of the components in systemic ways
Éric Tanter – U.Chile [june | 2005] 100 Examples of Aspects [Kic+97]
● Performance-related issues
● “performance optimizations often exploit inform- ation about the execution context that spans components” ● Error and failure handling
● “the different dynamic contexts that can lead to a failure, or that bear upon how a failure should be handled, crosscut the functionality of sys- tems”
Éric Tanter – U.Chile [june | 2005] 101 An AOP Implementation [Kic+97]
● Language
● A component language to program components
● One or more aspect languages to program the aspects ● Compiler
● An aspect weaver for the combined languages ● Program
● A component program implementing components
● One or more aspect programs implementing the aspects
Éric Tanter – U.Chile [june | 2005] 102 Component Language & Program [Kic+97]
● 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 programs need to control
● Must not address issues that are handled by aspect programs
Éric Tanter – U.Chile [june | 2005] 103 Aspect Language & Programs [Kic+97]
● Aspect languages
● Support implementation of desired aspects, in a natural 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 expressing implementation strategies at an appropriately abstract level, through an appropriate aspect language, with appropriate locality”
Éric Tanter – U.Chile [june | 2005] 104 Aspect Weaving [Kic+97] ● 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 that aspect programs coordinate with
● Not necessarily explicit constructs
● e.g., nodes in dataflow graph, runtime method invoca- tions Éric Tanter – U.Chile [june | 2005] 105 AspectJ Quick Overview
Good slides on AspectJ can be obtained at: http://www.cs.chalmers.se/~giese/AOP.html
look at: course2.pdf course3.pdf course4.pdf
Éric Tanter – U.Chile [june | 2005] 106 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] 107 AOP and Reflection/MOPs [Kic+97]
● Deep connection
● Birth of AOP through iterative MOP prototyping ● Meta-languages crosscut base level computation
● Provide a view on computation that is not available at 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”
Éric Tanter – U.Chile [june | 2005] 108 Perspective: AOP Kernels [TN05] ● 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)
P (L ) 1 1 AL 1 P (L ) i 1 ... a p S B P (L ) AL i k n n comp application
Éric Tanter – U.Chile [june | 2005] 109 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] 110 Conclusions
OOP and the Post-OOP paradigm
Éric Tanter – U.Chile [june | 2005] 111 Conclusion
● Limitations of OOP (and previous paradigms)
● Clean modularization in complex systems
● Non-functional concerns, crosscutting concerns
● “Advanced Separation of Concerns”
● Reflection and metaprogramming
● AOP
● AOLMP, hyperspaces, composition filters, adaptive programming, ...
● Many open issues, at all levels of development process
Éric Tanter – U.Chile [june | 2005] 112