Headway Software has released Structure101, a product that measures "fat" and "tangle" in code. "Fat" refers to the interdependencies in a given package, and "tangle" refers to cyclic dependencies between packages.
- Posted by: Joseph Ottinger
- Posted on: February 06 2006 08:40 EST
Structure101 has an interesting demonstration that shows what the product is designed to highlight, along with what problems can be solved by designing software with less "fat and tangle," problems that are well-known but are still quite prevalent.
Stucture101 , at $499USD per user, is currently available for Java only, with C/C++ versions forthcoming.
How does this resolve runtime, IOC type dependencies. Would be good to see a roadmap to address these types of issues.
The definition that McCabe gave in 1976 for cyclomatic complexity is used today virtually unchanged. Folks complained that McCabe ignores call stack depth (we've all seen what a JBoss stack trace looks like). But my big beef with his formula is that it neglects the complexity implications of invoking virtual methods. Eg, when a method invokes Object.toString(), it's actually choosing between many alternate implementations and therefore has many possible control flow paths. Polymorphism shifts complexity, but it doesn't reduce complexity. Too many folks think this gives better code. Ie, ArrayList<String> should have less cyclomatic complexity than ArrayList<Object>.
Trying this out, the thing that impresses me the most so far is its speed. Part of that is probably that it works on bytecode, not trying to parse your .java files, which is also good for other reasons. I handed it a 50K LOC project and it was done with the analysis in <5s. That's running on an AMD 4800+, so not a chump processor by any stretch, but still. IDEA, which can do some of the same analysis, takes quite a bit longer to do its thing and doesn't exactly inspire paeans to its usability once it's done.
Speaking of usability, the product feels a bit more like a beta to me than a 1.0. For instance, the "Overview perspective" summarizes the most problematic areas of the your code, some of which can be quite buried. Jumping into the source code should have been a matter of clicking on one of the rows in the little tables it generates. Instead you have to switch to a different perspective, drill down to the area of interest, and then you can get into the code viewer. In a large project, by the time you get there you may have forgotten what it was you were looking for in the first place. ;)
Another oddity was the fact that configuring the project only asks for your classpath. When you want to view source, you have to configure the code viewer with a source path separately. Once you're in the code viewer, it's only a view for that file, it has no way to browse your package hierarchy. It's like the code viewer and the bytecode analyzer were written by completely separate groups. In its defense, the dependency graph does obviate the need to examine source code in some cases.
If you have a large code base, I can see this tool being valuable for your organization, although I'd be surprised if you need more than one or two licenses per team. I tried it on some different projects of mine which are smaller (20K LOC and less), and it didn't find anything useful to tell me. Part of that is probably just that when you only have one or two developers working on something the chances for problems this sort of tool is designed to discover don't crop up as easily.