Position Statement for working group on object-oriented programming within the ACM Workshop on Strategic Directions in Computing Research held at MIT, June 14-15, 1996.

From Transience to Persistence in Object Oriented Programming: Architectures and Patterns

Author: Karl Lieberherr

Object-oriented programs (like most programs) evolve over time and it would be ideal if we could capture persistent parts of the programs early on and then derive the transient versions of the program from the persistent part. In our view, the object-oriented community is moving in this direction through its work on software architecture and patterns. Capturing the persistent parts of a program allows us to better maintain the integrity of the program during evolution.

Software Architecture

The goal of software architecture is to capture the persistent parts of the program and to derive the transient versions using architecture refinement. A number of architecture description languages are under development. Common to many of those architecture description languages is the concept of components and connections between them. Work in this area is summarized in the Architecture Guide.

The work at Northeastern on software architecture is distinguished by using adaptive programming (AP) to capture architecture. This has the advantage that architectural refinements can be automated in many cases. An adaptive program tries to capture the persistent parts of an object-oriented program by using traversals and context objects. Traversals are specified succinctly taking advantage of the structure of object-oriented programs. Work on AP is collected in the adaptive programming book and recent developments are described in Collaborative Behavior Modification.

The work on adaptive programming has connections to many other approaches such as Open Implementation. Those connections are further explored in a description of AP with five patterns. The Inventor's Paradox pattern abstracts from the specifics of AP and tries to describe something which Gregor Kiczales calls Aspect-Oriented Programming (AOP). In AOP a program is described by several loosely-coupled aspects which are woven together into a combined program. In my view, the goal of AOP is to make programs robust to changes in one aspect and to avoid redundancy in the programs. AOP strives to describe the aspects of an application in such a way that the volatile aspects are localized and so that changes to those aspects don't have too many repercussions. This leads to a better description of the persistent parts of the application. A definition of AOP is under preparation at Xerox PARC and the above summary might not be correct.

In the application of AOP to AP we have three aspects: The structural aspect (class graph), the navigation aspect (traversal specifications), and the behavior modification aspect (context objects). The three aspects are described by three little languages, one per aspect. Adaptive programs are robust since they are robust to changes in the class graph and also robust to changes in the context objects. AP eliminates redundancy since the class graph information is not repeated many times in the program.

AP is programming by hooks which loosely couple the parts together. The program for each part defines hooks into other parts. When all parts are given, the hooks are combined, if necessary, by weaving instructions. (we borrow the term "weaving" from AOP; but AOP is more general than AP.) The hooks are used to formulate the weaving algorithm. In the simplest form of AP, the hooks are classes and edges in the class graph to which we refer selectively to express context objects and traversals.

One feature of interesting applications of AP is that the weaving algorithm is sophisticated enough so that from weave(A1,A2,A3) it is not possible to uniquely determine a part even if all other parts are given. On the other hand, the weaving algorithm cannot be too sophisticated since it must be fast. For example, in simplest form of AP with class graphs and traversal specifications, it is usually impossible to uniquely determine the traversal specifications from the object-oriented program, the class graph and the context objects.

The typing of adaptive programs is a challenge. We call a program (A1,A2,*) type-correct if there exists a part A3 such that weave(A1,A2,A3) is type-correct. Jens Palsberg is currently studying the typing of adaptive programs: Given an adaptive program consisting of traversal specifications and context objects, is there a class graph which creates a type-correct object-oriented program.

The typing of adaptive programs is influenced by the generality of the weaving algorithm. If the weaving algorithm needs to make many restrictions regarding what can be woven together, the typing question becomes more difficult. It is important that the weaving algorithm is general purpose. See the work on compiling adaptive programs Efficient Implementation of AP , and Automata Theoretic Compilation.

The work on meta-object-protocols is also concerned, to some degree, with persistence versus transience and with software architecture. The idea is that the persistent parts of the program are expressed at the base level while the transient parts are expressed at the meta level. The meta level provides building blocks for the base level and ideally most changes to the program can be accomplished by changing the meta objects and programs. See URL: http://www.parc.xerox.com/spl/projects/oi/

Patterns

Work on patterns in software development has been popularized by the design pattern book [GOF]. Patterns can be classified in different categories: programming, design, architectural and organizational. Patterns contribute to capturing the persistent parts of a program by describing often used solutions to problems in a context.

The work on design patterns will develop in a number of directions. New patterns will be added to the catalog of well known patterns. Patterns of different levels of abstraction will be developed. Finally, well known patterns will be supported directly by tools. To develop those tools, it is necessary to have a notation to describe patterns so that a tool can operate with patterns. Tasks which can be automated are: analyzing patterns, customizing patterns, composing patterns, retrieving patterns.

Analyzing means to check whether the pattern is ``type-correct'' and customizing means to check for proper application of a pattern to a program and to automatically create the code prescribed by a pattern.

The emerging field of architecture description languages can play an important role in producing models and tools to make work with patterns even more productive. An architecture description language ought to be expressive enough to express design patterns and even some architectural patterns.

However there are high-level patterns which will not (yet) lend themselves to automation. For example, the description of AP with five patterns leads to high-level patterns, called Class Graph, Structure-shy Object, Structure-shy Traversal and Context which would be hard to describe formally and would be hard to automate. What kind of features do architecture description languages need to express design patterns?

Conclusions

More work is needed to explore techniques which allow us to better express the persistent properties of program families. The ideas behind AP should prove useful to formulate software architectures and patterns at a higher level of abstraction.

At the programming language level, it would be useful to integrate the AP concepts of traversals and contexts into the programming language Java.

References

DEMETER:
@BOOK{karl:demeter,
AUTHOR = "Karl J. Lieberherr",
TITLE = "Adaptive Object-Oriented Software:
The Demeter Method with Propagation Patterns",
PUBLISHER = "PWS Publishing Company, Boston",
YEAR = "1996",
NOTE = "ISBN 0-534-94602-X"
}
(see URL: http://www.ccs.neu.edu/research/demeter)


GOF:
@BOOK{gang-of-4,
AUTHOR = "Erich Gamma and Richard Helm and Ralph Johnson and John Vlissides",
TITLE = "Design Patterns: Elements of Reusable Object-Oriented Software",
PUBLISHER = "Addison-Wesley",
YEAR = "1995"
}
The theme of persistence versus transience was suggested in a talk by Kesav Nori at the Tata Research Center in Pune, India. This theme nicely captures the common ground between adaptive programming, software architectures and patterns.

Back to AP home page

Karl J. Lieberherr
College of Computer Science, Northeastern University
Cullinane Hall, Boston, MA 02115
Internet: lieberherr@ccs.neu.edu
Fax: (617) 373 5121