テストでバグ発見!(9)状態遷移図への機能追加の勘所は「混ぜるな、危険!」:山浦恒央の“くみこみ”な話(151)(3/4 ページ)
提示された仕様とプログラム(バグを含む)から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見!」。今回は、前回までの題材だった扇風機シミュレーターを使って、状態遷移図への機能追加を行う。その勘所は「混ぜるな、危険!」だ。
5.解答
モデルの記述方法には「厳密な正解」は存在しませんが、筆者が意図した解答例を示します。
5.1 筆者の意図
この問題を学生に出題する場合、恐らく、「アイドルモード」「運転モード(弱)・(中)・(強)」「減速モード」のそれぞれ5つに首振りモードを入れる可能性があります。例えば、運転モードに絞って考えてみましょう。
図5が記述例です。各処理の右上にある「1」「2」は実行順序を表しています※1)。このように、運転モードの中に首振りモードが入り込み、モードの入れ子状態を作ってしまう可能性があります。
※1)書き方はツールや技法によってさまざまなので、もしかすると読者の皆さまの書き方と違うかもしれません。
プログラムでイメージすると以下のようになります(運転モードのみ記述)。
while(1) { switch(モード){ case 運転: //処理 //運転処理 //首振り処理 break; } }
このように記述することは間違いではありませんが、状態遷移図や処理がどんどん複雑になってしまいます。
5.2 筆者のオススメの書き方
5.1の記述方法も間違いではありませんが、各状態のそれぞれに首振りモードが付いてしまうため、複雑で分かりづらく、手間がかかります。そこで、「アイドル・運転・減速」を実行する状態遷移図とは別の状態遷移図を別途作ります。プログラムでイメージすると、以下のようになります。
while(1) { //アイドル・運転・減速モード switch(モード){ case 運転: //処理 //運転処理 break; //・・・ } //首振りモード switch(首振りモード){ case 首振りOFF: //首振りOFF処理 break; case 首振りON: //首振りON処理 break; } }
後段にプログラムを追加しているように、アイドル・運転・減速モードとは別のものとして実装します。結果として、機能追加がやりやすく、図と表も分かりやすくなります。状態遷移図と状態遷移表を下記に示します。
このように、基本機能(アイドル・運転・減速モード)と分離した状態遷移図・状態遷移表を記述することで、より簡単に機能追加できます。
Copyright © ITmedia, Inc. All Rights Reserved.