From mira@ccs.neu.edu Tue Jun 30 19:38:44 1998
Received: from taboor.ccs.neu.edu (mira@taboor.ccs.neu.edu [129.10.116.185])
	by amber.ccs.neu.edu (8.8.6/8.8.6) with ESMTP id TAA15617;
	Tue, 30 Jun 1998 19:38:43 -0400 (EDT)
From: Mira Mezini <mira@ccs.neu.edu>
Received: (from mira@localhost)
	by taboor.ccs.neu.edu (8.8.6/8.8.6) id TAA27826;
	Tue, 30 Jun 1998 19:37:41 -0400 (EDT)
Message-Id: <199806302337.TAA27826@taboor.ccs.neu.edu>
Subject: Re: interface class graph
To: johan@ccs.neu.edu (Johan Ovlinger)
Date: Tue, 30 Jun 1998 19:37:41 -0400 (EDT)
Cc: lieber@ccs.neu.edu (Karl Lieberherr), dougo@ccs.neu.edu (Doug Orleans),
        jayantha@ccs.neu.edu (Joshua C. Marshall)
In-Reply-To: <199806302258.SAA03929@carbon.ccs.neu.edu> from "Johan Ovlinger" at Jun 30, 98 06:58:37 pm
X-Mailer: ELM [version 2.4 PL23beta2]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: R

There seem to be a lot of confusion about what each of us mean and about
how we interpret each other. Let me try to clarify some points by writting
down in terms of our example what 
I mean by using the same notation as for class dictionaries when 
we write the class graph interface of an APPC.

We would have something like:

APPC Pricing()

Class-Graph-Interface:

  // first the assumed structure

  Class-Graph-Structure: <lineItem> LineItemParty
    LineItamParty: <item> ItemParty <pricer> PricerParty <customer> Customer
    ItemParty: <charges> {ChargesParty} //whatever you use for 1-to-many
  
  // then the assumed behavior

  LineItemParty { Integer quantity(); }
  PricerParty {
     float basicPrice(ItemParty item);
     Integer discount(ItemParty item, Integer qty, Customer customer);}
  ChargesParty { float cost(Integer ....);}

Behavior

 //here we use strategies written to the assumed Class-Graph-Structure,
   i.e. stratgy types

  ....


  private float additionalCharges(....) {
    float total = 0;
   
    from lineItem: LineItemParty via item: ItemParty to ChargesParty

    	at (before) ChargesParty {total += cost(...);}

    retuen total;}

   }
 }

}
  

The syntax for aditionalCharges is somehow invented, but it gives the
idea. 

Given this APPC, we can say that it works with a family of class
dictionaries. A cd is in this family if it contains a subgraph
homeomorphic with the interface graph Class-Graph-Structure. 

I believe this fits with Johan's thinking. Is that right?

Can somebody resend this message to me? I forgot to cc it to myself.

- Mira


>   >term "strategy type". I think it is a good idea to write class graph
>   >interfaces in the interface part of an APPC by using a notation like that
>   >of class dictionaries. Thus, the interface part of an APPC contains 
> 
>   Yes. We have come several times to the conclusion that strategy graphs
>   and class dictionaries should be integrated.
>   Strategies probably should talk about syntax so that a strategy graph
>   defines a nice family of class dictionaries and not only a family
>   of class graphs. Let's think about this.
> 
> This is not what I intended. Indeed, I think whilst they can/should
> use the same syntax on a shallow level (but grammars/abstract classes
> for strategies it think is not good), they are quite different and
> should be treated so. Let me start by pointing out the difference in
> languages they induce. The difference in languages arrises from a
> difference in goal; class graphs define the grammar of the object
> graph. Strategies define regexps that match sentences of this
> language. They are connected, but not the same. Thring to make them the
> same (as opposed to looking similar) is bound to confuse the issues
> beyond what mere mortal (or at least swede) can understand
> 
> Johan
>