Controlling order of classes and attributes

[kjourdan]

I have an xmi file that has classes with sub-classes where the order of these is important. The top level class may contain a configuration class but this must be the 1st sub-class.  The top level class may then contain 1 or more record element classes; the order of these classes should match the S/W implementation. Consider a class used to model a data record. This class could contain a sub-class that defines the attributes of the record; this sub-class is expected to be the 1st sub-class.  This data record class could also contain 1 or more data element classes; the order of these data element classes is expected to match the S/W implementation.

After importing my xmi file, the order of the sub-classes is changed.  Is there a way to force or the order of the elements to match the order they were defined in the xmi file during import?  During export, is there a way to force the elements to be populated in the xmi file according to the order they are defined in the Project Browser?

[qwerty]

I made a quick test with different ordering and after an import the order was as expected. Which EA version and which XMI format do you use?

q.

[kjourdan]

XMI 2.1 with EA 12.1

<xmi:XMI xmlns:uml="http://schema.omg.org/spec/UML/2.3" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1

My xmi file has the following:
                <packagedElement xmi:type="uml:Class" xmi:id="EAID_c297f8fb_aef3_bd88_35f3_6560afc31e42" name="AlvCalibrationDataTypeAlv1">
                                <packagedElement xmi:type="uml:Class" xmi:id="EAID_42482dca_e1b0_8621_da41_7885cd87ffb5" name="DataDefProp"/>
                                <packagedElement xmi:type="uml:Class" xmi:id="EAID_86a55fb0_cd88_a92a_e643_c512dd284893" name="AlvOffset"/>
                                <packagedElement xmi:type="uml:Class" xmi:id="EAID_d6cf1044_19f7_831e_5eae_9aabaf28892f" name="Sensitivity"/>
                                <packagedElement xmi:type="uml:Class" xmi:id="EAID_e39e552c_6c47_8ac1_b237_5fb0592fccc5" name="Checksum"/>
                </packagedElement>

After import, the AlvCalibrationDataTypeAlv1 class has AlvOffset, Checksum, DataDefProp and Sensitivity sub-classes in this order.  When I export the model as xmi again, I get
      <packagedElement xmi:type="uml:Class" xmi:id="EAID_03FA9522_8E9A_4130_A3DB_7C6DB1858A62" name="AlvCalibrationDataTypeAlv1" visibility="public">
            <nestedClassifier xmi:type="uml:Class" xmi:id="EAID_49799FB4_B6C9_462b_93F6_B107BC30F897" name="AlvOffset" visibility="public"/>
            <nestedClassifier xmi:type="uml:Class" xmi:id="EAID_256557F3_2952_4344_B939_6416616D0670" name="Checksum" visibility="public"/>
            <nestedClassifier xmi:type="uml:Class" xmi:id="EAID_BEDC37A5_B584_4550_91EC_70B76D861A86" name="DataDefProp" visibility="public"/>
            <nestedClassifier xmi:type="uml:Class" xmi:id="EAID_C4693AAC_CAA7_4fab_8965_38A7BAD4FE50" name="Sensitivity" visibility="public"/>
         </packagedElement>

This matches the order displayed in the Project Browser but differs from the order that were defined in the original xmi file.

[kjourdan]

One additional piece of information, the xmi file being imported does not contain Enterprise Architect extension nodes; the input xmi file is created externally and is intended to be tool independent.

     <xmi:Extension extender="Enterprise Architect" extenderID="6.5">

[qwerty]

Strange. I tested with V13 and V12 and found the correct order after an import (with and without strip GUIDs). You should probably contact Sparx support via mail.

q.

[Eve]

My xmi file has the following:
                <packagedElement xmi:type="uml:Class" xmi:id="EAID_c297f8fb_aef3_bd88_35f3_6560afc31e42" name="AlvCalibrationDataTypeAlv1">
                                <packagedElement xmi:type="uml:Class" xmi:id="EAID_42482dca_e1b0_8621_da41_7885cd87ffb5" name="DataDefProp"/>
                                <packagedElement xmi:type="uml:Class" xmi:id="EAID_86a55fb0_cd88_a92a_e643_c512dd284893" name="AlvOffset"/>
                                <packagedElement xmi:type="uml:Class" xmi:id="EAID_d6cf1044_19f7_831e_5eae_9aabaf28892f" name="Sensitivity"/>
                                <packagedElement xmi:type="uml:Class" xmi:id="EAID_e39e552c_6c47_8ac1_b237_5fb0592fccc5" name="Checksum"/>
                </packagedElement>

Then you're lucky it imports at all. It's not valid XMI as a class doesn't have a member called packagedElement.

I don't know if it's relevant, but the packagedElement property (on Package or Component) is not ordered. So UML says the order is not important. On the other hand, nestedClassifier (how EA interpreted your XMI and exported it) is.

[kjourdan]

Thanks for feedback Simon.  Using nestedClassifier did not address the issue. After the import, the order of the nested classifiers does not match the order specified below.

   <packagedElement xmi:type="uml:Class" xmi:id="EAID_c297f8fb_aef3_bd88_35f3_6560afc31e42" name="AlvCalibrationDataTypeAlv1">
      <nestedClassifier xmi:type="uml:Class" xmi:id="EAID_42482dca_e1b0_8621_da41_7885cd87ffb5" name="DataDefProp"/>
      <nestedClassifier xmi:type="uml:Class" xmi:id="EAID_86a55fb0_cd88_a92a_e643_c512dd284893" name="AlvOffset"/>
      <nestedClassifier xmi:type="uml:Class" xmi:id="EAID_d6cf1044_19f7_831e_5eae_9aabaf28892f" name="Sensitivity"/>
      <nestedClassifier xmi:type="uml:Class" xmi:id="EAID_e39e552c_6c47_8ac1_b237_5fb0592fccc5" name="Checksum"/>
   </packagedElement>

[galpeti]

I have tried to export a small example and import back, the nested classifiers order is changed after the import : ( here we have 1.2 before 1.1 ) This is not the case in the "other" UML tool (element order is respected ). I have the "Allow Free Sorting" ticked, and the "Sort Features Alphabetically" is not ticked. Am I missing something?

<?xml version="1.0" encoding="windows-1252"?>
<xmi:XMI xmi:version="2.1" xmlns:uml="http://www.omg.org/spec/UML/20090901" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:thecustomprofile="http://www.sparxsystems.com/profiles/thecustomprofile/1.0">
   <xmi:Documentation exporter="Enterprise Architect" exporterVersion="6.5"/>
   <uml:Model xmi:type="uml:Model" name="EA_Model">
      <packagedElement xmi:type="uml:Package" xmi:id="EAPK_AE309504_54A1_45b6_B125_9959572FABE7" name="TestPackage">
         <packagedElement xmi:type="uml:Class" xmi:id="EAID_78D9AF96_CB93_4622_8A8B_02ADA783CE76" name="Class1">
            <nestedClassifier xmi:type="uml:Class" xmi:id="EAID_A303D3F5_E901_461c_9D77_827E9BB0D5CF" name="Class1.2"/>
            <nestedClassifier xmi:type="uml:Class" xmi:id="EAID_EE626B36_A1E3_4391_B5F1_5C08E4C4F36F" name="Class1.1"/>
         </packagedElement>
      </packagedElement>
      <profileApplication xmi:type="uml:ProfileApplication" xmi:id="profileap_thecustomprofile">
         <appliedProfile xmi:type="uml:Profile" href="http://www.sparxsystems.com/profiles/thecustomprofile/1.0#thecustomprofile"/>
      </profileApplication>
   </uml:Model>
   <thecustomprofile:test base_Class="EAID_78D9AF96_CB93_4622_8A8B_02ADA783CE76"/>
</xmi:XMI>

[kjourdan]

Feedback from Sparx indicates handling of nestedClassifiers in xmi file does not comply with the standard but will be corrected in a future release:

>>Is the order of these nestedClassifiers for import only controlled based on the EA extensions node?
Currently this is the case - EA relies on the information in the EA extensions node to order the elements.
But we will update the XMI 2.1 Importer in the future releases of EA to reply on the order of elements in the UML section when EA extensions node is not available.

>>Is there any option available to indicate to EA that the xmi file being imported should retain the order defined for nestedClassifiers?
No, this information is stored only in the EA extensions node.

[Guillaume]

Hi,

If you can add in your XMI an expected order value in a tagged value or alias within each class, you can use eaUtils free addin to sort your elements within EA once all classes have been imported.
See www.eautils.com for more info.

Hope it can help.
Guillaume

[kjourdan]

Hi Guillaume,

Thanks, we went with a similar approach to resolving.