資料流程圖（通常簡稱為DFD）是系統分析與設計中的基礎工具。它提供了一種視覺化方式，用以呈現資訊在系統中如何流動。與專注於控制邏輯或硬體的其他圖表不同，DFD著重於資料本身的流動。這種方法有助於利益相關者理解資料從輸入到輸出的轉換過程，而不會陷入實作細節的困擾。
無論您是規劃新的軟體架構，還是分析現有的業務流程，一個設計良好的DFD都能清楚地呈現各元件之間的關係。它對開發人員而言如同設計圖，對企業主而言則是溝通的橋樑。本指南探討了建立有效圖表所需的基礎原則、符號、層級與最佳實務。
理解核心目的 🎯
資料流程圖的主要功能在於視覺化資料的流動。它不會顯示操作的順序或事件的時間點，而是回答這個問題：「資料從哪裡來，往哪裡去，以及如何被改變？」在區分邏輯設計與實際實作時，這種區別至關重要。
在建構系統時，團隊經常面臨複雜性的挑戰。DFD能將這種複雜性分解為可管理的模組。透過隔離特定流程，您可以分析資料的完整性，確保資料在傳輸過程中不會遺失或遭到破壞。它讓分析師能夠發現資料無謂累積或流向不必要區域的瓶頸。
在需求收集階段，DFD尤為重要。它有助於確認所有必要的輸入與輸出都已納入考量。若某流程產生輸出，但沒有明確的資料來源，圖表便會揭示設計上的缺口。反之，若資料進入系統卻從未被使用，則表示存在冗餘。
DFD的關鍵組成部分 🧩
每個資料流程圖都是由一組特定符號構成。雖然不同方法論（如Gane與Sarson或Yourdon與Coad）之間的符號表示法略有差異，但基本元素保持一致。理解這四個核心組成部分對於準確繪製圖表至關重要。
1. 外部實體 🚪
外部實體代表系統邊界以外的資料來源或目的地。這些是與被模擬流程互動的使用者、其他系統或組織。它們通常以矩形或方形表示。
-
來源： 提供資料給系統的實體（例如，客戶下訂單）。
-
接收端： 從系統接收資料的實體（例如，政府機構接收稅務報告）。
請記住，這些實體位於當前系統的範圍之外。它們是界定系統控制範圍與非控制範圍的邊界標記。
2. 流程 ⚙️
流程代表轉換資料的活動。它們是系統內部所執行的「工作」。流程會接收輸入資料，執行某項操作，並產生輸出資料。在DFD符號中，這些通常以圓角矩形或圓形表示。
每個流程都必須有一個名稱，以動詞與名詞組合來描述其功能。例如「計算利息」或「更新庫存」。流程若無資料流入或流出，便無法存在。若某個圓形沒有任何流入或流出的線條，則在圖表中毫無意義。
3. 資料儲存 🗄️
資料儲存是資訊被保留以供後續使用的地點。它們代表資料庫、檔案或實體檔案庫。與流程不同，資料儲存不會改變資料，僅僅是保存它。這些通常以開口矩形或平行線表示。
繪製DFD時，請確保每個資料儲存至少在某段時間內有至少一個流入與一個流出的資料流，除非它是終端儲存點。這可確保資料被存取與更新，維持儲存資訊的完整性。
4. 資料流 🔄
資料流是連接各元件的箭頭。它們顯示資料移動的方向。每個箭頭都必須標註，以描述資料封包的內容。例如，從「客戶」到「流程」的箭頭可能標示為「訂單請求」，而從「流程」到「資料儲存」的箭頭可能標示為「銷售紀錄」。
關鍵的是，資料流必須保持一致。若某流程輸出「客戶資料」，則接收的流程或儲存位置必須能接受此特定資料結構。若無轉換步驟，便無法讓「財務資料」流入專門處理「文字輸入」的流程。
資料流程圖的層級 📉
一個完整的系統很少會以單一圖表呈現。為了管理複雜性，DFD會被分解為不同層級。這種層級化方法讓您能從高階概覽開始，逐步深入到具體細節。
第0層：上下文圖 🌍
第0層圖表，通常稱為上下文圖，提供最廣泛的視角。它將整個系統視為單一流程。所有外部實體都顯示與此核心流程互動。
此圖表明確界定了系統的邊界。它回答了這個問題：「系統是什麼，誰與它互動？」它不顯示內部流程或資料儲存，僅專注於系統與外部世界之間的主要輸入與輸出。
第1級：功能分解 🔍
第1級將上下文圖中的單一流程擴展為主要的子流程。這正是內部結構開始顯現的地方。您將看到多個流程、資料儲存區，以及連接它們的資料流。
第1級圖表的輸入與輸出必須與上下文圖一致。如果上下文圖顯示來自「使用者」的輸入，第1級圖表仍必須顯示該輸入進入系統，即使它進入特定的子流程。這確保了各級之間的資料守恆。
第2級：詳細邏輯 🧠
第2級圖表進一步分解第1級中的特定流程。此級別用於需要詳細邏輯的複雜操作。並非每個流程都需要第2級圖表；只有那些足夠複雜、值得進一步分解的流程才需要。
在此階段，重點轉向所需的特定資料轉換。您可能會看到資料儲存區的多次存取，或透過多條資料流表示的複雜分支邏輯。此級別通常是開發人員開始將需求對應到實際程式碼結構的時刻。
一致性與準確性規則 ✅
建立有效的資料流程圖（DFD）需要遵守特定規則。違反這些規則會導致混淆與設計錯誤。以下是規範DFD建構的基本原則。
資料守恆
資料在流程中無法被創造或消滅。它必須流入並流出。如果一個流程輸出「報表」，則產生該報表所需的資料必須進入此流程。若資料進入後消失，則圖表在邏輯上存在缺陷。
無自發產生
流程不能在沒有資料流入的情況下存在。您不能有一個僅「發生」而無輸入的流程。系統中的每一項動作都是由資料或事件觸發的。請確保每個流程至少有一個資料流入。
控制與資料
資料流程圖（DFD）不顯示控制流程，例如「if/else」邏輯或時序信號。雖然流程可能做出決策，但DFD僅顯示該決策所產生的資料，而非決策機制本身。對於控制邏輯，其他建模技術更為合適。
標籤標準
每條箭頭都必須標示標籤。未標示的箭頭無法提供資料內容的資訊。同樣地，每個流程都必須以動詞-名詞短語命名。標籤不清晰會導致開發階段的誤解。
資料流程圖與流程圖的差異 🆚
人們常將資料流程圖與流程圖混淆。雖然兩者都使用箭頭和圖形，但其用途不同。理解兩者的差異可避免在系統文件中誤用。
|
特徵 |
資料流程圖（DFD） |
流程圖 |
|---|---|---|
|
重點 |
資料的移動與轉換 |
步驟的順序與邏輯流程 |
|
控制 |
不顯示控制邏輯（迴圈、決策） |
明確顯示決策與迴圈 |
|
時間 |
不表示時間或順序 |
通常表示時間或執行順序 |
|
組件 |
實體、流程、儲存、資料流 |
開始/結束、流程、判斷、輸入/輸出 |
當你需要編寫演算法的邏輯時，請使用流程圖。當你需要記錄系統架構與資料需求時，請使用資料流程圖。它們是互補工具，而非可互相替代的工具。
建立資料流程圖：逐步指南 🛠️
遵循此結構化方法，為您的專案建立可靠的圖表。此過程可確保從一開始就具備邏輯一致性。
-
定義系統邊界：決定系統內部與外部的範圍。識別與系統互動的主要外部實體。
-
繪製環境圖：草繪代表系統的單一流程。繪製主要輸入與輸出的箭頭，並連接到外部實體。
-
分解流程：將主要流程拆分為子流程。識別支援這些流程所需的資料儲存。
-
連接資料流：在實體、流程與儲存之間繪製線條。為每條線標示所傳輸的具體資料。
-
驗證守恆性：檢查各層級的輸入與輸出是否平衡。確保資料不會無故消失或憑空出現。
-
審查與優化：與利害關係人一起走過圖表。確保視覺化呈現符合他們對業務流程的理解。
邏輯型與實體型資料流程圖 🧠🖥️
資料流程圖可根據抽象層級分為兩種類型。理解此區別有助於與不同對象進行溝通。
邏輯型資料流程圖：此圖表著重於系統的功能，而非其實現方式。它忽略硬體、軟體或人員角色。它描述的是業務需求。例如，無論是由人工櫃員或自動化腳本處理，「處理訂單」都是一個邏輯步驟。
實體型資料流程圖：此圖表描述系統實際的實現方式。它包含具體的硬體、軟體模組與人員角色。若邏輯型資料流程圖顯示「處理訂單」，實體型資料流程圖可能顯示「Web 伺服器 API 呼叫資料庫以檢查庫存」。實體型資料流程圖通常在開發週期後期使用，當實現細節確定後。
資料流程圖設計中的常見挑戰 🚫
即使經驗豐富的分析師在建模複雜系統時也會遇到問題。了解這些挑戰有助於產生更清晰的圖表。
-
過度擁擠：試圖將過多細節塞入單一圖表會使其難以閱讀。使用分解法將複雜區域拆分為獨立圖表。
-
遺漏資料儲存：有時會假設資料存在，卻未實際儲存。請確保每項需要持續存在的資訊都與資料儲存連結。
-
交叉的線條： 雖然在複雜系統中難以避免，但應盡量減少線條交叉。這能提升視覺清晰度。若圖表跨越多頁，請使用頁外連接器。
-
不正確的術語： 在針對商業使用者設計的圖表中使用技術術語會造成混淆。應使用所建模領域的專用詞彙。
將DFD與其他模型整合 📚
資料流程圖很少單獨存在。它們是系統文件更大生態體系的一部分。與其他模型整合可提升其價值。
實體關係圖（ERD）： 雖然DFD顯示資料如何流動，ERD則顯示資料如何結構化。DFD中的資料儲存通常對應到ERD中的資料表。同時使用兩者可確保資料流與資料結構一致。
統一塑模語言（UML）： 在現代物件導向設計中，DFD可對應至用例圖或活動圖。雖然UML更為全面，但DFD能更清楚地呈現特定子系統中資料的持久性與轉換。
視覺清晰度的價值 🌟
有效的系統設計依賴於清晰的溝通。資料流程圖作為分析師、開發人員與利害關係人之間的通用語言。它能消除關於資料需求與系統邊界的模糊性。
透過遵循標準規範並專注於資料流動而非控制邏輯，您將創造出能經得起時間考驗的文件。即使技術架構改變，資料流動通常仍保持不變。這使得DFD成為未來維護與擴展的持久資產。
從上下文圖開始，細心地進行分解，並始終驗證資料守恆。經過練習後，您會發現DFD成為探索與記錄任何複雜系統架構的直覺方式。