要件定義ツールを使った既存システムの分析

CodeZine / 2012年8月3日 14時0分

図8 特定のつながりを確認する

 前回はUMLを使ってシステムの地図をかく方法を説明しました。今回はUMLを使わずにより簡単に分析する方法を説明します。システムの入出力とデータをつなぐ分析手法は、要件定義でも使われる手法なので同じ要領で既存システムを分析することができます。今回ご紹介するのは要件定義ツールを使う方法です。柔軟性には欠けますが、要件定義が初めての方でも簡単に短時間でまとめることができます。

■短期間に分析する

 今回ご紹介する方法は画面数が100程度の中小規模なシステムを対象としています。システム関係者へのヒアリングが行える環境があり、材料(入出力情報とデータ)が揃っている場合は、手法とツールを使うことで、短時間でシステムの地図を作成できます。

 今回は要件定義ツール「要件のツボ」を使った方式を説明します。今回もプログラムそのものを調査するのではなく、システムの入出力を調べ、その使われ方を調べる方法です。「要件のツボ」も同じ考え方で作られており、情報の表現方法をそのまま活用できます。

●対象とする情報

 既存システムの分析は、以下の6種類のデータと2つのモデルで表現します。

誰に: 「アクター」「外部システム」 何を行い: 「画面・帳票」「外部システムとの入出力」「機能」「データ」 何のために: 「ステートマシンモデル」「概念モデル」  「要件のツボ」を使った場合は、システムの関係者を「アクター」「外部システム」で表現し、入出力情報として「画面・帳票」「イベント」「イベントデータ」を使い、システムは「機能」と「データ」で表現します。

 ステートマシンモデルはプロトコル(後述の「手続きにともなうルール化」を参照)という機能で代用し、概念モデルは用語集で代用します。

 扱える情報は前回紹介したUMLを使った方法とほぼ同じ(違いは画面にイベントを結びつけないこと)です。

 思考方法はUMLと「要件のツボ」では多少異なります。UMLはダイアグラム単位で図としてつながりを記述しますが「要件のツボ」では個々の要素を直接つなげるので、ダイアグラムのように1枚の図として表現する単位がありません。UMLではダイアグラム単位が表現の単位になるので、読み手と作り手は同じダイアグラムを見ることになり、作り手の表現力がそのまま読みやすさにつながります。「要件のツボ」は図としての要素がない分、要素のつながりにだけ集中でき、作成が容易になります。

 UMLのような汎用的なツールは柔軟性があり表現力も高いのですが、使いこなすには経験が必要です。一方専用ツールは柔軟性には劣りますが、初心者にも扱え、素早くまとめることができます。

●材料を順次入力する

 既存システムの分析は、最初に入出力情報(画面・帳票、イベント、イベントデータ)とデータを洗い出すことから始めます。「要件のツボ」ではそれらのデータをアイコンではなくテキストとして入力します。

図1 洗い出した情報を順次入力する


 図1にあるように洗い出した情報の名前を順次登録します。この時情報は個々に分析せず、そのまま登録します。そして、ある程度材料がそろったところで分析を始めます。あくまでもシステム全体の視点から分析することが重要で、個々の情報を個別に分析することはしません。それを行うと時間がいくらあっても足りなくなるからです。

 材料(入出力情報とデータ)を集めることと、分析を分けることが大事です。



■関連記事
要件定義ツールを使った既存システムの分析
Google製のC++ Unit Test Framework「Google Test」を使ってみる
UMLを使った既存システムの分析
TDDBC大阪の課題をC#でやってみる ~ クラス設計とTDD
C++11 : スレッド・ライブラリひとめぐり

■記事全文へ

CodeZine

トピックスRSS

ランキング