Usage of the UML varies greatly among software organizations, in the level of detail the UML is applied, the types of diagrams that are created, the rigor with which the UML is applied, and the ways in which the extension mechanisms of the UML are used.

SDMetrics enables you to measure almost any design aspect which you think is important in the way you use the UML in your development processes. With SDMetrics, you can define your own design rules and metrics, tailored to your design practices!

SDMetrics reads the definitions of its metrics and design rules from an XML-based configuration file. You can download several metric definition files from the Project Files Page, or write your own metric definitions.

Definition of metrics

The following is an example of a simple metric that counts the number of public operations in a class:

<metric name="NumPubOps" domain="class" category="Size">
 <description>
  The number of public operations in a class.
 </description>
 <projection relset="ownedoperations"
  condition="visibility='public'"/>
</metric>

There are nine more calculation procedures to define metrics besides <projection>. Section 8.1 of the SDMetrics user manual describes these in detail.

Definition of sets

You can define intermediate "helper" sets, and use them as building blocks for more complex metrics and rules. For example, we can define for an interface the set of outgoing associations like so:

<set name="AssocOut" domain="interface">
 <description> The set of associations with navigability
  away from the interface.
 </description>
 <projection relset="ownedattributes" condition="association!=''"
  element="association" />
</set>

Definition of rules

Definitions of rules are similar to definitions of metrics: there is a description and a calculation procedure how to evaluate the rule. The following example checks interfaces for outgoing associations:

<rule name="OutgoingAssoc" domain="interface" severity="low"
 category="Style" >
 <description>
  The interface has outgoing associations.
 </description>
 <violation condition="size(AssocOut)!=0"
  value="'#Assoc: '+size(AssocOut)" />
</rule>

Some rules return a value providing details about how the element violates the rule. In the example, the rule returns a string with the number of outgoing associations the interface participates in. Section 8.3 of the SDMetrics user manual describes in detail how to define your own rules.

Why not use OCL for the definition of rules?
OCL as part of the UML standard is naturally suited to define design rules. The well-formedness rules of the UML are mostly expressed in OCL. SDMetrics does not use OCL for performance reasons. SDMetrics' design rule definitions are prescriptive, which allows for more efficient checks than OCL's declarative nature. For example, rules involving the detection of cycles in dependency graphs use a computationally optimal algorithm that could not be expressed in OCL.