Which type of export to use for distributed development with non-UML tools?

[mse]

I need to export our model to another party which is working with a non-UML tool. The plan is to receive the XML version of the data and transform it into XMI. Which version of XMI should I use if I want to roundtrip the data back into EA? I want EA to be the single source of truth i.e. the central model. The other tool will only be modifying certain aspects of the model. I read in the documentation that XMI 1.1 is used to export a baseline package and then bring it back, is this the way to go? What about XMI 2.1?

[Geert Bellekens]

You probably don't want to try roundtripping with xmi.

For a non-EA generated xmi, EA won't recognize existing elements and overwrite them.
I usually write a little import/export script to/from whatever format they need (xml, csv, excel,..)
Probably much faster then trying to make transform something into valid xmi.

Geert

[mse]

Right, that is what I am after. Because their tool only writes XML, I want to apply a XSL transformation in order to translate their XML to XMI in preparation for importing back into EA. It might be that they make changes to some aspect of the model that I'd like to see in the central model in EA. Likewise, maybe we make some changes, and we want it to be reflected in their tool.

I'm thinking of going with the Package Control in EA to write the XMI verison of the package. That way we have our packages also under Git version control. I can then apply an XSL transformation to that XMI that will transform into the XML that they can read. They make updates in their tool and give us the XML again. I transform the XML back into the Package Control XMI 2.1 file and "Load from file" in the Package Control menu in EA. That should do the trick.

[Geert Bellekens]

Yeah, I would still stay away from xmi. That seriously complicates things in my eyes.

You can still do version control, but for the import/export I would choose a much simpler approach.

Geert

[mse]

Yes, the XMI has been rather inconsistent with my experience thus far. I noticed that you can export XMI from EA modify the XMI and try to bring it back but things get lost if you disable for example EA extensions in the export. I was trying to keep the XMI as lean and independent as possible while avoiding having to track things in both EA extensions and the original XMI in a single file.

I could try the same with the UML DTD to see if perhaps it is easier. I would like to avoid EA extensions and tool specific things if possible.

[horszasz]

Hi!

I had an interesting adventure a few years ago that is similar to this one. At the time, we had a comprehensive UML / EA model. This had to be complemented by the structures and processes of a system built with its own (non-UML) graphical design tool. (Imagine a graphical process automation tool)

This had to be done repeatedly as the system was continuously developed and expanded.

Our solution was to build an intermediate meta database. We loaded the elements from the non-UML modeling tool here, and here we linked the GUIDs used in the EA model and the identifiers used in the non-UML tool.

Finally, we generated a simple structured XMI from the meta database to update the EA model.

Important: this work cost many times more than buying a few EA licenses for an external developer. In this case, we had no choice, but if you have a choice, you better buy a few EA licenses for the other party. It will be much cheaper than solving the problem of model integration. Seriously!

Cheers,
Gergely