創建一個清晰的視覺化表示，以展示資訊如何在系統中流動，是系統分析與設計的基礎。資料流圖（DFD）正是為了這個目的而設計。它描繪資料從外部來源進入系統，再流向目的地的流程，並詳細說明途中所發生的轉換。
本指南深入探討構建DFD的機制。我們將探討其歷史背景、核心符號、層級結構，以及在不依賴特定專有工具的情況下繪製功能性圖表所需的實際步驟。完成本教程後，您將理解線條背後的邏輯，並具備有效記錄複雜系統的能力。
🧠 理解DFD的目的
在繪製任何一條線之前，了解DFD實際代表的意義至關重要。與描述程式控制流程或邏輯的流程圖不同，DFD專注於資料.
- 專注於資料： 它顯示資料來自何處（來源）以及流向何處（接收點）。
- 專注於流程： 它說明資料如何被轉換為不同形式。
- 專注於儲存： 它標示資料被儲存以供後續檢索的位置。
DFD在需求收集階段尤其有用。它幫助利益相關者視覺化系統邊界，並確認所有必要的輸入與輸出均已納入考量。這種視覺化溝通彌補了技術團隊與業務使用者之間的差距。
🛠️ 核心元件與符號
每張資料流圖都是由一組特定的圖形與線條構成。雖然歷史上使用過兩種主要符號系統（Yourdon & DeMarco 與 Gane & Sarson），但其概念保持一致。以下是任何DFD所需的四個基本元素的說明。
1. 外部實體（終端）
這些代表位於系統邊界之外的資料來源或目的地。它們是與您的流程互動的人、部門或其他系統。
- 範例：客戶、供應商、銀行、政府機構。
- 視覺呈現： 通常為矩形或人形圖示。
- 規則： 不要在系統邊界之外放置資料儲存或流程。
2. 流程
流程將流入的資料流轉換為流出的資料流。它代表系統內執行的工作、運算或所做的決策。
- 範例：「計算稅額」、「驗證訂單」、「產生報表」。
- 視覺呈現： 圓形或圓角矩形。
- 規則：每個流程必須至少有一個輸入和一個輸出。
3. 數據儲存
這些是用於儲存數據以供未來使用的儲存庫。這可能是一個資料庫、一個檔案、一個實體檔案櫃，或一個暫時的緩衝區。
- 範例：客戶資料庫、庫存日誌、訂單歷史。
- 視覺表示：開口的矩形或兩條平行線。
- 規則：流程必須從數據儲存中讀取或寫入數據；它們不能直接將數據從一個儲存傳遞到另一個儲存。
4. 數據流
這些是數據所經過的路徑。它們代表了實體、流程和儲存之間的數據移動。
- 範例：「訂單詳情」、「付款確認」、「庫存更新」。
- 視覺表示：帶有標籤的箭頭，用以描述數據內容。
- 規則：箭頭必須標示標籤。未標示標籤的箭頭無效。
| 組件 | 符號形狀（Yourdon & DeMarco） | 符號形狀（Gane & Sarson） | 功能 |
|---|---|---|---|
| 外部實體 | 矩形 | 圓角方形 | 來源或目的地 |
| 流程 | 圓形 | 圓角矩形 | 轉換數據 |
| 資料儲存 | 開口矩形 | 開口矩形 | 儲存資料 |
| 資料流 | 箭頭 | 箭頭 | 移動資料 |
📉 資料流程圖中的抽象層級
複雜系統無法以單一圖示呈現。為了管理複雜性，資料流程圖會以不同細節層級繪製，類似於在地圖上縮放。這種層級結構稱為分解。
第0層：環境圖
這是最高層級的視圖。它將整個系統呈現為單一處理程序，並顯示其與外部實體的互動。它明確定義了系統的邊界。
- 處理程序數量： 1（整個系統）。
- 細節層級： 最少。不顯示內部處理程序。
- 用途： 定義範圍與高階共識。
第1層：主要子程序
在此層級，環境圖中的單一處理程序被分解為主要子程序。這正是系統內部結構開始顯現的地方。
- 處理程序數量： 3到7個為可讀性最佳的數量。
- 細節層級： 主要功能區域。
- 用途： 理解主要功能模組。
第2層：詳細子程序
此層級深入探討特定的第1層程序。用於需要進一步分解的複雜功能。
- 處理程序數量： 每個父程序各不相同。
- 細節層級：函數內的具體步驟。
- 使用方式：實作指導與詳細邏輯。
第三層：基本圖示
除非系統極其複雜，否則很少繪製。它們代表最低層次的細節，通常對應到特定的程式模組或手動程序。
🚀 繪製資料流程圖的逐步指南
遵循此結構化方法，為您的專案建立穩健的資料流程圖。
步驟 1：識別系統邊界
定義系統內部與外部的內容。這對於判斷哪些實體是外部的，哪些流程是內部的至關重要。在系統流程周圍畫一個方框。
步驟 2：識別外部實體
列出所有將與您的系統互動的人、組織或外部系統。將它們放置在邊界方框之外，並清楚標示。
步驟 3：繪製上下文圖（第零層）
在中心畫一個單一圓圈，代表整個系統。使用箭頭將外部實體連接到此圓圈。以被交換的資料標示這些箭頭（例如：「訂單請求」、「發送發票」）。
步驟 4：分解為第一層
將單一圓圈擴展為多個流程。問：「這個系統的主要功能是什麼？」
- 識別輸入資料。
- 識別輸出資料。
- 識別所需的資料儲存位置。
- 繪製箭頭連接實體、流程與儲存位置。
步驟 5：應用平衡規則
這是最重要的技術規則。父流程的輸入與輸出必須與其子圖的輸入與輸出相符。
- 如果第零層流程的輸入為「客戶編號」，則第一層子流程也必須有「客戶編號」流入或流出。
- 如果第一層流程產生「報表資料」，則第零層的父流程也必須將「報表資料」輸出至外部實體。
步驟 6：審查與驗證
根據需求檢查您的圖表。
- 所有箭頭是否都已標示？
- 所有流程是否都有輸入與輸出？
- 是否每個實體都有一條通往儲存位置或流程的路徑？
- 是否有任何「義大利麵式」線條（不必要的交叉重疊）？
🏪 範例情境：線上商店系統
為了說明這些概念，讓我們走過一個簡化的線上商店情境。
背景圖（第0層）
- 實體： 客戶。
- 實體： 支付網關。
- 實體： 倉庫。
- 流程： 線上商店系統。
- 流程：
- 客戶 ➔ 系統：訂單詳情
- 系統 ➔ 客戶：訂單確認
- 系統 ➔ 支付網關：付款資訊
- 支付網關 ➔ 系統：付款狀態
- 系統 ➔ 倉庫：出貨請求
第1層分解
我們將「線上商店系統」分解為三個主要流程：
- 管理訂單： 接收訂單詳情，檢查庫存。
- 處理付款： 處理信用卡資訊，驗證資金。
- 發貨： 與倉庫進行通訊。
資料儲存
我們引入兩個資料儲存：
- 訂單資料庫： 儲存訂單歷史與狀態。
- 庫存資料庫： 儲存目前的庫存水準。
在此層級1圖中，“管理訂單”會寫入訂單資料庫。“處理付款”會從訂單資料庫讀取資料，以確認訂單存在後再進行信用卡扣款。“發貨”會從庫存資料庫讀取資料，以確認商品有庫存後再發送出貨請求。
⚠️ 常見錯誤與陷阱
即使經驗豐富的分析師在繪製資料流程圖時也會犯錯。避免這些常見陷阱，以確保您的圖表保持有效且實用。
- 控制流程：除非控制訊號包含資料，否則不要繪製代表控制訊號（例如「按鈕點擊」、「錯誤訊息」）的箭頭。資料流程圖追蹤的是資料，而非控制邏輯。
- 資料儲存間的直接流程：資料無法直接從一個資料儲存處移動到另一個資料儲存處。它必須先經過一個處理程序。這確保了資料的轉換或驗證能夠發生。
- 未標示的箭頭：沒有標籤的箭頭不提供任何資訊。請始終標示出箭頭中流動的資料名稱。
- 幽靈處理程序：沒有輸入或沒有輸出的處理程序是無用的。每個泡泡都必須轉換某些東西。
- 過度複雜化：如果一張層級1圖的處理程序超過7到9個，很可能過於細節化。應將其拆分為邏輯上的功能區塊。
- 忽略黑洞：只有輸入而無輸出的處理程序稱為「黑洞」。它會消耗資料，但不產生任何輸出。
- 忽略奇蹟：只有輸出而無輸入的處理程序稱為「奇蹟」。它會憑空創造資料。
📝 文件編寫的最佳實務
繪製圖表僅完成了一半的工作。文件編寫與維護能確保資料流程圖長期保持價值。
一致的命名規範
使用標準格式來命名處理程序與資料流。
- 處理程序：使用動詞-名詞格式（例如「驗證使用者」、「產生報表」）。
- 資料流：使用名詞格式（例如「使用者憑證」、「銷售報表」）。
- 資料儲存：使用複數名詞（例如「客戶記錄」、「產品清單」）。
色彩編碼
使用顏色來區分不同類型的元件或不同抽象層級。
- 藍色代表外部實體。
- 綠色代表流程。
- 橙色代表資料儲存。
- 紅色代表關鍵資料流。
版本控制
系統需求會變更，你的資料流程圖必須反映這些變更。
- 為你的圖表分配版本號碼（v1.0、v1.1）。
- 維持變更紀錄，記錄新增、移除或修改的內容。
- 存檔舊版本以維持審計追蹤。
🔗 與其他方法論的整合
資料流程圖並非孤立存在，它們通常是更大結構化分析框架的一部分。
實體關係圖（ERD）
雖然資料流程圖顯示資料的流動，但實體關係圖則顯示資料的結構。當你在資料流程圖中識別出資料儲存時，通常需要使用實體關係圖來設計對應的資料表。資料流程圖告訴你需要哪些資料；實體關係圖則告訴你資料是如何結構化的。
結構化英文
對於資料流程圖中的複雜流程，單純的圖示可能不夠。結構化英文是自然語言與程式邏輯的混合體，用來描述流程泡泡內部的邏輯。
資料字典
每個資料流、儲存與實體都應在資料字典中明確定義。此文件為圖表提供元資料，包括資料類型、大小與格式（例如：「客戶編號：整數，10位數」）。
🛠️ 工具與軟體選擇
創造資料流程圖並不需要昂貴的軟體。重點應放在邏輯上，而非美觀。
- 白板與筆：非常適合與利害關係人進行腦力激盪與初步草圖。
- 紙張與鉛筆：在不受軟體限制的情況下，快速迭代概念的最快方式。
- 一般繪圖工具：任何向量圖形工具皆可用來製作乾淨的數位圖表。
- 專業分析工具：市面上有許多專為系統分析設計的工具。選擇一個支援標準資料流程圖符號且具備版本控制功能的工具。
無論使用何種工具，請確保它能以標準格式匯出圖表，以便與團隊分享。
🔄 維護與生命週期
資料流程圖是一份活文件。當系統演進時，圖表也必須隨之演進。
- 變更請求： 當有新功能請求時，更新第1級圖表以觀察其影響。
- 影響分析： 若某流程變更，請檢查哪些其他流程依賴其輸出。同時更新這些圖表。
- 程式碼審查： 開發人員在實作時應參考資料流程圖，以確保程式碼符合資料流程邏輯。
- 測試： 測試案例可從資料流程中推導出來。若存在某一流程，則必須有測試來驗證該路徑上的資料完整性。
📚 關鍵原則摘要
總結建立有效資料流程圖的關鍵要點：
- 從簡單開始： 從背景圖（第0級）開始，以界定範圍。
- 逐步分解： 僅在必要時，才從第0級逐步移至第1級，再至第2級。
- 嚴格保持平衡： 確保父層與子層之間的輸入與輸出相符。
- 所有項目皆需標示： 無任何未標示的箭頭或流程。
- 專注於資料： 忽略控制邏輯；僅追蹤資料流動。
- 與利害關係人共同驗證： 與業務使用者共同審查圖表，以確保準確性。
遵循這些原則，您將建立一份文件化成果，可作為開發人員、測試人員與業務分析師的可靠地圖。您的圖表清晰度直接影響系統開發週期的效率。
🏁 終極想法
掌握資料流程圖的藝術，需要實踐與系統思維的嚴謹態度。這不僅僅是畫圖形，更在於理解組織內資訊的生命周期。當您能追蹤一筆資料從其來源到最終目的地的全程，您才真正理解了這個系統。
將此教程作為基礎。在真實情境中實踐，批判性檢視自己圖表中的常見錯誤，並始終以清晰度優先於複雜度。一張繪製良好的資料流程圖，是打造穩健、可靠軟體系統的靜默夥伴。