Hi Johan:

you are talking about the interface of an APPC to a class graph.
That interface expresses constraints which the class graph
must satisfy for the APPC to work. Those constraints are of
different forms but a very important kind of constraints are
path existence constraints. Those constraints come from the strategies
used internally by the APPC. Now, instead of putting all those strategies
into the interface of the APPC I propose that we consolidate them
into one strategy (a strategy type).

The reason for the consolidation is that when a specific class graph
is given, we have to personalize the strategies to that class graph.
It is much easier to personalize only once the strategy type
and that will carry over to the strategies used internally.

Strategy graphs have now subclass edges and abstract classes.

How does this justification sound? Maybe it sounds a little strange
the blurring of class graphs and strategy graphs but it makes things
simpler.

-- Karl

From johan@ccs.neu.edu Sun Jun 28 21:00:58 1998
To: Karl Lieberherr <lieber@ccs.neu.edu>
cc: dougo@ccs.neu.edu, johan@ccs.neu.edu, jayantha@ccs.neu.edu,
        mira@ccs.neu.edu
Subject: Re: interface class graph 
From: Johan Ovlinger <johan@ccs.neu.edu>

I think interface class graphs are best described in terms of
classes/intefaces. In short, for the vary same reason why we just
don't use strategies for every thing; both class graphs and
traversals.

In more length, there are two main arguments for this: 

1) The role of a strategy is to talk about the object graph, but 
   the role of the interface graph is to give a different view of the
   class graph. Thus, using strategies as interfaces makes it
   difficult to talk about abstract classes, which are a very
   important aspect of the class graph.

2) Just because we use the same convienent graph notation for
   strategies and class graphs, the interpretation of the two is quite
   different. I think it is obvious that we stick to the same notation
   for describing interface graphs, (in my terminology "module
   interfaces"). The the sematics of the module's interface are much
   closer to that of class graphs than strategies. 

Johan