レガシーシステムの設計手法

次に、オブジェクト指向アプローチによる業務分析について考えてみる。

オブジェクト指向アプローチでは、業務にとって重要な概念をクラスとして抽出する（ここでは、そのようなクラスのことを「ビジネスエンティティ」と呼ぶ）。次に、UML のクラス図などを用いて、抽出したビジネスエンティティ間の関係を記述する（図4）。また、ビジネスエンティティのインスタンスが業務の中でどのように状態を変えていくのかを把握するために、UML のアクティビティ図などを用いて業務フローを記述する（図5）。図5 にも示したように、業務フローでは、ビジネスエンティティのインスタンスを各業務処理の入力情報および出力情報として記述する。このように、オブジェクト指向アプローチで業務分析を行う際には、主な検討対象はクラスとなる。

図4：ビジネスエンティティ間の関係を表すクラス図

図5：業務フローを表すアクティビティ図

今度は、オブジェクト指向アプローチによるシステム設計について考えてみよう。

例えば、商品の発注業務システムの場合、クラス Hinmoku などを設計して実装する。上述したように、このクラスは、データと処理を組み合わせたものとなる。

図6 に、クラス Hinmoku を含む設計モデルを示す。なお、図6 には、この設計モデルの位置づけを明確にするために、システム開発の各工程（注4）で作成される成果物を、開発工程に沿って示した。すなわち、ビジネスモデル（注5）が業務分析工程の成果物、分析モデル（注6）がシステム分析工程の成果物、設計モデルがシステム設計工程の成果物、実装モデル（ソース・コード）が実装工程の成果物となる。

オブジェクト指向アプローチには、業務分析の結果（ビジネスモデル）を、システム分析の結果（分析モデル）やシステム設計の結果（設計モデル）と比較しやすいという特徴がある。さらに、設計モデルと実装モデルを比較しやすいということも、図6 から理解できるだろう。なぜなら、オブジェクト指向アプローチでは、すべての開発段階において、クラスの単位で成果物を管理するからである。つまり、クラスの存在により、業務やプログラムの変更個所を特定しやすくなっているのである。

図6：オブジェクト指向アプローチにおけるモデルの変化

データ中心アプローチにおける業務分析は、次のように行う。

まず、オブジェクト指向アプローチの場合と同様に、業務にとって重要な概念を洗い出す。ただし、データ中心アプローチでは、重要な概念を、クラスではなくエンティティとして抽出する。エンティティとは、簡単にいえば、オブジェクト指向アプローチにおけるクラスから処理（操作）を除いたものであり、これがデータ構造を表す。エンティティを洗い出す際には、システムを構成する画面や帳票を参考にする。

なお、データ中心アプローチにおいても、処理を管理しないわけではない。このアプローチでは、CRUD マトリクスを使い、どのデータがどの処理で作成／参照／更新／削除されるのかを管理する（図8）。C，R，U，D は、それぞれデータの作成、参照、更新、削除を表す（注7）。

図8：CRUD マトリクス

データ中心アプローチでは、以上のような方法により、データと処理の組み合わせを管理するのである。

次に、システム設計の観点から、データ中心アプローチを見てみよう。

データ中心アプローチには、オブジェクト指向アプローチにおけるクラスに相当する概念が存在しない。そのため、別の方法によってデータと処理の管理を行うことになる。

オブジェクト指向アプローチでは、開発者がクラスを指定すれば、そのクラスが持つデータと処理を特定できる。それに対して、データ中心アプローチでは、開発者はデータと処理の外部に、それらを管理するためのリポジトリ（ツール）を用意する必要がある（前掲の図7を参照してほしい）。このリポジトリによって、どのデータがどの処理で使われているのかを管理するのである。データ項目に対する変更などが発生した場合、開発者はリポジトリを参照して、その変更の影響が及ぶ処理（プログラム）を特定する。

なお、リポジトリによってシステムの外部からデータと処理の組み合わせを管理する方法には、システムの保守性に関して、1 つ問題がある。データ中心アプローチでは、データを正規化することによってデータ項目の重複を防止できるが、処理内容は正規化できない。つまり、処理内容の重複までは排除できないのである。そのため、複数のプログラムに同じ処理が存在するという状況が発生しやすい。その場合、何か変更が生じた場合には、複数のプログラムを修正する必要が生じる。つまり、システムの保守性が低下するのである。

上記のような問題点がある一方で、プロセス中心アプローチの考え方の中には、オブジェクト指向アプローチに引き継がれているものもある。それは、「システムを分割する」という考え方である。プロセス中心アプローチでは、機能（つまり処理）の単位でシステムを分割するが、オブジェクト指向アプローチでは、クラスの単位でシステムを分割する。

また、プロセス中心アプローチにおけるモジュール分割の方針には、オブジェクト指向アプローチに応用できる部分もある。それは、プログラムを処理の固まり（モジュール）に分割するということである。分割が妥当かどうかは、モジュール間の結合度が低いかどうか、モジュールの強度が高いかどうかの 2 点で判断する。モジュール間の結合度はモジュール間の結びつきの強さを示し、モジュールの強度はモジュールが持つ機能の独立性を示す。理想的なモジュールは、他のモジュールとの結合度が低く、またそれ自身の強度が高いものである（図10）。このような考え方は、オブジェクト指向アプローチにおけるクラスの分割にも適用できるだろう。

図10：理想的なモジュール

1 つ目のポイントは、従来アプローチで使う CRUD マトリクスは、オブジェクト指向アプローチにおいて必須ではないという点である。なぜなら、CRUD マトリクスはデータと処理の組み合わせを整理するためのドキュメントであるが、オブジェクト指向アプローチでは、データと処理との組み合わせについての情報をクラス図に記述できるからである。具体的には、クラス図中の各クラスの属性がデータであり、操作が処理となる。

ただし、オブジェクト指向アプローチでも、CRUD マトリクスが有効な場合がある。例えば、クラスの中に複数の属性があるとしよう。それらの属性に対して値を設定するタイミングがそれぞれに異なる場合は、クラスを分割することもありうる。このようなとき、クラスの分割方針を検討するのに CRUD マトリクスを使える。

2 つ目のポイントは、オブジェクト指向アプローチでは、プログラムの外部仕様を決めるためにロバストネス図を記述することがあるという点である（図11）。ロバストネス図は、ユースケース（システムの機能の一部）を構成するクラスを「バウンダリクラス」、「コントロールクラス」、「エンティティクラス」（注8）の 3 種類に分け、それぞれのクラスがどのような役割を担うのかを示すためのものである。

図11：ロバストネス図

ビジネスアプリケーションの場合、バウンダリクラスは、主としてシステムのユーザーに対して提供される成果物である。つまり、ユーザーは、バウンダリクラスを通じてシステムとかかわるのである。ユーザーとシステムとの境界（バウンダリ：boundary）は、画面や帳票となる。また、コントロールクラスは、システムの挙動を制御するクラスである。ある画面の次にどの画面を表示するかなどは、コントロールクラスが制御する。そして、エンティティクラスは、長期間存在するものを表すクラスである。

従来アプローチでは、プロセスチャートなどを用いて設計書を記述する。一方、オブジェクト指向アプローチでは、ロバストネス図を使うことによってプロセスチャートなどを代替できる。従来アプローチで使うプロセスチャートには、どの画面がどのデータを使うのかといった処理の流れを記述する。プロセスチャートと同様の役割を果たすロバストネス図も、入出力画面や利用するデータ、処理の流れを記述するためのドキュメントと見なせる。

3 つ目のポイントは、オブジェクト指向アプローチでは、プログラムの内部仕様を決めるために、設計モデルのクラス図を記述するという点である。具体的には、クラス図にクラス間の関係やクラスの属性、クラスの操作を記述する。このようなクラス図は、従来アプローチにおけるモジュール構造図（注9）に相当するものである。

4 つ目のポイントは、バウンダリクラス、つまり画面や帳票に関する設計書の内容が異なるという点である。

従来アプローチの画面設計書では、文字の表示位置などを精密に指定する。一方、オブジェクト指向アプローチでは、Web ブラウザに表示する画面などの設計は、もう少しシンプル（大まか）になる。ただし、ボタンの位置や配色などについては指針が必要である。また、画面中のどのボタンをクリックするとどの画面が表示されるのかといった画面遷移については、UML のステートチャート図などできちんと定義しておかなければならない。

従来アプローチでは、帳票についても厳密な設計書（図12）を作成していたが、オブジェクト指向アプローチでは、やはりこれも多少シンプルになる。とはいえ、定型的な帳票については、オブジェクト指向アプローチでも、文字の印刷位置などを綿密に指定する必要がある。

図12：従来アプローチにおける帳票設計書のイメージ

Java で対話型の Web システムを構築する場合、画面での入力内容のチェック方式が、レガシーシステムとは異なることがある。メインフレームの場合、基本的に、画面への入力内容をクライアント側ではチェックしない。しかし、Web システムでは、クライアントの Web ブラウザ上で JavaScript などを実行し、入力内容をチェックすることがある。したがって、バウンダリクラスを設計モデルに変換する場合には、入力内容をクライアント側でもチェックするのか、それともサーバ側だけでチェックするのかについて、指針が必要となる。

5 つ目のポイントは、RDB を採用する場合、オブジェクト指向アプローチでも、入出力データの設計時に ERD を記述する必要があるという点である。その際、IDEF1X などの ERD 専用の表記法を使ってもよい。なお、従来アプローチで使うファイル設計書のファイル項目は、クラスの属性になる点に注意してほしい（図13）。

図13：従来アプローチにおけるファイル設計書のイメージ

なお、新システムの開発に EJB を使う場合、RDB のテーブルは Entity Bean という形でメモリ中のオブジェクトにすることができる。通常、RDB のテーブルは操作（処理）を持たず、そこにはクラスの属性に相当するデータのみが格納される。一方、Entity Bean には、テーブルに格納されているデータだけではなく、処理も持たせることができる。Entity Bean は、データと処理を持った「永続化可能なクラス」である（注10）。