From irini@dworkin.CCS.Northeastern.EDU Thu Feb 27 10:13:40 1992
Return-Path: <irini@dworkin.CCS.Northeastern.EDU>
Received: from dworkin.ccs.northeastern.edu by flora-e0.ccs.northeastern.edu (4.0/SMI-3.2+CCS-main-2.8)
	id AA28430; Thu, 27 Feb 92 10:13:36 EST
Received: by dworkin.ccs.northeastern.edu (4.1/SMI-3.2+CCS-subsidiary-2.2)
	id AA02130; Thu, 27 Feb 92 10:12:40 EST
Date: Thu, 27 Feb 92 10:12:40 EST
From: irini@dworkin.CCS.Northeastern.EDU (irini haralamboulou)
Message-Id: <9202271512.AA02130@dworkin.ccs.northeastern.edu>
To: lieber
Subject: meeting
Status: R

Hi!
Unfortunately I have something else today at 4:00.  What about tommorrow
around 9:00 or 9:30 a.m.?

I send you the current copy of the paper.  It follows.
Irini
********************************************************************


COMPONENTS

A component is an independent self-contained reusable unit of code that performs (defines a finite programming task)
a finite, well defined task.  It consists of:
--A class dictionary that describes the data on which the component functions.
--A list of Propagation Programs which in turn consist of:
  --A Propagation Pattern:  it is the part of the component that performs the
    actual programming task.  It defines all the member functions that will be
    propagated alond the classes of the cd.
  --A list of Propagation Graphs:  these define specific paths on the cd graph
    and name them with acronyms.  They are used by the Propagation pattern for
    more convenience.  Whenever a path is to be traversed several times, we 
    don'tneed to define it each time.  Instead, we use the acronym that repre
    sents it to indicate where a particular interface will be propagated.
  --A list of Derived Edges:  when we need to enhance a class with a new pro
    perty (part) we define derived edges.  A derived edge is a component-dependent
    addittion to a class of a cd.  It encapsulates the graph traversal needed
    to connect the given class with another class of the cd, and represents
    the relationship between them, exactly like the edges of the cd-graph
    represent the part-of/inheritance relationship between the vertices-classes
    of the graph.
Propagation graphs and derived edges are not vital parts of a component.  They
are optional and used mostly for convenience.  Our  experience tells us that
they make propagation patterns much shorter and clearer.

Components can be formally defind by the following cd:
Component =
  <cd> ClassDictionary 
  "*propagation-program*" <propagationProgram> List(PropagationStatement).
PropagationStatement :
  PropagationPattern | PropagationGraphDef | DerivedEdge.
PropagationGraphDef =
  "*subgraph*" 
  <name> PropagationGraphName
  <graph> PPGraph ".".
DerivedEdge =
  "*edge*"
  <source> Vertex "+=" 
  "<" <label> LabelName "(" [<requires> CommaList(Arg)] ")" ">"
  <target> Vertex
  <computesEdge> String. ; (@ @)
PropagationGraphName = <name> Ident.
PropagationPattern = Interface PPGraph Cuts <fragments> List(Fragment).

MAPPING

We have defined formally a cd to be a tuple:
.......................
Alternatively a cd graph can be viewed as a set of objects: the set of all its 
vertices which in essence is the set of all classes they represent.
We define the alternation reachability relationship between two vertices of
a cd graph as follows:
.........................
We have also defined mathematically the following sets:
	SUPERCLASS(v)=....
This is the subset of all the vertices of a cd graph that contains the vertices
that v is alternation reachable from.  In other words, all the classes that
the class represented by v inherits from.
	ASSOCIATED(v) = ....
is the set of all construction vertices of a cd-graph that are alternation
reachable from a given vertex v.
We also introduce the sets:
	PARTS(v)=..........
which are all the parts of either v or its superclasses
And
	PARTCLUSTERS(v) = ...........
which in turn is the st of all the pairs of labels and the associated set of
each part of v.

Mathematical notation is a high level language that allows us express complex
relationships between mathematical objects and define sets that have specific
properties.  This is accomplished simply through reusing a finite st of math 
symbols that express primitive properties and relationships.
Taking a closer look to the definitions above we observe that:
1. The definition of PARTS(v) contains the notion of SUPERCLASS(v) since it
contains the symbol w =>* v.
2. The definition of PARTCLUSTERS(v) has exactly the same form with the definition of PARTS with the only difference that (l, w) has been replaced by (l, A(w))
Demeter specification provides a high level of abstraction and reuse mechanisms.
We would like to study how mathematical definitions of sets of objects can be 
mapped on propagation pattrns that yield the same set of objects.  We would 
like also to see how and whether the similarities observed in the above definitions
appear in the corresponding components.  In order to study that, we are going
to define the following four components:
	SUPERCLASS
	ASSOCIATED
	PARTS
	PARTCLUSTERS
Each of them is going to take a vertex v as an input and build a list of objects
that represents the set of mathematical objects of the corresponding definitions.
According to that we would like to see:
1. The component that yields the set of SUPERCLASS  being reused in the component
 PARTS
2. Component PARTCLUSTERS being similar to the PARTS component.  As far as their
difference is concerned we would like to enhance the list of objects being 
returned, by some entity that will encapsulate in total component ASSOCIATED

PRESENTATION OF EXAMPLES

Component SUPERCLASS collects in a list all the vertices that represent super-
classes of a given vertex v.  We use a graph with two kinds of vertices: A and 
C.  We define the derived edge <imm_supeclasses> that connects every vertex of
the graph with the list of its immediate superclasses.  In order to find all
the superclasses of the given vertex we use this derived edge recursively:
for every one of the immediate superclasses is the list, we find its immediate
superclasses and we do the same for these classes until we reach a vertex with
no superclasses.

*component* SUPERCLASS
Cd_graph = <adjs> List(Adjacency).
   Adjacency =
     < source > Vertex
         < ns > Neighbors
           "." .
   Neighbors :
        C | A.
   A = ":"
     < alternat_ns > Bar_list(Vertex).
   C = "=" List(Vertex).
   Vertex = .
*derived*
Vertex += <imm_superclasses> List (Adjacency)
*requires* (Cd_graph* g);
(@	Adjacency_List* alist = new Adjacency_List();
	g->find_imm_superclasses(alist, this);
	return ( alist);   @)

*interface* void find_imm_superclasses(Adjacency_List* alist, Vertex* v)
*from* Cd_graph
*to* Adjacency
*primary* Adjacency
(@      this->find_imm_superclasses(alist, this, v);  @)

*interface* void find_imm_superclasses(Adjacency_List* alist, Adjacency* adj, Vertex* v)
*from* Adjacency
*to* Vertex_Bar_list
*from* Vertex_Bar_list
*to* Vertex
*primary* Vertex
(@      if (this->g_equal(v))
                alist->append(adj);  @)



*interface* void find_all_superclasses(Vertex_List* vlist, Cd_graph* cd)
*from* Adjacency_List
*through* -> Adjaceny, source, Vertex
*to* Vertex
*primary* Vertex
(@	vlist->append(this);
	Adjacency_List* alist = new Adjacency_List();
	alist = this->get_imm_superclasses();
	alist->find_all_superclasses(vlist, cd);  @)

*end*

We can easily see how this component works.  A call to find_all_superclasses
initiated by a given vertex, and supplied with an empty Vertex_List and the 
graph to be traversed, will be propagated to its immediate superclasses and 
recursively to their immediate superclasses.  Eventualy, the empty Vertex_List 
will be filled with all the superclasses of v.
The list of the immediate superclasses is created by traversing the graph
and by checking for every vertex whether the given vertex v is a member of
their list of A-kind neighbors.

Our second example is component ASSOCIATED.
This finds all the C-kind vertices of a graph that are alternation reachable
from the given vertex v.

*component* ASSOCIATED

  Cd_graph = <adjs> List(Adjacency).
  Adjacency =
    < source > Vertex
        < ns > Neighbors
           "." .
  Neighbors :
       C | A.
  A = ":"
    < alternat_ns > Bar_list(Vertex).
  C = "=" List(Vertex).
  Vertex = .

*derived* Vertex += <find> Adjacency
*requires* (Cd_graph* g);
(@      Adjacency* adj;
        g->find(adj, this);
        return adj;  @)

*interface* void find( Adjacency* adj, Vertex* v)
*from* Cd_graph
*to* Adjacency
*primary* Adjacency
(@      if (v->g_equal(source))
                adj = this;   @)

*interface* void associated( Vertex_List* l, Cd_graph* cd)
*from*  Vertex
*through* -> A alternat_ns, Vertex_Bar_list
*to* Vertex
*primary* Vertex
(@      this->append_if(l, this);
        this->associated(l, cd);  @)

*interface* void append_if(Vertex_List* l, Vertex* v)
*from* Vertex
*through* ->, Vertex, find, Adjacency
*to* C
*primary* C
(@      l->append(v);  @)

*end*
  
Here we use the derived edge <find>.  It conects every Vertex with the Adjace
ncy it belongs to.  We can think of it as a reverse <source> edge.
The call to associated is initiated by a vertex v and is supplied an empty
Vertex_List and the graph to be traversed.  The call is propagated along
the Adjacencies of the graph, collecting in the empty Vertex_List all the
C-kind vertices that are alternation reachable by v.

We present now component PARTS.  This operates on larger cd-graph than the 
two previous components did.  Our task is to collect all the parts of a given
vertex v as well as the parts of its superclasses.  Each part, represented by 
Labeledterm, consists of a Label and a Vertex.  We collect the parts in a 
LabeledTerm_List.

*component* PARTS
*enhance* SUPERCLASS
  *cd-changes*
	A  += <common-parts>List(LabeledTerm)
	C  =  "=" List(LabeledTerm)
	LabeledTerm = <label> Label
		      <term>  Vertex.
	Label = "<"
		<label_name> Ident
		">".
*derived* Vertex += <find> Adjacency

*interface* void trav_for_parts( LabeledTerm_List* lt, Cd_graph* cd)
*primary* Vertex
(@      Vertex_List* l  = new Vertex_List();
        this->find_all_superclasses(l, cd);
        l->find_imm_parts(lt);   @)

*interface* void find_imm_parts(LabeledTerm_List* lt);
*from* Vertex_List
*to* Adjacency       ;here we need the derived edge <find>
*from* Adjacency     ;
*to* LabeledTerm
*primary* LabeledTerm
(@      lt->append(this);  @)

*end*

	Here the call to trav_for_parts, initiated by the given vertex v, 
performs two tasks:  collects all the superclasses of v into a list by a call
to the functionality of component SUPERCLASS.  Then, it goes through this list
to find and collect the immediate parts of all the superclasses.  Note that
according to the definition of the Superclass(v) set, and the form of component
SUPERCLASS, vertex v is a member of the list of superclasses (because v is
a superclass of itself).  therefore, v's parts are also collected.
	
Our last example is component PARTCLUSTERS.  Here, we're going to collect in
a list, entities of Partcluster type.  We can think of a Partcluster as an
enhanced Part entity:  a Part contains a label and a Vertex while a Partcluster
contains the Label and the Associated set of the Vertex.

In this example, our task is different than what we did in all the previous 
ones.  Until now we were writing pps to FIND  sets related to a given
vertex, assuming that these were sets of classes already existing on the
cd this vertex belonged. In this manner we found sets of adjacencies and
sets of vertices.  But a partcluster is not a natural part of the cds
so we have to have a different approach to the problem: we have to construct
the Partclusters out of their parts (Labels and Vertex_Lists) and then collect
them in a list.

*component* PARTCLUSTERS
*reuse* code@ASSOCIATED
*enhance* cd@PARTS
  *cd-changes* 
	*add* PartCluster = <label> Label.
	 		    <assoc-set> List(Vertex).

*interface* void trav_for_partclusters(PartCluster_List* pclist, Cd_graph* cd)
*primary* Vertex
(@      Vertex_List *l = new Vertex_List();
	this->find_all_superclasses(l, cd);
        l->find_imm_partclusters(pclist, cd);  @)

*interface* void find_imm_partclusters(PartCluster_List* pclist, Cd_graph* cd)
*from* Vertex_List
*to* Adjacency
*from* Adjacency
*to* LabeledTerm
*primary* LabeledTerm
(@	PartCluster* pc = new PartCluster();
	Label* l = this->get_label();
	Vertex_List* vlist = new Vertex_List();
	term->tr(vlist, cd);
	pc->set_label(l);
	pc->set_assoc_set(vlist);
	pcl->append(pc);       @)

Component PARTCLUSTERS is using totally component ASSOCIATED.  This was 
expected since Associated set appears as a part of the Partclusters set
definition.  There are also some obvious similarities between component PARTS
and component PARTCLUSTERS. The graph traversal is the same and the interfaces
propagated appear to have some enhancement relationship.  To have a better
view of the relationships between these components let's summarise what
we have observed so far:

SUMMARY OF THE RELATIONSHIPS BETWEEN THE COMPONENTS:

Here we list the elements of the above introduced components: The class dictionary
they operate on, the derived edges they contain and finally the interfaces propa
gated.  We use operator @ to denote the use of an exact copy of one of previously
defined elements.  Operator @@ implies automatic adaptions.  This can happen when
we need to use a previously defined propagation pattern.  The pp is the same, but 
since the cd it operates on is different, the system is probably going to generate 
code for another set of classes.


SUPERCLASS
  cd
  derived
    imm_superclasses
  interfaces
    find_all_superclasses

ASSOCIATED
  cd
    = cd@SUPERCLASS
  derived 
    find
  interfaces
    associated

PARTS
  cd
    extends cd@ASSOCIATED (= cd@SUPERCLASS)
  derived
    find@ASSOCIATED
    imm_superclasses@SUPERCLASS
  interfaces
    find_imm_parts
    trav_for_parts
    find_all_superclasses@SUPERCLASS

PARTCLUSTERS
  cd
    extends cd@PARTS
  derived
    find@ASSOCIATED
    imm_superclasses@SUPERCLASS  {used by find_all_superclasses }
  interfaces
    find_imm_part_clusters enhances find_imm_parts
    trav_for_partclusters enhances trav_for_parts
    find_all_superclasses@SUPERCLASS

@  use a copy
@@ use with "automatic" adaptions

Until now we have used informally the terms "extends" and "enhances" to denote
the similarities that we observed in the above components.  Now we can define
formally these terms:

enhancement for classes:
	required: at least the same reachability relationships
enhancement at code levwl:
	call function for an enhanced class
	add code (before fragment)
	use function on enhanced argument
	add more arguments
NEED: replacement of argument classes with enhanced argument classes

controled editing:

ENHANCE(C1,C2)
ENHANCE(I1,I2)

when a function name is replaced by a new name, the correponding interfaces
must be in an enhancemnt relationship.