Section 4.1. INTRODUCTION

4.1. INTRODUCTION

During the last several years, many aspect-oriented languages have been proposed, including such representative examples [19] as adaptive programming [29], hyperspaces [32], AspectJ [25], and Composition Filters (CFs) [12]. The idea of CFs dates back to as early as 1986. As such, it is among the earliest, if not the first, aspect-oriented language. Like other approaches, the CF model has evolved. This chapter presents the contemporary CF model, illustrating how it can address certain modeling problems and providing insight into its motivations and design rationale.

The structure of this chapter is as follows: in Section 4.1, we introduce the background and objectives of the CF model. Section 4.2 introduces an example, which is used to illustrate the issue of composing and reusing multiple concerns in object-oriented programs when requirements evolve. In Section 4.3, the CF model is presented as an approach to address the identified problems. This section introduces the CF model, focusing on its application to concerns that crosscut within an object. Section 4.4 extends this discussion by explaining how the CF model can address crosscutting over multiple objects. Section 4.5 evaluates the CF model, Section 4.6 discusses common misconceptions about the CF model, and Section 4.7 presents our conclusions.

4.1.1. Background and Aims of the Composition Filters Model: Finding the Right Abstractions

The CF model has originated from the Sina language, which was first published in 1988 [6]. The concepts and ideas of Sina have since evolved, with the main objective being to improve the composability characteristics of object-oriented and, ultimately, aspect-oriented programming languages.

We use the term composability to refer to the ability to define a new program entitywith a behavior as requiredas the construction of two or more program entities. We distinguish two key elements of composability. The first element refers to the mechanisms (or composition operators) used to compose software units (objects, aspects, etc.). Typical composition operators are inheritance, aggregation, and weaving mechanisms. The second key element refers to the properties or restrictions imposed on software units to make them safe for composition. For example, well-defined interfaces and declarative join point models may contribute to safe composition; these can be used for early detection of problems such as references to non-existent program elements and naming conflicts. The challenge is to find the right balance between the expressiveness of composition mechanisms and the restrictions imposed on software units. Addressing this challenge has been the main focus of the work on composition filters.

A fundamental design decision of the CF model is to distinguish two kinds of abstractions: (class-like) concerns and filters. Briefly, a concern is the unit for defining the primary behavior, while a filter is used to extend or enhance concerns so that (crosscutting) properties can be represented more effectively.

The main objectives of the composition filters model are summarized here. Later in this chapter, we discuss how these objectives are addressed.

Composability. Support composition (of the behavior) of modules into new modules with the desired behavior.

Evolvability. Extend existing (object-oriented) programming models in a modular way, instead of replacing or adapting them.

Robustness. Support the creation of correct programs through appropriate language abstractions that avoid common programming mistakes and enable verification of certain quality properties.

Implementation-independence. Allow multiple implementations of the same behavior, including both static and dynamic implementations, tradeoffs between time and space efficiencies, and execution on different platforms.

Dynamics. Support dynamic adaptation of structure and behavior to meet changes in requirements or context, without compromising the above objectives.