状態遷移のAction設計してます？

一ヶ月ブログ更新せずにほったらかしになってしまいました。
ほとんど”やるやる詐欺”ですな。

今日の記事は、前回の「状態って、どうやって抽出します？」の続きにもなります。

状態遷移図で設計した場合、Actionの設計ってどうしています？

むかしの私は、状態遷移図に処理の概要だけをちょこっと書き込み、そのまま実装で作りこんでいました。
そうすると、各状態Action同士の関係をコード上で考えることになってしまいます。簡単な振る舞いならば、それでも良いのですが、システム構造の上位の方で状態制御をしている場合、気がづけば下位の処理間が複雑に絡み合っていた... という困ったことになったこともありました。

『リファクタリングして、直せばいいじゃない』　とも思いました。
しかし、そもそもActionを設計していないので、リファクタリングするときにも、再考する機能構造を表したものが無かったのです。これじゃぁね．．．なるべくしてなった結果かもしれません

リアルタイム構造化分析を、再勉強したときに、「あ～、CFD（制御フローダイアグラム）の分析って、こういうときに有効なのね」と、後から理解しました。

前回Blog記事の状態遷移図と対となる、CFDがこの図です。

右上にある、黒棒が制御バーと言って、制御の集約場所を表します。この中に、状態遷移図が入っていて、このダイアグラム上の処理を統括していることを表しています。
このように、振る舞いと機能分割をそれぞれ別の図に表し、関係性を表せるのが、CFDの良いところです。
状態遷移のActionにあたる部分が、分割したプロセスとして登場します。
こうして、Actionを設計するモデルを残しておけば、下位の処理を検討するときにも、それぞれの機能分担の中で、重複するところ、統合して再構成すべきところ etc. を考えることができるわけです。
また、制御フローが状態遷移を起こすトリガになるため、どこで遷移を起こす要因を作っているかも、モデル図から見て取れます。

状態遷移図で設計する際、別の角度からActionを設計するモデル図を作る。
結構大事なところじゃないかな... と思っています。

今になっては、CFD というと、松尾谷さんの提唱する 原因流れ図（CFD：cause flow diagram） の方が有名かもしれません。 これとは、まったく別物ですので、ご注意ください。

※　関連記事：　Interface 2011年8月号