アーキテクチャを調査するためのビューが2つ用意されています。1つは [サブシステムアーキテクチャダイアグラム] で、これは [サブシステム・インタフェースの依存関係]ビューをベースとしており、Jeff Garland 氏と Richard Anthony 氏が共著の書籍 Large-Scale Software Architecture, A Practical Guide Using UML に解説が記載されています。これらのダイアグラムは、ソフトウェアの"全体像"という概観を提供するため、一般的に未知のコードを理解するための第一歩としては最善の機能です。[サブシステムアーキテクチャダイアグラム] は、ソフトウェア固有のアーキテクチャを構成するサブシステム、レイヤ、インターフェイスなどの本質を明らかにします。さらに、低いレベルのグラフ、例えば特定のソフトウェアの機能における関数呼び出しツリーなどの精査中に、[サブシステムアーキテクチャダイアグラム] に切り替えることで、調査中のソフトウェアに関するアーキテクチャのコンテキストを表示することができます。

2つめのビューは、Design Structure Matrix （DSM）です。Dependency Structure Matrix とも言われ、DSM の一般的なフォーマットと使用方法については DSMweb.org に情報が掲載されています。DSM は [サブシステムアーキテクチャダイアグラム] を補完するものです。ソフトウェアの基礎となるアーキテクチャに関して、同一のデータを共有します。ただし、DSM はサブシステム間の依存関係に焦点を当てたデータ示します。これにより DSM は依存性の解析および再構成に対して特に有効となります。

コードを Imagix 4D にロードすると直ちに、[サブシステムアーキテクチャ] ビューを使用することができます。最初のステップは、[サブシステムアーキテクチャ] ウィザードを使用した、サブシステム・アーキテクチャ（SA）の作成です。最初に作成すると、SA 上のサブシステムはソフトウェア・システムの物理的（[ディレクトリ] > [ファイル] > [クラス] > [関数と変数]）ないしは、論理的な（[名前空間] / [パッケージ] > [クラス] > [関数と変数]）パーティーションを示します。現状の SA を作成した時点で、他のビューと同様に SA を速やかに活用することができます。

ただし、作成した SA がモデルとして認識されることがあります。このモデルは [サブシステムアーキテクチャダイアグラム] で修正することが可能です。サブシステムの追加、削除、移動を行うことによって、アーキテクチャに関する構想を SA の表示に反映させたり、アーキテクチャ関連の変更における影響を解析したりすることができます。また、[サブシステムアーキテクチャダイアグラム] で行ったモデルの変更は、DSM で表示することや、さらに深く解析することが可能です。同じプロジェクト内で、一連の SA を管理することもできます。論理的に派生しているアーキテクチャに並行して、物理的に派生しているアーキテクチャを確認することは、現在、存在するもののように、ソフトウェアを理解する上での新しい手がかりとなり得るのです。さらに修正した SA を複数持つことにより、レイヤ化あるいはインターフェイスを改善する別の手法との比較を可能とします。

ダイアグラムのレイアウトと依存関係の解析

[サブシステムアーキテクチャダイアグラム] の中にあるボックスはサブシステムを表し、ボックス間に描画される線はサブシステム・メンバの呼び出し（部分的に設定および読み取りを含む）を表現しています。

サブシステム間における階層ならびに依存関係の双方が、レイアウトに反映されるのです。あるサブシステムが2つめのサブシステムを組み込むような場合には、1つめのサブシステムを表すボックスの中に、2つめのサブシステムを表すボックスが表示されます。

ボックスの中に他のボックスが表示されている場合は、それらのボックスが表すサブシステム間の関係が依存関係であることを示します。あるサブシステムが2つめのサブシステムに対して呼び出しを実行するが、2つめのサブシステムからは呼び出されないケースでは、そのサブシステムは2つめの上に表示されます。2つのサブシステムが相互に呼び出すか、直接的あるいは間接的に他のサブシステムを呼び出す場合には、その2つのサブシステムはダイアグラムでは同じ行に配置されます。

[表示] メニューには、サブシステム間の依存関係を解析するために、多彩なオプションが用意されています。外部への呼び出し（あるいは変数の使用）が、次の下位レイヤ以外のサブシステムに対して実行されると、厳密なレイヤ化の違反が発生します。上位レイヤに対する呼び出しが実行された場合にのみ発生するのは、緩和したレイヤ化の違反です。

[表示] メニューの項目を使用し、表示される関係を変更することで、サブシステムの依存関係における問題を特定することができます。数多くのサブシステムが同じレベルとなる場合には、サブシステムの依存関係の解決ならびに、レイヤ化の改善を促進するために [関係の強度] オプションを利用することが可能です。ごくわずかな基礎のシンボルのみを示す関係を、特定することができます。関係を表す線の上で右クリックするとコンテキスト・メニューが開き、関連する特定の関数をドリルダウンしたり調べたりすることが可能となります。これらの関数はソフトウェアの意図したレイヤ化に対して、より適切な物理的もしくは論理的なパーティション分割を行うための再パッケージ用のターゲットとなる可能性があるのです。

アーキテクチャの修正

サブシステム・アーキテクチャ（SA）を最初に作成すると、 "現状"のソフトウェアと表示されます。ダイアグラムに示されるサブシステムは、コードのファイルあるいは名前空間 / パッケージのパーティション分割に対応しています。サブシステム間の相対的な位置関係は、それらが表すソースコード内の関数と変数における、実際の依存関係を表現しているのです。

これらのダイアグラムは、ドラッグ&ドロップや右クリックで表示されるメニューを組み合わせて活用することで、サブシステムやそのコンテンツに対して追加、移動、再配置、削除などの修正作業を行うことができます。ダイアグラムに変更を加えると、それが示す基礎となる SA にも反映されます。

SA を修正する理由の1つとして、ソフトウェアのシステム・アーキテクチャおよびレイヤ化を、より正確に SA に反映させることがあげられます。さまざまな理由によって、ソースコードの物理的あるいは論理的なパーティション分割が、内在するアーキティクチャもしくは意図したアーキテクチャを反映しなくなっている可能性があるのです。ダイアグラムを操作し基礎となる SA モデルに対して変更を加えることによって、その結果 SA は、コード本来のアーキテクチャを、より精確に表すことができます。今後、修正済みの SA がより円滑に連動するよう、コードの物理的なパッケージングを調整する必要があるかもしれません。

SA を修正する2つめの理由は、別のレイヤ化の手法を模索することにあります。ソフトウェアにおけるレイヤ化を微調整したり、より大幅に再度パーティーションを変更したりすることを検討しているケースでは、別の方法を選択したことによって生じる依存関係の問題を、確認することが可能です。

複数のアーキテクチャの管理

サブシステム・アーキテクチャ（SA）内の階層は、ダイアグラムを修正することによって階層に加えられたあらゆる変更を含め、セッション間に保存されます。変更内容は、後のセッションで SA を再度開いた際に復元されます。特定のサブシステムにおけるメンバのレイアウトは保存されないため、後のセッションで利用することはできません。

SA を変更する際には、さまざまな方法をいくつか試すために、ブランチを作成しすることが可能です。このような場合には、[サブシステムアーキテクチャ] ウィザードを立ち上げて新しい SA を作成し、この際に現在の修正済み SA をベースとして指定することが最前の方法となります。このケースでは、1つのソフトウェアに対して複数の SA を使い、作業を進める必要が生じるかもしれません。定義する SA はそれぞれ、明示的に削除されるまで、セッション間で保存されます。