You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by sb...@apache.org on 2002/02/24 12:51:39 UTC
cvs commit: jakarta-turbine-maven/xdocs metrics.xml
sbailliez 02/02/24 03:51:39
Added: xdocs metrics.xml
Log:
A description of metrics for further references. This is roughly what it would
be interesting to see in a metrics reports.
Revision Changes Path
1.1 jakarta-turbine-maven/xdocs/metrics.xml
Index: metrics.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<author email="sbailliez@apache.org">Stephane Bailliez</author>
<title>Metrics</title>
</properties>
<body>
<section name="Metrics">
<p>
This document tries to collect information required to compute some metrics that
are of interest in a design.
</p>
<p>
Most of it has been blatently copied from the <a href="http://www.webgain.com">WebGain</a>
QA manual and from Robert C. Martin article :
<a href="http://www.objectmentor.com/resources/articles/oodmetrc.pdf">Object Oriented Design Quality Metric - An Analysis</a>
</p>
<a href="#V(G)">V(G)</a> |
<a href="#LOC">LOC</a> |
<a href="#DIT">DIT</a> |
<a href="#NOA">NOA</a> |
<a href="#NRM">NRM</a> |
<a href="#NLM">NLM</a> |
<a href="#WMC">WMC</a> |
<a href="#RFC">RFC</a> |
<a href="#DAC">DAC</a> |
<a href="#FANOUT">FANOUT</a> |
<a href="#CBO">CBO</a> |
<a href="#LCOM">LCOM</a> |
<a href="#NOC">NOC</a>
<a href="#A">A</a>
<a href="#Ca">Ca</a>
<a href="#Ce">Ce</a>
<a href="#I">I</a>
<a href="#Dn">Dn</a>
</section>
<a name="V(G)"/>
<h3>Cyclomatic Complexity - V(G)</h3>
This metric was introduced in the 1970s to measure the amount of control
flow complexity or branching complexity in a module such as a
subroutine. It gives the number of paths that may be taken through the
code, and was initially developed to give some measure of the cost of
producing a test case for the module by executing each path.
<p/>
Methods with a high cyclomatic complexity tend to be more difficult to
understand and maintain. In general the more complex the methods of an
application, the more difficult it will be to test it, and this will adversely
affect its reliability.
<p/>
V(G) is a measure of the control flow complexity of a method or
constructor. It counts the number of branches in the body of the method,
defined as:
<ul>
<li>while statements;</li>
<li>if statements;</li>
<li>for statements.</li>
<li>What about ternary operators and and/or ?</li>
</ul>
This metric should be be able to computed in two different ways:
<ul>
<li>MCC (considering case): each function has a base complexity of 1, each if/do/while
adds 1 and each switch adds (n-1) where n is the number of branches in the switch statement.
</li>
<li>MCN (not considering case): each function has a base complexity of 1, each
if/do/while adds 1 and each switch adds 2.
</li>
</ul>
A number of 10 is usually admitted as a maximum value in normal conditions.
<a name="LOC"/>
<h3>Lines of Code - LOC</h3>
This is perhaps the simplest of all the metrics to define and compute.
Counting lines has a long history as a software metric dating from before
the rise of structured programming, and it is still in widespread use today.
The size of a method affects the ease with which it can be understood, its
reusability and its maintainability. There are a variety of ways that the size
can be calculated. These include counting all the lines of code, the number
of statements, the blank lines of code, the lines of commentary, and the
lines consisting only of syntax such as block delimiters.
<p/>
This metric can also be used for sizing other constructs as well, for
example, the overall size of a Java class or package can be measured by
counting the number of source lines it consists of.
<p/>
LOC can be used to determine the size of a compilation unit (source file),
class or interface, method, constructor, or field. It should be able to be
configured to ignore:
<ul>
<li>blank lines;</li>
<li>lines consisting only of comments;</li>
<li>lines consisting only of JavaDoc</li>
<li>lines consisting only of a header portion (regexp ?)</li>
<li>lines consisting only of opening and closing braces.</li>
</ul>
A number of 1000 is usually admitted as a maximum in a class/file.
<a name="DIT"/>
<h3>Depth of Inheritance Hierarchy - DIT</h3>
This metric calculates how far down the inheritance hierarchy a class is
declared. In Java all classes have java.lang.Object as their ultimate
superclass, which is defined to have a depth of 1. So a class that
immediately extends java.lang.Object has a metric value of 2; any of its
subclasses will have a value of 3, and so on.
<p/>
A class that is deep within the tree inherits more methods and state
variables, thereby increasing its complexity and making it difficult to
predict its behavior. It can be harder to understand a system with many
inheritance layers.
<p/>
DIT is defined for classes and interfaces:
<ul>
<li>all interface types have a depth of 1;</li>
<li>the class java.lang.Object has a depth of 1;</li>
<li>all other classes have a depth of 1 + the depth of their super class.</li>
</ul>
<a name="NOA"/>
<h3>Number of Attributes - NOA</h3>
The number of distinct state variables in a class serves as one measure of
its complexity. The more state a class represents the more difficult it is to
maintain invariants for it. It also hinders comprehensibility and reuse.
<p/>
In Java, state can be exposed to subclasses through protected fields, which
entails that the subclass also be aware of and maintain any invariants. This
interference with the class's data encapsulation can be a source of defects
and hidden dependencies between the state variables.
<p/>
NOA is defined for classes and interfaces. It counts the number of fields
declared in the class or interface.
<a name="NRM"/>
<h3>Number of Remote Methods - NRM</h3>
NRM is defined for classes. A remote method call is defined as an
invocation of a method that is not declared in any of:
<ul>
<li>the class itself;</li>
<li>a class or interface that the class extends or implements;</li>
<li>a class or method that extends the class.</li>
</ul>
The value is the count of all the remote method calls in all of the methods
and constructors of the class.
<a name="NLM"/>
<h3>Number of Local Methods - NLM</h3>
NLM is defined for classes and interfaces. A local method is defined as a
method that is declared in the class or interface. NLM can be configured to
include the local methods of all of the class's superclasses. Methods with
public, protected, package and private visibility can be independently
counted by setting configuration parameters.
<a name="WMC"/>
<h3>Weighted Methods per Class - WMC</h3>
If the number of methods in a class can be determined during the design
and modeling phase of a project, it can be used as a predictor of how
much time and effort is needed to develop, debug and maintain it. This
metric can be further refined by incorporating a weighting for the
complexity of each method. The usual weighting is given by the cyclomatic
complexity of the method.
<p/>
The subclasses of a class inherit all of its public and protected methods,
and possibly its package methods as well, so the number of methods a
class has directly impacts the complexity of its subclasses. Classes with
large numbers of methods are often specific to a particular application,
reducing the ability to reuse them.
<p/>
The definition of WMC is based upon NLM, and it provides the same
configuration parameters for counting inherited methods and of varying
visibility. The main difference is that NLM always counts each method as 1,
whereas WMC will weight each method. There are two weighting schemes:
<ul>
<li>V(G) the cyclomatic complexity of the method is used as its weight.
Methods from class files are given a V(G) of 1.</li>
<li>the arity, or the number of parameters of the method are used to
determine the weight.</li>
</ul>
<a name="RFC"/>
<h3>Response For Class - RFC</h3>
The response set of a class is the set of all methods that can be invoked as
a result of a message sent to an object of the class. This includes methods
in the class's inheritance hierarchy and methods that can be invoked on
other objects. The Response For Class metric is defined to be size of the
response set for the class. A class which provides a larger response set is
considered to be more complex than one with a smaller response set.
<p/>
One reason for this is that if a method call on a class can result in a large
number of different method calls on the target and other classes, then it
can be harder to test the behavior of the class and debug problems. It will
typically require a deeper understanding of the potential interactions that
objects of the class can have with the rest of the system.
<p/>
RFC is defined as the sum of NLM and NRM for the class. The local methods
include all of the public, protected, package and private methods, but not
methods declared only in a superclass.
<a name="DAC"/>
<h3>Data Abstraction Coupling - DAC</h3>
DAC is defined for classes and interfaces. It counts the number of reference
types that are used in the field declarations of the class or interface. The
component types of arrays are also counted. Any field with a type that is
either a supertype or a subtype of the class is not counted.
<a name="FANOUT"/>
<h3>Fan Out - FANOUT</h3>
FANOUT is defined for classes and interfaces, constructors and methods. It
counts the number of reference types that are used in:
<ul>
<li>field declarations;</li>
<li>formal parameters and return types;</li>
<li>throws declarations;</li>
<li>local variables.</li>
</ul>
The component types of arrays are also counted. Any type that is either a
supertype or a subtype of the class is not counted.
<a name="CBO"/>
<h3>Coupling Between Objects - CBO</h3>
When one object or class uses another object or class they are said to be
coupled. One major source of coupling is that between a superclass and a
subclass. A coupling is also introduced when a method or field in another
class is accessed, or when an object of another class is passed into or out
of a method invocation. Coupling Between Objects is a measure of the
non-inheritance coupling between two objects.
<p/>
A high value of coupling reduces the modularity of the class and makes
reuse more difficult. The more independent a class is the more likely it is
that it will be possible to reuse it in another part of the system. When a
class is coupled to another class it becomes sensitive to changes in that
class, thereby making maintenance for difficult. In addition, a class that is
overly dependent on other classes can be difficult to understand and test in
isolation.
<p/>
CBO is defined for classes and interfaces, constructors and methods. It
counts the number of reference types that are used in:
<ul>
<li>field declarations</li>
<li>formal parameters and return types</li>
<li>throws declarations</li>
<li>local variables</li>
</ul>
It also counts:
<ul>
<li>types from which field and method selections are made</li>
</ul>
The component types of arrays are also counted. Any type that is either a
supertype or a subtype of the class is not counted.
<a name="LCOM"/>
<h3>Lack of Cohesion Of Methods - LCOM</h3>
The cohesion of a class is the degree to which its methods are related to
each other. It is determined by examining the pattern of state variable
accesses within the set of methods. If all the methods access the same state
variables then they have high cohesion; if they access disjoint sets of
variables then the cohesion is low. An extreme example of low cohesion
would be if none of the methods accessed any of the state variables.
If a class exhibits low method cohesion it indicates that the design of the
class has probably been partitioned incorrectly, and could benefit by being
split into more classes with individually higher cohesion. On the other
hand, a high value of cohesion (a low lack of cohesion) implies that the
class is well designed. A cohesive class will tend to provide a high degree
of encapsulation, whereas a lack of cohesion decreases encapsulation and
increases complexity.
<p/>
Another form of cohesion that is useful for Java programs is cohesion
between nested and enclosing classes. A nested class that has very low
cohesion with its enclosing class would probably better designed as a peer
class rather than a nested class.
<p/>
LCOM is defined for classes. Operationally, LCOM takes each pair of
methods in the class and determines the set of fields they each access. If
they have disjoint sets of field accesses increase the count P by one. If they
share at least one field access then increase Q by one. After considering
each pair of methods,
LCOM = (P > Q) ? (P - Q) : 0
<p/>
Indirect access to fields via local methods can be considered by setting a
metric configuration parameter.
<a name="NOC"/>
<h3>Number Of Classes - NOC</h3>
The overall size of the system can be estimated by calculating the number
of classes it contains. A large system with more classes is more complex
than a smaller one because the number of potential interactions between
objects is higher. This reduces the comprehensibility of the system which
in turn makes it harder to test, debug and maintain.
<p/>
If the number of classes in the system can be projected during the initial
design phase of the project it can serve as a base for estimating the total
effort and cost of developing, debugging and maintaining the system.
<p/>
The NOC metric can also usefully be applied at the package and class level
as well as the total system.
<p/>
NOCL is defined for class and interfaces. It counts the number of classes or
interfaces that are declared. This is usually 1, but nested class declarations
will increase this number.
<a name="A"/>
<h3>Abstractness - A</h3>
A = abstract classes % total number of classes
<p/>
This metric range is [0,1]. 0 means concrete and 1 means completely abstract.
<a name="Ca"/>
<h3>Afferent Couplings - Ca</h3>
Number of classes outside a category that depend upon classes
within this category.
<a name="Ce"/>
<h3>Efferent Couplings - Ce</h3>
Number of classes inside this category that depend upon classes
outside this category
<a name="I"/>
<h3>Instability - I</h3>
I = Ce / (Ca + Ce): this metrics has the range [0,1], 0 indicates
a maximally stable category, 1 indicates a maximally instable
category.
<a name="Dn"/>
<h3>Normalized distance from the main sequence - Dn</h3>
Dn = | A + I - 1) |
The perpendicular distance of a category from the main sequence.
This metrics ranges from [0,1]. Any category that is not near zero
can be reexamined and restructured in order to define ones that are
more reusable and less sensitive to changes.
</body>
</document>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>