Section 16.5. RELATED TECHNOLOGIES AND TOOLS

16.5. RELATED TECHNOLOGIES AND TOOLS

16.5.1. Aspect-Oriented Languages and Tools

AspectJ [11, 14] is a powerful language that provides support for the implementation of crosscutting concerns through pointcuts (collections of principle points in the execution of a program) and advice (method-like structures attached to pointcuts). Precedence rules are defined when more than one advice applies at a join point. In many features (e.g., pointcuts definition) AspectJ has rich and vast semantics. Nevertheless, we argue that in many cases that we have studied, simple schemes such as the wrapping technique proposed by JAC are sufficient to implement a broad range of solutions dealing with separation of concerns. AspectJ is a compile-time approach, whereas JAC is oriented toward run-time AOP: Aspects can be woven or unwoven on-the-fly. This feature is particularly useful for distributed applications, where application servers that cannot be stopped may still require some level of reconfiguration. For example, dynamic aspects allow introducing monitors for faults. In our opinion, the AspectJ rich syntax and compile-time approach makes it suitable for general-purpose aspect-oriented applications, whereas JAC features dedicate it for dynamic applications running in open environments. Under such circumstances, JAC also shares objectives with EJB [29] application servers such as J2EE. The main difference between the two approaches is that JAC containers are open and can be extended with any required technical services (implemented as an AC), whereas technical services are hard-coded in EJB containers and can simply be configured with XML descriptors, not changed or extended.

The composition filter object model (CFOM) [1] is an extension to the conventional object model where input and output filters can be defined to handle sending and receiving messages. This model is implemented for several languages, including Smalltalk, C++, and Java. The latter implementation is an extension to the regular Java syntax where keywords are added to declare, for instance, filters attached to classes. The goals of this model and ours are rather similar: handling separation of concerns at a meta level. Many similarities exist between composition filters and JAC wrappers. They both control the way method invocations are delivered or not to the final business objects. Nevertheless, JAC wrappers follow a programming model that does not require any extension to the Java language.

Aspectual components [15] and their direct predecessors, adaptative plug and play components [16, 17], define patterns of interaction called participant graphs (PGs) that implement aspects for applications. PGs contain participant roles (e.g., publishers and subscribers in a publish/subscribe interaction model) that (1) expect features about the classes on which they are mapped, (2) may reimplement features, and (3) provide some local features. PGs are then mapped onto class graphs with entities called connectors that define the way aspects and classes are composed. Aspectual components can be composed by connecting part of the expected interface of one component to part of the provided interface of another. Nevertheless, it seems that by doing so, the definition of the composition crosscuts the definition of the aspects, thereby losing the expected benefits of AOP.

Subject-oriented programming [9, 18] (SOP) and its direct successors, the Hyper/J tool [31] and the Concern Manipulation Environment (CME) [7], provide the ability to handle different subjective perspectives, called subjects, on the problem to model. Subjects can be composed using correspondence rules (specifying the correspondences between classes, methods, fields of different subjects), combination rules (giving the way two subjects can be glued together), and correspondence-and-combination rules that mix both approaches. Prototype implementations of SOP for C++ and Smalltalk exist, and a more recent version for Java called Hyper/J is available. This latter tool implements the notion of hyperspace [19] that permits the explicit identification of any concerns of importance.

An approach relatively close to the spirit of JAC is the Mozart project [34]. Mozart is an open distributed programming system on the Oz language that provides object/component-orientation, declarative, logic, and constraint programming. It provides a good degree of separation of concerns with support for multiple paradigms. Despite its complete nature, the core Mozart does not take full advantage of new AO programming concepts such as aspect-classes or pointcuts. In our opinion, it is therefore more difficult to comprehend and less flexible, as the provided concerns are built-in (but configurable) within the system.

Superimpositions [27] are also an approach for separation of concerns in distributed environments. This approach is a theoretical work that furnishes a language that can be applied to AOP. We are currently working on using some of the fundamental concepts of superimpositions in our aspects.

Finally, several projects such as Lasagne [33], JMangler [13], and PROSE [25, 26] provide dynamic weaving/unweaving of aspects that are similar to JAC. However, none of them fully handles the automatic distribution of aspects as JAC does.

16.5.2. Comparison with Design Notations for Aspects

Suzuki and Yamamoto's study [30] is one of the first on aspects and UML. They extend the standard UML notation and designate aspect classes with a stereotype called <<aspect>>. These classes are then related to base classes using a realization relationship. Nevertheless, nothing is said about how to express pointcuts or how to define whether advices are applied before, after, or around a join point. The stereotypes introduced in Section 16.2 answer these needs.

Theme/UML [5, 6] is an AOSD design-level language defined by Clarke and Walker and is the direct successor of work done by these authors on subject-oriented design. Theme/UML allows designing crosscutting concerns as separate models in so-called composition patterns (CP). Unless their name contains the term composition, these are units of specification for a concern. They can be seen as AspectJ abstract aspects. Strategies for merging elements from the composed models and resolving conflicts are defined. The models are packages labeled with the <<subject>> stereotype. They define a class diagram for a particular concern (e.g., the observer design pattern, with a subject and observers notified whenever state changes occur in the subject). They allow some degree of variability in the sense that they are templates. The template parameters represent exported elements from the package to be bound to elements of other base packages: they define a crosscut. The binding is specified with a bind clause attached to the base package. Crosscuts with JAC are relationships from the aspect class to the base class, and not between the packages containing these elements. Hence, the resulting diagrams are of lower level with JAC but are in our sense more precise. Also, the semantics of crosscuts with Theme/UML are related to a merge operation, whereas JAC aspect class diagrams reflect the before, after, and around options for an advice. Finally, the ambition of Theme/UML is to be a general-purpose aspect-oriented design notation independent of any programming approach, whereas the JAC design notation is directly linked to its programming model, allowing our CASE tool to generate code.

Stein, Hanenberg, and Unland present in [28] a design notation for the AspectJ programming model. They precisely define representations for all AspectJ language constructs. They take advantage of many UML facilities and extend four categories of diagrams to express aspect-oriented notions: interaction diagrams, class diagrams, collaboration diagrams, and use cases. First, join points are highlighted in interaction diagrams whenever they appear. UML interaction diagrams represent method invocations but leave apart instance creations and reads and writes of instance variables. Thus, they are extended with these pseudo-operations that may be concerned by join points. Second, in class diagrams, stereotypes exist to label aspects, pointcuts, and advice. When writing pointcuts and advice, an additional property named base is defined to hold the implementation of the pointcut. A new relationship named <<crosscut>> signifies the crosscutting effect of aspects on base classes. Third, parameterized collaborations are used to represent introductions of members (constructors, methods, fields) and relationships (inheritance, implementation) to the base class structure. Finally, use cases define the weaving order at each join point, e.g., whether an advice is to be executed before, after, or around the join point. This work is, as far as we know, the most advanced on defining a design notation for AspectJ constructs. As the JAC programming model is simpler than AspectJ, our design notation can be simpler than theirs. However, we think that the use cases of this work may be less intuitive than the stereotypes used in JAC. Also, introductions defined in terms of collaboration diagrams may be hard and long to write. This is the price of having a notation fully compliant with UML. The way we perform introductions with the JAC notation is more pragmatic and is completely left as an implementation issue for the CASE tool (the current version of our CASE tools let AC designers enter the introductions as lines of code). This limitation should be solved in future versions of the notation.