From lieber@ccs.neu.edu Thu May  7 11:36:14 1998
Received: from stockberg.ccs.neu.edu (lieber@stockberg.ccs.neu.edu [129.10.112.123])
	by amber.ccs.neu.edu (8.8.6/8.8.6) with ESMTP id LAA22613;
	Thu, 7 May 1998 11:36:13 -0400 (EDT)
From: Karl Lieberherr <lieber@ccs.neu.edu>
Received: (from lieber@localhost)
	by stockberg.ccs.neu.edu (8.8.6/8.8.6) id LAA27754;
	Thu, 7 May 1998 11:36:12 -0400 (EDT)
Date: Thu, 7 May 1998 11:36:12 -0400 (EDT)
Message-Id: <199805071536.LAA27754@stockberg.ccs.neu.edu>
To: lieber@ccs.neu.edu, mira@ccs.neu.edu
Subject: Re:  thoughts on APPCs
Status: R

Hi Mira:

>From mira@ccs.neu.edu Thu May  7 11:11:36 1998
>Subject: thoughts on APPCs
>To: lieber@ccs.neu.edu (Karl Lieberherr)
>Date: Thu, 7 May 1998 11:11:34 -0400 (EDT)
>Cc: mira@ccs.neu.edu (Mira Mezini)
>
>Hi Karl:
>
>a fw thoughts that crossed my mond yesterday with regard to APPCs:
>
>1- Calling APPCs "Plug and Play" is (maybe) wrong at least for what they
>are at this moment. I think people use the "plug-and-play" attribute more
>for the so-called black-box components, i.e. those that are connected by
>use relationships with each other. The idea is how to put components
>together that use the functionality of each other without coupling them
>too much to each other. 
>
>On the other hand, so far we have been concerned only with "refinment"
>relationships between components. Corresponding concepts (to our
>composition of APPCs) in the oO designe world is the extends relationship
>between use cases. While plug and play would stay for flexible
>establishment of use relationships between use cases. 
>I see an APPC as a generic specification of the main system operation of
>one use case. In a oreder system (including the pricing example), we could
>e.g. have other use cases. The main one is called "Order Items". Another
>use case would "Payment" and surely "Pricing". "Order Items" uses both
>"Pricing" and "Payment". On the other side there might be two different
>payment schemes, "Cash" and "Authorized". "Authorized" can be further
>refined in "Check Payment" and "Credit Payment". The relationships between
>"Payment" and "Cash"/"Authorized" as well as between "Authorized" and
>"Check Payment"/"Credit Payment" are "extends" relationships. This is what
>we have considered so far. This needs to be cleaned up. But, in addition
>we need to consider connecting collaborating APPCs together, e.g. 
>"Order Items" with "Pricing". Here we need to make them plug and play in
>the sense of the hardware world. 
>
>I will draw a use case diagram for the scenario described above and send
>it to you. 
>

>I see an APPC as a generic specification of the main system operation of
>one use case.

That is very interesting. Will be very good for the paper.

I think we will keep the name "plyg-and-play"?

>
>2- We should have considered sending a simplified version to:
>
>>
>>               13th IEEE International Conference on
>>
>>               Automated Software Engineering - ASE'98
>>
>>
>>               October 13-16, 1998, Honolulu, Hawaii, USA
>>                       (co-located with WCRE'98)
>>
>
>maybe with the pricing example only and a simple variation of the pricing
>APPC ... But, it seems like it is too late now, at least for the abstract:
>
>>Paper Submission: May 8, 1998 (email abstracts by May 1, 1998)
>
>Well, ... some forthcomming conference on generative programming around???

We will look for one. I am sure we will get this into some good conference.
Related simultaneous submissions are a little tricky.

>
>3- In the last slide of your talk about APPCs yesterday, you have an item:
>
>"We build on Mixin-Layers ..."
>
>I don't think this is very accurate. While the approaches have
>similarities, we haven't build on their work. Rather, we have come up
>independently with ideas that overlap somehow. I started talking about
>next() calls in visitors and making visitors more mixin like already in
>November (or maybe earlier?). By that time, I had no idea about their
>forthcomming paper. It's not so important, but I also don't see why the
>item should be there.
>

Ok, I will change that to: We independently ...
I think it is useful to connect to related work. There is still
plenty of a difference between the two.

>
>Long mail ... Suggestions ... ?
>
>- Mira
> 
>

-- Karl