Automated analysis, hand-picked data

Dependency analysis war story #2

After we had designed what our project's dependency graph should look like we started evaluating the current status. Certain parts of the code felt too entangled so a dependency analysis would be needed.

Fully automatic dependency analysis is useful for the big picture, but at least in this project it didn't help (even a DSM generated by dtangler).

Package-level analysis hides essential information, especially if the package structure is messy (i.e. when the code needs analysis most). Class-level analysis either contains too much information or is restricted to one package/module at a time.

The analysis needs to be class-level, because that's where the devil is. The classes need to be picked from several packages to see the whole picture. But only the essential classes need to be included so some manual work would be needed.

On the other hand, the actual dependency analysis cannot be manual, because it is too laborous and error-prone and needs to be repeated after each refactoring.

So we combined the best parts of manual and automatic: We hand-picked the classes that best represent the essentials of the program. Then we used some simple scripting to analyse the dependencies between them and draw them as a graph.

The result was as to-the-point as a hand-drawn picture but reliable and repeatable.

Originally published on 2011-04-29 at under category Software Architecture