ユースケースモデリングの包括的ガイド

ユースケースモデリングとは何か？

これはソフトウェア開発およびシステム工学で用いられる技術であり、システムの機能要件を記述することを目的としています。ユーザーの視点からシステムがどのように動作すべきかを理解し、文書化することに焦点を当てます。本質的には、「ユーザーのニーズや目標を満たすためにシステムが何をすべきか？」という問いに答えるのに役立ちます。

ユースケースモデリングの主要な概念

機能要件：機能要件とは、システムがその目的を果たすために備えるべき機能、行動、および振る舞いを指します。ユースケースモデリングは、これらの要件を構造化された形で定義し、把握することに主に注力します。

最終ユーザーの視点：ユースケースモデリングは、システムと対話する人々やエントティ（「アクター」と呼ばれる）の視点からシステムを検討することから始まります。これらのアクターが目的を達成したり、タスクを遂行するためにシステムをどのように利用するかを理解することが不可欠です。

相互作用：ユースケースモデリングは、これらの最終ユーザー（アクター）とシステムとの相互作用を捉えることに重点を置きます。システムが単独で何をするかという点だけでなく、ユーザーの行動や要求に対してどのように反応するかが重要です。

ユースケースの基礎：

• ユースケースとは、特定の目的を達成するために、システムが1つ以上の外部エントティ（アクターと呼ばれる）とどのように相互作用するかを記述したものです。
• ユースケースは、必要な詳細度や複雑さに応じて、文章形式または図式形式で記述できます。
• ユースケースは、事前条件、事後条件、主な流れ、代替の流れ、例外など、相互作用の重要な側面を捉えるべきです。

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

ユースケース図は、ユースケースモデリングで用いられる図式表現であり、これらの相互作用や関係を可視化し、伝達するために使用されます。ユースケース図では、通常、アクターが棒人形で表され、ユースケース（特定の機能や特徴）が楕円形または長方形で示されます。線や矢印がアクターとユースケースを結び、どのように相互作用しているかを示します。

 

• • アクター：これらはシステム外部のエントティまたはユーザーで、システムと対話する存在です。人間、他のシステム、あるいは外部のハードウェアデバイスも含まれます。各アクターはシステム内で特定の役割や責任を持っています。
  • ユースケース：ユースケースは、アクターのニーズを満たすためにシステムが実行できる特定の機能やプロセスを表します。各ユースケースには通常、名前と説明があり、何を達成するかを理解するのに役立ちます。
  • 関係：図中のアクターとユースケースを結ぶ線や矢印は、アクターがこれらのユースケースを通じてシステムとどのように相互作用するかを示します。関係の種類として、関連、拡張関係、包含関係などがあり、これらの相互作用の性質を明確に指定するために使用できます。

ユースケースモデリングの実施方法は？

1. ユースケースを理解するには、システムに関与するアクターとユースケースを特定する必要があります。
   アクターとは、システムとの相互作用において役割を持つ外部のエントティです。アクターは人間、他のシステム、あるいは時間的なイベントである可能性があります。
2. ユースケースとは、システムとアクターが共通の目標を達成するために協働する様子を記述するシナリオの集合です1。シナリオとは、特定の状況で何が起こるかを説明するステップの順序です1。
   ユースケースモデリングにおけるアクター：
3. アクターはユースケース図において棒人形で表されます。
   アクターは一般化関係を持つことができ、これは1つのアクターが他のアクターの特徴や振る舞いを継承することを示します。たとえば、StudentアクターはUndergraduate StudentアクターとGraduate Studentアクターの一般化であることができます。
4. アクターは関連関係を持つこともでき、これはアクターがユースケースに関与していることを示します。たとえば、InstructorアクターはGrade Assignmentユースケースに関連付けられることがあります。

アクターとユースケースの関係：

• ユースケースはinclude関係があり、これは1つのユースケースが通常の実行の一部として、別のユースケースの振る舞いを組み込むことを示している。たとえば、認証を必要とする多くの他のユースケースがLoginユースケースを含めることができる。
  • include関係は、1つのユースケース（ベース）が通常の実行の一部として、別のユースケース（インクルージョン）の振る舞いを組み込む2つのユースケース間の依存関係である。
  • include関係は、ベースからインクルージョンへ向かう破線の矢印と、スタereotype «include»で表される。
  • include関係は、共通の機能を再利用したり、複雑なユースケースを簡素化したり、低レベルの詳細を抽象化するために使用できる。

• ユースケースはまたextend関係があり、これは特定の条件下で、1つのユースケースが別のユースケースにオプションまたは例外的な振る舞いを追加することを示している。たとえば、ユーザーが予約をキャンセルすると決定した場合、Cancel ReservationユースケースはMake Reservationユースケースを拡張することができる。
  • extend関係は、1つのユースケース（拡張）が特定の条件下で、別のユースケース（ベース）にオプションまたは例外的な振る舞いを追加する2つのユースケース間の依存関係である。
  • extend関係は、拡張からベースへ向かう破線の矢印と、スタereotype «extend»で表される。
  • extend関係には拡張ポイントを持つことができる。拡張ポイントとは、拡張を挿入できるベースユースケース内の位置である。
  • 拡張ポイントには名前と条件をラベルとして付けることができる。

効果的なユースケースの作成：

• システム境界の特定：
  • システム境界は、ユースケースを囲むボックスであり、システムの範囲を示す。
  • システム境界は、システム内部（ユースケース）と外部（アクター）を区別するのに役立つ。
  • システム境界は、システム名とそのバージョン1で明確にラベル付けされるべきである。
• ユースケースの目的とシナリオの定義:
  • ユースケースの目的は、ユースケースがアクターに対して達成する内容を要約した文である。
  • ユースケースの目的は、具体的で、測定可能で、達成可能で、関連性があり、検証可能でなければならない。
  • ユースケースシナリオは、目的を達成するためにアクターとシステムがどのように相互作用するかを説明する手順の連鎖である。
  • ユースケースシナリオは、完全で、一貫性があり、現実的で、トレーサブルでなければならない。
• 明確で簡潔なユースケース記述の作成:
  • ユースケース記述は、事前条件、事後条件、主な流れ、代替フロー、例外など、ユースケースに関する詳細情報を提供するテキストドキュメントである。
  • ユースケース記述は明確で簡潔で、簡単で正確な言語を使用し、専門用語や曖昧さを避け、一貫したフォーマットに従うべきである。
  • ユースケース記述はまた、一貫性があり、包括的で、すべての可能なシナリオ、結果、バリエーションをカバーし、すべての関連する要件に対応しなければならない。
• ユースケーステンプレートとドキュメント:
  • ユースケーステンプレートは、ユースケース情報を一貫性があり構造的な方法で整理し、提示するための標準化されたフォーマットです。
  • ユースケーステンプレートには、ユースケース名、ID、目的、アクター、優先度、仮定、事前条件、事後条件、主要フロー、代替フロー、例外など、さまざまなセクションを含めることができます。
  • ユースケースドキュメントは、システムの機能を異なる視点から記述するユースケースの集まりです。
  • ユースケースドキュメントは、コミュニケーション、検証、検証、テスト、保守など、さまざまな目的に使用できます。

ユースケースモデリングのベストプラクティス：

• ユースケースモデリングにおけるいくつかのベストプラクティスは以下の通りです：
  • 以下のものを特定する：重要なステークホルダーおよびその目的を特定し、それらをユースケース開発プロセスに参加させる
  • 以下の命名規則を使用する：トップダウンアプローチにより、最も重要なユースケースを特定および優先順位付けする
  • 以下の命名規則を使用する：命名規則ユースケースおよびアクターに対して一貫性があり、意味があり、説明的であるもの
  • 以下の関係を使用する：図および文章による記述互いに補完し、異なる詳細レベルを提供する
  • 以下の関係を使用する：関係拡張、包含、一般化などにより、ユースケース間の依存関係や共通点を示す
  • レビューおよび検証ステークホルダーと協議してユースケースをレビュー・検証し、システム要件と整合していることを確認する

ユースケーステンプレートを用いたユースケースモデリング

問題の説明：大学図書館システム

大学図書館システムは、学生、教職員、職員への効率性およびサービス品質に影響を与えるさまざまな運用上の課題に直面しています。これらの課題には以下が含まれます：

1. 手動による貸出および返却プロセス：図書館は、本の貸出、返却、返却日追跡において紙ベースのプロセスに依存しています。この手動方式は誤りを引き起こしやすく、記録の不一致や図書館職員と利用者との間で偶発的に紛争が生じる原因となっています。
2. 在庫管理：図書館の膨大な書籍および資料の管理に用いられている現在のシステムは古くなっています。効率的な在庫管理システムが欠如しているため、特定の資料を検索することが困難となり、利用者の不満や不要な遅延を引き起こしています。
3. 延滞料金の追跡：貸出超過の本に対する延滞料金の追跡および回収は困難な作業です。図書館職員は、返却日を正確に監視し、罰金を適切に評価するための自動化システムが不足しています。その結果、収益の損失と利用者への不便が生じます。
4. 利用者アカウント管理：利用者アカウント（図書カードの発行および管理を含む）はすべて手動プロセスに依存しています。これにより、新規学生への図書リソースへのアクセス提供が遅れたり、既存会員の利用者情報の更新が困難になります。
5. アクセスの制限：現在の図書館システムは、利用者がオンラインで本の検索、予約、貸出中の資料の更新を行うことができません。この制限により、現代の学生や教職員が期待する利便性とアクセスの容易さが阻害されています。
6. 非効率なリソース配分：図書館職員は、書籍、雑誌、学習スペースなどのリソースの最適な配分を実現する上でしばしば課題に直面します。リアルタイムデータや分析の不足により、リソース配分に関する適切な意思決定が困難です。
7. 情報共有のギャップ：図書館職員と利用者の間に情報共有のギャップがあります。利用者はしばしば図書館のポリシー、新着資料、営業時間の変更を把握しておらず、誤解や不満が生じます。
8. セキュリティ上の懸念：図書館システムには、利用者データの保護や資料の窃盗、不正アクセスを防ぐための十分なセキュリティ対策が欠けています。

これらの課題は、図書館職員および利用者の両方にとって最適でない図書館体験をもたらしています。これらの問題を解決し、大学図書館システムを近代化することは、効率的なサービス提供、利用者の満足度向上、および大学コミュニティ全体の学術体験の改善に不可欠です。

ユースケーステンプレート：

以下は、大学図書館から本を借りるためのユースケーステンプレートと例を表形式で示したものです：

ユースケース名	本を借りる
ユースケースID	UC001
主要アクター	学生
補助アクター	図書館員、書籍在庫システム
事前条件	– 学生は有効な図書館カードを持っている。
	– その本は図書館の在庫に存在する。
事後条件	– その本はシステム上で貸出済みとしてマークされる。
	– 学生はその本を手元に持っている。
メインフロー	1. 説明： 学生は図書館から本を借りたいと希望する。
	大学図書館の本を借りる。
	2. アクターの行動：
	– 学生は自分の図書館カードを図書館員に提示する。
	図書館員に提示する。
	– ライブラリアンは図書カードをスキャンして
	有効性を確認する。
	– 生徒は借りたい本のタイトルまたはISBNを提供する。
	借りたい本のタイトルまたはISBNを提供する。
	– ライブラリアンは図書館のカタログを検索する。
	本を検索する。
	– ライブラリアンは本の利用可能状況を確認する。
	– ライブラリアンは本を生徒に貸し出す。
	生徒に貸し出す。
	– 生徒は本を持ち帰り、図書館を出る。
	図書館を出る。
	3. システムの動作：
	– システムは図書カードの有効性を検証する。
	– システムは本の状態を「貸出中」に更新する。
	“貸出中”に更新する。
	– システムは本の返却日を記録する。
	貸出の返却日を記録する。
	– システムは取引の領収書を生成する。
	取引の領収書を生成する。
	4. 代替フロー：
	– 生徒の図書カードが無効な場合、ライブラリアンは生徒に通知し、ユースケースは終了する。
	ライブラリアンは生徒に通知し、ユースケースは終了する。
	ユースケースは終了する。
	– 要求された本が利用できない場合、ライブラリアンは生徒に通知し、ユースケースは終了する。
	ライブラリアンは生徒に通知し、ユースケースは終了する。
	ユースケースは終了する。
拡張	– 生徒が返却期限を過ぎた本を持っている場合、通知が行われる。
	学生に送信されます。
	– 学生が本を更新したい場合、以下の操作が可能です。
	図書館のウェブサイトを通じて更新を申請できます。
特別な要件	– システムは以下の安全なデータベースを保持する必要があります。
	図書館利用者。
	– 期日および延滞料金はシステムによって計算され、適用されるべきです。
	システムによって強制されます。

使用例：大学図書館から本を借りる

使用例名	本を借りる
使用例ID	UC001
主なアクター	学生
補助アクター	図書館司書、書籍在庫システム
事前条件	– 学生は有効な図書館カードを持っている。
	– その本は図書館の在庫に存在する。
事後条件	– 本はシステム上で貸出済みとしてマークされる。
	– 学生はその本を手元に持っている。
主なフロー	1. 説明： 学生は大学図書館から本を借りたいと考えています。
	大学図書館から本を借りる。
	2. アクターの行動：
	– 生徒は図書カードを図書館員に提示する。
	図書館員に。
	– 図書館員は図書カードをスキャンして
	有効性を確認する。
	– 生徒は借りたい本のタイトルまたはISBNを提供する。
	借りたい本のタイトルまたはISBNを提供する。
	– 図書館員は図書館のカタログを検索する。
	その本を検索する。
	– 図書館員はその本の貸出可能状態を確認する。
	– 図書館員はその本を生徒に貸し出す。
	生徒に貸し出す。
	– 生徒は本を手に取り、図書館を出る。
	図書館を出る。
	3. システムの処理：
	– システムは図書カードの有効性を検証する。
	– システムは本の状態を「貸出中」に更新する。
	“貸出中”に更新する。
	– システムは本の返却日を記録する。
	貸出。
	– システムは取引の領収書を生成する。
	取引の領収書を生成する。
	4. 代替フロー：
	– 生徒の図書カードが無効な場合、図書館員は生徒に通知し、ユースケースは終了する。
	図書館員は生徒に通知し、ユースケースは終了する。
	ユースケースは終了する。
	– 要求された本が利用できない場合、図書館員は生徒に通知し、ユースケースは終了する。
	図書館員は生徒に通知し、ユースケースは終了する。
	ユースケースは終了する。
拡張機能	– 学生が返却期限を過ぎた本を持っている場合、通知が送信される
	学生に送信される。
	– 学生が本を更新したい場合、彼らは
	図書館のウェブサイトを通じて更新を申請できる。
特別な要件	– システムは安全なデータベースを備えるべきである
	図書館利用者。
	– 期限日と遅延料金はシステムによって計算され、
	システムによって強制されるべきである。

上記の表は、ユースケースのテンプレートと例を構造的で整理された形で提示しており、ユースケースの主要な要素を読みやすく、理解しやすくしている。

ユースケースの粒度

ユースケースの粒度の定義: ユースケースの粒度とは、ユースケース仕様における詳細さと組織性の程度を指す。本質的に、ユースケースを文書化する際、システムの機能をどれだけ細かく分解するかを表している。より簡単に言えば、ユースケースをどれだけ小さな部分やステップに分解するかということである。

ユースケース粒度の重要性:

1. コミュニケーションの向上: ユースケースの粒度は、ビジネスアナリスト、開発者、テスト担当者、最終ユーザーなど、ソフトウェアプロジェクトに関与するさまざまなステークホルダー間のコミュニケーションを改善する上で重要な役割を果たす。ユースケースが明確に定義され、適切な粒度で分割されている場合、すべての関係者がシステムの機能や要件をよりよく理解できる。
2. プロジェクト計画: ユースケースの粒度のレベルはプロジェクト計画に影響を与える。より小さく、より細かく粒度分けされたユースケースは、開発作業に必要な時間と労力の見積もりを容易にする。これにより、プロジェクトマネージャーはより正確なプロジェクトスケジュールとリソース配分を策定できる。
3. 明確さと正確さ: 適切な粒度を達成することで、ユースケースが明確かつ正確になる。もしユースケースが高レベルで抽象的すぎると、効果的な開発に必要な詳細が不足する可能性がある。逆に、あまり詳細すぎるユースケースは扱いにくくなり、管理が困難になる。

例: eコマースアプリケーションにおける「ユーザー登録」機能に関連する例を用いて、ユースケースの粒度を説明する。

• 高粒度: 「ユーザー登録」というタイトルの単一のユースケースが、開始から終了まで全体の登録プロセスをカバーする。個人情報の入力、パスワードの作成、パスワードの確認、登録フォームの送信といったすべてのステップを含む。
• 中粒度: ユースケースはより小さく、より焦点を絞った部分に分割される。たとえば、「個人情報の入力」、「パスワードの作成」、「登録の送信」はそれぞれ別々のユースケースとなる可能性がある。それぞれはユーザー登録の特定の側面に焦点を当てる。
• 低粒度: 最低限の粒度では、単一のステップ内のアクションを分解する。たとえば、「個人情報の入力」はさらに「名の入力」、「姓の入力」、「メールアドレスの入力」などに分解される可能性がある。

適切な粒度は、プロジェクトの要件とステークホルダーの具体的なニーズによって異なります。利用事例がすべての関係者にシステム機能を効果的に伝えるために、理解しやすく、管理しやすく、効果的であることを確保するためには、適切なバランスを見つけることが不可欠です。

『効果的な利用事例の書き方』という著書で、アラスタイア・コブンは、目標達成のさまざまな段階を可視化するための簡単な類比を提示しています。彼は、これらの段階を海をたとえ話として考えるよう提案しています。

参考文献：

1. 利用事例図とは何か？（visual-paradigm.com）
2. 利用事例仕様とは何か？