v15.2 – Order of sections in generated MDG varies by machine

[Paolo F Cantoni]

Another weird (in my view probably a defect - cf Eve) behaviour. 

We generate a number of profiles using a script with a number of SavePackageAsUMLProfile() statements and then stitch them together with a GenerateMDGTechnology() statement.

We use file comparators to confirm that the changes we make in the model are reflected in the generated XML (by individual profile).  This works VERY well and has saved us heaps of time by catching anomalies early.

We also test our generation mechanism by running it on a number of machines.  We do this to ensure that the process is robust and that sanity prevails¹.

Imagine our surprise (and dismay) when running the same process with the same inputs on two different machines our file comparator "barfed"!  Red lines "all over the place"!

Investigation revealed that although the overall content appeared the same² the order of the sections was changed - breaking the file comparison!
As an example...

Code: [Select]

<Apply type="Activity">
<Property name="isReadOnly" value="false"/>
<Property name="isSingleExecution" value=""/>
<Property name="parameterName" value=""/>
<Property name="postcondition" value=""/>
<Property name="precondition" value=""/>
<Property name="_HideMetaclassIcon" value="true"/>
<Property name="_HideUmlLinks" value="true"/>
</Apply>
versus

Code: [Select]

<Apply type="Activity">
<Property name="_HideMetaclassIcon" value="true"/>
<Property name="_HideUmlLinks" value="true"/>
<Property name="isReadOnly" value="false"/>
<Property name="isSingleExecution" value=""/>
<Property name="parameterName" value=""/>
<Property name="postcondition" value=""/>
<Property name="precondition" value=""/>
</Apply>

That is, the location of

Code: [Select]

<Property name="_HideMetaclassIcon" value="true"/>
<Property name="_HideUmlLinks" value="true"/>
had changed!

Is there some setting that is controlling this, or some environmental factor or is it just bad coding?
In my view, we were running the same process with the same inputs - and expecting the identical output! ³ 

Not yet reported,
Paolo

¹  As is widely known, the definition of insanity is "running the same process twice (with the same inputs) and expecting a different result"!
²  There were far too many changes to check them all, so after a random sample, we "took it on faith" that the content was effectively the same.  As opposed to actual confirmation that the result was identical.
³  Running the process multiple times with the same inputs DOES generate identity of output on the same machine.

[Eve]

I suspect the difference is Start > Desktop > Preferences > Objects > Sort Features Alphabetically

¹Which would imply that if a different result is received that there is some additional input that you haven't accounted for.

[Paolo F Cantoni]

I suspect the difference is Start > Desktop > Preferences > Objects > Sort Features Alphabetically

¹ This would imply that if a different result is received that there is some additional input that you haven't accounted for.

I also suspected that setting (which is why I asked), but I thought "Why would a setting for rendering attributes in the GUI affect XML output"?  I was wrong.  Although the Help says NOTHING about anything other than diagrams being affected, the setting does impact the XML output!

Historically, Sparx has had REAL problems with import/export.  Such processes should (in general) be affected only by parameters that can be manipulated in the export process itself.  I can see no rationale for connecting the two processes (diagram rendering and XML output).  The XML output should be consistent (regardless of the display rendering).

I'll report the defect, now that it has been successfully diagnosed.
Paolo

[Eve]

"Why would a setting for rendering attributes in the GUI affect XML output"?

Where does it say that the option is only for rendering? It is for everywhere that an object is loaded with features, and therefore it impacts everywhere that serializes those features from an object.

[Paolo F Cantoni]

"Why would a setting for rendering attributes in the GUI affect XML output"?

Where does it say that the option is only for rendering? It is for everywhere that an object is loaded with features, and therefore it impacts everywhere that serializes those features from an object.

From the Help:
Select the checkbox to list element features of each type alphabetically. Features include attributes, operations, tags, constraints and Test Cases.
Deselect the checkbox to list the features in the order in which they are defined (if not alphabetical) in the corresponding dialog or window for the feature.
To observe the effects of selecting or deselecting the checkbox, you must close the diagram and reload it.

The clear (to me) implication is that it is related to visual rendering (only).  Besides, in the case of XML, if an order can be specified, then the XSD will specify the order and it will be constant.  I'm not complaining about the order, just that it changes for a reason that is spurious.  In addition, in the XML, they aren't attributes of an element, but properties of an "apply type".  They're implemented in the GUI as attributes of an element, but conceptually they are something else.

By the way, I've just noticed that the setting is machine-dependent, not repository-dependent.  That sounds questionable to me in the first place...  (and if it was repository-dependent there wouldn't be a problem).

We can (again) agree to differ.

Paolo