An Overview of Aspects

Shmuel KatzComputer Science

DepartmentThe Technion

Email: katz@cs.technion.ac.il

Overview Motivation and Background AspectJ: the standard for AOP Some other languages Aspects and design Validating aspects Some challenges

Basic claim of AOP Pure Object-Oriented doesn’t work!!! Gives one central decomposition—but

others are possible, and sometimes needed

Cross-cutting concern: one that involves many classes/methods

Tangling: code treating the concern is mixed with that for other concerns

Scattering: code treating the concern is scattered throughout the system

A Personal Note: My Interest

Early work on Superimpositions for distributed systems: identical motivation

Part of core group of EU’s 6th programme for a Network of Excellence on Aspect Oriented Software Development—beginning now…

My work on aspects: connecting requirements to proof; Design for aspects in UML; Specification and Correctness for aspects

Augmentations as subjects Syntax: how to express them? Classification: What types are there?

Spectative: only observes/records Regulative: affects control/ termination Invasive: changes values of existing fields

Specification: what do they add, to what?

Correctness/validation: how do we know they do what is intended?

Aspects and Superimpositions:Modularity for Cross-cutting For distributed:

Termination detection (Regulatory) Monitoring (Spectative) Fault-tolerance (Invasive)

For Object Oriented Monitoring and debugging Adding security Preventing overflow Enforcing a scheduling policy

Analyzing QOS and Performance

Aspects (and esp. AspectJ) Aspects: modular units that crosscut classes Aspects are defined by aspect declarations

and may include pointcut declarations: where to add/replace advice declarations: what to add or do instead Can introduce new methods, variables, code…

Weave (=bind) aspect to different systems (but not entirely separated yet…)

Pointcuts A program element that identifies join

points Denotes a (possibly empty) set of join points

kind of join point signature of join point Can be dynamic (calls within a context, look at stack)

call(void Line.setP1(Point))

Denotes the set of method call join points with this signature

primitive pointcut

signature

Advice Additional action to take at join points

Defined in terms of pointcuts The code of a piece of advice runs at every

join point picked out by its pointcut

pointcut move() :call(void Line.setP1(Point)) ||call(void Line.setP2(Point));

after() returning : move() {< code here runs after completion of each join point denoted by move >

}

advice type pointcut

advice body

parameters

Types of joinpoints and changes

Method calls Changes/uses of a field (variable) Method calls while another method is

active (relates to stack contents) Add code before/after/around joinpoint Replace previous with new code Often use types, fieldnames,…, from the

rest of the system (not fully generic)

Advice types before

Before proceeding at join point after returning

After execution of a join point completes normally after throwing

After execution of a join point ends abnormally (exception is thrown)

after After execution of a join point (completing either way)

around On arrival at join point gets explicit control over when

and if program proceeds

Some History AspectJ started at Xerox Parc, in a

team led by George Kiczales First presented in a paper at

ECOOP97, updated at ECOOP01 Today, it is incorporated into Eclipse,

and its homepage is there. Kiczales is at U. British Columbia

Obliviousness: a Basic Principle?

AspectJ assumes underlying system is unaware of any aspects: no explicit hooks

Aspects either are or are not applied…the system can function in either case

Is this necessary, or always possible?

Languages for Aspects AspectJ—the standard, seen so far HyperJ ---IBM’s approach to slices

(Ossher..) Treats Concerns, Less rich way of adding, but adds whole slice

Composition filters Only at method calls, cleaner treatment Mehmet Askit, U. of Twente

Demeter, Ceasar, Jasco, JAC,…

Hyper/J Decomposition of a system to

Concerns Some concerns conform to class

hierarchy—others do (and can) not Define hyperslices One logical decomposition: Company

has Research, Sales, Services, etc. Another: Company has Payroll,

Reporting, Managing, Work tasks Can move between decompositions

Declarative Completeness Each concern in a hyperslice:

Must declare everything to which it refers Don’t need to provide a full definition for these

declarations Thus, declaration can be abstract

Highly important because : Every hyperslice must represent a legal java program Creating self contained hyperslices Reuse and replace

Can be done automatically by Hyper/J

Relationships between HyperslicesNeed to define: Composition rule: Specify how hyperslices relate to one another,

which units correspond Brings up issues like:

Are two corresponding methods… Overriding one another? Both executed? What order? Return value? What if types of parameters are different?

Hyper/J VS. Aspect/J Aspect/J is a language Hyper/J is a tool with language elements

Aspect/J supports augmentation of single model Aspects augment classes & methods of distinguished

base hierarchy Hyper/J supports integration of multiple models

Can integrate few base hierarchies Less rich notation for Joinpoints

Aspect/J – incremental changes only

Some language issues Dynamic aspects: are they applied

only at compile time, or dynamically added or removed? (When can we weave?)

Genericity: do aspects refer to elements in the underlying system, or can they be reused for many systems?

Efficiency versus Expressiveness Correctness and validation: how to

specify and verify/test aspects?

Aspect Oriented Software Design Beyond programming languages and

implementations What should be in an aspect, or

collection of aspects? How may aspects interact?

Cooperate in Combinations of aspects Interfere

How to capture in design stage?

Examples of Early Aspects Theme/UML: adding aspects to UML, as

reusable modules to add to existing systems Can Persistence be viewed as an aspect?

Answer: yes, but not if application is oblivious Web caching as an aspect Extensions to UML to describe relations

among aspects in a Concern Diagram

Support for AOSD: CME IBM’s Concern Manipulation Environment

(T.J. Watson/Hurley) for Hyper/J and AspectJ An Eclipse AOSD Environment (as an

Eclipse Open Source Project?) Concern Explorer (part of JDK): finding

them.. Concern Manager Concern Visualizer Concern Composition (Weaver) for multiple

languages

Aspects for Components Some Aspects should be made into

components (but how?) Some Components should be Aspects! Aspects can be associated with a

component to allow customization Component Architectures are

implemented with wrappers and capture method calls

Services of JEBs replace aspects

Encryption, Authentication, Persistence can all be handled by standard services

Restricted to message-call pointcuts Has a built-in fixed solution, hard to

modify or configure Does isolate part of what aspects do…

Implement components using Aspects

Some experiments have been done Most promising direction: keep

component architecture with stubs and skeletons, and use it to implement AOSD constructs in a language-independent way

A potential problem: lack of standardization in services and language support

Prominent example: JBoss JBoss is an open-source implementation

of the J2EE platform Developed independently and freely

distributed Full support for the latest J2EE

specification Passed Sun's certification tests

The following discussion is with regard to version 4.0 Currently in "developer release" stages

JBoss and Aspects The lead developers of JBoss believe that

AOP "should have the same effect on software development that object-oriented programming (OOP) had 15-20 years ago" B. Burke (Chief Architect) and A. Brock (Director

of Support), 2003 As a J2EE platform, JBoss provides the

standard EJB aspects/services However, JBoss also includes a built-in AOP

framework and is written using aspects

Sources AOSD homepage: http://www.aosd.net AOSD Conferences in 2002, 2003, 2004 CACM issue of October 2001 AspectJ homepage:

http://www.eclipse.org/aspectj Composition filters, Caesar, others,… Books on aspects

Topics1a 1b– 31/10 Basic syntax, principles and examples for

AspectJ and use in Eclipse (the standard aspect language) 2a – 7/11 HyperJ: language and concepts of general

concern combination 2b -- HyperJ and Concern Manipulation Environment

(CME)

3a – 14/11 Composition filters: an elegant message-based approach

3b -- Composition filters support environment and analysis

4a – 21/11 Demeter: interesting ideas on dynamic aspects

4b -- Ceasar: dynamic aspect application and development

Topics (cont.) 5a – 28/11 JasCo: an aspect language intended for

components 5b -- JAC an environment for system development with

aspects in Java

6a – 5/12 Implementation issues: advice weaving in AspectJ

6b Static analysis of aspects

7a – 12/12 Just-in-time aspects 7b Virtual machine support for dynamic joinpoints

8a 19/12 Event-based aspects in EAOP 8b Composition, reuse, and interaction of stateful

aspects

Topics (cont.) 9a – 26/12 Verifying aspect advice modularly 9b – Aspect Validation and aspects for specification

10a – 2/1 Theme/UML: extending UML for aspects 10b – Architectural views of aspects in UML

11a – 9/1 Scenario-based specification of aspects 11b – Aspect requirements and traceability: Arcade

/Probe

12a – 16/1 Large-scale AOSD for middleware: a case study

12b – JBOSS and aspects for middleware 13a – 23/1 AspectWerkz: a framework for

AOdevelopment 13b – BBN and other frameworks for aspect development