hide all comments

DSM

XMI still a failure

April 09, 2008 13:58:50 +0300 (EEST)

Three years ago I posted about the lack of adoption and lack of tool interoperability for XMI:

The OMG has XMI versions 1.0, 1.1, 1.2 and 2.0, with 2.1 under development. Looking on Google, I note that there are 865 XMI files on the web using 1.0, 78 for 1.1, 64 for 1.2, and 34 for 2.0 (released in 2003). That gives some indication of the adoption of XMI as a format, and tallies with my own impression. Everybody was interested when it first came out, but most who actually tried to use it found it lacking. One can always hope the situation improves with newer versions...

So have things improved? In a word, no. Google finds 40 files for 2.1 (released in 2005), and the figures for 1.0 have dropped by over 90%. Now even the most used version, 1.2 from over five years ago, only has 136 files, and the figures decline from there. Yet still people I meet believe that XMI is a useful standard that will solve their problems.

What about tool interoperability then? In an article from the MODELS conference, Lundell et al. tested XMI with 14 UML tools. Obviously, the older tools can't load from the newer tools, but can the newer tools read models from the older tools? That's the important question after all, if you want to use XMI as insurance against your tool being discontinued: will this year's tools load last year's models? Here's the table, see the article for full details:

==> Borland Eclipse  Rational  MagicDraw UModel
ArgoUML   Failed Failed Failed Failed Failed
Fujaba Successful Failed Failed Failed Failed
Umbrello Failed Failed Failed Failed Failed
Artisan Failed Failed Failed Failed Failed
Poseidon Failed Failed Failed Successful Failed
Rhapsody Failed Failed Failed Failed Failed
Rose 1.0 Failed Failed Failed Failed Failed
Rose 1.1 Failed Failed Failed Failed Failed
Visio Failed Failed Failed Failed Failed

Looking at the tools supporting the latest version, 2.1, the picture looks darker still. None of these tools were able to import even 2.0. If XMI were really being implemented by these tools to offer interoperability and insurance, why would they drop support for the previous version? That leaves you rather open to claims that the intention is to pretend there is a standard, and then spread FUD by claiming that other tools don't support it. If the only tools that can interoperate are jointly developing the same code base (Eclipse, IBM, Borland), it's hardly impressive if their parallel versions work well together.

In the DSM world, of course, all this is somewhat academic: the tests were of the simplest possible UML Class Diagrams. None of the tools support working with DSM languages from another tool. If you want to move your DSM models from one tool to another, the main cost is the same as the cost of building support for that DSM language in the new tool -- translating the models is easy in comparison. In that area I'd say MetaEdit+ wins hands down: nothing comes close in terms of ease and speed for the metamodeler or features provided automatically for the modeler. But don't listen to me -- listen to our customers, industry gurus and even competitors all saying the same thing.

Comments

XMI deciphering

[Arnold deVos] April 13, 2008 04:49:24 +0300 (EEST)

Steve,

I maintain an open source tool (see cimtool.org) that reads class/association models in a number of XMI dialects. The woeful situation with XMI standardisation has made this very hard to do well. I can only imagine what its like to extract other UML information.

I have been unable to decipher the earlier OMG standards for XMI. These must be read in combination with MOF specs and profiles, which amounts to a truly huge volume of material. Little of this material is related to UML or XML. I might be able to untangle it eventually, but how would I know I got it right? In fact, no two people have the same interpretation of these standards as your article points out.

So its back to reverse engineering the dialects on a tool by tool basis. I am sorry, but reverse engineering petal files was much easier than this.

My colleagues in the electric power industry need to be able to collaborate on development of a model called the 'CIM'. They are struggling with tool lock-in and have accepted that all collaborators will need to adopt the same one.

I wish the OMG had simply cast petal in XML and called it the standard. That would have been more in accord with their professed policy of not doing new design in standards committees.

[Tom Morris] May 17, 2008 02:15:48 +0300 (EEST)

It's true that XMI interchange sucks, but your numbers about XMI files on the web are waayyy off. Try the Google query "xmi filetype:xmi" (without the quotes) and see all the files your missing -- and that doesn't count the ones that are posted as .xml or .xml.zip (like MagicDraw), .zargo (like ArgoUML), or any number of other file extensions.


BTW, the table is interesting, but it isn't clear whether readers are in columns and writers in rows, or vice versa. Also, does the original version of the table include software versions? That would be another useful bit of information.

Updated XMI statistics

[Steven Kelly] May 19, 2008 14:16:14 +0300 (EEST)

Thanks for the suggestion, Tom! I tried your search for 'xmi filetype:xmi', and it shows a total of 157 hits, excluding duplicates. That's an aggregate over all XMI versions, so it doesn't look like my figures were a long way off. Even including duplicates there are only 579; most of the duplicates seem to be the same file in multiple versions in version control systems. Maybe you were fooled by the first page of results, where Google estimates there are over 2000 files?

The table shows the results of taking a file from the application on the left, and trying to load it in the application at the top. There weren't any more version numbers in the table in the original article.