Before installing and using JQA please read carefully the license agreements (evaluation or standard)
Installation is very easy. Please unzip the zip file into any directory.
example: c:\Program Files
Once you have successfully unzipped the file you may launch the tool by launching the script JQA.bat. You can now launch the settings (File->Properties) to configure the source and class path. You should be aware that most metrics need the source code as well as the compiled classes (and all used classes) to be configured correctly.
JQA is a tool that provides objective quality measurements of Java source code for management and for developpers. The tool can be used (and should be used) during the development cycle of a project by the developer himself allowing him to produce better code. It can also be used by the management to assess the quality of the produced code. This does of course not mean that all the results given by the tool can be used as such to valid a code as good or bad. It is merely an objective indication if the code is getting better or not.
Whereas most metric tools only produce the bare metric results, JQA can also be used for validating quality rules based on the metrics (e.i. the number of methods allowed). No difficult scanning of the produced results are necessary to find the piece of code that should be investiguated.
JQA can be configured to meet any needs:
it can skip some classes (for example
generated classes whose quality assessment is of no use) for all metrics or for
some
it can apply different validation rules for
different classes (for example a class descending from javax.swing.JPanel may
have a DIT of 10 as javax.swing.JPanel has
already one of 5 whereas other classes are only allowed one of 5)
it can apply detailed validation rules for the
different metrics (for example: no limits for private methods and a limit of 10
methods for non private methods)
no limits can be achieved by typing ‘–1’ as
the number of occurrences allowed
etc.
JQA is fully integrated into VisualAge for Java using the Tool API provided by IBM. It will be integrated into the Eclipse workbench immediately after the availablity of the workbench will be officially announced.
JQA is very easy to use and to install.
Coupling Between Objects - CBO
Number of Inner Classes - NOIC
Depth of Inheritence Tree - DIT
The number of attributes of a class (i.e. the number of states it can hold) is one measure to evaluate the complexity of a class. The more attributes a class has the more difficult it is to understand and to maintain this class. As a class can inherit state information from its parent classes, the metric can include the NOA values from the parent classes.
The metric can be configured to count the number of attributes of inner classes separately (suggested). The metric can also include the attributes of the parent class (public, protected and default (if both classes are in the same package)) (suggested) and exclude the static final variables (suggested as static final variables are constants). The presentation can be detailed by the visibility of the attributes.
The attributes can be counted all in once or in more details during the validation process. Two levels of details are distinguished: all details and all non private attributes validated together. Private attributes play a less important role for measuring the complexity of a class as they are only visible within the class and do not influence the subclassing process.
Cyclomatic complexity is used to evaluate the complexity of an algorithm in a method. Cyclomatic complexity is measured by counting the number of different execution paths within a method (i.e. number of ‘if’, ‘for’, ‘while’ and ‘switch’ statements. A low V(G) for methods is generally better as these methods tend to be understood more easily. Because of inheritance, cyclomatic complexity cannot be used to measure the complexity of a class, but the cyclomatic complexity of individual methods can be combined with other measures to evaluate the complexity of the class.
The metric can be configured to measure the cyclomatic complexity of inner classes separately (suggested). The presentation of the results can be detailed to the method level or can aggregate all the metrics to the class level. The result can be configured to exclude switch statements as switch statements tend to produce a high number for the cyclomatic complecity metric without inducing a real higher complexity of the method.
The same possibilities apply for the validation process. Suggested cyclomatic complexities for methods are 10 or below.
CBO is used to express the level of coupling between the class and other classes (also called corelation). Excessive coupling is has a negative impact on maintenance and can prevent reuse. The larger the number of couples, the higher the sensitivity to changes in other parts of the design; maintenance is therefore more difficult. The more independent a class, the easier it is to reuse in another application. Coupling is measured by counting the number of references to foreign types. If the foreign type is a supertype, a subtype, an inner class or an outer class, it is not inluded in the result.
The metric can be configured to treat inner classes separately (suggested). It can skip references to types of same package or same project (suggested only on Visualage for Java) as coupling of close classes can be rarely avoided and can even be a sign of a bad object oriented design (i.e. one class does it all). The metric can also skip references to static final fields (suggested) as they do not tend to influence the complexity of a class. The presentation can be detailed to the method level.
The validation process can be detailed to the method level or to the class level. Both are equally interesting. Details to the class level can show too strongly coupled classes whereas details on the method level can show the ‘guilty’ methods.
NOIC is used to evaluate the complexity of a class. Using a lot of inner classes can result in a difficult to understand design. In Java, especially when using Swing components, using inner classes is sometimes the most common way (see SwingUtilities). That is why the metric can distinguish between the different types of inner classes enabling a different validation for anonymous classes which are more commonly used in the previously mentionned situations.
The metric can be configured to treat inner classes separately (not suggested) and to include the inner classes (top level and member) of the parent classes (not suggested). The presentation of the result can be detailed to the type of the inner classes or can count inner classes defined on class level and those on method level together. The same possibilities exist for the validation process.
The NLM of a class is another measure to evaluate the complexity of a class. The more methods contained in a class the more difficult it is to understand and to maintain this class. As a class can inherit methods from its parent classes, the metric can include the NLM values from the parent classes.
The metric can be configured to count the number of methods of inner classes separately (suggested). The metric can also include the methods of the parent types (public, protected and default (if both types are in the same package)) (suggested). The presentation can be detailed by the visibility of the methods.
The methods can be counted all in once or in more details during the validation process. Two levels of details are distinguished: all details and all non private methods validated together. Private methods play a less important role for measuring the complexity of a class as they are only visible within the class and do not influence the subclassing process.
The depth of a class within the inheritance hierarchy is the maximum length from the class node to the root of the tree, measured by the number of ancestor classes. The deeper a class within the hierarchy, the greater the number of methods it is likely to inherit, making it more complex to predict its behavior. Deeper trees constitute greater design complexity, since more methods and classes are involved, but the greater the potential for reuse of inherited methods.
In Java, the class java.lang.Object has a DIT of 1. All the other classes have DITs bigger than 1. As in Java the notion of interfaces exist, the presentation of the results can differentiate between the number of parent classes and the number of parent interfaces. The validation process can rely on the same differentiation.
The filters can apply:
on types starting with a specific string
on types ending with a specific string
on types contained in packages starting with a
specific string
on types contained in packages ending with a
specific string
on types contained on same project (only for
Visualage for Java)
on types descending from a specific other type
JQA® Copyright © 2001 by Informatique sur Mesure Sarl.
IBM is a registered trademark of International Business Machines Corporation.
VisualAge is a trademark of International Business Machines Corporation.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries