Research Projects: Implicit Context
My primary research concerns the use of dynamic context in easing
problems of software evolution and reuse through a combination of
dynamic execution information and system structural information.
Implicit context is a model for the transformation of
localized world views. IConJ is a language and preprocessor
for the application of implicit context transformations to Java source
code. Essential structure is a principle guiding the
application of implicit context transformations. Essential structure
is to implicit context as policy is to mechanism.
This research is currently taking three different paths:
In addition, there are some more general
references about implicit context available.
The ideas involved in implicit context were developed as my PhD
thesis. My supervisor, Gail Murphy, helped me to focus and direct these
ideas. We maintain our collaboration on this topic. My other thesis
committee members were Kelly Booth, Mike
Feeley and Alan Mackworth.
- Robert James Walker. Essential Software Structure through
Implicit Context. Ph.D. thesis, Department of Computer Science,
University of British Columbia, March 2003. [Adobe PDF]
The most complete reference to read about implicit context is my
PhD thesis; the first chapter gives an overview of the ideas of
essential structure and implicit context.
- Robert J. Walker and Gail C. Murphy. Dynamic Contextual
Reflection: A Mechanism for Software Evolution and Reuse. In
Walter Cazzola, Robert J. Stroud, and Francesco Tisato, editors,
OORaSE '99---OOPSLA'99 Workshop on Reflection and Software
Engineering (Proceedings) (Denver, USA; 1 November), pp. 43--50,
1999. [superceded] [Adobe
PDF]
A position paper describing some of the early ideas about implicit
context (called dynamic contextual reflection at the time).
- Robert J. Walker. Contextual Programming. In
Proceedings: 21st International Conference on Software
Engineering (Los Angeles, USA; 16--22 May), pp. 734--735,
1999. Doctoral symposium, extended abstract. [superceded]
[Adobe PDF]
An initial groping towards the ideas of essential structure and
implicit context (called contextual programming at the time).
Essential structure is the idea that one can "boil down" a
module to its essence, that most modules contain a lot of details that
are there strictly for the sake of the global system view and not for
the sake of local needs. These extra details are termed extraneous
embedded knowledge or EEK (an acronym that was purely serendipitous
but that amused me). My PhD
thesis is the most thorough accounting of essential structure at the
moment.
- Robert J. Walker. Supporting Inconsistent World Views. In
Proceedings of the Workshop on Software Engineering Properties of
Languages for Aspect Technologies (Boston, USA; 17 March), 2003. Held
at the 2nd International Conference on Aspect-Oriented
Programming. [Adobe PDF]
A position paper looking at one of the key properties of implicit
context that is needed to permit modules to express only their
essential structure. A full paper is currently in the works.
- Robert J. Walker and Gail C. Murphy. Implicit Context: Easing
Software Evolution and Reuse. In David S. Rosenblum, editor,
Proceedings of the ACM SIGSOFT Eighth International Symposium on
the Foundations of Software Engineering (FSE-8): Foundations of
Software Engineering for Twenty-First Century Applications (San
Diego, USA; 8--10 November), ACM Press, pp. 69--78, 2000. [Adobe PDF]
An earlier analysis of implicit context, before the idea of
essential structure had crystalized, and before automated support for
the application of implicit context had been developed. The work has
progressed significantly since this paper was published.
- Robert J. Walker and Gail C. Murphy. Using Implicit Context to
Ease Software Evolution and Reuse. Technical report TR-99-13,
Department of Computer Science, University of British Columbia,
Vancouver, Canada, 11 November 1999. [superceded] [Adobe PDF]
The initial version of the FSE 2000 paper listed above.
Communication history is, conceptually, a record of every
communication (method call, procedure call, field access, etc.) that
has occurred within an execution "so far". This record can
be queried from within the execution to determine properties about the
system and to retrieve information that has previously been
communicated.
One can use communication history queries to reduce the overall
knowledge of the system that must be embedded within individual
modules. In the absence of communication history, one must sometimes
implement a given module to store data or provide an interface that is
of no importance from a purely local perspective. An example would be
the Observer design pattern: modules acting as Subjects must provide
the appropriate interface. However, there is no locally recognizable
purpose in such a module providing this interface: the need for it
arises only at a more global level. By making the appropriate
communication history queries, we can effect the same behaviour as
defined in an object-oriented Observer design pattern without
embedding the knowledge of its use in every module. Modules acting as
Subjects are then not so tightly coupled to the continued use of the
Observer pattern.
The idea of using communication history is similar to the principle
of "structure-shy" programming found in Lieberherr and
colleague's Demeter project. There, behaviour is defined relative to
static structural patterns; here, we define behaviour relative to
dynamic patterns sought in the execution.
My PhD thesis describes
these ideas in more detail.
The current project involves the development of an efficient means
to support communication history queries. My MSc student Kevin
Viggers is currently implementing such a means.
- Robert J. Walker and Kevin Viggers. Communication History
Patterns: Direct Implementation of Protocol Specifications.
Technical report 2004-736-01, Department of Computer Science,
University of Calgary, January 2004. [Adobe PDF]
This technical report describes the use of communication history in
capturing patterns in an execution, to more closely implement a
protocol specification than can be done with other AOP approaches. A
brief description of Kevin's implementation is given; he implemented
it as an AspectJ extension, disconnected from the remainder of
implicit context.
- Robert J. Walker and Gail C. Murphy. Joinpoints as Ordered
Events: Towards Applying Implicit Context to Aspect-Orientation.
In Proceedings for Advanced Separation of Concerns Workshop
(Toronto, Canada; 15 May), pp. 134--139, 2001. Held at the 23rd
International Conference on Software Engineering. [Adobe PDF]
A position paper extending the notion of join point and connecting
some of the ideas of aspect-orientation to implicit
context. Join points and communication history are closely tied.
I am not willing to say too much about this project at the moment.
Basically, it deals with determining what external modules and
interfaces a given module is dependent upon. However, this analysis
proceeds in an unusual and important way.