解説

本問は主にUMLを題材にしてソフトウェア設計能力を問う問題です。

設問1に登場する「アクティビティ図」は一連の手順、手続き(処理）の流れを表現する図で、従来使用されていた「フローチャート」に近い用途で使われます。システムの動的な動きを表現するため、UMLの中では「振る舞い図」に分類されています（振る舞い図には他に「シーケンス図」や「ステートマシン図」等が含まれます）。

〔a，bについて〕
図1のアクティビティ図はクレジット決済処理とコンビニ決済処理について記述しているので、表1の内容と比較しながら読み解きます。[a]と[b]はカード会社での決済が完了した後、商品発送前に実施する処理であり、しかも2つの処理を同時並列で処理していることに着目します。

表1では「カード情報送信」で決済完了を確認した後、「商品発送」の処理手順に移っています。「商品発送」の処理内容を読むと、「Webサイトは，クレジットカード会社の回答が決済完了の場合，配送センタに商品の発送を指示し，同時にWebサイトの画面で顧客に商品の発送を通知する」と書かれているので、[a]と[b]には「配送センタへ商品の発送を指示する」及び「顧客に商品の発送を通知する」が入ります（順不同）。

∴a＝配送センタへ商品の発送を指示する
　b＝顧客に商品の発送を通知する

〔c，dについて〕
図3のアクティビティ図は入金期限チェック処理について記述しているので、表3の内容と比較しながら読み解きます。[c]と[d]は処理の分岐条件であり、直前に「購入情報のチェックを行う」処理があることから、購入情報のチェック結果に基いた処理分岐が行われていると考えられます。

そこで、表3の処理グループ「入金期限チェック」に着目します。処理名称「入金期限確認」で「商品発送前かつ取消前の購入情報を1件ずつ読み込み，入金期限のチェックを行う」と書いてあることから、図3に表記されている「購入情報のチェック」は入金期限チェックであることがわかります。その後に行う、処理名称「購入取消」には「入金期限日が過ぎても入金されていない購入情報を取り消して，メールで顧客に通知する」という記述があるので、[c]と[d]は発送前の購入情報ごとに入金期限を過ぎていないか否かを判断する分岐であると判断できます。

[c]は購入取消処理に進み、[d]は購入を取り消さずに次に処理が移っていることから、[c]には「入金期限を過ぎている」、[d]には「入金期限を過ぎていない」旨の分岐条件が入ります。

∴c＝入金期限を過ぎている
　d＝入金期限を過ぎていない

解説

設問2に登場する「クラス図」はオブジェクト（クラス）の構造と関連性を表現する図です。システムの静的な構造を表現するため、UMLの中では「構造図」に分類されています（構造図には他に「コンポーネント図」や「パッケージ図」等が含まれます）。

[e]はクラス「クレジット購入情報」のメソッド名、[f]はクラス「コンビニ購入情報」のメソッド名です。両クラスは共にクラス「購入情報」の子クラス（派生クラス）になっている事から、[e]と[f]は購入手続きに関わる処理のうち、クレジット購入時とコンビニ購入時それぞれに固有の処理であることがわかります。

〔eについて〕
クレジット決済処理をまとめた表1を見ると、クレジットカードが決済完了した場合は「商品発送」を行うことになっており、この処理はクラス「クレジット購入情報」にあります。一方これと対になる処理として、カード利用不可であった場合に「再決済依頼」をする事になっていますが、図4のクラス図には記載されていません。したがって[e]には「再決済依頼」が入ります。

∴e＝カ：再決済依頼

〔fについて〕
コンビニ決済処理は表2と表3にまとめられていますが、表2は決済処理に関する内容しかないため、表3に着目します。表3に記載されている処理の中から図4に記述のないものを探すと、「購入取消」がないことがわかります。したがって[f]には「購入取消」が入ります。

∴f＝エ：購入取消

解説

抽象操作（抽象メソッド）は、処理の内容が入っておらず、外部から呼び出すときのインタフェース、すなわち戻り値の型、メソッド名、引数の型、引数の数のみが定義されているメソッドです。抽象メソッドを1つ以上含むクラスは抽象クラスといいます。処理内容が定義されていないため、抽象クラスをインスタンス化することはできず、必ずサブクラスに継承してオーバーライドし、処理内容を確定する必要があります。

オーバーライド（Override）

上位クラスで定義されたメソッド(メンバー関数)を、下位クラス側の役割に応じて再定義し動作を変更すること

図4のクラス図を見ると、クラス「決済」は「クレジット決済」と「コンビニ決済」の2クラスに継承され、それぞれでメソッド「決済手続」をオーバーライドしています。クラス「コンビニ決済」でオーバーライドしたメソッド「決済手続」には、コンビニ決済固有の処理（すなわち、クレジット決済とは異なる処理）が入ります。なぜなら、仮に決済手続に関わる「クレジット決済」と「コンビニ決済」で共通の処理があるならば、「決済方法選択」のようにスーパークラスである「決済」側で処理を定義するべきだからです。

コンビニの決済処理の処理内容が記載された表2には、「決済方法選択」「決済番号取得」「決済情報通知」「コンビニ支払」という4つの処理名称がありますが、このうち「決済方法選択」はクレジット決済と共通の処理であり、スーパークラスで定義済です。また「コンビニ支払」は、図1のアクティビティ図でもWebサイトの処理範囲外とされているように、顧客が行うものであってシステムは関与しません。したがって、残った「決済番号取得」及び「決済情報通知」がコンビニ決済クラスで実装すべき処理内容となります。

∴決済番号取得，決済情報通知

解説

改めて「入金データチェック処理」及び「入金期限チェック処理」の内容を簡単にまとめておきましょう。

入金データチェック処理

入金データを取り込み、その決済番号がWebサイトで保持している決済番号と一致し、該当の購入情報が取り消されていない場合に商品発送を行う

入金期限チェック処理

商品発送前かつ取消前の購入情報に対して、入金期限が過ぎていないかをチェックする

以上を踏まえて解答するにあたっては、問題文に示された「日付が変わった後」という記述がヒントになります。仮に1月31日が入金期限日の注文について、その注文の料金支払いが1月31日の23時以降に行われたことを考えます（バッチ処理は1時間毎に行われるので）。日付が変わって2月1日になってからバッチ処理が実行される際、先に「入金期限チェック処理」を行ってしまうと、当該注文は「未発送かつ入金期限日を過ぎている」と判断され、（顧客は入金期限日内に支払いをしていたにも関わらず）購入取消の処理が進められてしまいます。これが、処理順の先後によって生じる不具合です。

逆に「入金データチェック」を先に行えば、入金確認→商品発送の手続きで発送済となり入金期限チェックの対象から外れるため、購入が取り消されることはありません。

∴入金されている購入情報が取り消されてしまう