データフロー図とは何ですか、なぜそれがソフトウェア開発にまだ役立つのですか？

データフローモデルは、システムがデータを処理する  方法を示す直感的な方法です。分析レベルでは、既存のシステムでデータが処理される方法をモデル化するために使用する必要があります。

DeMarcoの著書StructuredSystems Analysisの発行後 、データフローモデルは分析でますます広く使用されるようになりました。これらは、この作業から開発された構造化されたアプローチの固有の部分です。これらのモデルで使用される記号は、関数処理（丸みを帯びた長方形）、データストレージ（長方形）、および関数間のデータ移動（ラベル付き矢印）を表します。

なぜDFDはまだソフトウェア開発に役立つのですか？

データフロー指向のモデリングは、一部のソフトウェアエンジニアによって時代遅れのテクノロジーと見なされてい  ますが、それでも最も広く使用されている要件分析シンボルの1つです。データフロー図（DFD）はUMLの正式な部分ではありませんが、UML図を補足し、システム要件とプロセスに関する追加の洞察を提供するために使用できます。

特定のプロセスに関連するデータがシステム内をどのように移動するかを追跡および記録することで、アナリストが何が起こっているのかを理解するのに役立つため、データフローモデルは価値があります。データフロー図の利点は、他のモデリングシンボルとは異なり、シンプルで直感的であることです。これらは通常、要件の分析と検証に関与する可能性のある潜在的なシステムユーザーに説明できます。

なぜDFDなのか？

DFDは、システムとその環境間、およびシステムのコンポーネント間でデータをキャプチャ、操作、保存、および配布する機能またはプロセスをグラフィカルに表します。視覚的な表現により、ユーザーとシステム設計者の間の優れたコミュニケーションツールになります。DFDの構造により、大まかな概要から始めて、詳細な図の階層に拡張することができます。DFDは、次の理由でよく使用されています。

• システムの論理情報の流れ
• 物理システム構築要件の決定
• 表記の単純さ
• 手動および自動システム要件の確立

DFDはトップダウンの分解プロセスです

データフローモデリングは「トップダウン」プロセスです。まず、調達プロセス全体を分析します。次に、サブプロセスがトップダウン分解方式で分析されます。

DFDは、あらゆるレベルの抽象化でシステムまたはソフトウェアをモデル化するために使用できます。前述のように、DFDは、情報の流れと機能の詳細の増加を表すレベルに分割できます。DFDのレベル番号は、0、1、2以上です。ここでは、データフロー図にレベル0 DFD、レベル1 DFD、レベル2DFDの3つの主要なレベルがあることがわかります。

コンテキスト図—DFDのレベル

コンテキスト図（レベル0 DFDとも呼ばれます）は、ソフトウェア要件全体をバブルとして表し、入力データと出力データは入力矢印と出力矢印で表されます。

次に、システムは複数のバブルを持つDFDに分解されます。次に、各バブルで表されるシステムの部分が分解され、ますます詳細なデータフロー図に記録されます。このプロセスは、手元のプログラムが完全に理解されるまで、必要なレベルで繰り返すことができます。

レベル間の入力と出力の数を維持する必要があります。これは、DeMacroレベリングと呼ばれる概念です。したがって、バブル「A」に2つの入力X1とX2、および1つの出力Yがある場合、上位レベルのDFD「A」を表すサブレベルのデータフロー図には、正確に2つの外部入力と1つの外部出力が必要です。

1レベルDFDでは、コンテキスト図が複数のプロセスに分解されます。このレベルでは、システムの主な機能を強調し、0レベルDFDの高レベルプロセスをさらにサブプロセスに分解して、処理アクティビティの詳細を表します。

コンテキスト図（レベル0 DFD）  —コンテキスト図DFDは、システムの概要と、システムの他の部分との相互作用を表す図です。

レベル1のデータフロー図 —レベル1のDFDは、システム全体を構成する主要なサブプロセスとデータストアを表示することにより、コンテキスト図よりもシステムの詳細なビューを提供します。

レベル2（またはそれ以下）  —データフローモデリングテクノロジーの主な利点は、「レベリング」と呼ばれるテクノロジーを通じて、実際のシステムの詳細な複雑さを抽象的なレベルで管理およびモデル化できることです。データフロー図の一部の要素は、階層の下位レベルでより詳細なモデルに分解（「分解」）できます。

DFDレベル—例—食品注文システム

レベル0

コンテキスト図とも呼ばれ ます。これは抽象化ビューとして設計されており、システムを外部エンティティとの関係を持つ単一のプロセスとして表示します。

• コンテキスト図は1ページに収まる必要があります。
• コンテキスト図のプロセス名は、情報システムの名前である必要があります。
• たとえば、グレーディングシステム、注文処理システム、登録システム。

1レベルDFDでは、コンテキスト図が複数のプロセスに分解されます。このレベルでは、システムの主な機能を強調し、0レベルDFDの高レベルプロセスをさらにサブプロセスに分解して、処理アクティビティの詳細を表します。

レベル1—食品注文システム

1レベルDFDでは、コンテキスト図が複数のプロセスに分解されます。このレベルでは、システムの主な機能を強調し、0レベルDFDの高レベルプロセスをさらにサブプロセスに分解して、処理アクティビティの詳細を表します。

少数の外部エンティティ間で大量のデータフローがリンクしているプロセスの場合、プロセスを別のレベルのDFDに絞り込む前に、まずその特定のプロセスと関連する外部エンティティをコンテキスト図と同様の別の図に抽出できます。このようにして、それらの間の一貫性をはるかに簡単に確保できます。

DFDシンボル

 データフロー図を表すために使用される4つの基本的な記号があります 。

プロセス

プロセスは入力データを受け取り、異なるコンテンツまたは形式で出力を生成します。プロセスは、入力データを収集してデータベースに保存するのと同じくらい単純な場合もあれば、北西地域のすべての小売店の月間売上を含むレポートを作成するのと同じくらい複雑な場合もあります。

すべてのプロセスには、実行する機能を識別する名前が付いています。

名前は、動詞とそれに続く単数名詞で構成されます。

例：

• 支払いを適用する
• コミッションを計算する
• 注文を確認する

DFD表記

• 角の丸い長方形はプロセスを表します
• プロセスには、簡単に参照できるようにIDが付けられています

プロセス例

データフロー

データフローは、データが情報システムのある部分から別の部分に移動するためのパスです。データフローは、顧客IDなどの単一のデータ要素を表す場合もあれば、データ要素のセット（またはデータ構造）を表す場合もあります。

例：

• Customer_info（LastName、FirstName、SS＃、Tel＃など）
• Order_info（OrderId、Item＃、OrderDate、CustomerIDなど）。

データフローの例：

表記

• 入ってくる矢印の付いた直線は入力データフローです
• 出て行く矢印の付いた直線は出力データフローです

ご了承ください：

すべてのプロセスがデータをある形式から別の形式に変更するため、少なくとも1つのデータフローが各プロセスシンボルに入力され、1つのデータフローが終了する必要があります。

データストア

データストアまたはデータリポジトリは、データフロー図で使用され、1つ以上のプロセスが後で保存されたデータを使用する必要があるため、システムがデータを保持する必要がある状況を表します。

表記

• データストアにデータを書き込むことができます。データストアは、外向きの矢印で示されています。
• データストアからデータを読み取ることができます。データストアは、入ってくる矢印で示されています。
• 例としては、在庫、売掛金、注文、日次支払いなどがあります。

データストアの例

ご了承ください：

• データストアは、データフローを使用してプロセスに接続する必要があります。
• 各データストアには、少なくとも1つの入力データフローと少なくとも1つの出力データフローが必要です（出力データフローが制御メッセージまたは確認メッセージである場合でも）。

外部エンティティ

外部エンティティは、システムにデータを提供したり、システムから出力を受信したりする個人、部門、外部組織、またはその他の情報システムです。外部エンティティは、情報システムの境界外のコンポーネントです。それらは、情報システムが外界とどのように相互作用するかを表しています。

• 長方形は外部エンティティを表します
• データを提供するか、データを受信します
• データを処理しません

表記

• 注文を送信してからシステムから請求書を受け取る顧客
• ベンダーが請求書を発行します

外部エンティティの例

ご了承ください：

• 外部エンティティは、データの発信元または最終的な宛先であるため、ターミネータとも呼ばれます。
• 外部エンティティは、データフローを介してプロセスに接続する必要があります。