You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by ka...@apache.org on 2002/02/26 00:15:55 UTC
cvs commit: jakarta-turbine-maven/xdocs project.xml metrics.xml
kaz 02/02/25 15:15:55
Modified: xdocs project.xml metrics.xml
Log:
- Reformatted the Metrics document (was not rendering properly) to an
xdoc.
- Added link to the maven navbar.
Revision Changes Path
1.13 +1 -0 jakarta-turbine-maven/xdocs/project.xml
Index: project.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine-maven/xdocs/project.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- project.xml 25 Feb 2002 15:45:00 -0000 1.12
+++ project.xml 25 Feb 2002 23:15:55 -0000 1.13
@@ -17,6 +17,7 @@
<item name="Build File" href="/build-file.html"/>
<item name="Directory Layout" href="/dirlayout.html"/>
<item name="JRCS" href="/jrcs.html"/>
+ <item name="Metrics" href="/metrics.html"/>
</menu>
<menu name="Development">
<item name="Building" href="/bootstrap.html"/>
1.3 +409 -345 jakarta-turbine-maven/xdocs/metrics.xml
Index: metrics.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine-maven/xdocs/metrics.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- metrics.xml 25 Feb 2002 20:43:58 -0000 1.2
+++ metrics.xml 25 Feb 2002 23:15:55 -0000 1.3
@@ -6,350 +6,414 @@
<title>Metrics</title>
</properties>
-<body>
+ <body>
-<section name="Metrics">
+ <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>.
- See also McCabe publication <a href="http://www.mccabe.com/nist/nist_pub.php">Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric</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>
\ No newline at end of file
+ <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>. See also
+ McCabe publication <a
+ href="http://www.mccabe.com/nist/nist_pub.php">Structured
+ Testing: A Testing Methodology Using the Cyclomatic Complexity
+ Metric</a>
+ </p>
+ <p>
+ <a href="#Cyclomatic Complexity - V(G)">V(G)</a> |
+ <a href="#Lines of Code - LOC">LOC</a> |
+ <a href="#Depth of Inheritance Hierarchy - DIT">DIT</a> |
+ <a href="#Number of Attributes - NOA">NOA</a> |
+ <a href="#Number of Remote Methods - NRM">NRM</a> |
+ <a href="#Number of Local Methods - NLM">NLM</a> |
+ <a href="#Weighted Methods per Class - WMC">WMC</a> |
+ <a href="#Response For Class - RFC">RFC</a> |
+ <a href="#Data Abstraction Coupling - DAC">DAC</a> |
+ <a href="#Fan Out - FANOUT">FANOUT</a> |
+ <a href="#Coupling Between Objects - CBO">CBO</a> |
+ <a href="#Lack of Cohesion Of Methods - LCOM">LCOM</a> |
+ <a href="#Number Of Classes - NOC">NOC</a>
+ <a href="#Abstractness - A">A</a>
+ <a href="#Afferent Couplings - Ca">Ca</a>
+ <a href="#Efferent Couplings - Ce">Ce</a>
+ <a href="#Instability - I">I</a>
+ <a href="#Normalized distance from the main sequence - Dn">Dn</a>
+ </p>
+ <subsection name="Cyclomatic Complexity - V(G)">
+ <p>
+ 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>
+ <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>
+ <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.
+ </p>
+ </subsection>
+ <subsection name="Lines of Code - LOC">
+ <p>
+ 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>
+ <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>
+ <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.
+ </p>
+ </subsection>
+ <subsection name="Depth of Inheritance Hierarchy - DIT">
+ <p>
+ 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>
+ <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>
+ <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>
+ </p>
+ </subsection>
+ <subsection name="Number of Attributes - NOA">
+ <p>
+ 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>
+ <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>
+ <p>
+ NOA is defined for classes and interfaces. It counts the
+ number of fields declared in the class or interface.
+ </p>
+ </subsection>
+ <subsection name="Number of Remote Methods - NRM">
+ <p>
+ 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.
+ </p>
+ </subsection>
+ <subsection name="Number of Local Methods - NLM">
+ <p>
+ 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.
+ </p>
+ </subsection>
+ <subsection name="Weighted Methods per Class - WMC">
+ <p>
+ 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>
+ <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>
+ <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>
+ </p>
+ </subsection>
+ <subsection name="Response For Class - RFC">
+ <p>
+ 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>
+ <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>
+ <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.
+ </p>
+ </subsection>
+ <subsection name="Data Abstraction Coupling - DAC">
+ <p>
+ 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.
+ </p>
+ </subsection>
+ <subsection name="Fan Out - FANOUT">
+ <p>
+ 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.
+ </p>
+ </subsection>
+ <subsection name="Coupling Between Objects - CBO">
+ <p>
+ 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>
+ <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>
+ <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.
+ </p>
+ </subsection>
+ <subsection name="Lack of Cohesion Of Methods - LCOM">
+ <p>
+ 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.
+ </p>
+ <p>
+ 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>
+ <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>
+ <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>
+ <p>
+ Indirect access to fields via local methods can be considered
+ by setting a metric configuration parameter.
+ </p>
+ </subsection>
+ <subsection name="Number Of Classes - NOC">
+ <p>
+ 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>
+ <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>
+ <p>
+ The NOC metric can also usefully be applied at the package and
+ class level as well as the total system.
+ </p>
+ <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.
+ </p>
+ </subsection>
+ <subsection name="Abstractness - A">
+ <p>
+ A = abstract classes % total number of classes
+ </p>
+ <p>
+ This metric range is [0,1]. 0 means concrete and 1 means
+ completely abstract.
+ </p>
+ </subsection>
+ <subsection name="Afferent Couplings - Ca">
+ <p>
+ Number of classes outside a category that depend upon classes
+ within this category.
+ </p>
+ </subsection>
+ <subsection name="Efferent Couplings - Ce">
+ <p>
+ Number of classes inside this category that depend upon
+ classes outside this category
+ </p>
+ </subsection>
+ <subsection name="Instability - I">
+ <p>
+ I = Ce / (Ca + Ce): this metrics has the range [0,1], 0
+ indicates a maximally stable category, 1 indicates a maximally
+ instable category.
+ </p>
+ </subsection>
+ <subsection name="Normalized distance from the main sequence - Dn">
+ <p>
+ 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.
+ </p>
+ </subsection>
+ </section>
+ </body>
+</document>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>