Loading article…
データフロー図は、プロセスまたはシステム（通常は情報システム）を通るデータの流れを表す方法です。DFDは、各エンティティの出力と入力、およびプロセス自体に関する情報も提供します。データフロー図には制御フローはありません。つまり、決定ルールもループもありません。データに基づく特定の操作はフローチャートで表すことができます。[ 1 ]
データフロー図を表示するための表記法はいくつか存在する。上記で紹介した表記法は、1979年にトム・デマルコによって構造化分析の一部として記述されたものである。
各データフローにおいて、少なくとも一方のエンドポイント（送信元および／または送信先）はプロセス内に存在しなければなりません。プロセスのより詳細な表現は、別のデータフロー図で行い、その図ではプロセスをサブプロセスに分割します。
データフロー図は、構造化分析、データモデリング、脅威モデリングの一部を構成するツールです。UMLを使用する場合、通常はアクティビティ図がデータフロー図の役割を担います。データフロー図の特殊な形式として、サイト指向データフロー図があります。
データフロー図は、ペトリネットの反転とみなすことができる。なぜなら、そのようなネットワーク内の場所は、データメモリの意味論に対応するからである。同様に、ペトリネットにおける遷移の意味論と、データフロー図におけるデータフローおよび関数の意味論は、同等であると考えるべきである。
DFD表記法は、もともとオペレーションズ・リサーチで組織のワークフローをモデル化するために、またコンピュータサイエンスで計算における入力と出力の流れをモデル化するために使用されたグラフ理論に基づいています。 [ 2 ] [ 3 ] DFDは、1970年代半ばの構造化分析設計手法から生まれました。 [ 3 ]最初に提案したのはラリー・コンスタンティン[ 4 ]で、エドワード・ヨードン、トム・デマルコ[ 5 ]、 クリス・ゲイン、トリッシュ・サーソン[ 6 ] [ 7 ]によって普及し、彼らは図式化手法をさまざまな表記法、データ辞書の実践[ 5 ] 、プロセスの階層的分解のガイダンス[ 6 ]で充実させました。
構造化設計の文脈におけるデータフロー図の主な目的は、異なるモジュール間の相互依存関係を合理化して、複雑なモジュールシステムを構築することでした。[ 3 ] データフロー図（DFD）は、ソフトウェアシステムプロセスに関わる主要なステップとデータを視覚化する一般的な方法となりました。DFDは通常、コンピュータシステムのデータフローを示すために使用されましたが、理論的にはビジネスプロセスモデリングにも適用できます。[ 8 ] DFDは、主要なデータフローを文書化したり、データフローの観点から新しい高レベル設計を検討したりするのに役立ちました。[ 9 ]
DFDは、プロセス、フロー、ウェアハウス、およびターミネータで構成されます。これらのDFDコンポーネントを表示する方法はいくつかあります。[ 10 ]
プロセス
プロセス（関数、変換）は、入力を出力に変換するシステムの一部です。プロセスのシンボルは、円、楕円、長方形、または角が丸い長方形（表記法の種類による）です。プロセスは、その本質を明確に表現する単語、短い文、またはフレーズで命名されます。[ 7 ]
データフロー
データフロー（フロー、データフロー）は、システムのある部分から別の部分への情報（場合によっては物質も）の転送を示します。フローのシンボルは矢印です。フローには、移動される情報（または物質）が何であるかを決定づける名前が必要です。例外は、これらのフローにリンクされているエンティティを介して転送される情報が明確なフローです。物質の移動は、単に情報を提供するだけのシステムではないシステムでモデル化されます。フローは、1種類の情報（物質）のみを転送する必要があります。矢印はフローの方向を示します（エンティティとの間の情報が論理的に依存している場合、双方向になることもあります。たとえば、質問と回答など）。フローは、プロセス、倉庫、および終端装置をリンクします。[ 7 ]
倉庫
ウェアハウス（データストア、データストア、ファイル、データベース）は、後で使用するためにデータを保存するために使用されます。ストアのシンボルは2本の水平線で、別の表示方法はDFD表記で示されています。ウェアハウスの名前は複数名詞（例：orders）で、ウェアハウスの入力ストリームと出力ストリームから派生します。ウェアハウスはデータファイルだけではなく、たとえばドキュメントのフォルダ、ファイルキャビネット、または光ディスクのセットでも構いません。したがって、DFDでウェアハウスを表示することは実装に依存しません。ウェアハウスからのフローは通常、ウェアハウスに保存されているデータの読み取りを表し、ウェアハウスへのフローは通常、データの入力または更新（場合によってはデータの削除も）を表します。ウェアハウスは、メモリ名が配置されている2本の平行線で表されます（UMLバッファノードとしてモデル化できます）。[ 7 ]
ターミネーター
ターミネータは、システムと通信し、システムの外部に存在する外部エンティティです。たとえば、モデルシステムには属さない、さまざまな組織（銀行など）、人々のグループ（顧客など）、当局（税務署など）、または同じ組織の部門（人事部など）などが考えられます。ターミネータは、モデル化されたシステムが通信する別のシステムである場合もあります。[ 7 ]
エンティティ名は、追加の説明なしで理解できる必要があります。 DFD は、アナリストがシステム ユーザーへのインタビューに基づいて作成するグラフィカル モデリング手法です。 システム開発者とプロジェクト 請負業者の両方に役立つため、エンティティ名はモデラー、ユーザー、システム アナリストが理解できる必要があります。 エンティティ名は一般的 (独立、たとえばアクティビティを実行する特定の個人) である必要がありますが、エンティティを明確に指定する必要があります。 プロセスには、マッピングと特定のプロセスへの参照を容易にするために番号を付ける必要があります。 番号付けはランダムですが、すべての DFD レベルで一貫性を維持する必要があります (DFD 階層を参照)。 DFD は明確である必要があり、1 つの DFD 内のプロセスの最大数は 6 ～ 9 に推奨され、最小数は 3 プロセスです。[ 1 ] [ 7 ]例外は、モデル システムとシステムが通信するすべての終端を唯一のプロセスが象徴する、いわゆるコンテキスト 図です。
DFD は、エンティティ関係図、状態遷移図、データ ディクショナリ、プロセス仕様モデルなど、システムの他のモデルと整合性が取れている必要があります。各プロセスには、名前、入力、出力が必要です。各フローには名前が必要です (例外については「フロー」を参照)。各データ ストアには、入力フローと出力フローが必要です。入力フローと出力フローは、1 つの DFD に表示する必要はありませんが、同じシステムを記述する別の DFD には存在する必要があります。例外は、システムが通信するシステムの外部にある倉庫 (外部ストレージ) です。[ 7 ]
DFD の透明性を高めるため (つまり、プロセスが多すぎないようにするため)、多階層 DFD を作成できます。上位レベルの DFD は詳細度が低くなります (下位レベルのより詳細な DFD を集約します)。コンテキスト DFD は階層構造の最上位にあります (DFD 作成ルールを参照)。いわゆるゼロ レベルの後には、プロセス番号 (プロセス 1、プロセス 2 など) から始まる DFD 0 が続きます。次のいわゆる第 1 レベル (DFD 1) では、番号付けが続きます。たとえば、プロセス 1 は、1.1、1.2、1.3 と番号付けされた DFD の最初の 3 つのレベルに分割されます。同様に、第 2 レベル (DFD 2) のプロセスには、2.1.1、2.1.2、2.1.3、2.1.4 と番号が付けられます。レベルの数は、モデル システムのサイズによって異なります。DFD 0 のプロセスは、同じ数の分解レベルを持つとは限りません。DFD 0 には、最も重要な (集約された) システム機能が含まれます。最下位レベルには、A4用紙1枚分程度のプロセス仕様書を作成できるようなプロセスを含める必要があります。ミニ仕様書が長くなる場合は、そのプロセスを複数のプロセスに分解するための追加レベルを作成するのが適切です。DFD階層全体を明確に把握するために、垂直（断面）図を作成できます。倉庫は、最初に使用される最上位レベルと、それより下位のすべてのレベルに表示されます。[ 7 ]
ウィキメディア・コモンズにあるデータフロー図に関連するメディア