ObjectSquare [2004 年 9 月号]

[技術講座]


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

レガシーマイグレーションで、オブジェクト指向アプローチを採用するために

ビジネスプロセスモデリング部
筒井彰彦


1. はじめに

COBOL 技術者の引退や、ハードウェアのダウンサイジングに伴い、Java 技術者には、レガシーマイグレーション(注1)の業務が増える可能性がある。ところが、Java 技術者の育った文化と、レガシーシステム(注2)の文化は異なる。具体的には、それぞれの文化で使う専門用語は異なっている。さらに、専門用語よりも重要な相違として、専門用語の土台となる開発手法が挙げられる。

開発手法に焦点を当てると、多くのレガシーシステムは、データ中心アプローチやプロセス中心アプローチといった従来的な開発手法に基づいて開発されてきたといえる。したがって、レガシーシステムの仕様を理解するためには、こうした手法の特徴を知っておく必要がある。そこで本稿では、現在のシステム開発で主流を成すオブジェクト指向アプローチと比較しながら、データ中心アプローチとプロセス中心アプローチについて説明する。また後半部では、各アプローチにおいて作成されるドキュメントを比較し、レガシーシステムの仕様を把握する上でのポイントを紹介する。

※注1 : 本稿でいうレガシーマイグレーションとは、老朽化したビジネスアプリケーションを新しいソフトウェアとハードウェアで置き換える業務を指す。

※注2 : 本稿でいうレガシーシステムとは、次のようなシステムを指す。すなわち、主要な開発言語として COBOL を使い、開発プロセスとしてウォータフォール型を採用するようなシステムである。レガシーシステムは、メインフレーム(大型汎用機)の上で稼動する。


2. 開発手法の変遷

現在のシステム開発においては、開発手法として「オブジェクト指向アプローチ(OOA:Object Oriented Approach。オブジェクト指向手法とも呼ばれる)」が広く用いられている。このオブジェクト指向アプローチが主流になる以前は、データ中心アプローチ(DOA:Data Oriented Approach)やプロセス中心アプローチ(POA:Process Oriented Approach)といった手法が多用されていた(図1)。レガシーシステムは、これらの従来的な手法に基づいて構築されているケースが多いため、レガシーシステムの仕様を理解するためには、それぞれの開発手法の特徴を知っておく必要がある。

以降では、オブジェクト指向アプローチと比較しながら、データ中心アプローチとプロセス中心アプローチの特徴を説明していく。特に、「開発の単位は何か」、「開発の単位をどのように管理するのか」という 2 つのポイントを中心に、各開発手法の特徴を整理してみたい(注3)。

※注3 : 本稿では、便宜上、データ中心アプローチとプロセス中心アプローチを総称して従来アプローチと呼ぶ。

開発アプローチの変遷
図1:開発アプローチの変遷

3. オブジェクト指向アプローチの特徴

まずは、オブジェクト指向アプローチの特徴を確認しておこう。

オブジェクト指向アプローチとは、「オブジェクトを組み合わせてシステムを構築する」という開発手法である。

オブジェクトは、「データと処理をカプセル化した単位」であるクラスを基に生成(インスタンス化)される。ここでいうカプセル化とは、データと処理をクラスにまとめ、細かいデータ構造や処理の内容を外部から隠蔽することを指す。つまり、オブジェクト指向アプローチでは、クラスとオブジェクトの間の関係、およびシステムの内部構造を、図2 のようにとらえているわけである。図中にも示したように、システムは、オブジェクト間でメッセージが送受信されることによって動作する。

クラスとオブジェクトの関係
図2:クラスとオブジェクトの関係

オブジェクト指向アプローチでは、基本的にクラスの単位でシステムを開発する。したがって、開発者が管理しなければならない対象は、クラスだということになる(図3)。

オブジェクト指向アプローチにおけるクラスの管理
図3:オブジェクト指向アプローチにおけるクラスの管理

なお、カプセル化によって作成されるクラスのことを、「抽象データ型」と呼ぶ場合がある。抽象データ型とは、複数のデータ型と、それらのデータ型に関連する処理をまとめた"雛型"だと考えればよい。オブジェクト指向アプローチでは、システムの開発者が、そのシステムに固有のデータ型を新たに定義できる。しかし、そのとき、多くの場合には、まず抽象データ型を(抽象クラスやインタフェースなどとして)定義する。その上で、抽象クラスやインタフェースを基にして個別のクラスを作成していく。このような手法が、オブジェクト指向アプローチの基本となる。

オブジェクト指向アプローチによる業務分析

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

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

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

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

オブジェクト指向アプローチによるシステム設計

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

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

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

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

※注4 : 本稿でいう工程は、IBM Rational Unified Process(RUP)の作業分野(Discipline)のように厳密に定義しているわけではない。

※注5 : RUP では、ビジネスモデルという用語を使わない。RUP のビジネスモデリングという作業分野では、ビジネスユースケースモデルやビジネス分析モデルなどを作成する。

※注6 : RUP では、分析モデルと設計モデルを作成するのは、「分析と設計」という 1 つの作業分野においてであり、しかも、分析モデルの作成についてオプションとなっている。

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

3. データ中心アプローチの特徴

オブジェクト指向アプローチでは、データと処理の組み合わせであるクラスを管理する。一方、データ中心アプローチは、その名のとおり、処理よりもデータの構造を重視した手法である。データに注目する理由は、処理と比べるとデータのほうが安定しているからである。また、DFD (Data Flow Diagram) や ERD (Entity Relationship Diagram) といったダイアグラムを多用する点も、この開発手法の特徴である(図7)。

データ中心アプローチにおけるデータと処理の管理
図7:データ中心アプローチにおけるデータと処理の管理

データ中心アプローチによる業務分析

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

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

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

※注7 : C,R,U,D は以下の英語の頭文字である。
C − Create
R − Retrieve あるいは Read あるいは Refer
U − Update
D − Delete

CRUDマトリクス
図8:CRUD マトリクス

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

データ中心アプローチによるシステム設計

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

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

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

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


4. プロセス中心アプローチの特徴

データ中心アプローチでは、処理よりもデータを重視する。それに対して、プロセス中心アプローチでは、処理(プロセス)の単位に注目してプログラムを管理する。具体的には、図9 に示すように、1 つの処理を細かい処理に分割していく。そのため、システムを構成するプログラムは、その処理に関して階層構造を持つことになる。

プロセス中心アプローチにおける処理の分割
図9:プロセス中心アプローチにおける処理の分割

ただし、このアプローチには限界がある。それは、処理を重視するあまり、データの軽視につながるという点である。その弊害として、例えばデータ項目を統一しづらくなるというような問題が発生する。なぜなら、このアプローチでは、基本的に、最初に処理を決めてから、それに合わせてデータを決めるからである(データ中心アプローチの場合、最初にデータを標準化するため、重複したデータ項目が発生しにくい)。

上記の問題は、仮にプログラムを解析するためのツールがあったとしても、解決することはできない。ツールを使っても、どのデータ項目が重複しているのかは、データ項目のネーミング・ルール(命名規則)によってしか把握できないからである。したがって、プログラムの保守性は、プログラムの設計/開発者がネーミング・ルールを遵守するかどうかに左右される。ネーミング・ルールが無視された場合、あるデータ項目の変更がプログラムにどのような影響を及ぼすのかを把握することはできないのである。

プロセス中心アプローチとオブジェクト指向アプローチ

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

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

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

5. システムを適切に設計するために

以上、オブジェクト指向アプローチと従来アプローチの特徴を説明した。

繰り返しになるが、オブジェクト指向アプローチには、クラスによってデータと処理の両方を管理するため、業務やプログラムの変更個所を特定しやすいという長所がある。

ただし、ここで注意してほしいのは、オブジェクト指向アプローチを採用したからといって、それだけで適切な設計が行えるわけではないという点である。例えば、Java でシステムを構築する場合でも、1 つのメソッドが多くの処理を持ちすぎたり、2 つのクラスが相互にメソッドを呼び出し合ったりするのは、システムの設計上、不適切である。データと処理をカプセル化する Java においても、このような不適切な設計が行われるのを未然に防ぐことはできないのである。

このような問題を解決するには、開発プロジェクトで設計指針を決め、各メンバーがそれを遵守しなければならない。その点は、オブジェクト指向アプローチでも従来アプローチでも同じである。


6. 設計ドキュメントの比較

ここからは、オブジェクト指向アプローチで作成されるドキュメントと、従来アプローチで作成されるドキュメントを比較しながら、それぞれの開発手法の相違点をより具体的に見ていく。また、Java 開発者がレガシーシステムのドキュメントを読む際のポイントも説明する。

表1 は、オブジェクト指向アプローチと従来アプローチで作成される主なドキュメントを比較したものである。同じ用途に向けたものでも、開発手法によって作成されるドキュメントが大きく異なることに気づくだろう。以下、表1 における比較でポイントとなる点を説明していく。

表1:作成されるドキュメントの例
ドキュメントの用途
オブジェクト指向アプローチ
従来アプローチ
データと処理との組み合わせに関する設計
設計モデルのクラス図
(UML のクラス図で記述する)
CRUD マトリクス
プログラムの外部仕様の設計
ロバストネス図
(UML のクラス図で記述する)
プロセスチャート
プログラムの内部仕様の設計
設計モデルのクラス図
(UML のクラス図で記述する)
モジュール構造図
システムで使う画面に関する設計
画面設計書
(画面の遷移について UML のステートチャート図(UML 2.0 におけるステートマシン図)などで記述する。画面はバウンダリクラスである)
画面設計書
システムで使う帳票に関する設計
帳票設計書(帳票はバウンダリクラスである)
帳票設計書
入力データと出力データに関する設計
設計モデルのクラス図
ERD (ERD は IDEF1X などで記述する)
ERD
ファイル設計書(ファイルレイアウト)


データと処理の組み合わせに関する設計

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

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

プログラムの外部仕様の設計

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

※注8 : エンティティクラスは、データ中心アプローチにおけるエンティティとは異なる。エンティティクラスには操作(処理)があるが、エンティティには操作はない。

ロバストネス図
図11:ロバストネス図

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

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

プログラムの内部仕様の設計

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

※注9 :モジュール構造図は、モジュール関連図と呼ばれることもある。モジュール構造図は通常、矩形で表現される複数のモジュールが木構造を成すような図である。モジュール構造図では、1 つのプログラムを複数の処理に分割する。バッチ処理を行うプログラムは通常、初期処理、主処理、終了処理に分割できる。初期処理では、ファイルをオープンしたり、ファイルに存在する 1 件目のレコードを読み込んだりする。主処理では、ファイルのレコードが存在しなくなるまで、何らかの計算を行う。終了処理では、ファイルをクローズしたりする。オンライン処理(対話型処理)のプログラムも基本的にバッチ処理のプログラムと同じような構造を持っていた。

画面/帳票の設計

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)。

※注10 : クラスのインスタンスを RDB のレコードとして永続化する場合には、JDO (Java Data Objects) という仕組みも今後検討すべきである。

《参考文献》

     
  1. 『ラショナル統一プロセス入門』
    著者:フィリップ・クルーシュテン氏/発行:ピアソン・エデュケーション,2001 年

  2.  
  3. 『ソフトウェアの複合/構造化設計』
    著者:グレンフォード・J. マイヤーズ氏/発行:近代科学社,1979 年

※本記事は、『Java WORLD』 2004 年 4 月号に掲載された拙稿「レガシー・システムの設計手法」を加筆、修正したものです。


記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。
  

© 2004 OGIS-RI Co., Ltd.
Prev. Index
Prev. Index