diagram layout out of textual representation

How to cook your own DSL language. That’s what most DSL tool suppliers want you to do right away, don't they? I say: no problem, but please notice there’s already a plethora of languages (and their notations) that you could leverage, gain experience from, and then move on to design your own brainchild. Examples follow.

Consider statecharts. Diagrams are nice to browse, but hard to edit. Let’s say we have an IDE for a textual notation of statecharts. I like this comparison [1]:


Which is faster?

textual Environment:
1 move cursor to position
2 type “|| await C”

graphical Environment:
1 make room: shift neighbor states, enlarge parent state
2 click on “add state”
3 move mouse to location and place new state
4 click on “add state”
5 move mouse to location and place new state
6 double click on new state, toggle terminal field
7 click on “initial state”
8 move mouse to location and place new initial state
9 click on “transition”
10 move mouse to location of initial state
11 press left mouse button and keep pressed until reaching state
12 click on “transition”
13 move mouse to location of state
14 press left mouse button and keep pressed until reaching terminal
state
15 double click on transition
16 write “C” in trigger field
17 press “OK”
18 click on “delimiter line”
19 move mouse to location and place delimiter line


The underlying argument is that having a true DSL infrastructure, including access to the Abstract Syntax Tree (AST) of the doc being edited, gives you a lot of mileage, e.g. enabling the suggested use (auto-layout).

There's more related work, of course (the idea cannot be new), but I don't see it being mentioned often enough in DSL tooling circles. Diomidis Spinellis has a nice prototype to layout UML class diagrams from Java source, to achieve things like:

given the following input:

// Author:  Vadim Nasardinov
// Version: $Id: ceg-mv.xml,v 1.1 2005/11/23 22:21:22 dds Exp $

import java.util.List;
import java.util.Map;

/**

 * @assoc "1..1" - "0..n" Adapter
 * @assoc "" - "0..n" ObjectType

 * @assoc "" - "0..n" ObjectMap
 * @assoc "" - "0..n" Table
 * @assoc "" - "0..n" DataOperation

 **/
class Root {
  private Map m_adapters;
  private List m_types;
  private List m_maps;
  private List m_tables;
  private List m_ops;

  public Adapter getAdapter(Class klass) {}
}


class Adapter {
  public Root getRoot();
}

abstract class Element {
  Root getRoot() {}
}

class ObjectType extends Element {}


/**
 * @has "1..1" - "1..1" ObjectType
 **/
class ObjectMap extends Element {
  private ObjectType m_type;
}


class Table extends Element {}

class DataOperation extends Element {}

Notice that it's possible to generate different diagram views from the same source description.

Actually, all this detour into diagrams actually aims at reinforcing the view that language engineering (by means of metamodeling, with well-formedness and type-checking conditions specified in OCL) is a good thing, that also comes to benefit in case you're all for diagrams. But I won't peruse any further this visual path, for that you can check two generators of diagram editors:

1. the Eclipse Graphical Modeling Framework
   
2. the Tiger Project at Tech Univ Berlin (Germany)
   

Have fun (and please come back to this textual DSLs blog soon :)

References:

[1] The Kiel Statechart Layouter