Beyond OOP - dcc.uchile.cletanter/courses/cc72q/tanter-asoc-june05… · Éric Tanter – U.Chile...

Éric Tanter – U.Chile [june | 2005] 1

Beyond OOPAdvanced Separation of Concerns

MetaprogrammingReflection

Aspect-Oriented Programming

Eric TanterDCC/CWR University of Chile

[email protected]


Contents

● A brief history of programming

● Advanced modularization problems

● Reflection and metaprogramming

● Aspect-oriented programming


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


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


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


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


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]


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


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


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


Object orientation

● Key mechanisms

● Instantiation (or cloning)

● Inheritance

● Polymorphism

● Aggregation and delegation


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


Part II

Advanced Modularization Problemsin (OO) Programs


OOP Promises

● Major objectives

● Evolution, extension

● Maintenance

● Reuse

● Additional mechanisms

● Frameworks

● Design Patterns [GoF95]

● “the quality without a name” [Alexander,1979]


Apache Tomcat case study

● Realized by AspectJ folks

● eclipse.org/aspectj

● Illustrates modularization problems in the ApacheTomcat engine


XML Parsing in Tomcat

● Cleanly modularized in one class


URL Pattern matching inTomcat

● Cleanly modularized

● one abstract class/interface and one class


Logging in Tomcat

● Is this modularized???


Session Expiration in Tomcat

● Is this modularized???


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


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


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


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


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


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


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()


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


“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, ...


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


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


Part III

Reflection and Metaprogramming


Introduction

History and concepts


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!


Programs and Data

● From computing theory

● Lambda calculus (Church)

● Universal Turing Machine

● Metaprogram

● A program that affects a program

● Metaprogramming

● Developing metaprograms


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”


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


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


A Computational System

data

program

executer

worldreason and act upon

causal connection


A Metasystem

data

program

executer

world

data

program

executer

metasystem base system


A Reflective System

data

program

executer

world


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

...


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)


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


Introspection and Intercession

introspection intercession

behavioral behavioralintercession

behavioralintrospection

structural structuralintrospection

structuralintercession

● Introspection = “read access”

● Intercession = “write access”


Introspection and Intercession

(a) (b)

(c) (d)


Reflection in OOP

MetaobjectsMetaobject ProtocolsOpen Implementations


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:


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!)


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


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


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


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


MOP

MetaObject Protocols


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


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, ...)


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


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


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


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


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]


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], ...


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


The Dual-interface Framework

● Adjustment interface = “meta”-interface

● Gives access to the “internal how” of the system

openimplementation

traditional interface adjustment interface

[Kiczales,1992]


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


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]


MOPs for SOC

Satisfying Non-Functional Requirements

Taken from “Using Metaobject Protocols to Satisfy Non-Functional Requirements”, R. Stroud and Z. Wu, 1996


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


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



● 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



● 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.)


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


Building Reflective Systems

Characteristics of reflective systems


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



● 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]



● 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


Reflection in Java

Standard APIand Reflective Extensions


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”


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)


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


The Java Class Model

ClassF

^FieldF ^MethodF^Object^Point

p1 p2

instanceOf

subclassOf


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()


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 {...}


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);


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()


Extending Java

Reflective Extensions for Java


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


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)


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)


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


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)

...


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


Conclusions

Reflection and Metaprogramming


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.


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!


Part IV

Aspect-Oriented Programming


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”


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”


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]


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]


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]


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]


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]


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]


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]


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]


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


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


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]


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)


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


Conclusions

OOP and the Post-OOP paradigm


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

Beyond OOP - dcc.uchile.cletanter/courses/cc72q/tanter-asoc-june05… · Éric Tanter – U.Chile...

Documents

Transcript of Beyond OOP - dcc.uchile.cletanter/courses/cc72q/tanter-asoc-june05… · Éric Tanter – U.Chile...