New in 1.3 M1: better integration with diagramming tools

Even though it has always been possible to open models generated by the TextUML Toolkit in UML2-based diagramming tools, until 1.2 the Toolkit assigned new ids to each element every time a model was regenerated. That meant that any diagrams based on the model being regenerated would become invalid as any cross-references from the diagram to the model would be broken.

Starting with 1.3 M1 (test build available from the milestones update site), the TextUML Toolkit is now better compatible with diagramming tools based on UML2. You can edit the source in TextUML and save it to cause model generation to occur, and any existing diagrams should still remain valid.

Here you can see the TextUML Toolkit being used side-by-side with the UML2 Tools graphical editor:

Actually, I found out that UML2 Tools can be a great companion for the TextUML Toolkit because it seems to just do the right thing when it notices the underlying model has been changed externally: new elements show up, removed elements disappear, preserved elements preserve their layout. I tried doing the same with Papyrus 1.11 and unfortunately it does not seem to handle external updates properly. I haven’t tried with other UML2-based diagram editors, so at this point I am not sure which one represents the trend here.

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

3 thoughts on “New in 1.3 M1: better integration with diagramming tools

  1. Juha

    January 6, 2010 at 12:42am

    TextUML is really excellent and useful tool!! Thanks for that. This is simply the best way to great and maintain object models. Possibility to integrate the model with other eclipse tools is one of key factors. However the implementation of stable ids is not that stable because it do not allow code/model refacoring since ids are derived from class and role names. Would be great to have possibility to assign ids manually or have automated GUID generator in model editor.

  2. rafael.chaves

    January 6, 2010 at 12:52am

    Wow, thanks for the encouraging words, Juha. Yes, elements will change id if moved around, and that will break things if you have other tools’ models (such as diagram files) referring to a model generated by the TextUML Toolkit.

    Having a project setting for whether to automatically generate ids as GUIDs or derive from qualified names is a good idea, and should be easy to implement.

    To allow some sort of annotation for declaring ids manually would be possible, but I wonder how people would use that.

    Feel free to enter your suggestions as feature requests on the project tracker:



  3. Juha

    January 6, 2010 at 12:47pm

    Might be good to keep the GUIDs (which must be real surrogate keys (i.e. not derived from names)) in source code, otherwise the generated xmi file may run out of sync. GUIDs/ids could be optional and generated by auto completion. Problem is that code becomes rather ugly… It may work, for most of the cases, if ids are assigned only for classes and hashed for associations and other xmi elements from these.

Comments are closed.