状態遷移のAction設計してます?
一ヶ月ブログ更新せずにほったらかしになってしまいました。
ほとんど”やるやる詐欺”ですな。
今日の記事は、前回の「状態って、どうやって抽出します?」の続きにもなります。
状態遷移図で設計した場合、Actionの設計ってどうしています?
むかしの私は、状態遷移図に処理の概要だけをちょこっと書き込み、そのまま実装で作りこんでいました。
そうすると、各状態Action同士の関係をコード上で考えることになってしまいます。簡単な振る舞いならば、それでも良いのですが、システム構造の上位の方で状態制御をしている場合、気がづけば下位の処理間が複雑に絡み合っていた... という困ったことになったこともありました。
『リファクタリングして、直せばいいじゃない』 とも思いました。
しかし、そもそもActionを設計していないので、リファクタリングするときにも、再考する機能構造を表したものが無かったのです。これじゃぁね...なるべくしてなった結果かもしれません
リアルタイム構造化分析を、再勉強したときに、「あ~、CFD(制御フローダイアグラム)の分析って、こういうときに有効なのね」と、後から理解しました。
前回Blog記事の状態遷移図と対となる、CFDがこの図です。
右上にある、黒棒が制御バーと言って、制御の集約場所を表します。この中に、状態遷移図が入っていて、このダイアグラム上の処理を統括していることを表しています。
このように、振る舞いと機能分割をそれぞれ別の図に表し、関係性を表せるのが、CFDの良いところです。
状態遷移のActionにあたる部分が、分割したプロセスとして登場します。
こうして、Actionを設計するモデルを残しておけば、下位の処理を検討するときにも、それぞれの機能分担の中で、重複するところ、統合して再構成すべきところ etc. を考えることができるわけです。
また、制御フローが状態遷移を起こすトリガになるため、どこで遷移を起こす要因を作っているかも、モデル図から見て取れます。
状態遷移図で設計する際、別の角度からActionを設計するモデル図を作る。
結構大事なところじゃないかな... と思っています。
今になっては、CFD というと、松尾谷さんの提唱する 原因流れ図(CFD:cause flow diagram) の方が有名かもしれません。 これとは、まったく別物ですので、ご注意ください。
※ 関連記事: Interface 2011年8月号