This paper expresses collaborative change to behavior with a loose coupling to the behavior which is changed. Linda Seiter's thesis topic (Design Patterns for Managing Evolution). Shows that some Design Patterns are much easier to use when the programming language supports the right abstractions.

This paper is in the line of work also recommended by Grady Booch that patterns should be first class citizens that are an explicit part of the architectural modeling language. See his ROAD article.

Significantly improves the Visitor pattern. See the visitor usage discussion to see the importance of the visitor pattern. This paper improves the GOF visitor design pattern in two important ways: 1. Context Objects: so that we don't need a visitor entry for each traversed class and so that we can compose visitors. 2. Succinct traversal specifications: so that BOTH visitor and traversal specifications are robust under changes in class structure.

Two implementations supporting the improved visitor pattern are available. You should start with the very easy to use DJ system and later switch to the much more powerful Demeter/Java. Demeter/Java uses a preprocessor to process Java-like programs which take advantage of the improved Visitor pattern.

The paper adds context classes as an important ingredient of a language to express patterns. The book on Adaptive Programming contains descriptions of other important ingredients, such as navigation specifications and propagation patterns.

The paper has been accepted by the IEEE Transactions on Software Engineering with the following reviewer feedback:

REVIEWER FEEDBACK: ... In summary, this is an excellent, technically sound paper that introduces a novel mechanism that is applicable to various kinds of object systems. ...

Bibtex entry:

AUTHOR = "Linda M. Seiter and Jens Palsberg and Karl J. Lieberherr",
TITLE = "{Evolution of Object Behavior using Context Relations}",
BOOKTITLE = "Symposium on Foundations of Software Engineering",
YEAR = "1996",
ADDRESS = "San Francisco",
PAGES = "",
EDITOR = "David Garlan",

AUTHOR       = "Linda M. Seiter and Jens Palsberg and Karl J. Lieberherr",
TITLE        = "{Evolution of Object Behavior using Context Relations}",
INSTITUTION  = "College of Computer Science, Northeastern University",
YEAR         = 1996,
MONTH        = "April",
NUMBER       = "{NU-CCS-96-09}",
ADDRESS      = "Boston, MA"

AUTHOR = "Linda M. Seiter and Jens Palsberg and Karl J. Lieberherr",
TITLE = "{Evolution of Object Behavior using Context Relations}",
JOURNAL = "IEEE Transactions on Software Engineering" ,
YEAR = 1998,
PAGES = "79-92",
MONTH = "January",
VOLUME = 24,

============ The following maybe not needed.

In a next step it will be necessary to extend the expressiveness of context objects to make them do what transportation patterns can do but in a much better way. We need the capability to restrict the scope of context objects. We need to allow expressions like Exp1.m{Exp2:t} instead of only Exp1.m{Exp2}. t is a traversal function which limits where the context object determined by Exp2 is available.

The semantics needs to be extended to cover the incremental case: Exp1.m{+Exp2:t2, +Exp3:t3} ============ End of: The following maybe not needed.

Tradeoff between safety and adaptiveness
Context classes should have the following structure:

Context Class V {
	instance variables
	// several redefinitions:
	redefines C { // vertex based redefinition
	  // additional instance variables
	  D d; // not needed for attachment to objects
	       // only for attachment to calls
	  // overwrite or add new methods for C-objects
	  f(A) {};
	  // incremental methods for C-objects 
	  before {};
	  after {};
	  around {};
	  // incremental methods for edges from C-objects 
	  before l {}
	  after l {}
	  around l {}
	    // includes also "derived" edges (methods)
	  before x(A) {}
	  after x(A) {}
	  around x(A) {}
        redefines -> X,y,Y { // edge based redefinition 
	  // additional instance variables for source of edges
	  // overwrite or add new methods for source of edges
	  f(A) {};
	  // incremental methods for y-edge
	  before {};
	  after {};
	  around {};

New parts and functions may only be used in redefinition.
Either all incremental or all overwriting.

What is new here?

This removes the pollution of the class graph with information
which is only needed for a specific task.

Incremental modification of methods with before/after/around methods
is useful for dynamically changing objects incrementally
(feature composition).

Back to Adaptive Programming home page