Dependency Structure Matrix

9 April 2010

This is just a quick post to raise awareness for a technique that has been around for a while. In software architecture a Dependency Structure Matrix (DSM) can be used to understand dependencies between groupings of classes, that is packages in Java and namespaces in C#. There are obviously other uses, and this Wikipedia article has more background information.

Returning to classes and packages, the following matrix shows a view of some of the core classes of the Spring framework:

In this typical package DSM the packages are listed on both axes. If a package has dependencies on another package, the number of dependencies is listed at the intersection. The package that has the dependency is on the top, the package that it depends on is on the left. In the example above the matrix shows that there are seven dependencies from the beans.propertyeditors package to the package.

The first, and most obvious, issue that can be spotted in a DSM is a cyclical dependency. Most tools (more on those at the end of the post) try to arrange the matrix such that all dependencies are shown in the lower left triangle. A cyclical dependency makes this impossible and one “half” of the dependency will be shown in the upper right triangle.

In the following matrix, which shows a package view of the Jetty server, we can see that jetty.webapp has six dependencies on jetty.handler but the latter also has a single dependency on the former.

Another design concern is that of cohesion and coupling, very well explained here. Applying this to a package level and DSM it is good to see dependency numbers arranged in squares, showing cohesion between related packages, but rows or columns filled with numbers are often a concern. A row filled with numbers signifies a package that many other packages depend on. This can be acceptable, as in the util package in the Spring matrix above, but often it is a sign of a lack of cohesion. Conversely, a column filled with numbers represents a package that depends on many other packages, which is usually a sign of bad coupling and the possible presence of god classes and feature envy.

These patterns become even more apparent when looking at larger systems. The following matrix is a zoomed out version showing most of the Spring framework.

There is a good cohesion, shown in pink, in many of the subpackages, but there are also some classes that invite a large number of dependencies, shown in blue, as well as a couple of classes that have unfocussed dependencies, shown in green.

At this point I should probably mention that I think that the Spring framework is fairly well designed, and that I’ve seen quite different matrices in the wild.

I hope I have convinced you that DSMs are worth a look, and luckily there is now widespread support for DSMs, in IDEs, e.g. IntelliJ, and in tools, e.g. Structure 101, Lattix, .NET Reflector. The screenshots in this post were created with Structure 101 for Java.


  1. Fabio Gavilondo

    15 October 2010, 11:14

    A free (and otherwise great) tool with DSM support is Sonar:

  2. Fabio Gavilondo

    15 October 2010, 12:41

    An oldie but goodie: The article Reducing Coupling by Martin Fowler discusses some effective techniques that can be employed to correct packaging issues:

  3. Patrick Smacchia

    30 December 2010, 22:41

    So many patterns can be made obvious with a DSM
    * Layered Code
    * Dependency Cycle
    * High Cohesion – Low Coupling
    * Too Many Responsibilities
    * Popular Code Elements
    * Mutually Dependent
    I’ve written here some thoughts

  4. Schauderhaft » Introducing Degraph for Visualizing Package Dependencies

    24 February 2013, 07:29

    [...] that tell you when you have dependency cycles. Most of the time they show you the problem as a dependency structure matrix. Unfortunately it is really hard to identify a bunch of classes that you can pull out of a package [...]

Leave a comment