応用情報技術者 2011年 秋期 午後 問08
バス運賃精算システムの要求分析に関する次の記述を読んで、設問1~3に答えよ。
H社では、ICカードを利用したバス運賃精算システム(以下、システムという)の試験導入を行うことになり、そのためのプロトタイプ開発に着手した。ICカードには、ICチップが埋め込まれている。ICチップに保存されている情報は、ICチップ専用のリーダ/ライタにICカードをかざすだけで、読取りと書込みができる。
〔ICバスカード〕
ICバスカードとは、ICカードを利用したプリペイドカードである。乗客は、バス停や営業所にあるチャージ装置を使用してあらかじめ一定の金額をチャージする。
〔IC整理券〕
IC整理券とは、ICチップを利用した整理券である。ICバスカードを持っていない乗客の乗車区間を確定するために利用する。
〔運賃の確定〕
乗客がバスに乗車する際、ICバスカードを持っていれば、ICバスカードを乗車口の整理券箱にかざす。チャージ金額が初乗り金額未満の場合は、警告するが乗車は可能である。ICバスカードを持っていなければ、整理券箱が発券するIC整理券を取り出す。この時点で、乗客の乗車バス停が確定する。
乗客がバスから降車する際、ICバスカードを利用していれば、ICバスカードを運転席横の運賃箱にかざすと運賃が確定する。IC整理券を利用していれば、IC整理券を運賃箱に投入すると運賃が確定する。運賃が確定すると、それを“運賃の残金”の初期値として後述の〔精算処理〕が実行される。
〔精算処理〕
精算とは、乗客が現金かICバスカードいずれか片方、又は両方の併用によって、運賃を支払うことである。システムは、運賃の残金があればその金額を表示する。現金での精算に釣銭を返すことはできない。運賃の残金を超えた現金を投入した場合は、投入した現金を返却する。釣銭が必要な乗客は、運賃箱の両替機能で両替してから運賃を支払う。両替金の補充は、管理部門が運行時間外に行う。
〔乗車区間未確定処理〕
整理券箱に IC バスカードをかざさず、かつ、IC 整理券を取り忘れた場合は、始発バス停からの運賃が適用され、運転手が運賃箱にその金額を運賃として設定する。
表1のアクター一覧と表2のユースケース一覧のレビューを実施し、表3のレビューでの指摘事項を反映させて、図1のユースケース図を作成し、ユースケース記述の作成と非機能要件の抽出を開始した。




表4はユースケース記述ガイドライン、表5はユースケース記述の一部である。


設問1:
図1のユースケース図を凡例に倣い完成させよ。凡例で定義した関連、汎化、特化、包含、拡張のうち、“関連”についての記述は完了しており、これ以上増えない。
模範解答
(図を参照)


解説
解答の論理構成
-
要求分析の対象範囲
表3の指摘事項に「“システムの要求分析の範囲は、運行時間内の車内の運用に関する機能とすること。”」と明記されています。よって
・表2 項番1「チャージする」
・表2 項番8「両替金を補充する」
はバス車内の動作ではないためユースケース図から除外します。 -
ユースケースの採択と名称
車内で発生するユースケースは、表2 から次の6件です。
「バスに乗車する」「運賃を確定させる」「運賃を支払う」「ICバスカードで支払う」「現金で支払う」「現金を両替する」。
これがシステム境界内に楕円として配置されます。 -
汎化(Generalization)の設定
表2 項番4「運賃を支払う」には「“抽象ユースケース”」と記載があり、項番5・6は具体ユースケースです。この関係は UML の汎化で表し、 「ICバスカードで支払う」▷「運賃を支払う」
「現金で支払う」▷「運賃を支払う」
という上向きの三角矢印になります。抽象ユースケースから子への <> や < > ではない点に注意します。 -
アクターと関連
表1より「乗客」は主アクター、「運転手」はサポートアクターです。
乗客は6つすべてのユースケースを起動し得ますが、既に“関連”線は完成している前提なので追加なし。
〔乗車区間未確定処理〕に「“運転手が運賃箱にその金額を運賃として設定する。”」とあるため、「運賃を確定させる」に運転手を接続します。
他ユースケースへ運転手が直接操作する場面は要求記述にないため、接続は1本のみです。 -
ループ要求の扱い
表3 の2点目「“項番6のユースケースは、精算が完了するまで繰り返し実行できること。”」はユースケース内部のフロー設計(シナリオ)で示せば足ります。図レベルで再帰矢印や <> を付けるのは UML 上必須ではなく、模範解答も矢印の追加を行っていません。 -
完成図
以上を反映すると、模範解答図のように
・システム境界内に6ユースケース
・汎化2本
・運転手―運賃を確定させる の関連1本
が配置された構成になります。
誤りやすいポイント
- 「チャージする」を残してしまう
⇒ 表3の範囲制限を読まずに図へ入れるケースが頻発します。 - 抽象ユースケースを <
> と誤認
⇒ 表2に“抽象”と明示されている場合は汎化が正解です。 - 運転手の接続漏れ
⇒ 〔乗車区間未確定処理〕の文を見落とし、運転手―運賃確定の線を忘れるミスが多発します。 - 「現金で支払う」の繰返しを図に過剰表現
⇒ ループ指示はシナリオで扱い、UML の自己関連線は不要です。
FAQ
Q: 「運賃を確定させる」は乗客だけで良いのでは?
A: 〔乗車区間未確定処理〕にあるように、整理券忘れ時は「運転手」が運賃箱へ金額入力を行います。この操作もユースケースの一部であるため、運転手との関連を付けます。
A: 〔乗車区間未確定処理〕にあるように、整理券忘れ時は「運転手」が運賃箱へ金額入力を行います。この操作もユースケースの一部であるため、運転手との関連を付けます。
Q: 「現金を両替する」に運転手は関与しませんか?
A: 乗客が自ら両替機能を使う仕様であり、運転手が操作する要求は提示されていません。従ってアクターは「乗客」のみとなります。
A: 乗客が自ら両替機能を使う仕様であり、運転手が操作する要求は提示されていません。従ってアクターは「乗客」のみとなります。
Q: 汎化の三角矢印の向きが覚えづらいです。
A: UML では「子 ▷ 親」が原則です。図中では「現金で支払う」「ICバスカードで支払う」が子、「運賃を支払う」が親ですので、矢印の三角は親ユースケース側に付けます。
A: UML では「子 ▷ 親」が原則です。図中では「現金で支払う」「ICバスカードで支払う」が子、「運賃を支払う」が親ですので、矢印の三角は親ユースケース側に付けます。
関連キーワード: ユースケース図、UML汎化、要求分析、プリペイドカード、非機能要件
設問2:
表5のユースケース記述のa〜dに入れる適切な文章を解答群の中からそれぞれ一つ選び、記号で答えよ。
解答群
ア:運賃の残金は確定している。
イ:運転手は、運賃の精算が完了したことを確認する。
ウ:運転手は、運賃を設定する。
エ:運転手は、チャージ金額が初乗り金額未満であることを確認して乗客に響告する。
オ:システムは、IC整理券の乗車バス停を読み取る。
カ:システムは、現金が運賃の残金と等しいことを確認する。
キ:システムは、チャージ金額が初乗り金額未満であることを確認して乗客に警告する。
ク:システムは、ユースケースを終了する。
ケ:乗客は、ICバスカードを理券箱にかざす。
コ:乗客は、整理券箱からIC整理券を取り出す。
サ:条件なし
シ:乗車バス停は確定している。
模範解答
a:キ
b:コ
c:ア
d:カ
解説
解答の論理構成
-
代替シナリオ1の 3 行目〔a〕
– 代替シナリオ1は IC バスカードを持つ乗客が「チャージ金額が初乗り金額未満」のケースです。
– 【問題文】では「チャージ金額が初乗り金額未満の場合は、警告するが乗車は可能である。」と明記されています。
– したがってシステムが金額不足を検知し、乗客に警告する動作を記述した「キ:システムは、チャージ金額が初乗り金額未満であることを確認して乗客に警告する。」が適切です。 -
代替シナリオ2 の 1 行目〔b〕
– 代替シナリオ2は IC バスカードを使わない乗客の通常手順です。
– 【問題文】に「ICバスカードを持っていなければ、整理券箱が発券するIC整理券を取り出す。」とあるので、最初の行動は IC 整理券を取ることになります。
– よって「コ:乗客は、整理券箱からIC整理券を取り出す。」が入ります。 -
ユースケース「現金で支払う」の事前条件〔c〕
– 現金精算は運賃確定後に開始されます。
– 【問題文】の「運賃が確定すると、それを“運賃の残金”の初期値として後述の〔精算処理〕が実行される。」という流れから、事前条件は残金が確定している状態であると分かります。
– したがって「ア:運賃の残金は確定している。」を置きます。 -
同ユースケース 基本シナリオ 2 行目〔d〕
– 基本シナリオは運賃がぴったり支払われる成功パターンです。
– 成功条件は投入現金=残金であるため、システムは両者が等しいかを確認します。
– 解答群の「カ:システムは、現金が運賃の残金と等しいことを確認する。」が最も合致します。
以上より
a=キ b=コ c=ア d=カ
a=キ b=コ c=ア d=カ
誤りやすいポイント
- 〔a〕と〔b〕を逆にする
IC バスカードを持たないケースと金額不足のケースの切り分けが甘いと混同しやすいです。 - 事前条件〔c〕を「サ:条件なし」と誤認
「残金が確定している」というシステム状態を見落とすと無条件と勘違いしやすいです。 - 基本シナリオ〔d〕で「ク:システムは、ユースケースを終了する。」を選択
成功確認の具体的処理(金額一致)を飛ばして終了させてしまう誤答が散見されます。
FAQ
Q: 「警告するが乗車は可能」の扱いは例外シナリオではないのですか?
A: 失敗ではなく通常成功パターンの一種なので「代替シナリオ」として整理します。
A: 失敗ではなく通常成功パターンの一種なので「代替シナリオ」として整理します。
Q: 事前条件に「残金確定」を入れると冗長になりませんか?
A: ユースケース記述ガイドラインの「事前条件」は実行可否を決める要因を示す場です。残金が未確定なら精算処理自体が呼び出されないため、必須情報として明記します。
A: ユースケース記述ガイドラインの「事前条件」は実行可否を決める要因を示す場です。残金が未確定なら精算処理自体が呼び出されないため、必須情報として明記します。
Q: 基本シナリオと代替シナリオの区別が難しいです。
A: 基本シナリオは「最も頻度が高く正常終了する手順」、代替シナリオは「正常終了する別手順」、例外シナリオは「失敗に向かう手順」と覚えると整理しやすいです。
A: 基本シナリオは「最も頻度が高く正常終了する手順」、代替シナリオは「正常終了する別手順」、例外シナリオは「失敗に向かう手順」と覚えると整理しやすいです。
関連キーワード: ユースケース図、事前条件、代替シナリオ、ICカード、精算処理
設問3:
システムの要求分析の範囲内で、非機能要件の項目として適切なものを解答群の中から全て選び、記号で答えよ。
解答群
ア:IC整理券に乗車バス停を書き込む手順
イ:IC整理券の読取り成功率
ウ:IC整理券を発券するまでの所要時間
エ:ICバスカード、IC整理券のデータ構造
オ:ICバスカードに一定の金額をチャージする所要時間
カ:現金を返却するまでの所要時間
キ:乗車区間から運賃を算出するアルゴリズム
模範解答
イ、ウ、カ
解説
解答の論理構成
-
要求分析の対象を確認
表3の指摘事項に「“システムの要求分析の範囲は、運行時間内の車内の運用に関する機能とすること。”」と明記されています。したがってバス車内で行う処理だけが評価対象です。 -
非機能要件とは
性能(処理時間)、信頼性(成功率)、使用性など“機能の質”を示す指標を指します。手順やアルゴリズム、データ構造など“何をするか”に直接関わる内容は機能要件です。 -
解答群の評価
- ア:IC整理券に乗車バス停を書き込む手順 → 手順そのもの=機能要件。×
- イ:IC整理券の読取り成功率 → “成功率”は信頼性指標で非機能要件。○
- ウ:IC整理券を発券するまでの所要時間 → “所要時間”は性能指標で非機能要件。○
- エ:ICバスカード、IC整理券のデータ構造 → 内部設計情報で機能要件ではない。×
- オ:ICバスカードに一定の金額をチャージする所要時間 → チャージはバス停・営業所で実施され車内運用外。範囲外なので除外。×
- カ:現金を返却するまでの所要時間 → 車内運賃箱での処理時間=性能指標。○
- キ:乗車区間から運賃を算出するアルゴリズム → アルゴリズムは機能仕様。×
-
よって非機能要件に該当するのは「イ、ウ、カ」です。
誤りやすいポイント
- 「所要時間」という語に反射的に○を付けても、表3の範囲条件を忘れて「オ」を選んでしまうミス。
- データ構造(エ)やアルゴリズム(キ)を“内部品質”と解釈して非機能と誤認するケース。
- 成功率(イ)が信頼性メトリクスであることを見落とし、機能要件と混同するケース。
FAQ
Q: チャージ処理は車内でも将来行うかもしれません。将来拡張を考えてオを残してはいけませんか?
A: 表3により「運行時間内の車内の運用」に限定されています。将来拡張は設計段階で検討しますが、本要求分析では除外します。
A: 表3により「運行時間内の車内の運用」に限定されています。将来拡張は設計段階で検討しますが、本要求分析では除外します。
Q: 成功率や所要時間はテストでどう扱いますか?
A: 非機能要件は受入試験の評価指標になります。例えば「IC整理券の読取り成功率99%以上」「現金返却まで3秒以内」など定量値で規定し、実機テストで測定します。
A: 非機能要件は受入試験の評価指標になります。例えば「IC整理券の読取り成功率99%以上」「現金返却まで3秒以内」など定量値で規定し、実機テストで測定します。
Q: データ構造は品質にも影響しますが非機能要件に入らないのですか?
A: データ構造は内部設計事項であり要求段階では“どう作るか”に該当します。非機能要件は“機能の質を利用者観点で示すもの”と区別しましょう。
A: データ構造は内部設計事項であり要求段階では“どう作るか”に該当します。非機能要件は“機能の質を利用者観点で示すもの”と区別しましょう。
関連キーワード: 信頼性、処理時間、非機能要件、要求分析


