Of course if your tool chain is entirely Eclipse then this may not matter to you. This may have changed I have not looked at this for well over a year. Whether this is because of a view that XMI based on ecore is a defacto standard, so conformance to the actual standard isn't seen as important, or whether there is just little call from users onto the developers for transfer into or out of the Eclipse environment I don't know. The only other generalization I will make, that may be more contentious, is that my experience has been that XMI founded on ecore tends to be less conformant. Clearly if those cases match ones used by the MISIG and both tool vendors are in the 6 your chances go up. Using XMI to swap between diagramattic modelling tools is frankly a use case that is rarely supported well enough to make it feasible for more than particular point cases and usually one off transfers, even considering the addition of DI (Diagram Interchange). You have a higher (though still not all that high) chance of success exporting from the modelling tool to a dis-similar tool downstream (for example a code generator) especially if you have control over the downstream tool's importer. If I was choosing between tools I wouldn't actually put all that much weight on XMI - good APIs to get at the stuff that doesn't transfer using XMI (and from my experience there will be some) I would put a much higher weight on. I consider it probably safe to generalize that, on average, the XMI from tools sold by vendors particicpating in this group (see the URL) will be higher quality (as they have been working to improve exchange) but the reality is that you should really concentrate on the specifics of your tool chain - one pair of tools might do a good job on a class model transfer, but fall on its face for (say) A SysML requirements transfer - another pair of tools (or even the same pair operating in reverse) may give completely different results - you get the idea. I don't feel comfortable going into any detail that names names partly for that reason, but I will point you to the work of that Group, you may find some useful info (and tooling) there:Īll the rest of this is best taken as my (personal) opinion only. This means I have mainly (though not exclusively) worked with XMI from the vendors that are members of that group. I have worked with XMI quite a bit (though not so much in the last year or so) but mainly concerned with the Model Interchange SIG (formerly the Model Interchange Working Group). Anyway, good luck with your endeavour.įinal point – you do know that flowports are deprecated in theĬurrent version of SysML – you should really be using full ports for new work. To and from PTC Integrity Modeler (this is the new name for Artisan Studio Hopefully the tweaking will be easier than a complete rewrite)Īs an aside I am, right now, doing some work concerning readingĪnd writing part hierarchies (including flowports, connectors and Item Flows) Work will need tweaking first) it is still a possibility to consider (and On a different tool also exporting XMI) is not fully met (as in in fact your Is a standard, and even if the ideal (that your work could then be used as is Toīe fair the quality of XMI generated also varies greatly between tools, but it Less useful, as well as being less mature and less supported than core XMI). It “leads” because standard XMIĬovers underlying model, not diagrams (a Diagram Interchange standard doesĮxist too, but given tools vary so much in representation on diagrams it is far Tools XMI export capability (if it has one). This leads me on to my second point – you might consider the Not the diagrams (and a proper UML or SysML tool will typically let you do Things like fault tree analysis you should be looking at the underlying model, Meaning than (say) whether a given symbol is within or outside the currently The fact that something does or does not show on a diagram should have no more Any givenĭiagram may elide some aspects of the model in order to concentrate on others. Shorthand then it’s fine – but for proper UML and SysML tools (as opposed toĭrawing tools) diagrams are ways of building and looking at models. To add to the good advice from Cédric, there are two otherįirstly you talk in terms of diagrams.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |