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!

Last Thursday happened the 1st Eclipse DemoCamp in Vancouver. It was a very dynamic event, with nine short talks packed into little more than one and a half hours. Attendance was high, I was really amazed to see such a great turnaround. The audience saw a diverse range of interesting Eclipse-based projects being developed in Vancouver/Victoria.

I demoed the TextUML Toolkit and got good feedback and some very interesting questions. The idea of a using a textual notation for creating UML models is still not a very easy sell, and that continues to surprise me. Being a developer, I find working with a textual notation so much more natural than a graphical one that it makes it hard for me to see things from other people’s shoes. I plan to go over the issue of textual versus graphical notations on a future post.

All in all, it was a great event. Many thanks to Tasktop’s Robert Elves and Mik Kersten for organizing it, to the Eclipse Foundation for sponsoring the event, and congrats to all presenters.

In a recent thread on the EMF newsgroup, I came to realize that there are (at least) two EMFs, each belonging to a different class of product, and attending completely distinct requirements.

EMF’s native metamodel, Ecore, is a generic, lean object-oriented metamodel based on a subset of UML.

EMF’s runtime framework provides Java applications with runtime support for object models “including change notification, persistence support with default XMI serialization, and a very efficient reflective API for manipulating EMF objects generically” (source).

I am a happy user of EMF’s Ecore metamodel as a poor man’s UML (EMF team, please take that as a compliment). From Ecore-based models, using a compatible template engine, I can generate all code/artifacts that are prone to automation, be they Java code or not.

The runtime aspect of EMF is certainly useful to many applications, but certainly not to all or maybe even most. That is not to say that the EMF runtime does not provide a lot of value, as it clearly does given its popularity. Nor does it imply that the EMF runtime API has design flaws that prevent its use to be more widespread. The fact is that frameworks, while designed for extension, always impose a certain set of architectural decisions in order to provide value out-of-the-box. Those decisions are bound to make its use more suitable to some scenarios and applications than others. The goal is to make as many people happy as possible. It is clear that the EMF team has pulled off that trick. But that does not mean that using EMF-generated model code is appropriate for every Java application out there.

Model driven development maximizes reuse via a complete separation between problem domain and technological concerns. This separation is critical to allow us to build software in an obsolescence-proof way. EMF’s Ecore provides a good foundation for MDD in this sense, regardless the technology choices for the software being developed. The EMF runtime framework, albeit a valuable tool for a significant range of applications, brings with it a specific set of choices in terms of design and implementation decisions, and as such has a less universal applicability.

However, time and again I read comments in the EMF newsgroup that lead me to believe that this duality might have been accidental, and that the sole reason Ecore was created was to support the generation of Java applications based on the EMF runtime. If that is really the case, this is something that both amuses and worries me. My concern is that if the EMF team does not acknowledge the importance of Ecore as an independently useful product, technical decisions in the evolution of EMF might break the use of Ecore in contexts other than EMF-based Java applications.