An overview of aspects
1 / 31

An Overview of Aspects - PowerPoint PPT Presentation

  • Uploaded on

An Overview of Aspects. Shmuel Katz Computer Science Department The Technion Email: Overview. Motivation and Background AspectJ: the standard for AOP Some other languages Aspects and design Validating aspects Some challenges. Basic claim of AOP.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' An Overview of Aspects' - abba

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
An overview of aspects

An Overview of Aspects

Shmuel Katz

Computer Science Department

The Technion



  • Motivation and Background

  • AspectJ: the standard for AOP

  • Some other languages

  • Aspects and design

  • Validating aspects

  • Some challenges

Basic claim of aop
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
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
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
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 (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…)


  • 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


  • 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



advice body

Types of joinpoints and changes
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
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
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
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
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
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 hyperslices
Relationships between Hyperslices

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


  • AOSD homepage:

  • AOSD Conferences in 2002, 2003, 2004

  • CACM issue of October 2001

  • AspectJ homepage:

  • Composition filters, Caesar, others,…

  • Books on aspects


1a 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
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 cont1
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