コンセプト編
第２章 Drop構成用語集(開発プロセス用語編)
開発プロセス用語編とは、どのようなプロセス(手順)でアプリケーションやコンポーネントの仕様を定め、実装し、ユーザに提供していくか、という開発の流れを中心に、Dropで使われる用語を解説するものである。
Drop開発プロセスを他の方法論と比較すると、非常に複雑に思得るかも知れない。しかしながら、Dropのコンセプトは、オブジェクト指向開発において、本質的で自然な開発プロセスを形式化しているのである。この本質面だけを覗いてみると、Dropの開発プロセスがソフトウェア開発において自然な流れであることが理解できるだろう。
ここでは、Drop開発プロセスにおける用語の構成と関係を示すことで、その本質的な意味や必要性を理解してもらうことを目指している。
開発サイクルとは、開発プロセスを構成する個々のフェーズとその流れ方のことである。Dropの開発プロセスは、ADGとODGによるコンカレントチームワーク（並行的な共同作業）による開発プロセスが基本である。しかし、初めからコンカレントチームワークを強要するものではない。ADGとODGとはチームの名前でもあり、技術者が持つべき観点でもあるのだ。つまり、ADGとODGという２つの観点を１人の開発者が持つところからスタートし、徐々にチーム編成へと発展させることが重要なのである。
図2-1 開発サイクル
アプリケーションを開発する観点を持つADGは、ユーザとの契約期間内にアプリケーションの仕様を定め、システムを開発する。ADGのアプリケーションの骨組み的な仕様を定めるという開発サイクルは、初めに全体像を決定しなければならないという性質上、カスケードウォータフォール開発サイクルを適用する。カスケードウォータフォールとは、従来の非現実的なウォータフォール開発サイクルの欠点を解消するために、それぞれのフェーズが重複することを許可するものであり、フェーズの始まりを問わず、フェーズの終わりを重視しながら開発を進めるというものである。
コンポーネントを開発する観点を持つODGは、コンポーネントの仕様を定め、コンポーネントを開発・保守する。ODGの開発サイクルは、一般的にADGの開発サイクルの周期よりも短く、コンポーネントをパッケージという単位で何度も開発して積み上げていくような形態となる。このサイクルを積み上げ反復開発サイクルと呼ぶ。
図2-2 開発プロセス
ソフトウェア開発におけるモデルとは、「対象問題の深い理解を得るために、その対象をある目的または観点から眺め、重要でない部分を取り去り重要な部分だけにしたもの」のことをいう。この行為をモデリングと呼び、モデリングの成果がモデルである。モデルは、開発者の頭の中にソフトウェアのイメージとして作られるものである。これを、単純な図や文章にして移し替えたものをモデル図と呼ぶ。モデル図は、開発者の頭の中にあるソフトウェアのイメージに近似するものを図として映し出すものであり、その目的は、他人に開発者の考えていたソフトウェアの重要部分の構造を伝受させることにある。
Dropの開発モデル図は、オブジェクトを中心においている。開発対象をオブジェクトを示す図が中心となる５つの視点をもつ図を提供している。
クラスの静的構造とオブジェクトの動的構造を示すモデルの表記は、UMLをベースとしている。シネマスコープモデルは、Dropバージョン2.0で新たに導入したもので、要求をモデル化することと、要求の中からオブジェクト候補を抽出することが目的となるものである。
図2-3 開発モデル
オブジェクトモデルのライフサイクルとは、開発プロセスの中でオブジェクトモデルを使って行く際、それぞれの局面において、モデルに対する明確な目的と視点が必要であることを説明するものである。
現状認識モデル
現状認識モデルにおいて重要となる点は、問題を深く理解したかどうかということである。
戦略モデル
戦略モデルとは、問題領域に対する理想的なモデルを作り上げることであり、長期的視野で企業戦略をモデルに含まなければならない。よって戦略モデルは、予算や期間を考慮しない理想のモデルのことをいう。
要求モデル
要求モデルは、ソフトウェア領域に依存しない問題領域に対する要求の本質部分をモデル化した概念的なオブジェクトモデルであり、データ管理とシステムの本質的な振る舞いに視点をおいているものである。その後、特定のソフトウェアアーキテクチャに特化したアーキテクチャモデルに要求モデルを落とし込んでいくようなプロセスの流れとなる。
アーキテクチャモデル
図2-4 オブジェクトライフサイクル
モデル変換の必要性
「オブジェクト指向モデルは開発過程においてシームレスでなければならない」ということを主張するオブジェクト指向方法論提唱者は多い。しかし、それは誤りである。オブジェクト指向モデル（表記法）はシームレスに利用できても問題領域からオブジェクトを捉える視点は、それぞれ異なるものでなければならない。よってそれぞれの視点を通過して最終的にはソースコードとなる。その際、若干の変換が必要となることは当然の話である。
オブジェクトモデルのシームレス性だけを強調してしまうと、ドメイン分析段階のモデル（Dropの現状認識モデル）を段階的に詳細化しながら実装に落としてしまうことになり、その結果、「期間を考慮していない非現実的なソフトウェアモデル」や「要求を満たしていないソフトウェア」を作り出してしまう恐れがある。
本来のオブジェクトライフサイクルは、開発過程の目的により明確な視点をもってオブジェクトを抽出し、洗練させていくものである。
図2-5 目的によって観点が定まる
現状認識モデルと戦略モデル
Dropの現バージョン(2.0)においては、現状モデルと戦略モデルは対象外としている。なぜなら、これらのモデルはソフトウェア企業におけるビジネスプロセスの一環として述べるべきであり、その解説を加えるとDropドキュメントは倍増してしまい、ソフトウェア開発から論点がずれてしまう危険性があるからだ。また、筆者自身正直なところビジネスプロセスにオブジェクト指向モデルを使う効果を把握しきれていない。また、そのような役に立つレベルのオブジェクト指向によるビジネスプロセス方法論は存在していないと考えている。
よって、これらについては、Drop開発方法論の上位に位置するビジネスプロセス方法論として今後考えていきたい。
要求モデルの必要性
Dropでは、要求モデルを抽出することが開発プロセスの開始となる。要求モデルの大前提は、「開発システムの要件定義が明確になされているか？」ということである。これがなされない限り、要求モデルは、現状認識モデルや戦略モデルとの区別がつきにくく、「要件が不明確なシステム」や「コスト的にも期間的にも実現不可能なシステム」を開発するきっかけを初期段階で作りだしてしまう。
要求モデルとは、開発システムの要件定義がなされた後に、その要件定義を基に作成したオブジェクトモデルのことを言う。
アーキテクチャモデルの必要性
ソフトウェアは全て始めから作られるわけではない。現在では、オブジェクト指向の発展による再利用可能なソフトウェア(API、コンポーネント、フレームワーク)が開発環境になくてはならない存在となっている。
これらソフトウェア領域におけるソフトウェア設計のモデルがアーキテクチャモデルである。
アーキテクチャモデルは、明らかに要求モデルとは異なる次元で分析を行う。要求モデルは「何を作るか」であり、アーキテクチャモデルは「どのように作るか」である。ソフトウェア開発においては、要求モデル・「何を作るか」を完全に定めてからアーキテクチャモデル・「どのように作るか」を決めることが最善であるように言われている。
しかしながら、要求モデルとアーキテクチャモデルは問題領域をソフトウェア化する際の視点と捕らえることもできるのである。この場合、要求モデルとアーキテクチャモデルは同時並行的に決めるべき部分も多々あり、そのように進行させることが可能なのである。
アーキテクチャモデルは、「要求モデルを受け入れるための受け皿モデル」と考え、「受け皿を前もって用意するべきだ」と考えると、このことがわかりやすいだろう。
プロトタイプ開発の役割は、分析・設計結果をそれぞれの初期工程で検証し、さらに洗練作業を行うことができるという意味で非常に重要なものである。しかしながら、プロトタイプの安易な乱用や開発プロセスとの混同によって、「プロトタイプは、開発者の自己満足だけに終わってしまった」、「ソフトウェア製品の品質を落としてしまった」など、思いがけなく悪い結果を引き起こすこともある。
このような問題は、プロトタイプの目的、利用範囲、期待する効果、評価方法などがプロジェクトチームにおける開発プロセスの中で明確に定義されていないことからくる。
Dropでは、このようなプロトタイプ開発によって引き起こされる問題を未然に防ぐために、図2-7に示す標準的なプロトタイプ開発をDrop開発プロセスに組み込んでいる。実際には、どのプロトタイプを利用するかはプロジェクトリーダが決めるものであるが、いざ実施することになれば、プロトタイプの実施方法はDrop開発プロセスに準拠しておこなうことになる。
図2-6 プロトタイプ開発
ワークショップとは、ADGとODGのコンカレントチームワークによる開発プロセスを補うための重要な意志決定を行う会議のことである。図2-6に示す会議をそれぞれの開発フェーズにおいて開催することで、２つのチームのコミュニケーションを図り、意識を同期させながら開発を進めていくのに重要な役割を果たす。
ワークショップで決定された作業は、ADG、ODG分担され、明確な期限が設けられる。
図2-7 ワークショップ