Not yet another language

One potential downside people often point out about using TextUML as a notation for UML is that it is yet another language to learn. But that is not really a well founded argument. TextUML is not a full-blown language, it is just an alternative notation for UML, the de facto standard language for modeling. The language semantics of UML are defined in terms of an abstract syntax, and even though the specification includes sections about the graphical notation, it clearly supports the idea of alternate concrete syntaxes.

Moreover, we really shouldn’t care much about the actual notation being used, be it the standard graphical notation, TextUML or any other textual notation. I surely don’t. Regardless what notation you use for creating UML models, in the end there is only one language. All you know about the semantics of UML model elements is still true no matter what syntax you choose (for instance, if you know your UML, you should easily become productive with the TextUML Toolkit by just glancing over the notation guide now and then). In fact, I predict a time where people will want to move between different notations across tasks and time. Also, in the same team, different people will be collaboratively creating UML models using different notations.

This will only be possible because supporting a new concrete syntax is much simpler than supporting a whole new language (by the way, that is the same reason why I believe UML-based DSLs to be a better option than homegrown proprietary DSLs, but I digress). Any reasonably good programmer armed with a parser generator and knowledge of the metamodel should be able to write a compiler for a textual notation for UML, and Eclipse makes it really easy to provide basic IDE features such as those you see in the TextUML Toolkit. Also, there are tools in the horizon such as IMP and TMF that will make these tasks really a breeze.

Meanwhile, you can stick with what is here today. ;)

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

6 thoughts on “Not yet another language

  1. Manfred Moser

    August 7, 2008 at 12:12pm

    I am split between agreeing and disagreeing. A parallel example is all the different languages running on the JVM. They all represent java byte code so they all have a common target, but man are they different as well. In a similar manner I think that UML notations could be VERY different, yet still talk about the same model. And looking at the multiple languages on the JVM that might not be bad either…

  2. rafael.chaves

    August 7, 2008 at 10:45pm

    Thanks for your comment, Manfred, keep them coming.

    I am really glad you brought that up. There is a big difference between multiple notations for UML and multiple languages on common runtimes such as JVM or the CLR, and the difference is exactly that for UML we talk about “notations” and for the JVM or CLR we say “languages”.

    Notations for UML are just a thin layer of user interface for the language abstract syntax and semantics, no existing semantics changed, no new semantics added.

    Languages for the CLR or JVM are true languages, and in many cases, the fact they run on the CLR or the JVM is just an implementation detail, i.e., they could be (and frequently are) implemented on other runtimes. Even for Java there is a considerable gap in abstraction level between the language and the JVM.

    That is not to say that it does not make sense to support other even richer/more abstract languages on top of UML as you suggest. Model transformation (across metamodels) is one of the key mechanisms in model-driven development. But that is a totally different discussion (which I would be glad to have, btw).



  3. Patrick

    February 14, 2009 at 7:23am

    Gee, it’s been some time since this thread started, but seems still a recurring subject. I dare disagree with Raphael in stating that TextUML in fact, just like UML itself — a language (alas, it even says so in its name). My point ( was that there is not much difference except in syntax between capturing design in TextUML v.s. say Java or Ruby. Let’s look at an example, for brevity using TextUML and Ruby:

    class Car
    def drive(speed); end
    def stop; end
    def accelerate; end

    class Car
    operation drive(speed:Integer);
    operation stop();
    operation accelerate();

    See what I mean? That is why I dare question the notion of using UML, if you can use the implementatino language directly, without loosing semantics. Of course, there are features of one language over another that let you express “semantically rich” elements more easily than in another language — but that IMHO is merely a matter of choosing the right language for the right task.

  4. rafael.chaves

    February 15, 2009 at 11:15am

    Hi Patrick,

    Yes, UML is a language. But TextUML per se is not a real language, instead being just a shallow notation built on top of the UML semantics and abstract syntax.

    Re: Java or Ruby serving as modeling languages – well, if you limit yourself to simple concepts such as classes, their structural features, and inheritance, yes, Ruby or Java can make do as modeling languages. But for sound OO modeling, you need much more: associations (with composition/aggregation semantics), multiplicities, and things from other modeling aspects such as states and transitions. You can try to mimic that with hacks in Java and Ruby, but a modeler will be better served if those features are natively supported by the modeling language.

    That, assuming your creating models to support model-driven development. Totally agreeing with “choosing the right language for the right task”, the best language will be the one that better supports your modeling needs.

  5. Ersin ER

    April 19, 2009 at 12:42pm


    Lots of things can be said on the topic (and I think we should do so) but to put it as simple as possible I can explain the difference as follows:

    TextUML is just another representation for the UML concepts but JRuby has nothing to do with being a representation for JMV bytecode. A machine microcode is at the bottom of the abstration layer chain and almost anything can be built on top of it. On the other hand TextUML (or any concrete syntax) does to add anything to or does not build a really new abstration level on top of UML (or to a abstract syntax/metamodel). So it’s important to distinguish a metamodel and a microcode.

  6. [...] and behavioral modeling (since 2002!). Action languages are not (or don’t have to be) “other languages” – but just a textual notation on top of the existing abstract syntax and semantics. [...]

Comments are closed.