応用情報技術者 2016年 春期 午後 問07
飲食店向けタッチ式注文端末に関する次の記述を読んで、設問1〜4に答えよ。
G社は、飲食店向けのタッチ式注文端末（以下、端末という）を開発している。
飲食店向けタッチ式注文システムのシステム構成を図1に示す。管理システムは、ネットワークのアドレスを利用して、端末を識別する。
〔端末の画面操作〕
端末の画面はタッチパネルになっている。利用者は、ボタンの領域（以下、ボタンという）にタッチして端末を操作する。画面には、選択画面、注文画面及び履歴画面の3種類がある。端末画面の表示概要を図2に示す。
端末は、利用者が一つのボタンに触れ、離したときに、そのボタンにタッチしたと認識する。また、利用者が複数のボタンに同時に触れていた場合、最後に離したボタンをタッチしたと認識する。
なお、端末の初期化中又は画面の切替え中に、ボタンにタッチした場合、タッチは無効とする。
〔端末の動作概要〕
端末の主な機能の動作概要を表1に示す。
〔端末ー管理システム間の通信〕
注文ボタンへのタッチを認識すると、端末は、管理システムに注文メッセージを送信する。管理システムは、注文メッセージを受信すると、一定時間後に、端末に注文確定メッセージを送信する。
端末は、注文確定メッセージを受信すると、注文履歴の中から対応する注文を確定し、管理システムに注文確定完了メッセージを送信する。ただし、対応する注文が注文履歴の中に存在しなかった場合、端末は注文確定メッセージを破棄する。
管理システムは、注文確定メッセージを送信後、一定時間内に端末から注文確定完了メッセージを受信できなかった場合、注文が取り消されたものとして扱う。
注文取消ボタンへのタッチを認識すると、当該の注文が確定していない場合に限り、端末は、管理システムに注文取消メッセージを送信する。
〔端末ー管理システム間のメッセージの構成〕
注文メッセージは、メッセージの種別を示すデータ、注文ID及び注文情報から構成される。それ以外のメッセージは、メッセージの種別を示すデータ及び注文IDから構成される。
〔端末のソフトウェア〕
端末は、イベントドリブンプリエンプション方式のリアルタイムOSを使用する。
・端末の初期化
端末の電源を入れると、初期化プログラムが動作する。初期化プログラムは、ハードウエアの初期化、メモリの初期化、端末制御プログラムの RAM への転送、及び OS の起動を行う。端末制御プログラムの RAM への転送速度は 1M バイト／秒、ハードウエア及びメモリの初期化から端末制御プログラムの転送開始までの所要時間は 0.2 秒であり、OS の起動には 0.3 秒掛かる。
・タスクの機能概要
主なタスクの機能概要を表2に、入力判定タスクの処理を図3に示す。
設問1：端末の動作について、(1)〜(3)に答えよ。
（1）200kバイトの端末制御プログラムの場合、初期化プログラムの動作開始からOSの起動完了まで何秒掛かるか。答えは小数第2位を四捨五入して、小数第1位まで求めよ。ここで、1Mバイト＝1,000kバイト、1kバイト＝1,000バイトとし、初期化プログラムの各処理の移行に必要な時間は無視できるものとする。
模範解答
0.7（秒）
解説
解答の論理構成
-
転送速度と転送量を確認
【問題文】に「端末制御プログラムの RAM への転送速度は 1M バイト／秒」とあります。
また、小問説明で転送量は 200kバイト と与えられています。 -
変換係数を確認
小問説明に「1Mバイト＝1,000kバイト、1kバイト＝1,000バイト」と明記されています。
よって 1Mバイトは 1,000kバイト、すなわち です。 -
転送に要する時間を計算
転送時間 は -
その他の所要時間を加算
【問題文】には
・「ハードウエア及びメモリの初期化から端末制御プログラムの転送開始までの所要時間は 0.2 秒」
・「OS の起動には 0.3 秒掛かる」
とあります。
したがって総所要時間 は -
指定された丸め処理
小問説明：
「小数第2位を四捨五入して、小数第1位まで求めよ」
既に 0.7 秒は小数第2位が存在しないため、そのまま 0.7 秒 となります。
誤りやすいポイント
- 1Mバイトを 1,024kバイトと誤って計算し、転送時間を 秒にしてしまう。
- 初期化準備の 0.2 秒 を見落として合計を 0.5 秒にしてしまう。
- 丸め指示を読み飛ばし、0.70 秒や 0.67 秒など端数付きで答えてしまう。
FAQ
Q: もし転送量が 512kバイトなら転送時間はどう計算しますか？
A: 同じ換算規則に従い 秒となります。
A: 同じ換算規則に従い 秒となります。
Q: OS 起動時間が変わった場合でも丸め方は同じですか？
A: はい。「小数第2位を四捨五入」という指示は合計値に対して常に適用します。
A: はい。「小数第2位を四捨五入」という指示は合計値に対して常に適用します。
Q: 1Mバイトを 1,024kバイトで換算したら減点されますか？
A: 小問説明に「1Mバイト＝1,000kバイト」と明示されているため、指示に従わないと誤答となります。
A: 小問説明に「1Mバイト＝1,000kバイト」と明示されているため、指示に従わないと誤答となります。
関連キーワード: データ転送速度, 単位換算, ラウンド規則, 初期化処理, リアルタイムOS
設問1：端末の動作について、(1)〜(3)に答えよ。
（2）注文IDだけでは実現できないことを解答群の中から選び、記号で答えよ。
解答群
ア：注文を確定するときに、確定すべき注文を選択する。
イ：注文を取り消すときに、注文履歴の取り消すべき注文を選択する。
ウ：注文を取り消すときに、当該の注文を取り消してよいかを判断する。
エ：利用者が注文した順に、履歴画面に注文情報を並べる。
模範解答
ウ
解説
解答の論理構成
- 注文IDの役割を確認
- 問題文では「注文IDは、端末ごとに、1から始まる連番として生成される。」とあり、IDは一意に注文を識別するためのキーです。
- 各選択肢で“IDだけ”で足りるかを検討
- ア：管理システムから届いた「注文確定メッセージ」には注文IDが入っています。端末は「注文履歴の中から対応する注文を確定」するだけなので、IDがあれば十分です。
- イ：履歴画面で利用者が行単位で「注文取消ボタン」に触れるとき、注文IDで該当行を引き当てれば取り消すべき注文を選択できます。
- エ：IDは「1から始まる連番」で発番されるので、ID昇順＝注文受付順です。従ってID順に並べれば「利用者が注文した順」で表示できます。
- “IDだけでは不十分”な処理
- ウ：注文取消の可否判定には「当該の注文が確定していない場合」という状態情報が必須です。問題文は「当該の注文が確定していない場合に限り、端末は、管理システムに注文取消メッセージを送信する。」と規定しています。
- この“確定／未確定”は注文IDとは別の属性なので、IDだけでは判断できません。
以上より、注文IDだけで実現できないのは「ウ：注文を取り消すときに、当該の注文を取り消してよいかを判断する。」です。
誤りやすいポイント
- 「連番＝状態情報」と誤解し、IDが大きいほど確定済みと早合点する。IDは時系列を表すだけで確定状態は含みません。
- 「管理システムが取り消し可否を教えてくれる」と想像するミス。可否判断は端末側仕様に明記されています。
- 表示順と内部処理順を混同し、エの並べ替えに余分な情報が必要だと思い込む。ID順で要件は満たせます。
FAQ
Q: 「確定かどうか」を何で管理すればよいのですか？
A: 注文履歴レコードに“確定フラグ”や“状態コード”を追加し、注文確定メッセージ受信時にフラグを立てる実装が一般的です。
A: 注文履歴レコードに“確定フラグ”や“状態コード”を追加し、注文確定メッセージ受信時にフラグを立てる実装が一般的です。
Q: ID重複で取り消し誤動作しませんか？
A: 問題文にあるとおり「端末ごとに、1から始まる連番」です。端末内では一意なので重複は起こりません。
A: 問題文にあるとおり「端末ごとに、1から始まる連番」です。端末内では一意なので重複は起こりません。
Q: 履歴並べ替えに時間が掛かりませんか？
A: 発行順＝ID順なので、リスト追加時に末尾へ挿入すれば並べ替え処理自体が不要です。
A: 発行順＝ID順なので、リスト追加時に末尾へ挿入すれば並べ替え処理自体が不要です。
関連キーワード: 一意識別子, 状態管理, メッセージ設計, イベントドリブン, 履歴管理
設問1：端末の動作について、(1)〜(3)に答えよ。
（3）管理システムが端末に注文確定メッセージを送信してから、端末が受信するまでの間に、端末が、当該の注文の注文取消メッセージを送信した場合の、端末の動作として適切なものを解答群の中から選び、記号で答えよ。
解答群
ア：管理システムと端末の情報に矛盾が生じ、異常な処理が実行される。
イ：そのときの端末の状態によって異なる。
ウ：注文確定メッセージが優先され、注文を取り消すことはできない。
エ：当該の注文の注文情報を削除する。
模範解答
エ
解説
解答の論理構成
-
状況整理
- 端末は「注文ボタンへのタッチを認識すると、…注文メッセージを送信する。」
- 管理システムは「注文メッセージを受信すると、一定時間後に、端末に注文確定メッセージを送信する。」
- 端末が注文確定メッセージを受信する前に、利用者が取消を実行すると「注文取消ボタンへのタッチを認識すると、当該の注文が確定していない場合に限り、端末は、管理システムに注文取消メッセージを送信する。」
-
取消時の端末処理
- 取消条件に合致する（まだ確定していない）ため、端末は注文履歴から当該注文を削除しつつ注文取消メッセージを送信すると読み取れる。
-
その後に注文確定メッセージが届いた場合
- 仕様には「注文確定メッセージを受信すると、注文履歴の中から対応する注文を確定し…ただし、対応する注文が注文履歴の中に存在しなかった場合、端末は注文確定メッセージを破棄する。」とある。
- すでに履歴から削除済みのため該当注文は存在しない。よって端末はメッセージを破棄し、状態は矛盾しない。
-
以上より
- 端末側の動作は「当該の注文の注文情報を削除する」が正しく、選択肢「エ」が該当する。
誤りやすいポイント
- 「管理システムが優先される」と早合点して「ウ」を選ぶ。端末側仕様を読めば削除後に破棄すると明記されている。
- 端末と管理システムの整合性に不安を感じ「ア」を選ぶ。実際には“破棄”処理により矛盾は解消される。
- タイミング依存だと誤解し「イ」を選ぶ。取消メッセージ送信可否は確定前かどうかだけで決まり、端末状態ごとの差異はない。
FAQ
Q: 管理システムは取り消された注文をどう扱いますか？
A: 「注文確定メッセージを送信後、一定時間内に端末から注文確定完了メッセージを受信できなかった場合、注文が取り消されたものとして扱う」とあるため、自動的に取消として処理します。
A: 「注文確定メッセージを送信後、一定時間内に端末から注文確定完了メッセージを受信できなかった場合、注文が取り消されたものとして扱う」とあるため、自動的に取消として処理します。
Q: 端末が注文確定メッセージを破棄すると通信エラーにはなりませんか？
A: 回答不要です。破棄は仕様で定められており、管理システムは完了メッセージ未着を検知して取消と判断するためエラーにはなりません。
A: 回答不要です。破棄は仕様で定められており、管理システムは完了メッセージ未着を検知して取消と判断するためエラーにはなりません。
Q: 端末側で確定済みか未確定かはどう判定しますか？
A: 注文履歴に確定フラグを持たせ、確定処理後にのみフラグ更新する実装が一般的です。本問では詳細構造は問われていません。
A: 注文履歴に確定フラグを持たせ、確定処理後にのみフラグ更新する実装が一般的です。本問では詳細構造は問われていません。
関連キーワード: メッセージ破棄, 排他制御, イベントドリブン, 非同期通信, 状態遷移
設問2：図1中の下線①について、(1)、(2)に答えよ。
（1）通知してきたタスク名を答えよ。
模範解答
タッチパネルタスク
解説
解答の論理構成
- 図3の冒頭には「①通知された情報を取得」とあります。ここで“通知”を行っているタスクを特定する必要があります。
- 【問題文】の表2「主なタスクの機能概要」において、
- 「タッチパネル」タスクの機能概要に「“タッチしたと認識すると起動し、必要情報を入力判定タスクに通知する。”」と明記されています。
- 他のタスク（メイン・画面表示）は、入力判定タスクに対して“通知”を行う記述がありません。
- 従って、図3で入力判定タスクが受け取る“通知された情報”の送り主は「タッチパネル」タスクとなり、設問の解答は「タッチパネルタスク」です。
誤りやすいポイント
- 「画面表示」タスクも入力判定タスクと情報をやり取りしますが、これは図3の途中処理（情報要求後に取得）であり、①で言及される“最初の通知”ではありません。
- “タッチパネル”と“タッチパネルタスク”を混同し、省略形で記述すると減点される場合があります。必ず【問題文】と同一表記「タッチパネルタスク」を用います。
- 図3の[ a ]分岐に意識を取られ、本質である“誰が通知したか”を見落としてしまうケースがあります。
FAQ
Q: 画面表示タスクも通知しているのでは？
A: 画面表示タスクは「情報要求の通知を受け取ると、画面種別及びボタンの座標から成る画面情報を、要求元に通知」します。これは入力判定タスクが①で受け取る“最初の通知”ではなく、後段の比較処理用です。
A: 画面表示タスクは「情報要求の通知を受け取ると、画面種別及びボタンの座標から成る画面情報を、要求元に通知」します。これは入力判定タスクが①で受け取る“最初の通知”ではなく、後段の比較処理用です。
Q: “タッチパネル”と書いただけでは不正解になりますか？
A: 設問は「タスク名」を求めています。【問題文】の正式名称「タッチパネルタスク」をそのまま記載するのが安全です。
A: 設問は「タスク名」を求めています。【問題文】の正式名称「タッチパネルタスク」をそのまま記載するのが安全です。
Q: 同時に複数箇所をタッチした場合でもタッチパネルタスクが通知元ですか？
A: はい。複数タッチ時の最終離脱判定もタッチパネルタスクが行い、その結果を入力判定タスクに通知します。
A: はい。複数タッチ時の最終離脱判定もタッチパネルタスクが行い、その結果を入力判定タスクに通知します。
関連キーワード: タスク間通信, イベントドリブン, 優先度制御, リアルタイムOS
設問2：図1中の下線①について、(1)、(2)に答えよ。
（2）通知された情報を答えよ。
模範解答
タッチされた座標情報
解説
解答の論理構成
- 【問題文】のタスク説明
表2に“タッチパネル”タスクの機能として
“タッチしたと認識すると起動し、必要情報を入力判定タスクに通知する。”
とあります。①で入力判定タスクが“通知された情報を取得”しているのは、この“必要情報”です。 - その“必要情報”が何か
利用者がどのボタンを押したかを判断するには、画面上のどの位置に触れたかが分からなければなりません。そこで入力判定タスクは、後段で“画面表示タスクに情報要求を通知して、画面情報を取得”し、タッチ位置が“ボタンの座標内か？”を判定しています（図3）。
この流れから、タッチパネルタスクが渡す“必要情報”は“タッチされた位置（座標）”だと分かります。 - まとめ
したがって、①で取得する“通知された情報”は
“タッチされた座標情報”
となります。
誤りやすいポイント
- “ボタン名”や“ボタンID”と答えてしまう
ボタンを特定する情報そのものは画面表示タスクから取得するため、タッチパネルタスク側では不要です。 - “イベント種別（押下・離脱）”と勘違いする
図3のフローでは複数ボタン同時押しや離した瞬間の判定はすでに済んでおり、①で必要なのは座標だけです。 - 図の[ a ]判定内容と混同する
[ a ]は“タッチが有効か？”の判定であり、座標情報とは別概念です。
FAQ
Q: 座標は具体的にどの形式で渡されますか？
A: 問題文では形式までの指定はありません。一般的にはピクセル単位の値です。
A: 問題文では形式までの指定はありません。一般的にはピクセル単位の値です。
Q: マルチタッチをどう扱っていますか？
A: “複数のボタンに同時に触れていた場合、最後に離したボタンをタッチしたと認識する”とあるので、最終的に1点の座標だけが通知されます。
A: “複数のボタンに同時に触れていた場合、最後に離したボタンをタッチしたと認識する”とあるので、最終的に1点の座標だけが通知されます。
関連キーワード: タッチパネル, 座標判定, イベントドリブン, リアルタイムOS, UI入力
設問3：
図3中のaに入れる適切な内容を、15字以内で答えよ。
模範解答
a：画面切替え中か
解説
解答の論理構成
- 【問題文】には、タッチを無効とする条件として
「端末の初期化中又は画面の切替え中に、ボタンにタッチした場合、タッチは無効とする。」
とあります。 - 図3のaは、入力判定タスクが最初に行う判定です。ここでタッチが無効かどうかを判定し、無効なら右分岐して後続処理を行わない流れになっています。
- 初期化中はOSが未起動のため入力判定タスク自体が動作していません。したがって、タスク動作中に考慮すべき“無効条件”は「画面の切替え中」だけです。
- “画面の切替え中”は【問題文】のタスク仕様で
「画面表示タスク…画面切替え中は、切替えフラグを1にする。」
と示されており、入力判定タスクはこのフラグを参照して無効かどうかを判断します。 - 以上より、aには「画面切替え中か」を入れるのが最も適切で、模範解答と一致します。
誤りやすいポイント
- 「初期化中又は画面の切替え中か」と両方を書きたくなる
→ 初期化中はタスク未動作なので、実際に判定すべきは後者のみです。 - 「切替えフラグ=1か」とフラグ名で答えてしまう
→ 設問は“内容”を尋ねており、処理内容を日本語で簡潔に書く必要があります。 - 「画面遷移中か」など別表現にしてしまう
→ 原文表記「画面の切替え中」をそのまま使わないと減点リスクがあります。
FAQ
Q: フラグ値を直接判定しているのだから「切替えフラグが1か」でも良いのでは？
A: 設問はタスク処理の内容を問うており、【問題文】の表現に合わせる方が明確です。「画面切替え中」という言い回しが原文に一致します。
A: 設問はタスク処理の内容を問うており、【問題文】の表現に合わせる方が明確です。「画面切替え中」という言い回しが原文に一致します。
Q: 初期化中のタッチも無効なのに判定しないのはなぜ？
A: 初期化中はOSとタスク起動前なので入力判定タスクが存在しません。したがってタスク内でチェックする必要はありません。
A: 初期化中はOSとタスク起動前なので入力判定タスクが存在しません。したがってタスク内でチェックする必要はありません。
Q: 画面情報を取得する前にこの判定がある理由は？
A: 切替え中であればそもそもボタンの座標が確定していないため、画面情報を取得して比較するまでもなくタッチを無効化できます。
A: 切替え中であればそもそもボタンの座標が確定していないため、画面情報を取得して比較するまでもなくタッチを無効化できます。
関連キーワード: タッチパネル, 画面切替え, イベントドリブン, フラグ管理, 無効判定
設問4：
図3中の下線②の情報は二つあり、一つは画面種別である。もう一つの情報を答えよ。
模範解答
有効なボタンの座標情報
解説
解答の論理構成
- 図3では、入力判定タスクがタッチの有効／無効を判断し、最後に「メインタスクに②情報を通知」と示されています。
- 表2の「入力判定」タスクの説明には、
「“タッチパネルタスクから通知された情報と、画面表示タスクから通知された画面情報を基に、タッチの有効性を判断する。有効な場合、メインタスクに通知する。”」
とあり、通知内容が“有効かどうか”だけではなく、メインタスクが次の処理を決めるための追加情報を含むことが分かります。 - 表2の「画面表示」タスクには、
「“画面種別及びボタンの座標から成る画面情報を、要求元に通知する。”」
と記載されています。よって“画面情報”は「画面種別」「ボタンの座標」の2要素で構成されています。 - 図3中の①②の流れを見ると、入力判定タスクは“画面表示タスクに情報要求を通知して、画面情報を取得した後、①通知された情報と画面情報を比較”しています。ここでボタン位置の当たり判定を行い、押下が有効なら②情報をメインタスクへ通知します。
- ②情報の一つは設問文が示す「画面種別」。残るもう一つは、メインタスクが「どのボタンが押されたか」を理解できる情報、すなわち「ボタンの座標」です。
- 以上より、②のもう一つの情報は「有効なボタンの座標情報」と結論付けられます。
誤りやすいポイント
- 「画面種別だけあればメインタスクは処理できる」と考えがちですが、同一画面内に複数ボタンが存在するため座標情報が必要です。
- 「注文IDや商品名を送るのでは」と混同しやすいですが、注文ID等はメインタスク側で生成・管理するため入力判定タスクから送る必要はありません。
- 「ボタン名を送る」と答えると部分点になりやすいものの、問題文では“座標”という表現が明示されている点に注意が必要です。
FAQ
Q: ボタン名ではなく“座標”が求められる理由は何ですか？
A: 表2に「画面情報＝画面種別＋ボタンの座標」と書かれており、入力判定タスクが扱うのは座標ベースの情報だからです。メインタスクは座標を基にボタン名を解釈します。
A: 表2に「画面情報＝画面種別＋ボタンの座標」と書かれており、入力判定タスクが扱うのは座標ベースの情報だからです。メインタスクは座標を基にボタン名を解釈します。
Q: 入力判定タスクがメインタスクへ“有効/無効”の情報を送らないのですか？
A: 有効でない場合は通知自体を行わない運用です（表2に“有効な場合、メインタスクに通知する”と明記）。したがって②情報は「有効なときに送る詳細情報」のみです。
A: 有効でない場合は通知自体を行わない運用です（表2に“有効な場合、メインタスクに通知する”と明記）。したがって②情報は「有効なときに送る詳細情報」のみです。
Q: “画面種別”と“ボタンの座標”以外に送る可能性のある情報は？
A: 入力判定タスクの役割はタッチの当たり判定までなので、追加情報は不要です。実際の業務データ（注文個数など）は後続の処理で生成されます。
A: 入力判定タスクの役割はタッチの当たり判定までなので、追加情報は不要です。実際の業務データ（注文個数など）は後続の処理で生成されます。
関連キーワード: タッチパネル, イベントドリブン, 座標判定, リアルタイムOS, メッセージ通信
