Section 5.2. RESEARCH TRENDS IN THE EARLY 90S

5.2. RESEARCH TRENDS IN THE EARLY '90S

In writing this section, I have consulted a technical report written by my colleague Walter Hürsch and myself at the end of 1994 [12]. That report was titled "Separation of Concerns," and it was written when I was still at Northeastern University. In retrospect, it is evident that we missed a few important pieces of work and that we had a somewhat narrow vision of what was being separated. But overall, that report did a good job of capturing a trend that was in the air, and that is the reason why I am reproducing it here. People were talking about "separation of concerns;" our report captured the building blocks and the conceptual glue of what later became AOP and the AOP community. For reasons that fall out of the scope of this chapter, Walter and I stopped working on that report. I continued working on my thesis, which focused on concurrency and distribution Aspects.

What follows is a summary of that report. Parts in italics are verbatim text. In reading it, the reader should place him/herself in 1994. The reader should also be aware that the projects mentioned here have evolved considerably since 1994.

5.2.1. Formulation of the Problem

The increasing complexity of today's software applications and the advent of novel and innovative technology make it necessary for programs to incorporate and deal with an ever greater variety of special computing concerns such as concurrency, distribution, real-time constraints, location control, persistence, and failure recovery. Underlying all of these special purpose concerns is the basic concern responsible for the fundamental computational algorithm and the basic functionality. Special purpose concerns exist to either fulfill special requirements of the application (real-time, persistence, distribution) or manage and optimize the basic computational algorithm (location control, concurrency).

Typical approaches to integrate an additional concern have been to extend a given programming language by providing a few new programming language constructs that address the concern. An example of such an extension is the Distributed Real-time Object Language DROL (Takashio and Tokoro 1992), an extension of C++ with the capability of describing distributed real-time systems.

Even though the concerns may be separated conceptually and incorporated correctly, commingling them in the code brings about a number of problems:

• Programming intertwined code is hard and complex since all concerns have to be dealt with at the same time and at the same level. The extended programming language provides no adequate abstraction of concerns at the implementation level.

• Intertwined code is hard to understand because of the above lack of abstraction.

• Commingled code is hard to maintain and modify because the concerns are strongly coupled.

• Specific to object-oriented systems, the intertwined code gives rise to inheritance anomalies (Akit et al. 1994, Matsuoka and Yonezawa 1993) due to the strong coupling of the different concerns. It becomes impossible to redefine a method implementation or the commingled special concern in a subclass without redefining both.

Many researchers have recognized the above problems for single concerns in their specific area of expertise and have started to address them. Many devised techniques for separating individual concerns (Akit et al. 1992, Akit et al. 1994, Honda and Tokoro 1992, Okamura and Ishikawa 1994, Akit, Wakita et al. 1994, Lopes and Lieberherr 1994, Lieberherr et al. 1994).

5.2.2. Analysis of the Problem and Specialized Solutions

For software concerns, we distinguished two different levels of separation:

Conceptual level. At the conceptual level, the separation of concerns needs to address two issues. 1) Provide a sufficient abstraction for each concern as an individual concept. 2) Ensure that the individual concepts are primitive, in the sense that they address the natural concerns in the mind of the programmer.

Implementation level. At the implementation level, the separation of concerns needs to provide an adequate organization that isolates the concerns from each other. The goal at this level is to separate the blocks of code, which address the different concerns, and provide for a loose coupling of them.

The concerns identified at the conceptual level are mapped into the implementation level through programming language constructs. [. . .] Separation of concerns at the conceptual level is generally considered important and a primary means to manage complexity in all engineering disciplines. [. . .] However, few programming languages allow these abstractions to actually be separately programmed. The resulting code organization is monolithic, intertwining statements for different purposes [. . .].

We then turned to some approaches that had been suggested in the literature, including the work of our own group, Demeter [22, 24, 41]. We identified a set of papers that focused on the separation of some concern from the basic algorithmic concern. Table 5-1 gives an overview of this survey; I have now added more references than what we originally had.

Table 5-1. Approaches for Separation of Certain Concerns

Technique	Meta-Level Programming	Adaptive Programming	Composition Filters	Others
Class organization		Lieberherr [24]
Process synchronization	Watanabe [48]	Lopes [29]	Akit [3]	Frølund [7] Reghizzi [39]
Location control	Okamura [36]			Zeidler [50] Takashio [46]
Real-time constraints			Akit [2]	Barbacci [5]
Others				Liskov [25] Jacobson [14] Magee [32]

5.2.3. Identifying Concerns That Can Be Separated

In the "Separation of Concerns" report, Walter and I went on to analyze the major software concerns that had been referenced in the literature. We focused on class organization, synchronization, location control (configuration issues), real-time constraints, and failure recovery. We stressed the point that such a list was, by no means, exhaustive; we believed it was open-ended. For the purposes of that report, we were simply compiling a set of software engineering concerns that had been frequently referred to in different papers as problematic. We mentioned other examples such as debugging, persistence, and transaction management.

In the years that followed, these concerns would again be the central focus of AOP-related work. Later on, AspectJ introduced general-purpose aspect programming constructs that made the concept of "aspect" more general and helped open up the list.

5.2.4. Separation Techniques

In the report, we made a distinction between separation of concerns at the conceptual level and at the implementation level. The former may exist without the latter, and that was pretty much the state-of-the-art in 1994. There were, however, some programming techniques that looked promising for achieving the separation at the implementation level. Refer to Table 5-1 to see the techniques we identified at the time. What follows are the highlights of our analysis.

5.2.4.1 Meta-Level Programming

Meta-level programming is a well-know paradigm that has been documented in several publications (Smith 1984, Maes 1987, Watanabe and Yonezawa 1990, Kiczales et al. 1991, Okamura and Ishikawa 1994, among others). [. . .] A reflective system incorporates structures for representing itself. The basic constructs of the programming language, such as classes or object invocation, are described at the meta-level and can be extended or redefined by meta-programming. Each object is associated with a meta-object through a meta-link. The meta-object is responsible for the semantics of operations on the base object.

How does meta-level programming support the separation of concerns at the implementation level? By trapping message sends and message receives to objects, meta-objects have the opportunity to perform work on behalf of the special purpose concerns. For example, they can check for synchronization constraints, assure real-time specifications, migrate parameters between machines, write logs, and so forth. This allows the base-level algorithms to be written without the special purpose concerns, which in turn can be programmed in the meta-objects. Also, by having structural reflection (meta-knowledge about the relations between classes), meta-level programming can achieve separation between algorithms and data organization.

5.2.4.2 Adaptive Programming

The work described in Lieberherr et al. 1994 and Lopes and Lieberherr 1994 presents adaptive software, a programming model based on code patterns. Code patterns are classified in different categories, each one capturing abstractions in programming:

Propagation patterns define operations (algorithms) on the data. Propagation patterns identify subgraphs of classes that interact for a specific operation. References to the data are made in a structure-shy manner through succinct subgraph specifications, and the actual code is defined in code wrappers along traversal paths.

Transportation patterns abstract the concept of parameterization. They are used within propagation patterns in order to carry parameters in and out along the subgraphs.

Synchronization patterns define synchronization schemes between the objects in concurrent applications. Their purpose is to control the processes' access to the execution of the operations.

How does adaptive programming support the separation of concerns at the implementation level? Each pattern category addresses a different concern and can be viewed as a high-level software component that interacts with other components in a very loose manner through name resolution. Each pattern is quasi-independent of both the other patterns and the data organization. This has the effect, for example, that changes in the class organization don't necessarily imply updates in the patterns, and modifications of the algorithm (propagation patterns) don't necessarily imply changes in the synchronization scheme.

5.2.4.3 Composition Filters

The composition filter model is an extension of the conventional object-oriented model through the addition of object composition filters. We will focus here on the filterpart and how it can achieve separation. For a detailed description of the model and its various applications we refer to Akit et al. 1992, Bergmans 1994, Akit et al. 1994.

Filters are first class objects and thus are instances of filter classes. The purpose of filters is to manage and affect message sends and receives. In particular, a filter specifies conditions for message acceptance or rejection and determines the appropriate resulting action. Filters are programmable on a per class basis. The system makes sure that a message is processed by the filters before the corresponding method is executed: once a message is received, it has to pass through a set of input filters, and before a message is sent, it has to pass through a set of output filters.

How do composition filters support the separation of concerns at the implementation level? Separation of concerns is achieved by defining a filter class for each concern. For example, in Akit et al. 1994, a real-time filter RealTime was proposed to affect the real-time aspects of incoming messages. RealTime filters have access to a time object that is carried with every message and which specifies the earliest starting time and a deadline for the message.

Each filter class is responsible for handling all aspects of its associated concern. The filter mechanism gives programmers a chance to trap both message receives and sends, and to perform certain actions before the code of the method is actually executed. The resulting code is thus nicely separated into the special purpose concern (in the filter) and basic concern (in the method).

5.2.4.4 Discussion

Common to the above techniques is the fact that they provide some mechanism to intercept message sends and receives. Meta-object protocols perform the interception at the meta-level through computational reflection and reification of messages. Composition filters trap messages through the built-in filter mechanism. In both cases, interception was done at run-time. Pattern-oriented programming achieves message interception at compile time; the pattern compiler detects when a method needs to be extended with code for special purpose concerns and inserts that code directly, similar to a preprocessorno interception is done at run-time. [. . .]

An important aspect of meta-level programming is that the separation of concerns is not imposed by the model. [. . .] Rather, meta-level programming facilitates the separation of concerns by providing the reflective information about the constructs of the language itself. Programming the special purpose concerns at the meta-level is a strategy that may or may not be followed by the programmers. This is contrary to filters and code patterns, which provide specific language constructs to achieve the separation of concerns. As a consequence, both the filters approach and the code patterns approach require new language construct for each new concern, while in the meta-level programming that is not the case.

In retrospect, we missed at least one important piece of related work: Subject-Oriented Programming [10]. We also missed the opportunity to compare all these approaches with an emerging wave, design patterns [8]. But the important thing about our paper was that it pointed out how the search for better expression mechanisms that focused on certain software development concerns were, in fact, driving a large number of research efforts at the time. This research was being driven by some common goal, and it was important for me to understand what that was. I wanted to formulate the kernel of the problem that was prompting so many solutions. Why weren't C++ and Lisp good enough?