an overview of aspects n.
Skip this Video
Download Presentation
An Overview of Aspects

Loading in 2 Seconds...

play fullscreen
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

Download Now 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