| フェーズ | 内容 | 成果物 |
|---|---|---|
| １．シナリオの作成 | ソフトウェアに対する要求機能の個々の項目についてストーリ化する | シナリオ表 |
| ２．シーンの作成 | シナリオを実現するための概念的なオブジェクトと、オブジェクト間のメッセージの流れを記述する | シーン図 |
| ３．シーンの統合 | 何枚かのシーンを統合し洗練することで、要求オブジェクトモデルの原型を作り出す | シーン統合図 |
シナリオの作成
シナリオとは、開発するソフトウェアの要求機能に対し、１つ、または関連するいくつかの項目毎に、その機能を実行する際の手順や方法について、ソフトウェアユーザが理解可能な用語を使って解説する。シナリオ表とは、要求項目シナリオの集まりを示す。
１つのシナリオを実現するための概念的なオブジェクトをいくつか考え、それらがメッセージをやりとりしながらどのようにシナリオを実現するかというイメージ図を示す。
このオブジェクトを「映画撮影」に例えると、監督が描くシーンの中で思いついた登場人物に該当する。この時、監督はまだ具体的な俳優をイメージせず、理想的な登場人物を描いているだろう。ここでのオブジェクトの場合も、シーンを実現するための理想的なオブジェクトをオブジェクトの詳細にこだわらず描けばよい。よって、シーン図に登場するオブジェクトは、オブジェクトの内部構造についてあまり言及することはしない。オブジェクト同士がメッセージを交換することでシナリオに書かれていることを実現していることが分かればよいだけである。
シナリオの中に現れる名詞がオブジェクトの候補となるだろう。しかしすべての名詞がオブジェクトの候補とはならない。名詞というよりその問題領域に浮き上がってくるキーワードと言った方が正しい。キーワードは、以下のようにシナリオ中の名詞を整理すると見つかる。
- 同じ「もの」をさしている名詞は、その中から問題領域にとって最も役割が明確で重要と思われるものをオブジェクトとする。
- 開発するソフトウェアの世界に関係しない名詞はオブジェクトの対象から除外する。たとえば、レジ係など、現実世界のものを表し、ソフトウェア実装に無関係な名詞。
シーンの統合とは、シーンに現れるオブジェクトを中心としながら、いくつかのシーンを統合させることである。この際、複数のシーンにおいて、似通った役割を持つオブジェクトや、シーンによって別の役割を持つオブジェクトがいないかということに着目する。そして、シーン全体を通して矛盾のないオブジェクト名とオブジェクト同士の関係となるよう調整しながらオブジェクトを洗練させていくのである。その後、複数のシーンを１枚のシーン図に統合して、統合されたシーンの中に調整後のオブジェクトとオブジェクト同士の関係を書き表す。
このシーン統合フェーズを「映画撮影」に例えると、映画監督が思い描いたいくつかの映画の重要なシーンを組み合わせて映画全体としての一貫性のあるストーリを描くことである。その際に、登場人物の性格や役割が映画として一貫性を持ったものであるか再度調整することになる。
シーン統合図は、１枚以上作成されることになる。小さなソフトウェアでは１枚で十分だろう。しかし、大きなソフトウェアシステムでは、複数枚のシーン統合図が書かれることになるだろう。たとえば、システムを構成するアプリケーション毎にシーン統合図が書かれるかもしれない。
モデルの意義
シネマスコープモデルは、要求項目から作られたシナリオを基に、機能に着目しながら概念的なオブジェクトを抽出し、そのオブジェクト同士の関係を示すものである。シネマスコープモデルで抽出されたオブジェクトは、まだクラス化されていないことに注意しなければならない。シネマスコープモデルに現れるオブジェクトは、オブジェクトの内部構造を示すことはしない。要求の中に現れるキーワードをオブジェクトとし、それらオブジェクトを使って要求を実現するための流れをいくつかのシーンとして描き、それを統合することでオブジェクトの洗練を徐々に図っていこうとするものである。
このようにシネマスコープモデルは、オブジェクトをクラスという静的な内部構造にまとめる前段階として、要求を満たすための大まかなオブジェクトとオブジェクト同士の流れに着目したモデルであり、それはクラス図を作成する際の思考過程を表すモデルと考えればよい。
モデルと開発フェーズ
シネマスコープモデルがDropの問題領域分析フェーズで使われる時には、シーン統合図をベースとして「要求モデル（要求オブジェクトで構成されたクラス図）」が作られることになる。また、Dropのコンポーネント分析フェーズで使われる場合は、コンポーネント分析モデルの原型となる。
まだクラス化されていないシネマスコープモデルが要求モデルに詳細化される際には、DROを使って、クラスの内部構造に着目したモデリングがなされる。DROは、シーン統合図に現れるオブジェクト群を制御オブジェクト(Process)とデータ管理オブジェクト(DataManage)に分類し、データ管理オブジェクトは、データの性的関係構造に重点をおいて分析する。また、制御オブジェクトは、クラスのインタフェースと動的側面に重点をおいて分析される。要求モデルでは、画面のデザインや画面構成などソフトウェア環境に深く依存するオブジェクトは対象外とする。よって、見せ方(View)に属するオブジェクトは存在しない。
モデルの長所と短所
シネマスコープモデルは、Drop version2.0で採用された新たなモデルである。旧Dropは、要求モデルの取りかかりとしてデータ管理オブジェクト(Data Manage)を中心にDRO手法を使ってモデリングをおこなう方法を採っていた。この方法では、データ中心のビジネスアプリケーションなどには有用であっても、機能中心のツール開発などでは、機能を分析モデルとして表せないという欠陥があった。シネマスコープモデルは、このような機能中心のオブジェクトを分析モデルの対象とするために採用したモデリングである。このモデルの長所は、オブジェクト同士が協調しながら動作するための全体的な構造に着目できることである。
シネマスコープモデルの短所は、データ管理オブジェクト(Data Manage)を抽出することはできても、詳細化はできないことである。よって、データ中心のビジネスアプリケーションでは、シネマスコールモデルで作られたシーン統合図を基に、DRO手法を使ってもう１度データ管理オブジェクトの関係構造を見直す必要がある。この詳細については、「第２２章 問題領域分析フェーズ」にて解説する。
UMLユースケースとの比較
シネマスコープモデルは、要求のモデル化を目的とするものであり、その目的はユースケースと同じと考えてよい。ユースケースとの相違点は、ユースケースよりもオブジェクトの原型をダイレクトに抽出する点と、アクターに対するモデリングを省略している点である。これによってオブジェクト分析がよりシームレスになり、技術者にとって分かりやすい。ソフトウェアユーザにとってはやや難しさを感ずるかもしれないが、シナリオから抽出される名詞をオブジェクトにしている為に理解可能なモデルである。
シネマコープモデルの着目点は、オブジェクト指向技術者が、要求を基に、オブジェクトベースで分析を行うプロセスである。それは、クラスの型が明確とならない段階で、要求を実現するためのインスタンスベースの世界をシーンとして作りだし、そのシーンを統合することで、クラスの候補を作り上げていこうとする過程を重要視しているものである。
一方、ユースケースは、シネマスコープモデルよりも、開発ソフトウェアの「使い方」をモデル化することを重視する。ユースケースでは、システムの外にアクターを書き、システム内部にあるシステムのユースケース（利用事例）と結びつける。つまり、システムの内部にダイレクトにオブジェクトが作られるのではなく、ユースケース（利用事例）が書かれる。このようにして作成されたモデルはソフトウェアユーザにとって分かりやすく、この点がシネマスコープモデルより優れている。