ACM Computing Surveys 28A(4), December 1996, http://www.acm.org/surveys/1996/Formatting/. Copyright © 1996 by the Association for Computing Machinery, Inc. See the permissions statement below.
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.
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.
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?
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 firstname.lastname@example.org.