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

解答の論理構成

1. 問題文の該当箇所

   在庫調整処理で使用するI/Fファイルの形式として、“CSV形式”と“XML形式”を比較した。検討の結果、aの追加によってデータ項目を追加できるという、“XML形式”の拡張性に注目して、ファイル形式は“XML形式”を採用することにした。

2. ここで XML の拡張性を生む仕組みは、階層構造を持つ「要素」を任意に追加できる点です。CSV は列追加が必須ですが、XML では新しいデータ項目を「要素」としてタグ内に追加すれば既存システムとの互換を保てます。
3. したがって a には「要素」が入ることで文意が完全に成立します。

誤りやすいポイント

• 「タグ」と解答してしまう
  XML では開始タグ・終了タグで要素を表現しますが、追加できるのは構造体そのもの＝要素です。
• CSV でも列追加で拡張可能と早合点する
  CSV の列追加はフォーマット変更となりパース側の改修が必要になるため、“追加しやすい”という要件を満たしません。
• 「属性」と混同する
  XML では属性も拡張に使えますが、問題文は“データ項目を追加”と述べており、内容を包む単位として要素が適切です。

FAQ

解答の論理構成

• 【問題文】では、「通信の異常などで、C社からのI/Fファイル送信のエラーを検出した場合、又はD社側でI/Fファイル受信タイムアウトを検出した場合は、その時点でC社、D社とも在庫調整処理前のDBの状態で販売を再開する。」と規定しています。
• ところがシーケンス図（タイムアウト処理追加前）には、
  「C社 在庫調整処理 → D社 在庫調整処理：C社ファイル送信」
  「C社 在庫調整処理 → D社 在庫調整処理：C社ファイル受信回答」
  の後段で “販売再開” が描かれており、C社ファイル送信がエラーになるとこのメッセージ列が実行されません。
• 下線①の指摘は、「“C社ファイル送信がエラーとなった場合にD社Webサイトで不具合が発生する”」というものです。
• つまり、C社ファイル送信エラー時に“販売再開”メッセージが送られないため、D社Webサイトは販売停止状態を解除できず、対象公演だけがいつまでも販売停止になります。
• よって不具合の原因は「販売再開処理が実行されず、対象公演が販売停止のまま残ること」と説明できます。

誤りやすいポイント

• “タイムアウト発生”を図に追加した理由と、下線①の不具合内容を混同してしまい、原因と結果を逆に記述する。
• 「C社Webサイト」か「D社Webサイト」かを取り違え、販売停止が継続するサイトを誤答する。
• 不具合の原因を“在庫が不一致になる”と広く捉え過ぎ、販売再開メッセージ欠落に絞り込まない。

FAQ

解答の論理構成

1. 【問題文】には
   “通信の異常などで、C社からのI/Fファイル送信のエラーを検出した場合、又はD社側でI/Fファイル受信タイムアウトを検出した場合は、その時点でC社、D社とも在庫調整処理前のDBの状態で販売を再開する。”
   とあります。
   したがってタイマが “タイムアウト発生” を通知した直後、まだ C社ファイル受信回答 が返って来ていないならば、在庫調整処理は未完了なので D 社は即座に “販売再開” を行う必要があります。
2. 一方、すでに C社ファイル受信回答 が返って来ている場合は、
   ① C 社側での在庫移動結果が D 社へ正常に返却済み
   ② D 社はその結果を用いて DB 反映を完了済み
   の状態です。ここでタイムアウトが発生しても、追加で行う処理はありません。従って “（何も行わない）” 分岐になります。
3. 以上より分岐条件は次のように整理できます。
   • b：C社ファイル受信回答未実施（未受信）
   • c：C社ファイル受信回答済み（受信済み）

誤りやすいポイント

• “タイムアウト発生” の対象が C社ファイル送信 ではなく C社ファイル受信回答 であると混同しやすい点。
• “販売再開” を C 社・D 社どちらが送るか取り違えやすい。タイムアウト後の主導は D 社側です。
• “未実施／済み” をメッセージの名前ではなく状態変数で表記して減点されるケース。

FAQ

解答の論理構成

1. 問題文では、異常系テスト時に「表2の項番3に該当するテストデータでは一部のチケット在庫が C 社 Webサイト、D 社 Webサイトの両方で d 、表2の項番4に該当するテストデータでは一部のチケット在庫が C 社 Webサイト、D 社 Webサイトの両方で e となる」と記載されています。
2. 表2の項番3は「C社の販売可能なチケット在庫が50席未満、D社の販売可能なチケット在庫が51席以上」という“D社→C社”への在庫移動ケースです。移動完了前に通信エラーで処理が宙に浮くと、
   ・C社側は在庫を受け取り更新済み
   ・D社側は在庫をまだ保持
   という“二重在庫”が生じ、両サイトで当該座席が購入できてしまいます。したがって d は「販売可能」と判断できます。
3. 表2の項番4は「C社の販売可能なチケット在庫が51席以上、D社の販売可能なチケット在庫が50席未満」という“C社→D社”への在庫移動ケースです。同様にエラーが起きると、
   ・C社側は在庫を移動済みで手元に残らない
   ・D社側はまだ在庫を受け取っていない
   ため、両サイトとも当該座席を売れる状態にありません。よって e は「販売不可」となります。

誤りやすいポイント

• 「在庫が重複して見える＝販売済み」ではなく“販売可能”である点を取り違えやすい。
• 表2の項番3と項番4の方向（D社→C社 と C社→D社）を逆に覚えてしまうと答えが入れ替わる。
• 障害時は「両社とも在庫調整処理前のDBの状態で販売を再開する」という仕様を、そのまま実装順序が正しい前提で解釈し、シーケンス図の誤りによる不整合を想像し損ねやすい。

FAQ

解答の論理構成

1. 原設計の手順
   【問題文】には、C社側の通常処理順として
   「処理結果のチケット在庫データをDBに反映し、C社Webサイトでその公演の販売再開を行った後、…I/Fファイルに編集してD社へ送信する。」
   とあります。すなわち
   ① 処理結果反映 → ② 販売再開 → ③ C社ファイル送信 → ④ C社ファイル受信回答
   という順序でした。
2. 不具合の発生メカニズム
   同じく【問題文】には
   「通信の異常などで、C社からのI/Fファイル送信のエラーを検出した場合…C社、D社とも在庫調整処理前のDBの状態で販売を再開する。」
   と規定されています。
   ところが原設計では、C社はDBを更新して販売を再開した“後”にファイル送信を行います。もしこの送信が失敗すると
   ・C社…新しい在庫状態を公開
   ・D社…タイムアウトを検知し旧状態へロールバック
   という不整合が生じ、下線①の「C社ファイル送信がエラーとなった場合にD社Webサイトで不具合が発生する」という問題が現実化します。
3. 必要な修正方針
   不整合を避けるには、
   A. C社が確実にファイル送信成功を確認（＝受信回答を受領）するまではDBを更新しない。
   B. 双方の販売再開は、DBが確定した後に実施する。
   という二相コミットに類似した流れが望まれます。
4. 修正後の最適順序
   以上より、C社側のメッセージ順は
   ウ：C社ファイル送信 → エ：C社ファイル受信回答 → ア：処理結果反映 → イ：販売再開
   が妥当となります。これなら送信エラー時点でDBは未変更のままなので、D社がタイムアウトで処理を中止しても両社が同じ（調整前）状態を保てます。

誤りやすいポイント

• 「ファイル送信が終わってからDB更新では処理が二度手間」と考え、原設計を正しいと思い込む。ネットワーク障害時の整合性を見落としがちです。
• 受信回答（ACK）を軽視して、送信完了＝成功と誤認する。実際にはACKが届かなければ転送の成否は確定しません。
• 販売再開をDB反映より先に置くと、在庫数と画面表示が乖離して不正な重複販売を招きます。

FAQ