１．オブジェクト指向設計とは

オブジェクト指向のメリットは、何といっても「もの」という人間的な認識の単位でソフトウェアを構築できるというところにあります

0と1のビット列で物事を考えているわけでない人間にとって、これは非常に有益なことと言えます。理想的には、分析者の頭の中に浮かんだ「ナチュラルなもの」が、そのままコンピュータ上に写像され、様々な問題解決処理が自動的に行われてしまえばこれに越したことはありません。

しかしそれほど甘くないのが世の中です。実際には、「現実世界のもの」に加えて「現実世界には存在しない技巧的なもの」もコンピュータ上に用意してあげなければ、本当に役に立つシステムは作れないのです。

通常ソフトウェアには、何らかの問題を解決するための要求が課せられますが、これはユーザの視点から見た場合、大きく分けて2種類に大別されます。

例えば、「銀行口座の預金を行わせたい」、「商品の受注を行わせたい」など、業務に比較的近い観点からの要求があります。これはシステムに対して論理的に実施してもらいたい「純粋な機能」といえます。

一方で、論理的な機能が実現されただけでは、ユーザが納得することはありません。「口座の預金処理のレスポンスは10秒以内でなければならない」「受注情報は二重化されたデータベースに保存すること」といった、実行性能や堅牢性などについての要求もあります。この場合は、機能とは別個のいわば「非機能的」な事項をシステムに求めていると考えられます。

また、今度はソフトウェアを使う側でなく、作る視点に立って考えてみましょう。「機能的」「非機能的」の両方について、ユーザの要求はたえず変化します。開発者側は、こうした変化する要求に対処するため、ソフトウェアの製作や、変更にかかるコストを最小限にしようと考えます。既存のライブラリの使用を検討したり、たとえ自分で作り込む量が多くなったとしても、なるべく次期のプロジェクトでも使えるように再利用性の高い部品としてソフトウェアを作りたいと考えるのが自然でしょう。こうした再利用性、保守性に関する要求は、「開発者側要求」とでも呼べるものです。

このように、現在のソフトウェアが解決しなければならない問題は、多くの側面を持っています。単に「機能的な要求」のみを満足させることを考えた場合には、その問題領域となる業務自体を熱心に分析することによって、オブジェクトとしてモデル化の作業を進めていくことができます。しかし「非機能的」な要求は、ネットワークのバンド幅やデータベースといった、純粋な業務とは別個の物理的なものに深く根差しているため、ナイーブな、業務だけを純粋に見ようという姿勢だけでは不十分なところがでてきます。この場合は視点を「業務」よりは「情報システム自体」に移さないと、問題解決の手助けとなるオブジェクトを切り出していくことができません。更に、移り変わりの激しい現在のビジネスにおいては、ソフトウェアも常に変化していかねばならない宿命を背負っています。変化する部分をきちんと見定め、全体を作り替えずとも特定部分の取り替えによってシステムを容易に拡張できるような工夫を行っておかないと、すぐに使えないものなってしまいます。そのために、現在扱っている対象領域から、多少独立性の高い「プラグイン部品」としてオブジェクトをとらえていくことも時には必要になるのです。

従来のオブジェクト指向分析、設計方法では、比較的ナイーブな視点に立ち、「機能的な要求」のみを中心事項として扱い、その他の視点に関してはあまり注目していなかったのが実状です。しかし、オブジェクト指向による大規模、本格的なシステムの構築事例が増えてくるに従い、こうしたアプローチだけでは不十分なことが徐々に分かってきました。

「機能的」な要求に関しては、基本的に業務分析を行っていくことで対処できますが、それ以外の要求は範囲の外に置かれてしまいがちです。従来のやり方では、設計の段階で、各人の職人的な技量によって「なんとなく」設計用のオブジェクトが補完され、「機能的」以外の要求が充足されていくやり方が蔓延していました。(充足されない場合もありました)。

しかしソフトウェア作りを産業として見た場合には、その開発はもっと戦略的に行われていかねばなりません。

旧来のナイーブなやり方の反省として、Unified Processによるオブジェクト指向分析/設計方法では、「アーキテクチャ中心」という考え方が提唱されています。
この方式では分析の段階から、ユースケースによる業務分析に並行して、システムの実現に必要になるであろうアーキテクチャについての検討をしっかりと行います。これは業務分析に対してアーキテクチャ分析と呼ばれます。設計段階では、アーキテクチャ設計として更に検討が行われ、設計用オブジェクトがドメインモデルと依存性の少ない形で統合されていきます。
このようにUnified Processでは従来のOO開発プロセスに比べ「設計」の重要性が強調されています。ソフトウェア開発にまつわる様々な要求を実現させていくには、単純な業務のみの分析では不十分で、「設計」という作業を意識的に行っていかなければならないのです。

問題領域の分析だけで、一人前のシステムが出来上がらないといってなげくことはありません。「オブジェクト指向で現実世界そのものをあらわす」といっても、本当に必要なのは現実世界「そのもの」ではなく、現実世界をあらわして問題解決を行うソフトウェアという一種の「機械」だという認識が肝心です。機械には、それを動作させるための機構(メカニズム)があるのが当然であり、そのうまい機構や、機構を実現するための部品を作り上げていく「設計」作業は不可欠であると言えます。

一見、泥臭く、オブジェクト指向の基本から離れているようですが、この態度こそが現実を見据えており、正しい世界のとらえ方をしているということになるのです。

Index