状態遷移表を使用した設計モデル（拡張階層化状態遷移表）：状態遷移表による設計手法（4）（1/3 ページ）
状態遷移表による設計手法について解説。今回は、前回作成した要求分析モデルを基に、「設計モデル」を作成する。プログラミングを意識したモデリングを行うため、「拡張階層化状態遷移表」による表記を用いる。
はじめに
組み込みソフトウェアが抱える一番の課題は「設計品質の向上」です。本連載の主役「状態遷移表」であれば、“イベント”と“状態”の全ての組み合わせを捉えることができるため、「モレ」「ヌケ」のない品質の良い設計が可能です。そして、不具合発生による手戻りコストの削減や開発効率の向上にも役立ちます。
こうした理由から、組み込みソフトウェア開発の世界では、長年、状態遷移系モデルで設計が行われています。
前回は、“状態遷移表を使用した要求分析モデル”をテーマに、要求仕様から状態遷移表を作成するプロセスを紹介しました。今回は、前回作成した要求分析モデルを基に、「設計モデル」を作成したいと思います。
設計モデルとは、プログラミングを意識し、より良い実装を行うために作成するモデルのことです。
ただし、通常の状態遷移表の表記の場合、プログラミングを意識したモデリングを行うには表現力が足りないので、状態遷移表設計手法では、「拡張階層化状態遷移表」による表記を使用します。
なお、本連載では以下の6つのテーマを順番にお届けしていきます。
- （連載第1回）：状態遷移表設計手法の概要
- （連載第2回）：なぜ状態遷移表を使うと、品質の良い開発ができるのか
- （連載第3回）：状態遷移表を使用した要求分析モデル
- 状態遷移表を使用した設計モデル（拡張階層化状態遷移表）
- 状態遷移表からの実装
- 状態遷移表を使用したテスト手法
今回モデリングするキッチンタイマーの要求仕様範囲
前回は、基本仕様部分の要求分析を行いました。基本仕様では、「分ボタン」「10秒ボタン」「クリアボタン」の3つのボタンを1つにまとめ、時間設定ボタンとして扱いました。
今回は、時間設定ボタンの詳細部分も設計していくため、「分ボタン」「10秒ボタン」「クリアボタン」をそれぞれ別のボタンとして扱っていきます。つまり、これらのボタンが押された際の各処理について、個別に設計していくということです（図1）。
前回作成したキッチンタイマーの要求分析モデル
図2は、前回作成したキッチンタイマーの要求モデルです。
今回は、この図2の要求分析モデルを基に設計モデルを作成していきます。
拡張階層化状態遷移表とは
今回使用する拡張階層化状態遷移表とは、組み込みソフトウェアの開発を行う際に必要な表現を、状態遷移表に追加したものです（図3）。
状態遷移表を機能拡張することにより、通常の状態遷移表では表現しきれないようなものに対応できます。例えば、組み込みソフトウェア開発では、C言語などを用いた構造化プログラミングによる実装がよく行われますが、拡張階層化状態遷移表であれば、構造化表現に対応できます。
さらに、通常の状態遷移表では、状態とイベントの全ての組み合わせを表現するため、表が巨大化してしまいますが、階層化することにより、これを抑制できます。加えて、C言語の関数コールのようなトップダウン設計も可能です。
今回紹介する設計モデル作成手順
図4に、今回紹介する設計モデルの作成手順を記します。流れとしては、イベント部分、状態部分、アクション部分、遷移部分、アクティビティの順に機能拡張を行い、最後に階層化を行います。
イベント部分の機能拡張例
イベントとは、遷移をもたらす外的刺激や内部変化などを表すものです。
イベントの種類には、イベントを待ち続け、イベントが来たらどのようなイベントが来たかを解析するメッセージ型と、常にイベントのポーリング参照を行い、変化を監視するフラグ型が存在します（図5）。さらに、割り込みが発生した際のイベントに対応した割り込み型、デバイスドライバのシステムコールなどに対応した関数コール型などが存在します。
イベント部分では、複数のイベントを1つのまとまりとしてグループ化し、親子関係で表現するなどの機能拡張がなされています。
キッチンタイマーモデルのイベント部分を機能拡張してみよう
それでは、キッチンタイマーモデルのイベント部分を機能拡張してみましょう。
前回作成した要求分析モデルでは、前述の通り、時間設定ボタンを1つのイベントとしてまとめて表現していました。設計モデルでは、各ボタンの処理を全て設計するため、時間設定ボタンを「分ボタン」「10秒ボタン」「クリアボタン」とし、詳細のイベント表現を記述します。図6に変更した状態遷移表を示します。
状態部分の機能拡張例
状態とは、システムの状況や特性を表すものです。
状態には、各状態が排他的に存在している「排他状態」があります。状態部分では、複数の状態を1つのまとまりとしてグループ化し、親子関係で表現するなどの機能拡張がなされています。
親子関係で表現する際、親状態は仮想的に表現し、親自体に状態の実態を持たずにアクションに影響のない「仮想状態フレーム」と、親自体に実態が存在しておりアクションに影響する「実態状態フレーム」が存在します。
実態状態フレームでは、アクションに遷移すると親のアクションを実行後に子のアクションが実行されます。
キッチンタイマーモデルの状態部分を機能拡張してみよう
それでは、キッチンタイマーモデルの状態部分を機能拡張してみましょう。
前回作成した要求分析モデルでは、全て排他状態で、それぞれの状態として表現していました。ここでは、「カウントダウン」状態と、「アラーム音出力」状態を1つのグループとして、仮想状態フレームで表現したものを示します（図8）。
Copyright © ITmedia, Inc. All Rights Reserved.