テストでバグ発見！（7）状態遷移モデルで扇風機シミュレーターのバグを摘出せよ【出題編】：山浦恒央の“くみこみ”な話（149）（5/5 ページ）

提示された仕様とプログラム（バグを含む）から、自身の手でテストケースを設計し、バグを実際に見つけ、バグレポートまでを作成する実践的なシリーズ「テストでバグ発見！」。今回は、扇風機シミュレーターをテーマとする問題の出題編。状態遷移モデルをベースにしたデバッグに取り組もう。

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

※本記事はアフィリエイトプログラムによる収益を得ています

付録その2：状態遷移モデルとは？

1.タクシーと状態遷移モデル

　状態遷移モデルは、サイコロを振り、出た目でコマを動かすすごろくのようなものです。現実の社会で、完全に状態遷移モデルといえるのがタクシーです。

　タクシーでは、運転席の前に「空車」「賃走」「支払い」「迎車」「回送」を赤い文字で表示しています。これが「タクシーの状態」で、すごろくの「場所（区画？）」に相当します。サイコロに相当するのが外部からの入力（外部イベント）で、「道で客が手を挙げている」「目的地に到着した」「本部から出迎えの無線を受信した」「乗客が支払いを完了した」などがあります。タクシーの状態が外部入力により、どのように変化するかを表したのが図10です。

　この図で、円内に書いたのが「タクシーの状態」で、矢印の上に記載したのが「外部からの入力」です。この図を見れば、どんな状態の時に、どんな外部入力が発生すれば、状態がどう変化するかが分かると思います。

図10　タクシーの状態と外部入力［クリックで拡大］

2.表による状態遷移モデルの表現

　上記の「図式表現」によるタクシーの状態遷移を表形式にしたのが表6です（図10と表6は等価で、全く同じことを表現しています。人間には、視覚的な要素がある「図式表現」が分かりやすいのですが、プログラムの中では、表形式で記述します）。

　表の縦方向にはタクシーの状態である「空車」「賃走」「支払い」「迎車」「回送」を並べ、横方向には、全ての外部入力を挙げています。全部で、5×5＝25のマスがあり、複雑そうに見えますが、色を付けた19個のマスは「無効」あるいは「無視」でき、有効なマスは白い6つのマスだけです。

　例えばこの表で、「空車」状態のタクシーは、「目的地到着」や「現金、カードによる支払い」はあり得ず、無視します。「空車」状態で、道に立っている客が手を挙げている場合、停車して客を乗せ、目的地を聞き、そこへ向かいます。状態は「賃走」に変化します。また、「空車」状態で、本部から「渋谷駅前で●●さんが新橋へ行きたいそうです」との無線を受けると、客の名前とピックアップする場所を記憶して目的地に向かいます。この時、タクシーの状態は「迎車」になります。

　このように、全ての状態と全ての外部入力を並べて表を作り、この表をベースにして設計するのが状態遷移モデルによる設計です。基本的に、この表（あるいは、図）ができれば、設計はほぼ完成です。

　このタクシーの状態遷移モデルでは、初期状態を「空車」にし、外部からの入力により、処理が進みます。

表6　タクシーの状態遷移を表形式で表現［クリックで拡大］

3．状態遷移モデルの実装法

　状態遷移モデルを表形式で表現できれば、設計はほぼ終了です。

　状態遷移モデルの実装法ですが、以下のステップで進めます。

1. メインルーティンの中に、状態遷移表を作成します。メインルーティンは、すごろくを制御する「すごろくマスター」となります
2. 現在の状態を示す「ポインタ」を初期状態に設定します（タクシーの場合は、①「空車」となります）
3. 外部入力があれば外部入力を解析し、「状態」と「外部入力」の交点にある四角の中の処理を実行します。実際の状態遷移表では、図11のように、コールするサブルーティンを並べます
4. 処理が終了したら、四角の中に示してある「次の遷移先」へポインタを移動します
5. 四角の中は、さらに状態遷移モデルをネストさせることが可能です。例えば、「支払い」状態では、「現金」「クレジットカード」「デビッドカード」「タクシー券」の支払い方法をそれぞれ「現金による支払い状態」「クレジットカードによる支払い状態」……と4つに分割し、状態遷移モデルの中にこの4つの状態遷移モデルをネストさせることが可能です。

図11　状態遷移モデルの実装法［クリックで拡大］

4．状態遷移モデルの利点

　状態遷移モデルには、以下のように、たくさんの利点があります。非常に強力な技法ですので、可能な限り、状態遷移モデルを使うことをお薦めします。ぜひ、状態遷移モデルを自由自在に使いこなしてください。

1. 視覚的、直感的であり、非常に分かりやすい。
2. 曖昧さがない。
3. 誰が設計しても同じになる。
4. 変更が容易で、拡張性にも富む。

山浦先生の書籍が発売中です！

　前シリーズ「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の書籍「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から好評発売中です。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しています。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。

　前著「ソフトウェア技術者のためのバグ検出ドリル」（2019年11月刊行）も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。

　両書とも興味のある方は、Amazon.comや書店でチェックしてください！

【 筆者紹介 】

山浦 恒央（やまうら つねお）

東海大学 大学院 組込み技術研究科 非常勤講師（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科准教授、2016年より非常勤講師。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。