データフローダイアグラム（DFD）は、システム分析および設計において重要な視覚的ツールです。情報の流れをシステム内にマッピングし、データが入力から出力へどのように移動するかを示します。フローチャートが制御論理に注目するのに対し、DFDはデータそのものの移動に焦点を当てます。この違いは、実行のタイミングや条件に巻き込まれず、システムの本質を理解する必要があるアーキテクトやアナリストにとって極めて重要です。
DFDを作成するには構造的なアプローチが必要です。単に図形を描くことではなく、プロセスの論理とデータ整合性をモデル化することです。新しいソフトウェアアプリケーションの設計、既存のワークフローの監査、ビジネスプロセスのマッピングなど、あらゆる場面で、適切に構築された図は明確さを提供します。ステークホルダーがシステムの境界を視覚化し、データの発生源や保存場所を特定するのに役立ちます。
コアコンポーネントの理解 🧩
線やボックスを描く前に、基本的な構成要素を理解する必要があります。すべてのDFDは4つの主要な要素で構成されています。これらのコンポーネントを認識することで、図が一貫性を持ち、読みやすくなることが保証されます。
- 外部エンティティ： これらはデータの発生源または到着先です。システムの境界外に存在します。エンティティはユーザー、別のシステム、または組織である可能性があります。図では、通常、四角形または円で表されます。
- プロセス： ここがアクションが起こる場所です。プロセスは入力データを出力データに変換します。データに対して行われる作業を表します。プロセスには最低1つの入力と1つの出力が必要です。通常、ラウンドされた長方形または円で描かれます。
- データストア： これらはデータが後で使用するために保持される場所を表します。物理的なデータベース、ファイルキャビネット、あるいはメールの受信箱なども含まれます。アクションを開始するのではなく、情報を保持するだけです。データストアは、開口部のある長方形や平行線で描かれることがよくあります。
- データフロー： これらはコンポーネントをつなぐ矢印です。データの移動方向を示します。各矢印には、転送されているデータの名前をラベル付けする必要があります。
データがプロセスを介さずに、1つのエンティティから別のエンティティへ直接移動することはできず、データストアからエンティティへもプロセスを介さずに移動することはできません。これらのルールがモデルの論理的整合性を保ちます。
表記スタイルの選択 🖊️
DFDを描くための主な方法は2つあります。同じ基本的な論理を共有していますが、視覚的な表現は異なります。適切なものを選ぶには、チームの好みや特定の業界標準に基づく必要があります。
| 特徴 | YourdonとDeMarco | GaneとSarson |
|---|---|---|
| プロセス | ラウンドされた円 | ラウンドされた長方形 |
| データストア | 開口部のある長方形 | 太い側面を持つ開口部のある長方形 |
| データフロー | カーブした矢印 | カーブした矢印 |
| 外部エンティティ | 長方形 | 長方形 |
YourdonとDeMarcoスタイルはしばしば古い手法と関連付けられるが、GaneとSarsonは現代の構造化分析で広く使われている。選択した図形にかかわらず、一貫性が重要である。単一の文書内でスタイルを混在させると、読者を混乱させる可能性がある。
システム境界の定義 🚧
図を作成する最初のステップは、範囲を定義することである。システムの内部と外部にあるものを明確にしなければならない。これは、コンテキスト図（レベル0DFDとも呼ばれる）を作成することで行われることが多い。
コンテキスト図は、システム全体を単一のプロセスとして表現する。システムと外部エンティティとの高レベルな相互作用を示す。これにより、システムに入力されるデータと出力されるデータの全体像を俯瞰できる。この図を描く際は、入力と出力にのみ注目する。内部プロセスの詳細はまだ記述しない。
たとえば、図書館システムを考えてみよう。システムは単一の円で表される。外部エンティティには「司書」や「会員」などが含まれる。データフローには、システムに入力される「書籍貸出依頼」と、システムから出力される「貸出領収書」がある。このシンプルな視点が、より詳細な分解の基盤となる。
プロセスの分解 🔄
コンテキストが確立されると、システムを分解する必要がある。このプロセスを分解という。コンテキスト図の単一プロセスを複数のサブプロセスに拡張する。これにより、レベル1DFDが作成される。
分解には注意が必要である。ランダムにプロセスを追加してはならない。各サブプロセスは特定のデータ変換を処理しなければならない。データフローがサブプロセスに入力される場合、必ず特定の出力が生じなければならない。データが保存される場合、データストアに接続されなければならない。
分解のための重要なステップ
- サブプロセスの特定： 主プロセスを確認する。どのような明確なタスクを実行しているかを確認する。これらのタスクを別々の円または長方形に分割する。
- データストアの接続： 情報が保存される場所を特定する。タスクがレコードを更新する場合、データストアへのフローを描く。
- データフローの精査： すべての矢印にラベルを付けること。ラベルは動作ではなくデータを説明するものでなければならない。たとえば、「注文送信」ではなく「顧客注文」とする。
- 一貫性の確認： レベル1図のデータフローが、レベル0図の親プロセスの入力と出力と一致していることを確認する。
このプロセスはさらに続くことができる。レベル1のプロセスが複雑すぎる場合は、さらにレベル2DFDに分解できる。この再帰的な分解により、分析者は全体の文脈を失うことなく、特定の関心領域に注目できる。
描画とバランスのルール ⚖️
DFDの構築には厳格なルールがある。これらのルールを違反すると、図が無効となる。最も重要な概念は「バランス」である。
バランスとは、親プロセスの入力と出力が、その子プロセスの入力と出力と一致していることを意味する。レベル0プロセスに「注文」が入力されている場合、レベル1図では同じ「注文」データが子プロセスのいずれかに入力されていることを示さなければならない。上位レベルに存在しなかったデータを下位レベルで新たに導入することはできない。ただし、論理的な詳細である場合は例外である。
追加の描画ルール
- エンティティ間にはデータフローがない： データはプロセスを経由しなければならない。外部エンティティから別の外部エンティティへ直接移動することはできない。
- データストア間にはデータフローがない： データストアは静的データを保持する。それらの間での移動には、データを変換または移動するプロセスが必要である。
- プロセスなしにデータストアへの入力または出力はできない： ストアは独自にデータを生成したり受信したりすることはできない。プロセスが相互作用を制御しなければならない。
- プロセス名の付け方： プロセスには動詞と名詞を組み合わせて名前を付ける。これにより、動作が明確になる。たとえば「税金計算」や「在庫更新」など。
- データフロー名の付け方： フローには名詞句を用いて名前を付ける。これにより、内容が明確になる。たとえば「請求書詳細」や「支払い確認」など。
レビューと改善 🧐
図が作成されると、レビュー段階が不可欠である。これは、誤り、漏れ、明確性の問題を確認するものである。ステークホルダーは図がシステムの心理的モデルと一致しているかを確認する必要がある。
この段階では、ダングリングフロー（どこにもつながっていない矢印）がないか確認する。すべてのフローはプロセス、ストア、またはエンティティに接続されている必要がある。また、線が交差していないか確認する。厳密に禁止されているわけではないが、線が交差すると図が読みにくくなる。交差を避けるようにラインをルーティングする努力をすべきである。
レビューのもう一つの側面は命名規則である。図全体を通して、同じデータが同じ名前で参照されていることを確認する。あるセクションで「顧客ID」と呼ぶなら、別のセクションで「クライアント番号」とは呼ばない。一貫性は理解を助ける。
時間の経過に伴う保守 🛠️
DFDは一度だけ作成するものではありません。システムは進化し、要件も変化します。システムが変化するにつれて、図は新しい現実を反映するように更新されるべきです。古くなった図は、開発者や分析家を誤解させるため、何も描かれていない状態よりも悪いのです。
図のバージョン管理システムを確立しましょう。重要な変更が生じた際には、バージョン番号を更新してください。これにより、システム設計の履歴を追跡できます。また、新しくチームに加わったメンバーがシステムの成長過程を理解するのにも役立ちます。
システム分析との統合 📋
DFDは単独で使用されることがほとんどありません。大きな文書セットの一部です。しばしばデータ辞書やプロセス仕様書とともに使用されます。データ辞書は、図に含まれるデータ要素の属性を定義します。プロセス仕様書は、特定のプロセスバブル内の論理を詳細に記述します。
これらの文書を組み合わせることで、包括的な仕様書を作成できます。この文書は、開発チームがシステムを構築するのを支援します。最終製品が初期の分析と一致することを保証します。
図示手法に関する結論
データフローダイアグラムを作成することは、コミュニケーションのための厳密な訓練です。抽象的な要件を、理解しやすい視覚的な形式に変換します。標準的な構成要素、表記スタイル、バランスルールに従うことで、図がその目的を効果的に果たすことを保証できます。
明確さが目的であることを忘れないでください。ステークホルダーが図を見てシステムを理解できれば、図は成功したといえます。図の内容と矛盾する説明が必要になる場合は、図の見直しが必要です。情報の流れに注目し、表記の整合性を保ち、範囲を明確に保つようにしましょう。練習を重ねることで、正確で有用なデータフローダイアグラムを構築することは、システム設計プロセスの自然な一部になります。