Welcome to the Joint-Venture Blog from Fabio Cortesi and Stefan Jäger.
In a software project, Software Engineers need to ensure, that the source code meets the architectural rules. One of a usual architecture rule are the dependencies between the layer and packages. There are a lot of tools, which can be used to ensure, that no class breaks this rules.
If you know, that there are some specific classes, which do not meet these rules, a dependency code analysis is needed. Therefore, I found a free tool called CDA (http://www.dependency-analyzer.org/), which is very helpful in such a situation. It can also be used for repeated check to ensure architecture compatibility, but in this blog entry, I will focus on code analysis.
First of all, just install this tool as described on the website (http://www.dependency-analyzer.org/#Installation). CDA doesn’t need any installation (just unzip the compressed file) and can be run with Java 1.5.
After finishing the installation procedure, you need to create for every project a Workset. A Workset can contain different code sources, which are analysed together. First, define a Name. After that, go to the Classpath register. The easiest way to use CDA is to analyse a JAR file. Add all JAR files, which you want to analyse.
If you are finished, save the Workset. CDA will load now all classes from the JAR files into a tree. With CTRL + F you can search for a specific class or you can navigate with the package name to a specific class. With right click, you can analyse all dependencies (on which classes/packages does the class depends on) or you can analyse all dependants (which classes/packages depends on the currently selected class).
If you are analysing the dependencies, you can show the classes or packages, on which the specified class depends on. Furthermore, you will see all third-party libraries, on which the class depends on. If you do not want to see some specific packages, you can apply a filter (button “edit filter”), on which you can define excluded packages.
The generated graph looks like following. It is almost the same as the textual dependency view, with the exception, that no third-party libraries are shown.
This tool is user friendly. If you are using this tool, you will very fast get to work with it. I use this tool to find dependants on a class and to draw simple UML diagrams of a class (very useful if you want to draw a UML diagram from just one class with all it dependencies).