資料流程圖（DFD）在系統分析與設計中扮演基本的視覺化表示角色。它描繪資訊在系統中的流動，強調資料如何從輸入移動到輸出。與專注於控制邏輯的流程圖不同，DFD專注於資料的移動。本指南概述了在不依賴特定專有工具的情況下，建立精確圖表的方法。此過程需要清晰的思考，並遵守既定的符號標準。
🧐 理解核心目的
在繪製線條與形狀之前，必須先理解其目的。DFD用來模擬系統的功能需求。它顯示系統的功能，而非其物理實作方式。此區別對分析師至關重要。這讓利害關係人能在不陷入技術實作細節的情況下，驗證業務流程的邏輯。
此圖表有助於識別：
- 資料在系統邊界內的來源位置。
- 資料如何被轉換為有用的資訊。
- 資料儲存的位置，以供未來取用。
- 資料離開系統，傳遞給外部實體的位置。
透過視覺化這些元素，團隊能在開發週期早期發現瓶頸、重複或遺漏的資料路徑。它在技術團隊與業務使用者之間扮演溝通橋樑的角色。
🛠️ 四個基本組成部分
完整的DFD依賴於四個主要符號。所有繪製的元素都必須屬於這四類之一。使用其他形狀會導致含義模糊。標準符號通常遵循Yourdon與DeMarco方法，或Gane與Sarson方法。雖然這兩種風格的符號略有差異，但其背後邏輯完全相同。
1. 外部實體 👤
外部實體代表系統邊界外的資料來源或目的地。它們是與系統互動的參與者。這些可以是個人、組織或其他系統。
- 來源： 該實體向系統提供輸入資料（例如，顧客下訂單）。
- 接收端： 該實體從系統接收輸出資料（例如，稅務機關接收報告）。
在圖表中，這些通常以矩形或正方形表示。它們以名詞片語標示其角色。
2. 處理程序 ⚙️
處理程序代表將輸入資料轉換為輸出資料的動作。它是圖表的核心。處理程序必須始終至少有一個輸入和一個輸出。
- 轉換： 它將資料從一種形式轉換為另一種形式（例如，將原始銷售數字轉換為摘要報告）。
- 標籤： 處理程序通常以動詞片語標示（例如，“計算稅額”、“驗證使用者”）。
根據符號標準，它們通常以圓形、圓角矩形或氣泡形表示。
3. 資料儲存 📂
資料儲存代表資訊被保存以供後續使用的地點。這並非實際的資料庫檔案，而是一個邏輯儲存庫。資料流入儲存庫以進行儲存，並流出以供取回。
- 開放與封閉： 資料可從儲存庫讀取，也可寫入儲存庫。
- 持久性： 即使創建它的流程已經結束，資料仍可持續存取。
常見的符號包括開口的矩形或圓柱，用以代表檔案和資料庫。
4. 資料流 🔄
資料流顯示資料在實體、流程和儲存之間的移動。它們是具有方向性的箭頭。
- 方向： 箭頭指向資料移動的方向。
- 內容： 每個資料流都必須標示出傳輸中的特定資料（例如：「訂單詳情」、「付款確認」）。
- 一致性： 資料無法在兩個外部實體之間直接流動，而必須經過一個流程。
| 元件 | 符號形狀 | 標籤類型 | 功能 |
|---|---|---|---|
| 外部實體 | 矩形 / 正方形 | 名詞 | 來源或目的地 |
| 流程 | 圓形 / 圓角方框 | 動詞片語 | 轉換資料 |
| 資料儲存 | 開口矩形 / 圓柱 | 名詞 | 儲存資料 |
| 資料流 | 箭頭 | 資料名稱 | 移動資料 |
📈 分解層級
複雜系統無法透過單一視圖理解。DFD 是層次性的。您從高階概覽開始，逐步將流程分解為更詳細的內容。這稱為分解。
第 0 層：上下文圖 🌍
上下文圖是最高層級。它將整個系統顯示為一個單一的流程氣泡。它說明系統如何與外部世界互動。
- 僅在中心繪製一個流程。
- 外部實體包圍著流程。
- 資料流將實體與單一流程相連。
- 此層級不顯示資料儲存。
此圖定義範圍，界定專案的邊界。
第 1 層：主要流程 🔍
第 1 層將上下文圖中的單一流程擴展為主要的子流程。這正是內部邏輯開始出現的地方。
- 單一流程變為 3 到 7 個主要流程的群組。
- 此處引入資料儲存。
- 外部實體與第 0 層相同。
- 流程必須與第 0 層的輸入和輸出保持平衡。
第 2 層：詳細功能 🔬
第 2 層將第 1 層的特定流程進一步分解。用於需要進一步說明的複雜操作。
- 專注於前一層的單一流程。
- 顯示詳細邏輯與子步驟。
- 當第 1 層的流程過於複雜，無法在單一視圖中管理時使用。
| 層級 | 焦點 | 流程 | 資料儲存 |
|---|---|---|---|
| 第 0 層 | 系統範圍 | 1（系統） | 無 |
| 第 1 層 | 主要功能 | 3 到 7 | 是 |
| 第二級 | 具體細節 | 依賴第一級 | 是 |
✍️ 分步繪製方法
建立資料流程圖需要有結構化的方法。遵循這些步驟可確保文件中的一致性和清晰度。
步驟 1：定義範圍與邊界 🚧
首先識別系統內部與外部的內容。此決定將影響外部實體的位置。邊界以外的所有內容均為外部實體，邊界以內的所有內容則為流程、儲存或資料流。此處不要包含硬體或程式碼等實作細節。
步驟 2：識別外部實體 👥
列出所有與系統互動的各方。可提出以下問題：
- 誰將資訊傳送給系統？
- 誰接收系統產生的報表或輸出？
- 是否有其他系統與此系統交換資料？
將這些實體繪製在工作空間的周圍。使用清晰且具描述性的名稱。
步驟 3：確定主要流程 ⚙️
識別系統為將輸入轉換為輸出必須執行的主要功能。將相關活動歸類。例如，“訂單管理”可能是一個主要流程，包含“驗證訂單”和“更新庫存”等子流程。
- 保持流程數量在可管理範圍內（第一級建議少於 7 個）。
- 確保每個流程都有明確的目的。
- 以動詞標示流程（例如：“處理付款”）。
步驟 4：繪製資料流 🔄
繪製箭頭連接實體與流程，以及流程與流程之間。每個箭頭都必須標示描述資料的標籤。
- 確認資料流動符合邏輯。
- 確保任何資料流在穿越系統邊界前都必須經過一個流程。
- 以具體的資料封包標示資料流（例如：“客戶編號”，而非僅僅“資料”）。
步驟 5：新增資料儲存 📂
識別資訊需要儲存的位置。若資料後續需要使用，則必須存入儲存區。
- 將儲存區與讀取或寫入資料的流程連接起來。
- 確保資料流入儲存區以保存它。
- 確保資料從儲存區流出以使用它。
步驟 6：驗證並平衡 ⚖️
這是最重要的技術步驟。平衡確保父流程的輸入和輸出與其子圖（下一層）的輸入和輸出相匹配。
- 如果第 0 層有輸入「訂單」，第 1 層也必須顯示「訂單」進入主流程。
- 如果第 1 層拆分一個流程，子流程必須處理與父流程相同的資料輸入和輸出。
- 檢查是否有孤立的流程（沒有資料流的流程）。
- 檢查是否有孤立的資料儲存區（沒有資料流入或流出的儲存區）。
🧠 最佳實務與規則
遵守嚴格的規則可防止混淆。偏差可能導致對系統邏輯的誤解。
1. 命名慣例 🏷️
一致性是關鍵。所有元素都應使用標準的命名慣例。
- 實體：複數名詞（例如「客戶」、「供應商」）。
- 流程：動詞短語（例如「更新庫存」）。
- 儲存區：名詞（例如「庫存檔案」）。
- 資料流：資料名稱（例如「庫存更新」）。
2. 避免控制邏輯 🚫
資料流程圖不是流程圖。不要包含代表控制流程的判斷菱形或迴圈。如果一個判斷影響資料流，應根據資料內容將資料流拆分成不同路徑來表示，而非根據邏輯條件本身。
3. 一個箭頭，一個資料封包
不要將多種類型的資料合併到單一箭頭中。如果一個流程同時傳送「訂單資料」和「付款資料」，應繪製兩個獨立的箭頭。
4. 無直接實體到實體的資料流
資料無法在不經過系統的情況下直接從一個外部實體傳送到另一個外部實體。如果發生這種情況，表示系統被跳過，或圖表範圍不正確。
5. 避免黑洞與奇蹟
- 黑洞： 一個有輸入但無輸出的流程。資料消失。這是不可能的。
- 奇蹟： 一個有輸出但無輸入的流程。資料從無中生有。這是不可能的。
⚠️ 應避免的常見錯誤
即使經驗豐富的分析師也會犯錯。了解常見陷阱可節省審查時的時間。
錯誤 1：層級混雜
將第0層和第1層的細節放在同一頁會造成混亂。應將每一層分開，以保持清晰。
錯誤2：流程方向不一致
確保箭頭指向正確方向。常見錯誤是當處理程序實際上正在將資料寫入儲存時，卻畫出從儲存指向處理程序的箭頭。
錯誤3：標籤模糊
避免使用「資訊」、「資料」或「細節」等模糊標籤。應具體明確。「客戶細節」比「資料」更佳。「資料」對分析毫無幫助。
錯誤4：忽略資料儲存
跳過資料儲存會導致模型不完整。若資料稍後會被使用，則必須加以儲存。未包含儲存點，暗示系統為無狀態系統，這對於複雜應用而言極少正確。
🔍 高階考量
隨著系統擴大，資料流程圖（DFD）需要更嚴謹的維護。大型專案應考慮以下事項。
實體與邏輯資料流程圖
- 邏輯資料流程圖： 聚焦於業務需求。忽略紙本檔案與資料庫等技術實作細節。
- 實體資料流程圖： 反映實際實作情況。明確指定硬體、軟體與檔案類型。
最佳實務是先建立邏輯資料流程圖以達成需求共識，再推導出用於開發的實體資料流程圖。
並發與時間
標準的資料流程圖不顯示時間或並發性。它只顯示發生了什麼，而非何時發生。對於時間至關重要的系統，可能需要搭配使用其他建模技術，例如狀態轉移圖。
安全性與存取控制
雖然資料流程圖不會明確顯示安全協定，但資料流程應標示敏感資訊。包含「密碼」或「信用卡號碼」的流程應特別註記，這有助於安全架構師識別需要加密的位置。
📝 工作流程總結
建立資料流程圖是一項系統思維的嚴謹練習。它需要將複雜系統拆解為可管理的部分，同時維持資料流動的完整性。此過程從上下文圖的宏觀視角，逐步轉向詳細流程的微觀視角。
成功取決於：
- 明確界定邊界。
- 元件標籤的一致性。
- 嚴格遵守平衡規則。
- 與利害關係人共同驗證。
透過遵循這些步驟並避免常見陷阱，您將建立一個可靠的系統開發藍圖。此文件可作為資料庫設計、軟體架構與流程改善計畫的基礎。它始終是理解資訊如何透過任何組織化系統流動的永恆工具。