Dependency Analysis

Introduction

Dependencies – often underestimated thing in software development. When you are building the projects you build them from components, classes, routines etc. And each of such a components are always dependent on a certain other things (the root ones usually are just dependent on the system units/classes/components). When you have a completed project it is always a good thing to check out the dependencies of your things. In this topic I will only talk about one of the ways how you can analyze the module dependencies for Delphi projects.

Maybe you already tried to guess that you can do that with tools like GExperts or CnPack uses cleaner. While these tools allows you to analyze the things (GExperts) and remove unneeded uses items (CnPack) they actually does not give the overview of your project as a whole!

So the way of analyzing the project for the dependencies is the following:

1. Decide which project you want to analyze;
2. Use Delphi Dependency Scanner to parse the dependencies;
3. Export the Gephi CSV formatted graph edges;
4. Open the exported file in Gephi and apply required visualization;
5. Inspect your graph!

Example

Let’s take the Spring4D as an example for the analysis. I used the release 1.2 branch for this example. So first what we need to do is adding the spring units to the Delphi Dependency Scanner and then scanning them. After we have done that we will get the following result:

Sure we see there is a lot of circular dependencies between implementation and interface units, but that’s acceptable for a library like Spring4d. There are arguments to have these thing like that (probably). But what I can say about normal projects is that you should avoid the circular references in your sources in any way!

Once we have the result we can save this to the Gephi CSV (upper right corner, button in toolbar) and then we open it using the Gephi tool. After confirming the import dialog you will get such a nice picture of the Graph (at least with my defaults and version of the Gephi tool). You can consider also using the yEd option.

Holy crap you will think! But wait. We can improve the graph by doing the following:

• In Layout window select Force Atlas and enter 25000 for the Repulsion Strength. Run the layout process, wait a bit and then stop it;
• Turn on the unit names and selection coloring (it will highlight the edges in different color depending on the direction of the dependency) as its shown below:
  
• You can use the Label Adjust in layout window to fix the label overlapping and perform any appearance changes;
• You can export the result as PDF if you like (probably you will need to adjust the preview settings before). The example of mine can be found there: Spring4D Graph.pdf.

So now you can browse the graph, click on a interesting nodes and see the links between modules and see which modules have too many dependencies etc. You can analyze your graph statistics to make certain conclusions about your project dependency state. It can be not that useful/easy to do such thing for the whole project but it is certainly very good for a features/components used in the project – you can just analyze any part of the project – it is not mandatory that it even should compile.

After you get some experience with these tools you will easily see a difference between well built and decoupled projects and tightly coupled ones.

So there is the “persistence” wing of the Spring4D framework:

And you can actually see the decoupling in action here 😉

yEd

You can also use the “Save to GraphML” option from DDS tool and then use the yEd to analyze the diagram:

This tool can be more user friendly and intuitive than Gephi for you, but that’s your choice.

Thank you for reading this. I hope you enjoyed and it was useful for you.