トピック

説明 ページの先頭へ

ユース・ケース・モデルはシステムの期待される機能とその環境のモデルであり、顧客と開発者の間での契約書の役割を果たします。また、ユース・ケースはシステム開発全体を通して統合されたスレッドとしての役割を果たします。同一のユース・ケース・モデルは、「要求」の作業分野の結果であり、「分析 / 設計」の作業分野と「テスト」の作業分野に対する情報源として使用されます。

下のダイアグラムは、「リサイクル マシン システム」のユース ケース モデルの一部を表しています。

キャプションで説明される図。

アクターとユース ケースと共にユース ケース モデルの例を表したユース ケース図

システムをモデル化する方法は多数あり、それぞれ異なる目的で使用されます。しかし、ユース ケース モデルの最も重要な目的は、システムの振る舞いを顧客やエンドユーザーに伝えることです。したがって、モデルはわかりやすいものでなければなりません。

システムと相互作用を持つユーザーやほかのシステムは、アクターです。アクターはシステムのユーザーを表すため、システムの境界を設定し、システムがなすべきことを明確にします。ユース ケースはアクターの要求に基づいて作成されます。これにより、システムはユーザーの期待どおりに仕上がります。

ユース・ケース・モデルの展開方法 ページの先頭へ

アクターとユース ケースは共に、顧客や潜在的ユーザーの要求を重要な情報として使用して、基本が形成されます。これらが発見されたら、簡単な記述を行う必要があります。ユース ケースを詳細に記述する前に、ユース ケース モデルを顧客にレビューしてもらい、ユース ケースやアクターすべてが発見され、全体として顧客の希望を満たしているかを確認します。

反復型開発環境では、ユース ケースのサブセットを選択して、各反復で詳細化します。「作業: ユース ケースの優先順位付け」も参照してください。

アクターとユース ケースが発見されたら、各ユース ケースのイベントのフローが詳細に記述されます。この説明では、システムとアクターとの相互作用の方法が表され、それぞれのケースでシステムが何をするかが記述されます。

最後に、完成されたユース ケース モデル (ユース ケースの説明も含む) がレビューされ、開発者と顧客がこれを使ってシステムのあり方について合意します。

機能分解の回避 ページの先頭へ

ユース ケース モデルが退化してシステムの 1 機能となるのは、よくあることです。これを回避するには、次の兆候に注意します。

  • 「小さい」ユース・ケース。イベントのフローの記述がほんの 1 行か数行しかないものです。
  • 「多数の」ユース・ケース。ユース・ケースの数が数十ではなく数百に及ぶものです。
  • 「このデータのときはこの操作をする」や「このデータのときはこの機能を使う」といった構造の名前を持つユース・ケース。たとえば、「ATM マシンに暗証番号を入力」は独立した ATM マシンのユース・ケースとしてモデル化されるべきではありません。これは、ただそれだけのためにシステムを使う人はいないためです。ユース・ケースはアクターに価値のある結果を提供する完成されたイベントのフローです。

機能分解を回避するには、ユース ケース モデルによって次のような質問に答えられることを確認します。

  • システムの背景は何か
  • システム作成の目的は何か
  • ユーザーがシステムを使って達成したいことは何か
  • システムによってユーザーにもたらされる付加価値は何か

機能外要求 ページの先頭へ

ユース ケースがシステムの機能要求を捉えるのに有効な方法であることは簡単にわかります。しかし、機能外要求に対してはどうでしょうか。機能外要求はどのように、どこで把握されるでしょう。

機能外要求はしばしば、使いやすさ - 要求、信頼性、性能、代替可能性 - 要求に分類されます (「概念: 要求」も参照)。これらは多くの場合、法的、あるいは規制の要求を遵守する必要性を指定する要求です。また、オペレーティング システム、プラットフォーム環境、互換性の問題、または適用されるアプリケーションの基準による設計制約となる場合もあります。一般に、1 つ以上の設計オプションを許容しない要求はどれでも、設計制約と見なされます。

多くの機能外要求は、独立したユース ケースに適用され、ユース ケースのプロパティ内で把握されます。この場合、ユース ケースのイベントのフロー内で把握されるか、ユース ケースの特殊な要求として把握されます (「ガイドライン: ユース ケース」参照)。

例:

「リサイクル マシン システム」の例において、「リサイクル品の返却」ユース ケースに特有の機能外要求は次のとおりです。

マシンは 95% よりも高い信頼性でリサイクル品を認識できる必要があります。

機能外要求はシステム全体に適用される場合が多くあります。そのような要求は、補足仕様書で把握されます (「成果物: 補足仕様書」参照)。

例:

「リサイクル マシン システム」の例において、システム全体に適用される機能外要求は次のとおりです。

マシンは一度に 1 人のユーザーしか使用できません。

「何」と「どのように」のジレンマ ページの先頭へ

最も困難なことの 1 つは、ユース・ケースが「開始され終了される」べき詳細度を決定する方法を学ぶことです。機能が開始され、ユース・ケースが始まるのがどこで、ユース・ケースが終わり、設計が始まるのはどこでしょうか。ユース・ケースまたはソフトウェアの要求では、システムによって「何」が行われるかを規定するべきで、「どのように」実現されるかではありません。下記のグラフを考慮します。

キャプションで説明されているダイアグラム。

ある人の目的地は、ほかの人の出発点です。

背景によって、異なる状況を使用して何が「何」で、何が「どのように」なのか決定します。これは、特定の詳細がユース・ケースから除外されるべきかどうかを決定する際に考慮されなければなりません。

具象的なユース・ケースと抽象的なユース・ケース ページの先頭へ

具象的なユース・ケースと抽象的なユース・ケースには違いがあります。具象的なユース・ケースはアクターによって開始され、完全なイベントのフローを構成します。「完全な」という意味は、ユース・ケースのインスタンスがアクターにコールされた操作すべてを実行するということです。

抽象的なユース ケースはそれ自身では決してインスタンスを作成しません。抽象的なユース ケースはほかのユース ケースに包含され (「ガイドライン: 包含関係」を参照)、拡張され (ガイドライン: 拡張関係」を参照)、あるいは汎化されます (ガイドライン: ユース ケースの汎化」を参照)。具体的なユース ケースが開始されると、ユース ケースのインスタンスが作成されます。このインスタンスによって、関連付けられた抽象的なユース ケースに指定された振る舞いが示されます。このように、抽象的なユース ケースからは独立したインスタンスは作成されません。

この 2 つの差は、アクターが「見て」システムにおいて開始するのが具体的なユース・ケースである、という点で重要です。

抽象的なユース ケースの名前はイタリック体で書きます。

例:

キャプションで説明されているダイアグラム。

ユース ケース「タスクの作成」はユース ケース「注文の登録」に包含されます。「タスクの作成」は抽象的なユース ケースです。

「倉庫管理システム」では、抽象的なユース ケース「タスクの作成」はユース ケース「注文の登録」に包含されます。「注文の登録」が開始されると、次の「注文の登録」のイベントのフローから別れて「注文の登録」のインスタンスが作成され、さらに包含されるユース ケース「タスクの作成」で記述されるイベントのフローもたどります。「注文の登録」はそれ自身で何かをすることはなく、常に「注文の登録」(または、それが包含されるユース ケース) の一部となります。したがって、「注文の登録」は抽象的なユース ケースです。

ユース・ケース・モデルの構成 ページの先頭へ

ユース ケース モデルの構成には、次の 3 つの主な理由があります。

  • ユース ケースを理解しやすくすること
  • 複数のユース ケースで記述されている共通の振る舞いを分離すること
  • ユース ケース モデルを保守しやすくすること

構造化は最初に行うことではありません。ユース ケースの振る舞いを 1 文の簡単な説明以上に理解するまでは、構造化は意味がありません。少なくとも、ユース ケースのイベントのフローに対する手順を追った概要を確立し、決定が振る舞いの的確な理解に基づいて行われるようにすべきです。

ユース ケースを構成するために、3 つの関係を使用できます。これらを利用してほかのユース ケースで再利用できたり、特殊なものやオプションとして使用できるユース ケースの部分を見つけます。変更を表すユース ケースを、追加ユース ケースと呼びます。変更されたユース ケースを、基底ユース ケースと呼びます。

  • ユース ケースが結果を得る方法ではなく結果そのものに依存するという機能を表す基底ユース ケースの一部がある場合、その部分を追加ユース ケースと解釈できます。この追加ユース ケースは包含関係を使って明示的に基底ユース ケースに含められます。「ガイドライン: 包含関係」も参照してください。
  • オプションであったり、ユース ケースの主目的を理解する必要がない基底ユース ケースの一部がある場合、基底ユース ケースの構造を簡単にするためにその部分を追加ユース ケースと解釈できます。この追加ユース ケースは拡張関係を使って明示的に基底ユース ケースに含められます。「ガイドライン: 拡張関係」も参照してください。
  • 振る舞いと構造に共通点があり、目的が類似しているユース ケースがある場合、共通の部分を基底ユース ケース (親) とし、追加ユース ケース (子) に継承させます。子ユース ケースでは、新しい振る舞いを追加したり、親ユース ケースから継承した構造の既存の振る舞いを変更できます。「ガイドライン: ユース ケースの汎化」も参照してください。

アクターの汎化を使用して、アクターが互いに特殊化されている様子を表せます。「ガイドライン: アクターの汎化」も参照してください。

例:

「注文管理システム」のユース ケース モデルの一部を検討します。

通常の「顧客」から「インターネットの顧客」を分離すると便利です。これは、プロパティがやや異なっているためです。しかし、「インターネットの顧客」は「顧客」のプロパティすべてを備えているので、アクターの汎化で表される「インターネットの顧客」は「顧客」の特化と言えます。

ダイアグラム中の具象的なユース ケースは「電話注文」(「顧客」アクターによって開始される) と「インターネット注文」(「インターネットの顧客」アクターによって開始される) です。これらのユース ケースは共に、より一般的な「注文」ユース ケース (この例では抽 象的なユース ケース) の変化形です。「カタログの注文」ユース ケースによって、「注文」の基本的な目的の一部ではない振る舞いのオプションのセグメントが表されます。これは、「注文」ユース ケースを簡単にするために、抽象的なユース ケースとして分離されます。「顧客データの供給」ユース ケースにより、分離された振る舞いのセグメントが表されます。これは、結果だけが「注文」ユース ケースに影響する独立した機能だからです。「顧客データの供給」ユース ケースはまた、ほかのユース ケースで再利用できます。「カタログの注文」と「顧客データの供給」は共に、この例では抽象的なユース ケースです。

キャプションで説明されているダイアグラム。

このユース ケース図では、「注文管理システム」のユース ケース モデルの一部が表されています。

次のテーブルでは、3 つの異なるユース ケース関係がより詳細に比較されています。

問題 拡張 包含 汎化
関係の方向 追加ユース ケースが基底ユース ケースを参照 基底ユース ケースが追加ユース ケースを参照 追加ユース ケース (子) が基底ユース ケース (親) を参照
多重度のある関係かどうか 追加ユース ケースでは、多重度あり 多重度なし。振る舞いの同じセグメントが 2 回以上あるとき、基底ユース・ケースで指定されなければならない。 多重度なし
関係に制約があるかどうか 制約あり 制約なし。包含に制約を設ける場合、基底ユース・ケースで明示的に宣言しなければならない。 制約なし
追加ユース ケースは抽象的かどうか 多くの場合、抽象的。だが、必ずしもそうとは限らない。 抽象的 多くの場合、抽象的ではない。だが、必ずしもそうとは限らない。
基底ユース ケースが追加ユース ケースによって変更されるかどうか 拡張により、基底ユース ケースの振る舞いは暗示的に変更される。 拡張により、基底ユース ケースの振る舞いは明示的に変更される。 基底ユース ケース (親) のインスタンスが作成されると、子の影響は受けない。追加の効果を得るには、追加ユース ケース (子) のインスタンスも作成されなければならない。
基底ユース ケースは完全で意味のあるものでなければならないかどうか そうあるべき 追加と共に、そうあるべき 抽象的である場合、必要なし
追加ユース ケースは完全で意味のあるものでなければならないかどうか 必要なし 必要なし 基底ユース ケース (親) と共に、そうあるべき
追加ユース ケースが基底ユース ケースの属性にアクセスできるかどうか できる できない。包含はカプセル化されており、自身を「見る」ことしかできない。 できる。通常の継承メカニズムを使用する。
基底ユース ケースが追加ユース ケースの属性にアクセスできるかどうか できない。基底ユース・ケースは追加ユース・ケースがない場合、的確に形成されていなければならない。 できない。基底ユース・ケースは追加の効果だけしか認知しない。追加ユース・ケースはカプセル化されている。 できない。基底ユース・ケース (親) は追加ユース・ケース (子) がない場合、的確に形成されていなければならない。

ユース・ケース モデルを簡単に理解するための整理に関する別の側面は、ユース・ケースをパッケージにグループ化することです。ユース・ケース・モデルは、アクターまたはユース・ケースから成る「リーフ」を持つユース・ケース・パッケージの階層として整理できます。「ガイドライン: ユース・ケース・パッケージ」も参照してください。

キャプションで説明されているダイアグラム。

このグラフでは、ユース ケース モデルの階層が示されています。矢印は可能な所属を表しています。

ユース・ケースは常にアクターに関連付けられているか ページの先頭へ

各ユース ケースの実行には、1 つ以上のアクターとのコミュニケーションが含まれています。ユース ケースのインスタンスは常に、アクターがシステムに何かをするように依頼することによって開始されます。これは、全ユース ケースにアクターとのコミュニケーション関連が備わっていなければならないことを意味します。このルールは、システムがユーザーに対して必要な機能だけを提供するようにするために存在します。誰も要求していないユース ケースの存在は、ユース ケース モデルか要求になんらかの問題があることを意味します。

ところが、このルールにも例外があります。

  • ユース ケースが抽象的なものの場合 (単独でインスタンスを作成できない)、その振る舞いにはいかなるアクターとの相互作用も備わっていない可能性があります。この場合、このユース ケースからアクターに対するコミュニケーション関連は存在しません。
  • 汎化関係における子ユース ケースには、親ユース ケースでアクターのコミュニケーションがすべて記述されている場合、これに関連付けられたアクターがなくてもかまいません。
  • 包含関係における基底ユース ケースには、包含ユース ケースでアクターのコミュニケーションがすべて記述されている場合、これに関連付けられたアクターがなくてもかまいません。
  • スケジュールによって開始される可能性のあるユース・ケース (たとえば週に一度や、1 日に一度など) では、システム時計が始動体となります。システム時計はシステムの内部的なものであり、ユース・ケースはアクターによって開始されずにシステムの内部的なイベントによって開始されます。このユース・ケースでアクターとの相互作用がほかにない場合、アクターとの関係がまったくないことになります。しかし、わかりやすくするためにアクター「時間」を創作して、ユース・ケース図においてユース・ケースがどのように開始されるかを表せます。

概要の説明 ページの先頭へ

ユース ケース モデルの概要では、次の事柄が説明されている必要があります。

  • システムの主要なユース ケースの状態 (システムが構築される利用)
  • システムの重要な技術的現実の概要
  • システムの限界 (システムでの実行がサポートされていないものなど) についての指摘
  • 対象プラットフォームや既存のソフトウェアなどの、システム環境の概要
  • システムにおける、ユース ケースによって通常実行されるシーケンスの記述
  • ユース ケース モデルによって取り扱われない機能の指定

例:

「リサイクル マシン」ユース ケース概要の説明の例を次に示します。

このモデルには、3 つのアクターと 3 つのユース ケースがあります。主要なユース ケースは「リサイクル マシン」の主目的を表す「リサイクル品」です。

サポートするユース ケースは次のとおりです。

  • 「日次報告書の印刷」。リサイクルされた物品の数がオペレータにわかるようにします。

  • 「リサイクル品の管理」。オペレータがリサイクル品の種類による返却価値を変更したり、新しいリサイクル品の種類を変更したりできるようにします。



Rational Unified Process   2003.06.15