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

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

http://abstratt.com/blog/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.

I wonder how EclipseGraphviz differs from UmlGraph (http://www.spinellis.gr/sw/umlgraph/)?
NIH syndrome?
SCNR
Best regards,
Andreas

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.