ユースケース分析チュートリアル

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

UMLのユースケース図は、開発中の新しいソフトウェアプログラムのシステム/ソフトウェア要件の主要な形式です。ユースケース図の目的は、システムが何をすべきか（何を）を視覚化することです。この段階では、それをどのように（どのように）行うかは考慮されていません。

ユースケースを指定すると、テキストおよび視覚的な表現（つまり、ケース図）で表すことができます。ユースケースモデリングの重要な概念は、エンドユーザーの観点からシステムを設計するのに役立つということです。これは、外部から見えるすべてのシステム動作を指定することにより、ユーザー用語でシステム動作を伝達するための効果的な手法です。

言い換えれば、システムの使用は外部から見る必要があります。つまり、システムを内部から見るのではなく、システムが外部のアクターに提供する機能を決定するために、より高いレベルから見る必要があります。

ユースケース図の目的

ユースケース図は通常、開発の初期段階で作成され、人々は多くの場合、次の目的でユースケースモデリングを使用します。

• システムのコンテキストを指定する
• システムの要件をキャプチャする
• システムのアーキテクチャを検証する
• 実装を推進し、テストケースを生成する
• アナリスト、ドメインエキスパート、ターゲットエンドユーザーが一緒に開発する

以下のユースケース図の例に示すように、標準形式のユースケース図は統一モデリング言語で定義されています。

このユースケース図の例を編集する

ユースケース図の要素

俳優

各ユースケースには、少なくとも1人のアクターが含まれます。これは、少なくとも1人の参加者（役割）として理解できます。これは、必ずしも人ではありませんが、別のシステムまたはデバイスである場合があります。アクターは複数のユースケースと対話でき、ユースケースは複数のアクターと対話できます。

アクターは必ずしも人、つまりユーザーである必要はありませんが、実際には非人、つまりシステムや時間である可能性があります。

ほとんどの場合、ユーザーは、顧客、従業員、上司など、ユースケース図に関与する人々です。

人間対非人間の俳優

時々、システムは特定の状況で特定の機能を実行するためにさまざまなイベントの影響を受けます。たとえば、監査に合格すると、システムは積極的に手紙を送り、人々に通知します。それで、手紙の送信はシステムによって自動的に実行されますか？このユースケースは実際には時間によってトリガーされ、アクターはタイマーです。たとえば、このユースケースは「毎日5:00に自動的に手紙を送る」と見なすことができ、このイベントをトリガーするアクター（手紙を送る）はシステムではなく、実際にはタイマーアクターです。

プライマリアクターとセカンダリアクター

プライマリアクターは、システムを使用して目標を達成するアクターです。ユースケースは、プライマリアクターの目標を達成するためのシステムとアクター間の相互作用を文書化します。セカンダリアクターは、プライマリアクターの目標を達成するためにシステムが支援する必要のあるアクターです。

• アクターはプライマリまたはセカンダリの場合があります。プライマリアクターは、システムとの対話を開始します。
• セカンダリアクターは通常、システムからヘルプを求められ、セカンダリアクターがユースケースを開始することはありません。

注：アクターのシンボルは、プライマリアクターとセカンダリアクターを区別しません。違いは、ユースケースの説明（ユースケースの説明とも呼ばれます）から推測する必要があります。

例えば：

銀行の融資担当者は、顧客の融資申し込みを確認したいと考えており、プロセスの一部には、リアルタイムの信用格付けチェックが含まれます。

このユースケース図の例を編集する

• ユースケース名。ローン申請書を確認する
• 主演俳優。融資担当者
• 二次俳優。信用格付け制度

アクターを特定するにはどうすればよいですか？

アクターは必ずしも人である必要はありませんが、外部システム、デバイス、またはタイマーである可能性があるため、次の質問をすることで、より具体的なアクターを見つけます。

• システムが開発されたら、誰がシステムを使用しますか？
• システムは誰から、または他のどのシステムからデータを取得する必要がありますか？
• システムがデータを提供するのは誰または他のどのシステムですか？
• システムは他にどのようなシステムに関連付けられますか？
• 誰がシステムを維持および管理しますか？

これらの質問は、システムのアクターを抽象化するのに役立ちます。例としてATMを使用すると、これらの質問に答えることで、より多くのアクターを見つけることができます。

• オペレーターはATMシステムの維持と管理に責任があります
• ATMは、ユーザーアカウントに関する情報を取得するために、バックエンドサーバーとも通信する必要があります。

使用事例

ユースケースは、システムによって実装されることが期待される機能（通常は要件）を表します。一意の名前以外のユースケースの詳細は、図には視覚的に表されていません。これらの詳細は、ユースケースの説明（テキストによる説明）に記載されています。

ユースケースは、目標を達成するためのアクターの役割とシステム間の相互作用を通常定義するアクションまたはイベントステップのリストです。ユースケースは、システム要件を特定、明確化、および整理するための便利な手法です。ユースケースは、システムとユーザーの間で可能な一連の相互作用で構成され、達成する機能と発生する可能性のあるエラーの解決策を定義します。

ユースケースを特定する方法は？

アクターを見つけたら、主に各アクターがシステムから必要とするサービス、またはアクターがシステムをどのように使用するかを見て、アクターに基づいてシステムのユースケースを決定できます。ユースケースの特定は、（参加者ごとに）次の質問から始めることができます。

• アクターがシステムを使用するのはなぜですか？
• 参加者は、システム内のデータを作成、変更、削除、アクセス、および保存しますか？もしそうなら、アクターはこれらの操作をどのように実行しますか？
• アクターは特定の外部イベントをシステムに通知しますか？
• システムは特定の内部イベントをアクターに通知しますか？

以上をまとめると、ATMシステムのユースケース図は次のようになります。

ユースケースは、静的または動的なもの、またはタスクまたはシステムの省略記号で表されます。

システム境界

システム境界は、ユースケースを長方形の境界にグループ化することによってシステムを記述し、ビジュアルパラダイムのシステム境界はユースケースの封じ込め動作を提供します。

アクターは、開発中のシステムと相互作用する役割（人間のアクターまたは人間以外のアクター）です。したがって、アクターはシステム境界の外側に配置し、システム境界内に配置されたユースケースと対話する必要があります。

ご了承ください： 

アクターは、システムの境界によって定義されます。定義するシステム境界がATM自体に限定されている場合、バックエンドサーバーは外部システムであり、アクターとして抽象化できます。

定義するシステム境界が銀行システム全体に拡張され、ATMとバックエンドサーバーの両方が銀行システム全体の一部である場合、バックエンドサーバーはアクターとして抽象化されなくなります。

関係

これらの3つの重要な記号について学習した後、関係の知識とユースケース図の描画を続けます。参加者とユーザーケースの直接的な関係が描かれ、その関係は矢印のない線として使用され、リンク線と呼ばれる双方向の関係を示します。

ユースケースは、<< include >>、<< extend >>、または<< generalization >>の関係（この投稿で後述）によって接続されるいくつかのユースケースに分類できます。

コミュニケーションリンク関係

これは、アクターとユースケースの間の双方向通信を表すため、バイナリ関係です。

このユースケース図の例を編集する

<<含める>>関係

インクルード関係とは、ユースケースに他のユースケースが含まれることを意味します。インクルードリレーションシップの目的は、インクルードリレーションシップを使用して、同じユースケースを再度説明する繰り返しを減らすことです。多くのケースが同じ部分の機能を共有している場合は、機能を分離して、他のユースケースをケースに含めることができます。

たとえば、図書館員は、本がチェックアウトされたときに借りた本を記録するためにコードを読む必要があります。また、コードを読むことはアクションの繰り返し部分であるため、本が返却されたときに返却された本を記録するためにコードを読む必要があります。 、別のユースケースにすることができ、借りた本と返却した本にこのケースを含めることができます。

このユースケース図の例を編集する

ユースケースAに別のユースケースBが含まれている場合、Aの実装では、タスクを完了するためにBの実装が必要です。ただし、Bはそれ自体から独立しています。つまり、BはAについて何も知る必要はありません。Bは他のユースケースにも含めることができます。

<<拡張>>関係

ユースケースBが別のユースケースAを拡張する場合、Aの実装には、そのタスクを完了するためのBの実装を条件付きで含めることができます。つまり、場合によっては、AはBなしでタスクを完了できます。ただし、説明されている条件によっては、AはBを必要とする場合があります。この場合、BはBに依存します。ただし、説明されている条件によっては、AはBを必要とする場合があります。 。この場合、BはAに依存しており、単独で存在することはできません。このため、Bを複数のユースケースに拡張することはできません。Aのユースケースの説明には、Bから必要な実行ステップが含まれます。このポイントは拡張ポイントと呼ばれます。

このユースケース図の例を編集する

在庫がないときにシステムが自動的に商品を注文し、マネージャーが注文を直接実行する必要がない別の例を見てみましょう。以下のユースケース図を参照してください。

このユースケース図の例を編集する

一般化関係

一般化された関係は、クラス図のオブジェクト指向言語の一般化された関係に似ており、役割（アクター）とユースケースの一般化に適用できます。

たとえば、予約システムでは、「電話でチケットを予約する」と「オンラインでチケットを予約する」の2種類の予約方法と、基本的なユースケース「ブックティッカー」があり、一般化を使用してケースを作成できます。そして、一般化された関係を示すために、親のユースケース（予約）に<< Essential >>を追加します。

このユースケース図の例を編集する

ユースケース図で関係について話し合う

• 一般的なユースケース図では、アクターとユースケースの間の関係、つまり、それらの間の通信の関連付けのみを表します。
• さらに、参加者とアクターの間の一般化、およびユースケース間の包含、拡張、および一般化の関係についても説明できます。
• これらの関係を使用して、既存のユースケースモデルを適応させ、再利用のためにいくつかの共通情報を抽出して、ユースケースモデルの保守を容易にします。
• ただし、アプリケーションでこれらの関係を選択する際には注意が必要です。一般に、これらの関係はユースケースと関係の数を増やすため、ユースケースモデルの複雑さが増します。
• さらに、ユースケースモデルは通常、完成後に調整されるため、ユースケースモデリングの初期段階でユースケース間の関係を抽象化するために急ぐ必要はありません。

ユースケース–イベントの流れ

ユースケース図は、システム機能の全体像を示し、どの参加者がシステムと対話するか、および各アクターがシステムからどのサービスを取得する必要があるかを知ることができます。

ユースケースは、アクターとシステム間の会話を説明しますが、この会話の詳細はユースケース図に表されていないため、各ユースケースについて、イベントストリームの観点からこの会話の詳細を説明できます。

ユースケースシナリオとイベントの流れ–ATMでお金を引き出す

たとえば、ATMシステムの「引き出し」の場合は、次のようなイベントのフローで表すことができます。

通常のシナリオ–資金の引き出し–イベントの基本的な流れ：

1. ユーザーがクレジットカードを挿入します
2. PINを入力してください
3. 引き出し金額を入力してください
4. 現金を引き出す
5. システムを終了し、クレジットカードを取得します

ただし、これは撤回のユースケースの通常のシナリオのみを説明しています。実際のATMシステムとして、次のような他のさまざまなシナリオも考慮する必要があります。

• 無効なクレジットカード、
• 間違ったパスワード、
• ユーザーの口座の現金残高が不足しているなど。

これらの考えられるすべての状況（正常と異常の両方）は、ユースケースのシナリオと呼ばれ、シナリオはユースケースのインスタンスとも呼ばれます。シナリオは、ユースケースのインスタンスとも呼ばれます。ユースケースのさまざまなシナリオの中で、最も一般的なシナリオは基本プロセスによって記述され、他のシナリオは代替プロセスによって記述されます。

代替シナリオ

ATMシステムの「撤回」ユースケースでは、次のような代替プロセスを取得できます。

撤回–代替イベントプロセス。

1. 代替シナリオI：ユーザーは、基本プロセスの任意のステップでオプトアウトして、基本プロセスのステップ5に進むことができます。
2. 代替プロセスII：基本プロセスのステップ1で、ユーザーが無効なクレジットカードを挿入し、システムがエラーを表示してクレジットカードを終了し、ユースケースが終了します。
3. 代替プロセスIII：基本プロセスのステップ2で、ユーザーが間違ったパスワードを入力すると、システムはエラーを表示し、ユーザーにパスワードを再入力して基本プロセスのステップ2に戻るように促します。3回の誤ったパスワード入力の後、クレジットカードはシステムによって没収され、ユースケースは終了します。
4. …

基本シナリオと代替シナリオを組み合わせることで、ユースケースで発生する可能性のあるさまざまな状況をすべて明確に説明できます。ユースケースのイベントのフローを説明するときは、要件の完全性を確保するために、考えられるすべてのシナリオを可能な限り説明したいと思います。

ユースケースモデルとユースケース図

アクターとユースケースで構成されるユースケース図がユースケースモデルであるという誤解を避けることが重要です。ユースケース図は、システムが提供できるサービスの単なる視覚的表現であり、システムの機能。

ユースケースモデルは、ユースケース図と各ユースケースの詳細な説明、ユースケース仕様で構成され、RUPでテンプレートとして提供されます。

簡単な説明
ユースケースの役割と目的の簡単な説明。

イベントのフローイベントの 
フローは、基本シナリオと代替シナリオを含むすべてのシナリオを表す必要があります。

ユースケースシナリオ
成功シナリオと失敗シナリオが含まれ、シナリオは主に基本フローと代替フローの組み合わせです。

特別な要件
ユースケースに関連する非機能要件（パフォーマンス、信頼性、可用性、スケーラビリティなど）と設計上の制約（オペレーティングシステム、開発ツールなど）について説明します。

事前条件
ユースケースを実行する前に、システムが存在している必要がある状態。

事後条件
ユースケースが実行された後にシステムが存在する可能性のある一連の状態。

ユースケース仕様は基本的にテキスト表現であり、状態図、アクティビティ図、またはシーケンス図を使用して、イベントの流れをより明確に説明するオプションがあります。ユーザーインターフェイスとプロセスの任意のグラフィック表現、または他のグラフィック、つまりワイヤーフレームは、表現の明確さを向上させるのに役立つ限り、ユースケースに添付できます。

例えば：

• アクティビティ図は、複雑な意思決定プロセスを説明するのに役立ちます。
• 状態遷移図は、状態に関連するシステムの動作を説明するのに役立ちます。
• シーケンス図は、時間ベースのメッセージングを説明するのに適しています。

ユースケースツール

オンライン版

無料の描画ツールであるVisualParadigm Online（VP Online）の無料バージョンは、UML、ERD、および組織図をサポートしています。直感的なUML描画エディターを使用して、ユースケース図をすばやく描画できます。この無料のUMLツールには、広告、アクセス期間の制限、図の数、図形の数などの制限はありません。UMLを自由に描画できます。UMLを自由に描画します。あなたは、個人的および非営利目的で作成した図を所有しています。

デスクトップ版

2004年から利用可能なVisualParadigm Community Editionは、非営利目的でのみ無料のUMLソフトウェアを提供し、UMLモデリングの最初の一歩を踏み出したユーザー、および無料のクロスプラットフォームUMLモデリングソフトウェアを必要とするユーザーをサポートします。学生プロジェクトにUMLを適用するなどの個人的な使用。

参考文献

• ユースケース図とは何ですか？
• ユースケースモデルのアクターのタイプ
• ユースケース図を使用してユーザー要件を特定する
• ユースケース仕様とは何ですか？
• アジャイルソフトウェア開発のユーザーストーリーとユースケース
• アジャイル開発のためのユースケース主導のアプローチ

UMLリソース

• UMLとは何ですか？
• なぜUMLモデリングなのか？
• 14のUMLダイアグラムタイプの概要