UMLを使った既存システムの分析

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

バリエーションに対応する

　システムの分析にはいくつかのバリエーションがあります。ここでは画面とバッチ処理のバリエーションを説明します。

複数リクエストへの対応

　システムによっては一つの画面で意味の異なるリクエストを発生させる場合があります。例えば一つの画面に検索や登録などの機能を持つ場合、1画面に2つのイベントがあると考えます。表現方法としては1つの画面アイコンに2つのイベントアイコンを対応づけます。同時に手続きにともなうルールをまとめるときも、状態の遷移に各々のイベントを対応づけることで画面の役割を正確に表現できるようになります。

バッチを分析する

　バッチ処理を分析するときは以下の2点に着目して調査分析します。

• ファイル交換を目的とした処理を探しイベントとして整理する
• バッチ処理の順番を決めている要因を把握する

　バッチ処理の中には純粋に大量データを処理しているものと、ファイル交換を目的としたバッチ処理があります。ファイル交換用のファイルがバッチ処理の中で使われている場合は、データを取り込む、またはデータを渡すことを行っています。これらはバッチ処理と考えずに定周期で発生するイベントとして洗い出し、バッチ処理には含めません。

　夜間バッチのような処理の場合は複数の処理が決められた順番で処理されます。その順番をバッチが扱っているファイルやRDBのテーブルの内容から類推してまとめ、保守担当者にヒアリングします。多くのプロジェクトではバッチ処理の内容について詳しく知っている人はおりません。ヒアリングではバッチについての直接的な情報を得ることよりも、類推した結果の妥当性を確認する事を優先します。

　バッチの分析はあまり深入りせずに上記の調査がある程度できた時点でやめ、プログラムを個々に調べることはしません。

　システムの地図にはバッチ処理は含めません。それはシステムの実現方法として選択した処理形態の一つでしかないからです。重要なことはその中から入出力情報とビジネスルールを明らかにすることであり、バッチ処理そのものではありません。

　ファイル交換の洗い出しはバッチに隠れた入出力の洗い出しです。また、バッチ処理の実行順序の依存性はビジネスルール発見のきっかけのために実施します。

　バッチ処理の分析は目的を絞り調査することが重要です。まともに調査すると相当時間がかかります。詳細な調査は後工程で必要になったときに実施します。

隠れた意図をあぶり出す

レイアウトの嘘を見抜く

　長年保守されてきたシステムではファイルやテーブルのレイアウトは様々な意味で使われることがあります。名前通りの値が入っているとは限りません。例えば「XX区分が3の時にはこの入金額には入金額がセットされるが、XX区分が4の時には値引き額がセットされる」というようなケースがあります。通常このような条件はテーブルレイアウトにコメントとして記載されています。それらの条件の中にはビジネスルールに起因するものと、処理の方式上必要になったものがあります。

　一見してどちらかが見分けられないときは、他の作業と合わせて考慮し、ビジネスルールと認識できたものを抽出します。

タイミングの罠に気をつける

　レイアウトと同じく処理のタイミングもごまかされる時があります。例えば5分周期で通信していた処理に10分周期の情報が紛れ込んでいる場合などです。もともと5分周期の処理があり、そこに新たに10分周期の処理を追加する必要が生じたときに、新たな処理を作成するのは大変なので、既にある5分周期の処理に紛れ込ますケースがこれにあたります。こうなると5分周期の処理を認識できても、そこから10分周期の処理を見つけることは困難です。

　このようなケースに対応するためには、タイミングは表面上の情報だけでは分からないということを頭の片隅においておく必要があります。