I have just released an updated set of project files for UML and SysML. The update resolves a problem when parsing XMI files that conform to the rules of Canonical XMI.

Canonical XMI

The XML document production rules of the XMI 2.x standards leave tool developers quite a few options how an object model can be serialized to XML. There are various ways to identify objects, represent object ownership, encode object properties, determine the order of elements, and so forth.

If you run one and the same UML model through several different XMI exporter implementations, the resulting XMI files are likely to be very different, despite them representing the exact same UML model. Yet, a good XMI importer should be able to deal with all these variations and reconstruct the original model from any of those XMI files.

Canonical XMI (see Appendix B of the XMI 2.5 specification) restricts the choices of the XML production rules, and defines a precise order in which elements and properties must be serialized. Thus, the output files of different Canonical XMI exporter implementations exporting the same model should have identical XML element structures and only differ in minor ways such as the chosen XMI UUIDs. If you can restrict yourself to Canonical XMI, XMI import then becomes a much simpler task.

Source of the problem

SDMetrics’ problem with Canonical XMI concerns the serialization of properties that hold a simple data value (primitive type or enumeration). Consider, for example, properties “name” and “visibility” of operations. Practically every existing XMI 2.x exporter uses XML attributes to serialize such properties, like so:

<uml:Operation xmi:id="op1" xmi:type="uml:Operation" xmi:uuid="DCE:1234" 
               name="op1" visibility="public" />

This is also how SDMetrics expects such properties to be serialized. But the full XMI specification allows for an alternative serialization, using nested XML elements:

<uml:Operation xmi:id="op1" xmi:uuid="DCE:1234" xmi:type="uml:Operation">
  <name>op1</name>
  <visibility>public</visibility>
</uml:Operation>

In Canonical XMI, only this latter option is admissible. Using XML attributes for simple data properties is no longer allowed. This choice seems a bit curious, since it runs against one of the overall goals of XMI 2 to produce smaller and better human readable files. The rationale behind this decision probably involves the consideration of multi-valued data properties. Nested XML elements are better suited to serialize multi-valued data properties, because you can have an arbitrary number of nested XML elements with the same tag name, but you cannot have two or more XML attributes with the same name.

SDMetrics’ XMI import currently does not support the second option with nested XML elements. Hence, if you parse a file that uses nested XML elements for simple data properties, SDMetrics will not pick up the property values.

Solution

Fortunately, this problem is easy to fix. We just need to modify the XMI transformation file to also read the property values from nested XML elements:

<xmitransformation modelelement="operation" xmipattern="uml:Operation" recurse="true">
<trigger name="name" type="attrval" attr="name" />
<trigger name="name" type="ctext" src="name" />
<trigger name="visibility" type="attrval" attr="visibility" />
<trigger name="visibility" type="ctext" src="visibility" />
...
</xmitransformation>

In the download section, you will find updated project file sets for the UML and SysML that contain all the necessary modifications, and instructions how to add them to your SDMetrics installation.