Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Sirius » XMI compatibility
XMI compatibility [message #1818868] Tue, 31 December 2019 07:34 Go to next message
Avi Shaked is currently offline Avi ShakedFriend
Messages: 131
Registered: October 2019
Senior Member
Hi,

Is there a way to export Sirius models into OMG's XMI file?
If so, how? and also, has anyone tried to transfer a model from Sirius to another MOF/UML compatible modeling tool?
Re: XMI compatibility [message #1818870 is a reply to message #1818868] Tue, 31 December 2019 08:42 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Ho

You will find that Sirius models are already XMI files; no export necessary.

Diagram transfer is a long standing problem that UMLDI might alleviate once tools support it.

Regards

Ed Willink
Re: XMI compatibility [message #1818874 is a reply to message #1818868] Tue, 31 December 2019 09:27 Go to previous messageGo to next message
Avi Shaked is currently offline Avi ShakedFriend
Messages: 131
Registered: October 2019
Senior Member
Thank you.

I saw that underlying meta-model is XMI, but the models created using a domain specific model are not XMI, in the sense that they do not include the full mapping of objects into MOF elements.

For example: my meta-model includes two classes: Sensor, Actuator. These are specified in XMI compliant ecore xml file. Once the user uses these two classes to create instances in the model (Sensor1, Sensor2, Actuator1) the DSM xml file includes only the association of Sensor1 and Sensor2 to the Sensor class (e.g., <sensor name="Sensor1" ...>) and not the information about the sensor class itself.

Is there a more "complete" model XML representation form available?

Re: XMI compatibility [message #1818884 is a reply to message #1818874] Tue, 31 December 2019 15:59 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
HI

Your terminology / understanding of XMI seems to be poor.

I have no idea what yo mean by "a full mapping of objects into MOF elements", certainly few of my models have an overt relationship to MOF.

Perhaps you are confused by the omission of xsi:type when the element tag makes it obvious. Or perhaps you expect too much of generator. Clearly if your DSL generator produces C++ text, the C++ text will not be XMI.

You need to provide an example of what you find defective.

The following is part of a UMLX file maintained by a Sirius editor:

<?xml version="1.0" encoding="ASCII"?>
<umlx:UMLXModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:umlx="http://www.eclipse.org/qvt/2016/UMLX">
  <ownedTxDiagrams name="Forward2Reverse" package="org::eclipse::qvtd::umlx::tests::forward2reverse">
    <comments>Reverse the order of elements in a circular list.</comments>
    <ownedRelDiagrams name="element2element" isTop="true">
      <comments>Map each element to an element with reversed source/target linkage.</comments>
      <ownedRelDomainNodes referredTxTypedModelNode="//@ownedTxDiagrams.0/@ownedTxTypedModelNodes.0">
        <ownedRelPatternEdges source="//@ownedTxDiagrams.0/@ownedRelDiagrams.0/@ownedRelDomainNodes.0/@ownedRelPatternNodes.1" target="//@ownedTxDiagrams.0/@ownedRelDiagrams.0/@ownedRelDomainNodes.0/@ownedRelPatternNodes.0">
          <referredEStructuralFeature xsi:type="ecore:EReference" href="DoublyLinkedList.ecore#//DoublyLinkedList/ownedElements"/>
        </ownedRelPatternEdges>


The root element clearly shows that it is an XMI 2.0 serialization of an http://www.eclipse.org/qvt/2016/UMLX model (DSVL).

The ownedRelDiagrams element has no XMI clues since the type is inferred unambiguously from umlx:UMLXModel.ownedTxDiagrams.ownedRelDiagrams.

IIRC there is an XMIResource save option to emit gratuitous xsi:type attributes.

Regards

Ed Willink

Re: XMI compatibility [message #1818956 is a reply to message #1818884] Fri, 03 January 2020 10:29 Go to previous messageGo to next message
Avi Shaked is currently offline Avi ShakedFriend
Messages: 131
Registered: October 2019
Senior Member
Thank you Ed.

You actually showed my exact point:
"The ownedRelDiagrams element has no XMI clues since the type is inferred unambiguously from umlx:UMLXModel.ownedTxDiagrams.ownedRelDiagrams"

Indeed, but if I try to migrate this model to another tool just by using the XMI file you provided, the nature of ownedRelDiagrams element is not explicitly listed. Therefore, an external tool will be unable to parse it solely by parsing the specific model file.

Just to make clear: I am not saying there is any problem. There is no problem!
I am just asking for your advice on producing a full model description which includes both the specific model entities (implementation) and the meta-model that was used, so that a different tool (which - you can assume - can understand MOF elements) will be able to reproduce the same model.
Re: XMI compatibility [message #1818957 is a reply to message #1818956] Fri, 03 January 2020 11:32 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

I suspect that you are overthinking the problem and anticipating a problem where there should be none. Any XMI (or XML) tool should cope. If not, you should reconsider why you are using such defecting tooling.

As I mentioned earlier, the XMIResource save option to emit gratuitous xsi:type attributes might help some defective tool.

Regards

Ed Willink
Re: XMI compatibility [message #1818970 is a reply to message #1818957] Fri, 03 January 2020 17:56 Go to previous message
Avi Shaked is currently offline Avi ShakedFriend
Messages: 131
Registered: October 2019
Senior Member
Ed Willink wrote on Fri, 03 January 2020 11:32
Hi

I suspect that you are overthinking the problem and anticipating a problem where there should be none.


Indeed. It is posible.
I will try to have a partner working with another tool trying this. There is a more, somewhat related, generic concern behind this (which I will ask about soon).

Regardless, if anyone cares to share experience from transfering Sirius based models to other modeling tools, that would be appreciated.

Thank you!
Previous Topic:Copying/Moving items
Next Topic:how "Links to other representations" works
Goto Forum:
  


Current Time: Fri Apr 19 11:09:17 GMT 2024

Powered by FUDForum. Page generated in 0.02066 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top