Can someone show me what a good dependency matrix looks like and specify why?

Question

I would like to start using DSM, but not sure how to get started.

What does a good dependency matrix look like and why? How does it work?

Answer 1

Erik Dörnenburg gives the best description I've seen, including some good examples of how arrangements of the graph can expose structural issues. Briefly:

• as others have mentioned, anything above the diagonal indicates a cycle, which essentially means that your boundaries are "fuzzy" (not clean)
• smallish squares (well, lower triangles) along the diagonal == good, if the components are grouped according to hierarchy
• on the other hand, heavily weighted rows or columns == possible issues: either
  • rows: you have a component/group that lots of others depend on (maybe it's trying to serve too many features), or
  • columns: you have a component/group that depends on lots of others (maybe it's trying to take care of everything itself, instead of delegating)

Answer 2

One of the most valuable feature of a DSM is to detect cycles, for example between projects or packages. A cycle is displayed in the top-right side of the matrix. See this page for more details : http://docs.codehaus.org/display/SONAR/Dependency+Structure+Matrix

Answer 3

On this blog post Identify Code Structure Patterns with No Effort it is explained how to use a Dependency Structure Matrix to identify Code Structure Patterns. The screenshots are done with the Dependency Structure Matrix of the tool NDepend. Here are a few patterns:

Layered code (code with no cycle, certainly the coolest thing that a DSM can show you at a glance)

Code with dependency cycles

High Cohesion / Low-Coupling

Hungry Caller

Popular Callee

Mutual Coupling

Data Object

Answer 4

List the subsystems on the X and Y axis in the same order. Mark an "O" diagonally. Subsystems depending on themselves doesn't make much sense. Go vertically down the matrix. If that subsystem depends on the matching horizontal subsystem, mark an X.

A good one rearranges the subsystems to show patterns that might lead to a good refactoring.

I don't have one handy, though. Sorry.