An Overview of Aspects Shmuel Katz Computer Science Department The Technion

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 6 th 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() { } advice typepointcut 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 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  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 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: AOSD Conferences in 2002, 2003, 2004 CACM issue of October 2001 AspectJ homepage: Composition filters, Caesar, others, … Books on aspects

Topics 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.) 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