Whenever I mention that I am working on a compiler for executable UML, most programmers I know immediately respond with an expression of their distaste of UML. I understand, I used to feel the same way. So how can we make UML, or at least executable UML more palatable for the average developer?

Many developers seem to view UML as a terrible burden, that their managers subject them to. The problem I think developers have with it is that it forces them to replicate their code in a different form, just to appease their managers.

Reverse engineering tools if available lessen the burden somewhat, they only go half the distance: you usually end up having to  

The problem I have with UML is that tools are visual. This means that when constructing a model, you have to choose a two-dimensional location for everything, and make sure that it makes sense. Not only that you have to use your mouse, and click on things, and constructing the model becomes slow and tedious. Most free UML tools are horribly horribly broken (ArgoUML, I am looking at you)

When programming in a textual language, things are much easier: I just have to worry about the linear sequence of things, and indentation. Most editing tools make indentation a non-issue, and even if I screw up the linear sequence, the code is still readable. This is unlike a two-dimensional model, where sufficienly poor placement of boxes and lines can render a model completely unreadable.

On the other side of the coin, a good UML diagram of a module communicates very efficiently what the structure and design is. I love that. In my mind, one of the primary responsibilities of a computer language is effective communciation. Code on the other hand, epsecially one we are unfamiliar with, tends to hide the structure of a module.

So when a colleague convinced me to start working on an action language (a surface syntax of the action semantics in a UML model) for executable UML the first thing I did was design a textual representation of xUML to contain the action language. This way I could completely avoid using stupid visual tools. Then my colleague said to me: "it would be really impressive if we could have a visual tool!".

Well now that I had a textual representation, the stupid visual tool didn't seem like quite a bad idea, if it allowed rapid context-switching between diagrammatic and textual representations of xUML.

Now Heron is in its early stages as an xUML language. It had a previous life as a C++ type language. Its new role, isn't too far a stretch from where I was taking it before.