応用情報技術者 2011年 秋期 午後 問08

解答の導き方

1. 問題の狙いと前提を確認します。設問は図1の空欄([a][b][c])に適切なユースケース名を入れ、凡例に従ってユースケース間の関係（汎化／特化、包含、拡張など）を決める問題です。設問の指示に「凡例で定義した関連、汎化、特化、包含、拡張のうち、“関連”についての記述は完了しており、これ以上増えない。」とあるので、図に描かれているアクタとユースケース間の実線（関連）はそのまま扱い、アクタ－ユースケースの関連を新たに増やさないことに注意します。
2. 範囲を確定して候補を絞ります。表3に「システムの要求分析の範囲は、運行時間内の車内の運用に関する機能とすること。」とあり、かつ本文に「両替金の補充は、管理部門が運行時間外に行う。」とあるため、ユースケース「両替金を補充する」はシステムの対象外（図に含めない）です。したがって表2の残りのユースケースが図の未定位置に入ります。
3. [a] の決定（理由と根拠）

• 問題文に「乗客がバスから降車する際、ICバスカードを利用していれば、ICバスカードを運転席横の運賃箱にかざすと運賃が確定する。IC整理券を利用していれば、IC整理券を運賃箱に投入すると運賃が確定する。運賃が確定すると、それを“運賃の残金”の初期値として後述の〔精算処理〕が実行される。」とあることから、降車時に運賃を確定する処理が明記されています。表2にあるユースケース名の中でこれに対応するのは項番3の「運賃を確定させる」です。よって [a] = 「運賃を確定させる」です。
• また同文に「乗車区間未確定処理…運転手が運賃箱にその金額を運賃として設定する。」とあるため、「運賃を確定させる」には運転手も関与します。従って運転手をこのユースケースのアクタとして関連付けます（図の関連線は問題で与えられているものを用いる）。

1. [b] の決定（理由と根拠）

• 運賃確定の直後に実行されるのが「精算処理（運賃を支払う）」であり、表2の項番5は「ICバスカードで支払う」です。ICカードを使って支払う処理は、運賃確定→精算の流れに関係するため、図の右側にある空欄 [b] は「ICバスカードで支払う」に当てはまります。よって [b] = 「ICバスカードで支払う」です。

1. [c] の決定（理由と根拠）

• 残る下部の空欄は、表2の「現金を両替する」に対応します。問題文に「釣銭が必要な乗客は、運賃箱の両替機能で両替してから運賃を支払う。」とある点からも、このユースケースは乗客が利用するものであり、図の下部に位置する [c] は「現金を両替する」で適切です。よって [c] = 「現金を両替する」です。

1. ユースケース間の関係の決定（凡例に従う根拠）

• 包含（<>）の採用根拠：問題文に「運賃が確定すると…後述の〔精算処理〕が実行される。」とあるため、運賃を確定させる処理が完了すると必ず精算処理（＝運賃を支払う）が実行されます。これは「必ず呼ばれる」振る舞いなので、ユースケース図では「運賃を確定させる」→包含（<>）→「運賃を支払う」と表現します（凡例の包含は「AはBを包含する <>」の向き）。
• 汎化／特化（specialization）の採用根拠：表2に「運賃を支払う」は「抽象ユースケース。具体的な処理は項番5、6のユースケース。」と明記されています。抽象ユースケースと具体的ユースケースの関係は汎化／特化で表現します。したがって「ICバスカードで支払う」と「現金で支払う」はそれぞれ「運賃を支払う」の特化（子）であり、凡例に従って子から親へ向かう実線＋三角矢頭で結びます。
• 「現金を両替する」と「現金で支払う」の関係については、本文で「釣銭が必要な乗客は…両替してから運賃を支払う。」とあり、両替は任意の前処理です（条件付き）。UML的には拡張（<>）で表現するのが自然ですが、図では独立ユースケースとして乗客と関連づけても要件は表現できます。問題の模範図は「現金を両替する」を乗客と関連させる構成をとっているため、ここではそのように扱います。必要ならユースケース記述側で「条件：釣銭が必要な場合」などと記述します。

1. まとめ（図上の具体的配置／関係）

• [a] = 「運賃を確定させる」：アクタは「乗客」（既存の関連）および「運転手」。
• [b] = 「ICバスカードで支払う」：ユースケース「運賃を支払う」の特化（汎化図の子）。
• [c] = 「現金を両替する」：アクタは「乗客」。
• 「運賃を確定させる」 ――<>──▶ 「運賃を支払う」（確定後に必ず精算処理を実行するため）。
• 「ICバスカードで支払う」 ──▷ 「運賃を支払う」 （三角矢頭：特化）
  「現金で支払う」 ──▷ 「運賃を支払う」 （三角矢頭：特化）
• 「両替金を補充する」は範囲外のため図に入れない（管理部門の運行時間外作業）。

誤りやすいポイント

• 「運賃を支払う」を包含（<>）の親として扱ってしまう誤り。表2に「運賃を支払う」は「抽象ユースケース。具体的な処理は項番5、6のユースケース。」とあるため、5・6は特化（子）として描くのが正解です。
• 包含と拡張を取り違える誤り。本文に「運賃が確定すると…精算処理が実行される」とある場合は必ず実行される処理なので包含（<>）で表します。拡張（<>）は条件付き・任意の処理に使います。
• 範囲外のユースケースを図に入れてしまう誤り。表3の「システムの要求分析の範囲は、運行時間内の車内の運用に関する機能とすること。」と、本文の「両替金の補充は、管理部門が運行時間外に行う。」を見落とすと「両替金を補充する」を誤って入れてしまいます。
• アクタ－ユースケースの関連（実線）を勝手に増やす誤り。設問に「“関連”についての記述は完了しており、これ以上増えない。」とある点を忘れないでください。
• ループ（繰り返し）を図に無理に書こうとする誤り。表3にある「項番6のユースケースは、精算が完了するまで繰り返し実行できること。」はユースケース記述（基本シナリオ／代替シナリオ）で扱い、図では明示しないのが通常です。

FAQ

解答の論理構成

1. 代替シナリオ1の3行目〔a〕
   – 代替シナリオ1はICバスカードを持つ乗客が「チャージ金額が初乗り金額未満」のケースです。
   – 【問題文】では「チャージ金額が初乗り金額未満の場合は、警告するが乗車は可能である。」と明記されています。
   – したがってシステムが金額不足を検知し、乗客に警告する動作を記述した「キ：システムは、チャージ金額が初乗り金額未満であることを確認して乗客に警告する。」が適切です。
2. 代替シナリオ2の1行目〔b〕
   – 代替シナリオ2はICバスカードを使わない乗客の通常手順です。
   – 【問題文】に「ICバスカードを持っていなければ、整理券箱が発券するIC整理券を取り出す。」とあるので、最初の行動はIC整理券を取ることになります。
   – よって「コ：乗客は、整理券箱からIC整理券を取り出す。」が入ります。
3. ユースケース「現金で支払う」の事前条件〔c〕
   – 現金精算は運賃確定後に開始されます。
   – 【問題文】の「運賃が確定すると、それを“運賃の残金”の初期値として後述の〔精算処理〕が実行される。」という流れから、事前条件は残金が確定している状態であると分かります。
   – したがって「ア：運賃の残金は確定している。」を置きます。
4. 同ユースケース 基本シナリオ2行目〔d〕
   – 基本シナリオは運賃がぴったり支払われる成功パターンです。
   – 成功条件は投入現金＝残金であるため、システムは両者が等しいかを確認します。
   – 解答群の「カ：システムは、現金が運賃の残金と等しいことを確認する。」が最も合致します。

誤りやすいポイント

• 〔a〕と〔b〕を逆にする
  ICバスカードを持たないケースと金額不足のケースの切り分けが甘いと混同しやすいです。
• 事前条件〔c〕を「サ：条件なし」と誤認
  「残金が確定している」というシステム状態を見落とすと無条件と勘違いしやすいです。
• 基本シナリオ〔d〕で「ク：システムは、ユースケースを終了する。」を選択
  成功確認の具体的処理（金額一致）を飛ばして終了させてしまう誤答が散見されます。

FAQ

解答の論理構成

1. 要求分析の対象を確認
   表3の指摘事項に「“システムの要求分析の範囲は、運行時間内の車内の運用に関する機能とすること。”」と明記されています。したがってバス車内で行う処理だけが評価対象です。
2. 非機能要件とは
   性能（処理時間）、信頼性（成功率）、使用性など“機能の質”を示す指標を指します。手順やアルゴリズム、データ構造など“何をするか”に直接関わる内容は機能要件です。
3. 解答群の評価
   • ア：IC整理券に乗車バス停を書き込む手順 → 手順そのもの＝機能要件。×
   • イ：IC整理券の読取り成功率 → “成功率”は信頼性指標で非機能要件。○
   • ウ：IC整理券を発券するまでの所要時間 → “所要時間”は性能指標で非機能要件。○
   • エ：ICバスカード、IC整理券のデータ構造 → 内部設計情報で機能要件ではない。×
   • オ：ICバスカードに一定の金額をチャージする所要時間 → チャージはバス停・営業所で実施され車内運用外。範囲外なので除外。×
   • カ：現金を返却するまでの所要時間 → 車内運賃箱での処理時間＝性能指標。○
   • キ：乗車区間から運賃を算出するアルゴリズム → アルゴリズムは機能仕様。×
4. よって非機能要件に該当するのは「イ、ウ、カ」です。

誤りやすいポイント

• 「所要時間」という語に反射的に○を付けても、表3の範囲条件を忘れて「オ」を選んでしまうミス。
• データ構造（エ）やアルゴリズム（キ）を“内部品質”と解釈して非機能と誤認するケース。
• 成功率（イ）が信頼性メトリクスであることを見落とし、機能要件と混同するケース。

FAQ