A reader’s “Thoughts about TextUML”

Andreas Awenius, from Empowertec, was kind enough to devote not only one, but two blog postings on the TextUML Toolkit. While his first post was just a paragraph or two acknowledging the use of a textual notation for UML modeling in the TextUML Toolkit, his second post was a very detailed and balanced analysis on the whether using textual notations is a good idea. Even though the conclusion of his posting is that a graphical notation is superior to a textual one, I still agree with many points Andreas has made in his analysis:

  1. the presentation notation and the persistence format are completely unrelated concerns (exactly, see my previous comment on this).
  2. diagrams are views for models, focused on a specific aspect, and as such must show only what is needed and omit anything that is not essential. (perfect)
  3. there are “multiple ways to manipulate the repository, e.g. the conventional – graphical – way or a textual notation”. (yes!)

These are the very same facts that justify the existence of a tool such as the TextUML Toolkit.

  1. since user-oriented notation and persistence format are completely different things, you can please users with the most appropriate syntax for their needs (and that is text for many developers), without affecting interoperability with other tools, as tools interoperate at the level of the persistence format. The TextUML Toolkit achieves that by producing UML2 models as the native object file format.
  2. the graphical notation is great for creating views, but it is not that suitable for exposing all the details in a model. A textual notation has no problem doing that. The graphical notation is still useful, and this is why TextUML Toolkit will include a read-only graphical view for browsing the repository. And here is the first point I disagree with Andreas. He says: “a diagram must carefully be crafted manually, leaving out all irrelevant detail”. I say: automatically generated diagrams can still obey a set of preferences defined by the user (level of detail, color, font, etc). UMLGraph has been doing this for a long time (albeit by breaking some basic rules of separation of concerns, but I digress). The TextUML Toolkit will embed an upcoming version of UMLGraph in its next milestone.
  3. this is basically a conundrum of points #1 and #2. The model created will be the same (from the point of view of tools) regardless the user-facing notation. If users say they would rather use a textual notation, why forcing them to use a graphical one when there are no technical reasons to do so? Here is where Andreas makes several points to back his opinion based on technical and strategical reasons, most of which I (strongly to moderately) disagree. Instead of trying to refute each of those arguments (that is not how you encourage people to provide elaborate feedback), I will use them as an opportunity for driving awareness efforts around the Toolkit, the notation and our future offerings in upcoming posts to this blog.

The ‘raison d’être‘ for this blog is to establish connections with the modeling community at large, users and tool providers. I really appreciate the time and energy that Andreas committed to sharing his views on the TextUML Toolkit and the textual notation approach and am both grateful and honored for that. Thanks a lot, Andreas. Stay in touch. I hope at some point I can convince you that you are wrong! ;)

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

4 thoughts on “A reader’s “Thoughts about TextUML”

  1. Andreas

    December 18, 2007 at 2:26pm

    Hello Rafael,

    thanks for your appreciation.
    There’s another point I forgot in my posting: in early design phases sketching diagrams works great for me to (iteratively) get a clearer picture of a systems design. I don’t think I would achieve the same effect with a graphical notation (only).
    Anyway, it seems as if you are not alone:
    (I was not aware of this until recently)

    Best regards,

  2. rchaves

    December 19, 2007 at 1:25am

    Hey Andreas,

    Maybe surprisingly to you, the TextUML Toolkit would not be a good tool for sketching as it requires well formed models. Please see this post for more on this subject: http://blog.abstratt.com/2007/05/12/uml-modes-and-tools/

    Thanks for the pointer to the TMF proposal. That one is much more ambitious as it is a framework for building textual notations for modeling, for multiple metamodels (basically being for textual modeling what GMF is for graphical modeling). The TextUML Toolkit is just a concrete implementation of a specific textual notation for UML.

    When/if TMF becomes a reality, the TextUML Toolkit could in theory be retrofitted to be based on TMF. The same considerations are true for the IMP project.

    Another project following the same approach (for Ecore-based models) is Emfatic.



  3. Andreas

    December 30, 2007 at 6:30am

    Hello all,

    seems as if I finally have been confused somewhat in my first comment.
    While I wrote
    “I don’t think I would achieve the same effect with a *graphical* notation (only).”
    I actually meant the opposite
    “I don’t think I would achieve the same effect with a *textual* notation (only).”

    Sorry & best regards,

  4. rchaves

    December 30, 2007 at 12:36pm

    Hi Andreas,

    I see now, thanks for clarifying. That is a good point.

    As I said above, the focus for the TextUML Toolkit’s is code generation, requiring completely defined models (all typed elements must declare a type), and thus it is not ideal for sketching.

    But it does not have to be like that. A textual notation could allow incomplete syntax, and thus be appropriate for sketching. I agree that when sketching, we usually are in “picture” mode. However, your sketch of a UML model might eventually evolve into a more complete version suitable for code generation. In that case, if you are a user that bought the idea of textual notation for “formal” modeling, my guess is that you would be fine with using the textual notation while sketching as well (granted, relying heavily on the automatic diagram rendering feature).



Comments are closed.