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

解答の論理構成

1. a の決定
   • 表2「Created」の説明文は “仮想サーバの状態変更内容” を記載しています。
   • 図2の状態遷移では “作成中” から “処理完了” イベントで “停止” へ遷移します。

     “作成中 →（処理完了）→ 停止”

   • よって “Created” ハンドラの新しい状態は “停止” になります。
   • したがって a = 停止 です。
2. b の決定
   • 表3「サーバ起動」行を確認します。
   • “サーバ起動” メッセージは “停止” 状態のときだけ受け入れられる仕様です（図2および API 仕様より）。
   • “停止” → “起動中” への遷移を担うのは表2で “起動中” に変更し StartServer を呼び出す “Starting” ハンドラです。
   • したがって b = Starting です。
3. c の決定
   • 表3「サーバ削除」行を確認します。
   • “停止” 状態で “サーバ削除” メッセージを受信した場合、図2では “停止” → “削除中” へ遷移します。
   • “削除中” への遷移と DeleteServer 呼び出しを行うのは表2で定義されている “Deleting” ハンドラです。
   • したがって c = Deleting です。

誤りやすいポイント

• CreateServer 完了後の状態を “起動” と誤解する
  → API 仕様には「CreateServer は仮想サーバを作成し…」としか書かれておらず、自動起動は行いません。図2も “停止” を示しています。
• “サーバ起動” のハンドラを “Ready” と混同する
  → “Ready” は処理完了メッセージを受け取った後に “起動” に確定させるハンドラであり、起動要求そのものを処理するのは “Starting” です。
• “サーバ削除” 時に StopServer が必要と考え “c” に “Stopping” を入れてしまう
  → “停止” 状態からは直接 “削除中” へ遷移できるため DeleteServer を呼び出す “Deleting” が正解です。

FAQ

解答の論理構成

1. 処理完了メッセージが必要となる条件
   • 【問題文】「メッセージハンドラは、メッセージハンドラの処理完了のイベントを発生させる必要がある場合に限り、呼び出したAPIの処理終了後に処理完了メッセージを生成し、メッセージキューに格納する。」
   • すなわち、次の状態遷移を“自動で”発生させる必要があるかどうかが判断基準です。
2. “次の状態遷移”が必要なメッセージハンドラ
   • Starting：状態を“起動中”に変更し【表2】「StartServer」を呼び出す。完了後は“起動”へ遷移させる必要があるため、②は「する」。
   • Stopping：状態を“停止中”に変更し【表2】「StopServer」を呼び出す。完了後は“停止”へ遷移させる必要があるため、④は「する」。
   • Deleting：状態を“削除中”に変更し【表2】「DeleteServer」を呼び出す。完了後は“削除済”へ遷移させる必要があるため、⑥は「する」。
3. “次の状態遷移”が不要なメッセージハンドラ
   • Created・Ready・Stop・Deleted は「処理完了」メッセージを受け取って呼び出されるハンドラです。すでに完了イベントが到達しているため、さらに処理完了メッセージを送ると無限ループになります。よって①・③・⑤・⑦は「しない」。
4. 結論
   • 処理完了メッセージを送信する番号は ②、④、⑥ です。

誤りやすいポイント

• 「CreateServer は完了してから応答を返す」ため、Creating が即座に“停止”へ遷移できると誤解し、①も「する」と答えてしまう。
• Ready・Stop・Deleted も API を呼び出さないので“暇だから送る”と考え、③・⑤・⑦を「する」としてしまう。
• 「_中」状態＝必ずメッセージ送信、と機械的に覚えて②④⑥以外も選んでしまう。

FAQ

解答の論理構成

1. 下線部は「サーバ停止とサーバ削除の二つのメッセージをメッセージキューに格納するだけだと、意図した結果にならない」と述べています。
2. その理由は、【問題文】の「メッセージキューに複数のメッセージが存在した場合は、メッセージごとに別々のスレッドを生成し、それぞれのメッセージハンドラを並列に動作させる。」という仕様により、
   • “サーバ停止”メッセージ（Stopping ハンドラ）と
   • “サーバ削除”メッセージ（Deleting ハンドラ）
   が同時並行で処理され得る点にあります。
3. 図2の状態遷移では、削除要求が有効になるのは仮想サーバが“停止”になってからです。しかし並列実行のため、「停止処理中」に “削除” ハンドラが先に動くと、
   • 仮想サーバはまだ“起動”または“停止中”であり
   • 表3のルール「サーバ削除 × “起動”＝Err」「サーバ削除 × “停止中”＝Err」に該当し、APIエラーになります。
4. よって「仮想サーバの状態が“停止”になる前にサーバ削除のメッセージが送信されるから」という解答となります。

誤りやすいポイント

• 同期的に順番どおり処理されると思い込み、並列スレッドによる競合を見落とす。
• 「停止中」は“停止”とは別状態であることを無視し、削除が許可されると誤解する。
• 表3の“Err”セルの意味を読み飛ばし、APIが成功するケースだと勘違いする。

FAQ

解答の論理構成

• まず、追加するメッセージハンドラ StopDeleting の役割を把握します。問題文には
  「仮想サーバの状態が“起動”のときにサーバ削除のメッセージを受信した場合は、メッセージハンドラが StopServer の API を呼び出した後、自動的に状態遷移して、続いて DeleteServer の API が呼び出されるようにする」
  とあります。StopDeleting は “StopServer を呼び出し、処理完了後に DeleteServer へバトンタッチする” ための専用ハンドラです。
• StopDeleting を表2に追加すると、対応する遷移先状態として “停止・削除中” が必要になります。これは「“停止・削除中”の状態を新設することにした」という仕様変更により決定されます。
• 表3の行・列を点検すると、(i) 以前は “起動 × サーバ削除” のセルに Err が入っており、削除要求をエラーにしていました。今回の仕様変更はまさにこの箇所を置き換えるものなので、
  • 仮想サーバの状態： “起動”
  • メッセージの種類： “サーバ削除”
  • メッセージハンドラ名： “StopDeleting”
  へ修正します。設問(3)の空欄は従って d＝起動, e＝サーバ削除, f＝StopDeleting です。
• 表2・表3の他のセルは従来仕様と衝突しないため変更不要です。なお (1) の空欄 a は CreateServer 処理完了後の安定状態なので “停止”、(2) の b は “停止” から起動要求を受けた際のハンドラで “Starting”、(2) の c は “停止” から削除要求を受けた際のハンドラで “Deleting” となります。

誤りやすいポイント

• “停止中” に対しても StopDeleting を適用してしまう
  → StopServer が二重発行となり、問題文「同一のサーバ ID に対する API 呼出しの排他制御」を破ってしまいます。
• “停止・削除中” の追加だけで満足し、表3の Err セルを修正し忘れる
  → ディスパッチャが StopDeleting を生成できず、新仕様が動きません。
• StopDeleting で DeleteServer を直接呼び出すと誤解する
  → StopDeleting は StopServer を呼び出し「処理完了メッセージの送信: する」として次の Deleting を誘発する設計です。

FAQ

解答の論理構成

1. 仕様変更の目的を確認
   • 問題文には「仮想サーバの状態が“起動”のときにサーバ削除のメッセージを受信した場合…サーバを削除できるように仕様を変更する」とあります。したがって “起動” 状態で “サーバ削除” メッセージを受け取った際の挙動を新しく定義する必要があります。
2. 既存の表3（変更前）を確認
   • “サーバ削除” 行の “起動” 列は “Err” になっています（引用：表3）。
   • これは仕様変更前はエラーにしていたことを示します。
3. 新設するメッセージハンドラの確認
   • 表4で新たに追加するハンドラ名は “StopDeleting” です（引用：表4）。
   • このハンドラは「“停止・削除中”に変更し」「StopServer」を呼び出し「処理完了メッセージを送信する」と定義されています。
4. どのセルを “StopDeleting” に書き換えるか
   • (3) の指示文：「表3中の仮想サーバの状態が“d”で、メッセージの種類が“e”の箇所のメッセージハンドラ名を、“f”に変更する。」
   • 仕様変更の対象は「状態が“起動”」かつ「メッセージの種類が“サーバ削除”」のセルです。
   • ここを新ハンドラ “StopDeleting” に書き換えることで、StopServer → DeleteServer の連続処理が実現します。
5. 結論
   d：起動
   e：サーバ削除
   f：StopDeleting

誤りやすいポイント

• “起動” と “起動中” の取り違え
  “起動中” は StartServer 実行中、 “起動” は稼働完了後です。今回の変更対象は後者。
• “サーバ停止” と “サーバ削除” の混同
  自動停止機能は削除要求時のみ。停止要求時は従来どおり “Stopping” を用います。
• 追加した “StopDeleting” をすべての削除要求に適用してしまう
  仕様変更は “起動” 状態限定。 “停止” 状態の削除は従来どおり “Deleting” です。

FAQ