データフロー図とは何ですか？
データフロー図は、情報システム内のデータの流れをグラフィカルに表現したものです。着信データフロー、発信データフロー、および保存されたデータを記述できます。DFDは、データがシステムをどのように流れるかについては言及していません。
DFD手法は、高レベルのデータフロー図を一連のより詳細な図に分解し、システム全体の全体像と、より詳細な分解を提供します。システム全体の全体像、およびより詳細な分解と、必要に応じて、明確化と理解を容易にするための個々のアクティビティのより詳細な内訳と説明を提供します。
その結果、システムの範囲と境界が図に明確に示されます。十分に開発されたDFDの最終結果は、各レベルで何が起こっているかを示す「全体像」です。
なぜDFDなのか？
データフロー図
は、 コンピューターの専門家と非専門家のユーザーが同様にアクセスできるようにすることを目的としたシステムのグラフィック表現を提供します。これは、コンテンツを視覚化するのに役立つため、非常に理解しやすいグラフィック表現です。
これらのモデルにより、ソフトウェアエンジニア、顧客、およびユーザーは、要件の分析および仕様作成中に効果的に連携できます。
これは、お客様がモデリング手法と構成を理解する必要があることを意味しますが、データフローモデリングでは、限られた構成のセットのみが使用され、適用されるルールはシンプルで従うのが簡単になるように設計されています。
DFD手法の利点は次のとおりです。
- これは、理解しやすい単純なグラフィック手法です。
- それは、技術的および非技術的な聴衆によってより簡単に理解することができます。
- システムの境界を説明するのに役立ちます。
- これにより、既存のシステム知識をエンドユーザーに伝達しやすくなります。
- これは、システムコンポーネントの詳細な表現を提供します。
- これは、システムドキュメントの一部として使用されます。
DFDとフローチャート
DFDとフローチャートには大きな違いがあります。基本的に、DFDはデータの流れを示します。フローチャートは、制御の流れを示しています。
- フローチャートは、プログラムモジュール内の制御の流れを説明し、問題を解決するための手順を説明するのに役立ちます。
- DFDは、入力、出力、データがシステム内をどのように流れるか、およびデータがどこに保存されるかを示します。制御要素や分岐要素は含まれていません。
DFDの要素
- エンティティ–エンティティは情報データのソースと宛先です。エンティティは長方形で表され
、独自の名前があります。
- プロセス–データに対して実行されるアクティビティとアクションは、円形または円形の長方形で表されます。
- データストレージ–データストレージには2つのバリエーションがあります– 1として表すことができます。1。2つの小さなエッジのない長方形、2）または1つのエッジのみの開いた長方形として表すことができます。エッジ
のない開いた長方形。
- データフロー–データの移動は鋭い矢印で表されます。データの移動は、ソースとしての矢印の下部から宛先としての矢印の頭までの移動として示されています。
データフローの例–電子バンキング
銀行のマネージャーは、新しいアカウントの詳細をオープンアカウントプロセスに提供します。これにより、顧客の詳細が顧客データベースデータストアに保持され、アカウントの詳細がアカウントデータベースデータストアに保持されます。解釈では「結果」という言葉を使用しますが、DFDは因果関係を意味するものではありません。それが示すのは、口座開設プロセスが、顧客データベースおよび口座データベースのデータストアに特定の順序でデータを書き込むことなく、銀行のマネージャーのインターフェースからデータを読み取ることができるということだけです。
オンラインバンキングのログインプロセスを使用する顧客は、ユーザー名やパスワードなどのデータを一連のログイン資格情報の形式で提供する必要があります。
顧客は、引き出しからある金額を受け取るか、ある金額を預金に寄付することができます。どちらの場合も、これにより、アカウントデータベースデータストアのアカウント残高が更新されます（ただし、この因果関係を明示的にモデル化することはできません）。
顧客は送金プロセスを開始でき、口座の宛先と資金の金額を提供する必要があります。資金移動プロセスでは、別の銀行インターフェースを介して別の銀行に資金の金額を送ることができます。
上記のDFDの例には、5つのプロセス、4つの外部インターフェース/ロール、および2つのデータストアが含まれています。これは、銀行システムのデータフローを網羅的に表現することを意図したものではありませんが、DFDの構築方法を理解するのに十分な包括的です。
トップダウン分解手法–複数レベルのDFD
データフローモデリング手法の主な利点は、トップダウン分解（「レベリング」とも呼ばれる）と呼ばれる手法により、現実世界のシステムの詳細な複雑さを管理し、抽象化の階層でモデル化できることです。レベリングは、必要な詳細レベルに達するまで、一連のますます詳細なDFDを描画することによって実現されます。
DFDをさらに複雑にする（つまり、プロセスが多すぎない）ようにするために、マルチレベルのDFDSを作成できます。
- コンテキスト図には、制御（集約）システムプロセスが含まれています。
- トップダウン分解プロセスと呼ばれる、高レベルのDFDはあまり詳細ではありません（より詳細なDFDは低レベルで詳しく説明されています）。
- コンテキスト図は、プロセス番号（たとえば、プロセス1、プロセス2など）で始まります。
- 番号付けは、次のいわゆる第1レベル（DFD）でも継続されます。たとえば、コンテキスト図のプロセス1は、レベル1のDFDの3つのプロセスに絞り込まれ、1.1、1.2、および1.3の番号が付けられています。
- 同様に、第2層のプロセスには、2.1.1、2.1.2、2.1.3、2.1.4などの番号が付けられます。階層内のプロセスの番号付け：
- （1、2、3、…）;
- （1.1、1.2、1.3、…、2.1、2.2、2.3、…）;
- （1.1.1、1.1.2、1.1.3、…）。
- レイヤーの数は、モデルシステムのサイズによって異なります。
DFDから下位レベルのDFDへのトップダウン分解を実行する場合、入力と出力はDFDのレベル間で保存する必要があります。たとえば、レベルnとn +1は同じ入力と出力を持っている必要があります
DFDの例–食品注文システム
コンテキスト図（レベル0 – DFD）
コンテキスト図は、システムの概要と、システムが「世界」の他の部分とどのように相互作用するかを示しています。コンテキスト図は、レベル0と呼ばれる最上位レベルのみを示すデータフロー図です。このレベルでは、システム全体の機能、つまり外部エンティティとの相互作用を表す表示可能なプロセスノードは1つだけです。コンテキスト図の利点のいくつかは次のとおりです。
- システムの境界の概要を示します
- 簡単な表記で、理解するのに技術的な知識は必要ありません
- 表記が限られているため、描画、変更、作成が簡単
次の図は、食品注文システム用に作成されたコンテキスト図（トップレベルのデータフロー図）を示しています。
- これには、システムモデル（この場合は「食品注文システム」）を表すプロセス（形状）が含まれています。
- また、外部エンティティと呼ばれる、システムと対話する参加者も表示されます。
この例では、サプライヤー、キッチン、マネージャー、および顧客がシステムと対話するエンティティです。
プロセスと外部エンティティの間には、エンティティとシステムの間で情報交換が行われていることを示すデータフロー（コネクタ）があります。
コンテキストDFDは、データフローモデルへのエントリポイントです。プロセスは1つだけで、データストレージは表示されません。
レベル1DFD
レベル1DFDは、コンテキスト図よりもシステムの詳細なビューを提供します。システムを構成する主要なサブプロセスとデータストアを表示します。
次の図は、レベル1 DFDを示しています。これは、コンテキストDFDに示されている食品注文システムプロセスの内訳（つまり分解）です。図を読んでから、それに基づいたいくつかの重要な概念を紹介します。
食品注文システムのデータフロー図の例には、3つのプロセス、4つの外部エンティティ、および2つのデータストアが含まれています。
- 図によると、顧客が注文できることがわかります。食品注文プロセスは注文を受け取り、それをキッチンに転送し、注文データストアに保存し、更新された在庫の詳細を在庫データストアに保存します。このプロセスでは、顧客への請求も行われます。
- 管理者は、レポートの生成プロセスを通じてレポートを受け取ることができます。このプロセスは、在庫の詳細と注文を、それぞれ在庫と注文のデータストアへの入力として受け取ります。
- マネージャーは、在庫注文を提供することにより、注文在庫プロセスを開始することもできます。このプロセスは、在庫注文をベンダーに転送し、更新された在庫の詳細を在庫データストアに保存します。
論理DFDと物理DFD
データフロー図は、論理データフロー図と物理データフロー図に分けられます。論理DFDは、ビジネスとその運用方法に焦点を当てています。発生するビジネスイベントと、各イベントに必要なデータと生成されるデータについて説明します。一方、物理DFDは、システムがどのように実装されるかを示します。論理DFDと物理DFDの主な違いは次のとおりです。
論理DFD
- 論理DFDは、ビジネスの運営方法を示します。
- プロセスはビジネス活動を表しています。
- データストアは、データの保存方法に関係なく、データのコレクションを表します。
- それはビジネスがどのように管理するかです。
物理DFD
-
- 物理DFDは、システムがどのように実装されるか（または現在のシステムがどのように動作するか）を示します。
- プロセスは、プログラム、プログラムモジュール、および手動手順を表します。
- データストアは、物理ファイルとデータベース、手動ファイルを表します。
- これは、入力データの検証、レコードの取得、プロセスの正常な完了の保証、およびシステムのセキュリティのためのコントロールを示しています。
- 物理DFDは物理ドキュメントの実際のフローを指定しますが、論理DFDはビジネス用語の情報フローのみに焦点を当てます。
たとえば、物理DFDは物理ドキュメントの実際のフローを指定しますが、論理DFDはビジネス用語の情報フローのみに焦点を当てます。
さらに、論理DFDは、物理アクティビティのみを参照し、データを変換しない物理プロセスを排除します。
論理DFDの例–食料品店
論理DFDは、アクティビティの物理的な実装について詳しく説明せずに、関連するプロセスを示しています。
物理的なDFDの例–食料品店
- 物理的なDFDは、バーコード（ほとんどの食料品店の商品にあるUPC PRICEコード）が使用されていることを示しています。
- さらに、物理DFDはスキャンなどの手動プロセスについて言及し、一時ファイルを使用してアイテムの小計を保持することを説明しています
- 支払いは、現金、小切手、またはデビットカードで行うことができます
最後に、それはその名前でレシートを参照します、CASH REGISTERRECEIPT
データフロー図に関するヒントと注意
- 複雑にしすぎないでください。通常、5〜7人の平均的な人がプロセスを管理できます
- データストアは少なくとも1つのプロセスに関連付けられている必要があります
- プロセスを経ずに2つの外部エンティティ間にデータフローが存在してはなりません
- 入力はあるが出力がないプロセスは、ブラックホールプロセスと見なされます。
- プロセスラベルは動詞句である必要があります。データストアは名詞で表されます。
- 外部エンティティは、少なくとも1つのプロセスに関連付けられている必要があります
- DFDは非決定論的です。番号付けは必ずしも順序を示すものではなく、ユーザーと話し合うときにプロセスを識別するのに役立ちます。
- データストアは外部エンティティに接続しないでください。接続しないと、外部エンティティにデータファイルへの直接アクセスを許可していることになります。
資力