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

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


通信販売用 Webサイトの設計に関する次の記述を読んで、設問1〜3に答えよ。

   P社では、新たな事業展開として、インターネットを用いた通信販売を開始することとした。通信販売のための販売用 Webサイトは、新規に開発する。販売用 Webサイト及び販売用 Webサイトで用いるショッピングカートに関する説明を次に示す。
〔販売用Webサイト〕  ・インターネットに公開し、一般の顧客が買物に利用する。  ・顧客は、P社から付与される顧客IDでログインしてから買物をする。  ・顧客は、商品カタログを画面にて表示し、ショッピングカートに商品を追加したり、ショッピングカートから商品を削除したりして、購入する商品を選ぶ。  ・顧客は、商品を選び終わったら、ショッピングカート内の商品の購入手続きを行う。  ・商品には、通常商品と予約販売商品の2種類がある。  ・通常商品を購入した場合の配送手続では、即座に商品の配送処理が行われる。  ・予約販売商品を購入した場合の配送手続では、配送のための情報がデータベースに保管され、実際の配送処理は商品の発売開始日以降に行われる。  ・商品の配送処理は、既存の配送処理システムと連携することによって行う。販売用   Webサイトは、購入された商品の情報を配送処理システムに通知する。配送処理システムは、通知された商品の情報をとりまとめて、配送業者に集配依頼の情報を送る。   〔ショッピングカート〕  ・顧客がショッピングカートに商品を追加すると、追加された商品の在庫数を、追加された数量分だけ減らす。ただし、商品の在庫数が不足している場合は、ショッピングカートに商品を追加せず、在庫数を減らさない。  ・顧客がショッピングカートから商品を削除すると、削除された商品の在庫数を、削除された数量分だけ増やす。    販売用 Webサイトの開発を行うに当たり、データベース及びショッピングカートの設計を次のように行った。   〔データベースの設計〕  販売用 Webサイトで使用するデータベースには、商品在庫情報テーブル、ショッピングカート情報テーブル及び販売明細テーブルを用意する。  商品在庫情報テーブルには、商品名や単価などの商品に関する情報と、その在庫数を格納する。商品は、商品IDで一意に識別する。  ショッピングカート情報テーブルには、ショッピングカートに入っている商品の商品IDと数量を格納する。ショッピングカートは、顧客IDで一意に識別する。  販売明細テーブルには、顧客が購入した商品の情報を格納する。販売明細は、注文IDと商品IDの複合キーで一意に識別する。注文IDは、購入手続きを行ったときに発行されるIDである。  なお、販売用 Webサイトに用いるデータベースでは、トランザクション内でテーブルに対する更新アクセスが発生するとテーブル単位のロックがかかり、トランザクション終了時に、すべてのロックが解除される仕組みになっている。   〔ショッピングカートの設計〕  ショッピングカートに関連する部分のクラス図を図1に示す。また、顧客がショッピングカートに商品を追加してから、商品を購入するまでの流れを表したアクティビティ図を図2に示す。  商品クラスと商品在庫管理クラスは、aクラスとして定義する。それをbするcクラスとして、通常商品用と予約販売商品用のクラスを定義する。  このような設計にすることによって、ショッピングカートクラスでは、商品の種類を意識することなく、すべての商品情報をdクラスで取り扱うことができる。  例えば、予約販売商品をショッピングカートに追加する場合は、予約販売商品の商品IDと数量を指定して、ショッピングカートクラスの商品の追加メソッドを実行する。  商品追加メソッドでは、追加される商品が予約販売商品であることを判定し、予約販売商品在庫管理クラスのインスタンスを作成して在庫取得メソッドを呼び出す。在庫取得メソッドの中では、在庫数についてデータベースの参照を行った後、eクラスのインスタンスを作成し、dクラスの型で返す。ショッピングカートは、返されたオブジェクトを属性に追加登録する。  商品の購入手続きを行うとき、通常商品と予約販売商品では、処理の大まかな流れは同一だが、配送手続きに関する処理が異なる。  ショッピングカートクラスの購入手続きメソッドでは、最初に注文IDを発行する。次に、発行された注文IDを用いて、ショッピングカート内の商品の購入手続きメソッドを個々に呼び出す。商品の購入手続きメソッドの内部では、販売明細更新メソッドと、配送手続きメソッドが順に呼び出される。このとき、販売明細更新メソッドはdクラスに実装されたメソッドが呼び出される。配送手続きメソッドは、dクラスでは抽象f関数(a関数)として定義されているので、b先のクラスで実装されたメソッドが呼び出される。 応用情報技術者試験(平成21年度 午後 問08 図01)
応用情報技術者試験(平成21年度 午後 問08 図02)

設問1

本文中のafに入れる適切な字句を答えよ。ただし、ac及びfについては解答群の中から選び、記号で答えよ。  deについては、図1中にあるクラス名から選び答えよ。
解答群  ア:依存  イ:インタフェース  ウ:仮想  エ:具象  オ:継承  カ:再帰  キ:集約  ク:スタイルシート  ケ:抽象

模範解答

a:ケ b:オ c:エ d:商品 e:予約販売商品 f:ウ

解説

解答の論理構成

  1. 抽象クラスを用意する理由
    本文に「商品クラスと商品在庫管理クラスは、aクラスとして定義する」とあり、後続文で「通常商品用と予約販売商品用のクラスを定義する」と記載されています。複数の派生クラスを統一的に扱うためには抽象クラスが適切です。解答群で “抽象” は「ケ」であるため、a=ケ(抽象)となります。
  2. 派生関係の表現
    「それをbするcクラスとして、通常商品用と予約販売商品用のクラスを定義する」とあるので、基底クラスから派生させる操作は“継承”です。“継承”は解答群オ、そして生成される側は実体を持つ“具象”クラスで、解答群エです。したがって b=オ(継承)、c=エ(具象)となります。
  3. 商品クラスの共通取り扱い
    「ショッピングカートクラスでは、商品の種類を意識することなく、すべての商品情報をdクラスで取り扱うことができる」とあり、共通の型は“商品”クラスしかありません。よって d=商品 です。
  4. 在庫取得メソッド内で生成する具体クラス
    「在庫取得メソッドの中では、在庫数についてデータベースの参照を行った後、eクラスのインスタンスを作成し、dクラスの型で返す」とあるので、現在処理中の具体商品は予約販売商品です。図1にも対応する “予約販売商品” クラスが存在するため e=予約販売商品 となります。
  5. 抽象メソッドの性質
    「配送手続きメソッドは、dクラスでは抽象f関数(a関数)として定義されている」とあるので、抽象クラス内でオーバーライドを前提に宣言する“仮想関数”です。解答群ウが“仮想”なので f=ウ です。
まとめ
a:ケ(抽象)
b:オ(継承)
c:エ(具象)
d:商品
e:予約販売商品
f:ウ(仮想)

誤りやすいポイント

  • “インタフェース”と“抽象クラス”の混同
    抽象クラスには実装を持つメンバも置けますが、純粋なインタフェースは実装を持てません。本文では「在庫取得メソッドの中でインスタンスを生成し…型で返す」とあるため実装を含む抽象クラスと判断します。
  • 多態性のキーワード
    “仮想関数”を “抽象関数” と誤答するケースが多いです。本文で「抽象f関数(a関数)」と二重にヒントが示されている点を見逃さないようにしましょう。
  • “具象”と“集約”の取り違え
    具象は「実体を持つクラス」、集約は「所有関係を示す関連」。語感が似ていますが意味は別物です。

FAQ

Q: 抽象クラスを使うのはインタフェースでは駄目なのですか?
A: 本文には「在庫取得メソッドの中でインスタンスを作成する」処理があり、基底クラス側にも一部ロジックを実装する想定です。完全なメソッド定義を持たないインタフェースだけでは実装共有ができないため抽象クラスが適しています。
Q: “仮想関数”と“オーバーライド”の関係は?
A: 基底クラスで仮想関数として宣言すると、派生クラスで同名シグネチャのメソッドを書いたときに自動的にオーバーライドされ、多態性が働きます。本問では“配送手続きメソッド”がその典型例です。
Q: 在庫取得メソッドが“商品”型を返すメリットは?
A: ショッピングカート側は商品の具体種類を意識せず “商品” 型だけで受け取れるため、後から商品種類が増えてもコード変更が局所化できます。これはオブジェクト指向のLSP(リスコフの置換原則)の好例です。

関連キーワード: 抽象クラス, 継承, 仮想関数, 多態性, 在庫管理

設問2

図2中のghに入れる適切な字句を答えよ。

模範解答

g:ショッピングカート内の商品の購入手続きを行う h:ショッピングカートから商品を削除する

解説

解答の論理構成

  1. 図2の【商品在庫管理】レーンの最初のアクション[g]は、顧客が買物を終えるタイミングで呼び出される処理です。問題文には「顧客は、商品を選び終わったら、ショッピングカート内の商品の購入手続きを行う。」とあります。この文言がそのままアクション名になれば、後続でショッピングカートに対して購入処理を依頼し、明細作成や配送処理へつなげる流れが自然です。したがって[g]は「ショッピングカート内の商品の購入手続きを行う」と判断できます。
  2. 続いて[h]は、同じ【商品在庫管理】レーンで在庫数を増やす処理の直前に置かれています。問題文には「顧客がショッピングカートから商品を削除すると、削除された商品の在庫数を、削除された数量分だけ増やす。」とあります。すなわち在庫数を戻す操作は“ショッピングカートからの削除”に対応します。よって[h]は「ショッピングカートから商品を削除する」と確定します。
  3. 以上より
     g:ショッピングカート内の商品の購入手続きを行う
     h:ショッピングカートから商品を削除する

誤りやすいポイント

  • 【購入手続き】と【注文確定】を混同する
    「注文IDを発行」などの処理に目を取られ、[g]を「注文IDを発行する」としてしまうケースがあります。注文ID発行はショッピングカートクラス内部の細かな処理であり、図2のアクションレベルでは触れていません。
  • 在庫を減らす/戻すタイミングの取り違え
    顧客操作と在庫操作を正しくペアにできず、[h]を「在庫を増やす」にしてしまうミスが散見されます。あくまでアクション名には“在庫を増やす”ではなく、そのトリガとなる顧客操作を書く必要があります。
  • 「商品削除」と「数量変更」の混同
    数量変更は一度削除して追加し直す実装もあり得るため、[h]を「ショッピングカート内の数量を変更する」と曖昧に書くと減点対象になります。問題文で明示されている「削除」に合わせることが必須です。

FAQ

Q: 購入手続きはどのクラスに実装されていますか?
A: 問題文にあるとおり「商品の購入手続きを行うとき、…ショッピングカートクラスの購入手続きメソッドでは、最初に注文IDを発行する。」と書かれており、ショッピングカートクラスがエントリポイントになっています。
Q: 在庫数のロックはレコード単位ではないのですか?
A: 「トランザクション内でテーブルに対する更新アクセスが発生するとテーブル単位のロックがかかり…」と明記されています。したがって商品単位のロックではなくテーブル全体が排他されます。
Q: 予約販売商品でも在庫は減るのでしょうか?
A: はい。予約販売商品でもショッピングカートに追加した時点で在庫を確保するため、「追加された商品の在庫数を、追加された数量分だけ減らす」というルールは共通です。

関連キーワード: アクティビティ図, 在庫管理, トランザクション, オブジェクト指向

設問3

設計レビューを実施したところ、図2のアクティビティ図のとおりにプログラムを書くと、複数人が同時にアクセスしたときに、処理のタイミングによっては問題が発生する可能性があるという指摘が出た。どのような場合に、どのような問題が発生する可能性があるか。45字以内で答えよ。

模範解答

商品の追加と削除が同時に行われると、デッドロックが発生することがある。

解説

解答の論理構成

  1. データベースのロック仕様
    原文には「トランザクション内でテーブルに対する更新アクセスが発生するとテーブル単位のロックがかかり、トランザクション終了時に、すべてのロックが解除される仕組み」とある。この仕様により、同一テーブルを更新する二つのトランザクションは互いのロックが解放されるまで待機する。
  2. “追加”と“削除”でロック取得順が逆
    ・商品の追加では、最初に「商品在庫情報テーブル」の在庫数を減らし、その後「ショッピングカート情報テーブル」に行を追加する流れになる。
    ・商品の削除では、先に「ショッピングカート情報テーブル」から行を削除し、続いて「商品在庫情報テーブル」の在庫数を戻す流れになる。
    更新対象テーブルは同じだが取得順序が逆である点が重要である。
  3. 並行実行時に循環待ちが成立
    例として、利用者Aが“追加”、利用者Bが“削除”をほぼ同時に開始した場合を考える。
    ① 利用者Aは「商品在庫情報テーブル」をロックする。
    ② 利用者Bは「ショッピングカート情報テーブル」をロックする。
    ③ 以降、Aは「ショッピングカート情報テーブル」のロック解放を待ち、Bは「商品在庫情報テーブル」のロック解放を待つ。
    双方とも相手のロックが必要なため待ち状態が循環し、抜け出せない ― すなわちデッドロックが発生する。
  4. 設問の要求
    発生場面と発生する現象を簡潔に述べると、模範解答の「商品の追加と削除が同時に行われると、デッドロックが発生することがある。」となる。

誤りやすいポイント

  • “排他制御が効くのだから安全”と誤解し、ロック順序の不一致によるデッドロックを見落とす。
  • 問題を“ロストアップデート”や“ダーティリード”と誤認する。今回の論点は整合性よりも停止状態の発生である。
  • 行ロックとテーブルロックを混同し、テーブル単位であることを忘れて評価を誤る。

FAQ

Q: 行ロックならデッドロックは起きませんか?
A: 行ロックでも取得順序が異なればデッドロックは起こり得ます。ただし本問題はテーブルロックなので可能性がより高いです。
Q: 回避策として最も単純なのは?
A: “在庫→カート”などロック取得順序を操作全体で統一する方法が手軽で効果的です。
Q: タイムアウト設定で十分でしょうか?
A: タイムアウトは障害の顕在化を防ぎますが、再試行処理を実装しなければ利用者には依然として失敗が見えるため、根本対策とは言えません。

関連キーワード: デッドロック, トランザクション, 排他制御, テーブルロック, 同期制御
戦国ITクイズ機能

\ せっかくなら /

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

クイズ画面へ遷移する

すぐに利用可能!

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

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