A recurring quality issue of UML class diagrams concerns the multiplicity on association ends. Modelers can get the multiplicity wrong, or forget to specify it at all. In his book “Elements of UML 2.0 style”, Scott Ambler suggests to always indicate the multiplicity of associations on all ends, even in apparently obvious cases. This demonstrates that the modeler has considered the multiplicity.

To detect an incorrect multiplicity in general requires a semantic analysis of the associated classes. But spotting a missing multiplicity is a simple syntactical check that is easily automated. In the following, we’ll add a design rule to SDMetrics that checks that the multiplicity is defined for all association ends in a UML2 model.

Multiplicity of association ends in UML 2

In the UML2 meta model, association ends are UML properties owned or referenced by the association. Meta class “Property” extends meta class “MultiplicityElement”, which defines two optional associations “lowerValue” and “upperValue” with value specifications for the lower and upper bounds, respectively. Serialized to XMI, an association end with 1..* multiplicity looks like this:

<packagedElement xmi:type="uml:Association" xmi:id="1" name="xyz" memberEnd="2 3">
  <ownedEnd xmi:type="uml:Property" xmi:id="2" name="abc" type="5" association="1">
    <lowerValue xmi:type="uml:LiteralInteger" xmi:id="7" value="1"/>
    <upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="6" value="*"/>
  </ownedEnd>
</packagedElement>

In order to check the multiplicity, we need to collect the value specifications owned by the UML Property via the “lowerValue” and “upperValue” associations. As it happens, none of the rules and metrics that SDMetrics calculates “out of the box” deal with multiplicity yet. Therefore, SDMetrics ignores multiplicity information when parsing XMI files. So we have a bit more work ahead of us, namely:

• Extend SDMetrics’ meta model to account for multiplicity on association ends.
• Tell SDMetrics how to extract the multiplicity information from an XMI file.
• Define a design rule that does the actual checking.

For this we’ll need a running installation of SDMetrics set up for customized project files, a text editor, and a few lines of XML code.

Extending the SDMetrics meta model

To store the multiplicity information with properties, we add two reference attributes to the “property” model element. In SDMetrics’ meta model definition file for UML2, metamodel2.xml, locate the definition of element type “property”, and add the lines shown in boldface:

<modelelement name="property">
... [previously defined attributes of "property", not shown here]
  <attribute name="upperbound" type="ref">Upper bound of the multiplicity.</attribute>
  <attribute name="lowerbound" type="ref">Lower bound of the multiplicity.</attribute>
</modelelement>

Our simplified meta model for SDMetrics defines the multiplicity attributes for properties directly in the “property” meta class, rather than inheriting them from a base class. For our purposes, it is OK to take such liberties with the standard UML2 meta model.

Adding the XMI transformation

Next, we need to tell SDMetrics how to extract the values for the “upperbound” and “lowerbound” attributes in the XMI file. In SDMetrics’ XMI transformation file “xmiTrans2_0.xml” for UML2/XMI2.x, locate the XMI transformations for “uml:Property”, and add the two XMI triggers shown in boldface:

<xmitransformation modelelement="property" xmipattern="uml:Property" recurse="true">
... [previously defined triggers for "uml:Property", not shown here]
   <trigger name="upperbound" type="xmi2assoc" attr="upperValue" />
   <trigger name="lowerbound" type="xmi2assoc" attr="lowerValue" />
</xmitransformation>

This instructs the XMI parser that the “upperbound” and “lowerbound” attributes we just defined should be mapped to the “upperValue” and “lowerValue” associations of the standard UML2 meta model.

Defining the rule

Now we have everything in place to create the new rule. Add the following definition to the metrics definition file “metrics2.xml” for UML2:

<rule name="MissingMultiplicity" domain="property" 
  category="Completeness" severity="2-med" applies_to="design">
<description>The association end does not specify upper and lower bounds.</description>
<violation condition=
   "association!='' and (upperbound='' or lowerbound='')" />
</rule>

The rule reports a violation if a property is an association end (association!=”), and the upper or lower bound for the rule is not specified (upperbound=” or lowerbound=”). Comparison against the empty string is SDMetrics’ way of testing if a reference is “null”.

Depending on your usage of the UML, you may want to play around with this definition a little bit. For instance, you could extend the rule to apply to all properties, not only association ends (just drop the association!=” condition). Or you could exempt association ends on actors and/or use cases (add the predicate … and type(propertytype)!=’actor’ to the condition). Or only require that at least one of the bounds (upper or lower) must be specified. Or change the severity of the rule. Or combinations of the above.