« 2011年7月 | トップページ | 2012年1月 »

2011年8月

2011年8月 4日 (木)

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

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

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

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

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

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

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

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

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

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

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

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

« 2011年7月 | トップページ | 2012年1月 »