Contents > 8 Defining Custom Design Metrics and Rules > 8.3 Definition of Design Rules
8.3 Definition of Design Rules
SDMetrics' design rules and heuristics (see Section 4.7 "The View 'Rule Checker'") are
defined in the metric definition file, making it easy for you to
modify existing rules and add new rules of your own.
The SDMetricsML defines a design rule with an XML element like follows:
<rule name="rulename" domain="ruledomain"
<description>Description of the rule.</description>
<'rule definition'" />
The attributes of the enclosing "rule" tag are:
Next is an optional description of the rule, enclosed in
description tags. The description will be shown in the
measurement catalog (see Section 4.13 "The View 'Catalog'").
Section 8.6 "Writing Descriptions" explains how to write rule descriptions.
- 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
- category (optional). The name of the category to which
this rule belongs, e.g., "Incomplete Design", "Naming", "Modularity",
Note that there is no preconceived categorization of design rules to
adhere to in SDMetrics - you can define any categories you deem
- severity (optional). The severity of the rule indicates
how critical a violation of the rule is, e.g., "very severe",
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
- 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
If you do not specify the applies_to attribute for a rule,
SDMetrics will consider the rule to be applicable to all application
- 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
- violation - rules defining a condition expression that
must not be violated.
- cycle - rules that check for the presence of cycles in a
- projection - rules that report elements in a projection.
- valueset - rules that reports values occurring in a value
8.3.3 Projection for Rules
8.3.4 Valueset for Rules
8.3.5 Word lists
8.3.6 Exempting Approved Rule Violations