David Herron's Blog

JDepend and code complexity

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.

Comments

• Ha. Looks like tools for experts cannot avoid experts writing complex code :).
  I dont understand the way JDepend does is analysis either. What does it say about an application if its classes are scattered over many packages?.
  If you would JDepend on OpenjDK SDK then i guess it would say that this is highly instabel because it makes lot of use of abstract classes, interfaces, and distributed classes.
  As a Java developer, would you say that OpenJDK SDK is too complex? A cross plattform multi OS SDK like java is complex and still gaining complexity if you look at the present OpenJDK builds.
  Personally i think that analysis tools or statistics should help providing a solution to simplify things. Everything that JDepend does i could do with NetBeans tools also.

  Posted by: alexanderschunk on August 24, 2007 at 03:00 AM

• JDepend Abstractness, Instability and Distance are only some first impression. Dont forget to count your McCabe Complexity perhaps with something like javaNCSS.

  Here an Example of an JDepend-GraphViz-Rendering: hit-the-code-jack on
  

  Posted by: dbt23 on May 12, 2008 at 02:30 PM

This work is licensed under a Creative Commons License.