DFDモデル お勧めできない例（その１）

今回のお話は、ちょっと前回のつづきになります。
前回のblog記事：WAHTで考える練習

未だ構造化設計の認知拡充を図る私としては、WHATのモデルとしてDFDによる分析モデルをちょいちょいご紹介しています。UMLが浸透した今となっては、すっかり忘れ去られた表記法かもしれません。でも、丸と矢印だけで、プロセス（処理のかたまり）の関係を表すこの表記法、とってもシンプルで好きなんです。
忘れ去られるのも悲しいので、コレ使いつづけてます。

さて、Interface6月号では、LEDキューブシステム(*1)のDFDによる分析モデルの例を載せました。
(*1) 開発対象物［LEDキューブシステム］の仕様については、こちらあたりをご覧下さい。
　過去blog：組込みソフトウェア開発者にとっての要求仕様書

このLEDキューブシステムを分析したコンテキストと、第一階層のDFD０はこんな感じになります。（雑誌掲載済み）

これらは、何度か描きなおして、出来上がった結果のDFDです。
この形におさまるまで、4, 5回は、機能の分割、グループ分け、再統合．．．を繰り返しています。

6月号には、もう一つアンチパターンとして、こんなモデルを載せました。

この例は、HOWで考えてしまった典型例なのですね。
どこがって．．． 左上にある 「100msタイマ割り込み処理」 があるところです。
これって、
　どうやってプロセスを順番に動かそう．．．、
　どうやってアレと、コレ同期させよう．．．
どうやって．．．（＝HOW) を考えないと、この タイマ割り込みドリブン な分割にはならないのです。

手続き型の言語によるプログラミングになれた人ほど、これはやってしまいがちです。

タイマ割り込みプロセスをDFDモデルに登場させないというのは、タイマ割り込みを使ってはいけないということではないですよ。
プロセス分割した結果、それらを動かす仕組みとして、タイマ割り込みを使うのはOKなんです。でも、タイマ割り込みはあくまでもプロセスを動かす仕組みであり、それ自身が要求仕様に紐付いた役割を担ったものではないということに、注意しましょう。

Whatによる思考に慣れない場合、まずこのタイマ割り込みドリブンを頭に思い浮かべずに、機能分割してモデルを書いてみる。　そんなところから、初めてみるのも、一つ手だと思いますよ。

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