Rendering UML2 models with Graphviz

2011-03-10 – UPDATE: this same facility is used in AlphaSimple for rendering UML models online.

The primary goal of the EclipseGraphviz project is to support Eclipse-based applications that want to use Graphviz as an easy way of producing non-interactive structured diagrams without requiring the complexity of GEF or GMF.

The TextUML Toolkit is the only application currently known to be based on the EclipseGraphviz project. To support rendering UML models generated using the TextUML textual notation, EclipseGraphviz has now the ability of rendering any UML model generated using the Eclipse UML2 API.

In this screenshot, you can see the UML model used in the article “Getting started with UML2” rendered with EclipseGraphviz:

getting-started-with-uml2-small.jpg

The main benefits are that the EclipseGraphviz graphical rendering of UML2 models is quite lightweight, and Graphviz produces great layouts automatically. The main caveat is that the diagrams are not interactive. Not to mention that EclipseGraphviz is still quite in its early stages, so it lacks maturity and features. And it does not run yet on non-Windows platforms.

There is where you can make a difference. Check out the project from the Subversion repository, give it a try, and contribute with bug reports, feature requests and patches.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

6 thoughts on “Rendering UML2 models with Graphviz

  1. Ian Bull

    September 2, 2007 at 7:56am

    I wonder if we should combine your work with Zest, an interactive visualization toolkit for Eclipse (http://www.eclipse.org/mylyn/zest.php). This way we can get the great layouts of GraphViz and the interactivity of Zest?

  2. rchaves

    September 5, 2007 at 10:20pm

    Hi Ian, sorry for the delay, but I have been away on an extended long weekend.

    That might work, if you think non-interactive visualizations are fine with your audience. I would be very interested in seeing others making use of the existing infrastructure and helping evolving it into a useful but minimalistic graph rendering framework. Right now the only use case pushing its development is visualization of UML models (class diagrams), which is my personal interest.

    Be warned though that besides the bundling of Graphviz and the image viewing framework there is very little value in it for non-UML related applications at this point.

    Let me know if you have suggestions or ideas. If you feel like contributing code, commit rights are one patch away. :)

  3. rchaves

    November 23, 2007 at 12:28am

    Absolutely not. If you looked further past in the blog, you would have seen this:

    http://blog.abstratt.com/2007/05/06/graphical-notation-in-the-textuml-toolkit/

    There are plans of adopting UMLGraph soon, but not before it suffering a significant surgery that will make it more useful in other contexts (UMLGraph currently only supports annotated Javadocs as input). That effort has just started (way later than initially planned). For the next milestone of the TextUML Toolkit (M3), UMLGraph should be the rendering mechanism.

    Also, EclipseGraphviz is mainly about rendering graphs using Graphviz in Eclipse. The current UML class diagram rendering in EclipseGraphviz is more an example of a concrete application than anything else.

    Thanks for the comments.

  4. Andreas

    November 24, 2007 at 3:14am

    Hello,

    ok, thanks!
    But i don’t get what’s the problem with UmlGraph relying on Java source code. Actually UmlGraph uses just a subset and I see this subset as a domain specific language for describing UML diagrams. So, instead of controlling an object model based on some API the client code emits a piece of source code (*you* should like that :-).
    Granted, this may be a bit more cumbersome and provides more potential for runtime errors but in practice it does not stop me using it (We are actually building an application that uses UmlGraph for rendering class diagrams – a UML metamodel viewer). I think it is a tiny implementation detail.
    I’d prefer having a version that does not rely on an external binary (the dot program) and a Java installation (our software is .NET based).

    Best regards,
    Andreas

  5. rchaves

    November 24, 2007 at 10:21am

    Hi Andreas,

    I am not against supporting that usage scenario (annotated Javadoc’d Java code), but that is what I think it should be: a usage scenario. Even if UMLGraph moves to an API style, the current approach still should be supported as one possible input form.

    It is a matter of separation of concerns (syntax and semantics are different concerns). Separation of concerns promotes reuse, and I always aim for reuse. High-level textual languages are for humans, not for tools. Different people like different syntaxes, even if the semantics is the same, so if the tool is strongly tied to a specific syntax notation, you are needlessly bound to have people that won’t like the tool because of the language. That does not make sense to me economically and strategically wise.

    UML is a great example of that: the semantics are extensively defined, and a graphical notation is proposed based on the semantics. Then, you can have a tool chain that supports UML, and one or more model creation tools that support different input notations.

    Another (incidental) reason is that there are plans of covering other UML diagrams in UMLGraph (sequence diagrams are already supported), and you cannot do that with annotated Java code, so another notation is required anyway (UMLGraph uses pic for sequence diagrams).

    Thanks for your comments,

    Rafael

Comments are closed.