オブジェクトの発見、構築に関する問題
ソフトウェア開発サイクルの各フェーズで見つけだされるオブジェクトの性質は異なるものでなければならない。
たとえば、実世界を理解するために作り出したオブジェクト(現状認識モデル)や、その理解を基に戦略を加味して最適化されたモデル(戦略モデル)と、システム要求を基に見つけだされるオブジェクト(要求モデル)は性質がまったく異なる。
また、このような分析的な視点で抽出された概念的なモデルと、クラスライブラリをベースにして作成されるオブジェクト(アーキテクチャモデル)も、性質が異なるものである。
従って、各開発フェーズでは観点を変えてオブジェクトを抽出しなければならない。
しかしながら、従来のオブジェクト指向方法論は、これを明確に示していないものが多い。
特に、実世界のモデルを、ある制約されたシステム要求に移し替える時のモデル変換の必要性について曖昧な点が多い。
この問題により、システム要求が不明確なまま設計、実装へ流してしまうという問題が起こる。
さらに、設計において既存資産のクラスライブラリなどの再利用コンポーネントをどのようにモデルに統合するかという具体的な指針も示していないことがある。
再利用性、そして拡張性・保守性の問題
オブジェクト指向技術を導入する動機は再利用性の向上であることが多い。多くの方法論で、再利用性のことが述べられている。
しかしながら、実際のオブジェクト指向方法論の開発サイクルには再利用のためのプロセスが含まれていない。
その結果、開発者は、システム分析とコンポーネントの再利用を同時に考えようとしてしまうことになる。
このようなプロセスでは、中途半端な再利用クラスが設計されるという問題が起こる。
さらには、コンポーネントの再利用性を考慮しすぎて開発システムの境界を定めようという意識が軽薄になり、開発システムの境界を見失ってしまうといった、システム開発にとって最悪の事態が生ずることもある。
このことは、拡張性と保守性にも共通する問題である。システムの拡張とは、既存システムを新たな要求に対して再利用するという考え方もできるだろう。
つまり、「再利用性の向上」と「拡張性の向上」に必要とされるアプローチは酷似しており、密接な関係にあるのだ。
再利用のためのプロセスが欠落してしまっては、拡張性・保守性を向上しようということなどできるはずもないのである。
作成ドキュメントに関する問題
オブジェクト指向方法論は、モデル化についてのドキュメントを中心に扱っており、その他の開発に必要なドキュメントについてはなにも言及されていない。
また、コンポーネントを再利用するためのドキュメントについても述べられていない。
よって、開発者は、オブジェクト指向方法論で提供されているモデル記述と、対象となるシステムに必要となるドキュメントを経験の中から考案し、ミックスして使用しなければならない。
このような応用知識がない開発者は、作成すべきドキュメントをモデル記述のみと勘違いしてしまうか、あるいはモデル記述に多くの時間とコストをかけすぎてしまうこととなる。
オブジェクト指向方法論の発展の流れを整理すると図４−１のようになる。
 |
第１世代方法論は、構造化方法論をベースにしてオブジェクト指向プログラミングのクラスや継承などのメカニズムを表記可能にした単純な拡張であった。それは、ＥＲモデル（実体関連図）のデータ項目にメソッドの記述を追加したり、リレーションの表記に継承を追加しただけの表記を提供したのである。
第２世代方法論に位置づけられるのは、実装に写しやすいようなインスタンスの動的側面を捉えるモデルを追加したり、第一世代の表記方法のよいところだけを拾い集めて、方法論としたものなどがある。そして、第３世代の方法論は、一般にRumbaugh、Booch、Jacobsonにより共同で開発されたオブジェクト指向統一モデリング言語(UML:Unified Modeling Language)であると考えられている。しかし、果たしてそうなのだろうか。
実はUMLは、version0.9にバージョンアップされたときに名前をUnified MethodからUnified Modeling Languageに変えた。このことは、標準化は表記方法に止めるということを示している。その決定には、方法論提唱者達による開発プロセスを統合化するのは難しいという判断があったことが伺える。つまり、統合化された表記方法を使ってどのようにオブジェクト指向開発を行うかという点は、利用者に委ねられたわけである。
このように表記法が統一されることは、標準的なオブジェクト指向方法論の貴重な第一歩であることは間違いない。しかし、それはあくまで「話すための言葉」が統一されたということにすぎない。その言語を使って意思表現するための表現手法が必要とされるのである。
筆者は、従来の方法論に加えて、次の条件をクリアするものが次世代の方法論、つまり、第３世代の方法論として位置づけられなければならないと考える。
以上、筆者が第３世代方法論として考える要素の中には、従来の方法論の領域だけではなく、開発プロセスという分野も含まれている。
このような第３世代方法論を目指して開発したものがDropである。
Drop(Developer's Rules of the Object- Oriented Process)とは、筆者がオブジェクト指向による開発経験を基に開発したオブジェクト指向方法論である。その目標は、先に第３世代方法論として掲げた条件をクリアすることで、オブジェクト指向技術の効果を最大限に発揮するための方法論である。
Dropでは、従来のオブジェクト指向方法論とはまったく異なるアプローチを導入した。すなわち、構造化方法論をベースとせず、オブジェクト指向プログラミングの本質に適合させるための開発プロセスをベースとして、その上に既存のオブジェクト指向方法論で培われた手法を載せたのである。
従来の方法論と比較した図を以下に示す。
 |
Dropのようなアプローチは、オブジェクト指向方法論の表記法(Unified Modeling Language)をベースにしてこそ成し遂げられるものである。
従って、先駆者であるUMLの開発者や日本で普及に携わってきた技術者たちの多大な努力に対して敬意を表したい。
しかし、Dropの設計概念は、他の方法論より時代に先行していると考えている。よって、いずれ他の方法論もDropと同じアプローチをとることとなるだろう。その根拠は、オブジェクト指向開発プロセスをべースとしたDropのアプローチは、コンポーネント開発（すなわちオブジェクト部品を組み合わせながらシステムを開発する）という新たなパラダイムに柔軟に適合できるアプローチだからである。
このように設計されたDropでは、従来の方法論と異なる斬新な概念や手法を採用している。一見これら新たな手法は、理想論のようにも思えるであろうが、実は非常に自然な開発手法である。このことは、「第１編３章オブジェクト指向開発の考え方(映画撮影のように）」を読むことで理解を深めることができるだろう。
４．５ Dropの現状、そして今後
Dropの現バージョンはv2.0である。このバージョンでは、Dropv1.0に以下の拡張を行ったものである。