新人およびOO初心者に贈る「オブジェクト指向」本格入門

[1999 年 4 月号]

［新人およびOO初心者に贈る「オブジェクト指向」本格入門］

４．開発プロセスとパターン/アーキテクチャ

オブジェクト指向で開発を行う場合に基本的には、要求分析、システム分析、システム設計、オブジェクト設計、実装というサイクルをスパイラルに数回繰り返しながら、最終的なシステムに仕上げていきます。従来もこうした繰り返し型の開発がやりたかったプロジェクトも多々あったわけですが、オブジェクト指向をベースにした開発になるまではスパイラル方式を採用できなかったのが実状です。としうのも、サイクルの各フェイズで用いる概念とダイアグラムがまったく異なっており簡単には行ったり戻ったりできなかったからです。それに対し、オブジェクト指向の場合、分析、設計、実装といった各フェイズで用いられる概念も図式もともにオブジェクトモデルであり、かつUMLという標準のダイアグラムであるため、オブジェクトを単位として作業の各フェイズでのトレーサビリティを確保しやすいのです。

ところが、トレーサビリティをつけやすいといっても従来のOO開発技法にはどうしても分析と設計の間に大きなギャップがありました。従来は、分析モデルを「詳細化」して設計モデルを得るというガイダンスがなされ、分析モデルにアドホックに設計上のクラスや属性･操作を追加してお茶を濁していたのです。しかし、実際には設計では、ターゲットプラットホームの制約や効率、ミドルウェアやクラスライブラリの特性を考慮した微妙なセンスが要求されるもので、結局、能力のある設計者に任せざるを得ませんでした。

それに対し、近年、分析モデルと設計モデルの関係に対する見直しが図られています。分析モデルは設計モデル中の問題ドメインサブシステムおよびアプリケーションサブシステムの一部に埋め込まれるものだという考え方です。設計モデルを考える際に、システム構成を表現したアーキテクチャの上で個別の設計を詰めていくという方針です。アーキテクチャは問題ドメインの性格、特に制御の特性に応じて構成が変わることが知られていますが、標準的なアーキテクチャは、プラットホーム層、ミドルウェア層、問題ドメイン層、アプリケーション層、プレゼンテーション層といった構成になります。

オブジェクト設計に関しても、最近は、設計目標に応じたデザインパターンをパターンカタログから選び設計制約を満足させるという手法が提唱されています。デザインパターンとは、設計課題とそれに対する一般的な解決策をペアにして記述した解法テンプレート集です。オブジェクトの生成方式に関するさまざまなファクトリパターン、複合オブジェクトの構成方式やアクセス方式に関するパターン、複数のオブジェクト間の相互作用や通信・制御の方式に関するさまざまなパターンがあります。再帰的な集約オブジェクトの構成法であるコンポジット・パターンやサブシステムの共通APIを提供するファサード・パターン、オブジェクト間の間接的な依存関係を実現するオブザーバ･パターン、代理オブジェクトによるアクセス制御を提供するプロキシー･パターン等が代表的なものです。

実際には、カタログから選んだ解法を個別状況に合わせてカスタマイズする作業が発生しますが、カタログにどのようなパターンが載っているかあらかじめその全体像を習得しておくことで、効率的にある程度の設計が平均的なエンジニアにも行えるという大きな利点があります。現在普及しているデザインパターンは柔軟性や拡張性や保守性を目標としたものがほとんどで、特定の機能や効率といった目標を解決するパターンの開発は今後の課題です。逆に言うと現在のデザインパターンは、設計において効率よりもソフトウェア工学上の原則を最大限引き出すためのものがほとんどです。

FIg.5

図5：システムアーキテクチャとトレーサビリティ

またデザインパターンは、アーキテクチャと組み合わせることによって、システム設計を補強することができます。つまり、問題ドメイン層を始めとする個々のレイヤー間のスムーズな接続と頑健さの増強に、デザインパターンを｢糊｣として使い、全体として設計モデルを構造化するという技法です。各レイヤー間のインターフェースにファクトリ、シングルトン、ファサードやオブザーバ、プロキシー･･･といったパターンが有用です。さらに各レイヤー内のサブシステム内ではほとんどすべてのパターンがオブジェクト設計に活用できます。

オブジェクトの単位でなくもっと大きなアプリケーションの単位で再利用性を提供するものにフレームワークがあります。サブクラスを定義することで実際実行可能なアプリケーションプログラムを提供するものです。汎用的な制御ロジックを抽象クラスのレベルでテンプレートメソッドとして記述しておき、変更可能部分をサブクラスのメソッドとして追加定義させる仕組みです。パラメータ部分自身がオブジェクト化されているわけです。こうすることで、ERPパッケージなどより非常に柔軟なカスタマイズを可能にしています。こうしたフレームワークはGUI分野に始まり、最近ではプロセス制御や金融派生商品リスク管理といった特定の業務ドメイン用のものも登場してきています。また、ビジネスドメインでのフレームワークの基本部品のことをビジネスオブジェクトと最近では呼びます。フレームワークやビジネスオブジェクトの設計にもデザインパターンは活用されています。

フレームワークの利用には一部コーディングが必要でしたが、継承を使わず、したがってコーディングも再コンパイルも必要なく、一切を既存部品オブジェクト(コンポーネントと呼ぶ)の組合せ(ワイヤリング)だけで済ませる方式をコンポーネントウェアと呼びます。コンポーネント実現のポイントは、通常のオブジェクトと違い、外部インターフェースとして呼び出し可能な操作のセットだけでなく、そのコンポーネントの内部状態遷移を示す外部イベントのセットも公開していることです。したがって、ソースコードを参照することなく、コンポーネントどうしで必要なメッセージのフローを組み合わせる（すなわちワイヤリングする）ことができるわけです。

Prev.

Index