SS1の日記： 組込システムのための状態遷移図

組込システムのための状態遷移図(UML)の書きかた。

組込システムの開発では，ソフト担当は，ハード仕様と要求仕様を貰ってから，開発に着手することになる。そこではじめに，状態遷移図を作ることが多い。組込屋さんは状態遷移図さえできれば，プログラムは出来たも同然という気分になる。状態遷移図を作ると，プログラムの挙動を明解に定義できるためだ。

私が書くときの基本的な指針はつぎのとおり。

１．図は，A4一枚にまとめる。
２．アクションの矢印が交わってはいけない。
３．初期状態は左上から，正常パターンは時計回りに進行する。

状態遷移表(ZIPCのEHSTM)は，UML形式に慣れてからは，あまり使わなくなった。表形式のもっとも大きい欠点は構造化されてないこと。遷移番号あるいはラベル名でジャンプするのは，BASIC，アセンブラの時代に逆行するようなものだ。
ただし，リバースエンジニアリングしたいときに使うと，表形式は便利だ。というのも構造化されていない状態遷移は，遷移図では記述が困難なためだ。ただし，いったん遷移表に落とされた状態遷移は，ダイクストラが構造化プログラミングで証明したように，順次，集約，循環で必ず構造化が可能である。例外は，外部の事象として考えれば良い。（コンセントが抜けた。など）。そのとき状態は，保持されるか破棄されて，例外アクションが実行される。

こうして状態遷移を構造化しつつ，A4一枚の図にまとめるのは，かなり大変な作業だ。新たに状態を追加したり，例外を発見すると一気に図が複雑になり，収集がつかなくなることもある。この場合，いくつかのアプローチがあると思う。

１．とりあえず大きい紙に遷移図を書いてみる。
２．複数の状態に共通するアクションは，グループ化して，グループのアクションとして記述する。
３．同じ状態遷移パターンが何箇所も出るときは，サブ状態として階層化する。
４．それでもダメなとき・・・

この4番目のそれでもダメなときを見つけるのが，とても重要なのである。どんなにがんばっても，図がぐじゃぐじゃになるとしたら。それはおそらく，並列した複数の状態遷移が重ね合わされているためだ。これを発見したら，二つの有限状態機械(FSM)が相互に通信するモデルを考えて欲しい。それを見つけるのがオブジェクト指向分析の目的でもあるわけだ。

できあがった状態遷移は・・・

さて，苦労して状態遷移図が出来上がったら，関係者全員を集めてレビューしよう。
レビューのやりかたは簡単だ。まず始めに状態遷移図を配り，もっとも基本的な動作を順を追って説明する。それが終わったら，例外パターンや意地悪なパターンを探す。一度レビューをするとたいてい一つは抜けがみつかるものだ。また，ときにはそれで，「これじゃ動かない」というのが判明することもある。そのときは，何が出来ないかを明確にした上で，新たに遷移図を書き起こすことになる。

レビューを通すと詳細設計／実装作業に入るが，遷移図の作成者と実装担当が異なることが良くある。それだけわかりやすいのが，状態遷移図のメリットでもある。実装担当のスキルにもよるが，詳細設計は抜きに，そのまま渡すことが多い。ここからが面白いのだが，実装担当者によって，実装方法がまったく異なるのである。たとえばif文のネストで記述したり，CASE文にGOTO文を併用するテクニックを使ったり，いわゆるディスパッチテーブルを使う人もいる。さらには，複数のオブジェクトのコラボレーションとして実装されることもある。じつのところ，状態遷移図からどのような実装方式が選ばれるかは，予想がつかないのである。

状態遷移図＝ユースケース。

そういうことが何度かあって気が付いた。これって，ユースケースじゃん。ようするに。
状態遷移図を実装担当に渡すと，こいつを見ながら詳細設計をしてる。そしてプログラムが完成すると，テスト時に，遷移図を片手に項目をつぶしていくのを見る。このように実装担当は，これを要求仕様として利用しているのがわかる。組込システムでユースケースを記述するとき，ストーリーでは甘すぎて，設計時にヌケを見つけることがよくある。そんなとき，状態遷移図を使ったユースケースを記述することは，とても効果的である。

参考：

構造化プログラミング
有限状態機械