データの受け渡し方
プロセスがデータを扱うとき、実装レベルで考えると「呼び出されるときに引き渡される＝引数」「プロセス側から所定の場所を参照する」の2つのパターンが想定されます。業務分析レベルでは「書類や情報を渡されて担当者の業務処理が始まる（担当者への〈PUSH〉で始まる）」のか、「担当者が自ら書類や情報をとりにいく（担当者による〈GET / PULL〉で始まる）」のかの違いです。
とくに「自らデータをとりにいく」ケースでは、プロセス側から進んでデータストアを経由する弧を描いてプロセス自身に戻ってくるような絵を描きがちですが、DFDではそのような表現はしません。
データを受けとるのであっても、とりにいくのであっても、「どこからどこへ流れるかは同じ」ですので、DFDでは同じ向きの矢印で表現されます。
シーケンス図ではメソッドの実行とデータの取得は明確に別のものとして表現されます。
このような内容も、やはり「ミニ仕様書」に記述すべき内容となります。
データの保存媒体・入出力手段
フローチャートではデータの媒体として、書類（ドキュメント）であったり、ハードディスクやデータベースであったり、カードやテープ であったり、媒体によって記号が異なっていました。また入力・出力の手段も、手動入力や手作業なども独立した記号として存在しています。DFDではそうした区別をしません。
データモデル
DFDは、「データの構造」や「データとデータの関係」といったデータモデルを表現しません。論理レベルのエンティティ・リレーションシップ・ダイアグラム（ER図）とDFDは一見すると似たような構造ですが、ER図はデータの「流れ」も「プロセス」も表現しません。
しかし、データモデルの整備は、システム開発を行ううえで欠かせない要素の1つですから、別途作成することを強く推奨します。その際、DFDで洗い出された「データストア」がER図に表現される「エンティティ」の最有力候補となるなど、ER図を作成するうえでDFDが重要な情報源となるでしょう。
状態
DFDはシステムやデータ、オブジェクトといったものの「状態」を表現しません。データモデルと並んで、DFDでは最も表現できない要素と言えるでしょう。
状態管理は1つのプロセスの中で制御される場合、ミニ仕様書の中で状態遷移図（ステートチャート図）を用いて記述することができますし、そうすべきでしょう。しかし、異なるタイミングで起こる、異なるイベントに起因する処理によって状態の変化が発生することがあります。この場合、各プロセスに対応するミニ仕様書の中で、必要な状態変化の処理を記述することが求められます。これが完全に記述されていれば、整合性もとれます。しかし、状態遷移の全体像を理解し、その整合性を確認するには、DFDとは別に状態遷移図を用意するのが望ましいでしょう。その中で、イベントとプロセスの対応関係を整理することが有効です。
「ノート」の扱い
DFDの表記記号の中に、コメント・メモに相当する「ノート」を表記する記号は指定されていません。かといって、絶対にノートを使用してはいけない、ということでもありません。データディクショナリやミニ仕様書などを書き起こすほどでもない補足情報の表記として、ノートを使用してもよいでしょう。
次のような情報は、DFDの図解とともにノートによって注釈がついていると、理解がより促されます。
- 依存性のある複数のプロセス間の実行順序
- データの受け渡しの方法として、受領するか、とりにいくか
- 条件分岐によって、特定条件においてのみ実行されるプロセスや、出力されるデータストアへの流れ
- 並列化した処理の同期ポイントとなるプロセス
- プロセスの実行多重度
UMLの各種モデルでは、ノートを表す記号が使われていることがあります。DFDでも同じ記号を利用するなど、明らかにDFDの4記号と異なるもので、メモとわかる記号を使用してください。
ただし、あまり多用すると情報自体も過多になり、また、図が窮屈で見づらいものとなってしまうので注意が必要です。
