資料流程圖（DFD）：層級、符號與實用範例
學習如何使用正確的符號建立資料流程圖。涵蓋 DFD 0-2 級、Yourdon-DeMarco 與 Gane-Sarson 符號，以及實際範例。
當系統故障或流程產生錯誤輸出時，第一個問題通常是：「資料在哪裡出了問題？」資料流程圖（DFD）透過明確呈現資料的移動，回答了這個問題——精確地顯示資料來自哪裡、去往何處、如何被轉換，以及儲存在哪裡。
與建立控制流（下一步發生什麼）模型的流程圖不同，DFD 建立的是資料流（資料往哪裡移動）的模型。這種差異使它成為系統分析、軟體設計和記錄複雜資料整合的正確工具。
什麼是資料流程圖？
資料流程圖是資料如何在系統中移動的視覺化表示。它顯示：
- 外部實體 — 系統外部的資料來源和目的地
- 流程 — 將輸入資料轉換為輸出資料的轉換過程
- 資料儲存 — 資料靜止存放的地方
- 資料流 — 上述元素之間的資料移動
DFD 不顯示時序、決策邏輯或任務由誰執行。它們僅顯示資料移動。這種聚焦的範疇使它們在理解和設計系統時，不會迷失在實作細節中。
DFD 符號
兩種符號系統佔主導地位：Yourdon-DeMarco 和 Gane-Sarson。它們使用不同形狀表示相同概念。
Yourdon-DeMarco 符號
原始的結構化分析符號，廣泛用於軟體工程：
| 元素 | 符號 | 描述 |
|---|---|---|
| 流程 | 圓圈（氣泡） | 轉換資料；以動詞短語標記 |
| 資料儲存 | 開放式矩形 | 儲存資料；以名詞標記 |
| 外部實體 | 矩形 | 系統外部的來源或目的地 |
| 資料流 | 帶標籤的箭頭 | 在元素之間移動的命名資料 |
┌──────────┐ ╭──────────╮ ┌═══════════════╗
│ 客戶 │───────→ │ 驗證 │───────→ ║ D1: 訂單 ║
└──────────┘ 訂單 │ 訂單 │ 有效 ╠═══════════════╣
╰──────────╯ 訂單 ║ ║
Gane-Sarson 符號
常見於資訊系統和業務分析：
| 元素 | 符號 | 描述 |
|---|---|---|
| 流程 | 圓角矩形（帶分割標題） | 以 ID 和流程名稱標記 |
| 資料儲存 | 左側開放的矩形 | 以 D 編號和名稱標記 |
| 外部實體 | 矩形 | 系統外部的來源或目的地 |
| 資料流 | 帶標籤的箭頭 | 在元素之間移動的命名資料 |
┌──────────┐ ┌────────────────┐ ┌═══╦════════════╗
│ 客戶 │───────→ │ 1.0 │───────→ ║D1 ║ 訂單 ║
└──────────┘ 訂單 │ 驗證訂單 │ 有效 ╚═══╩════════════╝
└────────────────┘ 訂單
應該使用哪種符號？
兩者傳達相同的資訊。根據你的情境選擇：
- Yourdon-DeMarco：在軟體工程、學術領域以及使用結構化分析方法時優先選用
- Gane-Sarson：常見於業務資訊系統和企業情境
選擇一種並在專案的所有圖表中保持一致。
DFD 層級
DFD 以層次結構組織。更高層級的圖表提供概覽；更低層級的圖表提供細節。每個層級將上一層的單個流程分解為其內部子流程。
第 0 級：情境圖
情境圖將整個系統顯示為單一流程，周圍環繞著外部實體。它定義了系統邊界，並顯示跨越該邊界的資料。
客戶訂單
┌──────────┐ ─────────────────→ ╭──────────────────────╮
│ 客戶 │ │ │
└──────────┘ ←───────────────── │ 訂單管理系統 │
訂單確認 │ │
│ │
┌──────────┐ ─────────────────→ ╰──────────────────────╯
│ 供應商 │ 庫存更新 │
└──────────┘ ↓
┌──────────────┐
│ 付款處理 │
└──────────────┘
情境圖應該能放在一頁上，只顯示跨越邊界的資料流——不含內部細節。如果你發現自己在添加內部流程，就代表你的層級不對。
第 1 級：概覽圖
第 1 級圖表將單一的情境流程分解為其主要子流程，即系統的主要功能區域。
┌──────────┐ ╭──────────╮ ╭──────────╮
│ 客戶 │───────→ │ 1.0 │───────→ │ 2.0 │───┐
└──────────┘ 訂單 │ 接收 │已驗證 │ 處理 │ │
│ 訂單 │ 訂單 │ 付款 │ │
╰──────────╯ ╰──────────╯ │
│ ↓
↓ ╭──────────╮
┌════════════════╗ │ 3.0 │
║ D1: 訂單 ║────────────→ │ 履行 │
╚════════════════╝ 訂單資料 │ 訂單 │
╰──────────╯
│
↓
┌──────────┐
│ 物流 │
│ 夥伴 │
└──────────┘
第 1 級圖表通常有 3-7 個流程。如果超過這個數量，考慮將相關流程分組到更少的高層次流程中。
第 2 級：詳細圖
第 2 級將每個第 1 級流程分解為其子步驟。第 1 級的每個氣泡都有自己的第 2 級圖表。
例如，展開上面流程 1.0「接收訂單」：
┌──────────┐ ╭──────────╮ ╭──────────╮
│ 客戶 │──────────→ │ 1.1 │──────────→ │ 1.2 │
└──────────┘ 原始訂單 │ 驗證 │ 有效資料 │ 查詢 │
│ 格式 │ │ 庫存 │
╰──────────╯ ╰──────────╯
│ │ │
無效訂單 │ 有庫存
│ 無庫存│
↓ ↓
┌──────────┐ ╭──────────╮
│ 客戶 │ │ 1.3 │
└──────────┘ │ 保留 │
│ 商品 │
╰──────────╯
│
↓
┌════════════╗
║ D1: 訂單 ║
╚════════════╝
應該分解到多深？
當一個流程滿足以下條件時，停止分解：
- 簡單到可以用幾句話描述
- 由單人或原子性系統功能實作
- 已達到實作所需的細節層級
大多數系統不需要超過第 2 級。第 3 級很罕見，通常表示系統過於複雜或分解結構不夠完善。
DFD 與流程圖的比較
這兩者經常被混淆，因為都使用方框和箭頭。但它們回答的是不同問題。
| 面向 | 資料流程圖 | 流程圖 |
|---|---|---|
| 顯示 | 資料如何在系統中移動 | 控制如何流過流程 |
| 主要問題 | 資料去哪裡？ | 下一步發生什麼？ |
| 時序／順序 | 不建模（僅資料轉換） | 核心——順序是主要結構 |
| 決策邏輯 | 不表示 | 明確（菱形決策節點） |
| 由誰執行 | 不顯示 | 可透過泳道格式顯示 |
| 資料儲存 | 明確的資料儲存符號 | 不表示 |
| 最適合 | 系統分析、資料架構 | 流程文件、程序指南 |
流程圖顯示貸款審批流程中的步驟。DFD 顯示貸款申請系統接收什麼資料、儲存在哪裡，以及產生什麼輸出。
在分析或設計系統時使用 DFD。在記錄程序時使用流程圖。
逐步指南：建立 DFD
第一步：定義系統邊界
識別系統內外的內容：
- 內部： 你控制的流程、資料儲存和資料流
- 外部： 外部實體——客戶、合作夥伴、外部系統
邊界外的一切都是外部實體。跨越邊界的資料在情境圖中顯示為流。
第二步：繪製情境圖（第 0 級）
- 將整個系統作為中心的單一標記圓圈
- 識別所有外部實體並將它們放置在周圍
- 用描述性標籤繪製跨越邊界的資料流
- 檢查完整性：有沒有進入或離開系統的資料未標記？
第三步：識別主要流程（第 1 級）
將系統分解為 3-7 個主要流程：
- 以動詞短語命名每個流程（「驗證訂單」、「處理付款」）
- 為它們編號（1.0、2.0、3.0）
- 識別連接它們的資料流
第四步：添加資料儲存
識別流程之間資料的存放位置：
- 資料庫：客戶記錄、訂單歷史、庫存
- 檔案：日誌檔案、設定
- 外部資料：傳遞給外部系統的資料（通常表示為邊界流，而非內部儲存）
以名詞命名每個資料儲存，並分配 D 編號（D1、D2）。
第五步：用資料流連接
在元素之間繪製帶標籤的箭頭：
- 流必須有描述性名稱（「客戶訂單」、「已驗證記錄」、「發票」）
- 流連接流程與流程、流程與資料儲存，以及外部實體與流程
- 資料儲存不直接連接到外部實體（資料必須通過流程）
第六步：分解到第 2 級
對於第 1 級中的每個主要流程，繪製一個單獨的第 2 級圖表，顯示其內部子流程。進入和離開第 1 級流程的資料流，成為第 2 級圖表的邊界流。
第七步：驗證一致性
檢查：
- 進入流程的每條資料流都被該流程使用
- 離開流程的每條資料流都源自該流程
- 資料儲存只能通過流程訪問（不能由外部實體直接訪問）
- 第 1 級邊界流與情境圖流相符
實際範例：電子商務訂單系統
第 0 級：情境圖
┌──────────┐ 訂單請求 ╭──────────────────────╮
│ 客戶 │ ────────────→ │ │
└──────────┘ │ 電子商務 │
↑ 訂單狀態 │ 訂單系統 │
└──────────────────── │ │
╰──────────────────────╯
┌──────────┐ 付款結果 │ ↑
│ 付款 │ ────────────→ │ │
│ 閘道 │ ←──────────── │ 物流
└──────────┘ 扣款請求 ↓ 資料
┌──────────────┐
│ 物流 │
│ 夥伴 │
└──────────────┘
第 1 級：主要流程
客戶 ─── 訂單請求 ──→ ╭──────────╮
│ 1.0 │ ──→ D1: 訂單
│ 驗證 │
│ 訂單 │
╰──────────╯
│
已驗證訂單
↓
付款閘道 ←── 扣款 ── ╭──────────╮ ── 付款記錄 ──→ D2: 付款
請求 │ 2.0 │
付款閘道 ── 結果 ──→ │ 處理 │
│ 付款 │
╰──────────╯
│
已確認訂單
↓
╭──────────╮
D1: 訂單 ── 訂單資料 ──→ │ 3.0 │ ── 出貨請求 ──→ 物流夥伴
D3: 商品 ─ 庫存資料 ──→ │ 履行 │
│ 訂單 │
╰──────────╯
│
物流資料
↓
╭──────────╮
│ 4.0 │ ── 狀態更新 ──→ 客戶
│ 追蹤與 │
│ 通知 │
╰──────────╯
第 2 級：分解流程 1.0（驗證訂單）
客戶 ─── 原始訂單 ──→ ╭──────────╮
│ 1.1 │ ── 無效 ──→ 客戶（錯誤）
│ 查詢 │
│ 格式 │
╰──────────╯
│
已格式化訂單
↓
╭──────────╮
D3: 商品 ─ 庫存資訊 ─→│ 1.2 │ ── 無庫存 ──→ 客戶
│ 驗證 │
│ 庫存 │
╰──────────╯
│
有庫存訂單
↓
╭──────────╮
D4: 客戶 ─ 驗證資料 ─→│ 1.3 │ ── 未驗證 ──→ 客戶
│ 驗證 │
│ 客戶 │
╰──────────╯
│
已驗證訂單
↓
D1: 訂單（已儲存）
常見的 DFD 錯誤
將外部實體直接連接到資料儲存。 資料儲存是內部的；外部實體無法直接訪問它們。所有跨越系統邊界的資料必須通過流程。
未標記的資料流。 每條箭頭必須有描述性名稱。「資料」或「資訊」不夠具體。流應以所代表的資料命名：「客戶訂單」、「付款確認」、「庫存水準」。
沒有輸入或輸出的流程。 流程必須至少有一條輸入流和一條輸出流。沒有傳入資料的圓圈「憑空創造」資料——那不是流程，而是外部實體。沒有傳出資料的圓圈丟棄一切——將其建模為資料儲存寫入，或移除該流程。
將控制流與資料流混合。 決策、順序和控制邏輯不屬於 DFD。如果你發現自己在繪製決策菱形，就代表你在建立流程圖而非 DFD。DFD 僅顯示資料移動。
第 1 級細節過多。 第 1 級應有 3-7 個主要流程。如果你在第 1 級顯示 15 個流程，就跳過了層次分解。將相關流程分組到更高層次的氣泡中，並使用第 2 級顯示細節。
層級不一致。 第 1 級圖表中進入流程 2.0 的資料流，必須與流程 2.0 的第 2 級圖表中的邊界流相符。不一致意味著圖表代表的不是同一個系統。
未解釋跨子系統共享的資料儲存。 如果多個流程訪問同一個資料儲存，請確保這是有意為之，且訪問是合理的。過度使用單一「主資料庫」資料儲存會隱藏重要的資料架構決策。
使用 Flowova 建立資料流程圖
手動繪製資料流需要相當多的精力——識別所有邊界流、為流程一致地編號，以及保持層級同步。
Flowova 的資料流程圖製作工具可以從純文字系統描述生成 DFD 結構。描述你系統的輸入、輸出和主要流程，獲得一個可以優化的草稿圖表。這對於快速建立情境圖和第 1 級概覽，然後針對需要的流程深入到第 2 級細節，特別有用。
結語
當你需要理解或溝通資料如何在系統中移動時，DFD 是正確的工具——不是逐步發生什麼，而是資料從哪裡來、什麼轉換了它、儲存在哪裡，以及最終去哪裡。
從情境圖開始以建立系統邊界。分解到第 1 級以識別主要流程。只對需要進一步說明的流程深入到第 2 級。保持資料流命名具體，避免將控制邏輯混入圖表，並驗證各層級之間的一致性。
