*begin*back*foward*end*contents

コンセプト編 - 第4章 Dropの目指すもの

4.1 Drop開発の経緯

オブジェクト指向方法論は、オブジェクト指向言語の普及に伴い、様々な開発で使われるようになった。

日本においては1990年前半より、OMT法、OOA/OOD、BOOCH法、OOSEなどの訳本が発刊され、オブジェクトモデルの形式的な表記法が紹介されてきた。

このような言語の普及と方法論の充実によって、ビジネスアプリケーションをオブジェクト指向によって開発するケースも多く見られるようになってきている。

しかしながら、ここ数年、オブジェクト指向開発において、オブジェクト指向方法論では解決できない様々な問題も指摘されるようになってきている。

このような問題は、「オブジェクト指向方法論がまだ未熟である」、「他の技術と同様に魔法の技法ではない」という2点から生じている。

既存のオブジェクト指向方法論は、オブジェクト指向言語とは異なり革新的なものではない。それは、あくまで構造化方法論で使用された表記方法や手法をベースに一部拡張を加えたものにすぎない。

しかし、方法論利用者は、このような方法論に対して多大に期待をしてしまったり、何か革新的技術にでも取り組むかのように身構えてしまったりすることも多いようである。

実際には現在のオブジェクト指向方法論は構造化方法論と比較して同レベル程度の進歩しかとげていないのが実状である。つまり、単に言語のパラダイムが変わっただけであり、手法のパラダイムを変えたわけではない。

筆者は、従来のオブジェクト指向方法論の問題は、方法論としての技術領域の範囲の狭さと構造化方法論をベースとするアプローチのまずさにあるのではないだろうかと思い始めた。

このような疑問がきっかけとなり、筆者は、オブジェクト指向方法論とオブジェクト指向開発プロセスの融合研究と実践を1993年より進めてきた。

そして、1996年8月にオブジェクト指向方法論Drop v1.0としてその成果を公開した。

WWWを使って公開したDrop v1.0は、筆者として満足できるものではなかった。Drop v1.0を作成した当時は、オブジェクト指向開発のルール部分を定めることが精一杯であった。

Dropのコンセプトを正しく伝えることを疎かにしてしまった。

v1.0をリリースしてから約2年経過した今、このような反省も兼ね、さらに新たな構想を加えて、ここにDrop v2.0を公開するまでに至った。

4.2 オブジェクト指向方法論の問題点

従来のオブジェクト指向方法論の問題は、方法論としての技術領域の範囲の狭さと構造化方法論をベースとするアプローチのまずさにあると述べた。ここでは、これによって引き起こされる諸問題を具体的に述べる。

オブジェクトの発見、構築に関する問題

ソフトウェア開発サイクルの各フェーズで見つけだされるオブジェクトの性質は異なるものでなければならない。

たとえば、実世界を理解するために作り出したオブジェクト(現状認識モデル)や、その理解を基に戦略を加味して最適化されたモデル(戦略モデル)と、システム要求を基に見つけだされるオブジェクト(要求モデル)は性質がまったく異なる。

また、このような分析的な視点で抽出された概念的なモデルと、クラスライブラリをベースにして作成されるオブジェクト(アーキテクチャモデル)も、性質が異なるものである。

従って、各開発フェーズでは観点を変えてオブジェクトを抽出しなければならない。

しかしながら、従来のオブジェクト指向方法論は、これを明確に示していないものが多い。

特に、実世界のモデルを、ある制約されたシステム要求に移し替える時のモデル変換の必要性について曖昧な点が多い。

この問題により、システム要求が不明確なまま設計、実装へ流してしまうという問題が起こる。

さらに、設計において既存資産のクラスライブラリなどの再利用コンポーネントをどのようにモデルに統合するかという具体的な指針も示していないことがある。

再利用性、そして拡張性・保守性の問題

ブジェクト指向技術を導入する動機は再利用性の向上であることが多い。多くの方法論で、再利用性のことが述べられている。

しかしながら、実際のオブジェクト指向方法論の開発サイクルには再利用のためのプロセスが含まれていない。

その結果、開発者は、システム分析とコンポーネントの再利用を同時に考えようとしてしまうことになる。

このようなプロセスでは、中途半端な再利用クラスが設計されるという問題が起こる。

さらには、コンポーネントの再利用性を考慮しすぎて開発システムの境界を定めようという意識が軽薄になり、開発システムの境界を見失ってしまうといった、システム開発にとって最悪の事態が生ずることもある。

このことは、拡張性と保守性にも共通する問題である。システムの拡張とは、既存システムを新たな要求に対して再利用するという考え方もできるだろう。

つまり、「再利用性の向上」と「拡張性の向上」に必要とされるアプローチは酷似しており、密接な関係にあるのだ。

再利用のためのプロセスが欠落してしまっては、拡張性・保守性を向上しようということなどできるはずもないのである。

作成ドキュメントに関する問題

オブジェクト指向方法論は、モデル化についてのドキュメントを中心に扱っており、その他の開発に必要なドキュメントについてはなにも言及されていない。

また、コンポーネントを再利用するためのドキュメントについても述べられていない。

よって、開発者は、オブジェクト指向方法論で提供されているモデル記述と、対象となるシステムに必要となるドキュメントを経験の中から考案し、ミックスして使用しなければならない。

このような応用知識がない開発者は、作成すべきドキュメントをモデル記述のみと勘違いしてしまうか、あるいはモデル記述に多くの時間とコストをかけすぎてしまうこととなる。

4.3 第3世代方法論に望まれる技術要素

オブジェクト指向方法論の発展の流れを整理すると図4-1のようになる。

*
図4-1 オブジェクト指向方法論の発展

第1世代方法論は、構造化方法論をベースにしてオブジェクト指向プログラミングのクラスや継承などのメカニズムを表記可能にした単純な拡張であった。それは、ERモデル(実体関連図)のデータ項目にメソッドの記述を追加したり、リレーションの表記に継承を追加しただけの表記を提供したのである。

第2世代方法論に位置づけられるのは、実装に写しやすいようなインスタンスの動的側面を捉えるモデルを追加したり、第一世代の表記方法のよいところだけを拾い集めて、方法論としたものなどがある。そして、第3世代の方法論は、一般にRumbaugh、Booch、Jacobsonにより共同で開発されたオブジェクト指向統一モデリング言語(UML:Unified Modeling Language)であると考えられている。しかし、果たしてそうなのだろうか。

実はUMLは、version0.9にバージョンアップされたときに名前をUnified MethodからUnified Modeling Languageに変えた。このことは、標準化は表記方法に止めるということを示している。その決定には、方法論提唱者達による開発プロセスを統合化するのは難しいという判断があったことが伺える。つまり、統合化された表記方法を使ってどのようにオブジェクト指向開発を行うかという点は、利用者に委ねられたわけである。

このように表記法が統一されることは、標準的なオブジェクト指向方法論の貴重な第一歩であることは間違いない。しかし、それはあくまで「話すための言葉」が統一されたということにすぎない。その言語を使って意思表現するための表現手法が必要とされるのである。

筆者は、従来の方法論に加えて、次の条件をクリアするものが次世代の方法論、つまり、第3世代の方法論として位置づけられなければならないと考える。

  • 業界標準のモデル表記法が使用されていること
  • オブジェクトの発見と構築に関して、開発サイクルの各フェーズに合わせた観点で、段階的な発展アプローチがとられていること
  • 再利用可能なコンポーネント(部品クラス及び再利用可能な部品クラスの意)の利用方法が開発プロセスとして説明されていること
  • 再利用可能なコンポーネントを開発するためのプロセスが記述されていること
  • ソフトウェアの要求仕様、利用のための仕様、方式仕様、再利用コンポーネント利用のための仕様などのド
  • キュメントについて取り上げられていること
  • モデル&ドキュメントについて、必要な範囲と利用方法などをコストバランスを考慮した形でガイドラインとしてまとめられていること
  • 形式的なオブジェクト抽出・構築技法を持ち備えていること
  • プロトタイピングについて具体的な利用方法が開発プロセスの一環として述べられていること
  • 再利用コンポーネント基盤構築のためのチーム育成・教育が含まれていること

以上、筆者が第3世代方法論として考える要素の中には、従来の方法論の領域だけではなく、開発プロセスという分野も含まれている。このような第3世代方法論を目指して開発したものがDropである。

4.4 Dropによるアプローチ

Drop(Developer's Rules of the Object- Oriented Process)とは、筆者がオブジェクト指向による開発経験を基に開発したオブジェクト指向方法論である。その目標は、先に第3世代方法論として掲げた条件をクリアすることで、オブジェクト指向技術の効果を最大限に発揮するための方法論である。

Dropでは、従来のオブジェクト指向方法論とはまったく異なるアプローチを導入した。すなわち、構造化方法論をベースとせず、オブジェクト指向プログラミングの本質に適合させるための開発プロセスをベースとして、その上に既存のオブジェクト指向方法論で培われた手法を載せたのである。

従来の方法論と比較した図を以下に示す。

*
図4-2 従来方法論とDropのコンセプト・アプローチの違い

Dropのようなアプローチは、オブジェクト指向方法論の表記法(Unified Modeling Language)をベースにしてこそ成し遂げられるものである。

従って、先駆者であるUMLの開発者や日本で普及に携わってきた技術者たちの多大な努力に対して敬意を表したい。

しかし、Dropの設計概念は、他の方法論より時代に先行していると考えている。よって、いずれ他の方法論もDropと同じアプローチをとることとなるだろう。その根拠は、オブジェクト指向開発プロセスをべースとしたDropのアプローチは、コンポーネント開発(すなわちオブジェクト部品を組み合わせながらシステムを開発する)という新たなパラダイムに柔軟に適合できるアプローチだからである。

このように設計されたDropでは、従来の方法論と異なる斬新な概念や手法を採用している。一見これら新たな手法は、理想論のようにも思えるであろうが、実は非常に自然な開発手法である。このことは、「第1編3章オブジェクト指向開発の考え方(映画撮影のように)」を読むことで理解を深めることができるだろう。

4.5 Dropの現状、そして今後

Dropの現バージョンはv2.0である。このバージョンでは、Dropv1.0に以下の拡張を行ったものである。

  • Dropをよりわかりやすい方法論にするためのコンセプトを詳しく解説する。(第1編コンセプトの強化)
  • Dropのチーム構成を取るための組織改革にともなう戦略について解説する章を設ける。
  • Dropのチームメンバの特徴を明確にすることで、Drop利用メンバが役割に合ったビジョンを持てるようにする。
  • 開発サイクルのフェーズについて、より現実的な名前を使い、フェーズ間の区切りを再度調整する。
  • 要求のモデル化を強化するためにシネマスコープモデルを導入する。
  • オブジェクトモデルの表記をUMLに準拠する、(コラボレーション図など)
  • 開発モデルと開発プロセスの関係をオブジェクトモデルのライフサイクルとして定義する

*begin*back*foward*end*contents

この記事のトップへ