Since the invention of UML, a lot of UML tools have been developed, both proprietary and free, for various platforms. So, why another one, and, to top it all, a text-based one?
Being a graphic language, UML is pretty well suited for drawing on paper, with a pencil. When you draw UML on paper, your design flows directly into your diagram and nothing distracts you from the process. However, most of the existing GUI UML tools cannot achieve this level of usability. In many tools, the process for adding a class to a class diagram looks like this:
Now suppose you want to add some attributes and operations to that class. Ideally, you would want to just click between the lines delimiting the attribute compartment and start typing: -name: string <Enter> -birthdate: date and so on. Then, you would press the Down arrow once or maybe twice to get into the operations compartment, and continue typing: +set_salary(value: int) <Enter> +get_salary(): int {query}…
Now, stop daydreaming. Everybody knows that you can’t do that and you wouldn’t really want that, would you? Remembering which characters mean which visibility, remembering the UML syntax for argument direction, name and type, remembering all the important things that can be specified only via the property string. We will draw you a nice dialog that will walk you through all these hurdles. You will just need to enter your data in a nice grid and check the right boxes. That’s what almost all UML tool designers tell you. See, it’s so intuitive, even a child could learn this in twenty minutes.
So, what’s wrong with this picture?
As many seasoned computer user know, there are two characteristics of software that are frequently misunderstood: Intuitiveness and Usability. The former is the ability of a total newbie to use the software. The latter is the ability of a trained specialist to use the software efficiently.
So, if you were a total newbie in UML, you might like some of the tools out there on the market. However, if you have studied the UML specification and/or attended an academic course in UML, these tools will distract your attention with endless dialogs and grids with broken Tab navigation. You will get the job done, but the incessant switching between your keyboard and mouse will drive you nuts.
In TextUML, I take another approach.
I posit that the most efficient interface for entering data is your text editor — be it Vim, Emacs, FAR Manager’s internal editor, or one of a thousand other text editors. What’s important is that you use it every day and have customized it over time for your personal convenience.
There’s just a small problem left. How can you write a graphical language in a text-only editor? In fact, that’s easy. After all, Graphviz authors have devised a text-only syntax for describing graphs, and UML diagrams are essentially graphs. Additionally, Graphviz has several high quality layout engines that can save us the trouble of deciding where to position each node — with a few little hints, it will automatically determine the best layout.
However, the Graphviz input language is quite a low-level one. If you want to draw a class with a
few attributes and operations, you have two options: either a record-shaped node, or a node with an
HTML-like label. Record-shaped nodes seem to be
mildly deprecated, and it is said HTML labels provide more features. But having to wrap each of your
attributes and operations in a <tr><td>…</td></tr> is hardly
conductive to modeling. Also, the dialect of HTML that Graphviz understands is the kind that was
popular in 1990s — no CSS, presentational
attributes all the way. Almost begs for some kind of script to generate it.
So, what I suggest is precisely that: Scripts that will accept an unobtrusive input syntax and generate code suitable for feeding into Graphviz.