なぜ状態遷移表を使うと、品質の良い開発ができるのか：状態遷移表による設計手法（2）（2/2 ページ）

状態遷移表による設計手法について解説。第2回では、状態遷移表を利用するとなぜ品質の良い設計・開発ができるのか、その理由を詳細に説明する。

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

状態遷移表設計手法

　このように、“不具合が発見されてから、それを修正する”ということを繰り返すのではなく、こうした不具合を設計段階で早期に発見し、対応できる手法はないのでしょうか――。

　そうです。実はこうした要求に応えられるのが、状態遷移表設計手法なのです。

　それでは、状態遷移表設計手法について解説していきます。状態遷移表設計手法を行うには、まず、適切なイベントと状態を抽出することが重要です。イベントの抽出については、先ほど説明をしていますので、以降では、状態を抽出する方法を説明していきます。

状態の抽出方法

　シーケンス図を参照すると、Cデバイスコントロールタスクに対する入力イベントは、「メイン管理タスクからの送信要求」「Cデバイスドライバからの送信完了」「タイマからのタイムアウト」の3つであることが分かります。そして、そこには、メイン管理タスクからの送信要求が来る前の「送信要求待ち」と、送信要求を受け、Cデバイスドライバからの送信完了イベントを待っている「送信中」という2つの状態が存在しています（図9）。

　このように、同じ“イベント待ち状態”であっても、メイン管理タスクから送信要求イベントを待っている「送信要求待ち」状態と、Cデバイスドライバから送信完了イベントを待っている「送信中」状態は、別の状態であることが分かります。

図9　Cデバイスコントロールタスクの状態について

状態遷移図で表現した場合

　それでは状態の抽出ができましたので、「状態遷移図」を作成してみましょう。

　まず、「送信要求待ち」と「送信中」の2つ状態を記します。そして、送信要求待ち状態で、メイン管理タスクからの送信要求イベントが発生した場合は、ドライバにデータを送信し、送信中状態に遷移します。送信中状態で、ドライバからの送信完了イベントが発生した場合は、メイン管理タスクに正常完了を返し、送信要求待ち状態に遷移します。また、送信中状態で、タイマからタイムアウトイベントが発生した場合は、メイン管理タスクに異常完了を返し、送信要求待ち状態に遷移します（図10）。

図10　状態遷移図

状態遷移表で表現した場合

　次に、「状態遷移表」で表現してみましょう。

　表上部の状態部分に「送信要求待ち」と「送信中」の2つを記述します。また、表左部にメイン管理タスクからの「送信要求イベント」、ドライバからの「送信完了イベント」、タイマからの「タイムアウトイベント」の3つを記述します。

　そして、送信要求待ち状態で、メイン管理タスクからの送信要求イベントが発生した場合は、「ドライバにデータを送信し、送信中状態に遷移する」と記述します。送信中状態で、ドライバからの送信完了イベントが発生した場合は、「メイン管理タスクに正常完了を返し、送信要求待ち状態に遷移する」と記述します。また、送信中状態で、タイマからのタイムアウトイベントが発生した場合は、「メイン管理タスクに異常完了を返し、送信要求待ち状態に遷移する」と記述します（図11）。

　状態遷移表は、状態とイベントの全ての組み合わせを表現します。これを踏まえ、図11をご覧ください。いかがでしょうか。送信中状態にメイン管理タスクからの送信要求イベントが発生した場合、そして、送信要求待ち状態にドライバからの送信完了イベントが発生した場合、同じく送信要求待ち状態にタイマからのタイムアウトイベントが発生した場合の3つの処理を考えずに設計していることが明確になります。

図11　状態遷移表

「モレ」「ヌケ」の発見による対応は、設計段階で行える

　送信中状態にもかかわらず、再びメイン管理タスクから送信要求イベントが発生した場合は、「メイン管理タスクにビジーを返す」処理を追加できます。つまり、設計段階で連続して送信要求イベントが発生した際の対応を考えて設計することができるのです。

　また、送信要求待ち状態で、ドライバからの送信完了が来た場合は「無視してよい」。そして、送信要求待ち状態で、タイマからのタイムアウトが発生するということはタイマ起動前ではあり得ないため「不可である」など、状態とイベントの全ての組み合わせを、「モレ」「ヌケ」なく設計できます（図12）。

図12　「モレ」「ヌケ」の発見による対応は、設計段階で行える

開発コストにおける効果

　最終的な実機試験において、“不具合が発見されてから、それを修正する”という行為を繰り返す手戻りは大きなコストとして表れてきます。

　また、図13を参照して頂ければ明確ですが、修正後は再び、実装（プログラミング）、テストなどを繰り返し実施する必要があります。そのため、不具合が発生してから修正するのではなく、状態遷移表設計手法を使用して、不具合が発生しない設計を行うことが大切です。

図13　不具合による手戻りは大きなコストとなる

今回のまとめ

　きちんと設計を行わず、“不具合が発見されてから、それを修正する”という開発を繰り返す手戻りは大きなコストとなります。

　状態遷移表は、イベントと状態の全ての組み合わせを考えて設計するため、処理を整理して、設計することができます。そして、設計時に「モレ」「ヌケ」を発見できるため、品質の良い開発が行えます。また、不具合発生による手戻りも削減できるため、開発効率も向上します。こうしたことから、組み込みソフトウェアの開発では、長年、状態遷移系モデルで設計が行われています。

　さて、今回は“なぜ状態遷移表を使うと、品質の良い開発ができるのか”を紹介しました。次回は「状態遷移表を使用した要求分析モデル」をテーマに、実際に要求仕様から状態遷移表を作成するプロセスを見ていきたいと思います。お楽しみに！ （次回に続く）

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

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