HSM (階層型ステートマシン) についての雑感

状態遷移機械(ステートマシン)

ステートマシンの実装どうなってるの?と思ってソースをみたら条件分岐しまくっていたり 巨大なcase 文のお化けだったりすることが稀によくある。
こんな時、オブジェクト指向とはなんだったのか、と遠い目になってしまう。

というか、プログラミングにあまり造詣が深くない私にダメ認定される時点で「品質?なにそれおいしいの?」状態である。

あとはテストで抑えるとかいう苦行が待っているのは言うまでもない。バグ曲線はexponentialなカーブを描く。

まぁ最終的に、「動くコードは正義」「さわらぬ神(コード)にたたり(バグ)なし」といった感じでプロダクションまで持っていく。

泣きたい。

HSMとは

最近、デザパタとしてHSMを使ったコードを見ている。

なんだ、High School Musical か。
違う。 Hierarchical Finite State Machines である。

文字通り、階層化されたステートマシンのことを指す。
といわれてもいまいちぴんとこないかもしれない。

ざっくり所感を述べると、イベントドリブンなシステムに向いているかもしれない。階層化することでより組込み向きに設計でき(そうな気がす)る。

FSM との比較

FSM = Finite State Machine 有限状態遷移機械。コンベンショナルなステートマシンのこと。

そういう意味ではHSMじゃなくてHFSMと言うのがよりただしい気もする。

コンベンショナルなステートマシンによる設計アプローチは、
小さな実装ではとても有用。
中規模な実装ではメンテが困難。
大規模な実装ではたいてい失敗する。

ということで、せいぜいストップウォッチや簡易電卓レベルの実装では有用だが、規模が少し大きくなると、とたんに難しくなるんじゃないかと思われる。

なぜか?
同じようなイベントのハンドルと状態遷移をいくつもの異なるステートに対して実装するはめになるからである。実際にやってみたらわかる。ただし仕事でやってはいけない。

HSMは階層化によって共通項を括りだすアプローチなはず。

イベントドリブンなシステムにおける振る舞いの再利用性。

振る舞いの継承
リスコフの置換原則
初期化・終了の保障

(ここまで書いて面倒になった。あとは気が向いたら書く。)

スポンサーリンク

フォローする

スポンサーリンク