We just released NDepend v2.10 that comes with interactive code dependencies graph. This feature goes beyond previous versions of NDepend that let users generate graph pictures. There is now a dedicated and interactive Dependency Graph panel..

On screenshot below, we see that when the mouse hovers the assembly PndLib (from the Paint.NET project), assemblies callers are updated in green and callees are updated in blue. The matrix is also updated and interestingly enough, we can see a direct correspondence between cells of the matrix and edges of the graph. Indeed, they both represent a dependency.

There are many options to format and zoom graph. For example, the boxes’ sizes can be proportional to number of Lines of Code or number of incoming edges. A metric can be chosen also to adjust edges thickness. On picture above, edge thickness are proportional to the number of members involved in the coupling between assemblies.

As shown on screenshoot below, boxes can be moved and edges shapes can be edited.

VisualNDepend comes with many facilities to generate the graphs needed to browse and understand the code structure.

Graph of code elements with same parent

At any time, the user can right click a code element and click: View internal dependencies on Graph. This lets  display graph of members of a class, graph of types of a namespace or graph of namespaces of an assemblies.

For example the picture below shows dependencies between types of the famous namespace System.Collections.Generic:

Callers Graph

To display a callers/callees graph there are 2 steps. First the user needs to generate a CQL queries to match callers/callees of a code element. On the screenshot below, we ask for methods using directly or indirectly the class System.AppDomain in the code base of NUnit.

Then, the user can export the query result in graph as shown below. This extra step brings a lot of power since it lets generates graph from virtually any query results.

And here is the resulting callers graph, exported to a poster picture thanks to the snapshot facility. I believe that such poster can help a lot when it comes to discuss and analyze an existing architecture.

Coupling Graph

Coupling Graph between 2 components, 2 namespaces or 2 types are useful to plan some refactoring. Indeed, imagine if the conceptors of the .NET Framework would need to get rid of the dependency from the assembly System.Deployment to the assembly System.Drawing. They would need to enumerate which methods of System.Deployment is using which members of System.Drawing, this could be a tedious task. With NDepend, it is as simple as clicking the dependency cell representing the dependency between the 2 assemblies in the Dependency Matrix. Notice that for clarity, I choose here not to prefix members' names with their namespaces but this possibility comes as an option.

Cycle Graph

Thanks to the option Direct & Indirect Weight of use the Dependency Structure Matrix is the perfect tool to let users know where the code structure is tangled with dependencies cycles. The screenshot below shows that the 2 namespaces System.Net.Mime and Microsoft.VisualBasic are involved in a cycle of minimum length 11.

Right clicking the cell lets display such a cycle and here it is:

Notice that a cycle doesn’t necessarily look like the classic A uses B uses C uses A. Here the namespace System is involved 2 times in the cycle. If you count the number of edges to go from and to Microsoft.VisualBasic including System.Net.mime, you’ll indeed find 11 edges.

Path Graph

Graph is a useful tool to display path between 2 code nodes. For example the Matrix below shows that the namespace System.IO.Ports is using the namespace Microsoft.VisualBasic with a path of minimum length 6.

Right clicking the cell lets display such a path:

Matrix vs. Graph

We explained that graph is the appropriate tool to browse code structure in some scenario, particularly when the number of code elements involved is small (under 30). Indeed, human brain is wired to understand graph with few nodes.

On the other side, graphs with numerous nodes quickly become a mess. In this situation the Dependency Structure Matrix is a more adapted way to understand code structure and to detect architectural patterns. In other words Dependency Structure Matrix scales better than Graph. For example here are below 2 screenshots with a matrix and a graph with the 282 types from the namespace System in the assembly mscorlib.dll.

The library MsAgl: Microsoft Automatic Graph Layout

The library we used to display graph is MsAgl (formerly named GLEE) from Microsoft Research. It is a full .NET/GDI library developed by Lev Nachmanson. The library is both very fast and very good at building comprehensive graph layout. It is also lightweight with 3 assemblies that weights 464 KB. Lev and its colleagues wrote an interesting paper to explain the theory behind MsAgl graph layout engine.

It has been a pleasure to develop with MsAgl. The library is full .NET, the API is comprehensive and well documented and the library natively comes with many customization point, such as custom GDI drawing of boxes or configuring the edge's thickness. From my point of view, the only drawback is that a few methods of MsAgl depends on some System.Core.dll types, meaning that now NDepend requires the .NET v3.5 Fx (or higher) to be installed. Update 15 Sept 2008: The MsAgl library has been refactored and can be ran on .NET v2.0 runtime, meaning that NDepend v2.10.1 can be ran also on .NET v2.0 (or higher) runtime, all details here.