An Overview of Aspects Shmuel Katz Computer Science Department The Technion Email:...
-
Upload
chad-taylor -
Category
Documents
-
view
213 -
download
0
Transcript of 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 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