DFD 簡單解釋：數據流圖入門指南

數據流圖（DFD）是用於可視化資訊在系統中如何流動的關鍵工具。無論您正在設計新應用程式、規劃業務流程，還是分析現有的工作流程，理解資料流動都至關重要。本指南將 DFD 的概念分解為易於管理的部分，著重於清晰性與實際應用。

🧐 什麼是數據流圖？

數據流圖是一種以圖形方式呈現資料在資訊系統中流動的表示法。與專注於控制邏輯和決策點的流程圖不同，DFD 僅關注資料從輸入來源到輸出目的地的移動。它幫助利益相關者理解需要哪些資料、資料來自何處、如何被處理，以及最終會到達哪裡。

可將 DFD 視為系統資訊的地圖。它並不會以線性方式顯示時間或事件的順序，而是呈現資料的連接性與轉換過程。這使得它在需求收集階段對系統分析師和開發人員尤為有用。

🧩 四個核心組件

要建立有效的 DFD，您必須理解四個基本構成要素。每個圖表都是由這些元素構建而成。正確使用這些元素，可確保圖表準確反映系統的邏輯。

• 外部實體（或終結者）：這些代表系統邊界外的資料來源或目的地。範例包括使用者、其他系統或組織。它們是資料流的起點或終點。
• 處理過程：這些是將輸入資料轉換為輸出資料的動作。處理過程會以某種方式改變資料，例如計算總額、驗證輸入內容或排序清單。每個處理過程都必須有描述該動作的名稱。
• 資料儲存：這些是資料被儲存以供後續使用的儲存庫。它們代表資料庫、檔案，或任何資訊被保存的地方。資料流入儲存庫以進行記錄，並從儲存庫流出以被取出。
• 資料流：這些是顯示資料移動方向的箭頭。它們連接實體、處理過程與儲存庫。每一個資料流都必須有標籤，用以描述正在移動的特定資料。

需要注意的是，資料不能憑空出現或消失。每個輸入都必須產生輸出，或被儲存。此原則稱為資料守恆。

📉 理解 DFD 層級

DFD 是層級式的。您從高階視圖開始，並根據需要逐步分解為更詳細的視圖。這種技術可透過在必要前隱藏細節來管理複雜性。

1. 上下文圖（第 0 層）

上下文圖是抽象層級最高的圖表。它將系統呈現為單一處理過程，並顯示其與外部實體的互動。上下文圖中沒有資料儲存。它回答的問題是：「這個系統的主要功能是什麼？」

• 一個代表整個系統的中央處理過程。
• 包圍在它周圍的所有外部實體。
• 主要資料流進入與離開系統。

2. 第 1 層圖

第 1 層圖將上下文圖中的單一處理過程分解為主要的子過程。這正是您開始看到內部結構的地方。您會看到資料儲存與更明確的資料流。

• 顯示運行系統所需的主功能。
• 識別資料在內部的儲存位置。
• 將外部實體與特定處理過程連接起來。

3. 第 2 層圖及更進一步

如果第 1 層圖中的某個處理過程過於複雜，您可以進一步分解為第 2 層圖。這種深入分析持續進行，直到處理過程簡單到足以實現為止。通常，當邏輯清晰到足以進行程式設計或執行時，您就會停止分解。

🎨 符號風格比較

繪製資料流程圖（DFD）主要有兩種風格。雖然它們代表相同的邏輯概念，但符號略有不同。選擇合適的符號風格取決於團隊的偏好或業界標準。

兩種符號風格都是有效的。關鍵在於一致性。如果您的團隊使用 Gane & Sarson 風格，請在所有圖表中堅持使用。混合使用符號可能會讓讀者混淆，並模糊圖表的含義。

🛠️ 分步流程建立

建立資料流程圖（DFD）是一項邏輯性的工作。雖然開始時不需要特定工具，但軟體可以協助後續維護。遵循以下邏輯步驟，即可建立有意義的圖表。

步驟 1：界定範圍

定義系統的邊界。系統內部是什麼，外部又是什麼？這將決定哪些實體是外部的，哪些流程是內部的。如果一個流程位於系統邊界之外，則它就是外部實體。

步驟 2：繪製上下文圖

從整體視角開始。將系統視為一個單一的圓泡。繪製與其互動的外部實體，並畫出它們之間的主要資料流。這能確保你在深入細節之前，已清楚掌握高階的輸入與輸出。

步驟 3：分解流程

從上下文圖中取出主要流程，並拆分成子流程。問自己：「涉及的主要步驟是什麼？」在步驟之間需要儲存資訊的地方加入資料儲存。確保每一筆資料流都連接到一個流程或資料儲存。

步驟 4：透過平衡驗證

將你的工作與父圖進行比對。這稱為平衡。分解後的流程的輸入與輸出必須與父流程的輸入與輸出一致。如果你在第 1 層圖中新增一個輸入，則必須在第 0 層圖中加以說明。

步驟 5：審查與優化

與相關利益者一起走過圖表。資料流是否合理？標籤是否清晰？是否有任何資料流缺少目的地？只有當圖表準確且易於閱讀時，它才具有實際價值。

⚠️ 常見錯誤應避免

即使是經驗豐富的分析師，在建立資料流程圖時也會犯錯。了解常見錯誤可以節省時間，並避免日後產生混淆。

• 懸空的資料流：絕對不要有箭頭在半空中結束的情況。每一個資料流都必須從實體、處理程序或儲存位置開始，並在其中一個結束。
• 義大利麵圖：避免線條交叉導致圖形雜亂。使用換行或直角路由來保持佈局整潔。
• 遺漏的資料儲存：確保資料在必要時被儲存。如果某個處理程序需要資料才能運作，該資料應來自儲存位置或輸入資料流。
• 混淆控制流程與資料流程：資料流程圖追蹤的是資料，而非指令。除非是實際傳輸的資料，否則不要為「按鈕」或「檢查密碼」繪製箭頭。
• 過度細節化：不要顯示資料儲存中的每一筆欄位。保持高階層次即可。欄位細節可另行記錄。

🔗 為何資料流程圖在系統設計中至關重要

資料流程圖的價值不僅僅在於繪製圖形。它在開發週期中扮演多項關鍵角色。

溝通工具

資料流程圖彌補了技術與非技術利益相關者之間的差距。圖形比技術規格文件更容易理解。業務使用者可以查看資料流程圖，確認系統是否符合他們的預期。

需求分析

建立資料流程圖迫使你識別所有資料需求。在不了解資料流動內容的情況下，無法繪製資料流。這能在流程早期揭露遺漏的需求。

系統文件

隨著系統的演進，資料流程圖便成為文件。新開發人員可透過圖形了解資料如何在應用程式中流動，而無需閱讀每一行程式碼。

錯誤檢測

邏輯錯誤經常出現在圖中。如果資料流入某個處理程序，但沒有輸出流出，就表示存在邏輯錯誤。如果資料進入儲存位置卻從未取出，則代表資料完整性問題。

🧠 邏輯型與實體型資料流程圖

區分系統的邏輯與實體面向非常重要。

• 邏輯型資料流程圖：專注於業務流程與資料需求。忽略硬體、軟體或特定實作細節。回答「系統做什麼？」
• 實體型資料流程圖：專注於系統如何實作。包含具體的檔案名稱、資料庫表格與軟體模組。回答「系統如何運作？」

應先從邏輯型資料流程圖著手，確保業務邏輯正確。邏輯驗證通過後，再建立實體型資料流程圖，以引導開發人員。

❓ 常見問題

我可以將資料流程圖用於非軟體系統嗎？

可以。資料流程圖對任何涉及資料流動的系統都很有用。這包括製造流程、行政工作流程或物流鏈。

資料流程圖會顯示決策點嗎？

並非直接顯示。資料流程圖著重於資料的移動。決策點通常由資料流的分支所暗示，但這並非主要重點。流程圖更適合顯示邏輯路徑。

標籤應該多詳細？

標籤應簡潔但具描述性。資料流可標示為「客戶訂單」，而處理過程則可標示為「驗證訂單」。避免使用「資料」或「資訊」等模糊用語。

資料流程圖與實體關係圖是一樣的嗎？

不是。實體關係（ER）圖著重於資料的結構（資料表與關係）。資料流程圖則著重於資料的移動與轉換（處理過程與資料流）。

🚀 最後的想法

資料流程圖是任何參與系統設計或分析人員的基礎技能。它提供了一種清晰、直觀的語言，用來討論複雜系統。透過掌握元件、層級與符號風格，你可以繪製出能釐清需求並引導開發的圖表。

請記住，圖表是一種思考工具，而不僅僅是最終產物。運用資料流程圖來探索想法、發現缺口，並與團隊溝通。經過練習，你會發現將資料流可視化將變得自然而然。