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

解答の論理構成

• 表3「コンビニ決済処理の処理内容（バッチ処理）」の“商品発送”には
  「Webサイトは、配送センタに商品の発送を指示し、同時にメールで顧客に商品の発送を通知する。」
  とあります。
  この一文が2つの並行処理（フォーク）に相当し、図2の a と b に分割されます。
  – 「配送センタに商品の発送を指示」→ a
  – 「顧客に商品の発送を通知」→ b
  よってaとbは提示のとおりとなります（順不同可）。
• 表3“購入取消”の記述は
  「Webサイトは、入金期限日が過ぎても入金されていない購入情報を取り消して、メールで顧客に通知する。」
  です。図3の c はこの“取消ルート”に入る条件なので
  「入金期限日を過ぎている」となります。
• “入金期限確認”後に“取消”しない場合は、まだ期限内であることを示します。
  したがって d は c の否定形で
  「入金期限日を過ぎていない」となります。

誤りやすいポイント

• 表現を短縮し過ぎて「発送指示」「発送通知」など主語・対象を落としてしまう。
• c を「入金なし」だけにしてしまい、“期限を過ぎた”条件を欠落させる。
• d を「入金あり」と誤記し、期限内でも未入金というケースを取り逃す。

FAQ

解答の導き方

1. まずどのクラスに入れる操作かを確認します。図4では、e はクレジット購入情報クラス、f はコンビニ購入情報クラスの操作です。どちらも購入情報クラスを継承しており、購入情報には抽象操作「商品発送()」があります。購入情報の派生クラスは、決済の結果を受けてその購入をどう扱うか、という処理を受け持つことが分かります。
2. 決済クラス側の操作を確認します。決済クラスには「決済方法選択()」と抽象操作「決済手続(注文ID)」があり、クレジット決済クラス・コンビニ決済クラスがそれぞれ「決済手続」を実装しています。設問3 のとおり、コンビニ決済の「決済手続」には決済番号取得や決済情報通知が含まれます。同じように、クレジット決済の「決済手続」には、表1 の「カード情報入力」と「カード情報送信」が含まれると考えられます。したがって、解答群のア（カード情報送信）とイ（カード情報入力）は決済クラス側の処理で、購入情報クラスの操作ではありません。
3. e（クレジット購入情報）について考えます。表1 で、クレジットカード会社の回答を受けた後の処理は二つです。

• 商品発送：「クレジットカード会社の回答が決済完了の場合、配送センタに商品の発送を指示し、…」
• 再決済依頼：「クレジットカード会社の回答がカード利用不可の場合、再度カード情報入力の画面を表示する。」 商品発送は既にクレジット購入情報クラスの操作として図4 にあるので、もう一方の「再決済依頼」が e に入ります。選択肢では カ が該当します。

1. f（コンビニ購入情報）について考えます。コンビニ購入情報には「商品発送()」と「入金期限確認()」があります。表3 に「入金期限日が過ぎても入金されていない購入情報を取り消して、メールで顧客に通知する。」とあり、図3 にも「購入を取り消す」処理があります。購入の取消しはコンビニ支払特有の振る舞いなので、f には「購入取消」が入ります。選択肢では エ が該当します。

誤りやすいポイント

• e にイ（カード情報入力）を選んでしまう。カード情報の入力は決済の手続そのもので、クレジット決済クラスの「決済手続」に含まれます。購入情報クラスが受け持つのは、決済の結果（決済完了・カード利用不可）に応じた処理です。
• e にア（カード情報送信）を選んでしまう。クレジットカード会社とのやり取りも決済手続の一部です。
• 「再決済依頼」を画面表示の処理だからクラスの操作ではないと考えてしまう。商品発送も配送センタへの指示と顧客への通知を行う処理であり、二つは同じく「回答を受けた後の購入の扱い」として対になっています。

FAQ

解答の論理構成

1. クラス図の前提
   決済クラスの操作“決済手続”は抽象操作で、サブクラスが具体的処理を実装します。問題文には「図4中の決済クラスの操作“決済手続”は抽象操作（抽象メソッド）であり、処理の実体を含まない。」と明記されています。
2. コンビニ決済クラスが担当する処理範囲
   システム側が実行する処理だけが“決済手続”の実装対象になります。顧客が店舗で行う行為や、ユーザ操作そのものはクラス内のロジックではありません。
3. 表2の処理名称を整理
   表2には次の4つの処理名称が列挙されています。
   ・「決済方法選択」
   ・「決済番号取得」
   ・「決済情報通知」
   ・「コンビニ支払」
4. 含める／含めないの判定
   • 「決済方法選択」：購入フロー共通の入口であり、スーパークラスまたは画面制御が担当。サブクラス固有ではないので除外。
   • 「決済番号取得」：U社へ購入情報を送信し決済番号を取得する処理であり、システム内ロジック。→ 含める。
   • 「決済情報通知」：取得した決済番号をメールで顧客へ通知する処理であり、システム内ロジック。→ 含める。
   • 「コンビニ支払」：顧客が店舗で行う行為であり、クラスのロジック外。→ 除外。
5. 結論
   以上から、コンビニ決済クラスの“決済手続”に含まれる処理名称は
   「決済番号取得」「決済情報通知」
   となります。

誤りやすいポイント

• 「決済方法選択」もサブクラスが処理すると誤解しやすい。実際には決済種別を選択するUIロジックであり、共通部品または親クラス側で扱います。
• 「コンビニ支払」をシステム処理と見做してしまう。店頭支払は顧客アクションであり、プログラム内で実装できる処理ではありません。
• 表1～表3の区分を見落とし、クレジット決済の処理名称を混在させるケース。

FAQ

解答の論理構成

1. 原因となる処理順の記述
   問題文には「“入金期限チェック処理”の前には必ず“入金データチェック処理”を実施する必要がある」とあり、その理由として「“入金期限チェック処理”が“入金データチェック処理”よりも先に実施された場合に発生する不具合を防止するため」と明示されています。
2. “入金データチェック処理”の役割
   表3には「Webサイトは、U社から1時間に1回送信される入金データファイルを1件ずつ読み込み、入金データの決済番号がWebサイトで保持している決済番号と一致するかどうかを確認する。」とあり、この処理で支払済み情報をシステムに反映させます。
3. “入金期限チェック処理”の動作
   同じく表3に「Webサイトは、入金期限日が過ぎても入金されていない購入情報を取り消して、メールで顧客に通知する。」とあります。ここでは“入金されていない”かどうかを判定します。
4. 不具合の発生タイミング
   支払済みなのにまだファイル読込前の場合、システム上は未入金と認識されるため “購入情報” が誤って取消対象になります。
5. 結論
   したがって不具合の内容は「入金されている購入情報が取り消されてしまう。」となります。

誤りやすいポイント

• “入金データチェック処理”をリアルタイム処理と思い込み、バッチ順序の重要性を見落とす。
• 「取消」＝キャンセルメール送信まで完了するため、その後の復旧コストを軽視しやすい。
• エラーファイル作成と購入取消を混同し、誤って「エラー扱いになる」と答えてしまう。

FAQ