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.