I. Characteristics of AOP: Quantification and Obliviousness A. What features make an AOP language? ------------------------------------------ WHAT DISTINGUISHES AOP LANGUAGES (FROM OO, FUNCTIONAL, ETC.)? Filman and Friedman: AOP = quantification + oblivousness ------------------------------------------ 1. quantification ------------------------------------------ QUANTIFICATION def: *quantified statements* have an effect on many places in the underlying code. e.g., - type declarations - code in superclasses - advice that applies to many calls ------------------------------------------ 2. obliviousness ------------------------------------------ OBLIVIOUSNESS def: The *obliviousness of module M with respect to module A* is to the degree to which the programmer of M doesn't need to know about A low - M calls subroutines in A - M calls a dynamically bound method defined in A - M implements an abstract method in A - M is derived from multiple inheritance mixin A - M is advised by aspect A high ------------------------------------------ 3. Summary ------------------------------------------ AOP SUMMARY Want to make statements of the form: In programs P, whenever condition C arises, perform action A. ------------------------------------------ What part of this is quantification? What does this have to do with obliviousness? How does weaving fit in? 4. What's not AOP ------------------------------------------ OPPOSITE OF AOP: UNITARY AND LOCAL unitary statements only affect one place local statements only affect neighboring statments ------------------------------------------ B. quantification 1. static ------------------------------------------ STATIC QUANTIFICATION static quantification = quantification over the program text black-box AOP: quantification over public interfaces clear-box AOP: quantification over internal structures ------------------------------------------ What kind does AspectJ have? Do any of these require source code? Which are more useful for debugging? Which are more difficult to implement? 2. dynamic ------------------------------------------ DYNAMIC QUANTIFICATION quantification over dynamic events during a program's execution - raising of an exception - call of a subroutine when some other call has taken place - when the call stack is a certain size - when a RPC has failed five times ------------------------------------------ C. What's AOP? ------------------------------------------ IS IT AOP? rule-based systems (OPS-5, Prolog): event-based publish and subscribe: intentional programming and meta programming: generative programming: ------------------------------------------ Is AOP always related to object-oriented programming? D. summary II. Problems with Obliviousness A. What is modular reasoning? ------------------------------------------ WHAT IS MODULAR REASONING? "it should be possible to study the system one module at a time" -- Parnas def: a language L supports modular reasoning if the actions of every module M written in L can be understood based solely on: - the code contained in M and the code surrounding M, - the signature and behavior of any modules referred to by the code in M and surrounding M. E.g., in Java: module = compilation unit ------------------------------------------ How to specify behavior? B. the behavioral subtyping analogy 1. behavioral subtyping deals with obliviousness in OOP ------------------------------------------ OBLIVOUSNESS IN OOP public class Point { private /*@ spec_public @*/ int pos; public /*@ pure @*/ final int getPos() { return pos; } /* ... */ //@ requires true; //@ assignable pos; //@ ensures getPos() == //@ dist + \old(getPos()); public void move(int dist) { pos = pos + dist; } } public void client(Point p) { /* ... */ assert p != null && p.getPos() == 0; p.move(-10); assert p != null && p.getPos() == -10; } ------------------------------------------ ------------------------------------------ A SUBCLASS public class RightMovingPoint extends Point { public void move(int dist) { if (dist < 0) super.move(-dist); else super.move(dist); } } ------------------------------------------ What happens if this class is included? How can we prevent that? 2. similar problem in AOP ------------------------------------------ ANALOGY IN ASPECTJ public aspect MoveLimiting { void around(int dist): call(void Point.move(int)) && args(dist) { if (dist < 0) proceed(-dist); else proceed(dist); } } ------------------------------------------ What discipline, like behavioral subtyping, would allow modular reasoning in AOP? C. spectators and assistants 1. what needs to be supported in AOP ------------------------------------------ USES OF (DYNAMIC) AOP superimposition stories: - combining modules for separate concerns without surprising behavior evolution stories: - modifying behavior of existing programs without changing their code ------------------------------------------ 2. spectators support superimposition ------------------------------------------ SPECTATORS SUPPORT SUPERIMPOSITION Def: spectators are aspects that are prohibited from changing the behavior of the modules they advise. How? ------------------------------------------ 3. assistants support evolution ------------------------------------------ ASSISTANTS SUPPORT EVOLUTION Def: assistants are aspects that can do anything. How to support reasoning? Make their use acceptance explicit in the language. ------------------------------------------