ユースケースモデリング

 UML ユースケース図 は、開発中の新しいソフトウェアプログラムのシステム/ソフトウェア要件の主要な形式です。ユースケースは、システムの予想される動作（何）を指定し、それを実現する正確な方法（方法）ではありません。ユースケースの完全なセットは、システムを使用するためのすべての異なる方法を指定し、したがって、システムのスコープを制限するシステムに必要なすべての動作を定義します。

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

ユースケース図の概要

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

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

• ユースケースは、議論中のシステムと特定の目標に関連するその外部アクターとの間の相互作用の可能なシーケンスのコレクションです。
• 各ユースケースは、ユーザーの観点から見たシステム内のイベントの完全なコースです。
• 一度指定されたユースケースは、テキスト表現と視覚的表現の両方で表すことができます（つまり、ユースケース図）。
• ユースケースは、要件を指定し、実際にソフトウェア開発プロセス全体を推進するために、コンポーネントおよびオブジェクトコミュニティが好む方法です。
• ユースケースは通常、かなり主要なタスクに固執します。ユーザーが実行できるすべてのアクションについて記述する必要はありません。

ユースケースアプローチの利点

ユースケースには、ユーザー要件の定義以外にも多くの利点があります。ユースケースは次の目的で使用できます。

• ユースケースヘルプを使用して、システムの機能要件を把握します。
• ユースケースは追跡可能です。
• ユースケースは、作業の見積もり、スケジューリング、および検証の基礎として役立ちます。
• ユースケースは、要件をキャプチャする方法から、プログラマーへの開発ガイドライン、テストケース、そして最終的にはユーザードキュメントに至るまで、反復ごとに進化する可能性があります。
• ユースケースの代替パスは、システムの堅牢性を向上させることができる追加の動作をキャプチャします。
• ユースケースは、ビジネスユーザーが簡単に理解できることが証明されているため、ソフトウェア開発者とエンドユーザーの間の優れた架け橋であることが証明されています。
• ビジネスドメインクラスとその関連を特定する

俳優

• 誰かがユースケース（システム機能）と対話します。
• 名詞で名付けられました。
• 俳優はビジネスで役割を果たします
• ユーザーの概念に似ていますが、ユーザーはさまざまな役割を果たすことができます
• 例えば：
• 教授。インストラクターになることも研究者になることもできます
• 2つのシステムで2つの役割を果たします
• アクターはユースケースをトリガーします。
• アクターはシステム（入力）に対して責任があり、アクターはシステム（出力）からの期待を持っています。

使用事例

• システム機能（プロセス—自動または手動）
• 動詞+名詞（または名詞句）によって名前が付けられます。
• すなわち何かをする
• 各アクターはユースケースにリンクされている必要がありますが、一部のユースケースはアクターにリンクされていない場合があります。

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

• ユースケースへのアクターの参加は、アクターをユースケースに強固なリンクで接続することによって示されます。
• アクターは、関連付けによってユースケースに接続できます。これは、アクターとユースケースがメッセージを使用して相互に通信することを示します。

システムの境界

• システム境界は、要件ドキュメントで定義されているシステム全体である可能性があります。
• 大規模で複雑なシステムの場合、各モジュールがシステムの境界になることがあります。
• たとえば、組織のERPシステムの場合、個人、給与、経理などの各モジュール。
• これらの各ビジネス機能に固有のユースケースのシステム境界を形成できます。
• システム全体は、システム全体の境界を表すこれらすべてのモジュールにまたがることができます

6ステップのユースケース分析

ユースケースを開発するときは、機能パーティション（対象システムの主要な機能カテゴリのリスト）から始める必要があります。これは、どの領域に焦点を当てる必要があるかを特定するのに役立ちます。

ステップ1—アクターを特定する：システムを直接使用するのは誰かを特定します。これらはアクターです。

• ユースケース開発の主要なコンポーネントの1つは、アクターです。
• アクターは、システムユーザーが果たす特定の役割であり、システムを使用するときに同様の動作を示すユーザーのカテゴリを表します。
• アクターは、人またはコンピューターシステムの場合があります。
• 主なアクターは、システムの支援を必要とする目標を持っているアクターです。
• 二次アクターは、システムがその目標を達成するために支援を必要とするアクターです。
• アクターの1人が検討中のシステムとして指定されています。
• 人はいくつかの役割を演じることができ、それによってコンピューターシステムのオペレーターやエンドユーザーなどの複数のアクターを表すことができます。

ステップ2：それらのアクターの1つを選択します。

• ターゲットシステムのユースケースを特定するために、システムアクターを特定します。
• 良い出発点は、システム設計をチェックし、それが誰を助けることになっているのかを特定することです。

ステップ3—ユースケースを特定する：そのアクターがシステムで何をしたいのかを定義します。アクターがシステムで実行したいこれらの各ことは、ユースケースになります。

• アクターがシステムでやりたいことは目標になります。
• 目標は、ユーザーのアクションの最終結果です。目標には2つのタイプがあります。最初のタイプは厳格な目標です。
• この目標は完全に満たされる必要があり、ターゲットシステムの最小要件を説明します。
• ユースケースを特定するために、アクターの観点から要件仕様を読み、アクターとして機能するユーザーと話し合いを続けることができます。
• すべてのアクターがシステムとの対話で実行できるすべてのことを定義することにより、システムの完全な機能が定義されます。

ステップ4—通常のユースケースシナリオを特定する：これらのユースケースのそれぞれについて、そのアクターがシステムを使用しているときに最も通常のコースを決定します。通常何が起こるか。

• ユースケースには、1つの基本コースといくつかの代替コースがあります。
• ベーシックコースは最もシンプルなコースで、問題なくリクエストが届きます。
• 基本コースのバリエーションと発生する可能性のあるエラーを説明する代替コースがある場合があります。
• これらは、ユースケースの拡張として文書化されています。

ステップ5—ユースケースの説明を作成する：ユースケースの説明でその基本的なコースを説明します。

• 使用シナリオは、ユーザーの視点からわかりやすい言葉で書かれています。
• 特定された目標を達成するために必要な手順は、イベントのフローとして知られているように書き出されます。

ステップ6—ユースケースの代替パスを開発する：基本コースに満足したら、代替案を検討し、それらを拡張ユースケースとして追加します。

ユースケースの代替シナリオ

ユースケースでは、物事がうまくいかない、または うまく いか ない 場合にシステムがどのように応答するかについても説明します  が、主な成功シナリオで説明した方法ではありません。これらの状況を 拡張機能と呼びます。

• 例外 と 代替の2つの種類があります 。
• 例外は障害状態です（問題が発生しました）。
• 代替案は、物事を正しく進めるための単なる別の方法です。

詳細のユースケースレベル

ユースケースの粒度とは、ユースケースの仕様内で情報を整理する方法と、ある程度、情報が記述される詳細のレベルを指します。適切なレベルのユースケースの細分性を実現すると、利害関係者と開発者の間のコミュニケーションが容易になり、プロジェクト計画が改善されます。

効果的なユースケースの作成におけるAlastairCockburn  は、海の観点から考えることにより、さまざまなレベルの目標レベルを視覚化する簡単な方法を提供します。

ご了承ください：

• ユースケース自体はあらゆる可能性について多くの詳細を掘り下げる可能性がありますが、ユースケース図は多くの場合、青写真としてのシステムのより高いレベルのビューに使用されます。
• ユースケースを、必要のない場合は詳細度を下げて、より粗いレベルで作成すると便利です。

今すぐ「ユースケース図とは」に答えて、プロジェクトにユースケースを適用できることを願っています。他のUMLダイアグラムの種類について詳しく知りたい場合は、UMLガイド：  14のUMLダイアグラムタイプの概要を確認してください。

参考文献

• ユースケース図の描き方
• ユースケース図チュートリアル
• ユースケースの説明