CS 4448 - Fall 1998
Object-Oriented Programming and Design
Talk 12.1
by
Maurine Hobbs
AspectJTM
by
XEROX - Palo Alto Research Center
-
Introduction.
The articles I read included this one, the Users Guide and Primer, the AspectJ Language Specification as well as earlier ones defining the need for Aspect Oriented Programming Languages and the problems they thought they could address. They are concerned with the category they call Cross-Cutting problems. Many of the problems are performance related because optimization often exploits information about the execution context that spans components. Since most Generalized Procedure languages decompose into units encapsulated into procedure/function/object categories they tend not to deal well with units of system composition that are not functional. These are the ones they classify as aspects. Using these concepts they break down system implementations using GP languages into components and aspects.
-
Definitions
-
Components
Components: These units can be clearly encapsulated in a generalized procedure (i.e. object, method, procedure, API). This means well localized, easily accessed and composed as necessary. They tend to be units of a systems functional decomposition , such as image filters, bank accounts and GUI widgets.
-
Aspects
Aspects: Cannot be cleanly encapsulated in a generalized procedure and tend not to be units of the systems functional decomposition. Rather they are properties that affect the performance or semantics of the components in systemic ways ( i.e. memory access patterns and synchronization of concurrent objects).
-
Examples from various languages (Lisp, C++, Fortran etc.)
Image Processing: GP Language - procedural; Components - filters: Aspects - loop fusion, result sharing, compile-time memory and allocation.
Digital Library: GP Language - object oriented; Components - repositories, printers, services; Aspects - minimizing network traffic, synchronization constraints, and failure handling.
Matrix Algorithms: GP Language - procedural; Components - linear algebra, operations; Aspects - matrix representation, permutation, and floating point errors.
-
Structure
Component Language: Any GP language that suits the system implementation.
Aspect Language or Languages: Xerox seems to be developing separate Languages for each GP application as well as subsets for each language to address various aspect problems such as concurrency issues, loop fusion and error catch and throw problems.
Compiler or Interpreter for the Component Language: Lisp, Fortran, C++, Java etc. .
Aspect Weaver: Provided by Xerox and can be used at Compile or Run Time.
- Java Specific Issues (see Figures 1, 2 and 3)
JCore: JCore is JAVA with some restrictions.
Removal of Keywords: Xerox removed the keyword synchronized and the methods wait, notify, and notifyAll. This is done to enforce that synchronization is done in the coordinators, not in the JCore classes.
Overloading of methods: This is disallowed because the join points between JCore and the aspect languages are over names of methods and classes so they avoid having to differentiate methods with the same name. (Note: overriding of methods is fully supported. Overloading of constructors is also supported.)
Class Literals: Removed - see above note.
-
The Coordination Aspect Language
COOL: Provides a means for dealing with mutual exclusion of threads, coordination state, conditional suspension and notification, in relative separation from the classes. It consists of coordinator modules processed in units. These are refinements of the classes' implementation and concentrate in only one place those parts that deal with coordination.
Import Declaration: Indicates the packages with which the coordinator is associated.
Coordinator Declaration_List: Have no proper names and can't be named in the classes' implementation or by other coordinators. Each class name can appear in at most one coordinator declaration. It is single class if it involves only one class and multiclass if its declaration involves more than one class.
Body: Declares condition and ordinary variables, optional initializers, exclusion constraints on method execution and method guards. Their scope is the coordinator declaration. Declarations of condition variables, ordinary variables and exclusion constraints may include the modifier static.
Exclusion Constraint declarations:
Self exclusion of individual methods: A self-exclusive method declaration identifies a method that is to be executed by at most one thread at a time (i.e. method will not have concurrent executions).
Mututal exclusion of sets of methods: A mutually-exclusive method set declaration identifies a set of methods that is to be executed by at most one thread at a time (i.e. any two methods that belong to the same mutex set will not have concurrent executions).
Method Guards: This code is executed immediately before and immediately after method execution. They may declare pre-conditions, inspect the objects' state and modify the coordinator's state. Changing the value of a condition variable results in issuing automatic notifications to threads that are waiting on pre-conditions including those variables. They are atomic entities and all computation made in a guard (checks and state changes) is guaranteed to be thread-safe and free of race conditions.
-
Issues
Real World Applications: How much does it help and how do you identify which applications it would help most?
Assesment: Which AOP systems can be designed and tested quickly without having to create extremely large ones to test the concepts:
Libraries: How can we develop useful common libraries for component and aspect languages that can be plugged together in different ways for different applications?
Integration: How to integrate into existing approaches, methods, tools and development processes.
Copyright © University of Colorado. All rights reserved.
Revised: Novemeber 17, 1998