データフロー図

データフロー図は、プロセスまたはシステム（通常は情報システム）を通るデータの流れを表す方法です。DFDは、各エンティティの出力と入力、およびプロセス自体に関する情報も提供します。データフロー図には制御フローはなく、決定ルールやループはありません。データに基づく特定の操作は、フローチャートで表すことができます。^[1]

データフロー図を表示するための表記法はいくつかあります。上記の表記法は、1979 年にTom DeMarcoによって構造化分析の一部として説明されました。

各データフローについて、少なくとも 1 つのエンドポイント (ソースおよび/または宛先) がプロセス内に存在する必要があります。プロセスの詳細な表現は、このプロセスをサブプロセスに分割する別のデータフロー図で行うことができます。

データフロー図は、構造化分析とデータモデリングの一部であるツールです。UMLを使用する場合、アクティビティ図がデータフロー図の役割を引き継ぐのが一般的です。データフロー計画の特殊な形式として、サイト指向のデータフロー計画があります。

データフロー図は、ネットワーク内の場所がデータメモリのセマンティクスに対応するため、逆ペトリネットと見なすことができます。同様に、ペトリネットの遷移のセマンティクスと、データフロー図のデータフローと関数のセマンティクスは同等であると考える必要があります。

歴史

DFD表記法はグラフ理論に基づいており、もともとはオペレーションズ・リサーチで組織のワークフローをモデル化するために使用され、コンピュータサイエンスでは計算全体の入力と出力のフローをモデル化するために使用されていました。^[2]^[3] DFDは、1970年代半ばの構造化分析および設計技術の方法論から生まれました。 ^[3]これは、ラリー・コンスタンティン^{[4]によって最初に提案され、}エドワード・ユアドン、トム・デマルコ^[5]、クリス・ゲイン、トリッシュ・サーソン^[6]^[7]によって普及しました。彼らは、さまざまな表記法、データ辞書のプラクティス^[5]、プロセスの階層的分解のガイダンスによって、ダイアグラム作成技術を充実させました。 ^[6]

構造化設計におけるデータフロー図の主な目的は、複雑なモジュールシステムを構築し、異なるモジュール間の相互依存性を合理化することであった。^[3] データフロー図 (DFD) は、ソフトウェアシステムプロセスに含まれる主要なステップとデータを視覚化する方法として急速に普及した。DFD は通常、コンピュータシステム内のデータフローを示すために使用されたが、理論的にはビジネスプロセスモデリングにも適用できる。^[8] DFD は、主要なデータフローを文書化したり、データフローの観点から新しい高レベルの設計を検討したりするのに役立った。^[9]

DFDコンポーネント

データフロー図 - Yourdon/DeMarco 表記 — *データフロー図 - Yourdon / DeMarco表記*

DFDはプロセス、フロー、ウェアハウス、ターミネータで構成されています。これらのDFDコンポーネントを表示する方法はいくつかあります。^[10]

プロセス

プロセス（機能、変換）は、入力を出力に変換するシステムの一部です。プロセスのシンボルは、円、楕円、長方形、または角の丸い長方形（表記の種類によって異なります）です。プロセスは、その本質を明確に表現する1つの単語、短い文、またはフレーズで命名されます。^[7]

データフロー

データフロー（フロー、データフロー）は、システムのある部分から別の部分への情報（場合によっては物質）の転送を示します。フローのシンボルは矢印です。フローには、移動される情報（または物質）を特定する名前が必要です。例外は、これらのフローにリンクされているエンティティを通じて転送される情報が明らかなフローです。物質の移動は、情報だけではないシステムでモデル化されます。フローは、1種類の情報（物質）のみを送信する必要があります。矢印はフローの方向を示します（エンティティとの間の情報が論理的に依存している場合は、双方向になることもあります。たとえば、質問と回答など）。フローは、プロセス、倉庫、およびターミネータをリンクします。^[7]

倉庫

ウェアハウス (データストア、データストア、ファイル、データベース) は、後で使用するためにデータを保存するために使用されます。ストアのシンボルは 2 本の水平線で、DFD 表記では別の表示方法が示されています。ウェアハウスの名前は複数名詞 (例: 注文) で、ウェアハウスの入力ストリームと出力ストリームに由来します。ウェアハウスはデータファイルだけである必要はなく、たとえば、ドキュメントの入ったフォルダー、ファイリングキャビネット、光ディスクのセットなどである場合もあります。したがって、DFD でウェアハウスを表示することは実装に依存しません。ウェアハウスからのフローは通常、ウェアハウスに保存されているデータの読み取りを表し、ウェアハウスへのフローは通常、データの入力または更新 (場合によってはデータの削除も) を表します。ウェアハウスは 2 本の平行線で表され、その間にメモリ名が配置されます (UML バッファーノードとしてモデル化できます)。^[7]

ターミネーター

ターミネータは、システムと通信し、システムの外側に立つ外部エンティティです。たとえば、モデルシステムに属さないさまざまな組織（銀行など）、人々のグループ（顧客など）、当局（税務署など）、または同じ組織の部門（人事部など）などです。ターミネータは、モデル化されたシステムが通信する別のシステムである場合もあります。^[7]

DFD作成のルール

エンティティ名は、それ以上のコメントがなくても理解できるものでなければなりません。DFD は、システムユーザーへのインタビューに基づいてアナリストが作成したシステムです。これは、一方ではシステム開発者、他方ではプロジェクト請負業者向けに決定されるため、エンティティ名はモデルドメイン、アマチュアユーザー、または専門家に合わせて調整する必要があります。エンティティ名は一般的なもの (独立したもの、たとえばアクティビティを実行する特定の個人など) にする必要がありますが、エンティティを明確に指定する必要があります。プロセスには番号を付けて、特定のプロセスへのマッピングと参照を容易にする必要があります。番号付けはランダムですが、すべての DFD レベルで一貫性を維持する必要があります (DFD 階層を参照)。DFD は明確でなければなりません。1 つの DFD に含まれるプロセスの最大数は 6 から 9 個、最小数は 3 個が推奨されます。^[1]^[7]例外は、いわゆるコンテキストダイアグラムで、唯一のプロセスがモデルシステムと、システムが通信するすべてのターミネータを象徴します。

DFDの一貫性

DFD は、システムの他のモデル (エンティティ関係図、状態遷移図、データディクショナリ、プロセス仕様モデルなど) と一致している必要があります。各プロセスには、名前、入力、出力が必要です。各フローには名前が必要です (例外についてはフローを参照してください)。各データストアには、入力フローと出力フローが必要です。入力フローと出力フローは、1 つの DFD に表示する必要はありませんが、同じシステムを記述する別の DFD には存在する必要があります。例外は、システムが通信するシステムの外部にある倉庫 (外部ストレージ) です。^[7]

DFD階層

DFD をより透明にする (つまり、プロセスが多すぎないようにする) ために、マルチレベルの DFD を作成できます。上位レベルの DFD は詳細度が低くなります (下位レベルでより詳細な DFD を集約します)。コンテキスト DFD は階層の最上位にあります (DFD 作成ルールを参照)。いわゆるゼロレベルの次には、DFD 0 が続き、プロセス番号 (プロセス 1、プロセス 2 など) から始まります。次の、いわゆる第 1 レベル (DFD 1) では、番号付けが続きます。たとえば、プロセス 1 は、DFD の最初の 3 つのレベルに分割され、1.1、1.2、1.3 と番号が付けられます。同様に、第 2 レベル (DFD 2) のプロセスには、2.1.1、2.1.2、2.1.3、2.1.4 と番号が付けられます。レベルの数は、モデルシステムのサイズによって異なります。DFD 0 のプロセスには、同じ数の分解レベルがない場合があります。 DFD 0 には、最も重要な (集約された) システム機能が含まれています。最下位レベルには、A4 用紙 1 枚程度のプロセス仕様を作成できるようなプロセスを含める必要があります。ミニ仕様が長くなる場合は、プロセスが複数のプロセスに分解されるレベルを追加作成するのが適切です。DFD 階層全体を明確に把握するには、垂直 (断面) ダイアグラムを作成できます。倉庫は、最初に使用される最上位レベルと、それより下位のすべてのレベルに表示されます。^[7]

参照

参考文献

^ ab Bruza, PD; van der Weide, Th. P. (1990-11-01). 「ハイパーテキストビューの品質評価」ACM SIGIR フォーラム24 ( 3): 6– 25. doi :10.1145/101306.101307. ISSN 0163-5840. S2CID 8507530.
^ Martin, David; Estrin, Gerald (1967-04-01). 「計算モデルとシステム - 計算グラフモデルにおける頂点確率の評価」Journal of the ACM . 14 (2): 281– 299. doi :10.1145/321386.321391. ISSN 0004-5411.
^ abc エドワード・ユアドン、ラリー・L・コンスタンティン（1975年）。構造化デザイン。ニューヨーク：ユアドン社。pp.54-55。OCLC 1036882595 。
^ Bergland, GD (1978-06-19). 「構造化設計方法論」.第 15 回設計自動化会議. 米国ネバダ州ラスベガス: IEEE プレス. pp. 475– 493. doi :10.1109/DAC.1978.1585214.
^ ab DeMarco, Tom (1979).構造化分析とシステム仕様。Prentice-Hall ソフトウェアシリーズ。Englewood Cliffs、NJ: Prentice-Hall。ISBN 978-0-13-854380-8。
^ ab ゲイン、クリス、サーソン、トリッシュ (1979)。構造化システム分析: ツールとテクニック。プレンティス・ホール・ソフトウェア・シリーズ。ニュージャージー州エングルウッド・クリフス: プレンティス・ホール。ISBN 978-0-13-854547-5。
^ abcdefgh Yourdon, Edward (1975). 「構造化プログラミングと構造化デザインの芸術形式」。1975年 5 月 19 日から 22 日まで開催されたNational Computer Conference and Exposition on - AFIPS '75 の議事録。p . 277。doi : 10.1145/1499949.1499997。S2CID 36802486 。
^ Tangkawarow, IRHT; Waworuntu, J (2016 年 4 月). 「ビジネスプロセスモデリング手法の比較」. IOP カンファレンスシリーズ: 材料科学および工学. 128 (1): 012010. Bibcode :2016MS&E..128a2010T. doi : 10.1088/1757-899X/128/1/012010 . ISSN 1757-8981.
^ ラーマン、クレイグ (2012)。UMLとパターンの適用: オブジェクト指向分析と設計および反復開発入門(第 3 版)。ニューデリー: ピアソン。ISBN 978-8177589795. OCLC 816555477.
^ ジェパ、ヴァーツラフ (1999)。システム情報の分析(Vyd. 1 ed.)。プラハ：エコプレス。ISBN 978-8086119137. OCLC 43612982.

文献

スコット・W・アンブラー著『オブジェクト入門第3版 UML 2によるアジャイルモデル駆動開発』
Schmidt, G.、Methode und Techniken der Organisation。 13. 8月、ギーセン 2003
Stahlknecht、P.、Hasenkamp、U.: Einführung in die Wirtschaftsinformatik。 12. 8月、ベルリン 2012
ゲイン、クリス、サーソン、トリッシュ。構造化システム分析：ツールとテクニック。ニューヨーク：Improved Systems Technologies、1977年。ISBN 978-0930196004。373ページ
デマルコ、トム。構造化分析とシステム仕様。ニューヨーク：ユアドン・プレス、1979年。ISBN 978-0138543808。352ページ。
エドワード・ユアドン著『構造化設計：コンピュータプログラムとシステム設計の分野の基礎』ニューヨーク：ユアドン・プレス、1979年。ISBN 978-0138544713。473ページ。
Page-Jones, Meilir.構造化システム設計の実践ガイド. ニューヨーク: Yourdon Press, 1988. ISBN 978-8120314825 . 384 ページ。
エドワード・ヨードン著『現代構造分析』ニューヨーク：ヨードン・プレス、1988年。ISBN 978-0135986240。688頁。

外部リンク

ウィキメディア・コモンズのデータフロー図に関連するメディア

[:0-1] Bruza, PD; van der Weide, Th. P. (1990-11-01). 「ハイパーテキストビューの品質評価」ACM SIGIR フォーラム24 ( 3): 6– 25. doi :10.1145/101306.101307. ISSN 0163-5840. S2CID 8507530.

[2] Martin, David; Estrin, Gerald (1967-04-01). 「計算モデルとシステム - 計算グラフモデルにおける頂点確率の評価」Journal of the ACM . 14 (2): 281– 299. doi :10.1145/321386.321391. ISSN 0004-5411.

[:2-3] エドワード・ユアドン、ラリー・L・コンスタンティン（1975年）。構造化デザイン。ニューヨーク：ユアドン社。pp.54-55。OCLC 1036882595 。

[4] Bergland, GD (1978-06-19). 「構造化設計方法論」.第 15 回設計自動化会議. 米国ネバダ州ラスベガス: IEEE プレス. pp. 475– 493. doi :10.1109/DAC.1978.1585214.

[:3-5] DeMarco, Tom (1979).構造化分析とシステム仕様。Prentice-Hall ソフトウェアシリーズ。Englewood Cliffs、NJ: Prentice-Hall。ISBN 978-0-13-854380-8。

[:4-6] ゲイン、クリス、サーソン、トリッシュ (1979)。構造化システム分析: ツールとテクニック。プレンティス・ホール・ソフトウェア・シリーズ。ニュージャージー州エングルウッド・クリフス: プレンティス・ホール。ISBN 978-0-13-854547-5。

[:1-7] Yourdon, Edward (1975). 「構造化プログラミングと構造化デザインの芸術形式」。1975年 5 月 19 日から 22 日まで開催されたNational Computer Conference and Exposition on - AFIPS '75 の議事録。p . 277。doi : 10.1145/1499949.1499997。S2CID 36802486 。

[8] Tangkawarow, IRHT; Waworuntu, J (2016 年 4 月). 「ビジネスプロセスモデリング手法の比較」. IOP カンファレンスシリーズ: 材料科学および工学. 128 (1): 012010. Bibcode :2016MS&E..128a2010T. doi : 10.1088/1757-899X/128/1/012010 . ISSN 1757-8981.

[9] ラーマン、クレイグ (2012)。UMLとパターンの適用: オブジェクト指向分析と設計および反復開発入門(第 3 版)。ニューデリー: ピアソン。ISBN 978-8177589795. OCLC 816555477.

[10] ジェパ、ヴァーツラフ (1999)。システム情報の分析(Vyd. 1 ed.)。プラハ：エコプレス。ISBN 978-8086119137. OCLC 43612982.