2015年 春期 応用情報技術者試験 問8
チケット販売システムの在庫調整機能の開発
C社とD社は、インターネットを用いたチケット販売用Webサイトをそれぞれ運営している。C社、D社のWebサイトは、ともに複数の公演を取り扱い、24時間販売可能である。両社は、イベントの主催者であるV社の委託を受けて、チケットを販売している。
V社は、公演ごとに両社の売行きを予想し、販売開始前にC社、D社にチケット在庫を割り当てる。両社のWebサイトでは、それぞれ自社に割り当てられたチケット在庫だけを販売する。
近年、同じ公演のチケットが、一方のWebサイトでは売切れになっているにもかかわらず、他方のWebサイトではまだ販売されているという状況が多く見られる。そこでV社は、C社とD社に対して、販売開始後に在庫が多いWebサイトから少ないWebサイトへチケット在庫を移動する在庫調整機能の開発を依頼した。
C社、D社は依頼を受けて検討に着手した。C社は開発部門のE氏、D社は開発部門のF氏がそれぞれ設計を担当することになった。
[V社の要望]
在庫調整機能に関するV社の要望は、次のとおりである。
・在庫調整を行うかどうかは、公演ごとに決定し、販売開始後も変更可能とする。 ・在庫調整は、利用者のアクセスが少ない時間帯を選び、1日に数回実施できる。 ・在庫調整実施中の公演のチケットは、数分程度であれば一時的に販売不可となってもよい。 ・公演ごとに、在庫調整を実施するチケット在庫数のしきい値を設定する。しきい値はC社WebサイトとD社Webサイトで同じ値とする。在庫調整を開始する時点でC社Webサイト、D社Webサイトのどちらか一方の販売可能なチケット在庫数がしきい値未満であった場合、チケット在庫を移動する。ただし、販売可能なチケット在庫数が、両方のWebサイトでしきい値以下の場合、チケット在庫の移動は実施しない。 ・これらの要望を満たす実現方法の中で、できるだけ費用を抑えずに済む方法を採用したい。
[V社チケット在庫のデータ項目]
C社、D社で保持するV社チケット在庫のデータ項目(抜粋)を表1に示す。チケット在庫データは、公演の全席分をC社、D社の両社で保持する。データ項目は将来的にV社の意向によって追加される可能性がある。
項目名 | 内容例 | 説明 |
---|---|---|
公演日時 | 2015-04-19 13:00 | 公演が行われる日時を示す。 |
席番 | ○列□□番 | 座席の位置を示す。 |
販売サイト | C社、D社 | C社、D社のどちらのサイトで販売するかを示す。 |
販売済フラグ | 販売済み、未販売 | 在庫が販売済みであるかどうかを示す(自社販売分だけ有効)。 |
[在庫移動処理の検討]
E氏とF氏は、チケット在庫を移動するための処理(在庫移動処理)の内容について検討した。しきい値を50席とした場合の在庫移動処理の内容を表2に示す。
項番 | 在庫数の状況 | 処理 |
---|---|---|
1 | C社、D社ともに販売可能なチケット在庫数が50席以下 | チケット在庫の移動は実施しない。 |
2 | C社、D社ともに販売可能なチケット在庫数が50席以上 | チケット在庫の移動は実施しない。 |
3 | C社の販売可能なチケット在庫数が50席未満、D社の販売可能なチケット在庫数が51席以上 | C社の販売可能なチケット在庫数が50席になるまで、販売サイト="D社"、販売済フラグ="未販売"の在庫に対し、販売サイトを"C社"に変更することでD社からC社へ在庫を移動する。ただし、処理途中でD社の販売可能なチケット在庫数が50席となった場合、その時点で在庫移動処理を終了する。 |
4 | C社の販売可能なチケット在庫数が50席以上、D社の販売可能なチケット在庫数が50席未満 | D社の販売可能なチケット在庫数が50席になるまで、販売サイト="C社"、販売済フラグ="未販売"の在庫に対し、販売サイトを"D社"に変更することでC社からD社へ在庫を移動する。ただし、処理途中でC社の販売可能なチケット在庫数が50席となった場合、その時点で在庫移動処理を終了する。 |
[システム処理方式の検討]
E氏とF氏は、V社の費用面の要望も考慮した結果、D社システムがファイルを送信することによって処理を開始し、ファイルを受信したC社システムが在庫移動処理を実施した後、D社システムへ結果のファイルを送信するという、ファイルを用いた疎結合構成の在庫調整処理を採用することとした。
決定した処理方式の案は次のとおりである。
D社システムは、スケジューラによって1日に数回、在庫調整処理を起動する。D社Webサイトでその公演の販売停止を行った後、データベース(以下、DBという)から処理対象公演全席分のチケット在庫データを抽出し、一つのファイル(以下、I/Fファイルという)に編集してC社へ送信する。
C社システムは、D社からI/Fファイルを受信すると、在庫調整処理を開始する。C社Webサイトでその公演の販売停止を行った後、DBから処理対象公演全席分のチケット在庫データを抽出する。C社、D社のチケット在庫データを基に表2の在庫移動処理を行い、処理結果のチケット在庫データをDBに反映し、C社Webサイトでその公演の販売再開を行った後、処理対象公演全席分の在庫移動結果を1/Fファイルに編集してD社へ送信する。
D社システムは、C社からI/Fファイルを受信すると、処理結果のチケット在庫データをDBに反映した後、D社Webサイトでその公演の販売再開を行う。
通信の異常などで、C社からの1/Fファイル送信のエラーを検出した場合、又はD社側でI/Fファイル受信タイムアウトを検出した場合は、その時点でC社、D社とも在庫調整処理前のDBの状態で販売を再開する。
[ファイル形式の検討]
在庫調整処理で使用する1/Fファイルの形式として、"CSV形式"と"XML形式"を比較した。
検討の結果、aの追加によってデータ項目を追加できるという、"XML形式"のもつ拡張性に注目して、ファイル形式は"XML形式"を採用することとした。
[シーケンス図の作成]
E氏とF氏は、ここまでの検討を基に処理のシーケンス図を作成した。作成したシーケンス図を図1に示す。
図1中の"タイマ"オブジェクト、"処理生成"、及び"タイムアウト発生"以降のメッセージは、シーケンス図作成段階で、①"C社ファイル送信がエラーとなった場合にD社Webサイトで不具合が発生する"という問題に対応するために追加した処理である。
[テストで見つかった不具合]
在庫調整処理中に回線の不通によってC社ファイル送信がエラーとなる異常系のテストを行ったところ、あるチケット在庫に関するC社Webサイト、D社Webサイトでの販売状況に、シーケンス図の誤りに起因する不具合が発生した。
表2の項番3に該当するテストデータでは一部のチケット在庫がC社Webサイト、D社Webサイトの両方でd。表2の項番4に該当するテストデータでは一部のチケット在庫がC社Webサイト、D社Webサイトの両方でeとなることが確認された。
E氏とF氏は、シーケンス図の不具合を修正するために、②C社在庫調整処理が呼び出す、又は受け取る"処理結果反映"、"販売再開"、"C社ファイル送信"、及び"C社ファイル受信回答"のメッセージの順序を見直した。