プログラムを解析しパッケージに分類。パッケージ間の関係をプログラムとデータの関係から整理します。そして大規模システムの再構築に向けた、段階的なインターフェースの整理へと説明をつなぎ、最後にシステム開発の発注側と受注側のコスト意識のギャップを埋めるポイントを説明します。
プログラムからマクロな情報を得る
ボトムアップで補足する
プログラムを調べる場合に気を付けなければいけないのは、プログラム1本1本を調査してしまうことです。「木を見て森を見ず」にならないように情報を分類することに主眼を置きます。分析は主にプログラムとデータの関係を調べ、データとプログラムを数枚のマトリックスで表現し、システム全体を俯瞰できるようにします。そのために「システムの地図」の中で洗い出したパッケージを利用します。
マトリックスの作成にはExcelのピボットテーブルを使います。図1はプログラムとデータの関係を示した表と、そこから作成したピボットテーブルを示しています。実際には数千、数万行の表になるので図1より大きなピボットテーブルになります。
「システムの地図」ではパッケージの役割から論理的に関係性を決めていました。その論理的なパッケージ構成を実際のプログラムに対応させることで、実際のシステム構成を論理的に整理されたパッケージ構成で把握することができます。多少おおざっぱでもパッケージとして分類し、それを分析することでマクロな視点から既存システムを分析できます。
例えばプログラムとデータの関係は同一パッケージに収まっていることが望ましく、その割合が高いほど凝集度は高いといえます。
一方パッケージ間の関係も分析することが可能です。「UMLを使った既存システムの分析／ネタを揃えて重要なものを抜き出す」でパッケージ分割のパターンを説明しました。共通系と個別系のパッケージでは相互の関係が異なってきます。共通系は他のパッケージとの関係が多くなります。特に個別系から共通系への参照が大量に発生します。個別系同士の関係は少ないはずです。その特性を理解してマトリックスを確認することで、システムの特徴を把握できます。例えばある受注パッケージが在庫パッケージのテーブルにCreateで関係付けられていた場合は、何か特殊な理由があるはずです。そのようなケースを個々に確認していくことで、保守担当者も忘れていた重要な条件を洗い出すことができます。
