応用情報技術者 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 ] は “コンビニ購入情報” に属する操作である。
   • いずれも “購入情報” 派生クラスに実装されるので、購入後に Webサイトが顧客へ行うフォローアップ処理が該当すると考える。
2. “[ f ]” の決定 ― コンビニ購入情報特有の処理
   • 表3「入金期限チェック」には、入金期限を過ぎている場合に “購入取消” を実施し、顧客へメール通知すると記載されている。
   • しかも “入金期限確認()” という操作が既に同クラスに定義済みであるため、その後段として “購入取消” を実装するのが自然である。
   • よって [ f ]＝ 「エ：購入取消」。
3. “[ e ]” の決定 ― クレジット購入情報特有の処理
   • 表1「クレジット決済処理の処理内容」では、カード利用不可時に “再決済依頼” を行うと明示されている。
   • カード情報の入力や送信は “クレジット決済” クラス側（決済手続）で実装するのが責務分担として妥当で、フォローアップである “再決済依頼” は “クレジット購入情報” クラスが保持する方が適合する。
   • 選択肢を照合すると、再決済を促す動作は「カ：再決済依頼」が一致する。
   • よって [ e ]＝ 「カ：再決済依頼」。
4. 結論
   • e：カ
   • f：エ

誤りやすいポイント

• “カード情報送信” や “カード情報入力” を [ e ] に選んでしまう
  → これらはクレジット決済手続きそのものなので “クレジット決済” クラス側の責務である。
• “[ f ]” を “決済情報通知” と誤認する
  → “決済情報通知” は表2でリアルタイムに行われる処理であり、入金期限後のバッチ処理とは無関係。
• クラス図の黒ひし形（コンポジション）に着目せず、購入情報クラスにどの業務イベントがひも付くかを見落とす。

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