Contents > 7 SDMetrics Metamodel and XMI Transformation Files
7 SDMetrics Metamodel and XMI Transformation Files
To define and calculate design metrics, SDMetrics needs to know what types
of design elements are present in a UML design, and what are their
interrelationships. The UML, standardized by the Object Management
Group (OMG), has a well-defined metamodel, based on the Meta Object
Facility (MOF™), also a standard of the OMG.
XMI (the XML Metadata Interchange format), yet another standard of the
OMG, is a mechanism to create a textual (XML) representation of
models based on the MOF, such as the UML. XMI defines a
set of production rules that prescribe how to serialize the elements
of a model to XML, and how to generate a DTD or schema for the XML
files thus generated. However, this standard is not immediately
suitable for the definition of design metrics for a number of reasons:
SDMetrics therefore uses a reduced and simplified 'metamodel for the
UML'. This metamodel defines the UML elements that SDMetrics knows
about, and contains all the relevant information to calculate
metrics. This simplified metamodel also abstracts from the various
versions of the XMI that are used to represent UML designs. To support
a specific version of the XMI, we need to define a mapping of
SDMetrics metamodel elements onto the XMI elements for the given
version of the XMI. SDMetrics stores these mappings in "XMI
- Different versions of the XMI exist, which yield different
representations of UML models. At the time of this writing, XMI
versions 1.2, 2.0, and 2.1 are widely used, and XMI 1.0 and 1.1
are still around, too, though less frequently used.
- The XMI DTDs or schemas for UML are huge (e.g., the XMI 1.2 DTD
for UML1.4 has over 110 pages), which is too unwieldy for the purpose
of defining metrics.
- In practice, tool vendors do not always fully adhere to the UML
and XMI standards, they often deviate in minor (and sometimes not so
minor) ways. This is one cause why, in practice, tool interoperability
via XMI exchange does not always work as intended.
When would I need to worry about all this?
Knowledge of the SDMetrics metamodel is needed if you want to define
new metrics or rules of your own (see Section 8 "Defining Custom Design Metrics and Rules"). The metric and
rule definitions make copious references to the elements and
relationships defined in the metamodel.
In addition, knowledge of XMI transformation files is needed if
- an XMI exporter you use does not fully comply with the XMI
standard or official UML metamodels, and you need to modify the XMI
transformations files to account for this,
- you want to define new metrics that take proprietary and/or
tool-specific XMI extensions into account. For instance, the
representation of UML diagram layout information is not standardized
in UML 1.x, and tool vendors usually define proprietary extensions
to store this information. You can extend the SDMetrics metamodel and
modify the XMI transformation files for such XMI extensions, and
define metrics for them.
(Note: since XMI is not limited to the representation of UML models,
but any models based on the MOF, it is possible to write SDMetrics
metamodels and XMI transformation files for other MOF-based
metamodels, and define metrics to perform measurements on these
7.1 SDMetrics Metamodel
7.2 XMI Transformation Files