Hi Dean:

I would like to put our discussion on the Web. Is this ok with you?
The discussion will be of interest to the AOP community.
Of course, please bring in Beat.

>From dta@organon.com Mon Jun 16 11:36:48 1997
>From: Dean T Allemang <dta@organon.com>
>To: lieber@ccs.neu.edu
>Subject: Re: FR and AP
>Status: R
>
>
>Hello Karl,
>
>Thank you for your prompt reply - you must have spent some time
>reading over the weekend.  I have a few comments about your summary.
>I would also be interested to read Beat's comments on this, as well.
>May I forward your message to him, and bring him into the discussion?
>
>
>
>
>> Functional Representation is a subarea of model-based
>> reasoning which is itself a subarea of AI.
>
>While this is roughly how I see the world, many of my colleagues in
>functional reasoning in AI would disagree with this (and for some good
>reasons).  It is probably safer just to think of FR as a small
>subfield in AI.  You can see the FR community's web page at
>http://huckleberry.sfsu.edu/, and notice how the word "modeling" is
>clearly missing.  Some of us have felt the need to tell how our work
>relates to model based reasoning in AI, but others have not.

Thank you for that clarification.

>
>> 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.
>
>
>This is a particularly interesting topic, and one which Beat and I
>have only just begun to address.  In fact, he and I are not yet in
>agreement about just how FR relates to AOP; he had some serious
>disagreements with the paragraph I wrote at the end of the ZD
>tutorial.  I think a discussion along these lines would be very
>profitable.

I noticed that paragraph too. It seems to conflict with what Beat says
in his thesis. He says contracts correspond to devices and you
say devices correspond to aspects? But contracts and aspects are different.
I think I am on Beat's side.

>
>My take on the issue is that an AO description of a program separates
>things in a particular way, which is not apparent in a program written
>in a conventional (i.e., non-AO) way.  A FR does the same thing, in
>that the various "roles" and "explanations" tell how different
>components work together to provide the overall functionality.  The
>different components could well represent different aspects (although
>I get a bit confused on this point, since, in the Demeter example we
>worked on last week, there were three things working together; a
>visitor, a traversal, and an object model.  In the FR that corresponds
>to this, the visitor and the traversal are separated out as two
>functional devices, but the object model is not.  However, if I were
>to make a modeling decision (as Demeter has done) to model this, then
>it would be a third component.  If I understand correctly, these three
>things in Demeter do not correspond to three aspects, but only two;
>the traversal strategy and the visitor are both part of the same
>aspect (core), while the object model is another aspect (structure).
>Am I correct?).

An aspect is a systemic artifact which cross cuts the entire program.
I agree with your analysis above of the two aspects. The structure
aspect influences the resulting object-oriented program at many
different places. It cross cuts the core aspect.
>
>Given this correspondence, in one sense, Demeter is more ambitious
>than ZD, in that it attempts to weave a program based on all these
>aspect descriptions.  As far as I know, however, Demeter makes no
>attempt to ensure that the various descriptions work together to
>provide their function as advertised.  In this sense, ZD is more

You are right, this is lacking. ZD might fill this hole.
But it is not easy since an adaptive program defines a large
family of different object-oriented programs with vastly different
structure.

>ambitious; ZD makes no attempt to generate a program that will
>actually do what the description says, but it will attempt to show
>that the various components (aspects?), once woven together, will be
>correct (with respect to whatever you have chosen to model about
>them).  I see this as a very complementary set of capabilities, and in

Yes, indeed. ZD helps to reason about adaptive programs.

>fact, Beat has mentioned on a number of occasions that having some
>form of generative technology connected to ZD would be a good way to
>achieve the separation of function from code structure that ZD
>requires.  
>

Demeter separates behavior from class structure which is something different
than separation of function from code structure? It would be great if
Demeter can deliver the generative technology which Beat envisioned.

>
>Now, this story is not completely consistent with the story I told you
>during our meeting last week, in which I stressed the non-uniqueness
>of a functional representation.  As a reminder, I outlined how one
>could construct more than one functional breakdown of some system, and
>each breakdown would describe something different about the system.
>For example, one breakdown might show how information is managed to
>avoid particular bottlenecks, while another might show how
>responsibilities are divided to allow the graphics to be used
>separately from the processing.  I suggested last week that these two
>breakdowns could correspond to two different /aspects/.  However, now
>that I have thought the demeter example through a bit more, these
>descriptions do not seem to be different aspects, but rather some
>other distinction.  

Yes, I agree with you: those are not aspects. They are not
cross-cutting and systemic.

>
>In any case, I think that the "concise description" that you are
>missing can be found in my first story, namely, that Demeter is a
>system for supporting programming, and hence has something of a
>code-generation feel to it, while ZD is more a design
>checking/explanation mechanism, which has a more
>diagnostic/verification feel to it.  
>
>
>I see a number of ways that ZD and Demeter could profitably be used
>together.  Consider the total salary example you did last week.
>Demeter allows us to describe the solution in a particular modular way
>(as a vistor, a traversal strategy, and an object diagram), and to
>create a program from it.  Nowhere do you tell the story that this
>visitor, when it visits all the things that this traversal strategy
>says it will visit, will calculate a particular sum that is of
>interest to you (am I correct here?).  And much less, Demeter cannot

Yes, you are correct. This is lacking. Mitch Wand did some work
on invariants for adaptive programs but only for an example.

>make sure that the visitor you have chosen, and the traversal you have
>chosen, actually do compute the sum you think they will.  These are
>the things that ZD does, i.e., ZD allows you to tell a story about how
>the traversal and the visitor will produce the sum that you are
>interested in (and check that it works).  However, ZD will not be able
>to make sure that this story really describes a particular program.
>This brings us full circle, back to the capabilities of Demeter in this
>division of labor.
>
>
>I can see an immediate application of this for design rationale, in
>that if we use a Demeter style development, asisted by ZD, we will
>have a description of what the system is supposed to do (which we can
>manipulate, prove things about, etc.), as well as a guarantee that the
>running system actually fits that description.  This is done without
>going through the traditional process of writing specs and developing
>from them.   I think this is a big win. 
>

Yes, this is indeed a big win. 

>
>> 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?
>
>Of course, I cannot answer this question for you, but I would think
>that the same connection that I described above in the context of
>design rationale capture could be of interest in Demeter; we spoke
>briefly about this last week, when I mentioned that ZD would check the
>consistency of a combination of traversal and visitor.  Perhaps one
>could view ZD as the basis of an Aspect-Oriented debugger, since the

Yes, using ZD as a tool to prove certain properties of adaptive programs
is a very useful thig to do. Can we work out an example?

>debugging strategies in ZD are accustomed to isolating faults in
>different components (which can correspond to "aspects", if the
>discussion above is true).
>
>I hope this message has been helpful.  I am looking forward to working
>with you further. 
>

So do I. There will be some delay because of my upcoming 2 week vacation.

>
>Dean
>

-- Karl