応用情報技術者 2019年 春期 午後 問03

解答の論理構成

1. 初期状態は【問題文】で「初期状態は0」であると示されています。
2. 1品目「鮭定食」のイベントコード
   • 表1よりN=“1”, S=“1”, O=“0” なので “110”。
   • 表2の“状態番号0×イベントコード110”のセルは “2:0”。
   • よって状態は “0→2” へ遷移します。
3. 2品目「野菜サラダ」のイベントコード
   • N=“2”, S=“1”, O=“2” で “212”。
   • 表2の“状態番号2×イベントコード212”は “3:0”。
   • よって “2→3” へ遷移します。
4. 3品目「ゴマドレッシング」のイベントコード
   • N=“4”, S=“0”, O=“2” で “402”。
   • 表2の“状態番号3×イベントコード402”は “4:0”。
   • よって “3→4” へ遷移します。
5. 4品目「みそ汁」のイベントコード
   • N=“3”, S=“1”, O=“0” で “310”。
   • 表2の“状態番号4×イベントコード310”は “5:50”。
   • よって “4→5” へ遷移し、ここで値引き“50”が適用されます。
6. 以上より遷移順は “0,2,3,4,5” となり、模範解答と一致します。

誤りやすいポイント

• 「鮭定食」はO=“0” であるためイベントコードは “110”。「111」と誤記しやすいです。
• 「みそ汁」はS=“1”。S=“0”と誤ると “300” になり、表2では自己ループ “4:0” なので最終状態が誤ります。
• 「ゴマドレッシング」は分類4のためN=“4”。分類2と混同して “212” を選んでしまうミスが散見されます。
• 値引き“50”は状態4→5のときだけ加算される点を見落としやすく、状態遷移自体を誤る原因になります。

FAQ

解答の論理構成

1. 状態3の発券可否（ア）
   • 図2で発券可を示す二重円は「2、4、5」、単一円は「0、1、3」です。
   • 表2の“発券可”列には、この図2の結果がそのまま入ります。
   • 従って単一円である状態「3」は発券不可なので、アにはfalseが入ります。
2. 状態4でイベントコード「212」が発生した際の遷移（イ）
   • イベントコード「212」は表1のＮ=2、Ｓ=1、Ｏ=2、すなわち「サイドメニュー−1」かつ“オプション必須”の商品です。
   • 図2を見ると、サイドメニュー−1でオプションが未指定のときは必ず状態「3」に遷移し、そこでオプション（イベントコード「402」など）を待つ設計になっています。
   • すでに発券可能な状態「4」にいても、新たにオプション必須のサイドメニュー−1を追加すると再びオプション待ちの状態「3」に戻る必要があります。
   • また、値引きはこの時点では発生しないので金額は0です。
   • よって イ には3:0が入ります。

誤りやすいポイント

• 発券可否を図2の円の形ではなく表2の既存値だけで判断してしまい、状態「3」をtrueと誤記する。
• 「212」が図2の矢印に明示されていないため自己ループと勘違いし、4:0やE:0としてしまう。
• “オプション必須”の判定をＯの値だけでなくＳの値まで誤って読んでしまい、イベントコードを取り違える。

FAQ

解答の論理構成

1. [ウ]
   • 図3(2)に「商品の金額を注文金額に加算する」とあり、表3のorder配列には「order[i].Aで…商品の金額を参照」と明記されています。
   • よって amount ← amount + order[i].A が成立し、[ウ] は order[i].A です。
2. [エ]
   • 図3(3)は「注文された商品のイベントコードを算出する」。
   • 問題文には「表1のN、S、Oを左から順に並べた3桁の数をイベントコードと呼び」とあるため、
     event_code = N×100 + S×10 + O
   • これをorder配列要素で表すと order[i].N*100+order[i].S*10 となり、末尾の + order[i].Oは既にプログラム行に固定で書かれているので、[エ] は order[i].N*100+order[i].S*10 です。
3. [オ]
   • 図3(4)では「状態遷移の際の値引きの金額を取得」すると記されています。
   • 表3には「status_table[stat][ev].discountで値引きの金額を参照」とあるので、[オ] は status_table[status][event_index].discount です。
4. [カ]
   • 図3(5)は「…次の状態番号を取得して、状態番号を更新」。
   • 表3には「status_table[stat][ev].statusで遷移先の状態番号を参照」と示されているため、[カ] は status_table[status][event_index].status です。
5. [キ]
   • 図3(8)で「発券の可否を判定して、発券ボタンの状態を変化」とあります。
   • 表3によれば発券可のフラグはstatus_table[stat][ACCEPT_INDEX].acceptに格納され、図4ではいったんacceptedへ代入されています。
   • よって判定条件は acceptedがtrueに等しい となり、[キ] は acceptedがtrueに等しい です。

誤りやすいポイント

• イベントコードの組立順を逆にしやすい
  「N、S、Oを左から順に並べた3桁」とあるため100,10の重みを付け忘れると誤答になります。
• event_codeとevent_indexの混同
  get_event_index() で得るのは列インデックスであり、そのまま状態を更新できない点に注意が必要です。
• 発券可否の判定先
  acceptフラグをstatus_tableから直接参照せず、一度acceptedへ格納しているのでif条件でstatus_tableを再参照してしまうミスが多発します。
• discount加算漏れ
  サイドメニュー値引きは遷移表から取得する設計です。表から読む代わりに別ロジックで判定しようとすると整合が取れなくなります。

FAQ

解答の導き方

1. 前提として押さえる点（問題文からの根拠）

• 判定処理は「イベントコードは、表1のN、S、Oを左から順に並べた3桁の数をイベントコードと呼び、イベントコードの値によって状態の遷移先を制御する」とある。つまり、どのボタン（商品・オプション）がどの遷移を引き起こすかは表1（商品のN,S,O,A）と表2（状態遷移表）の組合せで決まる。
• また「オプションを指定する際には、Oの値が一致するオプションだけが選択できる」とあるので、オプションの表示/選択制御はOの値（＝オプショングループ）でまとまっている。
• 判定プログラム本体は状態遷移表（status_table）を参照して遷移と値引きを決め、表1, 表2の内容だけで挙動を変えられる部分が「メニュー項目」「オプションのグルーピング」「状態遷移／その時の値引き額」である。

• 問題点：これは「時間帯」による動的な可否制御であり、実行時（券売機稼働中）に表示／非表示を切り替える必要がある。表1, 表2は静的データであり、問題文で「表1、2の内容について、業務運用中の変更は行わないものとする」と明記されているため、運用中に表を差し替えて対応することは不可である。
• また判定プログラム側に時刻を判断して可否を切る処理がないことから、時間条件での制御を行うにはプログラム（または運用プロセスでの表の差替え）を変更する必要がある。
  → よってアは表1, 表2だけでは対応できない。

• 実現可能性の根拠：「オプションを指定する際には、Oの値が一致するオプションだけが選択できる」「イベントコードはN,S,Oで決まる」なので、表1のO値を用いてオプション群を定義し、表2にそのイベントコード（例：N=4,S=0,O=新規の値 → 403等）の列を追加して遷移を定義すれば、プログラムを変えずに選択肢を増やしたり複数指定を可能にできる。具体的な手順（表のみの変更で完結）を示すと次の通り。
  実装方法（表だけで済ませる手順）
  • 追加するオプション群をひとまとめにする新しいO値を決める（既存のO=1やO=2を流用すると既存商品にも影響するため、影響を限定したければ新しいO値を使う）。
  • 表1：該当メイン商品のOを新しいO値に変更し、分類番号4（オプション）に「並、大盛り、特盛り」と「普通、多め、少なめ」を同一のO値で追加する。これにより、そのメイン商品を選択した際にそのO値に属するオプションだけが選べるようになる（「Oの値が一致するオプションだけが選択できる」のルールに合致）。
  • 表2：上で追加したオプションに対応するイベントコードの列（例：403）を追加し、状態遷移表の必要な行（主に状態1でオプション選択を受け付け、選択後の状態を適切にするセル）に遷移先と値引き（通常は0）を設定する。もし「複数オプションを順に選べる」ようにしたければ、オプション列の該当状態セルを自己ループや次状態へ許可するよう設定すればよい（プログラムはstatus_tableの指定どおりに遷移・値引き・発券可を判断する）。
  • 注意点（誤りやすいポイントへの対処）：既存のO値（例えばO=1）に単に「つゆ量」を追加すると、O=1を持つ全てのメイン商品に影響してしまう。望まない副作用を避けるには、新しいO値を作り、対象のメイン商品のみOを変更することが必要である。
  よって、イは表1（オプション追加・Oの割当変更）と表2（新イベント列の追加と遷移設定）だけで実現可能である。

• 表面上の考え方：表2の各セルには「遷移先の状態番号：値引きの金額」が入っており、判定プログラムはそれらを合算してdiscountを計算するので、値引き額を表2に書けば処理できそうに思える。だが実際には次の理由で表だけでは対応できない（あるいは現行要件との矛盾を生む）ことが多い。
• 主な理由：問題文に「値引きは食券購入ごとに1回だけ適用される」と明示されているため、現行の状態遷移図／状態遷移表は「1回適用」を前提に設計されている。複数回適用に変えるには、個々のセットを検出して都度50円を発生させるための「セット数のカウント」や「どの組合せが既に割引適用済みかの判定」といったロジックが必要になる。
  • 理論的には表2を大幅に書き換えて状態を増やし、特定の並び／組合せごとに値引きセルを作れば限定的なケース（最大個数が固定）については実装できる可能性もあるが、実際の注文の順序や組合せは多様であり、任意数のセットに対して一般的に正しく割り当てるにはプログラム側で「数をカウントする」「組み合わせを判断する」処理を加える方が確実で保守的である。
• 結論：要求そのもの（「複数回適用」）は状態遷移表だけでは網羅的かつ安全に実現できないため、プログラム本体の変更（または運用上の別管理）が必要であり、表1, 表2のみでは対応不可と判断する。

1. したがって、表だけで対応可能なのは「イ（オプションを追加・グルーピングする）」「エ（新しいメイン商品を追加し、その商品のオプション群を用意する）」であり、答えは イ、エ となる。

誤りやすいポイント

• オプションの追加だけで済むと考える誤り
  単に分類番号4にオプション行を追加しても、そのオプションがどのメイン商品に対して表示・選択可能かはO値の一致で決まる。既存のO値を流用すると想定外の商品にオプションが出てしまう。影響を限定するには新しいO値を割り当て、該当メイン商品の表1のOを変更する必要がある。
• 表2（状態遷移表）を忘れてしまう誤り
  新しいオプションを追加したら、そのイベントコード（N,S,Oによる3桁）に対応する列を表2に追加して、どの状態で受け付けるか、遷移先・値引きをどうするかを定義しなければならない。get_event_index() がそのコードを見つけられるように表2側を整える必要がある。
• 時間依存や動的切替を表だけで実現できると考える誤り
  「業務運用中に表1,2を差し替える」運用は問題文で禁止されている（運用中の変更は行わないものとする）。時間帯でオン／オフするにはプログラム側の時刻判定や運用手順が必要。
• 値引きの回数制御を表だけで安直に変える誤り
  表2の値引き金額を書き換えるだけで済むケースもあるが、「複数回適用」のように任意個の組合せを正しく検出して重複なく割引を与えるには、個数をカウントする等のプログラム的処理が必要になることが多い。

FAQ