Contents > 8 Defining Custom Design Metrics and Rules > 8.3 Definition of Design Rules > 8.3.2 Cycle

### 8.3.2 Cycle

The cycle procedure detects cycles in a directed graph. It does so by
calculating the strongly connected components of the graph. Within a
strongly connected component (SCC), there exists a path from each node
to every other node of the SCC, hence a cycle. A graph is acyclic if and
only if it has no SCCs.
You can use this procedure to check for cyclic dependencies between
model elements. For example, the following rule checks for cycles in
the inheritance graph for classes:

<rule name="CyclicInheritance" domain="class" category="Inheritance"
severity="1-high">
<description>Class inherits from itself!</description>
<cycle nodes="Parents" />
</rule>

The domain of the rule is "class", so the classes of the model
constitute the nodes of the graph. The required set expression
`nodes` yields, for each node, the set of connected nodes
to which there is an edge. In our example, set "Parents" is the set of
parents of the class.
To report the SCCs found, each model element in a SCC receives a label
of the form "cyc# c (n nodes)", where *c* is the number of the
SCC, and *n* is the number of nodes in the SCC.

The rule reports a violation for each model element in each SCC. The
value of the rule shown to the user is the label of the model
element. That way, users can tell which elements belong to which
connected component.

In some cases, you may only want to report SCCs of a certain size, for
instance, SCCs with three or more nodes. To this end, the cycle
procedure has a second, optional attribute `minnodes`, which
specifies the minimum number of nodes an SCC must have to be
reported. The default is 1 (nodes having an edge back to themselves).