Even though a textual notation such as TextUML is much more productive when creating UML models, the graphical notation is still better for a high-level overview. So, for the next milestone of the TextUML Toolkit, the main feature planned is a model visualizer using the conventional graphical notation of UML.
The first option considered in implementing that feature was the UML2 Tools project, part of the Eclipse.org Model Development Tools project. UML2 Tools supports viewing and editing most of UML diagram types, and works seamlessly with models created using UML2 and EMF, which the TextUML Toolkit already uses, and that is great. However, it also requires GEF and GMF, what is bad because it significantly increases the download size for the TextUML Tookit (currently at 31MB), already high for the value it currently provides. Also, from some initial experimentation, it seems to be very computation and/or memory intensive. Because of that, it was decided a more lightweight alternative should be found, even more so if you consider interactivity and support for diagrams other than the class diagram are very low on our list.
Enter Graphviz and UMLGraph
However, Graphviz is very generic, and does not know anything about the UML notation. That is when UMLGraph comes into play. UMLGraph produces dot files that generate OMG compliant UML diagrams (like the ones showing here).
So the direction is to adopt Graphviz and UMLGraph into a lightweight, non-interactive graphical viewer for UML class diagrams. We don’t dismiss having a more powerful graphical viewer (and editor) in the future, probably based on the UML2 Tools project, but the focus now is on simplicity.
There are two difficulties into adopting Graphviz and UMLGraph though:
- Graphviz is a native standalone tool, not a Java API
- UMLGraph, as a Java doclet, supports only one input representation: Java source with Javadoc comments
Turns out the first obstacle can be easily overcome by wrapping the Graphviz binaries into platform-specific fragments and providing a simple Java API on top of it.
The second obstacle is a bit trickier though. UMLGraph ties the usage of the doclet API into the generation of output in dot form. Breaking that coupling requires a non-trivial refactoring effort. I have been talking to UMLGraph author Diomidis Spinellis and he is keen on the decoupling, and that is the route we are going to take.
Would you like to see what it looks like? Make sure to check out the M2 milestone coming out in mid-June.