From mira@informatik.uni-siegen.de Mon Nov  2 17:22:09 1998
Received: from aretha.informatik.uni-siegen.de (aretha.informatik.uni-siegen.de [141.99.92.8])
	by amber.ccs.neu.edu (8.9.1a/8.9.1) with ESMTP id RAA08263;
	Mon, 2 Nov 1998 17:22:06 -0500 (EST)
Received: from doors.informatik.uni-siegen.de (doors [141.99.92.1]) by aretha.informatik.uni-siegen.de (Mailhost) with ESMTP id XAA02327; Mon, 2 Nov 1998 23:21:41 +0100 (MET)
Received: (from mira@localhost) by doors.informatik.uni-siegen.de (Mailhost) id XAA04594; Mon, 2 Nov 1998 23:21:37 +0100 (MET)
Message-Id: <199811022221.XAA04594@doors.informatik.uni-siegen.de>
Subject: related work
To: lieber@ccs.neu.edu
Date: Mon, 2 Nov 1998 23:21:37 +0100 (MET)
From: "Mira Mezini" <mira@informatik.uni-siegen.de>
Cc: lorenz@ccs.neu.edu, johan@ccs.neu.edu
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Status: R

Hi all:

I accidentally discovered work that is somehow related to APPCs
and CGVs. The work is about component binary adaption. Its a 
paper by Keller and H"olzle in ecoop '98:

http://www.cs.ucsb.edu/oocsb/papers/ecoop98.html

Below, I am sending my notes about the relation of our 
works. Would ge good if you read the paper and give your
feedback. There is also other work they refer to in the
above paper which might be of interest for us:

by Mätzel Kai-Uwe and Schnorf Peter

http://www.goeast.com/maetzel/abstracts/TR-97-6-1.html

I didn't have time to read this one. Would one of you read it 
and provide feedback? 

Below are my notes on the first paper. Let me know what you think after 
reading the paper.

----------------------- cut here ------------------------------------

1- Commonalities

Both add functionality to existing third parties components.

Example for Adding printing functionality from BCA paper with APPCs:

------------------
APPC Printing {

ICG:
  A = .
  B = .

  A {
    void output(PrintStream);}

  B {void print();}

Behavior {

  interface Printable {void print();}

  A implements Printable {
    public void print() {output(System.out);}   // <=== output (or provided)

    }

  B implements Printable {};


  // Something we haven't considered so far: having APPCs add
  // interface declarations and let entries for the participants
  // declare "implements" relationships. Seems like a useful extension.
  // I have simply used this "non-existing" extension above.
  // B implements a print() method. How can I say that B implements
  // the printable interface, consisting of a single entry,
  // void print();? The purpose of adding "B implements Printable"
  // is to allow clients of the extension to refer uniformly to
  // instances of enhanced As and Bs, e.g. when they are elements
  // of a collection, we want to iterate over and print the
  // elements. Writting "B implements Printable {};" is equivalent to
  // saying the expected method print() in B is the implementation of the
  // interface.

  }// Behavior

}

--------------------


1- Differences:

BCA  == in place change .class files of the base application.

Both our envisaged implementations add intermidiate objects in
between: adapter beans respectively map objects in Johan's approach.

What are the consequences?

(a) - for BCA:

        1- name clashes when more than one adaptation possible.
           Also the extent of an adaptation is constrained by the
           possibility of name clashes.
        2- Dynamic attachment/detachments of adaptations (deltas) to components
           are impossible, since the original component does not exist anymore
           after an adaption.

        3- There is no unit of adaption: an adaption is merely a set of
           deltas, where one delta affects one class.

        4- Adaptions are not generic - they are written for a single component.

        5- No way to apply deltas on deltas vs. refinements of APPCs

        6- No way to merge adaptions together vs. black-box composition of APPcs

        7- We emphasize software development as composition of APPCs.
           BCA emphasizes the minor adaption of existing of existing components,
           more related to Huersch's work on automatic adaptation of systems.
           Our view fits better with the whole development cycle.
           They concentrate more only at the evolution and maintainance phases.

(b) + for BCA

        1- BCA is more efficient than adapter/map objects.

Can we profit from BCA?

We could investigate the following. Keep the application / APPC(View)
separation after the gluing, but maybe avoid adapter/map objects by
binary adaption of the APPCs(Views). This would be a third path
we could follow. Pros and contras you can see with this approach?
We should continue with the two other paths first. there is enough to
do there. I could try to get a student work on the third path in Siegen.