From: dsouza@fraser.sfu.ca (Keith D'Souza)
Subject: Help needed-  OO methodology
Organization: Simon Fraser University, Burnaby, B.C., Canada
Distribution: World
Date: Sun, 6 Sep 1992 19:38:01 GMT

Hi !

I am assisting with some research in the area of graph-grammars.  I am 
currently trying to move most of the existing code (written in PROLOG) to 
an object oriented version (PROLOG++).  In doing so I am faced with 
some fundamental questions relating to objects/instances.  I would 
appreciate comments on possible approaches to the problem.  I have 
explained, briefly,  the scope of my problem below.

The system  deals with attributed graphs.  Thus, there exists:

- A problem graph which the user constructs
- A production graph which represents a syntax directed edit operation, 
which operate on the basis of sub-graph isomorphism.
- A program graph which simply specifies connections between production 
graphs.

Each graph consists of nodes and edges.  Node and edge types are common 
for the problem graphs and the production graphs.

For example,the user can model a simple transportation problem involving
sources and sinks.  Thus, there exist node types sources and sinks 
which the user can add or delete from the problem.  The system allows for 
more complicated edit operations than, simply, adding or deleting a source 
or sink.  For example if this was a multi timeperiod problem, deleting a sink 
would involve deleting all sink nodes for every time period relating to the 
offending sink.  This edit operation is represented in a production graph 
which is then applied to the problem graph.  Hence, the node and edge type 
in these graphs are the same.

Not so the nodes and edges for the program graph.  Here, the nodes and 
edges are more generic and simply represent the ordering of the productions 
to be executed.  We will ignore them for now.


- Each node/edge has attributes, bindings and a label.
Thus, a sink node will have a demand attribute and a name attribute.
Bindings for the node will include shape, color etc.

Each attribute/binding is composed of a value, a defining function and a few 
other flags which provide specific instructions to the system.


My initial ideas on this problem are as follows:

Construct parent objects graph, node, edge, attribute, binding, nodelist, 
edgelist, attributelist, bindinglist.
The user can then create a new node type object, say customer, as a child of 
node.
The user also creates a new attribute object, say demand, as a child of 
attribute.
Each node has an attribute alist which points to an instance of the object 
attributelist.  This attributelist points, in turn, to the instances of the various 
attribute objects associated with that node type.

Similarly for bindings and for edges.

Now, in creating a new problem graph, the user is allowed to create a new 
instance of graph.  Simultaneously, a new instance of nodelist and edgelist 
is created.  The nlist and elist attributes of the new graph point to these new 
instances of objects nodelist and edgelist.  

When the user adds a customer node to the new graph, an instance of the 
customer node is created and a pointer is created from the nodelist of the 
new graph to this new instance of customer.

In addition, a new instance for each attribute object associated with that 
nodetype needs to be created, and pointers setup to link these attribute 
instances to the attributelist for that particular node instance.

In other words, a graph instance will have, associated with itself, a nodelist 
instance, an edgelist instance, node instances, edge instances.  Each node 
instance will have associated with itself, an attributelist instance, a 
bindinglist instance, attribute instances and binding instances.


Comments on this line of thought would be appreciated (especially critical 
assessment and potential pitfalls).  Also any improvements/suggestions.  
Please e-mail all replies to dsouza@sfu.ca

Thanx!

Keith
dsouza@sfu.ca
Newsgroups: comp.object