Ned,

I will read the thesis as I get time.  It sounds interesting.  I am on  
my 5th such project, and can relate to your issues.  There are really 2  
types of diagrams to deal with.  Those that are true projections of a  
core model, and those that are a filtered/user constructed reflection  
of a core model.  The first is pretty easy to deal with, because there  
is some defined mapping from the core model to the desired diagram  
model.  This mapping may be complex or simple depending on the needs of  
the project.  The second requires that the two structures be maintained  
persistently, and kept consistent while not being equal.  As you point  
out having hierarchical graphs that can show the same core elements  
with different filtering or user controlled visibility is another  
complication.

In one project we have 3 layers of objects: model, diagram, drawing.   
The model level has the core elements that reflect the language (UML  
Metamodel in this case).  The diagram level retains a persistent  
representation of the user's choices for filtering/visibility.  The  
drawing layer is as you say dumb and just represents shapes and styles.  
  In our case the user can create diagram types, specify mapping from  
the core model to the diagram layer, and reference drawing layer  
elements for styling of the output.  Each diagram type can have  
multiple styles (like themes or skins) that can be applied as a whole,  
or the user can selectively modify appearance of individual nodes/arcs.  
  We have tried this with both smart drawing and dumb diagram, and the  
reverse.  Having a dumb drawing layer and a smart diagram layer is far  
more effective.  Then comes Morphic with far more user manipulation  
supported than the typical structured diagram system.  With the  
influence of Morphic I would want to make things less rigid.

The UML language started out as only a core model and a defined  
projection to a notation.  This has proven inadequate.  Now there is a  
standard for how to exchange the actual diagrams, not just the  
underlying core model.  The diagram interchange spec is worth looking  
at, but it does not really address the issues you bring up.  The spec  
only talks about the static representation of diagrams, not the dynamic  
relationship between diagrams, parts of diagrams, and the core model.

I would like to be able to associate a visual node with a core model  
element.  Then I would like to be able to expand visual connections  
conforming to the core model associations of my choice.  I would not  
want to have to define for some diagram type what associations are  
available, if that meant that only those could be presented.  In some  
cases you might want to be more rigid, but other times not.  The idea  
of a single "diagram context" that defines the mapping from the core  
model to the visible morphs would be too restrictive, or degenerate to  
a single context.  I would like to see multiple contexts active over  
different parts of the graph.  For example the mapping for the interior  
of a submachine state in UML is different depending on whether it is  
expanded or collapsed.  In the expanded case you show the entire nested  
state machine (which can be in a stand-alone diagram elsewhere).  In  
the collapsed case you show only those nodes of the nested state  
machine that are targets of transitions from the referencing state  
machine, and the visual presentation of those nodes is different.  So I  
would like to be able to attach a context to any set of shapes on a  
diagram.  This may typically be all children of a node, but it could  
also be a set of peer nodes.

Allowing end-users define the mapping and styling of the diagram  
presentation is very powerful, and requires a very well thought-out  
interface.  I would like to dialog on this, as my new project will need  
it, and I have some experience that may help in designing it.

Michael



On Dec 23, 2004, at 11:47 AM, Ned Konz wrote:

> On Thursday 23 December 2004 10:51 am, Michael Latta wrote:
>
>> Looking through the connectors GraphModel classes I have several
>> questions:
>>
>> 1) Are these classes meant to hold application data, or are they
>> "models" for the connectors morphs?
>
> Sigh...
>
> My intention was to give an easy way for end-users or programmers to  
> attach
> models to the connectors and to other morphs used as nodes in graphs  
> using
> connectors.
>
> Previously, there was no easy or standard way to associate a model  
> item with a
> connector, so you couldn't have a particular model item viewed by  
> multiple
> connectors. And you couldn't separate the model from the views.
>
> So I figured that what I needed was to have a separate concept of graph
> models. I wrote a set of graph model and context classes that were  
> extensible
> using a property dictionary. And I made several pluggable or  
> subclassable
> kinds of iterator with different iteration policies. You can look at  
> this
> work at my MC repository mirror at
> http://bike-nomad.com/squeak/monticello/Connectors  
> (ConnectorsGraphModel,
> ConnectorsGraphIterators).
>
> But then what got me was the hierarchical graphs. I realized that if I  
> had
> more than one idea of how to use hierarchical graphs, probably other  
> people
> did as well.
>
> The problem comes with the relationship between the different  
> sub-graphs of a
> hierarchical graph, and between differing views of the same entities in
> different graphs.
>
> For instance, in some cases (like, say, making a visual language that  
> allows
> you to expand nodes into other graphs) you want to summarize  
> connections into
> a single connector in the top-level graph. Sometimes you don't.
>
> Similarly for (say) pins in such a language: they would be viewed in  
> two
> different contexts: the graph in which the symbol was used (where  
> they'd be
> connected to from outside) and the graph in which the symbol was  
> defined
> (where they'd connect to the guts of the symbol).
>
> In other cases, you might want to summarize or otherwise fold nodes or  
> edges
> or some combination into other nodes or edges; in some cases you'd  
> want to
> hide them, etc.
>
> If you look at how different software handles hierarchical graph  
> you'll see
> many different ideas. I wrote this to the list earlier:
>
> --
> Short answer: I am in the midst of re-thinking the graph model stuff.  
> I would
> recommend that you postpone using it for a bit, as I will probably rip  
> it out
> soon and replace it with something quite different.
>
> A longer answer (and one that might bear some reflection on the list):
>
> The graph model support that I added is the part of Connectors that  
> I'm least
> happy with. It turns out that the way I did it (even if copying weren't
> broken) gets in the way of sharing graph model items between graphs,  
> and also
> imposes a particular set of decisions as to hierarchical graph  
> structuring
> and policy.
>
> In particular, there is the problem of allowing a particular domain  
> model
> object to have different connectivity in different contexts. And there  
> is
> also the distinction between a Morph and its domain model: original  
> Morphic
> thought would have them be the same thing in many cases, but a lot of  
> the
> time you want to look at Morphs as views (hence my separation of graph  
> model
> items from Morphs).
>
> However, this means that things work differently in Worlds with and  
> without
> graph contexts; in the ones *with* graph contexts, there is a separate
> structure that represents the "real" graph. Unless this (possibly  
> invisible)
> structure is maintained in a way that coincides with the user's needs,  
> it
> will get in the way. An example of this is my desire to have a generic  
> graph
> iterator morph for Etoys. I'd like such a thing to work in a world  
> where the
> entire graph model is implicit in the morphs themselves (i.e. what you  
> see is
> all you get). But I'd also like to be able to use EToys as an extension
> language for certain kinds of operations on Connectors drawings that  
> have a
> deeper model.
>
> I am in the middle of reading Giorgio Busatto's 2002 PhD thesis paper,
> entitled "An Abstract Model of Hierarchical Graphs and Hierarchical  
> Graph
> Transformation"  
> (http://theoretica.informatik.uni-oldenburg.de/~giorgio/papers/ 
> thesis.ps.gz ,
> 672Kb ).
>
> It is quite interesting and probably should be required reading for  
> anyone
> interested in hierarchical graphs of any kind. It is also quite  
> readable for
> someone like me who doesn't have a math or computer science degree  
> (though
> some familiarity with the concepts and notation of set theory is  
> helpful),
> and appears to be obviously useful, neither of which I can say about  
> all the
> graph theory papers that I've read.
>
> He argues (convincingly, I think) that because one might want to do a  
> number
> of graph transformations and/or apply various policies to how  
> hierarchical
> graphs are constructed, it is a bad idea to make excessively clever  
> graph
> elements (nodes and edges). In fact, his model views the connection
> relationship between graph elements as an attribute of the graph  
> itself,
> going so far as to move the knowledge of connectivity from the edges
> themselves into the graphs (more specifically, into the graph skeleton  
> and
> its packages).
>
> I think this view would work better in the general case, as it avoids  
> having a
> dual structure that must be maintained separately in the case of the
> Connectors themselves.
>
> Changes to the connectivity of a Connector are the user's assertions  
> and
> desires about changes to the visible part of the graph itself.  
> However, the
> morphs in the current world or other container may themselves only be a
> reflection of part of a larger graph.
>
> By making the graph package (Busatto's term for a particular subset of  
> the
> nodes and edges of the entire graph, itself part of the "hierarchy  
> graph")
> separate and responsible for reflection on connectivity, a number of  
> the
> problems are eliminated.
>
> So questions about connectivity are always delegated to a graph  
> package (what
> I called a "graph context"). This lets us have the same graph element  
> (nodes
> or edges) shared, with some elements visible in some contexts and not  
> others.
>
> Among the things that need to be made possible to make this end-user  
> friendly
> are:
>
> - specify graph types and policy without having to be a programmer
> - create graphical shapes representing specific graph elements (that  
> is, how
> best to present a focused view of the available graph elements for  
> assocation
> with the current package)
> - use pluggable transformers and iterators to define operations and  
> policy
> - see the distinction between the view(s) of the graph and the  
> internal model
> of the graph (that is, how to make the distinction between (say)  
> deleting the
> last view of an edge and deleting the edge itself).
>
> I'm interested in ideas for how this could be made useful and powerful  
> from a
> programmer as well as an end-user point of view.
>
> --
>
>> 2) Can you elaborate on the serialization functions in Connectors?  I
>> see a hook for when an NCGraphElementModel is loaded from disk into a
>> project (named class missing).
>
> These use the standard Squeak serialization support. What I did in  
> Connectors
> 1.9 was to serialize all the graph elements as a single array. Again,  
> I ran
> into problems with multiple graphs and since I was trying to support
> Squeakland first, the menu items for serialization (and hence the  
> support for
> it) were left out.
>
>> 3) I do not see evidence of a read/write method.  Are they inherited,
>> missing, a work in progress, or a planned future feature?
>
> As I said, the read/write is handled by the usual Squeak means
> (SmartRefStream).
>
> Thanks for your interest,
> -- 
> Ned Konz
> http://bike-nomad.com/squeak/
>