8.3 Definition of Design Rules

The SDMetricsML defines a design rule with an XML element like follows:

<rule name="rulename" domain="ruledomain"
      category="rulecategory" severity="ruleseverity" 
      applies_to="ruleapplication" disabled="false|true" 
      inheritable="true/false" > 
  <description>Description of the rule.</description>
  <'rule definition'" />
</rule>

• name (required). The name of the rule, used to identify the rule in the output.
• domain (required). The element type for which the rule is defined.
• category (optional). The name of the category to which this rule belongs, e.g., "Incomplete Design", "Naming", "Modularity", etc.
  Note that there is no preconceived categorization of design rules to adhere to in SDMetrics - you can define any categories you deem fit.
• severity (optional). The severity of the rule indicates how critical a violation of the rule is, e.g., "very severe", "moderate", etc.
  Again, there is no preconceived severity scale in SDMetrics, you can define any severity levels you like. However, you should consider that users will sort the list of reported rule violations by the severity of rules. The sorting is done lexicographically. Therefore, you should define the severity levels in a manner that they can be meaningfully sorted. For example, instead of "high", "medium", "low", define the levels as "1-high", "2-med", "3-low" to preserve the scale when sorting.
• applies_to (optional). Defines when the rule is applicable. For instance, some rules may only be useful at a particular design phase (requirements, analysis, design), or for a particular type of system (say, real time systems). The user can then decide to only check rules that are applicable to the model at hand, and ignore the remainder of the rules (see Section 4.7.1 "Filtering Design Rules").
  To use this feature, you first identify the application areas you wish to distinguish, and define a label for each area. The label must be a sequence of characters, without whitespaces and punctuation, for example "analysis", "design", or "realtime". Once more, there is no preconceived set of application areas, you can define whatever areas you find useful.
  Once you have identified your application areas and their labels, specify for each rule the label(s) of the area(s) to which the rule applies. If several areas apply, separate the labels with commas. For example applies_to="design" or applies_to="analysis,realtime".
  If you do not specify the applies_to attribute for a rule, SDMetrics will consider the rule to be applicable to all application areas.
• disabled (optional). With this attribute you can disable a rule. The attribute takes values true (rule will not be checked), or false (the default, rule will be checked).
• inheritable (optional). Indicates if the rule should also apply to subtypes of the "domain" element type. When you set the attribute value to "true", all direct and indirect subtypes of the domain "inherit" the rule definition, and the rule will be checked for all subtypes, too. When omitted or set to "false", the rule definition is not passed on to subtypes.

Following the rule description is an XML element that defines the check the rule performs. There are a number of procedures to choose from:

• violation - rules defining a condition expression that must not be violated.
• cycle - rules that check for the presence of cycles in a directed graph.
• projection - rules that report elements in a projection.
• valueset - rules that reports values occurring in a value set.