データフロー図(DFD)は、情報がシステムの中をどう動くかを示します。どこから来て、何がそれを変換し、どこに保存され、どこへ行くのか。タイミングやループ、どのサーバーが何を実行するかについては何も語りません。それこそが DFD の強みです。DFD は、システムがどんなデータを扱うのかについて合意する最速の方法であり、だからこそ要件定義、プライバシーレビュー、脅威モデリングに登場します。
この記事では、まず 2 つの古典的な記法で DFD の記号を説明し、次に 1 つの例であるオンラインストアを 3 つのレベルで見ていきます。コンテキスト図、レベル 0、レベル 1 です。さらに「レベル 0」をめぐる呼び方の混乱、レベル間の一貫性を保つバランシングのルール、レビュアーが探す誤りも説明します。
DFD の記号
DFD は 4 つの要素を使います。主流の記法は 2 つあり、どちらも 1970 年代後半の構造化分析の書籍に由来します。Yourdon と DeMarco の記法、そして Gane と Sarson の記法です。
| 要素 | 意味 | Yourdon と DeMarco | Gane と Sarson |
|---|---|---|---|
| 外部エンティティ | 境界の外にあり、データを送受信する人、組織、システム | 長方形 | 正方形(影付きが多い) |
| プロセス | データを変換する処理 | 円(バブル) | ID 帯付きの角丸長方形 |
| データストア | 静止しているデータ:テーブル、ファイル、キュー | 2 本の平行線 | 片側が開いた長方形(D1 のような ID 付き) |
| データフロー | 動いているデータ。名詞で名前を付ける | 矢印 | 矢印 |
2 つの記法は等価です。どちらかを選んで統一してください。最近のツールの多くはデータストアを円柱で描き、読み手はすぐにそれと分かります。どれを選ぶにしても、凡例を付けましょう。
DFD を正しくするルール
- すべてのプロセスには少なくとも 1 つの入力と 1 つの出力があります。 入力しかないプロセスはブラックホール、出力しかないプロセスは奇跡です。
- データはプロセスを通してのみ移動します。 外部エンティティからデータストアへ直接、データストアから別のデータストアへ、あるいは 2 つの外部エンティティの間を直接結ぶフローはありません。
- フローにはデータを表す名前を付けます。 たとえば「注文明細」や「決済結果」であり、「送信」や「確認」のような動作ではありません。
- プロセスは動詞と目的語で名付けます。 「注文を受け付ける」「注文を出荷する」のようにします。
- 各プロセスには番号を付け、分解した子プロセスはその番号を引き継ぎます。プロセス 1 は 1.1、1.2、1.3 になります。
レベルと「レベル 0」の混乱
DFD はトップダウンで、詳細度を上げながらレベルごとに描きます。
- コンテキスト図は、システム全体を 1 つのプロセスとして示し、そのまわりにすべての外部エンティティとそれらとのフローを置きます。境界を定義する図です。
- 次のレベルでは、その 1 つのプロセスを主要なプロセスに分解し、データストアを加え、外部とのフローはそのまま保ちます。
- さらに下のレベルでは、個々のプロセスを必要なだけ分解します。
ここで混乱が生じます。教科書やツールの中には、コンテキスト図を「レベル 0」、その最初の分解を「レベル 1」と呼ぶものがあります。一方、古い構造化分析の慣習に従うものは、コンテキスト図を独立したレベルとして扱い、最初の分解を「ダイアグラム 0」または「レベル 0」と呼びます。どちらも間違いではありません。この記事では後者の慣習を使い、コンテキスト図、レベル 0、レベル 1 の順に進みます。どちらを使う場合でも、図に明記してください。
例:オンラインストア
オンラインストアは顧客から注文を受け、決済代行サービスを通じて代金を請求し、商品を発送する倉庫にピッキングリストを送ります。
コンテキスト図
1 つのプロセス「0 Online store」と、3 つの外部エンティティです。
| フロー | 送り手 | 受け手 |
|---|---|---|
| Order details | Customer | Online store |
| Order confirmation | Online store | Customer |
| Payment request | Online store | Payment provider |
| Payment result | Payment provider | Online store |
| Pick list | Online store | Warehouse |
| Shipment status | Warehouse | Online store |
これが外から見たシステムのすべてです。誰でも 1 分でレビューでき、すでに重要な問いに答えています。どの組織が顧客データを受け取るのか、そして私たちはどのシステムに依存しているのか、です。
レベル 0
オンラインストアを 3 つのプロセスと 2 つのデータストアに分解します。
- Take order は顧客から注文明細を受け取り、D2 Products から価格を読み、注文を D1 Orders に書き込み、決済要求をプロセス 2 に渡します。
- Process payment は決済要求を決済代行サービスに送り、決済結果を受け取り、D1 Orders の注文を更新し、支払い済みの注文をプロセス 3 に渡します。
- Fulfil order は支払い済みの注文を読み、ピッキングリストを倉庫に送り、出荷状況を受け取り、注文確認を顧客に送ります。
コンテキスト図の外部フローは、すべてレベル 0 にも同じエンティティにつながった形で再び現れます。これがバランシングであり、下の図はそれを目に見える形にしています。
レベル 1
レベル 0 の各プロセスはさらに分解できます。プロセス 1 の Take order をレベル 1 で見ると次のとおりです。
| プロセス | 入力 | 出力 |
|---|---|---|
| 1.1 カートを検証する | Customer からの Order details | 有効なカート |
| 1.2 注文の価格を計算する | 有効なカート、D2 Products からの商品価格 | 価格付きの注文 |
| 1.3 注文を記録する | 価格付きの注文 | D1 Orders への新しい注文、プロセス 2 への決済要求 |
1.1 から 1.3 までの入力と出力を合わせたものは、レベル 0 におけるプロセス 1 の入力と出力に一致しなければなりません。レベル 1 の展開はそれぞれ別の図として描き、タイトルに親プロセスの番号を入れます。
バランシング:レビュアーが最初に確認するルール
子の図は、そこに出入りするデータフローが親プロセスに出入りするフローと等しいとき、バランスが取れています。コンテキスト図にない「返金依頼」というフローがレベル 0 にあれば、どちらかが間違っています。誰も合意していないインターフェースがシステムにあるか、コンテキスト図が不完全かのどちらかです。バランシングがあるからこそ、DFD のレベルは一式として信頼できます。各レベルの外部フローを並べて書き出せば、簡単に確認できます。
よくある誤り
- フローチャートを描いてしまう。 判断、ループ、「次に」を表す矢印は、フローチャートか BPMN 図に属するものです。DFD が示すのは制御ではなくデータです。
- 名前のないフロー。 ラベルのない矢印はレビュアーに何も伝えません。運ぶデータに名前を付けましょう。
- 1 枚の図にプロセスが多すぎる。 1 つのレベルにおよそ 7〜9 個を超えるプロセスがあると読みにくくなります。グループにまとめ、次のレベルでグループを分解します。
- データを受け取るだけのデータストア。 何も読み出さないストアは、なぜ存在するのでしょうか。何も書き込まないストアのデータは、どこから来るのでしょうか。
- レベルを混在させる。 詳細なサブプロセスを上位のプロセスと同じ図に並べると、階層が崩れます。
DFD、フローチャート、アーキテクチャ図
| データフロー図 | フローチャート | アーキテクチャ図 | |
|---|---|---|---|
| 示すもの | データ、その発生源、変換、保存 | ステップ、判断、順序 | コンポーネント、デプロイ、接続 |
| 時間と順序 | なし | あり | まれ |
| 適した用途 | 要件、プライバシーレビュー、脅威モデル | 手順とアルゴリズム | 設計と運用 |
DFD は脅威モデリングの標準的な入力です。レベル 0 の図に信頼境界を加えれば、STRIDE レビューの土台になります。詳しくは脅威モデリング用データフロー図の記事を参照してください。プライバシーの作業でも同じように役立ちます。GDPR データマッピング図は、同じ種類のフローで個人データの流れを追跡します。
DFD のレベルを示す図
ダイアグラムの内容
- Context diagram
- 0 Online store
- Customer
- Payment provider
- Warehouse
- Level 0
- 1 Take order
- 2 Process payment
- 3 Fulfil order
- D2 Products
- D1 Orders
- order details
- order confirmation
- payment request
- payment result
- pick list
- shipment status
- order to pay
- paid order
- prices
- new order
- payment status
図の読み方は次のとおりです。
- 外部エンティティは中央にあります:Customer、Payment provider、Warehouse です。両方の図がこれらにつながります。
- 左のフレームはコンテキスト図です:1 つのプロセス 0 Online store が、エンティティとの間に 6 本の名前付きフローを持ちます。
- 右のフレームはレベル 0 です:Take order、Process payment、Fulfil order と、Orders と Products のデータストアです。
- バランシングが目に見えます:左の外部フローはすべて右にも現れ、今度はそれを処理するプロセスにつながっています。
- Markdown ブロックは凡例と番号付けのルールです。
レビューに耐える DFD を描くには
- すべてのフローに名詞で名前を付けます。 DFD へのレビューコメントの大半は、ラベルのない矢印や曖昧なラベルの矢印に関するものです。
- レベルをまたいで一貫した番号を付け、読み手が 1.2 から 1 へたどれるようにします。
- 外部エンティティはどのレベルでも同じ位置に置きます。 バランシングが一目で分かります。
- 記法の凡例を付けます。 古典的な記号とデータストア用の円柱を混ぜる場合は特に重要です。
ほかの図の記法については、フローチャート形式のインシデント対応の例とBPMN 図の例を参照してください。
Archboard で作る
- Google または GitHub でサインインし、図を作成します。
- 中央の列に、Customer、Payment provider、Warehouse 用として基本パックの ボックス ノードを 3 つ追加します。
- 左側に Context diagram という名前の基本パックの フレーム を追加し、その中に 0 Online store 用として基本パックの 楕円 の図形を 1 つ置きます。
- 右側に Level 0 という名前の 2 つ目の フレーム を追加し、プロセス用に 楕円 の図形を 3 つ、D1 Orders と D2 Products 用に 円柱 の図形を 2 つ置きます。
- フローをラベル付きのエッジとして描き、エンティティの両側で同じラベルを使います。
- 凡例と番号付けのルールを書いた基本パックの Markdown ブロックを追加します。
この例で使うダイアグラムノードは 12 個で、Free プランの範囲に収まります。
よくある質問
データフロー図の 4 つの記号とは何ですか? 外部エンティティ、プロセス、データストア、データフローです。Yourdon と DeMarco はプロセスを円、データストアを平行線で描き、Gane と Sarson は角丸長方形と片側が開いた長方形を使います。
コンテキスト図とレベル 0 の DFD の違いは何ですか? コンテキスト図は、システム全体を外部エンティティとともに 1 つのプロセスとして示します。次のレベルでは、そのプロセスを主要なサブプロセスとデータストアに分解します。コンテキスト図をレベル 0 と呼ぶ資料もあるので、どの慣習を使うかを明記してください。
DFD におけるバランシングとは何ですか? 子の図に出入りするデータフローは、親プロセスのフローと一致しなければなりません。これにより、すべてのレベルが同じシステムを表していることが保証されます。
DFD とフローチャートはどう違いますか? DFD は、どのデータがどこへ動き、どう変換されるかを、順序や判断なしで示します。フローチャートは、ステップの順序とその間の判断を示します。
DFD にはいくつのレベルが必要ですか? 読み手が必要とするだけです。ほとんどのシステムはコンテキスト図とレベル 0 で十分に表現でき、レベル 1 の図は複雑なプロセスや機密性の高いプロセスにだけ描けば足ります。