データフローダイアグラム（DFD）で表現すること、しないこと
第3回 「DFDで表現しないこと」から見るダイアグラムの特徴
1970年代に登場した「データフローダイアグラム（DFD）」は、データの流れを矢印で表現するシンプルな図解手法。かつて主流だったこの“いにしえの技術”が、実は現代の複雑なシステム設計や要件整理にこそ効くとしたら──？ 本連載では、翔泳社刊『データフローダイアグラム いにしえの技術がもたらすシステム設計の可能性』より、DFDの基礎から活用法までを抜粋して紹介します。
これまでのおさらい
ダイアグラムで表現すること、しないこと
DFDは4つの記号で表されるシンプルな図解法であり、その表記ルールの説明を受けなくても、ぱっと見ただけで何を表現しているか、おおよそのイメージをつかめる便利な表記法です。しかし、シンプルであるが故に表現されない情報もあり、描き手と読み手、あるいは読み手の間でも認識の差が生まれてしまうことがあります。
これまでの解説の中で触れてきた内容も含まれますが、あらためてそうした読み間違い、認識差異の発生の原因となりやすい「DFDで表現しないこと」に焦点を当てて解説します。
実行順序・同期／非同期
DFDでは、処理を表すプロセスの「実行順序」を表現しません。いわゆるフローチャートと同様に、データフローを示す矢印に沿って、順番に実行されるものとして読み取りたくなりますが、必ずしもその順序で実行されることを示しているわけではないことに注意する必要があります。
データの生成経緯からして、頭から（データフローの矢印をたどった、DFDの図上の起点から）順番に実行されないと、中間地点にあるプロセスにとって必要なデータが存在しえないことがあります。それでも、DFDのルールとしては「DFDそれ自体は、順序を表さない」というものになります。
同様に、複数のプロセスの関係において、次のような同期／非同期の表現もDFDにはありません。
- 呼び出し先のプロセスの終了を待って後続処理を進める
- 呼び出したプロセスは非同期で実行し、その終了を待たずに呼び出し元の後続処理を進める
また、「並行・並列処理とその同期」についても、DFDでは表現しません。UMLのアクティビティ図では同期バーによって複数の処理に分岐した後、再び同期バーによって集約されるような表記ができますが、DFDでは同等の表記がありません。
普段、実装により近い部分を担当している人ほど、このような表現をしたくなる、あるいはそのように読み取りたくなるところですが、DFD自体にはこうした要素が含まれていないことに注意してください。
これらはいずれも、DFDが描こうとしている「データの流れ（データフロー）」ではなく、「プロセスの流れ（プロセスフロー）」の話です。オリジナルな図解をしているとき、その矢印が何を意味しているのかわからないことが時々ありますが、「DFDにおける矢印はデータフロー」ということを強く意識する必要があります。
図解における「矢印の意味」
コンサルタント時代、主にPowerPointスライド資料を作成し、そこでたくさんの図解を用いていましたが、「その矢印の意味するところは何か？」を強く意識するように指導されたことを覚えています。
これはDFDに限った話ではなく、その矢印が何を意味しているかわからない、凡例にも示されていない、「雰囲気で描かれている」資料が世の中にあふれています。
DFDのようにルールが定められた表記法にのっとって図解をしている場合は、その矢印が意味するところは「暗黙の了解」となるかもしれません。しかし、その前提を共有していない相手にも資料を提示することがあります。
「資料を作って見せる」ということは、誰かに情報を正確に伝えるために行っているのですから、矢印1つとっても認識の齟齬を生み出さないように、明確な意図をもって表現する必要があります。
モデリングの基本的な記号と表記における「プロセス」の説明の中で、プロセス名に番号を付与する話がありましたが、その番号は実行順序ではなく、あくまで「一意に識別するための付加情報」に過ぎません。
DFDで表現した複数のプロセスの間に、実行順序や同期的動作といった依存性がある場合、別途、プロセスフロー図としてフローチャートやシーケンス図、アクティビティ図などを補足資料として用意しましょう。
また、そうした依存関係はプロセスの詳細を記述する「ミニ仕様書」の中で、「前提条件」として記述しておくことも、コミュニケーション齟齬を防ぐうえで重要です。
たとえば、この図は「3.発送指示」のプロセスにおいて、「在庫を引き当て、また決済処理が済んで入金確認がとれた注文」について、注文内容に基づく配送情報を生成することを示すDFDです。「1.注文受付」が実行されていなければ、注文データは存在しえません。同様に、「2.支払い」が実行されなければ「支払いデータ」も存在しえません。
ただし、これらの処理が連続して同期的に実行されなければならないわけではありません。インプットデータさえそろっていれば、「3.発送指示」を単独で実行し、アウトプットを生成できるという仕様を表している可能性があります。
この記事は参考になりましたか？
- データフローダイアグラム いにしえの技術がもたらすシステム設計の可能性連載記事一覧
-
- データフローダイアグラム（DFD）を活用して身近なサービスをモデル化しよう
- データフローダイアグラム（DFD）で表現すること、しないこと
- データフローダイアグラム（DFD）の基本と書き方をマスターしよう
- この記事の著者
-
大嶋 和幸（オオシマ カズユキ）
株式会社アクアシステムズ SE、IT コンサルタントとしてCRM、HRM、BPR などの各種案件に関与し、企画立案から設計、実装、試験、運用、保守を経験。その後、事業会社数社にて事業企画、管理会計、総務、社内情報システム担当など多岐にわたる業務に従事。アクアシステムズ入社後は、各種データベースの導...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
松永 守峰（マツナガ モリオ）
株式会社アクアシステムズ オープンシステムの黎明期にはじめてリレーショナルデータベースに触れて以降、ソフトウェアベンダーのサポート技術者、大手メーカーのIT 部門ではDBA、コンサルティングファームでのDB コンサルタントと立場を変えながらデータベースに関わる。アクアシステムズに入社後はパフォーマ...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
湊川 あい（ミナトガワ アイ）
漫画家。コンピュータ書を中心に10年目。マンガで技術をわかりやすく伝えることが好き。 著書『わかばちゃんと学ぶ』シリーズ（C&R研究所）や『つくって壊して直して学ぶ NewSQL入門』（翔泳社）、『マンガでわかるITパスポート』（マイナビ出版）が発売中のほか、『マンガでわかるLLMの仕組み...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか？
この記事をシェア
