レベル: 初級 Scott W. Ambler (scott_ambler@ca.ibm.com), Practice Leader, Agile Development, Rational Methods Group, IBM
2000年 7月 01日 エッセンス・モデリングは、使い易さに重点をおいた (最近、"usage-centered" という言い方がされています）設計の基本となるものです。今週は Scott Ambler が、エッセンス・ユース・ケース・モデル開発のための背景とヒントをいくつか提供します。
要件モデリングの重要な目的は、システムで対処すべきビジネス問題を理解して、その動作要件を理解できるようにすることです。オブジェクト指向の開発も大切ですが、動作要件をモデル化するために開発すべき基本構造は、ユース・ケース・モデル です。ユース・ケース・ダイアグラムは、標準 Unified Modeling Language (UML) 構造の一部です。ユース・ケース・モデルには、エッセンス ・ユース・ケース・モデルと、システム ・ユース・ケース・モデルの 2 つの基本的な種類があります。
- エッセンス・ユース・ケース・モデルは、ビジネス ・ユース・ケース・モデルあるいは抽象的 ユース・ケース・モデルとよく呼ばれ、動作要件をテクノロジーから独立した視点でモデリングします。
- システム・ユース・ケース・モデルは、具体的 ユース・ケース・モデルまたは詳細 ユース・ケース・モデルとも呼ばれ、動作要件の分析をモデル化し、ユーザー・インターフェースの側面への参照を含む、システム使用方法を詳細に説明します。
エッセンス・モデリングとは？
エッセンス・モデリングは、ソフトウェア開発のアプローチにおいて、使い易さに重点をおいた設計の基本となるものです (「Software for Use」に詳しく説明されています。参考文献を参照してください。) エッセンス・モデリングは、テクノロジーを使用しない、理想化され抽象的な記述によって、問題の本質を把握することを目的としています。その結果として得られる設計モデルは柔軟性が高く、多くのオプションがオープンになり、テクノロジーの変化に順応しやすくなります。エッセンス・モデリングは、要件やインプリメント・テクノロジーの変更に直面しても有効である可能性が高いので、具体的な表記に比べて安定性が高いです。用途のエッセンス・モデリングでは目的 (ユーザーが実現しようとしているもの、およびその行為の理由) が重視されます。つまり、エッセンス・モデルは、システムの要件を把握するのに理想的なものなのです。
ユース・ケースとは？
ユース・ケースは、動作主に測定可能な値を提供する、一連のアクションです。このほかにも、実世界の動作主がシステムと対話する方法をユース・ケースが記述するという見方があります。エッセンス・ユース・ケースは単純で、抽象的で、一般的なユース・ケースで、ユーザーの意図をテクノロジーおよびインプリメンテーションに依存しない方法で把握します。エッセンス・ユース・ケースは、構造化された叙述であり、アプリケーション・ドメインおよびユーザーの言語で表現され、単純で、一般的で、抽象的で、テクノロジーを使用せず、インプリメンテーションに依存しない、単一タスクまたは対話の記述です。エッセンス・ユース・ケースは、システムとの関係でなんらかの役割を果たすユーザーの立場から見て、完全で、分かりやすく、巧みに設計されていて、対話の基礎となる目的または意図を具体的に示します。
システム・ユース・ケースとエッセンス・ユース・ケースの比較
2 種類のユース・ケースを「セミナー登録」として考えてみましょう。例 1は、単純化されたシステム・ユース・ケース (従来型または具体的ユース・ケースとも呼ばれます) で、例 2 はエッセンス・ユース・ケースです。以下の興味深い事が分かりました。
- システム・ユース・ケースには、インプリメンテーションの詳細が多く組み込まれています。たとえば、教務係という概念がなくなって、システム という語に置き換えられています。これは、日常的な登録事務の多くを自動化することが決定されたことを意味しています。システム・ユース・ケースの作成者は、問題が課した要件を、ユーザー・インターフェースがどのようなもかについての暗黙の決定と併せて分析し、記述します。しかし、エッセンス・ユース・ケースの作成者はそのようなことを行いません。
- システム・ユース・ケースでは、「UI23 セキュリティー・ログイン画面 (Security Login Screen)」や 「UI89 登録要約レポート (Enrollment Summary Report)」などの画面およびレポートを参照します。エッセンス・ユース・ケースでは、このような参照を行いません。これもまた、インプリメンテーションの詳細を反映します。たとえば、システムが、画面 (恐らく HTML ページとはまったく異なるように) と印刷レポートとしてインプリメントされるように決定します。ただし、エッセンス・ユース・ケースでも、主要なユーザー・インターフェース・エレメントと、画面およびレポートの基本バージョンを同じように簡単に参照することができるので、このようにすることをお勧めします。例 2 には、ユーザー・インターフェース・エレメントへの参照が含まれていません。この参照が行われていない例を示したかったからです。
- どちらのバージョンも、「BR129 登録資格を判別する」などの業務処理規則定義を参照します。これは、システムがインプリメントしなけばならないドメインの主な特性を、業務処理規則が反映するためです。
- システム・ユース・ケースのほうが、エッセンス・ユース・ケースよりもステップ数が多くなっています。実はこれは、私がユース・ケースを書くスタイルを反映しているからです。私は、どのユース・ケース・ステップも 1 つのステップだけを反映すべきであると信じています。この方法には利点がいくつかあります。まず、各ステートメントの理解と実証が容易なため、ユース・ケースがテストしやすくなります。また、処理が 1 つしかしない場合は、ステートメントからの分岐がしやすいので、代替コースが書きやすくなります。
- ユース・ケース・ステップは受動態ではなく能動態で書かれています。「教務係は学生に受講料を通知する」というステートメントのほうが、「学生は教務係から受講料を知らされる」というステートメントよりも簡潔です。
- どちらのバージョンも「ユース・ケースが終了する」、または「～の場合にユース・ケースが終了する」のようなステップで終わり、処理過程の論理が完全に定義されていることを示しています。
従来のユース・ケースまたはシステム・ユース・ケースには一般的に、まだ設計されていない基底テクノロジーのインプリメンテーションや、ユーザー・インターフェースに関する前提事項が、だいたいは隠れてあるいは暗黙的に、あまりにも多く組み込まれています。この特質は、分析および設計作業の段階では便利ですが、要件を扱うときには、あまり良いとは言えません。一方、エッセンス・ユース・ケースは、目的または意図を実現する具体的なステップまたはメカニズムではなく、ユーザーの目的あるいは意図を基にしています。エッセンス・ユース・ケースは、必要なエンジニアリング作業の一部として作成して、分析および設計作業でそれをシステム・ユース・ケースに進化させます。
 |
例 1: システム・ユース・ケースとしての「セミナーへの登録」
名前: セミナーへの登録
説明:
在学生を、受講資格のあるセミナーに登録する。
事前の状態:
学生は大学に登録されている。
事後の状態:
学生に資格があり、また定員に余裕がある場合には、希望する講座に登録できる。
基本的な処理の流れ:
- ある学生が、あるセミナーへの登録を希望している。
- その学生は「UI23 セキュリティー・ログイン画面」を使用して、自分の名前と学生番号をシステムに入力する。
- システムは、業務処理規則「BR129 登録資格を判別する」に従って、その学生が大学のセミナーに登録する資格があるかを検証する。
- システムは「UI32 セミナー選択画面」を表示する。この画面には、選択可能なセミナーのリストが表示される。
- 学生は登録したいセミナーを示す。
- システムは、業務処理規則「BR130 学生のセミナー登録資格を判別する」に従い、その学生がそのセミナーに登録する資格があることを検証する。
- システムは、業務処理規則「BR143 学生のセミナー・スケジュールを検証する」に従って、そのセミナーがその学生の既存スケジュールに合うことを検証する。
- システムは、講座案内に記載された受講料と、その学生に適用される受講料、および適用される税金に基づいて、そのセミナーの受講料を計算する。業務処理規則「BR 180 受講料を計算する」および「BR45 セミナーの税金を計算する」を適用する。
- 学生は「UI33 セミナー受講料表示画面」で受講料を表示する。
- システムは学生に対し、そのセミナーに登録したいかどうかを尋ねる。
- その学生はそのセミナーに登録したいことを示す。
- システムはその学生をそのセミナーに登録する。
- システムは、「UI88 セミナー登録要約画面」を介して、登録が正常に行われたことをその学生に通知する。
- システムは、業務処理規則「R100 学生にセミナー受講料を請求する」に従い、セミナー受講料をその学生に請求する。
- システムはその学生に、登録に関する印刷された文書を希望するかどうかを尋ねる。
- 学生は、印刷された文書を希望することを示す。
- システムは登録文書「UI89 登録要約レポート」を印刷する。
- 学生が印刷済み文書を受け取ると、ユース・ケースが終了する。
|
|
|
例 2: エッセンス・ユース・ケースとしての「セミナーへの登録」
名前: セミナーへの登録
説明:
在校生を、受講資格のあるセミナーに登録する。
事前の状態:
学生は大学に登録されている。
事後の状態:
学生に資格があり、また定員に余裕がある場合には、その講座に登録できる。
基本的な処理の流れ:
- ある学生が、あるセミナーへの登録を希望している。
- その学生は、自分の名前と学生番号を教務係に提示する。
- 教務係は、業務処理規則「BR129 登録資格を判別する」に従って、その学生が大学のセミナーに登録する資格を得ていることを検証する。
- 学生は、選択可能なセミナーのリストから登録したいセミナーを示す。
- 教務係は、業務処理規則「BR130 学生のセミナー登録資格を判別する」に従い、その学生がそのセミナーに登録する資格があることを検証する。
- 教務係は、業務処理規則「BR143 学生のセミナー・スケジュールを検証する」に従って、そのセミナーがその学生の既存スケジュールに合うことを検証する。
- 教務係は、講座案内に記載される受講料、その学生に適用される受講料、および適用される税金に基づいて、そのセミナーの受講料を計算する。業務処理規則「BR 180 受講料を計算する」および「BR45 セミナーの税金を計算する」を適用する。
- 教務係は学生に受講料を通知する。
- 教務係は、学生がそのセミナーへの登録を希望していることを確認する。
- 学生はそのセミナーに登録したいことを示す。
- 教務係は学生をそのセミナーに登録する。
- 教務係は、業務処理規則「BR100 学生にセミナー受講料を請求する」に従い、その学生の請求書に該当の受講料を加算する。
- 教務係は、その学生が登録されたことを本人に確認する。
- ユース・ケースが終了する。
|
|
参考文献
ユース・ケース・モデリングの詳細については、以下を参照してください。
著者について
記事の評価
| 
