Having spent quite a bit of time on trial and error I finally gave up trying to manage with just the GMF modeling tools to get the kind of layout that I want. I typed in a search in Google that I seemed to have done before. I must have overlooked some results because now I found this very helpful post that explained how to add a custom figure to the gallery. I cut and pasted the code and tweaked it a bit and see and behold, it did exactly what I expected (thanks Christian).

Having read the whole thread of the post referred to above, I realize that my woes with the unruly polygons are not unique and maybe somebody in the GMF community is already working on a solution.

Now that this “gate” is passed, I can proceed to the next step: to create a pretty-looking class diagram with Roles, Items (work products etc), and Workflows, just like my meta-model prescribes. And some relationships to boot. And then perhaps some code (HTML) generation before adding the rest of the classes from the meta-model.

This post is admittedly a digression from the original intended kaizen theme of this blog. This thing has fascinated me since my college years though (ever since I read that book Gödel, Escher, Bach, compulsory for all nerds in the 80′s), and still does, so bear with me.

Things referring to themselves can be very useful and have produced some profound insights. I hold Gödel’s proof the #1 intellectual achievement of mankind. Gödel created a language which he used to reason about number theory. The grammar of that language was – number theory. He then went on to create an interesting (true) theorem that said about itself that it wasn’t a (true) theorem. I will not go into further implications of this. Suffices to say that it has far-reaching implications for mathematics.

In a similar way, our brain builds representations of the world, including itself, which is probably what gives us this interesting illusion of a self. It also endows us with a very complicated and sophisticated behavior.

The example of self-reference in this post is illustrated in the diagram to the right. When creating a modeling language, it is necessary to create a model (textual, graphical or some other kind) of the modeling language. This model is known as a “meta-model” or a model of the model. But what is the modeling language for describing the meta-model? What does the meta-meta-model look like? I come to think of a story from Stephen Hawking’s A Brief History of Time:

A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever”, said the old lady. “But it’s turtles all the way down!”

An infinite number of turtles seems wasteful and so does an infinite number of meta-models. We need to stop the regression before it gets out of hand. The standard way of doing that is to create a meta-meta-model that is its own meta-model, i.e. it defines the language of itself. Kind of like a turtle that stands on himself. This idea always makes my head spin a bit so I tried to draw a picture of a really simple meta-meta-model and contemplate on it for a while. As you may see from the names of the “things”, or rather, “ideas”, in the model, it is inspired by the meta-meta-model used in Eclipse, Ecore.

There is quite a lot to say about this simple meta-meta-model:

• It defines by definition – it’s what meta-meta-models do for a living – an abstract syntax, a description of the ideas that we use to create meta-models and meta-meta-models, but it also assumes, or implicitly defines, a concrete syntax, i.e. how we draw representations of those ideas in our diagrams .
• Without any a priori knowledge, we would need to bootstrap the process of understanding the picture with a hypothesis. One such hypothesis could be that the ideas in our meta-meta-model are represented by the yellow boxes and that the names of the ideas can be found in the upper part of the box; the yellow boxes are part of the concrete syntax used to describe the abstract syntax of the meta-meta-model (and the meta-model).
• The test of our hypothesis and the correctness of the model is if we can create a consistent understanding of how the model represents itself. Do we in the model find representations of all the ideas that the model consists of? Do we for instance find a representation of that line with an arrow between two yellow boxes? We could guess that it is represented by a meta-model element called EReference and see if that mapping can be made part of a consistent interpretation.
• We can also deduce that we have an idea called EClass and another idea called EAttribute in our meta-model. These are thus additional building blocks of our meta-model (and our meta-meta-model). The red arrows indicate as far as I can see a consistent hypothesis about the mapping of the ideas in the meta-meta-model onto the element of the concrete syntax of the meta-meta-model and the meta-model.
• Just looking at the diagram we don’t get any clues as to the semantics (meaning) of the parts of the diagram. upperBound for instance could mean pretty much anything. To get something useful, we need to add semantics. To get closer to a semantics we could for instance create a framework in which the elements in our model (described in the meta-model) could correspond to classes in an object oriented language that could be stored and manipulated in a certain way. Without such a visit into the real world, the models would just be meaningless symbols.

I don’t think i will try to explain every single red arrow as I might still get lost in the self-referential maze and end up on the wrong level (meta when meta-meta would be correct and so on) all of a sudden. It seems to me that this picture ultimately still needs to be understood by contemplating on it and by getting an intuitive understanding of the mapping. And that may be better done under a lotus tree than at your desk.

There was no response at the forum so I filed a bug report on the behavior described in previous posts. It took some time to find the right place the file the bug report since the GMF button on the Bugzilla home page doesn’t take you to a place where GMF bugs can be reported. Instead you have to go to Other projects -> More… -> GMP.

The screen-shot to the right shows a simplified view of the issue. The blue and the red rectangles should in my opinion end up at the same location within their respective containing rectangles. The blue rectangle is defined as a Rectangle and the red one as a Polygon of the same size. The layout parameters are exactly the same in both cases (Grid Layout).

Now I’m excited to see if it was a real bug or just a newbie mistake. It seems a bit too obvious and basic to be a real bug but maybe this use case has never been tested.

As I mentioned earlier I realize that I have to learn quite a lot of basics, including what the generated code does, to be able to use the DSL Toolkit. Or to quote the excellent textbook on EMF [2]:

The problem is that high-level modeling languages need to be learned, and because we are going to need to work with (e.g. debug) the generated Java code anyway, we … need to understand the mapping between them.

Sounds just about right.

On the positive side I have to admit that the more I read about Eclipse in general, the more impressed I become. It looks like considerable time has been spent on the architecture of the platform. So there is lot to learn (and precious little time as always).

Links

[1] The models used to reproduce the bug.

[2] Dave Steinberg, Frank Budinsky, Marcelo Paternostro, Ed Merks. EMF Eclipse Modeling Framework.

I then created a GMF project in the Helios release of EMF and imported my models. In this version the red polygon doesn’t show up at all. Everything else seems to work.

A curious thing about unpacking the zip-file containing the DSL is that the native Windows unzip program asks for numerous passwords when unpacking so I canceled the whole operation. I tried 7-Zip instead and it didn’t ask for a single password. Go figure.

An additional frustration right now is that I can’t report a GMF-bug in Bugzilla. It allows me to report bugs on any other project but not GMF. There seems to be something evil going on

Having given up the polygons that wouldn’t center, I tried an SVG file. It’s there as an option in the context menu in the GMFGraph Model Editor. The reference to the actual SVG file isn’t entirely straight-forward: My workspace is at /home/arto/Helios/Source, my SVG file circle.svg resides in /home/arto/Helios/Source/ProcessModel/images which yields the following Document URI for the SVG file: platform:/plugin/ProcessModel/images/circle.svg. I’m sure there is a pattern there.

It turned out that SVG files couldn’t be used unless you added a plug in to both the development environment and the runtime environment. (This goes for both the DSL Toolkit release and the latest Helios release.) This is how it can be done (as far as I can recall):

Back to the classroom.

1. Download and unzip the gmf-sdk-experimental-2.2.0 package (use Google to find it). It contains the org.eclipse.gmf.runtime.lite.svg and the org.eclipse.gmf.runtime.lite plug-ins.
2. Add the plug-in jar-files from the unzipped package to the plug-in directory of the Eclipse installation.
3. Open the Java files that don’t compile and choose the quick fix to add the dependency (hover the cursor over the error message and you’ll see).
4. Add the plugin also into the runtime configuration by selecting Add Required Plug-ins under the Plug-ins tab of the Run Configurations dialog. The missing plug-ins are added to the list under Target Platform.

This was a useful exercise in plug-in management. Unfortunately it didn’t take me anywhere close to my goal. I was able to show an SVG image as a child to a Figure Descriptor but not as a child to an enclosing rectangle which means that I can’t combine it with a label using a layout.

Finally I tried a Polyline but it worked pretty much like a Polygon i.e. it didn’t obey the layout hints either.

The conclusion seems to be that I need to accept a more programmatic (and less “generative”) approach and dig deeper into the mysteries of some of the Eclipse TLAs (Three Letter Acronyms). The process I’m going through is very much like when I embarked on my quest for judder-free video on a PC a few years back (see my other blog). Also in that case I tried some high-level solutions first but ended up with having to spend considerable time to learn how to aggregate COM objects into other COM objects before I could do anything useful. The good thing is it gives the brain a lot of exercise and it is more entertaining than Sudoku.

I will go back to Gronback’s tutorial and give up my own progress for a while, however impatient I am to see my own icons show up there in the diagram. I recall seeing a lot of Java code on the pages ahead of where I thought I had got it all it so I assume the tutorial will eventually take me deeper into the generated code and hopefully give some hints as to how to tweak it.

Links

[1] GMF Forum

[2] How to install Eclipse plug-ins

/**
* @generated NOT
*/
private boolean myUseLocalCoordinates = true;

It kind of worked in the sense that now at least the body of the icon (defined as a polygon) ends up within the enclosing rectangle and can therefore be moved around on the canvas. It still doesn’t obey the same CENTER parameter that makes the ellipse center inside the rectangle. Now the forum is up so it’s time for that first n00b question. I also realize that GMF will be very hard to use without understanding the generated code.

I don’t easily give up so I went back to GMF the tutorial to try it once more, now that I’ve played around a bit more with figure definition. Reading the section “Graphical Definition”, I notice to start with that the code snippet and the GMFGraph Model Editor screen-shot to the right aren’t consistent. The code uses Flow Layout whereas the screen-shot indicates XY Layout. I copied the code into my project and got the thing to the right. The body of the icon always stays in the upper left corner of the canvas. Only the head follows the actual element when it is moved around. This looks like a variant of the behavior I described in my previous post: the polygon doesn’t obey the layout.

I also tried XY Layout but got a similar behavior (but not exactly the same). I would have expected to have been able to define the XY coordinates of the figure parts (head and body) using XY Layout Data but it doesn’t have any attributes in my version of the DSL Toolkit. If I still add an XY Layout Data child (with no attributes) to both the head (ellipse) and the body (polygon) of the icon, then the head disappears from the icon and the body still lingers in the upper left corner of the canvas.

I will post a question in the Modeling forum before I post a bug report although this looks very much like a bug or several bugs (at least in the tutorial). The forums are still down though so I document what I learn here on my blog in the mean time and perhaps start reading the basic EMF book that has now arrived to understand more of the history and the basic philosophy of Eclipse. My risk-based approach to start using the GMF has now come to it’s first “gate” that I will not pass before I can define a good-looking icon with a centered label below it (for more on the “risk-based approach”, see this post.)

Links

[1] GMF Tutorial Part 3

The layout of the rectangle defined as a Rectangle (blue) in the screen-shots below is as I would expect in both Flow Layout and Grid Layout. The same goes for the ellipse. The layout algorithm seems to make space for the the other rectangle which is defined as a Polygon (red) below the (“native”) rectangle but then throws the polygon up into the upper left corner.

Similarly the positioning of the element label isn’t in my opinion consistent. With Grid Layout the label ends up centered where I want it to, and expect it to. With Flow Layout it isn’t centered. In summary, only two out of four figures end up where I would expect them to when I use the Flow Layout.

Another thing that somewhat bothers me is the vertical space between the geometrics figures in Grid Layout. I can’t see that I have defined such a space anywhere in my .gmfgraph file.

As soon as the Eclipse forum is on line again, I’ll post a question. I guess that sooner or later I need to delve into the generated Java code to really understand what’s happening…

Flow layout definition.	Grid layout definition.
Resulting flow layout.	Resulting grid layout.

The first goal with my DSL Toolkit experiments is to create an “operations manual generator”, a bit like EPF (see this post), but using my own favorite meta-model (see this page).

It could be argued that I lack imagination as I have already created a couple of such generators before, one based on Rational Rose and one based on StarUML. (In both cases I used UML stereotypes for defining the meta-model.) Unfortunately both these solutions have serious drawbacks: Rational Rose is forbiddingly expensive (or at least was at the time) and StarUML is a dead open source project despite its very impressive qualities. Eclipse and the DSL Toolkit don’t seem to have those two particular drawbacks but I’m sure I’ll run into other road-blocks why I’m doing this in a risk-based fashion.

I believe that intuitive graphics, particularly good looking modeling element icons and a diagram editor that works as expected (no random reordering of elements, no rounding errors when snapping to grid, rectilinear lines behaving well etc), are important to make a domain specific language attractive to use. I have therefore spent several hours to explore the layout options in the gmfgraph model. I wish to eventually use my own icons with icon (class) labels centered below the icon. It took me quite some time to actually manage to center the label. There might be more than one way of doing it but only way that worked for me was the Grid Layout with default Grid Layout Data for the child element.

I still don’t have the full mental model of the modeling elements (e.g. the Child Access) in the diagram definition models so I guess I’ll spend a few more rainy hours making small adjustments and generating new diagram code. Fortunately I have a pretty fast computer.

I have waded through numerous tutorials on the Internet (links to those that I found most useful can be found below). I used the reference section of the DSL Toolkit book to understand the layout options (the reference part is actually pretty good).

GMF Tutorials

[1] A very basic tutorial that creates a class diagram editor using the wizards. The created solution is a good starting point for further experiments though.

[2] A basic tutorial with some hints as to how to change to look of elements in the diagram etc.

[3] A tutorial that covers more than just the basic diagram with a few classes-as-rectangles and associations.

[4] The official Eclipse GMF tutorial. Unfortunately, it seems a bit outdated. The Taipan example can for instance not be found at the indicated location.

When I try to understand a new domain, I build mental models of the domain, very much like we build Ecore models of the domains we try to model with our domain specific languages. (Peter Senge has a wonderful account of mental models in his book The Fifth Discipline.) The mental models are of course not as formal as the Ecore models and maybe not even consciously known but are nevertheless there in the synapses somewhere.

Quite often I get a sense of that something in my mental model is wrong but it is only much later that I can pin down exactly what it is. Finally finding out is one of the joys in life.

I could not at first create a consistent mental model of how the different models of the Graphical Modeling Framework used to create graphical editors related to each other. One of the aspects that I look for in my mental models is “orthogonality” (independence) between different concepts. When working through the wizards that created the various models needed to define the graphical editor for the mindmap example I got the feeling that things were not “orthogonal” which broke my mental model of the graphical editor definition process.

The mental tension was relieved when I realized that one of the wizards (see figure) didn’t really record all of the information that was available in the wizard dialog; even if it could have established a first mapping between the domain elements of the Ecore model and the graphical elements of the diagram, it didn’t. It established a set of graphical elements that were only later (in the Mapping Model) connected to the Ecore (domain) elements. It would here have been helpful if the tutorial had been clear about what information was extracted from the wizard and what information was discarded. So it goes.