戦国IT - 情報処理技術者試験の過去問対策サイト
お知らせお問い合わせ料金プラン

応用情報技術者 2010年 春期 午後08


ソフトウェアのオブジェクト指向設計に関する次の記述を読んで、設問1~3に答えよ。

 今まで、Q鉄道会社の自動券売機は、乗車券の発売しかできなかった。このたび、急行券も発売できる新型の自動券売機を開発することになった。急行券は、座席の指定は行わないが、乗車する急行列車を指定して発売する。  新型の自動券売機の主なシナリオは、次のとおりである。   〔前提〕  ・乗車券は、普通列車、急行列車にかかわらず、列車に乗るときに必要であり、乗車駅と降車駅を指定することによって、金額(運賃)が決まる。  ・急行券は、急行列車に乗るときに必要であり、列車とその乗車駅、降車駅を指定することによって、金額(料金)が決まる。   〔発売時〕  ・乗客は、まず購入する切符の種類(乗車券又は急行券)を選択し、乗車目、乗車駅、降車駅、人数及び急行券の場合は列車を自動券売機に入力する。  ・自動券売機は、入力されたデータに基づいて、金額(運賃又は料金)を算出し、表示する。  ・乗客は、表示内容でよければ、自動券売機に現金を投入し、発売ボタンを押す。表示内容でよくなければ、取消しボタンを押し、初期状態に戻す。  ・発売ボタンが押されると、自動券売機は投入されている現金を確認して収納し、発売券するとともに、釣りがあれば釣銭を返却する。    ソフトウェアの設計には、UMLのクラス図などを利用している。乗車券だけを発売する現在の自動券売機のクラス図を、図1に示す。    新型の自動券売機では、クラス“乗車券”と“急行券”についてはスーパクラスを設けることにし、図2に示すクラス図を作成した。
応用情報技術者試験(平成22年度 午後 問08 図01)
応用情報技術者試験(平成22年度 午後 問08 図02)
 図2のクラス図におけるスーパクラス“切符”とそのサブクラス“乗車券”及び“急行券”では、共通の属性をスーパクラスに、サブクラス個別の属性を各サブクラスにもたせている。ただし、属性“運賃”と“料金”については、個別に残しながら、共通の属性“金額”を追加した。また、乗車券面編集と急行券面編集は、切符に印刷するイメージを作成するための、それぞれのサブクラス個別の操作である。  図2のクラス“操作機構”の属性“切符”は、実装ではオブジェクト“乗車券”又は“急行券”を指していて、“操作機構”からそれらのオブジェクトの操作を呼び出すことを可能にする。    新型の自動券売機で急行券を発売する場合の正常処理について、図3に示すシーケンス図を作成した。範囲cにはメッセージが入る。 応用情報技術者試験(平成22年度 午後 問08 図03)

設問1継承を使用した図2のクラス図について、(1)、(2)に答えよ。

(1)abに入れる適切な属性名又は操作名を答えよ。

模範解答

a:列車 b:金額問合せ

解説

解答の論理構成

  1. 問題文は、急行券の金額を決める要素として「列車とその乗車駅、降車駅を指定することによって、金額(料金)が決まる。」と記述しています。乗車券・急行券共通の属性はスーパークラス“切符”にまとめる方針なので、急行券特有の要素「列車」はサブクラス“急行券”に残す必要があります。したがって a には「列車」が入ります。
  2. また、問題文には「共通の属性“金額”を追加した。」という設計方針が示されています。金額という共通属性を設けた以上、金額を取得する操作も共通化するのが自然です。元の図1では“乗車券”に「運賃問合せ」がありましたが、新設のスーパークラス“切符”で両券種共通に「金額問合せ」を持たせるのが合理的です。よって b には「金額問合せ」が入ります。
  3. 以上より、解答は
     a:列車
     b:金額問合せ

誤りやすいポイント

  • 「列車」をスーパークラスに入れてしまう
    急行券でしか必要とされないためサブクラス“急行券”に限定するのが正しい設計です。
  • 「運賃問合せ」「料金問合せ」をそのまま残す
    共通属性“金額”を導入した時点で名称も統一しないとポリモーフィズムが働かなくなります。
  • 面編集操作を共通化してしまう
    乗車券面と急行券面はレイアウトや記載項目が異なるため、個別操作として残す設計方針が問題文で明示されています。

FAQ

Q: 「金額問合せ」をスーパークラスに置く利点は何ですか?
A: “操作機構”はスーパークラス“切符”のインタフェースだけを意識して処理を記述でき、サブクラス追加時の修正範囲が小さくなります。
Q: 「列車」を“急行券”に追加する理由をもう一度教えてください。
A: 問題文が明示する要件「急行券は…列車を指定して発売する。」を実装に反映するためです。乗車券には列車指定が不要なので共通化できません。
Q: 「運賃」「料金」と「金額」は重複しませんか?
A: ビジネスルール上の値を保持する「運賃」「料金」と、表示や計算で使用する合計「金額」を分離し、将来の料金体系変更にも耐えられるようにしています。

関連キーワード: 継承, ポリモーフィズム, スーパークラス, サブクラス, UMLクラス図

設問1継承を使用した図2のクラス図について、(1)、(2)に答えよ。

(2)多様性(ポリモフィズム)をもつメッセージに該当する操作名を一つ答えよ。ただし、“発売”、“取消し”と“削除”は除く。

模範解答

発券

解説

解答の論理構成

  1. 図2を見ると、スーパクラス“切符”に下線付きで共通操作として
    「発券」
    が定義されています。
  2. 同じく図2のサブクラス“乗車券”と“急行券”にも、いずれも同名の操作
    「発券」
    が個別に定義されています。
  3. 問題文は「多様性(ポリモフィズム)をもつメッセージに該当する操作名」として、スーパクラスとサブクラスで共通名が呼び分けられるものを求めています。
  4. “発売”、“取消し”と“削除”は除外指示があるため除外します。
  5. 以上より、スーパクラス“切符”と各サブクラスで同名・同一タイミングで使われる操作は
    「発券」
    だけであると導けるため、解答は「発券」となります。

誤りやすいポイント

  • 「金額問合せ」を選ぶミス
    スーパクラス“切符”に同操作が存在しないためポリモフィズムの要件を満たしません。
  • 面編集系操作の混同
    「乗車券面編集」「急行券面編集」はサブクラス固有であり、共通操作ではないため該当しません。
  • “発売”を選んでしまう
    問題文が明示的に除外しています。

FAQ

Q: 「ポリモフィズム」とは具体的に何を指しますか?
A: 同一メッセージ(操作名)でスーパクラスとサブクラスのそれぞれが適切な処理を実行できる性質です。本問では「発券」がこれに該当します。
Q: スーパクラスに定義がなくてもサブクラスで同名ならポリモフィズムでは?
A: 原則として、多態呼び出しはスーパクラス参照を通じてサブクラス実装を動的決定できる必要があります。スーパクラス側に宣言がない操作はポリモフィズムの対象になりません。
Q: 除外指示の「発売」と「取消し」はなぜ対象外ですか?
A: 問題文が明示的に「“発売”、“取消し”と“削除”は除く」と指定しているため、たとえ条件を満たしていても解答としては選択できません。

関連キーワード: UML, クラス図, シーケンス図, ポリモーフィズム, 継承

設問2図3のシーケンス図について、(1)、(2)に答えよ。メッセージ名については、図2のクラス図中にある操作から選べ。

(1)cに入れるメッセージについて、送信側と受信側のクラス名、及び適切なメッセージ名を答えよ。

模範解答

送信側クラス名:乗客 受信側クラス名:現金機構 メッセージ名:入金

解説

解答の論理構成

  1. 【問題文】では発売時の流れとして
    「乗客は、表示内容でよければ、自動券売機に現金を投入し、発売ボタンを押す。」
    と記述されています。
    ここで “現金を投入” する相手は硬貨・紙幣を扱うモジュール、すなわちクラス“現金機構”です。
  2. 図2のクラス“現金機構”の操作一覧には「入金」が定義されています。
    またクラス間の関連で「乗客 0..* ── 1 現金機構」が示されており、乗客が直接“現金機構”にメッセージを送れる構造になっています。
  3. 図3のシーケンス図を見ると、altフレームより前に c が置かれ、その直後で “:操作機構” が “:急行券” を発売処理へ進めるか、取消しへ進むかを分岐しています。
    金銭を投入しない限り発売フローには入れないため、この位置に入るメッセージは現金投入を表す必要があります。
  4. 以上より c
    送信側:クラス“乗客”
    受信側:クラス“現金機構”
    メッセージ名:操作「入金」
    が論理的に整合します。

誤りやすいポイント

  • “入金” を “操作機構” に送ると誤解する
    乗客が触れる物理インタフェースは操作部ですが、金銭処理は“現金機構”が担当する設計です。
  • メッセージ名を「投入」などに変えてしまう
    解答は図2に定義済みの操作名「入金」をそのまま使う必要があります。
  • c を “操作機構 → 現金機構” としてしまう
    図3のライフライン順序は左端が “:乗客” であり、c はそのライフラインから発信されています。

FAQ

Q: なぜ“操作機構”を経由しないのですか?
A: クラス図の関連で「乗客 0..* ── 1 現金機構」が示されているため、乗客が現金機構へ直接メッセージを送る設計になっています。
Q: “入金”後に金額確認は不要ですか?
A: 金額不足の判定は “操作機構” が “現金機構” に対して行う「現在額問合せ」で実施されますが、図3では省略されているだけです。
Q: Altフレームの分岐条件はどこで判定されますか?
A: “操作機構”が投入金額と急行券の「金額」を比較し、充分なら “発売” メッセージ、不足なら “取消し” メッセージを“急行券”に送ります。

関連キーワード: クラス図, シーケンス図, 汎化, メッセージパッシング, オブジェクトライフライン

設問2図3のシーケンス図について、(1)、(2)に答えよ。メッセージ名については、図2のクラス図中にある操作から選べ。

(2)deに入れる適切なメッセージ名を答えよ。

模範解答

d:現在額問合せ e:急行券面編集

解説

解答の論理構成

  1. “発売ボタンが押されると、自動券売機は投入されている現金を確認して収納し、発売券するとともに、釣りがあれば釣銭を返却する。”
    ─ この処理を実現するには、操作機構 が “投入されている現金” を把握しなければなりません。
  2. 現金機構 には “現在額問合せ” という操作が用意されており、まさに “現在投入されている現金額を問い合わせる” ためのメソッドです。したがって
    【結論】d = “現在額問合せ”
  3. 次に印刷処理に必要な券面データの生成について、問題文には
    “乗車券面編集と急行券面編集は、切符に印刷するイメージを作成するための、それぞれのサブクラス個別の操作である。”
    とあります。急行券 を印刷する前に “急行券面編集” を呼んで券面イメージを作成しておく必要があるため
    【結論】e = “急行券面編集”

誤りやすいポイント

  • “金額問合せ” と “現在額問合せ” を混同しやすい
    (前者は券種の価格を取得、後者は投入金額を取得)。
  • 印刷直前の “急行券面編集” 呼び出しを忘れ、印刷機構 に直接 “発券” してしまう。
  • alt フレームの構造を読み違え、取消し 側に現金処理や印刷処理を誤って書いてしまう。

FAQ

Q: “現在額問合せ” と “収納返却” の呼び出し順序は入れ替えられますか?
A: いいえ。まず残高を確認(“現在額問合せ”)し、不足がなければ発券後に “収納返却” で現金を確定収納・釣銭返却する流れが正しいです。
Q: “急行券面編集” を 操作機構 が直接呼ばず、印刷機構 から呼び出す設計はダメですか?
A: 印刷機構 はあくまで「印刷だけ」を責務とするため、券面生成ロジックを持たせると責務分割が崩れます。図2の設計意図でも “急行券面編集” は 急行券 クラスの操作として定義されています。
Q: “取消し” 分岐では現金をどう扱っていますか?
A: “取消し” では券面も印刷されず現金も収納しません。券が存在すれば “削除” を行い、投入金があれば 現金機構 が返却動作を行います。

関連キーワード: シーケンス図, クラス図, 多態性, 責務分割, メッセージ駆動

設問3

乗客が乗車券と急行券など、複数の切符を同時に購入する場合を考慮し、まとめて発売する機能を追加したい。乗客が、切符要求の入力後、更に次の切符要求の入力を行い、最後に発売ボタンを押すことによって、それまでに入力した切符をまとめて発売できるようにする。 これを実現するために、クラス図としては図2のクラスの配置は変えず、いずれかのクラスの属性一つと、そのクラスにかかわる関係の多重度を変えて対応する。 変更する必要がある属性の所属するクラス名と属性名を答えよ。また、その属性の変更内容が分かる適切な変更後の属性名を、10字以内で答えよ。

模範解答

クラス名:操作機構 属性名:切符 変更後の属性名:切符の集合

解説

解答の論理構成

  1. 現状把握
    • 問題文は「図2のクラス“操作機構”の属性“切符”は、実装ではオブジェクト“乗車券”又は“急行券”を指していて、“操作機構”からそれらのオブジェクトの操作を呼び出すことを可能にする。」と述べています。
    • つまり現行モデルでは“操作機構”が扱える切符は1枚だけです(多重度 0..1)。
  2. 追加要件の確認
    • 新機能では「乗客が、切符要求の入力後、更に次の切符要求の入力を行い、最後に発売ボタンを押すことによって、それまでに入力した切符をまとめて発売できるようにする。」とあります。
    • まとめて発売するには、“操作機構”が複数の切符オブジェクトを保持し、最後に一括処理する必要があります。
  3. 影響範囲の特定
    • 問題文は「クラス図としては図2のクラスの配置は変えず、いずれかのクラスの属性一つと、そのクラスにかかわる関係の多重度を変えて対応」と指定しています。
    • 複数保持の対象は“切符”そのものなので、属性を持つクラスは“操作機構”で決まりです。
  4. 多重度と属性の変更
    • 多重度:現在 0..1 → 要件から 0..* に変更。
    • 属性:単一参照をコレクション参照に改める。集合であることが分かるように名前を更新します。
  5. 解答導出
    • クラス名:操作機構
    • 属性名:切符
    • 変更後の属性名:切符の集合(10字以内)
以上より模範解答「クラス名:操作機構/属性名:切符/変更後の属性名:切符の集合」となります。

誤りやすいポイント

  • 「乗車券」「急行券」側の多重度を増やすと誤認する
    → 集約元は“操作機構”であり、個々の切符クラスではありません。
  • 属性名を「切符一覧」等とし、要件の10字以内を超えてしまう
    → 解答欄の制約を見落とさないよう注意します。
  • 多重度変更を忘れ、属性名だけを書き換える
    → 問題指示は「属性一つと…多重度を変えて」と明記しています。

FAQ

Q: なぜ“切符”ではなく“乗車券”や“急行券”側の関連を変更してはいけないのですか?
A: 両方の切符を同時に扱う中心は“操作機構”であり、ここが複数の切符を保持すれば要件は満たせます。個別クラス側を変えると、サブクラスごとに管理ロジックが分散し冗長になります。
Q: 属性を配列型やリスト型にすれば名前変更は不要では?
A: UML クラス図では集合を示すなら、属性名でも集合であることを示すのが慣例です。視覚的・文書的にも分かりやすくするために名称変更が推奨されます。
Q: 「切符の集合」以外で許容される例は?
A: 10字以内で集合が分かれば「切符群」「切符一覧」なども可です。ただし正式解答例は「切符の集合」とされています。

関連キーワード: UML, クラス図, 多重度, コレクション, 汎化
戦国ITクイズ機能

\ せっかくなら /

応用情報技術者
クイズ形式で学習しませんか?

クイズ画面へ遷移する

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてプライバシーポリシー利用規約特商法表記開発者について