基本情報技術者 2010年 春期 午前（科目A） 問48
問題文
設計するときに、状態遷移図を用いることが適切なシステムはどれか。
選択肢
ア：月末及び決算時の棚卸資産を集計処理する在庫棚卸システム
イ：システム資源の稼働状況を計測し、レポートとして出力するシステム資源稼働状況計測システム
ウ：水道の検針データから料金を計算する水道料金計算システム
エ：設置したセンサの情報から、温室内の環境を最適に保つ温室制御システム（正解）
🔒 解説は解答すると表示されます
状態遷移図による制御システム設計【午前解説】
正解の理由
正解は エ です。温室制御システムは温度・湿度などのセンサ値やタイマー、外的イベントに応じて「監視」「加熱」「冷却」「加湿」「警報」など明確な状態を取り、それらの間をイベントで遷移します。状態ごとに入力に対する応答や出力（アクチュエータ操作）が異なるため、状態遷移図（ステートマシン）は設計・検証・テストに非常に適しています。
一方、ア（棚卸集計）、イ（資源稼働状況計測）、ウ（水道料金計算）は主にバッチ処理や時系列データ集計、数式による計算処理が中心で、状態遷移図よりフローチャートやデータフロー図、シーケンス図が適切です。
一方、ア（棚卸集計）、イ（資源稼働状況計測）、ウ（水道料金計算）は主にバッチ処理や時系列データ集計、数式による計算処理が中心で、状態遷移図よりフローチャートやデータフロー図、シーケンス図が適切です。
解法ステップ
- システムの振る舞いが「状態（モード）」によって明確に変わるか確認する（例：監視 ⇄ 加熱 ⇄ 冷却）。
- イベントや条件（センサ閾値、タイマー、外部コマンド）が存在し、それで遷移するかを確認する。
- 履歴依存（前の状態によって挙動が変わる）や時間遷移（一定時間後に遷移）があるかを確認する。
- 上記が当てはまれば状態遷移図／ステートチャートを選択、当てはまらなければフローチャートやデータフロー図を検討する。
- 必要なら状態図とシーケンス図やアクティビティ図を併用して振る舞いとデータの流れを補完する。
選択肢別の誤答解説
- ア: 月末や決算時に一括で集計する在庫棚卸システムはバッチ処理が主体で、処理の手順・データ依存を示すフローチャートやデータフロー図が適切です。状態遷移図は過剰です。
- イ: システム資源の稼働状況計測システムは測定→蓄積→レポートの周期処理が中心で、時系列データ解析や監視ダッシュボード設計が重要です。モードごとの振る舞い変化が主要でないため状態図は必須ではありません。
- ウ: 水道検針データから料金を計算するシステムはデータ取込→検針補正→課金計算→請求処理といった処理フローが主体で、ルールや計算式の管理が中心です。状態遷移図よりフローチャートやルール記述の方が有効です。
- エ: 温室制御システムはセンサ値とイベントにより明確な制御モードが遷移するため、状態遷移図でモデル化すると仕様設計・テストケース設計がしやすく最適です。
よくある誤解
- 状態遷移図は「制御系のみ」に限定される：誤り。制御系に最も有効ですが、ユーザセッション管理やプロトコル仕様など状態依存の振る舞いがある領域でも有効です。
- すべてのリアルタイムシステムで常に必要：誤り。リアルタイム性があっても単純監視・ログ収集のみなら状態遷移図は過剰設計になります。
- バッチ処理も状態図で表現すべき：誤り。バッチは処理フローやデータの流れを示す図の方が設計効率が良いことが多いです。
補足コラム
状態遷移図（ステートマシン）はUMLの一要素で、状態（state）、遷移（transition）、イベント（event）、ガード条件（guard）、アクション（action）を表現します。使用例として温室制御の簡易状態を示すと：
- 状態例：Monitoring、Heating、Cooling、Humidifying、Alarm
- 遷移例：Monitoring → Heating [温度 < 下限] / start_heater()
- タイマー遷移や優先度（例えば異常時は常にAlarmへ移る）も表現可能です。
短い擬似記述例：
Monitoring --[temp < T_low] / start_heater()--> Heating
Heating --[temp >= T_target] / stop_heater()--> Monitoring
こうした図によりエッジケース（同時イベント、ヒステリシス、故障時の遷移）を洗い出せます。
FAQ
Q: 状態の粒度はどのくらいにすべきですか？
A: 粒度は「設計や検証で区別が必要な振る舞いの単位」に合わせます。細かすぎると図が複雑になり、大きすぎると遷移条件が不明確になります。まずは高レベルで定義し、必要に応じてサブステートに分割します。
A: 粒度は「設計や検証で区別が必要な振る舞いの単位」に合わせます。細かすぎると図が複雑になり、大きすぎると遷移条件が不明確になります。まずは高レベルで定義し、必要に応じてサブステートに分割します。
Q: 複雑な制御ロジックは状態遷移図だけで表現できますか？
A: 基本的な挙動は表現可能ですが、複雑なデータ処理や並列処理はシーケンス図やアクティビティ図、フロー制御と組み合わせると効果的です。
A: 基本的な挙動は表現可能ですが、複雑なデータ処理や並列処理はシーケンス図やアクティビティ図、フロー制御と組み合わせると効果的です。
Q: 状態遷移図とフローチャートの使い分けは？
A: 状態中心（モード、イベント駆動、履歴依存）は状態遷移図、手続き中心（データ処理の逐次手順、集計）はフローチャート／データフロー図が適切です。
A: 状態中心（モード、イベント駆動、履歴依存）は状態遷移図、手続き中心（データ処理の逐次手順、集計）はフローチャート／データフロー図が適切です。
関連キーワード: 状態遷移図、ステートチャート、イベント駆動、リアルタイム制御、センサ制御、モード設計、UML、フローチャート、データフロー図、ヒステリシス検討
\ せっかくなら /
基本情報技術者を
クイズ形式で学習しませんか？
クイズ画面へ遷移する→
すぐに利用可能！