How can I export information in SysML diagrams to a different format (database tables, excel etc) ?
Ashish Bhagavatula
Cedric Gava
It seems you are new to the exciting world of Model Driven Engineering, no ?
Your question fall in the subdomain of Transformations. That can be Model2Text (M2T), ou Model2Model (M2M).
Depending on the tool you use to design your model (Papyrus, Magic Draw, Artisan studio, Modelio, or other ), there are tools and languages associated to query and navigate inside your model to extract what you want. Some of them rely in standard (like QVT, MTL, OCL) some other do not.
Maybe you should also take a look at : http://www.all4tec.net/Model-Based-Safety-Analysis/safety-architect.html, for FMEA analysis and safety considerations
Cheer
Cédric
Hains1967
Hello Ashish,
To add to the good advice from Cédric, there are two other things you should consider:
Firstly you talk in terms of diagrams. If this is just a shorthand then it’s fine – but for proper UML and SysML tools (as opposed to drawing tools) diagrams are ways of building and looking at models. Any given diagram may elide some aspects of the model in order to concentrate on others. The fact that something does or does not show on a diagram should have no more meaning than (say) whether a given symbol is within or outside the currently viewed zoomed in area of a diagram. This means that, particularly when doing things like fault tree analysis you should be looking at the underlying model, not the diagrams (and a proper UML or SysML tool will typically let you do this)!
This leads me on to my second point – you might consider the tools XMI export capability (if it has one). It “leads” because standard XMI covers underlying model, not diagrams (a Diagram Interchange standard does exist too, but given tools vary so much in representation on diagrams it is far less useful, as well as being less mature and less supported than core XMI). To be fair the quality of XMI generated also varies greatly between tools, but it is a standard, and even if the ideal (that your work could then be used as is on a different tool also exporting XMI) is not fully met (as in in fact your work will need tweaking first) it is still a possibility to consider (and hopefully the tweaking will be easier than a complete rewrite)
As an aside I am, right now, doing some work concerning reading and writing part hierarchies (including flowports, connectors and Item Flows) to and from PTC Integrity Modeler (this is the new name for Artisan Studio mentioned by Cédric). Anyway, good luck with your endeavour.
Final point – you do know that flowports are deprecated in the current version of SysML – you should really be using full ports for new work.
Ralph
Bender
Arun Chakrapani Rao
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.
To post to this group, send email to sysml...@googlegroups.com.
Visit this group at http://groups.google.com/group/sysmlforum.
To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/fc24b217-50cc-4bb2-b0a3-aef2d958a37d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ashish Bhagavatula
Daniel
Hains1967
Hello Daniel,
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). This means I have mainly (though not exclusively) worked with XMI from the vendors that are members of that group. 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:
http://www.omgwiki.org/model-interchange/doku.php
All the rest of this is best taken as my (personal) opinion only.
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.
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.
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. 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). Clearly if those cases match ones used by the MISIG and both tool vendors are in the 6 your chances go up.
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. 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. This may have changed I have not looked at this for well over a year. Of course if your tool chain is entirely Eclipse then this may not matter to you. The problem may be worse wrt Eclipse but it actually affects vendors across the board - there isn't all that much pressure for vendors to conform properly - hence the disappointing level of participation in the Model Interchange Group (6 out of a lot more than 6!).
As I said, I'm not going to name names (even if I could remember them) but problems are many and various. There are many versions in the mix (XML, XMI, MOF, UML etc) and in general if they don't all match on both ends at best fidelity suffers and at worst transfer fails.
Even when they claim to meet a particular version say of UML (in the headers) it is common to find aspects that are lagging (using names from earlier versions of, say, UML).
Outputting values that are set to default (against the rules, most importers cope but not all).
Outputting XMLID references to items that don't exist in the XMI.
Even in some cases badly formed XML (no chance with that if the <>s don't balance!).
Importers that refuse to import if just one version or url is not exactly what they expect (rather than informing user and doing a "best effort" job). Of course if you know this a little text editing of the XMI and it will try and may get further.
Actually based on a lot of experience, always be prepared to hand edit XMI to massage it into a shape that a given importer doesn't fall over, but some importers do a good job reporting back to the user why they failed, where they just say "Can't" you haven't a lot to work on!
These are just a few of the issues I remember encountering - I hope this helps.
