From: Jörn Guy Süß (firstname.lastname@example.org)
Date: Mon 16 Feb 2004 - 08:57:05 GMT
Laurie, as part of my thesis on UML methods and model transformation I am building a bus which allows to chain model-oriented services (UML profile checkers, model transform languages, etc.) together. It is built to distribute these across workgroups and globally. The idea is to reuse all the nice tools the model community has invented. As part of that approach, I found that the only viable way to generate acceptable XMI is to create proprietary plugs for each tool, which use tree-walkers to transcribe the internal representations of the tools. Everything else (as you have suspected) is very hard and I assume it will get worse with further variants of XMI, MOF and UML afoot, which produce an ever increasing Cartesian product of mappings. I 'standardize' on UML 1.3 and JMI, because the extension system of v. 1.4 is overly complicated (and has been removed in v. 1.5) and I have not seen v 1.5.'s imperative language support of action semantics in tools. Usually, tools still struggle with n-ary associations, association classes and stereotypes. Also, at UML2003 industry representatives openly declared that (quote) "no tool is going to support the full scope of UML 2.0". Martin Fowler, whom I spoke to after his talk, now only sees the UML relevant for sketching an architecture and believes that blueprinting of systems, the Metamodel and more complex artifacts are not very relevant. Certainly I hope UML is not going the way of the dodo. -- The great thing about standards is there are so many to choose from. -- Standard is as industry does. Jörn -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Laurence Tratt Sent: Friday, February 13, 2004 5:25 PM To: email@example.com Subject: Re: ocl conformance test On Thu, Feb 12, 2004 at 10:45:01AM +0100, Steffen Zschaler wrote: [Jörn] >> I agree, but your approach tacitly assumes that tools will be able to read >> XMI-Files and (moreover) extract the statements from them. IMO this is >> rather the exception than the rule. > This seems to be putting the barrier pretty low. Any OCL tool will need to > be able to access UML models in some manner. The two standard approaches > would be either by accessing some kind of model repository or by reading in > XMI files.In the latter case the ability to read in XMI files is implicitly > given, while in the former case most UML repositories support filling the > repository from an XMI file. So, I think its a pretty low barrier already > to be able to read in XMI files. That's certainly what would happen in an ideal world. About 18 months ago I investigated a number of commercial and open source UML tools, as I was writing an XMI exporter for a research tool we had at King's College. What I found shocked me somewhat: I tried something like 7 or 8 tools. None of them did what I would consider to be a good job. 2 or 3 generated XMI which wouldn't even validate against the DTD, the most basic check there is. One tool even managed to generate XMI which its own crummy importer couldn't read back in. Even for those tools which generated XMI valid against the DTD, pretty much all of them violated other requirements not captured in the DTD. In the end, the only standard there was that they could generate XMI which Rose could read in [actually, there were a couple of situations when even this wasn't true]. The XMI importers were mostly very poor, and for anything other than a ridiculously simple model, the chances of exporting XMI from one tool and importing into another were close to nil. Part of the problem for this is that the XMI standard isn't a great one in the first place and that worse there has been no checking that tools actually conform to the standard in any way - people in the OMG are well aware of these problems and the claim is that they will be fixed, presumably at some point when UML 2 is finalized. >From Jörn's comment, I would assume that the position of 18 months ago still holds roughly true today - that is that tools mostly operate in their own little bubble with very, very limited practical interoperability with the outside world. Yours, Laurie -- http://tratt.net/laurie/ To remove yourself from this list please mail firstname.lastname@example.org with a message containing the word "unsubscribe".