Section 8.6. RELATED WORK

8.6. RELATED WORK

8.6.1. Open Classes

An open class is a class to which new fields or methods can be added without editing the class directly. For example, in MultiJava [6] additional methods can be attached to a class. In AspectJ, methods as well as fields can be added to a class by means of introductions. As already discussed in Section 8.2, open classes are in contrast to the concept of independent extensibility [24], an essential prerequisite for reusable and extensible software. CAESAR offers an alternative to open classes that is even more powerful and that does not violate independent extensibility.

CAESAR is also related to Hyper/J and its notion of multi-dimensional separation of concerns (MDSOC) [25]. Tarr et al.'s observation about the "tyranny of the dominant decomposition" is in the vein of our term "arbitrariness of the decomposition hierarchy." Our aspect bindings serve as a translator from one hierarchy to another and allow viewing and using a system from different perspectives. This is similar to the MDSOC idea of having multiple concern dimensions such that the program can be projected on each concern hyper plane. However, on the technical level, CAESAR is very different from Hyper/J. In Hyper/J, one can define an independent component in a hyperslice. Hyperslices are independent of their context of use because they are declaratively complete. That is, they declare as abstract method everything that they need but cannot implement themselves. A hyperslice is integrated into an existing application by means of composition rules specified in a hypermodule. As the result, new code is generated by mixing the hyperslice code into the existing code. Similar to PCAs, Hyper/J [25] also lacks the notion of collaboration interfaces and the reuse of bindings related to it. Either the modules to be composed are not independent due to the usage of the "merge-by-name" composition strategy, or the modules are independent, but then the non-reusable composition specification gets very complex. Similar to Adaptive Plug and Play Components (APPCs) and aspectual component models (Section 8.6.2), Hyper/J's approach is class-based. It is not possible to add the functionality defined in a hyperslice to individual objects. Furthermore, Hyper/J's sublanguage for mapping specifications from different hyperslices is fairly complex and not well integrated into the common OO framework.

Lasagne [26] is a run-time architecture that features aspect-oriented concepts. An aspect is implemented as a layer of wrappers. Aspects can be composed at runtime, enabling dynamic customization of systems. Lasagne also allows context-sensitive selection of aspects, enabling client-specific customization of systems. Although Lasagne is an architectural approach focusing on middleware (instead of a general purpose language extension as CAESAR), it has some similarity to CAESAR. In particular, Lasagne also features extensions that are created and deployed at runtime, and it also provides means to restrict the visibility of an extension to a particular scope (as our deploy block statement).

Bergmans and Akit have presented an extension of the composition filter model [1, 2] geared toward aspect-oriented programming. With composition filters, it is possible to define various filters for incoming and outgoing messages of an object. By means of AESAR, where almost everything is specified as usual OO code, composition filters are more declarative. On one hand, this makes it easier to express kinds of concerns that are easily expressible with the declarative sublanguage, but on the other hand it restricts its applicability to arbitrary kinds of concerns.

8.6.2. Adaptive Plug and Play Components

Adaptive Plug and Play Components (APPCs) [18] and their aspect-oriented variant of aspectual components (AC) [14] are related to our work in that both approaches support the definition of multi-abstraction components/aspects and have a vague definition of required and provided interfaces. However, the latter feature was not well integrated with the type system. Recognizing this deficiency, the successor model of Pluggable Composite Adapters (PCAs) [20] even dropped this notion and reduced the declaration of the expected interface to a set of standard abstract methods. With the notion of collaboration interfaces, CAESAR represents a qualitative improvement over all three models in support for multi-abstraction aspects. Due to the lack of a CI notion, connectors and adapters in APPC, AC, and PCA models are bound to a fixed implementation of an aspect and cannot be reused. In addition, APPCs and AC rely on a dedicated mapping sublanguage that is less powerful than our object-oriented wrappers with wrapper recycling. Finally, these approaches lack the notion of virtual types.

8.6.3. Collaboration-Based Decomposition

Finally, the question rises of how to position the work presented here with respect to previously published work on generic programming and collaboration-based decomposition (CBD). Generic programming and CBD approaches aim at providing modules that encapsulate a whole collaboration of classes; classes are decomposed into the roles they play in the different collaborations. The idea is nicely visualized by a two-dimensional matrix, with the classes as the column indexes and collaborations in which these classes are involved as the row indexes.

Mixin layers [23] and delegation layers [21] are two representatives of approaches to CBD. The former makes heavy use of generic programming as provided by C++ templates, whereas the latter uses a combination of virtual classes and delegation. Both approaches provide concepts for composing and decomposing a collaboration into layers such that a particular collaboration variant can be obtained by composing the required layers. Neither of these approaches support on-demand re-modularization. The definition of a collaboration layer in these approaches also encodes how the collaboration is integrated. The vocabulary of abstractions that are involved in an application is defined a-priori to the definition of any collaboration layer and is consequently shared by all layer definitions.

Collaboration layers are especially useful when we have many different variants of a particular collaboration (for example, Graph, ColoredGraph, and WeightedGraph) and want to mix-and-match these variants at runtime (for example, create a ColoredWeightedGraph by composing the color and the weight layer). Collaboration layers nicely complement the concepts proposed in this chapter, as they allow us to decompose both components and connectors into layers that can be combined on-demand. In the future, we plan to combine the dynamic composition features of the delegation layers approach with the concepts of the work presented here.

8.6.4. Implementation of Dynamic Deployment

Dynamic deployment brings about new challenges for the implementation of aspects. Implementing dynamic deployment via static preparation of the code is only possible if many dynamic checks (checking for deployed aspects in the current thread) are inserted into the code. A more elegant solution to implement dynamic deployment is to use run-time weaving. The Steamloom virtual machine [3] supports run-time weaving and has dedicated support for dynamic deployment of aspects. Hanenberg et al describe an approach to continous weaving [11] within which the instrumentation of code locations can be deferred until other dependent join points are triggered.