Abstraction in computer science helps to manage the complexity of software [Sha84].
Abstraction is the process of emphasizing and hiding the details of software at different
levels and to different degrees. Abstraction refers also to a construct or concept that has been subjected to the process of abstraction [Kru92]. Separation of concerns and modules are the enabling technologies for abstraction. But abstraction is more than breaking down a system into modules. Abstracting from details means to introduce new concepts or constructs and to introduce new descriptions or formalizations that condense relevant information and that reduce complexity. A principal goal of abstraction is to express a design or implementation issue in terms of abstractions that are close to what the programmer has in mind when thinking about this issue.
An abstraction of a software artifact consists of a high-level, intuitive, and useful spec-ification that maps to a realization at a lower level; the specspec-ification describes “what”
the abstraction does, whereas the realization of the abstraction describes “how” it is done [Kru92].
In our evaluation we examine the abstraction capabilities of FOP and AOP for imple-menting program features. Since both AOP and FOP rely on OOP, we focus only on those abstraction mechanisms that exceed the level of traditional OOP (e.g., classes, methods) and on how they differ.
4.1.2 Crosscutting Modularity
Modularity is the property of software systems that measures the extent to which they have been composed of modules. We focus exclusively on crosscutting modularity since FOP and AOP are equal with respect to modularization mechanisms known from OOP.
Specifically, we use the results of the previous chapter to examine how aspects and feature modules perform in modularizing the different classes of crosscutting concerns that occur when implementing features, which are classified by our framework. That is, we evaluate how AOP and FOP perform in modularizing homogeneous and heterogeneous as well as static and dynamic crosscutting concerns.
4.1.3 Feature Cohesion
Cohesion is the ability of a feature to encapsulate all implementation details that de-fine the feature in one unit [BK06, LHBC05]. While modularity addresses the internal structure of a feature, i.e., the modular implementation of the artifacts that implement a feature, cohesion addresses the feature as a whole, i.e., the encapsulation of all artifacts that contribute to the feature. The highest degree of cohesion is achieved by a one-to-one mapping of requirements to corresponding units at implementation level [CE00].
For example, it is easier and more intuitive to plug a cohesive data management com-ponent to a cohesive network driver in one step than to connect the data management and the network software in many places by hand.
4.1 Evaluation Criteria
composed program
base program feature
Figure 4.1: Integrating features by superimposition.
4.1.4 Feature Integration
Once a set of desired features has been selected, they are integrated to form a tailored software product. Principally, we distinguish between two types of feature integration:
Superimposition: One way to apply a feature to a program is to superimpose the pro-gram structure with the structure of the feature [OH92, Ern03, SB02, BSR04, OZ05, Bos99]. The concept of superimposition was first proposed for combin-ing control structures of distributed processes [BF88, CM86, Kat93]. In terms of object-orientation, superimposition means that the class hierarchy of the program is merged with the class hierarchy of the feature [OH92], where the latter hierarchy is a sparse version of the former. The merging is applied recursively and structural elements are merged by name and type; merging classes is implemented by set union and merging methods is implemented by overriding.
Figure 4.1 illustrates the process of superimposition by example: on the left side is the class hierarchy of the base program; classes of the base program are depicted as white boxes. The program’s class hierarchy is superimposed (denoted by ‘•’) by a sparse class hierarchy of a feature; gray boxes are the classes of the feature and dashed white boxes mark the not-affected classes of the base program. On the right side the result of superimposing the structures of the base program and the feature is depicted; white boxes are the unmodified classes of the base program;
gray boxes are the classes introduced by the applied feature; boxes that are half white and half gray denote the merged classes of base program and feature.
Crosscutting integration: Superimposition as feature integration technique is not al-ways sufficient [MO02, MO03, LLO03]. Sometimes the structure of a feature does not fit the structure of the base program. This happens (1) when a feature is reused in different base programs that have different structures and (2) when a programmer wants to express a new feature in terms of abstractions that differ from those in the base program [Nov00]. For example, suppose a network software is refined by an application protocol. The protocol at application level can be ex-pressed more easily in terms of producer (server), consumer (client), and product
composed program base program feature
Figure 4.2: Crosscutting integration of features.
(delivered data) than by using the basic network abstractions such as sockets and streams. Since there are no structural counterparts between the two components it is complicated to achieve a clean mapping, i.e., it is not possible to superimpose their structures. Thus, such integration results in code scattering and tangling.
Figure 4.2 illustrates the process of a crosscutting integration of features: the left side shows the base program, the middle a feature, and the right side the composed program. Within the composed program the original base program and the applied feature are integrated via a set of links (denoted by dashed arrows) that connect the structural elements of both sides, e.g., object references, method invocations, advice, wrappers. In contrast to superimposing features, the integration pattern is cluttered. The links between base program and feature crosscut the program’s as well as the feature’s structure. Moreover, additional code for establishing the links is necessary.
4.1.5 Feature Composition
Features can be composed to form a new features. Technically, features are composed by superimposition or crosscutting integration. Using feature composition a programmer reuses code, which is beneficial because thinking in terms of existing features is often easier than building features from scratch. For example, constructing a data manage-ment feature out of simpler features such a storage managemanage-ment, query evaluation, and caching, is more efficient than constructing a tailored data management component for each use case from scratch.