状態遷移表を使用した要求分析モデル：状態遷移表による設計手法（3）（3/3 ページ）

実際に、要求仕様から状態遷移表を作成するプロセスを紹介する。モデリングを行いながら、要求仕様書で定義されていない曖昧な部分を検討し、明確化。上流工程の段階でモデルを洗練しておくことで、無駄のない最適なソースコードを作成できる。

[塚田 雄一 キャッツ，＠IT MONOist]

「一時停止」状態で「時間設定ボタン」イベントが入った場合の処理を検討

　次に、「一時停止」状態で、「時間設定ボタン」イベントが入力された場合の処理を検討してみましょう。

　“処理なし（無視）”とすることもできますが、これでは一時停止中に、キャンセルや時間変更を行うことができません。一時停止中に、キャンセルや時間変更が行えた方が便利であるため、今回は「時間設定」状態の処理と同じく、「一時停止」状態においても、「カウントダウン時間設定」処理を入れます（図21）。

図21　要求仕様の未検討項目「モレ」「ヌケ」を発見（4）

「アラーム音出力」状態で「時間設定ボタン」イベントが入った場合の処理を検討

　次に、「アラーム音出力」状態で、「時間設定ボタン」イベントが入力された場合の処理を検討してみましょう。

　「スタートストップボタン」イベントと同様に、「アラーム音停止」処理を行うことも検討しましたが、今回は、“処理なし（無視）”とすることにします（図22）。

図22　要求仕様の未検討項目「モレ」「ヌケ」を発見（5）　※処理なし（無視）の記述は、「／」と記述します

状態遷移表を洗練

　最後に、ここまで作成した状態遷移表を参照して、モデルを洗練してみましょう。

　状態遷移表を参照すると、「時間設定」状態の処理と「一時停止」状態の処理は、全て同様の処理であることが分かります。これらの処理を1つの状態としてまとめられないか検討した結果、まず「一時停止」状態を削除。そして、「カウントダウン」状態で「スタートストップボタン」イベントが入力された場合に、「時間設定」状態へ遷移するよう変更することにしました（図23）。

図23　要求仕様の未検討項目「モレ」「ヌケ」を発見（6）

参考：最終的な状態遷移図で表現した要求分析モデル

　参考までに、図24に最終的な状態遷移図で表現した要求分析モデルを記します。

　「一時停止」状態を削除し、「カウントダウン」状態で「スタートストップボタン」イベントが発生した際に、「時間設定」状態へ遷移する旨を記述しています。

図24　参考：最終的な状態遷移図で表現した要求分析モデル

状態遷移図／表で要求分析を行った結果と効果

　以上、状態遷移図と状態遷移表で要求分析を行ってきました。ここでは、その結果と効果を見てみましょう。

　状態遷移図は遷移による状態の流れが明確となります。今回は「一時停止」状態から「カウントダウン」状態へ復帰した際の遷移が不足していることが分かりました。

　一方、状態遷移表は全てのイベントと状態の組み合わせが明確となります。今回は、「カウントダウン」状態、「一時停止」状態、「アラーム音出力」状態で、「時間設定ボタン」イベントが入力された際の処理について、その要求仕様がきちんと定義されていなかったことが分かりました。

　状態遷移表を使用することにより、全てのイベントに対するアクション（処理）を、モレ・ヌケなく定義することが可能になります。そして最終的には、状態、遷移、アクションなどの全体を考慮してモデルを洗練させることにより、無駄な処理を削減でき、最適化することが可能となります。

実行順序	実行プロセス（作業）	効果	成果物
1	イベント抽出	イベントの明確化	イベントリスト
2	状態抽出	状態と遷移の明確化	状態遷移図
3	遷移モレ確認	処理の流れを明確にし、遷移モレの確認	状態遷移図
4	状態遷移図の洗練	モデルの最適化を行い、無駄な処理を削除	状態遷移図
5	状態遷移表に変換	イベントと状態の全ての組み合わせを明確化	状態遷移表
6	不明確な要求仕様検討	要求分析を行い、不明確であった部分の明確化	状態遷移表
7	状態遷移表の洗練	モデルの最適化を行い、無駄な処理を削除	状態遷移表
表1　要求分析モデリング作業と効果のまとめ

コラム：ツールによるシミュレーション

モデルベース開発の効率を上げるためには、ツールの活用が欠かせません。状態遷移図の作成、状態遷移表への変換などについては、専用ツールを使用すると容易に行えます。また、シミュレーションの実行を行い、PC上で動作確認を行うことも可能になります。

参考ツール：状態遷移表設計ツール「ZIPC」

今回のまとめ

　今回は、“状態遷移表を使用した要求分析モデル”をテーマにお届けしました。実際に、要求仕様から状態遷移表を作成するプロセスを紹介するため、モデリングを行いながら、要求仕様書で定義されていない曖昧な部分について検討を行い、明確にしました。要求仕様が不明確なまま開発を進めてしまうと、結局、手戻りが発生してしまいます。

　また、今回のモデリングを通じて、序々にモデルが洗練されていく様子がお分かりいただけたかと思います。上流工程でモデルを洗練しておくことにより、下流工程では、洗練されたモデルを参考にしてソースコードを作成することが可能になります。そうすることにより、下流工程においては、無駄のない最適なソースコードを作成することが可能となります。

　さて次回は、「状態遷移表を使用した設計モデル（拡張階層化状態遷移表）」をテーマに、今回作成した要求分析モデルを基に、拡張階層化状態遷移表設計手法を使用し、設計モデルを作成するプロセスを紹介したいと思います。お楽しみに！ （次回に続く）

組み込みモデリング コーナー

＞＞コーナーTOPはこちらから