状態遷移図とは?

状態図または状態遷移図は、ソフトウェアやシステムの状態が、条件やイベントによって変化する様子を図的に表現したものになります。統一モデリング言語 (UML) の行動図の一種です。

例えば電子レンジを使用する際は、停止状態の電子レンジの電源をオンにして初めて動き出します。その後、開始ボタンを押し、温めます。一定時間経過した、または既定の温度に到達したら、温めを停止します。電源をオフにすると、ボタンを押しても動作しません。

この電源のオン・オフや動作モードの切り替えが図中のイベントに当たり、切り替わった後の電子レンジがどうなったかを示すのが状態となります。この一連の動作現象を、一目でわかりやすくしたのが状態遷移図です。

状態遷移図を作るメリットは？

直観的に仕様を理解しやすい

状態遷移図は直観的に仕様を理解しやすく、開発に携わるメンバー間で認識齟齬が発生しにくいという利点があります。

仕様書では、文章で遷移を表現するため、文章を読み解かなければ動作をイメージすることができませんが、状態遷移図では流れをわかりやすく一覧することができ、プロジェクトのメンバー間で作業の全体的なイメージを合わせることが可能です。

また、何か不具合が発生した際に、状態遷移図を参照することで不具合の原因を特定しやすくなります。

仕様変更にも対応しやすい

急な仕様変更の要望があった場合でも、状態遷移図上で修正することで、変更箇所をメンバー間ですぐに把握できます。

分析、設計の段階で状態遷移図を作成して、それを実現する機能構築を進めるようにすると、仕様の漏れや抜けを発見しやすくなるのも大きなメリットです。

状態遷移図の設計

状態遷移図の基本要素

状態遷移図には、決まった書き方があります。基本的には、以下の3ステップで作業を進めます。

1. 状態を書く
2. 状態から状態へ遷移する矢印を追加する
3. イベントを矢印のそばに書く

状態は四角形の箱で表現します。そこに状態名を書き入れます。

次に遷移を矢印で表現します。状態から状態へ繋ぐように線を引きます。ここで、矢印の向きは必ず1方向のみにします。もし互いを遷移で結ぶことがあっても、必ず1方向の矢印を2本使います。イベントを記入するため、矢印は1方向で書く必要があります。

次に、遷移の矢印のそばに、どういうことが起きて、状態が遷移したかというきっかけとなる「イベント」を記入します。さらに遷移時に行われる動作（アクション）があれば記入します。

状態遷移図を作るツール

MathWorksでは、Stateflow^®という状態遷移図を設計するためのツールを用意しています。Stateflowを使うと、状態、遷移、イベントの記述を簡単に行うことができ、書いた状態遷移図そのままの形で実行し、動作を確認することができます。

状態遷移図を作成するデメリットとして、ソースコードと別に状態遷移図を作成するため、その二つを同時にアップデートし続けることが手間であり、管理が難しくなる、また両者の間で齟齬が発生する、という面があります。

しかし、Stateflowを使えば、状態遷移図そのままの形で実行でき、かつその図からコード生成することもできます。従って、管理するものは状態遷移図一つでよくなり、齟齬が発生することもありません。

状態とイベントの抜け漏れをなくす状態遷移表

状態遷移図を作成する際に見逃せないポイントがあります。もし要素が漏れていたり、不十分な図を作成してしまったりすると後で修正するのが難しくなります。

この時、状態遷移を表形式で表現する「状態遷移表」が便利です。状態遷移表は列にイベント、行に状態を入れて作ります。想定される全ての状態とイベントを項目に当てはめ、その遷移先を書き込みます。

Stateflowでは、状態遷移図モデルと状態遷移表モデルを相互に変換することができます。可視化したいポイントに合わせて、表現を切り替えながら設計を進めることができます。

状態遷移図設計のポイント

開発の後工程で不具合が発覚してしまうと、余計な手戻りコストが発生し、開発効率が低下します。そのためには設計の初期段階で状態遷移表と状態遷移図を同時に作成し、全ての項目を挙げていくことが大切です。

また、状態遷移図は一度作成したら、それで終わりということはありません。実際の作業を行っていると、どうしても当初想定していなかった事態が発生することがあります。

状態遷移図に新たに発生した状態などを書き加えて、更新していきましょう。Stateflowを使うと、状態遷移図、状態遷移表の表現そのままの形で実行し、結果を確認することができるため、手戻りの工数も最小化できます。

状態遷移図の表現スタイル

状態遷移図は出力が定義される場所に応じて、Moore と Mealy の 2 つのタイプに分類されます。

状態遷移図の Moore 実装

このタイプの状態遷移図では、出力はシステムの状態にのみ依存し、ステートアクションとして定義されます。状態の移行方法にかかわらず、ステートアクションは同じです。たとえば、図8の状態遷移図では、Heating からの出力は、Idling または OFF のどちらの状態からの遷移かにかかわらず同じままです。

状態遷移図の Mealy 実装

このタイプの状態遷移図では、出力はシステムの状態だけではなく、システムへの入力にも依存します。図10 の状態遷移図に示すように、Mealy 実装における出力は、遷移で定義されます。

Mealy 実装を使用すると、出力を更新するためのループを追加することで、状態遷移図を再編成し簡略化することができます。この実装は、設計の複雑度が増すほどメリットが大きくなります。

Mealy型と Moore型のいずれも、そのシンプルさと明確さから広く利用されており、同じ状態遷移図の中に 2 つのスタイルが混在していることもよくあります。

ステートチャート: 拡張された状態遷移図

設計する機能が複雑になると、より複雑な状態と遷移の表現が必要になります。この場合、状態遷移を階層的に表現することで、設計を細分化することができ、機能を分かりやすく表現できます。

たとえば、図12 の状態遷移図では、親状態である Baking に、子状態である Heating、Idle、および関連する状態遷移図が含まれます。

階層、並列処理、およびブロードキャスト機能を備えたステートチャートは、状態遷移図を複雑にすることなく複雑なシステムの機能性を表現するのに役立ちます。

Stateflowを使用した状態遷移図設計ワークフロー

Stateflow^® を使用すると、シンプルな状態遷移図から開始し、オートマチック トランスミッション、ロボットシステム、携帯電話などの動的システムの複雑なロジックをモデル化するための状態遷移図を構築することができます。この複雑なロジックの用途には、以下のようなものがあります。

• 監視制御
• 障害管理
• タスク スケジューリング
• インターフェイス ロジック
• 通信プロトコル

作成された状態遷移図を実機に実装する場合には、Simulink^®の自動コード生成機能を使用して、状態遷移図を C、HDL、または PLC コードに変換することができます。

これらの高度なテクニックを含む、状態遷移図のモデル化に関する詳細については、Stateflow と Simulink を参照してください。 セキュリティシステムのモデル化の例では、Stateflow における状態遷移図の階層化、並列処理、イベント ブロードキャストについて説明しています。

状態遷移図とモデルベース開発・モデルベースデザイン

モデルベース開発では、仮想モデルを中心に開発プロセスを進めることで、複雑なシステムを効率よく開発できます。MATLAB^® および Simulink を用いることで開発サイクルを短縮し、開発時間を 50% 以上削減することができます。

このモデルベース開発において、ハードウェア、ソフトウェアシステムを「モデル」という形で分かりやすく表現し、実機を作る前にシミュレーションします。Stateflowを使えば、状態遷移図そのままの形でモデルを作ることができ、そのモデルを使ってシミュレーションを行うことができます。まさに、Stateflowはモデルベース開発のためのツールであると言えます。

モデルベース開発の詳細については、モデルベースデザイン (モデルベース開発、MBD) もご参照ください。

状態遷移図のテスト

状態遷移図で設計する機能の多くは、多数の状態と複雑な分岐条件を持つシステムになります。このようなシステムが想定通り動くかどうか、きちんとテストするには非常に工数がかかります。しかし、Stateflowで設計した状態遷移図であれば、Simulink Coverage™ やSimulink Test™ を用いることで、少ない工数で、かつ確実にテストを行うことができます。

例えば、以下の図13のように、行ったテストがどれだけ網羅的であったかを色分けすることができます。緑は条件を満たして通過した遷移、赤は条件を満たしていないものになります。

全てを緑にすることができれば、そのテストは状態遷移図の全ての条件をチェックしたということになります。