Tags: Java
I found a blog posting,
Hidden dangers of code quality tools, discussing static analysis and code quality, using JDepend as their example. The point they make is that software quality metrics tools can give a false impression, unless you understand what you're looking at. They suggest it's better if you interpret the results of a code quality tool by understanding the context of your code, and understanding what's being measured by the tool.
I'm interested in static analysis tools as a way for the Java SE SQE team to better focus the tests we write. For example it's likely that complex code has more bugs than does simple code, so if we could focus our tests on the complex code we could find more bugs, our managers would be happy with our bug counts, and the developers might grumble with the bug fixing work we're sending their way, but in the end you guys, our customers, would hopefully have a better Java platform to run on.
Interested, I downloaded JDepend and gave it a spin. But maybe my target, to use it to analyze the JDK's rt.jar, isn't a good candidate.
They say: JDepend traverses Java class file directories and generates design quality metrics for each Java package, but actually it also can analyze JAR files (as I asked it to analyze rt.jar and it handled that without problem). It did it's analysis pleasantly fast and up popped a Swing GUI. Actually, what came up was two windows with identical contents, and I'm not at all understanding why it gave me two windows. Since I do not use eclipse I'm not trying out that plugin, but it appears from Enerjy's blog entry the eclipse plugin can graph the results.
The window has a bunch of lines of JTree entries with cryptic notations of various code quality metrics. These are: Number of Classes and Interfaces, Afferent Couplings (Ca), Efferent Couplings (Ce), Abstractness (A), Instability (I), Distance from the Main Sequence (D), and Package Dependency Cycles. Most of the entries are marked with "folder" icons, and double clicking the entry opens up a hierarchy of what appear to be a twisty maze of package names all alike, and I haven't found the pirate yet but I suspect the magic phrase xyzzy is not going to help here.
Maybe to a code quality metrics expert these labels make sense. While there is a guy named David Herron who is an expert on code quality metrics, that guy is not me, he's some other David Herron. But what I gather is there are two kinds of couplings (a coupling is a dependency between a package and some class), and some other measures related to complexity. Abstractness is a simple ratio of abstract classes to concrete classes in a package. Instability is a ratio of the coupling, so a package with a high degree of instability (by JDepend's measure) has dependencies on many other packages.
Clearly this is an expert friendly tool. It doesn't do much to help me understand what I'm looking at and doesn't present the data in a very friendly format. It does have a command line interface, and it can produce XML which can be processed for various purposes, one of which is to generate graphs using the GraphViz package. It also has an API and the author shows examples of running JDepend as a JUnit test, despite the fact that static analysis is not a unit test.
I've added a link in the Javapedia
Testing area, specifically on CodeAnalysisApps.
Source:
weblogs.java.net
