H29春ES午後2問2の解き方 複数の駐輪場を管理するシステム

問題の感想

駐輪場の問題です。計算問題がなく読解力が問われる問題でした。

解答

• 設問1

(1)(a)返却通知、精算カード支払い通知
(1)(b)会員番号、自転車ID
(1)(c)管理サーバからレンタル用ラック数を増やす指示を受信した結果、空き一般用ラックを空きレンタル用ラックとする場合
(2)(a)f:会員番号確認要求
(2)(a)i:貸出通知
(2)(b)g:電子ロック制御指示
(2)(b)h:自転車検出通知
(3)(a)情報:精算機に接続されているラックの総数
(3)(a)取得方法:精算機に戻ってきた接続確認要求の3バイト目から取得する
(3)(b)a:受信したシリアルIFとは異なるシリアルIF



• 設問2

(1)(a)貸出可能なレンタル自転車の有無と、有りの場合のラック番号
(1)(b)一定時間後にレンタル待ち状態に遷移し、貸出可能になっている可能性があるから
(1)(c)b:レンタル待ち
(1)(c)c:同一の会員番号


ラック管理タスクの処理の中で、レンタル通知を受けた時の処理を穴埋めします。
bは、「空き2」以外で「レンタル可」返す状態を回答すればいいので、「レンタル通知」を受けて「取出待ち2」状態になった後の状態を回答すればいいので、
「レンタル待ち」となります。
cは、状態が「取出待ち2」のままの時「レンタル不可」を返す対象を回答するので、「同一の会員番号」が解答になります。
(2)(a)レンタル用ラックに一般自転車を止めている状態
(2)(b)d:自転車ID　NG
(2)(b)e:自転車ID　OK
(3)ラックの状態が自転車ID確認待ち1からレンタル待ちに変化することで種別が変化したことを認識する


一般用ラックにレンタル自転車を返却した場合に、ラック管理タスクが種別変化を認識する方法を回答します。
ラック管理タスクは、状態の変化をラック制御タスクからのラック状態通知で知ることができます。
ラック制御タスクの状態遷移図を見ると、一般用ラックにレンタル自転車(自転車IDがある自転車)が返却された場合には、 状態が「自転車ID確認待ち1」から「レンタル待ち」に変化していることがわかります。この通知で種別変化を認識することができます。



• 設問3

(1)j:要求した会員番号以外の応答


ラック管理タスクの処理の中で、管理サーバから「会員番号確認応答」を受信したときに精算機2に送信する場合の条件を回答します。
「会員番号確認要求」はもともと精算機(ラック管理タスク)から送信されていたものですので、それが2台になったことで精算機1から送信された要求でなければ、精算機2に送信する必要があります。
(2)操作内容:精算機1で貸出手続きを行い、レンタル自転車を取り出す前に精算機2で同じ貸出カードで貸出手続きを行った
(2)変更点:レンタル要求で指定された会員番号を他精算機のラック管理タスクに送信し、重複で借りられないようにする。


精算機1から「貸出通知」が送信されてから、精算機2からも「貸出通知」が送信される事象が発生したそうです。この不具合解析をします。
操作内容については、「貸出通知」が送信される契機が、ラックからレンタル自転車が取り出されて貸し出された際に通知するものですが、自転車の貸し出しは自転車を借りた状態では借りれないように管理しているはずです。
通常は、自転車の「貸出通知」でだれが自転車を借りているかを把握しているのですが、今回はそれが2回出てしまっているということで、考えられる操作内容としては、 「精算機1で貸出手続きを行い、レンタル自転車を取り出す前に精算機2で同じ貸出カードで貸出手続きを行った。」となります。
変更点としては、「貸出通知」で管理していたレンタル済みの利用者の情報をもっと早い段階で認識する必要があるので、貸出する際のレンタル通知の情報を他の精算機と共有する必要があります。なので、変更点としては、 「レンタル要求で指定された会員番号を他精算機のラック管理タスクに送信し、重複で借りられないようにする。」となります。
(3)ラック状態を受信する前に、他精算機からの精算要求を受信した


「③精算通知待ちで精算要求を受けると、精算応答でエラーを通知する」この事象が発生するシーケンスを回答します。
従来、ラック管理タスクは、ラック制御タスクが「精算待ち」状態の時だけに「精算要求」を行っていましたが、精算機が2台になり、ほかの精算機からは「精算待ち」状態でない場合にも「精算要求」を送信してしまうことでこのエラーが発生しています。
なので、回答としては、「ラック状態を受信する前に、他精算機からの精算要求を受信した」となります。