Subject-Oriented Programming (SOP) and Adaptive Programming (AP)

IBM maintains an excellent site on Subject-Oriented Programming.

Subject-oriented Programming (SOP) is a program composition technology from IBM initiated by Harold Ossher and Bill Harrison. A subject is a collection of class fragments whose class graph models its domain in its own subjective way. Subject composition combines subjects to produce new subjects combining the functionality of the sub-subjects.

A subject has an affinity to an adaptive program. While a subject deals with class fragments, an adaptive program deals with class-valued variables which are mapped later onto class fragments automatically generating the necessary glue code. While a subject has to deal with all involved class fragments explicitly, an adaptive program only talks about the important class-valued variables. After the mapping to classes, code will be generated automatically for the less important classes based on the information in the traversal strategies and the class graph. We believe that traversal strategies simplify the composition rules for SOP and that composition of adaptive programs can benefit from the composition ideas already developed for SOP.

In a position paper from IBM for the ECOOP 1998 workshop on AOP Operation-Level Composition: A Case in (Join) Point, it is pointed out that SOP has focussed on two central issues which also are at the core of research on aspect-oriented programming:

1. Facilitating the description of cross-cutting concerns in a software system and

2. Facilitating the integration of join points

Subject-oriented programming focuses on operations as join points (as opposed to statement-level join points) and functional aspects. Some examples of functional aspects which are best described in terms of operation join points are: Persistence, error detection and handling, fault tolerance, logging, tracing and metrics-gathering.

The conclusion of the position paper says: SOP is an approach to AOP that is based on operation-level joining.

Most incarnations of Aspect-Oriented Programming (AOP) and AP also have this quality. Connection between Aspect-Oriented and Adaptive Programming: Some history behind the names and concepts. In D (and its two implementations: Demeter/Java and AspectJ), the coordination and remote invocation aspects are expressed in terms of operations.

Traversal strategies are often also used with operation join points in mind. For example, a traversal strategy defines a set of traversal methods which get sandwiched between additional code defined in visitors or APPCs. Design methodology paper on APPCs (OOPSLA 98). "before A ... after A ..." means that before calling the traversal method for A to call first the before code and after calling the traversal method to call the after code. In adjuster-style APPCs, a participant name can be used anywhere in a method and therefore we have here a successful form of statement level joining.

The unique feature which distinguishes AP from SOP is that in AP many of the join points are left implicit and are only specified explicitly if they are important. For example a traversal strategy "from A to B" can define implicitly any number of join points for the traversal methods which bring us from A to B. If we want to print tracing information during the traversal, we would write a visitor like "before * this.print()" which would exercise all the join points (* means: all classes in the traversal scope). But explicitly mentioned are only source A and target B.

Conclusions: Both SOP and AP are concerned with cross-cutting and join points, two central issues also in AOP. Adaptive Programming allows the subject-oriented programmer to focus only on the important join points which leads to simpler, more flexible and more easily composable subject-oriented programs. SOP can benefit from traversal strategies of AP and AP can benefit from the composition mechanisms available in SOP.

To Demeter/Adaptive Programming home page