You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by jv...@apache.org on 2002/02/26 08:41:05 UTC
cvs commit: jakarta-turbine-maven/xdocs metrics.xml project.xml
jvanzyl 02/02/25 23:41:05
Modified: xdocs metrics.xml project.xml
Log:
Adjusting the metrics definitions doc so that it renders correctly.
Revision Changes Path
1.4 +98 -407 jakarta-turbine-maven/xdocs/metrics.xml
Index: metrics.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine-maven/xdocs/metrics.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- metrics.xml 25 Feb 2002 23:15:55 -0000 1.3
+++ metrics.xml 26 Feb 2002 07:41:05 -0000 1.4
@@ -2,418 +2,109 @@
<document>
<properties>
- <author email="sbailliez@apache.org">Stephane Bailliez</author>
- <title>Metrics</title>
+ <author email="pete@kazmier.com">Pete Kazmier</author>
+ <author email="jason@zenplex.com">Jason van Zyl</author>
+ <title>Musings</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>
+ <section name="Musings">
<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>
+ The following is a list of things that are being contemplated
+ for Maven.
</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>
+ <ul>
+ <li>
+ figure out how to specify that aspects are required. i would like
+ to be able to make a huge reactor that the aspectj team can use to watch
+ the development of ajc.
+ </li>
+ <li>
+ possibly incorporate gretel, looks similiar to quilt.
+ http://www.cs.uoregon.edu/research/perpetual/dasada/Software/Gretel/
+ </li>
+ <li>
+ how to easily extend the build system for project specifics, we don't
+ want people editing the generated build system. has to be easy and clear.
+ </li>
+ <li>
+ have to figure out the structure for a jar repository and the naming
+ conventions.
+ </li>
+ <li>
+ encourage the use of a central repository of JARs -> ${lib.repo}
+ </li>
+ <li>
+ object model for a java project
+ </li>
+ <li>
+ the project is the unit of work for alexandria and that's
+ the idea we want to stress.
+ </li>
+ <li>
+ cvs log analyser
+ </li>
+ <li>
+ build tool
+ </li>
+ <li>
+ updater
+ </li>
+ <li>
+ cross referencer
+ </li>
+ <li>
+ source formatter
+ </li>
+ <li>
+ make something like webgain's Quality Analyser
+ </li>
+ <li>
+ audit
+ </li>
+ <li>
+ cover (david peugh's quilt)
+ </li>
+ <li>
+ indexing tool for javadocs. search the repositories for code
+ that might be useful.
+ </li>
+ <li>
+ graphs for cvs activity
+ </li>
+ <li>
+ source metrics
+ </li>
+ <li>
+ tool for taking patches
+ </li>
+ <li>
+ updating tool
+ </li>
+ <li>
+ installer help (webstart/jnlp)
+ </li>
+ <li>
+ integrate ceki's dir layout
+ </li>
+ <li>
+ integrate berin's build file
+ </li>
+ <li>
+ standard location for libs versus distributions
+ </li>
+ <li>
+ javadoc viewer
+ </li>
+ <li>
+ make the tools easily integrated into cvs
+ </li>
+ <li>
+ lxr finding all the source files that use a particular file
+ </li>
+ </ul>
</section>
</body>
</document>
+
+
1.14 +1 -1 jakarta-turbine-maven/xdocs/project.xml
Index: project.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine-maven/xdocs/project.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- project.xml 25 Feb 2002 23:15:55 -0000 1.13
+++ project.xml 26 Feb 2002 07:41:05 -0000 1.14
@@ -26,7 +26,7 @@
<item name="JavaDocs" href="/apidocs/index.html"/>
<item name="Source XReference" href="/xref/index.html"/>
<item name="Change Log" href="/changelog.html"/>
- <item name="Metrics" href="/jdepend-report.html"/>
+ <item name="Metrics Results" href="/jdepend-report.html"/>
</menu>
</body>
</project>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>