このような隙間を埋めようと現れた最新の技術が、Dependency Structure Matrices (DSM)(source)である。 DSMはマトリックスを表し、各行にモジュール、列は他次元における同様の一連のモジュールである。付けられているそれぞれのセルは、2つのモジュールの共通部分およびその依存関係の数を示している。 さらに詳しい情報がなければ、以下にあるような昔ながらの例(PDF・英語)でDSM視覚化のすばらしさをすぐさま直感することができる。
詳しく見ると、各行はレイヤードアーキテクチャでのパッケージを表している。行は1から5までの番号が付けられている。列にも1から5までの番号が付い ており、それぞれ同じモジュールを表している。厳密なレイヤードシステムでは、アプリケーションはモデルのみに依存し(37回)、モデルはドメインのみに 依存している。レイヤードシステムでは、アプリケーションなどの高位層はutilなどのすべての低位層に依存することができる。このような視覚化を考慮す ると、ルールを無視するコードが記述されると、すぐにそれは明らかになる。右上に表示されている依存関係は、アーキテクチャーの意図に背く可能性がある。
IntelliJは「Magnificent 7」の新リリースで新たなDSMツール(ブログ・英語)を導入した。コードベースの予定通りの階層化について考えたり、手動でUML図を配置する必要がなく、 IntelliJは既存のプロジェクトから自動的にDSMを生成する。他のDSMツールと同様に、自動的にノードを配置し、依存関係が左下に表示されるよ うになる。DSMはクラスレベルにインタラクティブでドリル可能である。
この例では、IntelliJのDSMツールはReferenceStrengthがアーキテクチャーでそれより下位の層で4回使用されることを示している。DSMツールをIDEAに統合すると、非常に便利である。IDEAは、コードベースでの4回すべての参照を簡単に表示し、問題修正を楽にさせる。この場合、ReferenceStrengthはItelliJのリファクタリングツールを使用して、上位パッケージへ移動することができる。
IntelliJのDSMツールには改良の余地がある。IDEAには珍しいが、前述の番号付きの行や列によって実現される使用可能性が欠落している。 Lattixのような他のツールには、さらに強力なリファクタリングサポート(source)がある。Lattixはクラスやパッケージを、マトリックスの視覚化から直接 移動することができる。
DSMは、 実行者のマシン上で進歩している強力なツールである。
原文はこちらです：http://www.infoq.com/news/2008/02/idea-dependency-structure-matrix