ACM Computing Surveys 28A(4), December 1996, Copyright © 1996 by the Association for Computing Machinery, Inc. See the permissions statement below.

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

Karl Lieberherr

Northeastern University, College of Computer Science
161 Cullinane Hall, Boston, MA 02115, USA,

Abstract: Object-oriented programs evolve over time and it is desirable to capture the persistent parts of the programs early on and then derive the transient versions of the programs from the persistent parts. 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 and Adaptive Programming and Aspect-Oriented Programming provide novel tools for this purpose.

Categories and Subject Descriptors: D.2.10 [Software Engineering]: Maintenance - Extensibility; H.2.1 [Database Management]: Logical Design - Schema and Subschema

General Terms: Design, Maintenance, Languages

Additional Key Words and Phrases: Adaptive Programming, Structure-Shy Modeling, Aspect-Oriented Programming.

1 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.

The work at Northeastern University on software architecture is distinguished by using techniques of Adaptive Programming (AP) to capture architecture. AP 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 visitor objects. Traversals are specified succinctly taking advantage of the structure of object-oriented programs. Work on AP is collected in [Lieberherr 1996] and the latest improvement to AP makes extensive use of the Visitor Pattern [Gamma 1995].

In AP, the core behavior is expressed in visitors. The visitors have ports consisting of classes and relationships. The ports are connected in two phases, using first strategical connections to express persistent information and then tactical connections to express the transient parts. The strategical connections are expressed by traversal specifications and the tactical connections by class graphs.

To describe the state of objects robustly, AP also uses two phases. In the first phase, objects are described by sentences which express the selections made. Those selections tend to represent the persistent information about the object. In the second phase, the details of the object structure are given in the form of an extended class graph which is a grammar. Much of the grammar information tends to be transient. Parsing is used to create the object directly from the sentence.

AP promotes the idea that core behavior needs to be modified in a variety of different ways when an application is built. We may want to modify the behavior of all objects of a class or only of individual objects. The modification may be permanent or last only during a call. The modification may change how threads are synchronized or how parameters are passed. [Lopes 1996] extends AP by adding a third aspect, called synchronization, to behavior and structure. The decoupling of the three aspects into separate sublanguages allows synchronization descriptions to be reused for different behaviors and structures. The synchronization language of [Lopes 1996] allows to express the following: Additional structure and operations, mutual exclusion sets, preconditions, reactions to false preconditions and initialization and finalization actions.

Aspect-oriented programming (AOP) is a term coined and developed at Xerox PARC [Kiczales 1996]. AOP is a generalization of AP by allowing any number of aspects to influence the core behavior (not just structure and synchronization) [Guerraoui 1996]. In AOP, a computation is subdivided into a base computation and several secondary computations. Each secondary computation, as well as the base computation, corresponds to an aspect which is described separately in its own language. The thesis of AOP is that programs become simpler and more reusable. AP is a special case of AOP: In AP also several aspects are allowed but succinct traversal specifications and class graphs must be used by the aspects. So we can summarize: AP is AOP restricted to using traversal specifications and class graphs (within any number of aspects).

In AOP a program is described by several loosely-coupled aspects which are combined together into an efficient 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 secondary aspects are localized and so that changes to those aspects don't have too many repercussions. In my view, AOP is inherently a matter of programming in program families. Since a given aspect description does not talk about too many details of other aspects, it describes a family of programs.

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.

2 Patterns

Work on patterns in software development has been popularized by the design pattern book [Gamma 1995]. Patterns can be classified in different categories: programming, design, architectural and organizational [Guerraoui 1996]. 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, lower-level 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.

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. What kind of features do architecture description languages need to express design patterns?

3 Conclusions

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


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 some common ground between adaptive programming, software architectures and patterns.


[Gamma 1995]
Erich Gamma and Richard Helm and Ralph Johnson and John Vlissides, 1995. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley.
[Guerraoui 1996]
Guerraoui, R. et al, 1996. Strategic Research Directions in Object-Oriented Programming, Computing Surveys, 28A, 4 (December),
[Kiczales 1996]
Kiczales, G. et al, 1996. Aspect-Oriented Programming (AOP) Computing Surveys, 28A, 4 (December),
[Lieberherr 1996]
Lieberherr, K. J., 1996. Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns , PWS Publishing Company , ISBN 0-534-94602-X,
[Lopes 1994]
Lopes, C., and Lieberherr, K., 1996. Abstracting Process-to-Function Relations in Concurrent Object-Oriented Applications, European Conference on Object-Oriented Programming, Bologna, Italy, editors Remo Pareschi and Mario Tokoro, pages 81-99, Springer Verlag, Lecture Notes in Computer Science.

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or

Last modified: Fri Nov 1 12:33:39 EDT 1996
Karl Lieberherr <>