状態遷移表からの実装：状態遷移表による設計手法（5）（3/3 ページ）

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

ステートドリブン型（S型）

　ステートドリブン型は、先に状態を解析するため、プログラムの1箇所で全ての状態を解析します。そして、状態を解析した後に、状態ごとに必要なイベントのみを解析します。例えば、アクションセルが“無視”や“不可”となるイベントのアクションについては解析を行いません。

　主に、メニュー画面などのある画像処理分野では一般的な構造であり、多く使用されています。例えば、メニューA表示状態で、イベントXが入力された場合と、メニューB表示状態でイベントXが入力された場合などは、表示しているメニュー画面（状態）が確定していないと、イベントの意味が明確となりません。従って、最初に現在表示されているメニュー画面などの状態を解析した後に、メニューに応じた入力イベントを解析することが多く、そのようなシステムにはステートドリブン型の実装が適しています。

　以下に、ステートドリブン型の特徴を記します。

• 常に全ての状態を解析する
• 必要なイベントのみを解析する
• アクションセルが“無視”や“不可”となるアクショセルのイベントの解析は行わない

図10　ステートドリブン型（S型）で実装した例

キッチンタイマーをステートドリブン型（S型）で実装

　それでは、状態遷移表からステートドリブン型で実装したフローチャートを作成してみましょう。

　まずメインループで、「時間設定状態」「カウントダウン状態」「アラーム音出力状態」の3つの状態を全て解析します。この時、有効となる状態は1つのみです。つまり、メインループで状態の切り替えを行い、状態が遷移した際に、有効となるループを切り替える構造になります。そして、以下のように、状態ごとに必要なイベントを解析し処理を行います。

（1）「時間設定状態」のループにおいて、「時間設定ボタン」イベントがヒットした際には「カウントダウン時間設定」処理を行い、「スタートストップボタン」イベントがヒットした際には「カウントダウン開始」処理を行い、「カウントダウン状態」へ遷移します。

（2）「カウントダウン状態」のループにおいて、「スタートストップボタン」イベントがヒットした際には「カウントダウン停止」処理を行い、「時間設定状態」へ遷移します。「カウントダウン終了」イベントがヒットした際には「カウントダウン停止＆アラーム音出力」処理を行い、「アラーム音出力状態」へ遷移します。

（3）「アラーム音出力状態」のループにおいて、「スタートストップボタン」イベントがヒットした際には「アラーム音停止」処理を行い、「時間設定状態」へ遷移します。

　状態については、イベントドリブン型と同様に、状態変数を用意しておき、遷移する際は状態番号（時間設定状態（0）、カウントダウン状態（1）、アラーム出力状態（2））を設定します。そして、現在の状態を参照する際は、状態変数の内容を参照します。つまり、複数のマイナーループで状態を表現するのではなく、1つのメインループで表現し、状態を状態変数で切り替える構造になります。

図11　キッチンタイマーをステートドリブン型（S型）で実装

状態遷移表からステートドリブン型（S型）で実装した場合と、基本仕様から直接実装した場合の比較

　それでは、状態遷移表を作成し、その後、ステートドリブン型で実装した場合と、基本仕様から直接実装した場合を比較してみましょう。

　状態遷移表からステートドリブン型で実装した場合の特徴は、以下の通りです。

• “マイナーループ”が存在せず、1つのメインループ構造になっている
• 全ての状態を1箇所で参照している
• 状態変数の切り替えにより状態遷移を行っているため、順序性のない状態遷移にも適している

　状態遷移表からステートドリブン型で実装した場合、状態は全て1箇所で管理されるため、状態の解析モレはなくなり、品質が向上します。また、状態を追加するなどの変更の際も、1つのメインループに状態を追加すればよいため、メンテナンス性も向上します。そして、状態遷移表から実装したフローチャートは、もともと状態を意識した構造となっており、下部から上部へ移動するなど順序性のない状態遷移部分についても容易に実装することが可能です。

図12　状態遷移表からステートドリブン型（S型）で実装した場合と基本仕様から直接実装した場合の比較

コラム：構造化プログラミングとは

　構造化プログラミングは、階層的に抽象化されたプログラムの組み合わせとして、プログラムを記述する手法であり、「順次」「選択」「反復」の3種類の制御構造のみを用いてプログラミングを行います。

　構造化プログラミングの目的は、品質の良いプログラミング構造を実現することであり、無条件に、指定されたラベルや行番号にジャンプ（跳ぶ）するGOTO文を使用しません。GOTO文を使用すると、動作するシーケンスが複雑になるため、動作品質の保証が困難となります。

　基本仕様から直接実装した場合のフローチャートにおいて、下部のループから上部のループにジャンプ（跳ぶ）するGOTO文を使用すれば、容易に実装できますが、上記の理由から、構造化プログラミングではGOTO文を使用せずに、フラグや変数でループを切り替えます。

図13　構造化プログラミングとは

今回のまとめ

　以下に、「基本仕様から直接実装」「状態遷移表からイベントドリブン型で実装」「状態遷移表からステートドリブン型で実装」を比較した表を記します（表1）。

表1　「基本仕様から直接実装」「状態遷移表からイベントドリブン型で実装」「状態遷移表からステートドリブン型で実装」を比較

　「基本仕様から直接実装」を行った場合は、イベント参照、状態参照など同じ処理があちこちに点在しています。それに比べ、状態遷移表は、イベントと状態を整理して考えられ、その後実装を行えば、イベントや状態などの処理をまとめて実装することが可能となります。また、状態遷移表から実装を行う手法として、イベントドリブン型とステートドリブン型が存在します。システムの性質上イベントによって処理を変えることが多く、イベント主体の処理であれば、イベントドリブン型で実装を行い、状態によって処理を変えることが多く、状態主体の処理であれば、ステートドリブン型で実装を行う方が適しています。

---

　さて、今回は“状態遷移表からの実装”について解説しました。状態遷移表を用いると「モレ」「ヌケ」のない設計が行えるため、要求分析のフェーズで、検討すべき仕様が明確となります。また、状態とイベントの組み合わせが整理された状態遷移表（設計書）を作成し、それを基に、イベントドリブン型あるいはステートドリブン型で実装を行うことにより、変更が容易なソフトウェアを実現できるため、メンテナンス性が向上します。今回の内容から、状態遷移表設計手法が、設計レベルだけではなく、実装レベルにおいても、品質を向上させるために有効な設計手法であることが理解できたのではないでしょうか。

　さて、次回は「状態遷移表を使用したテスト手法」をテーマに、状態遷移表から試験項目、試験シナリオを作成する手法を紹介したいと思います。お楽しみに！ （次回に続く）

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

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