EmPowerTec UML and modeling blog

Hello,

recently I have written a blog post about TextUML. Now the author asked me about my opinion on TextUML. My statement will be long enough to justify a dedicated posting so that I can use some formatting and I can refine it in multiple sessions. All in all, this posting contains a collection of random thoughts.

First of all, I have never used TextUML so I don’t feel qualified to give a statement about its usefulness. That’s the reason I deliberately did not make such a statement in my first posting on TextUML.

Nevertheless, here are some thoughts on the the topic:

• The UML model is contained in some repository and there are multiple ways to manipulate (and present) the content of the repository. The repository must be made persistent in some way over multiple tool invocations (database, XMI text files, proprietary text files). The persistence technology and format are distinct from the presentation, even if a textual presentation exists.
• Diagrams are “views” onto the repository which show a (possibly tiny) part of the repository. The main purpose of diagrams is to enable the comprehension of some aspects of the model. To achieve this goal a diagram must carefully be crafted manually, leaving out all irrelevant detail (”as much as necessary, as little as possible”).
• All relevant modeling tools use solely some kind of graphical editor to manipulate the model. This is either a diagram or a tree like presentation of the repository (”model browser”).
• Basically, there could be multiple ways to manipulate the repository, e.g. the conventional – graphical – way or a textual notation.
• If multiple users work on the same model, the tool must be able to allow manipulations of the model with sufficiently small granularity so that conflicts are reduced as much as possible. With a graphical tool this is typically achieved because only the selected model element is manipulated. With a text based approach that would mean that only a short fragment of text is presented to the user which makes it hard to see the context.
• Supporting two different manipulation models (graphical and text based) would mean additional effort for a tool vendor with no additional capabilities (I was tempted to write “no added value” but that would be a subjective statement). Tool vendors are usually driven by actual or assumed customer demand and since no tool contains the capability to modify the repository with a textual notation I think TextUML appeals only to relatively few users.
• A text based model manipulation would probably be harder to learn thus decreasing the number of potential users (customers, for a tool vendor). While a person who prefers the text based model manipulation would probably achieve good results when using the graphical approach the opposite is probably not true. And – as Rafael has written on his blog – TextUML is intended to be part of a product that will “aim at mainstream business application developers”. This is a bit contradictory.
• Modern UML tools can do so much more than just the manipulation of a UML repository. E.g. they can track requirements and link them to model elements, maintain access rights and permissions for model elements, calculate risks and efforts, maintain documentation and much more. Do you restrict the textual manipulation capability to the actual UML model? Does it include proprietary extensions of model elements, e.g.the costs associated with a model element? Must the user switch between the two manipulation models for the same model element?
• So if TextUML does restrict itself to the plain UML repository leaving other aspect to a graphical GUI (e.g. as an Eclipse plugin) the TextUML source must be kept synchronized with the repository – not an easy task.

Rafael has created the capability to visualize the models automatically. As written above I think that UML diagrams are about including and omitting the right information and that is difficult to achieve in automatically created diagrams. This applies both to the level of detail, the layout of the diagram and the occasional note that further increases the diagrams value.
Automatically created diagrams can be of value when a model is explored in the sense that one picks some element – typically a class – and wants to see all its relationships immediately without explicitly figuring out the related elements and adding them manually to a diagram. Since there is no significant user contribution to such a diagram it is a light weight, “throw away” artifact, more like a “state view” in a debugger.

I like to create language processing software so I think that TextUML is an interesting project but I don’t believe that it is the best approach for a commercial application.

Best regards,
Andreas

Technorati Tags: modeling, TextUML, UML diagrams

This entry was posted on Monday, December 10th, 2007 at 10:24 pm and is filed under Modeling. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.