Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

プログラムをマクロ(大域的)に分析する

モデルベースの手法でコストをかけずに既存システムを分析する(5)

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2012/11/01 14:00

 この連載の最後となる今回は「システムの地図」を補完するボトムアップの分析手法を紹介します。今までの分析は入出力情報とデータを使い、論理的にシステムの構成を整理する分析手法でした。今回紹介する手法は実際の構成を利用して論理的な構成を検証する手法です。

目次

 プログラムを解析しパッケージに分類。パッケージ間の関係をプログラムとデータの関係から整理します。そして大規模システムの再構築に向けた、段階的なインターフェースの整理へと説明をつなぎ、最後にシステム開発の発注側と受注側のコスト意識のギャップを埋めるポイントを説明します。

プログラムからマクロな情報を得る

ボトムアップで補足する

 プログラムを調べる場合に気を付けなければいけないのは、プログラム1本1本を調査してしまうことです。「木を見て森を見ず」にならないように情報を分類することに主眼を置きます。分析は主にプログラムとデータの関係を調べ、データとプログラムを数枚のマトリックスで表現し、システム全体を俯瞰できるようにします。そのために「システムの地図」の中で洗い出したパッケージを利用します。

 マトリックスの作成にはExcelのピボットテーブルを使います。図1はプログラムとデータの関係を示した表と、そこから作成したピボットテーブルを示しています。実際には数千、数万行の表になるので図1より大きなピボットテーブルになります。

図1 ピボットテーブルによる分析
図1 ピボットテーブルによる分析

 「システムの地図」ではパッケージの役割から論理的に関係性を決めていました。その論理的なパッケージ構成を実際のプログラムに対応させることで、実際のシステム構成を論理的に整理されたパッケージ構成で把握することができます。多少おおざっぱでもパッケージとして分類し、それを分析することでマクロな視点から既存システムを分析できます。

 例えばプログラムとデータの関係は同一パッケージに収まっていることが望ましく、その割合が高いほど凝集度は高いといえます。

 一方パッケージ間の関係も分析することが可能です。「UMLを使った既存システムの分析/ネタを揃えて重要なものを抜き出す」でパッケージ分割のパターンを説明しました。共通系と個別系のパッケージでは相互の関係が異なってきます。共通系は他のパッケージとの関係が多くなります。特に個別系から共通系への参照が大量に発生します。個別系同士の関係は少ないはずです。その特性を理解してマトリックスを確認することで、システムの特徴を把握できます。例えばある受注パッケージが在庫パッケージのテーブルにCreateで関係付けられていた場合は、何か特殊な理由があるはずです。そのようなケースを個々に確認していくことで、保守担当者も忘れていた重要な条件を洗い出すことができます。

図2 システムの地図との関係
図2 システムの地図との関係

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 神崎 善司(カンザキ ゼンジ)

    (株)バリューソース代表 大手SIerにおいて大小10システム以上のプロジェクトリーダを勤め、20年ほど前に独立。2002年から5年間(株)豆蔵での社員も兼任しながら要件定義などの上流工程のコンサルティングを行う。2008年に要件定義手法「リレーションシップ駆動要件分析(RDRA)」を開発し現在は...

バックナンバー

連載:モデルベースの手法でコストをかけずに既存システムを分析する
All contents copyright © 2005-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5