*begin*back*foward*end*contents

コンセプト編 -
第2章 Drop構成用語集
(開発プロセス用語編)

2.1 開発プロセス用語編

開発プロセス用語編とは、どのようなプロセス(手順)でアプリケーションやコンポーネントの仕様を定め、実装し、ユーザに提供していくか、という開発の流れを中心に、Dropで使われる用語を解説するものである。

Drop開発プロセスを他の方法論と比較すると、非常に複雑に思得るかも知れない。しかしながら、Dropのコンセプトは、オブジェクト指向開発におい て、本質的で自然な開発プロセスを形式化しているのである。この本質面だけを覗いてみると、Dropの開発プロセスがソフトウェア開発において自然な流れ であることが理解できるだろう。

ここでは、Drop開発プロセスにおける用語の構成と関係を示すことで、その本質的な意味や必要性を理解してもらうことを目指している。

2.2 開発サイクル

開発サイクルとは、開発プロセスを構成する個々のフェーズとその流れ方のことである。Dropの開発プロセスは、ADGとODGによるコンカレントチー ムワーク(並行的な共同作業)による開発プロセスが基本である。しかし、初めからコンカレントチームワークを強要するものではない。ADGとODGとは チームの名前でもあり、技術者が持つべき観点でもあるのだ。つまり、ADGとODGという2つの観点を1人の開発者が持つところからスタートし、徐々に チーム編成へと発展させることが重要なのである。

sorry this is image
図2-1 開発サイクル

アプリケーションを開発する観点を持つADGは、ユーザとの契約期間内にアプリケーションの仕様を定め、システムを開発する。ADGのアプリケーション の骨組み的な仕様を定めるという開発サイクルは、初めに全体像を決定しなければならないという性質上、カスケードウォータフォール開発サイクルを適用す る。カスケードウォータフォールとは、従来の非現実的なウォータフォール開発サイクルの欠点を解消するために、それぞれのフェーズが重複することを許可す るものであり、フェーズの始まりを問わず、フェーズの終わりを重視しながら開発を進めるというものである。

コンポーネントを開発する観点を持つODGは、コンポーネントの仕様を定め、コンポーネントを開発・保守する。ODGの開発サイクルは、一般的にADG の開発サイクルの周期よりも短く、コンポーネントをパッケージという単位で何度も開発して積み上げていくような形態となる。このサイクルを積み上げ反復開 発サイクルと呼ぶ。

sorry this is image
図2-2 開発プロセス

2.3 開発モデル

ソフトウェア開発におけるモデルとは、「対象問題の深い理解を得るために、その対象をある目的または観点から眺め、重要でない部分を取り去り重要な部分 だけにしたもの」のことをいう。この行為をモデリングと呼び、モデリングの成果がモデルである。モデルは、開発者の頭の中にソフトウェアのイメージとして 作られるものである。これを、単純な図や文章にして移し替えたものをモデル図と呼ぶ。モデル図は、開発者の頭の中にあるソフトウェアのイメージに近似する ものを図として映し出すものであり、その目的は、他人に開発者の考えていたソフトウェアの重要部分の構造を伝受させることにある。

Dropの開発モデル図は、オブジェクトを中心においている。開発対象をオブジェクトを示す図が中心となる5つの視点をもつ図を提供している。  クラスの静的構造とオブジェクトの動的構造を示すモデルの表記は、UMLをベースとしている。シネマスコープモデルは、Dropバージョン2.0で新た に導入したもので、要求をモデル化することと、要求の中からオブジェクト候補を抽出することが目的となるものである。

sorry this is image
図2-3 開発モデル

2.4 オブジェクトモデルのライフサイクル

オブジェクトモデルのライフサイクルとは、開発プロセスの中でオブジェクトモデルを使って行く際、それぞれの局面において、モデルに対する明確な目的と視点が必要であることを説明するものである。

現状認識モデル

システムを開発する際には、まず問題領域の現状を理解することから始まるだろう。このように問題領域の理解のためにオブジェクトを使ってモデル化したものを現状認識モデルという。

現状認識モデルにおいて重要となる点は、問題を深く理解したかどうかということである。

戦略モデル

現状認識モデルに企業戦略を加えた理想的なモデルを戦略モデルと呼ぶ。

戦略モデルとは、問題領域に対する理想的なモデルを作り上げることであり、長期的視野で企業戦略をモデルに含まなければならない。よって戦略モデルは、予算や期間を考慮しない理想のモデルのことをいう。

要求モデル

戦略モデルを現実的な側面である開発コストと開発期間により吟味したシステム用件定義がなされ、その用件定義に基づいたモデルを要求モデルと呼ぶ。

要求モデルは、ソフトウェア領域に依存しない問題領域に対する要求の本質部分をモデル化した概念的なオブジェクトモデルであり、データ管理とシステムの 本質的な振る舞いに視点をおいているものである。その後、特定のソフトウェアアーキテクチャに特化したアーキテクチャモデルに要求モデルを落とし込んでい くようなプロセスの流れとなる。

アーキテクチャモデル

アーキテクチャモデルは、要求モデルを受け入れるために既に準備されたソフトウェア領域のモデルだと考えてよい。つまり、要求モデルという概念的なモデ ルをソフトウェアモデルに落とし変えるための作業が必要となるわけである。

sorry this is image
図2-4 オブジェクトライフサイクル

モデル変換の必要性

「オブジェクト指向モデルは開発過程においてシームレスでなければならない」ということを主張するオブジェクト指向方法論提唱者は多い。しかし、それは 誤りである。オブジェクト指向モデル(表記法)はシームレスに利用できても問題領域からオブジェクトを捉える視点は、それぞれ異なるものでなければならな い。よってそれぞれの視点を通過して最終的にはソースコードとなる。その際、若干の変換が必要となることは当然の話である。

オブジェクトモデルのシームレス性だけを強調してしまうと、ドメイン分析段階のモデル(Dropの現状認識モデル)を段階的に詳細化しながら実装に落と してしまうことになり、その結果、「期間を考慮していない非現実的なソフトウェアモデル」や「要求を満たしていないソフトウェア」を作り出してしまう恐れ がある。

本来のオブジェクトライフサイクルは、開発過程の目的により明確な視点をもってオブジェクトを抽出し、洗練させていくものである。

sorry this is image
図2-5 目的によって観点が定まる

現状認識モデルと戦略モデル

Dropの現バージョン(2.0)においては、現状モデルと戦略モデルは対象外としている。なぜなら、これらのモデルはソフトウェア企業におけるビジネ スプロセスの一環として述べるべきであり、その解説を加えるとDropドキュメントは倍増してしまい、ソフトウェア開発から論点がずれてしまう危険性があ るからだ。また、筆者自身正直なところビジネスプロセスにオブジェクト指向モデルを使う効果を把握しきれていない。また、そのような役に立つレベルのオブ ジェクト指向によるビジネスプロセス方法論は存在していないと考えている。

よって、これらについては、Drop開発方法論の上位に位置するビジネスプロセス方法論として今後考えていきたい。

要求モデルの必要性

Dropでは、要求モデルを抽出することが開発プロセスの開始となる。要求モデルの大前提は、「開発システムの要件定義が明確になされているか?」とい うことである。これがなされない限り、要求モデルは、現状認識モデルや戦略モデルとの区別がつきにくく、「要件が不明確なシステム」や「コスト的にも期間 的にも実現不可能なシステム」を開発するきっかけを初期段階で作りだしてしまう。

要求モデルとは、開発システムの要件定義がなされた後に、その要件定義を基に作成したオブジェクトモデルのことを言う。

アーキテクチャモデルの必要性

ソフトウェアは全て始めから作られるわけではない。現在では、オブジェクト指向の発展による再利用可能なソフトウェア(API、コンポーネント、フレームワーク)が開発環境になくてはならない存在となっている。 これらソフトウェア領域におけるソフトウェア設計のモデルがアーキテクチャモデルである。

アーキテクチャモデルは、明らかに要求モデルとは異なる次元で分析を行う。要求モデルは「何を作るか」であり、アーキテクチャモデルは「どのように作る か」である。ソフトウェア開発においては、要求モデル・「何を作るか」を完全に定めてからアーキテクチャモデル・「どのように作るか」を決めることが最善 であるように言われている。

しかしながら、要求モデルとアーキテクチャモデルは問題領域をソフトウェア化する際の視点と捕らえることもできるのである。この場合、要求モデルとアー キテクチャモデルは同時並行的に決めるべき部分も多々あり、そのように進行させることが可能なのである。

アーキテクチャモデルは、「要求モデルを受け入れるための受け皿モデル」と考え、「受け皿を前もって用意するべきだ」と考えると、このことがわかりやすいだろう。

2.5 プロトタイプ開発

プロトタイプ開発の役割は、分析・設計結果をそれぞれの初期工程で検証し、さらに洗練作業を行うことができるという意味で非常に重要なものである。しか しながら、プロトタイプの安易な乱用や開発プロセスとの混同によって、「プロトタイプは、開発者の自己満足だけに終わってしまった」、「ソフトウェア製品 の品質を落としてしまった」など、思いがけなく悪い結果を引き起こすこともある。

このような問題は、プロトタイプの目的、利用範囲、期待する効果、評価方法などがプロジェクトチームにおける開発プロセスの中で明確に定義されていないことからくる。

Dropでは、このようなプロトタイプ開発によって引き起こされる問題を未然に防ぐために、図2-7に示す標準的なプロトタイプ開発をDrop開発プロ セスに組み込んでいる。実際には、どのプロトタイプを利用するかはプロジェクトリーダが決めるものであるが、いざ実施することになれば、プロトタイプの実 施方法はDrop開発プロセスに準拠しておこなうことになる。

sorry this is image
図2-6 プロトタイプ開発

2.6 ワークショップ

ワークショップとは、ADGとODGのコンカレントチームワークによる開発プロセスを補うための重要な意志決定を行う会議のことである。図2-6に示す 会議をそれぞれの開発フェーズにおいて開催することで、2つのチームのコミュニケーションを図り、意識を同期させながら開発を進めていくのに重要な役割を 果たす。

ワークショップで決定された作業は、ADG、ODG分担され、明確な期限が設けられる。

sorry this is image
図2-7 ワークショップ


*begin*back*foward*end*contents

この記事のトップへ