在系統分析與軟體工程的領域中，視覺化資訊的流動至關重要。資料流圖（通常簡稱為 DFD）作為資訊系統中資料流動的圖形化表示。與描繪控制流程的流程圖不同，DFD 僅專注於資料的輸入、輸出與儲存。此區別對架構師與分析師至關重要，使他們能理解系統處理的資料內容，而不會陷入資料處理方式的程序邏輯中。
DFD 於 1970 年代發展而成，至今仍是需求工程的核心技術。它提供系統的高階視圖，使利害關係人能驗證所有必要的資料輸入是否已被捕捉，且所有所需的輸出是否均已產生。透過將複雜系統分解為可管理的元件，DFD 促進了技術團隊與業務使用者之間的溝通。本指南詳細說明了構建精確圖表所需的結構元素、符號變異與方法論規則。
資料流圖的核心元件 🔍
要構建有效的 DFD，必須理解四個基本構成要素。無論圖表複雜程度為何，皆依賴這些元件來呈現系統的邊界與內部運作。錯誤辨識這些元件，將導致模型模糊不清或邏輯上不一致。
- 外部實體： 亦稱為終結點或來源，代表與被建模系統互動的人、組織或外部系統。它們是資料流的起點或終點。實體位於系統邊界之外，向系統傳送資料或從系統接收資料。例如，顧客下訂單，或政府稅務機關接收報告。
- 處理程序： 這些是在系統內部發生的動作或轉換。處理程序從一個或多個來源取得資料，加以修改，並傳送至其他目的地。必須牢記，處理程序不儲存資料，僅負責轉換。處理程序通常以動詞片語標示，例如「計算稅額」或「驗證使用者憑證」。
- 資料儲存： 這些代表資料被儲存以供後續使用的儲存庫。與處理程序不同，資料儲存不會執行運算，僅為被動容器。在實體層面，這些可能是資料庫表格、檔案或實體檔案櫃；在邏輯層面，僅表示資訊被持久化的地點。資料流必須進入並離開資料儲存，以表示更新或取得動作。
- 資料流： 這些是連接各元件的箭頭，代表資料的移動。資料流必須有命名，以描述資料封包的內容，例如「訂單細節」或「付款確認」。每一個資料流都應連接兩個元件；不能在半空中開始或結束。
資料流圖的類型 🗺️
DFD 具有層級結構。複雜系統無法透過單一視圖理解，因此標準做法是將系統分解為多個抽象層級。此方法使分析師能在不喪失整體脈絡的情況下，深入探討特定區域。
1. 上下文圖（第 0 層）
這是最高層次的抽象。它將整個系統呈現為一個單一的處理程序泡泡。顯示系統與外部實體之間的關係。此階段不顯示任何內部處理程序或資料儲存。目的在明確定義系統邊界。回答的問題是：「這個系統對外界而言做什麼？」
2. 第 0 層圖（圖 0）
亦稱為概念模型，此圖將上下文圖中的單一處理程序分解為主要的子程序。它提供系統主要功能的路徑圖。顯示主要資料流如何將主要處理程序與資料儲存及外部實體連接起來。這通常是詳細設計的第一步。
3. 第 1 層與分解
隨著分析深入，第 0 層的處理程序會進一步分解為第 1 層圖。此過程持續進行，直到處理程序簡化至可直接實作為止。每個子圖必須與其父圖保持平衡，即父圖中某處理程序的輸入與輸出，必須與包含該分解處理程序的子圖之輸入與輸出相符。
符號標準比較 📐
繪製 DFD 沒有單一的通用標準。業界主要由兩大思潮主導。兩者皆傳達相同的邏輯資訊，但使用不同的形狀來表示元件。選擇一種標準並堅持使用，對於專案內的一致性至關重要。
| 元件 | Yourdon 與 DeMarco 符號 | Gane 與 Sarson 符號 |
|---|---|---|
| 處理程序 | 圓形或圓角矩形 | 圓角矩形 |
| 資料儲存 | 兩條平行的水平線 | 開口矩形 |
| 外部實體 | 矩形 | 矩形 |
| 資料流 | 彎曲或直線箭頭 | 直線箭頭 |
| 註解 | 流線附近的文字 | 流線附近的文字 |
雖然形狀有所不同，但控制連接的規則保持一致。Yourdon 與 DeMarco 風格通常在較舊的遺留文件中較受青睞，而 Gane 與 Sarson 風格則因更乾淨的矩形美學，經常被現代系統採用。
邏輯與物理區別 🔄
DFD 建模中一個關鍵概念是將邏輯設計與物理設計分離。這種區別確保即使底層技術發生變更，模型依然有效。
- 邏輯 DFD： 關注業務需求。描述系統做什麼，而非如何執行。在邏輯圖中，「資料庫」可能被泛化為資料儲存，而不需指定是 SQL、NoSQL 或平面檔案。「處理」可能是「核准貸款」，無論核准是由人類、腳本或 AI 算法執行。
- 物理 DFD： 關注實作細節。描述系統是如何建構的。在此，資料儲存可能被指定為「伺服器 A 中的 Oracle 表格」。處理可能是「Java Servlet 處理請求」。物理圖表在程式碼撰寫階段由開發人員使用。
在單一圖表中混合這些層級會造成混淆。最佳實務是為利益相關者審查保留邏輯視圖，為技術實作保留物理視圖。
建構 DFD 的規則 ⚙️
繪製圖表不僅僅是畫出形狀；更關鍵的是遵守嚴格的邏輯規則。違反這些規則會使圖表在技術上無效，無法用於分析。
1. 資料守恆
資料在處理過程中無法被創造或消滅。若資料進入處理過程，則必須離開該過程或被儲存。處理過程無法輸出未輸入的資料，除非該資料來自其他輸入。這可防止系統設計中出現「奇蹟」。
2. 命名慣例
每個元素都必須有獨特的名稱。資料流應使用名詞（例如「發票」）。處理應使用動詞-名詞短語（例如「處理發票」）。資料儲存應使用複數名詞（例如「發票」）。命名的一致性有助於更輕鬆地導航與理解系統。
3. 平衡
此規則適用於層次分解。若一個處理被拆解為子處理，父處理的輸入與輸出必須等於子處理輸入與輸出的總和。在分解過程中，資料不能憑空消失或出現。
4. 避免控制流
DFD 不是控制流圖。它們不會顯示類似「如果 X，則 Y」的決策點。它們顯示的是資料的流動。決策邏輯由處理描述來處理，而非直接標示在圖上。這能保持視覺呈現的簡潔，並專注於資料。
應避免的常見陷阱 ❌
即使是經驗豐富的分析師，也可能在資料流程圖中引入錯誤。了解常見錯誤有助於維持模型的完整性。
- 黑洞： 一個有輸入但無輸出的處理過程。這表示資料被消耗卻從未被使用，這是一種邏輯錯誤。
- 奇蹟： 一個有輸出但無輸入的處理過程。這表示資料是憑空產生的。
- 幽靈流： 未連接到任何組件的資料流。每一個箭頭都必須有明確的來源和目的地。
- 功能重疊： 當單一處理框試圖執行太多任務時。如果一個處理框有超過七個輸入或輸出，很可能是在執行太多事情，應當拆分。
- 外部實體循環： 外部實體不應直接相互連接。所有互動都必須經過系統邊界。
系統分析中的優勢 🛠️
為什麼要花時間創建這些圖表？其價值遠超於簡單的文件記錄。
- 溝通： 它彌補了技術與非技術利益相關者之間的差距。視覺模型比文字需求更容易討論。
- 缺口分析： 透過繪製流程，分析師可以識別缺失的資料需求。如果使用者需要一份報表，但沒有資料流指向支援該報表的資料儲存區，則可早期發現缺口。
- 測試基礎： 資料流定義了測試案例。如果定義了特定的資料流，則必須設計測試來驗證資料是否正確地通過該流程。
- 系統文件： 隨著系統的演進，資料流程圖扮演著動態地圖的角色。當新增功能時，圖表會被更新，確保文件與程式碼保持同步。
常見問題 ❓
資料流程圖（DFD）與流程圖之間有什麼區別？
流程圖用來描述演算法的控制邏輯與決策點，顯示步驟的順序。資料流程圖則用來描述資料，顯示資料的來源與去向，而不考慮操作的順序。流程圖適用於程式邏輯，而資料流程圖則適用於系統架構。
資料流程圖能否顯示安全控制？
標準的資料流程圖不會明確顯示加密或驗證等安全協定。然而，安全分析師可以在資料流上加上註解，以標示敏感資料被處理的位置，或存取控制被執行的位置。這通常以附著於特定資料流的註解形式呈現。
繪製資料流程圖是否需要特定工具？
不需要。雖然存在許多軟體工具，但圖表本身是一種概念性產物。它可以在紙上、白板上，或使用任何向量圖形工具繪製。媒介不會改變模型的邏輯。
資料流程圖如何處理即時資料？
資料流程圖通常為靜態表示。它們本身並不會顯示時間或延遲。對於即時系統，資料流程圖通常會與狀態轉移圖或時序圖搭配使用，以捕捉資料移動的時間特性。
方法論結論
構建資料流程圖是一種有紀律的抽象練習。它要求分析人員摒棄實現細節，專注於資料流動的本質。透過遵守結構規則和符號標準，團隊可以為其資訊系統建立清晰的藍圖。這種清晰性能降低風險、改善溝通，並確保最終系統能滿足其所處理資料的實際需求。
資料流程圖之所以仍具相關性，是因為它回答了一個根本問題：「資料往哪裡去？」在複雜且分散式系統盛行的時代，追蹤資訊的流向比以往任何時候都更加重要。無論是簡單的網路應用程式，還是大型企業系統，DFD建模的原則都為設計與分析提供了穩固的基礎。