Doing Dependency Structure Matrices

(From my old Blog, Article – Dec 13, 2009)


In a few words: a Dependency Structure Matrix (DSM) is a matrix representation of a system or a project that shows the information exchanges and dependency patters between different sub-systems. It can be applied to any kind of project or system, and turns out to be very helpful for analysing IT projects.

More information: The wikipedia page on DSM, Dependency Structure Matrix homepage.

About Dependencies

– With dependencies, less usually is more. Less dependencies means better reusability, testability and maintainability.
– An item should only depend on items that are more stable than itself.
– Cyclic dependencies are the root of a lot of trouble so, in general, get rid of them.
– The domain usually also adds criteria to the definition of good dependencies. For example, in software development, server code should not depend on client code.

Note:The DTangler project has been discontinued.

Understanding DSM using DTangler

Let’s try DTangler on some example code. This will allow us to understand what a DSM is and what DTangler exactly does.

The following diagram shows the different classes we will use for testing. All classes are empty, without methods or members, except when defined otherwise. On each test construct, we will use the DTangler GUI to verify the resulting matrix.

For the first test case, we add two simple dependencies: Front1 depends on Front2, and Front2 depends on Front3:

public class Front1 {
   void test() {
      Front2 f2=new Front2();
public class Front2 {
   void test() {
      Front3 f3=new Front3();

After starting the DTangler GUI, we add the project’s compiling output directory (DTangler uses JAR and CLASS files) to the input parameters, selecting the JAVA engine:

Hitting the OK button generates the matrix. The result, after selection of the “classes” scope, is the following screen:

In the US and Asia, DSM diagrams are read from columns to rows (top to left). This is the way DTangler creates the matrix. In the European region, DSM diagrams are often read from rows to columns (left to top).

In our case, the matrix states:

  1. class (we are in class scope) 1 (Front1) has one dependency link to class 2 (Front2), i.e. Front1 has 1 outgoing reference to Front2.
  2. class 2 (Front2) has 1 outgoing reference to class 5 (Front3).

The second test case adds two new dependencies. We close the circle by making a link between Front3 and Front1.

public class Front3 {
   void test() {
      Front1 f1=new Front1();
      Back1 b1=new Back1();

Refreshing the matrix (after the project has been recompiled), shows the following:

The matrix highlights a cyclic dependency: (reading from left to right) Front3 (1) depends on Front1 (2), Front1 (2) depends on Front2 (3) and Front2 (3) depends on Front3 (1). Additionally, Front3 (1) depends on Back1 (4).

Cyclic dependencies should always be examined and if possible resolved. Often they are the result of a nasty bricolage like this one:

public class Derived1 extends Base {
public class Derived2 extends Base {

/* I am a base class that knows my inheritors. */
public abstract class Base {
   public String whoAmI() {
      if (this instanceof Derived1)
         return "I am Derived-1";
      else if (this instanceof Derived2)
         return "I am Derived-2";
         return "I don't know";

You may decide that cyclic dependencies are not considered being problematic. In this case, you can configure DTangler to treat them as warnings when using the command line tool.

The next step is to use the DSM to verify dependencies between project modules. Since these relations are derived from the project topology, we have to create a specific set of rules in DTangler.

In our example, we want to ensure that the back-end doesn’t become dependent on the front-end. To create the test case, we suppose that all classes are empty, except the following relations:

public class Front1 {
   void test() {
      Back1 b1=new Back1();

public class Back2 {
   void test() {
      Front2 f2=new Front2();

Refreshing the DSM in class scope doesn’t report any problem so far. The problem becomes apparent when seen in the context of the application’s layer architecture.

To define the rule that will protect the back-end from dependencies on the front-end, we open the “”Rules dialog in order to define two Groups:

  • – “Groups” tab, “Add”, Name: “backend”, “Add”, Group member: “*be.vitruvimente.dsm.backend*”
  • – “Groups” tab, “Add”, Name: “frontend”, “Add”, Group member: “*be.vitruvimente.dsm.frontend*”

Then we fix the forbidden relation:

  • – “Forbidden dependencies” tab, “Rules” part (top), “Add”, (*) Group “backend”, select the group, “Cannot depend on” part (botton), “Add”, (*) Group “frontend”, “Ok”, “Ok” to close the dialog.

Now the DSM indicates the illegal connection: Back2 depends on Front2.

Till now, we used the “classes” scope since it suits the best our small demo project. By selecting the “package” or “location” scope, the verification can be performed on a higher level.

Beside of using the GUI, the tool can be employed in command line mode. By this, it’s easy to include the dependency surveillance in an automated build process. The configuration created with the GUI tool can be saved in a properties file, which can be used by the command line tool.

What’s next?

DTangler is a fine tool but provides only base functionalities to work with DSM. The next tool that I would like to test is the commercial LDM software from Lattix Inc. A trial version can be downloaded from the company website. Update: Another great tool that I use regularly: Structure 101.

Et zou…

Leave a Reply

Your email address will not be published. Required fields are marked *