XMI 2.x not working

[thomas.beale]

I have generated out XMI 2.1 and 2.3 files from a model. An Enterprise Architect user has tried to use them, with partial success. However, attribute types are missing. I have checked the XMI files and they are there, so maybe the particular XML structures, or links or other details have a problem. The XMI looks 'good' to me but that doesn't mean it works! Has any testing been done on the XMI with particular tools? How do we know what options to work?

thanks

- thomas

[Bruno Pagès]

please can you create the same simple model containing class(es) and attribute(s) both under Enterprise Architect and Bouml where the XMI 2.1 / 2.3 exported by Bouml is not well imported by Enterprise Architect, and give me the XMI 2.1 and 2.3 produced by both tools to allow me to compare them and fix/bypass the problem ?

note : it this only concern primitive types (e.g. int) do a try setting the XMI export option Use primitiveType rather than DataType

[thomas.beale]

Bruno, I will do that. It wll take some time - have to ask people in another org to do it in EA. In the meantime, is there more detailed help for what all the XMI generation options mean?
thanks
- thoms

[Bruno Pagès]

Thomas,

I got a trial version of Enterprise Architect to do some tests, it doesn't allow to have an attribute typed by a class in an XMI file, I mean If you create an attribute typed by a class C the XMI produced by EA doesn't define a property typed by a reference to C. This is why it doesn't allow to import an attribute typed by a class.

If you use relations between classes rather than attributes the XMi exported by Bouml is rightly imported by EA

[edit]Bouml rightly imports the XMI 2.1 and 2.3 files produced by EA supposing you add a xmi:id at the project level, I will change the XMI import to not require this id[/edit]

[thomas.beale]

Looking at the XMI I provided based on the simple PERSON / PERSON_NAME model, it seems there is a link from the attribute to the type...

<packagedElement xmi:type="uml:Class" xmi:id="EAID_15348D24_58AB_4191_8BCB_F1A9516E57F4" name="PERSON" visibility="public">
<ownedAttribute xmi:type="uml:Property" xmi:id="EAID_EA385EA0_5FA0_449d_BEA6_16FB5C50C168" name="name" visibility="private" isStatic="false" isReadOnly="false" isDerived="false" isOrdered="false" isUnique="true" isDerivedUnion="false">
<type xmi:idref="EAID_B3A5F42C_FB5A_4ea9_889E_D9E05C8DF532"/>


the final ref. id EAID_B3A5F42C_FB5A_4ea9_889E_D9E05C8DF532 points to the following a few lines below:

<packagedElement xmi:type="uml:Class" xmi:id="EAID_B3A5F42C_FB5A_4ea9_889E_D9E05C8DF532" name="PERSON_NAME" visibility="public">

Doesn't this mean that EA is putting out correct references? Or is there an error in the XMI details?

- thomas

[Bruno Pagès]

sorry, I didn't know why but I looked at the extension part, anyway, using my trial version of EA :

• if I import the XMI you sent to me, all is ok and the attribute name of PERSON as the type PERSON_NAME
• however, if I modify the file to remove <xmi:Documentation exporterVersion="6.5" exporter="Enterprise Architect"/> and the xmi:Extension to not say to EA it is a EA file, then I import this modified file, the attribute name of PERSON doesn't have a type

to avoid problems when importing under EA you have to not use attributes typed by a class, this means you have to use relations in these cases

as you can see my XMI2 export has several options to take into account the specificities of the other tools I was able to see, but there are limits, I will not add an option to say the file is exported by EA

I see you set the toggle Generate for Eclipse (aggregation set on other relation side) to export with Bouml, don't do that. It is very strange but EA draws the aggregation/composition sign on the wrong side on the class diagrams (independently of the fact you imported or not a model to define this aggregation/composition)
Note that when you import under Bouml an aggregation/composition through an XMI file exported by EA, Bouml writes the sign on the right side

[thomas.beale]

In the large model we have, changing the hundreds of attributes to relationships is not an option - we have the model we want, the way we want it. But I wonder if you added (manually) an EA 'XMI generated by Enterprise Architect' XML header (i.e. what you removed from the EA XMI) to a BOUML XMI file, would it then import properly under EA?

- thomas

[Bruno Pagès]

Frankly I don't think to just add the line saying the file is generated by EA will solve the problem because I will not be able to generated the XMI exactly like EA does, and I guess this will introduce new problems inside EA. Perhaps there are also some legal problem to have a tool lying like that. Sorry to say but if a tool must be changed it is EA, to fix its bugs ...

To replace the attributes typed by a class by the corresponding relations can be done automatically by a plug-out, but this will change class definitions and will 'dramatically' affect your diagrams

[thomas.beale]

Don't worry, I am already convinced the main bugs are in EA. Unfortunately, there are a lot of people using it, and I need evidence of what is wrong before reporting it to them.

- thomas

[thomas.beale]

Ok, I have more information from an OMG XMI expert who has analysed the BOUML XMI. Here is what he said (I tried to upload the XMI files here, but .xmi isn't allowed).

* * * *

So, your posted UML 2.3 model cannot be imported by RSA 8. I get the following error. Exactly same with eclipse 3.6 or 3.7

Problem loading file openEHR_102_RM_DT_xmi2.3.xmi. See details for more information.
No UML elements recognized (only UML 2.1, 2.1.1, 2.1.2 and 2.2 are supported)

Thus, I could open your UML 2.1 xmi file in eclipse 3.6 and RSA 8, however UML 2.2 would be preferred.

But there is a technical error in both of these XMI files from BOUML that must be fixed by that vendor. I was able to make a quick text edit to the file so that it can be imported by both eclipse 3.6 and RSA 8. Corrected version is attached. At the bottom of the file, there is a list of DataTypes contained using the xml element "ownedMember". this is invalid, it must be "packagedElement". After that edit, the file can be opened.

The better fix would be to change the model, and hopefully avoid this export error from BOUML at the same time. Most of the EA models that I've looked at in XMI have a similar problem. EA exports valid XMI, but the UML model is not interoperable with other tools. I think that both tools and models can be fixed with a simple change to best practice. I do not have EA license, so cannot test.

If you look at the bottom of the XMI file from BOUML, you see a list of DataType definitions, e.g.

<ownedMember xmi:type="uml:DataType" xmi:id="BOUML_datatype_3" name="ANY"/>
<ownedMember xmi:type="uml:DataType" xmi:id="BOUML_datatype_34" name="Any"/>
<ownedMember xmi:type="uml:DataType" xmi:id="BOUML_datatype_26" name="Assertions"/>
<ownedMember xmi:type="uml:DataType" xmi:id="BOUML_datatype_5" name="DV_IDENTIFIER"/>
<ownedMember xmi:type="uml:DataType" xmi:id="BOUML_datatype_24" name="DV_INTERVAL&lt;DV_DATE&gt;"/>

I assume that BOUML (and EA) allow you to simply enter the text name of an attribute data type as part of defining a class. This looks OK in a diagram, but is an incomplete model. The data type is never defined. So, when exporting, both of these tools create new data types for these "implicit" names. If you ALWAYS define every type used in your model, including attribute types such as these, then use the defined type when creating class attributes, we should get a better model. In EA, the implied types are saved correctly in an XMI extensions element, but other tools are not expected to interpret or use these vendor-specific extensions.