Section 8.1. INTRODUCTION

8.1. INTRODUCTION

As early as 1972, Parnas [22] noted that the criteria that we choose for decomposing software systems into modules have an important impact on the software engineering properties of the resulting system. For example, a data-centric decomposition eases changes in the representation of data structures [22], whereas function-centric decomposition makes it easy to modify functions of the system or add new features [10]. With the aspect-oriented software development paradigm, the decomposition problem is considered under a new light: The question is now not as much about which criteria to choose as it is about how to support the decomposition of systems simultaneously according to several independent criteria. Such simultaneous decompositions are needed because our perception of the world and especially our perception of software systems depend heavily on this idea: Observing a software system from different perspectives may imply completely different decompositions of the concerns, yielding crosscutting models.

For a technical definition of the term "crosscutting," the reader is referred to Masuhara and Kiczales [16]. Here we give an informal (graphical) characterization. Consider Figure 8-1. Each shape stands for a particular object (in the most general sense) of a software system. We have three options for organizing this space: by size (see Figure 8-2), by shape (see Figure 8-3), or by color (see Figure 8-4). The resulting classifications are all equally reasonable models of the space, but they are not hierarchically related. That is, they do not represent more or less detailed views of the space.

Figure 8-1. Abstract concern space.

Figure 8-2. Divide by size.

Figure 8-3. Divide by shape.

Figure 8-4. Divide by color.

Informally speaking, a model M₁ would be a specialization of another model M₂ if, for each class^[1] C₁ C₂ C₁ is contained in C₂. Indeed, if we consider, for example, the size and shape of the models, some of the objects in the class rectangle in the shape model are classified as big in the size model, while others are contained in the class small. Being independent, not specializations of each other, is (roughly speaking) what characterizes "crosscutting models"their units of decomposition intersect but do not subsume each other.

^[1] The term "class" is used here to denote an element of the partition of the space implied by a model.

The motivation for the AO paradigm is that traditional software decomposition techniques lack appropriate support for crosscutting models. They assume that real-world systems have mind-independent concept hierarchies. As a result, most parts of a software system are defined in terms of the same global program structure. While multiple models of the system might actually be supported, these models are hierarchical, rather than crosscutting, views of a system. With decomposition techniques so far, we organize the system as a hierarchy of packages/classes/procedures, and we can have a more or less detailed view of the system. This is also reflected in the idea of organizing software in layers, another invention of structured programming [7]. The key point here is that crosscutting is not appropriately supported.

With a mind-independent hierarchical decomposition, we have to choose one fixed classification sequence, such as the one shown in Figure 8-5. In this example, the classification sequence was color, shape, size. The problem with such a fixed classification sequence is that all relevant independent decomposition criteria have to be forced into it. The result is code scattering and tangling. Figure 8-5 illustrates the scattering problem by means of the concern circle, whose definition is scattered around the hierarchical decomposition (cuts across the modular units of the color-driven decomposition of the system). Only the color concern (the first element in the classification sequence) is cleanly separated into white, grey, and black, but even this decomposition is not satisfactory because the color concern is still blended (tangled) with other concerns. We call this problem the arbitrariness of the primary model.

Figure 8-5. Arbitrariness of the decomposition hierarchy.

The 'arbitrariness of the primary model' problem is related to the 'tyranny of the dominant decomposition' [25], meaning that "existing languages and formalisms generally provide only one, dominant dimension along which to separatee.g., by object or by function" [25]. We prefer the term 'arbitrariness of the primary model' and its formulation given here, because it emphasizes that the problem arises not because only one dominant decomposition mechanism, such as classes versus functions, is supported. One can actually simulate functional decomposition in an object-oriented language [28]. The problem is the primary mental model: Hierarchical decomposition requires a primary model and other models that are subordinate, as illustrated in Figure 8-5.

8.1.1. Requirements on Language Support

Having characterized the term "crosscutting model" and the problems resulting from the lack of support for such models, let us consider the requirements they impose on the module definition and composition mechanisms. In this discussion, the term aspect is used to denote a piece of software that is expressed in terms of a particular model and that needs to be combined with other aspects, which are encoded in different crosscutting models.

8.1.1.1 Multi-Abstraction Aspect Modules

Appropriate module constructs are needed to express an aspect as a set of collaborating abstractions comprising the modular structure of the world as seen by the aspect. This allows each aspect to be described in terms of its own model, thereby escaping the arbitrariness of the primary model. For example, it should be possible to define the color aspect in terms of the hierarchy in Figure 8-4, i.e., in terms of the concepts "white," "grey," and "black," as well as relations between them. The advantage of supporting the definition of an aspect as a set of mutually recursive abstractions that interact via well-defined interfaces is more or less a direct derivate of the advantages of the object-oriented approach to modeling a world of discourse.

8.1.1.2 Aspect Composition

Given a set of independent crosscutting multi-abstraction models, we need mechanisms to define how they come together during the execution of the system, including the specification of when/where and how different models join the execution. The specification of when/where involves the definition of points in the execution of the system and eventually conditions under which models come together. The specification of how involves mappings between abstractions in different models. This is because values comprising the state of the system at a certain execution point are, in general, simultaneously instances of different abstractions (are classified under different classes) in different crosscutting models.

8.1.1.3 Reuse of Aspect Implementation and Bindings

Modules for expressing individual aspects should follow the open-closed principle [17]. On the one hand, they should be self-contained, capturing the "inherent" structure and behavior of one particular aspect independent of other aspects. On the other hand, due to being partial, perspective-specific views of a system, individual aspects cannot alone capture the complete system definition. They must somehow rely on compositions to fill in the other parts of the definition. Given this distinction between the "closed" and "open" parts of an aspect, the question is how to capture the interaction between them so that their definitions, the aspect implementation and aspect binding, can be reused independently. In the following, we briefly explain why such reuse makes sense.

An aspect implementation that is tightly coupled with a particular aspect binding, by the virtue of being defined within the same module, cannot be reused with other possible bindings. Hence, this particular aspect implementation must be rewritten for every meaningful binding, thereby rendering the application tangled, as the aspect implementation itself becomes crosscutting. Especially for non-trivial aspects with complex implementations, this rewriting of the aspect implementation is tedious and error-prone.

An aspect binding that is tightly coupled to a specific aspect implementation is also undesirable. A binding translates the concepts, terms, and abstractions of the application's world into the world of the particular aspect domain. Its usage is better not limited to a specific aspect implementation. For example, consider the calculation of shortest paths graphs modeled as an aspect in terms of edge and node abstractions. Consider now the calculation of shortest paths in a computer network for efficient routing. Binding a shortest path calculation aspect would involve mapping concepts of edges and nodes to respective abstractions in the aspect defining the structure of a computer network. Now, it makes sense to reuse this binding with different possible shortest path algorithms, taking advantage of their different performance properties.

8.1.1.4 Aspectual Polymorphism

Given that the intelligence of the system, i.e., of the entities making up the running system, is distributed among several equally important crosscutting models, it is important to support a new kind of polymorphism, aspectual polymorphism. Aspectual polymorphism is the counterpart of the subtype polymorphism in object-oriented languages. Subtype polymorphism allows us to write some polymorphic functionality pf to a high-level model of the system HM (a set of types, TS) and polymorphically reuse it with any detailed model conforming to HM (consisting of subtypes of the types in TS used within the definition of pf). We could also say that usual subtype polymorphism is hierarchical: It fits the hierarchical decomposition mechanisms available in object-oriented languages.

The idea behind aspectual polymorphism is that we want to be polymorphic not only within a hierarchy of models but also across independent crosscutting models. Aspectual polymorphism allows us to write polymorphic functionality to one of the crosscutting models of the system and combine it polymorphically with code that is written to any other crosscutting model.

To make things more concrete, consider a hierarchy that divides figures into different shapes, as in Figure 8-3.^[2] This means that it is possible to write a method with a Figure parameter that is polymorphic with respect to the shape of the figure. Aspectual polymorphism means that polymorphism is available with respect to any hierarchical decomposition. In terms of the example, this means that the code can simultaneously be used polymorphically with respect to color and size of figures as well!

^[2] In Figure 8-3, the figures represent abstract concepts and not graphical figures, but for the purpose of this example, let's just consider them as graphical figures.

Aspectual polymorphism is strongly related to the idea of fluid aspect-oriented programming, the "ability to temporarily shift a program (or other software model) to a different structure to do some piece of work with it, and then shift it back" [13]. Let us see how usual object-oriented polymorphism via late binding fits into this picture: Calling a method m(X x) with a parameter x that can be assigned polymorphically (i.e., x might refer to an instance of a subclass of X) at runtime can be seen as temporarily (during the execution of the method) shifting or transforming this method so that calls to methods of the parameter object are dispatched to the method implementations of the respective class of x. In this way, usual late binding can be seen as a primitive form of fluidity. It is limited, because one can only "transform" with respect to our single decomposition hierarchy.

8.1.2. Contribution and Structure of the Chapter

In this chapter, we argue that existing aspect-oriented approaches do not properly satisfy the requirements stated previously. Section 8.2 argues that the concepts that have been in the focus of aspect-oriented research, join points (points in the execution of a base program to intercept) and advice (how to react at these points), are only a part of the solution concerning the arbitrariness of the primary model. More powerful means for structuring aspect code are needed on top of join point interception (JPI). To keep the discussion focused and to clarify our terminology, in Section 8.2, we concentrate on join point/advice approaches only. In Section 8.6, we consider the deficiencies of other approaches.

To resolve the problems discussed in Section 8.2, we propose the CAESAR model in Section 8.3. CAESAR is based on the notion of collaboration interfaces (CIs) [19] as a means to better support a-posteriori integration of independent components into existing applications. We show that CIs and the related notions of separated CI implementations and CI bindings, once properly adapted to the needs of aspect-orientation, can also be applied to support a more modular structuring of aspect code and better aspect reuse. In Section 8.4, we evaluate CAESAR with respect to the problems identified in Section 8.2. The current state of an implementation of the model is discussed in Section 8.5, related work in Section 8.6, and future directions in Section 8.7.