Hi Dean:

Thank you for all the papers/thesis you brought. They are very interesting.
I wrote the description below for my group/www readers.
Do you agree?
Will put this into:
http://www.ccs.neu.edu/research/demeter/related-work

-- Karl



Functional Representation is a subarea of model-based
reasoning which is itself a subarea of AI.
In recent years, functional representation has been applied to software.

There are interesting connections between FR and AOP and AP.

Beat Liver and Dean Allemang give the following description
of functional representation in the context of software:

>A conceptual component defines roles that other components will
>play, and provides an explanation of how those roles support
>the role it plays, in turn, in another conceptual component.
>Thus components are layered one upon the other, with
>explanation appearing at every level of abstraction.
>Such a combined, multilevel representation of a program
>is called a functional representation.

Beat Liver compares FR with contracts of Helm and Holland
and the contracts of Holland's thesis at Northeastern University
as summarized in his ECOOP '92 paper.

Ref: Beat Liver, Ph.D. thesis, ETH Lausanne,
Title: A functional model of software and its 
application in troubleshooting, design and reuse.
(Introduces ZD (Zweckdarstellung) which is itself derived from
Dean Allemang's FR introduced in Allemang's Ph.D. thesis
at Ohio State under Chandrasekaran.)

Liver summarizes: (page 198 of Liver's thesis)

>Therefore, contracts constitute a functional representation
>which has the following major drawbacks:
>
>...
>Structure and function are not well separated.
>...

Since adaptive programs are a form of contracts, adaptive programs
also constitute a functional representation BUT with
a solution to the function/structure spearation problem.

ZD also claims a solution to the function/structure separation
problem. Beat Liver writes in a paper summarizing his thesis:

> ZD's separation of structure, behavior and function is not
> only desirable, but also practical, and results in reusable, 
> design-level components.

There seems to be set of common goals between Allemang's and Liver's
work and the AP work and its implementation in Demeter.
The solution approaches seem to be different.
The AP work is based on succinct traversal or graph specifications
and the FR work seems to use something different which I cannot
describe concisely at this point. 
But the solution techniques seem complementary so that one can
help the other.

Discussions with Dean Allemang (who fortunately lives now in Boston,
close to Northeastern) have resulted in the observation that
the traversal/visitor style of design/implementation
is used by both FR and AP but better developed on the AP side.
Usage of the AP traversal/visitor style in FR work might help
to advance the state-of-the-art of FR.

Liver and Allemang write in their journal paper on  ZD:
In this paper, we present a framework for maintainable software design,
based on a multilevel understanding of software function.
How can we use this framework (ZD) in Demeter?

Dean Allemang is currently working on the EDCS project FAMILIAR
where he applies the ZD work.