ja 日本語

ユースケース分析—ケーススタディ

ユースケースとは何ですか？

Table of Contents hide
1 ユースケースとは何ですか？
2 ユースケースの起源
3 その他のUML図

ユースケースは、システムを使用する  参加者のアクションと相互作用を説明的な方法で説明するためにプレーンテキストで記述できる要件のキャプチャと文書化の手法です。最後に、システムの機能は、利害関係者がシステムを使用する目的を満たす必要があります。

テキストを使用してユースケースの説明を文書化する前に、まずユースケース図を使用して、システムを使用するアクターの目的を強調することができます。グラフィック表現により、鳥瞰図から全体像をすばやく理解できます。システムのスコープ（システム境界）を定義し、システムの機能またはサービスの使用をサポートするアクター（ユースケースと呼ばれる）の主な目標を特定します。

ユースケース図はチームのコミュニケーションに適しています。これは人間の性質です。グラフィックを使用する方が、言葉でコミュニケーションするよりも優れていることがよくあります。

チームがシステムの全体的なルックアンドフィールについて最初の理解とコンセンサスを得た後、要件アナリストは楕円形のユースケースを開き、アクターとシステム間の対話プロセスを正確で読みやすい形式で説明します。

ユースケースの精度を単純なものから複雑なものへと徐々に高めていきます。間違ったデザインや説明にあまりにも多くの精神を投資しないように、最初は複雑な詳細にとらわれないでください。ユースケース図は、単純なものから複雑なものに移行し、不要な誤謬を減らすのに役立ちます。

図からわかるように、本システムの設計範囲は「オンライン図書注文システム」、本システムを利用する主な参加者の1人は「オンライン顧客」、本システムを利用する参加者の目的は「本注文」です。

「オーダーブック」はシステムのユースケースであり、アクターは「オンライン顧客」です。参加者の目的を決定した後、目的の詳細をテキストの説明に記録します。つまり、目的を達成するための参加者とシステム操作の間の相互作用を記録します。これはユースケースの説明と呼ばれます。

次の表は、簡単な「注文書」の使用例を示しています。

ユースケースの起源

このユースケースは、1992年にソフトウェア大手のJacobsonによって最初に公開されました。これは、最新のオブジェクト指向テクノロジに大きな影響を与えました。さらに、いわゆる「3つのアミーゴ」（Booch、Jacobson、およびRumbaugh）によって共同で作成され、OMGによってレビューされたUML（統一モデリング言語）仕様が、主要な標準仕様の重要な部分として含まれています。

これは、いくつかのソフトウェア大手によるユースケースの定義です。

  • 「ユースケースは、システムを使用してイベントを完了するアクターのプロセスシーケンスを説明するナラティブドキュメントです」[Jacobson92]。
  • 「ユースケースは、システムの一般的な使用目的に関連する一連のシナリオ（イベントのフロー）です」[Fowler97]。
  • 「ユースケースは、特定の目標を達成するために、アクター（通常は人ですが、おそらく別のシステムなどの外部エンティティ）がシステム内で実行する一連のアクションです」[Rosenberg99]。
  • 「ユースケースは、アクター（通常はユーザーですが、おそらく別の外部システムなどの外部エンティティ）であり、内部システムとの対話で特定の目標を達成するための一連のアクションです。」

「統一モデリング言語ユーザーガイド」という本では、ユースケースの定義は次のとおりです。

  • 「ユースケースは、一連のシーケンスを記述します。各シーケンスは、システムの外部にあるもの（そのアクター）とシステム自体（およびその主要な抽象化）との相互作用を表します。」
  • 「ユースケースでは、一連のシーケンスについて説明します。各シーケンスは、システムの外部にあるもの（参加者）とシステム自体（およびその主要な抽象化）の間の相互作用を表します。」

上記の説明から、ユースケースに関連する特性を取得できます。

  • ユースケースは、自然言語で記述されたナラティブドキュメントです（英語のナラティブなど）。一般的に、ユースケースには、説明するグラフィックスやプログラミング言語の文法（Javaなど）は含まれません。
  • ユースケースで説明されているシナリオは、アクターがシステムとの相互作用と通信から目標（目標）を達成（取得）することを期待しているものです。
  • たとえば、「アイテムの購入」はまさに消費者の消費の目的です。
    「消費者は購入した商品をチェックアウトし、レジ係は購入した商品を記録して支払いを回収します。完了すると、消費者は商品を持って出発します。」
  • ユースケースには、通常のシナリオと複数の例外シナリオがあります。通常のシナリオは、参加者とシステム間の相互作用の通常のプロセスを説明します。システムとの対話の過程で、例外の発生を考慮に入れると、状況の複雑さに応じて、「通常のシナリオの代替パス」で説明することも、別のシナリオで説明することもできます。複雑な例外のシナリオ。
  • システムは参加者と対話するための一連の機能を提供しますが、参加者はシステムで何が起こっているのか、またはその方法を知る必要はなく、システムは結果を参加者に送り返すだけで済みます。したがって、参加者にとって、システムは（またはユースケースのグループ）ブラックボックスです。
  • ユースケースの説明では、システムが何をすべきか（何をすべきか）を強調しており、それをどのように行うか（どのように行うか）を強調しています。したがって、実装の詳細をユースケースの説明に記載しないでください。
  • アクターは直接オペレーティングシステムにアクセスします。ユースケース図では、アクターは「棒人間」アイコンとして表されていますが、参加者は必ずしも実在の人物であるとは限りません。参加者は外部システムの場合もあり、このシステムから情報を取得する必要がある場合があります。

その他のUML図

コメントを残す

メールアドレスが公開されることはありません。