SDMetrics home page
The Software Design Metrics tool for the UML
Sitemap

Overview of the New Features in SDMetrics V2.3

April 9, 2012, Jürgen Wüst. Category: Announcements

SDMetrics V2.3 was released recently. We have already discussed the improved support for UML2 profile extensions in an earlier post. In this post, we take a closer look at the other new features of SDMetrics V2.3.

1. Custom functions in metric, set, condition expressions

The metrics engine of SDMetrics can now be extended with new, custom functions in metric expressions. For example, assume we want SDMetrics to automatically check that names of read-only attributes of classes must be all uppercase. Out of the box, SDMetrics does not have a function to check whether a name is all uppercase. So we implement a new function with a few lines of Java code:

public class IsUpperCaseFunction extends BooleanOperation {
 @Override
  public boolean calculateValue(ModelElement element,
    ExpressionNode node, Variables vars) {
      Object argValue = evalExpression(element, node.getOperand(0), vars);
      String s = argValue.toString();
      return s.equals(s.toUpperCase());
    }
  }
}

We can then declare the new function in the metric definition file, and use it to define the new rule for read-only attributes:

<booleanoperationdefinition name="isuppercase" 
	class="com.acme.IsUpperCaseFunction" />

<rule name="Capitalization" domain="property">
<violation condition="!isuppercase(name) and isreadonly='true'" />
</rule>

The metric expression parser now supports parameter lists for function calls. Functions are no longer restricted to a single argument, but can take any number of comma-separated arguments, if needed.

2. Updated meta-model for UML 2.4.1

There were some non-trivial changes to the UML meta-model in UML 2.4.1:

  • Occurrence specifications are no longer associated with an event.
  • DestructionOccurrenceSpecifications were newly introduced.
  • A new literal specification “LiteralReal” was introduced.

SDMetrics’ UML2 meta-model and XMI import accounts for these changes.

3. Simplified import of project file sets

It is now much easier to import project files sets from the SDMetrics download section into SDMetrics. Simply click the new “Import…”-button in the project file sets dialog, and select the zip file you downloaded.

4. XMI 2.x parser extracts sub-elements of model elements even if there is no “xmi2assoc” trigger

To illustrate this new feature, consider the following excerpt of an XMI 2.x file. It shows the serialization of a state with an invariant in a state machine.

<subvertex xmi:type='uml:State' xmi:id='1346' name='State 1'>
  <stateInvariant xmi:type='uml:Constraint' xmi:id='1428'>
    ...
  </stateInvariant>
</subvertex>

Older versions of the SDMetrics XMI parser do not extract the constraint element unless the XMI transformations for “state” define an “xmi2assoc” trigger for the “stateInvariant” composition association, like so:

<xmitransformation modelelement="state" xmipattern="uml:State" recurse="true">
  <trigger name="invariants" type="xmi2assoc" attr="stateInvariant"/>
...
</xmitransformation>

As of version 2.3, the XMI parser extracts such sub-elements even if there is no “xmi2assoc” trigger defined for the composition association. The xmi:type attribute must be present for the sub-element. Of course, without the “xmi2assoc” trigger we lose the information by which composition association the sub-element is owned.

5. Increased robustness when the installation directory is moved

In older versions of SDMetrics, users had to restore the paths to the default project file sets if they moved the SDMetrics installation directory. As of version 2.3, you no longer need to restore the file paths, SDMetrics will find its default project files anyway.