From NERAY@us.oracle.com Thu Jun 11 16:18:38 1998
Received: from inet16.us.oracle.com (inet16.us.oracle.com [192.86.155.100])
	by amber.ccs.neu.edu (8.8.6/8.8.6) with ESMTP id QAA16716
	for <lieber@ccs.neu.edu>; Thu, 11 Jun 1998 16:18:36 -0400 (EDT)
Received: from mailsun2.us.oracle.com (mailsun2.us.oracle.com [144.25.88.74])
	by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id NAA21252
	for <lieber@ccs.neu.edu>; Thu, 11 Jun 1998 13:18:35 -0700 (PDT)
Received:  by mailsun2.us.oracle.com (SMI-8.6/37.8)
	id NAA07036; Thu, 11 Jun 1998 13:18:33 -0700
Message-Id: <199806112018.NAA07036@mailsun2.us.oracle.com>
Date: 11 Jun 98 12:08:32 -0700
From: "Neeraj Ray" <NERAY@us.oracle.com>
To: lieber@ccs.neu.edu
Subject: Expressing Patterns as APPCs
MIME-Version: 1.0
X-Mailer: Oracle InterOffice (version 4.1.1.3.40)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Status: R

Hi Karl,

Following is the work I did for expressing patterns as APPCs.
This is based on my understanding from your paper and presentation.  
It is still pretty rough.  See if it makes any sense.  
I can give you further explaination in the evening.

- Neeraj


// the input to the APPC would be the Interfaces, and it would generate
// the proper collaborations and behavior using strategies and visitors
APPC ObserverAPPC(){

  Interfaces->
	Subject(1..1){
	}
	ConcreteSubject extends Subject(1..1){
	  getState();
	}
	Observer(0..1){
	}
	CocreteObserver extends Observer(0..*){
	}

  Collaborations->
     observers = from subject:Subject to (0..*) observers:Observer;
	 subject = from concreteObserver:ConcreteObserver to
concreteSubject:ConcreteSubject;

  Behavior->
     Subject{
	   attach(observer:Observer){
	     observers.add(observer);
	   }
	   detach(observer:Observer){
	     observers.remove(observer);
	   }
	   notify(){
	     during observers{ 
		   update();
		 }
	   }
	 }
	 ConcreteObserver{
	   update(){
	     subject.getState();
     }
}

// extend Observer where an observer cn have multiple Subjects
APPC MultipleSubjectObserverAPPC extends ObserverAPPC(){
  Interfaces->
	modify ConcreteSubject extends Subject(1..*){
	  getState();
	}

  Collaborations:
	delete subject;

  Behavior:
     Subject{
	   modify notify{
	     during observers{ 
		   update(this);
		 }
	   }
	 }
     ConcreteObserver{
	   modify update(subject:Subject){
	     subject.getState();
     } 

}



Input(for Java):
Interfaces.
Subject, Observer, ConcreteSubject and ConcreteObservers are  examples of 
APPCInterfaces.
Java interfaces or classes should satisfy the Interfaces methods 
(with exact signature).
Leaf APPCInterfaces have to be classes.  Others can be interfaces or
classes.
In the case above, Observer and Subject can be an interface, others 
have to be classes.

Output(for Java):
Collaborations and Behavior as specified in the APPC in the form of java 
interfaces, classes and methods.

Keywords introduced in APPC and explaination:
Interfaces - input to APPC.  
(n..m) - number of instances of that class allowed. Default is (1..1).
this - to specify an instance of the obejct.
extends - extend an interface or an APPC.
add - in case of aggregates(e.g. "observers").
remove - same as above.

The following can only be used in an extend(ed) APPC 
(e.g. MultipleSubjectObserverAPPC):
modify
delete


General Comments:
Similarity between APPC and Design Patterns:
- reusing  slice of behavior within different contexts.
So in a sense any kind of APPC is a pattern, and any kind of pattern can be 
expessed n an APPC.

What is more in APPC?
- a language to specify this slice of behavior.
- use of Strategies to specify collaborations.
- automatic optimal generations of collaboratins and behavior,
which may use Visitors.
- composing APPCs.

APPCs are very useful to express collabortions.
Design Patterns(from GoF) do not have lot of collborations and behavior
associated to them, and hence most of them are not a good candidate for
APPCs.
Following are the design patterns I found which are useful candidate for
APPCs:
Observer, Command, Momeneto, Builder, Visitor, Iterator?.
These patterns can also take advantage of "extend"ing APPCs with various
different implementations issues, as shown above with ObserverAPPC and
MultipleSubjectObserverAPPC.
Perhaps Composites [by Vlissiides] or Ananlysis Patterns [by Martin Fowler] 
are better candidates for APPCs, as they may express more collaborations.

Other Issues:
- extending it with various domains.(getState() can get  return value);
APPCs may be more useful for a specific domain. 
(e.g.  Observer within a GUI environment vs. a distributed environment)
- methods with no return value (as getState())
- code generated for methods may be just a place holder.
- aggregations vs. other associations.  How do we express them in APPCs.


APPC BuilderAPPC(){

  Interfaces->
	Director(1..1){
	}
	Builder(0..1){
	  buildPart();
	}
	ConcreteBuilder extends Builder(0..*){
	}  


  Collaborations->
     builder = from director:Director to (0..*) builders:Builder

  Behavior->
    Director{
	  void construct{
	    during builders{
		  buildPart();
		}
	  }
	}
}

Problem:
- there can be many buildPart() methods, as buildPartA(), buildPartB()...
How do we abstract that?  Using it in a certain domain may help.