CAMPaM Aspects of Aspect-Orientationmsdl.cs.mcgill.ca/conferences/CAMPaM/2007/material/presentations/... · of Concurrency and FailuresÓ at ECOOP 2002 ... CAMPaM Aspects of Aspect-Orientation

CAMPaM Aspects of Aspect-Orientation

CAMPaM

Aspects of Aspect-Orientation

Jörg KienzleSchool of Computer Science

McGill University, Montreal, QC, Canada


Talk Outline

• Background on AOP

• Crash-course on AspectJ

• My view of the “Essence” of Aspect-Orientation

• Weaving, Scattering, Tangling, Crosscutting

• Aspects and Reuse

• Aspect Dependencies and Interactions

• AspectOPTIMA Example

• Comments on Obliviousness

2


Aspect-Orientation History

• Initial Paper in 1997 by Kiczales et al. at ECOOP 1997

• First International Conference on Aspect-Oriented

Software Development (AOSD) in 2002

• Today Researchers work on Aspects at all Levels

• “Early Aspects” (Aspects in Requirements)

• Aspect-Oriented Modeling

• Aspect-Oriented Programming

• SPLAT, FOAL, AOM, ADI Workshops

• Industry Adoption has started

• Siemens / Motorolla / IBM

3


My Background on Aspect-Orientation

• Got interested in AOP as a means for providing elegant

APIs to frameworks / middleware / libraries• Enforcing programming rules / conventions

• Co-organizer of the Aspect-Oriented Modeling workshops

at MoDELS and AOSD (currently at edition 9)

• Controversion paper “AOP Does it make Sense? The Case

of Concurrency and Failures” at ECOOP 2002

• Papers on AspectOPTIMA studying aspect dependencies

and interferences

• Submitted paper on “Obliviousness” to OOPSLA

4


Aspect-Orientation

• Aspect-oriented programming (AOP) languages

provide advanced features enabling the modularization

of crosscutting concerns in source code

• Problem decomposed into aspects, which are later on woven

together at well defined join points to produce the final application

• Aspect-oriented software development (AOSD)

techniques aim to provide systematic means for the

identification, separation, representation and

composition of crosscutting concerns

5


Aspect-Oriented Programming (1)

• Object-Orientation

• Decompose problem into a set of abstractions / objects

• Objects encapsulate state and behavior

• Are assigned responsibilities

• “Tyranny of the dominant decomposition” [T+99]

• Result:

• Similar / identical code-fragments, all implementing some

common functionality, are often scattered through the code

6


Aspect-Oriented Programming (2)

• Modularize crosscutting concerns at the

programming language level

• Decompose problem into aspects, encapsulating

different concerns of the application [K+97]

• Weave aspects together for final product

• Weaving happens at so-called joinpoints

• Benefits: Simpler structure, improve readability,

customizability and reuse

7


AspectJ [K+01]

• Aspect-Oriented extension of Java

• Pointcuts

• Make it possible to name a set of joinpoints, e.g. method calls,

setting or getting field values, etc.

• Advice

• Specify behavior at joinpoints

• Introduction

• Add fields / methods to classes

• Aspects

• Group together pointcuts, advice and introductions

8


AspectJ Joinpoints (1)

• Joinpoints are identified using pointcut designators

• Methods and constructors

call(Signature), execution(Signature), initialization(Signature)

• Example:

call(public * Account.get*(..))

• Exception handling

handler(TypePattern)

• Example: handler(TransactionException+)

• Field accesses

get(Signature), set(Signature)

• Example: get(private * Account+.*)

9



• Objects

this(TypePattern), target(TypePattern), args(TypePattern, …)

• Example:

call(public * Account.get*(..)) && this(AccountManager)

• Lexical extent

within(TypePattern), withincode(Signature)

• Example:

call(public * Account.get*(..)) &&withincode(public void AccountManager.transfer())

• Based on control flow

cflow(Pointcut), cflowbelow(Pointcut)

• Example:

cflow(public void AccountManager.transfer()) &&call(public * Account.get*(..))

10



• Conditional

if(Expression)

• Example:

if(debugEnabled) &&call (public * Account.*(..))

• Combination

!, &&, || and ()

11


AspectJ Pointcuts

• Pointcuts group together a set of joinpoints, and

can pass on values from the execution context

• Examples:pointcut PublicCallsToAccount (Account a) :call(public * Account.*(..)) && target(a);

pointcut SettingIntegerFields (int newValue) :set(* int Account.*) && args(newValue);

12


AspectJ Advice

• Add behavior before, after or around a joinpoint

• Example:around PublicCallsToAccount(Account a) { if (a.blocked) { throw new AccountBlockedException(); } else { proceed(); }}

13


Introduction or Inter-type Declaration

• Even the account class does not provide the

“block” functionality, we can add it through

introduction

• Example:private boolean Account.blocked = false;public void Account.block() { blocked = true;}

public void Account.unblock() { blocked = false;}

14


AspectJ Aspect

• Aspects group everything relevant for implementing a

particular concern

15

public aspect BlockAccounts {! pointcut PublicCallsToAccount (Account a) :! call(public * Account.*(..)) && target(a);! private boolean Account.blocked = false;! public void Account.block() { !blocked = true;! }around PublicCallsToAccount(Account a) { if (a.blocked) { throw new AccountBlockedException(); } else { proceed(); }}

}


Advanced AspectJ

• Abstract aspects and pointcuts

• Implementing interfaces / inheritancedeclare parents : Account implements Blockable;

declare parents : Point extends GeometricObject;

• Compile-time checking, e.g. for verifying

programming conventionsdeclare error : Pointcut : String;

declare warning : Pointcut : String;

• Reflective access to run-time information through

the static thisJoinPoint variable

16


AO Interface for Transactions

public abstract aspect TransactionalMethod {

abstract public pointcut Method();

void around() : Method () {

ProceduralInterface.beginTransaction();

boolean aborted = false;

try {

proceed();"

} catch (TransactionException e) {

ProceduralInterface.abortTransaction();

aborted = true; throw e;"

} finally {

if (!aborted) {

ProceduralInterface.commitTransaction();

}

}}}

17


Applying Transactions

class AccountManager {

public void transfer(Account source,

Account dest, int amount) {…}

}

aspect MakeAccountMgrMethodsTransactional

extends TransactionalMethod {

public pointcut Method () :

call (public * AccountManager.*(..));

}

18


What is “the essence” of an Aspect?

• That’s a good question!

• How does it differ from a Class, a Component, a

Viewpoint?

• Aspects (AOM workshop at UML 2004)

• Modularize structural and/or behavioral properties

• Are first-class entities

• Are instantiable entities

• Provide introspection and intercession capabilities

• Provide mechanisms to define (extrinsic) properties of other elements

• Break encapsulation of other elements

19


Weaving

• Mapping from a source representation to a target

representation

20

Source

Target Module A Module B Module C Module D

Aspect X Aspect Y Aspect Z


Scattering

• A source module is scattered in a target

representation if part of it ends up in many target

modules

21

Source




Tangling

• A target module is tangled if it is composed of

parts of several source modules

22

Source




Crosscutting

• X crosscuts Y iff X is scattered in the target

representation, and there exists a module in the target

within which X and Y are tangled

23

Source




Asymmetric AO

• Well-identified base elements do not (and are not

allowed to) crosscut

24

Source

Aspects

Target

Aspect X Aspect Y Module A Module BSource

BaseModule C

Module A Module B Module C


Aspects and Reusability

• Assumption: since aspects are modularized

concerns, it should be straightforward to reuse

them within a different application

• Lots of issues

• Aspect Bindings: how to separate them

• Aspect Dependencies: how to specify them in a reusable

way• Aspect Orderings: how to specify them in a reusable way

• Aspect Interference: how to detect and resolve them

25


Aspect Case Study: Transactions

• A transaction groups together a set of

operations on data objects, guaranteeing the

ACID properties

• Atomicity

• Consistency

• Isolation

• Durability

26


AspectOPTIMA

• Different transaction models have common properties

• Nesting, multi-threading, synchronous exit, etc...

• Atomicity and Isolation implemented by Concurrency

Control and Recovery Mechanisms

• Concurrency control and recovery are separate

concerns at a higher level of abstraction

• At the implementation level, the two concerns are

tightly coupled

• Share parts of the implementation

• Certain combinations are incompatible with each other

27


Design of AspectOPTIMA

• 3 high-level concerns

• Objects

• Threads

• Contexts (or computations)

• We identified 12 aspects for objects, 3 for threads, and 13

for contexts

• Each aspect is individually reusable

• They can be combined in many different ways to

implement different transactional models with different

concurrency control and recovery mechanisms

28


Per Object Aspects

29

AccessClassified Named CopyableLockable

 ContextAware Shared Trackable VersionedSerializable

 ContextTracker

Checkpointable

Persistable

• Many interferences: e.g. Copyable and Shared


Per Thread Aspects

30

ContextParticipant

 Collaborative OutcomeAware


Per Context Aspects

31

 Nested Collaborative OutcomeAware Pausable

 Terminatable

 VotedOutcome

 Tracking

 SyncExit Checkpointing Deferring 2-Phase-Locking

 Recovering

 SyncEntry

{xor}

• Many COMPLEX interferences: e.g. 2PL and

Nesting, Deferring and Nesting


Example Configuration

• Flat Transactions, 2-PL, In-place Update,

Snapshot-based Recovery

• Threads: ContextParticipant

• Context: 2-PL, Recovering, Checkpointing,

Tracking

• Objects: ContextAware, Shared, Named, Lockable,

AccessClassified, Checkpointable, Versioned

32


An Operation Invocation

33

:ContextAware :AccessClas:Tracking :Named:Checkpointing :Shared :Object

op(..)

getKind(op)

getContext(..)

getName()

work(..)

establish()

:Checkpointable :Versioned :Copyable

op(..)

op(..)getKind(op)

op(..)

getKind(op)

:ContextPartic :Lockable

lock(..)

newVersion()copy()

work()

:Context

work()

:Recovering

getModified()

work(..)

:2-PL

getModified()


Aspect Frameworks and AO Languages

• Implementation of AspectOPTIMA in AspectJ

• Essential Language Features• Separate Aspect Binding

• Inter-Aspect Configurability

• Inter-Aspect Ordering

• Per-Object (per instance) Aspects

• Dynamic Aspects

• Thread-Aware Aspects

[TAOSD, in press]

34


Comments on Obliviousness

• Filman et al. stipulated that Obliviousness is a

fundamental property of Aspect-Orientation [F2000]

• We believe that there are two dimensions of

obliviousness: syntactic and semantic [sub. to OOPSLA]

• Semantic obliviousness is always bad

• The higher the syntactic obliviousness, the better

(provided that...)

• Aspect-Orientation can provide high levels of syntactic

obliviousness!

35


Levels of Syntactic Obliviousness

36

DSAL

GPAL

Annotations

Highly Tangled Code

Total Syntactic

Obliviousness

Total Syntactic

Awareness

Sem

antic B

indin

g E

ffort

Semantically Correct

Binding Depends on

Aspect and Base Details

Correct Binding Can Be

Expressed in Terms of

the Semantic Concepts

Synta

ctic

Obliv

iousness

Bin

din

g L

anguage P

ow

er


Open Issues / Current Research

• Expressiveness of Joinpoint Models and

Pointcut Languages

• Dependencies / Interactions / Interference

between Aspects

• Reusability

• Scalability of Weavers / AO Environments

• Affect of Aspects on “Software Engineering

Principles”

37

CAMPaM Aspects of Aspect-Orientationmsdl.cs.mcgill.ca/conferences/CAMPaM/2007/material/presentations/... · of Concurrency and FailuresÓ at ECOOP 2002 ... CAMPaM Aspects of Aspect-Orientation

Documents