SDMetrics - the UML design quality metrics tool

The Software Design Metrics tool for the UML

Home \| Features \| Downloads \| Order \| Support \| Resources \| About
- Overview - Screenshots - List of Metrics - List of Design Rules - Custom XMI Import - Custom Metrics and Rules - Revision History	XMI (XML Metadata Interchange) is an OMG standard to generate XML-based representations of UML and other OO data models. It provides a vendor-neutral format to store and exchange models between UML tools. Most UML modeling tools support XMI. In practice, however, exchanging models between tools via XMI is difficult for a number of reasons: Different versions of the XMI exist (1.0, 1.1, 1.2, 2.0, 2.1). Tools often support only a few of them. Some tools use proprietary extensions of the UML metamodel, or the XMI exporter generates XML code that is not fully compliant with the standards. In either case, the XMI file will not be understood by other tools. This is especially true for diagram layout information - diagrams often are lost in the process. The usual approach to XMI import/export is to autogenerate code (e.g. Java or C++ classes) from a DTD or XSD schema to read and write XMI files. But because there are so many 'flavors' of the XMI for UML, SDMetrics takes a different approach. SDMetrics' XMI import is controlled by two XML-based configuration files: Metamodel definition file - a simplified UML metamodel. XMI transformation file - defines how to extract information from the XMI file. For each metamodel, there can be several XMI transformation files, each for a different 'flavor' of the XMI. You can edit these files yourself, and exchange them at run-time. That way, SDMetrics' XMI import can be easily customized to account for proprietary UML metamodel extensions and non-standard XMI. Metamodel definition file The metamodel definition file defines the model elements that SDMetrics knows: what are the meta classes, their attributes and relationships. This simplified metamodel is defined as far as is needed for metric calculation and design rule checking. It is not a complete 1:1 representation of the standard UML meta models (though you can approximate them as close as you want). The following example shows the definition of a meta model element "class" for UML classes: <modelelement name="class"> <attribute name="visibility" type="data" multiplicity="one"/> <attribute name="abstract" type="data" multiplicity="one"/> <attribute name="ownedattributes" type="ref" multiplicity="many" /> <attribute name="ownedoperations" type="ref" multiplicity="many" /> ... </modelelement> This defines two data attributes to store the visibility and abstractness of the class, and two cross-reference attributes to store references to the attributes and operations owned by the class. Section 7.1 of the user manual describes in detail how to define meta models for SDMetrics. SDMetrics ships with default meta models for UML1.3/1.4 and UML2.0/2.1, see Appendix A of the user manual. XMI transformation file The XMI transformation file defines how to retrieve information of the model elements and attributes from XMI files. It provides a mapping from the UML meta model as manifested in the XMI file to SDMetrics' simplified meta model. The following is an excerpt from an XMI 2.0 file. It defines a public class "MyClass" with a private attribute "myAttr" and a public operation "myOperation": <ownedMember xmi:type='UML:Class' xmi:id='id345' visibility='public' isAbstract='false' name='MyClass'> <ownedAttribute xmi:id='id1138' name="myAttr" visibility='private' type='id42'/> <ownedOperation xmi:id='id1139' name='myOperation' visibility='public'> <ownedParameter xmi:id='1140' name='par1' type='id123' /> </ownedOperation> ... </ownedMember> The following XMI transformations extract the information for class visibility, abstractness, owned attributes and operations from the XMI file. Names in italics refer to SDMetrics' simplified metamodel. Bold names refer to the UML2.0 meta model and its XMI2.0 serialization <xmitransformation modelelement="class" xmipattern="UML:Class" recurse="true"> <trigger name="visibility" type="attrval" attr="visibility"/> <trigger name="abstract" type="attrval" attr="isAbstract"/> <trigger name="ownedattributes" type="xmi2assoc" src="UML:Property" attr="ownedAttribute" /> <trigger name="ownedoperations" type="xmi2assoc" src="UML:Operation" attr="ownedOperation" /> ... </xmitransformation> <xmitransformation modelelement="operation" xmipattern="UML:Operation" ... <xmitransformation modelelement="property" xmipattern="UML:Property" ... Section 7.2 of the user manual describes in detail how to define XMI transformations. The Project Files Download Page provides several XMI transformation files for the UML default metamodels and various modeling tools. XMI and SDMetrics' XMI parser technology are not limited to the exchange of UML models. You can define meta models for any application domains that use XMI to exchange data. The XMI parser can also be licensed separately. The API to access the parser and model data is available here. Why not use XSLT? Performance! Even though very simple XSL transformations are sufficient to extract the required information from XMI files, XSLT processors are not suitable to handle XMI files greater than a few megabytes.

XMI (XML Metadata Interchange) is an OMG standard to generate XML-based representations of UML and other OO data models. It provides a vendor-neutral format to store and exchange models between UML tools. Most UML modeling tools support XMI.

In practice, however, exchanging models between tools via XMI is difficult for a number of reasons:

Different versions of the XMI exist (1.0, 1.1, 1.2, 2.0, 2.1). Tools often support only a few of them.
Some tools use proprietary extensions of the UML metamodel, or the XMI exporter generates XML code that is not fully compliant with the standards. In either case, the XMI file will not be understood by other tools.
This is especially true for diagram layout information - diagrams often are lost in the process.

The usual approach to XMI import/export is to autogenerate code (e.g. Java or C++ classes) from a DTD or XSD schema to read and write XMI files. But because there are so many 'flavors' of the XMI for UML, SDMetrics takes a different approach.

SDMetrics' XMI import is controlled by two XML-based configuration files:

Metamodel definition file - a simplified UML metamodel.
XMI transformation file - defines how to extract information from the XMI file.

For each metamodel, there can be several XMI transformation files, each for a different 'flavor' of the XMI. You can edit these files yourself, and exchange them at run-time. That way, SDMetrics' XMI import can be easily customized to account for proprietary UML metamodel extensions and non-standard XMI.

Metamodel definition file

The metamodel definition file defines the model elements that SDMetrics knows: what are the meta classes, their attributes and relationships. This simplified metamodel is defined as far as is needed for metric calculation and design rule checking. It is not a complete 1:1 representation of the standard UML meta models (though you can approximate them as close as you want).

The following example shows the definition of a meta model element "class" for UML classes:

<modelelement name="class">
 <attribute name="visibility" type="data" multiplicity="one"/>
 <attribute name="abstract" type="data" multiplicity="one"/>
 <attribute name="ownedattributes" type="ref" multiplicity="many" />
 <attribute name="ownedoperations" type="ref" multiplicity="many" />
...
</modelelement>

This defines two data attributes to store the visibility and abstractness of the class, and two cross-reference attributes to store references to the attributes and operations owned by the class. Section 7.1 of the user manual describes in detail how to define meta models for SDMetrics.

SDMetrics ships with default meta models for UML1.3/1.4 and UML2.0/2.1, see Appendix A of the user manual.

XMI transformation file

The XMI transformation file defines how to retrieve information of the model elements and attributes from XMI files. It provides a mapping from the UML meta model as manifested in the XMI file to SDMetrics' simplified meta model.

The following is an excerpt from an XMI 2.0 file. It defines a public class "MyClass" with a private attribute "myAttr" and a public operation "myOperation":

<ownedMember xmi:type='UML:Class' xmi:id='id345' visibility='public'
 isAbstract='false' name='MyClass'>
 <ownedAttribute xmi:id='id1138' name="myAttr" visibility='private'
  type='id42'/>
 <ownedOperation xmi:id='id1139' name='myOperation' 
  visibility='public'>
  <ownedParameter xmi:id='1140' name='par1' type='id123' />
 </ownedOperation>
 ...
</ownedMember>

The following XMI transformations extract the information for class visibility, abstractness, owned attributes and operations from the XMI file. Names in italics refer to SDMetrics' simplified metamodel. Bold names refer to the UML2.0 meta model and its XMI2.0 serialization

<xmitransformation modelelement="class" xmipattern="UML:Class" 
 recurse="true">
 <trigger name="visibility" type="attrval" attr="visibility"/>
 <trigger name="abstract" type="attrval" attr="isAbstract"/>
 <trigger name="ownedattributes" type="xmi2assoc" 
  src="UML:Property" attr="ownedAttribute" />
 <trigger name="ownedoperations" type="xmi2assoc" 
  src="UML:Operation" attr="ownedOperation" />
 ...
</xmitransformation>
<xmitransformation modelelement="operation"
 xmipattern="UML:Operation"
  ...
<xmitransformation modelelement="property"
 xmipattern="UML:Property" 
 ...

Section 7.2 of the user manual describes in detail how to define XMI transformations. The Project Files Download Page provides several XMI transformation files for the UML default metamodels and various modeling tools.

XMI and SDMetrics' XMI parser technology are not limited to the exchange of UML models. You can define meta models for any application domains that use XMI to exchange data. The XMI parser can also be licensed separately. The API to access the parser and model data is available here.

Why not use XSLT?
Performance! Even though very simple XSL transformations are sufficient to extract the required information from XMI files, XSLT processors are not suitable to handle XMI files greater than a few megabytes.

Sitemap

webmaster@sdmetrics.com