DFDとは？ わかりやすく10分で解説

DFD（Data Flow Diagram）とは

DFDは、ソフトウェア制作を依頼する側と作る側の認識を合わせるツールとして使用されます。システムのイメージを共有するのに役立ち、機能の漏れや重複を防ぐことが可能となります。

これは基本的にシステムやソフトウェアの詳細について描写するためのツールであり、それはデータの流れや処理、記憶方法といったものです。

この記事では、DFDの基本的な概念や書き方、この設計ツールの効果的な使用方法について解説します。

DFDの定義

DFD、つまり、Data Flow Diagramは、システム中でデータがどのように移動するか、また、それがどのように処理され保存されるかを表す図のことを指します。

主要な記号としては、「データフロー」「プロセス」「データストア」「源泉と吸収」の4つがあります。これらはトム・デマルコが提案した構造化分析の一部として用いられます。

DFDは、それぞれデマルコ式やゲイン・サーソン式といった異なる描き方が存在しますが、どちらもプロジェクトの理解と共有に役立てるためのものです。

DFDの目的と利用シーン

DFDの主な目的は、システムのデータの流れを明確化し、それを通じてシステムの設計者や利用者、そして開発者がインタラクションの全体像を理解することができるようにすることです。

主に、ソフトウェア開発やビジネスプロセスの再設計、データベース設計、情報システムの設計など、データの流れを理解することが重要とされる場面で利用されます。事前にDFDを使用することで、余計な誤解を避けることができます。

また、DFDはシステムの新規開発だけでなく、既存システムの改修やアップデート、何か新しい要素を追加するといった場合の設計にも活用できます。

DFDの起源と歴史

DFDは1970年代に、情報システムデザインの一部として提案されました。これは、当時多くの企業がコンピュータを導入し、情報処理の複雑さが増してきた時期であり、その高度化に対応するための手法として生まれました。

起源は、ソフトウェア工学の一部として提唱され、特にトム・デマルコとエドワード・ヨードンによる構造化設計の一環として紹介されました。彼らはそれぞれ独自のDFD記号を提案し、それらは現在でも広く用いられています。

その後もDFDは進化を続け、現在では多数のバリエーションがあるため、プロジェクトのニーズに合わせて最適なスタイルを選択することができます。

DFDと他の設計ツールとの比較

DFDは他の設計ツールと比較して、特に「ビジュアルの表現力」に優れています。まさに、一枚の図で全体像をつかめるというメリットがあります。

例えば、UML（Unified Modeling Language）やER図（Entity-Relationship Diagram）などもシステム設計のための図表ですが、それぞれに異なる強みがあります。

UMLはソフトウェアの振る舞いをモデル化しますが、DFDはデータの流れを強調します。ER図はデータ構造を強調しますが、DFDはプロセスとデータの流れを強調します。このように、それぞれ異なる視点からシステムを解釈できます。

DFDの構造と記号

DFDの構造と記号について詳しく見ていきましょう。DFDには「データフロー」「プロセス」「データストア」「源泉と吸収」という4つの主要な要素があり、それぞれ特定の記号で表現されます。これらの記号を理解することで、DFDを読み解く力が高まります。

データフローとは

データフローは、システム内で移動するデータの流れを示す記号です。一般的には矢印で描かれ、その流れる方向がデータの移動方向を示しています。これを理解することで、システム内のデータの流れがどのように行われているかが把握できます。

なお、データフローには名前をつけることが推奨されています。これにより、何のデータがどこからどこへ流れているのか具体的に分かるようになり、DFDの可読性が向上します。

また、データフローは他の3つの要素、つまりプロセス、データストア、源泉と吸収の間で発生します。データがどの要素間を移動しているのかを理解することで、さらに具体的なシステムの流れを把握できます。

プロセスとは

次に、プロセスです。これは、システム内で行われる特定の操作やタスクを表す記号で、一般的には円形や四角形などで描かれます。プロセスが何を意味するのかを理解することで、システムの動作や役割を把握できます。

プロセスには入力と出力のデータフローが必要です。これにより、そのプロセスがどのようなデータを受け取り、どのように処理し、そしてどのようなデータを出力するのかが具体的に見えるようになります。

さらに、プロセスが複雑で詳細な設計が必要な場合、そのプロセス自体をさらに細かいプロセスに分解することも可能です。これにより、より具体的で詳細なシステム設計を行うことができます。

データストアとは

データストアは、システム内でデータが一時的に保管される場所を表す記号で、一般的には二本線で表現されます。データストアが何を意味するのかを理解することで、システムのデータ保管や管理の仕組みを理解できます。

データストアもまた、入力と出力のデータフローが必要です。これにより、そのデータストアにどのようなデータが保存され、どのように取り出されるのかが具体的に見えるようになります。

データストアとプロセスの間でデータがやり取りされることから、データストアはプロセスの一部と考えることもできます。これにより、システムの全体像を把握するのに役立ちます。

源泉と吸収の意味

最後に、源泉と吸収です。これらはシステムの入出力を表す記号で、一般的には四角形で表されます。源泉はシステムへのデータの入力を、吸収はシステムからのデータの出力をそれぞれ示します。

これらの記号は、システム外からの入力やシステム外への出力を明示的に示すことができます。これにより、システムとその外部とのやり取りを明確に理解することができます。

また、源泉と吸収の記号はシステムの境界を明確に示す役割も果たします。つまり、DFDを通じてシステムの「内」「外」が明確に分かれ、その結果、システムの全体像を把握するのに役立ちます。

DFDの書き方とルール

データフロー図（DFD）を書くときには、いくつかのルールが存在します。ここでは、それぞれの基本ルール、及びデマルコ式とゲイン・サーソン式の違い、DFDの描き方、そして常に発生する作成エラーとその回避策について詳しく解説します。

DFDを始める前に

DFDを初めて書く方でも理解しやすいよう、まず必要な基本的な概念と規則から始めましょう。最初に理解しておくべきことは、「データフロー」「プロセス」「データストア」「源泉と吸収」という4つの基本的な記号です。

また、それぞれの記号が持つシンボリズムを知ることも重要です。システム内の変化やデータの移動を示す「データフロー」、具体的な操作や処理を表す「プロセス」、情報が保存される「データストア」、そしてシステムの外部からデータが流れ込んだり、システムから外部へデータが流れたりすることを示す「源泉と吸収」などが挙げられます。

これらの記号をマスターすることで、DFDの構造を理解しやすくなり、読み書きがスムーズになります。また、より詳細な情報を表すためには、「データディクショナリ」という文書も併用することで、より具体的なデータ定義を追加することができます。

デマルコ式とゲイン・サーソン式の違い

DFDにはデマルコ式とゲイン・サーソン式という2つの描き方があり、それぞれが微妙に異なる特徴を持っています。これらの違いを理解することで、用途に応じて最適な表現方法を選択することができます。

デマルコ式は、データフローを矢印、プロセスを円形、データストアを2つの平行線で示し、比較的シンプルな記法でありながら、情報の流れや処理内容を分かりやすく表現できます。その一方で、複雑なシステムでは記述が難しくなる可能性があります。

一方のゲイン・サーソン式は、データフローは同様に矢印で示しますが、プロセスを斜面付きの四角形、データストアを直線で表します。この方式では、プロセス間の関連性をより明示的に示すことが可能で、便利な一面を持っています。

ステップバイステップでDFDを書く

手掛けるシステムが大きいほどDFDは複雑になりますが、何から手をつけてよいかわからないときは、最上層から順にDFDを書いていくことをお勧めします。これをトップダウンアプローチと呼びます。

最初は、システム全体を捉えた大まかなDFD（コンテキスト図）を作ります。その後、各プロセスを更に詳細に分解して中間層のDFDを作成していきます。これを繰り返して、最終的には詳細なレベルまでDFDを作っていきます。

なお、この手法は伝達と受け取りが容易で、また途中で設計変更が出ても比較的容易に対応できるため、初めてのDFD作成には非常に適しています。

DFD作成時のエラーとその回避策

DFDの作成は繊細な作業であり、さまざまなエラーが発生します。一般的なエラーには、データフローが不完全である場合や、データフローの方向が間違っている場合などがあります。

これらのエラーは通常、DFDを確認する過程で発見して修正します。しかし、エラーが大量に発生するとその修正作業自体が重荷となり、設計の品質を低下させる可能性があります。

エラーを避けるためには、きちんとした描き方とルールを理解し、逐一チェックしながら作成を行うことが重要です。また、他のメンバーにもDFDのレビューを依頼することで、客観的なフィードバックを得ることができます。

DFDとレイヤリング

DFDの大きな特徴の一つに「レイヤリング」があります。これはシステムを階層化し、一度に見る範囲を限定することで複雑なシステムを見やすくし、理解しやすくするというテクニックです。

コンテキストダイアグラムとは

最初に作成するDFDを「コンテキストダイアグラム」と呼びます。コンテキストダイアグラムは、システム全体の大まかな流れを示したもので、全体のビジョンを把握する上で非常に重要です。ここではシステムの境界を明確にし、システムの外部からの入力とその結果の出力を確認します。

コンテキストダイアグラムはDFDの最上位レベルに位置しますが、あくまで全体像を掴むためのものなので詳細な情報は含まれません。複雑なシステムを一つの図で表すため、具体的なデータの流れや個々のプロセスは省略されます。

コンテキストダイアグラムは、その後のレイヤリング作業の基盤となるので、十分な情報収集とその理解がとても重要です。

システムをレイヤリングする意味

DFDのレイヤリングは、大きなシステムを小さな部分に分け、それぞれを個別に理解・計画するための方法です。多くの領域やプロセスが関連付けられている複雑なシステムの場合、全体像だけでは理解しきれない部分が出てきます。それを解決するのがレイヤリングの役割です。

各レイヤーでは、一部のリアルなプロセスとデータフローに焦点を当て、その部分だけを詳しく見ることができます。一つ一つのレイヤーが組み合わさることで全体像が浮かび上がり、システム全体の理解を深めることができます。

レイヤリングにより個々のプロセスの理解を深めるだけでなく、各プロセス間の関係性やデータの流れを可視化することで、より効率的なシステム設計や改善策を見つけることができます。

レイヤリングのテクニック

レイヤリングのテクニックの一つとして、プロセスを複数の小さなタスクに分割する「分解」があります。これは、大きな問題を解決可能な小さな問題に分けることで、解決策を見つけやすくするという思想に基づいています。

また、一つのプロセスが持つ複数の役割を見つけ、それぞれに焦点を当てることで、各役割がシステム全体にどう影響を及ぼしているのか、その関連性を理解することにも有効です。

十分なレイヤリングのためには、全体としてのシステム理解だけでなく、各プロセスの細部に関する知識も不可欠です。各プロセスやデータフローについて詳しく調査することでより精度の高いレイヤリングを行うことができます。

DFDとデータディクショナリ

システム分析と設計において、データフローダイアグラム(DFD) とデータディクショナリは重要な役割を果たします。それぞれがどのように機能し、どのように連携してシステムの理解、設計、そして開発を助けるのかを解説します。

本節では、これらのツールを使用して、データの流れを明確にし、データのアイテムがどのようにプロセスに影響するかを理解する方法を説明します。

DFDとデータディクショナリは、システムの設計者とユーザーが共通の言語でコミュニケーションを取るためのツールです。それぞれの用途と機能性について詳しく見ていきましょう。

データディクショナリとは

データディクショナリは、システム内のデータに関する情報を中央に集約したリポジトリです。一般的に、データアイテムの名前、型、長さ、使用される場所、どのように生成されてどこで使用されるかといった情報を保持します。

これらはシステムの全体的な理解を深めるための情報であり、データディクショナリは通常、DFDと密接に関連して作成および使用されます。

あるデータのアイテムがどのように関連するプロセスに影響を与えるのかを追跡する際に役立ちます。

データディクショナリの使用方法

システム内のすべてのデータエレメントの詳細について記録されるデータディクショナリは、システム全体の理解を深めることに役立ちます。データアイテムが、それがどのように扱われ、どのプロセスで使用されるかを説明します。

例えば、顧客情報などのデータ群に対する変更を管理するためなどに使用されます。

さらに、デプロイ：または稼働前のテストプロセスをサポートし、データの整合性とエラーの発見にも役立ちます。

DFDとデータディクショナリの協調

DFDとデータディクショナリは相互補完関係にあります。DFDはデータの流れを視覚的に表現し、データディクショナリはそのデータの詳細を説明します。

DFDの各要素は、データディクショナリによって詳細に説明され、それぞれのデータエレメントがその系列の中でどのように動作するのかを示します。

DFDとデータディクショナリの組み合わせは、システム設計の明確化、エラーの最小化、労力の節約につながります。

データディクショナリ作成のヒント

ユースケース、フィールド定義、データ型、依存関係など、データがどのように使用されるかに関する詳細は、データディクショナリに記載する重要な要素です。作成過程でこれらの要素を見落とさないようにしましょう。

さらに、プロジェクト全体を通じてデータディクショナリを最新の状態に保つことが重要です。更新された情報を含めることで、プロジェクトチーム全体が最新のデータ構造とフローについて誤解なく理解することができます。

最後に、データディクショナリは共有文書であるべきで、プロジェクトチーム全体が参照できる位置に置きましょう。これによって情報の誤解を防ぎ、プロジェクト全体の進行をスムーズにします。

プロセスの詳細化

DFDのプロセス詳細化に役立つ重要な2つのツール、「ミニ仕様書」および「デシジョンテーブル」について解説していきます。これらは、DFDで示されるプロセスの詳細な動作を明確化し、プログラミングを行う際の参考にするための重要な情報を提供します。

それぞれの特性や使い方を把握することにより、システムの設計がよりスムーズになるでしょう。また、これらを適切に使うことで、システム開発の品質を向上させることが可能となります。

ミニ仕様書とは

ミニ仕様書は、DFDにおけるある一つのプロセスの詳細を記述するための文書です。これにより各プロセスの実際の振る舞い、適用条件、出力結果などが具体的に明らかになります。

ミニ仕様書は、各プロセスの具体的な動作を理解しやすくするために非常に重要であり、プログラミング作業の基準となる情報を提供します。また、プロジェクトメンバーや利害関係者との円滑なコミュニケーションも支えます。

デシジョンテーブルとは

一方、デシジョンテーブルは、ある制約条件に基づいて判断を行ない、それに対応する適切なアクションを自動的に決定するための表現方法です。これは、複雑な条件を整理し、透明性を保つことによってプログラムの複雑性を減らすことが目的です。

デシジョンテーブルは、特に条件が多いあるいは複雑なプロセスに適しており、条件の一部が変更された場合でも影響範囲がわかりやすく、修正作業も容易になります。

ミニ仕様書とデシジョンテーブルの相互関係

ミニ仕様書とデシジョンテーブルは、DFDで示されるプロセスの詳細を表現するための補完的なツールであり、一緒に使用することで効果を発揮します。ミニ仕様書はプロセスの概要を示し、デシジョンテーブルはその詳細な処理の流れを明確にします。

これら2つのツールは、それぞれが持つ強みを活かし、システムにおける情報フローと処理フローを共同で明示することで、設計の完全性と整合性を確保する助けとなります。

効果的なミニ仕様書とデシジョンテーブルの書き方

効果的なミニ仕様書とデシジョンテーブルの作成には、プロセスごとに適切な詳細レベルを確保することが重要です。情報が過剰になると読解の困難さが増し、管理も複雑になる可能性があります。

また、ミニ仕様書にはプロセスが扱う主要な条件や制約を記述し、それに対応する詳細な判断ルールやアクションはデシジョンテーブルで視覚的に示すと良いでしょう。

そして最後に、これらのドキュメントはシステムの開発や保守全体を通じて反復的に見直しと更新を行い、最新のシステムの状況を正確に反映させることが求められます。