建立資料流程圖（DFD）是系統分析與設計中的關鍵步驟。這些視覺化表示法可描繪資料在系統中的流動，強調輸入、輸出與儲存。當繪製精確時，DFD 可作為開發人員與利害關係人的藍圖，確保所有人理解資訊的邏輯與流程。然而，要創造精確的圖表，需要紀律並遵守特定標準。本指南概述了在不依賴特定軟體工具的情況下，繪製有效資料流程圖的必要實務。
🔍 理解 DFD 的目的
在深入機制之前，了解這些圖表的重要性至關重要。資料流程圖並非流程圖，它不會顯示控制流程或像「如果-那麼」之類的決策點。相反地，它專注於資料本身。它回答的問題包括：資料來自哪裡？資料會去往哪裡？資料如何被轉換？資料儲存在哪裡？
- 溝通工具： 它彌補了技術團隊與業務利害關係人之間的差距。
- 分析輔助： 它有助於識別瓶頸、遺漏的資料或重複的流程。
- 設計基礎： 它為資料庫設計與程式架構提供結構基礎。
🧱 DFD 的核心元件
要繪製精確的圖表，必須掌握四個基本符號。每個符號都有嚴格的定義，必須遵守以維持一致性。
1. 外部實體（來源與目的地）🚪
這些代表與您的系統互動的人、組織或系統。它們是您範圍的邊界。資料從它們流入或流出。它們本身並非系統的一部分。
- 範例： 一位客戶、一位供應商，或一個外部付款網關。
- 規則： 不要將系統內的使用者與外部實體混淆。只有外部來源或接收點才屬於此處。
2. 處理程序（轉換）⚙️
處理程序是資料發生變化的地點。它們接收輸入資料，加以處理，並產生輸出資料。它們是系統的核心。每個處理程序都必須至少有一個輸入與一個輸出。
- 範例： 計算稅額、驗證登入、產生報表。
- 規則： 使用動詞命名處理程序。處理程序是一種動作，而非名詞。
3. 資料儲存（資料庫）📂
資料儲存用於後續使用的資料。它們代表資料庫、檔案，甚至實體檔案櫃。與處理程序不同，資料儲存不會改變資料；它們僅僅是儲存資料。
- 範例： 客戶資料庫、訂單記錄、庫存清單。
- 規則： 資料儲存必須與處理程序相連。資料不能在沒有處理程序處理的情況下，無故出現或消失於儲存中。
4. 數據流動（移動） 🔄
這些是連接組件的箭頭。它們顯示數據移動的方向。每個箭頭都必須有標籤，明確描述正在移動的數據內容。
- 範例： 訂單詳情、付款確認、使用者憑證。
- 規則： 箭頭應使用名詞標示，而非動詞。標籤描述的是流動內容。
📉 資料流程圖中的抽象層級
複雜系統無法在單一頁面上呈現。標準做法是將系統分解為不同層級。這稱為分解。
第0層：上下文圖 🌍
上下文圖是最高層級的視圖。它將整個系統呈現為一個單一的氣泡。它將此單一流程與所有外部實體相連接。它明確定義了系統的邊界。
- 焦點：僅限輸入與輸出。
- 細節： 最少。不包含內部流程或資料儲存。
第1層：主要流程 🔢
第1層將上下文圖中的單一氣泡分解為主要的子流程。這正是開始看到內部邏輯的地方。它通常包含系統的主要功能區域。
- 焦點： 主要功能群組。
- 細節： 包含主要的資料儲存以及主要流程之間的資料流。
第2層：詳細分解 🔍
第2層將第1層中的一個特定流程進行分解。當某個特定流程在第1層視圖下過於複雜而難以理解時，便會使用此層級。
- 焦點： 特定且複雜的操作。
- 細節： 高細節度。顯示該特定功能的每一個步驟。
✍️ 為清晰而設定的命名規範
命名是資料流程圖中最常造成混淆的來源。清晰的命名可避免分析師與開發人員之間的誤解。
流程名稱
一律使用動詞後接名詞。這描述的是對資料執行的動作。
- 良好： “驗證使用者登入”
- 不良： “登入”或“使用者登入流程”
資料流名稱
使用代表移動資料封包的特定名詞。
- 良好： “已驗證的憑證”
- 不良： “登入資料”或“執行登入”
資料儲存名稱
使用代表資料集合的名詞。
- 良好： “使用者帳戶”
- 不良： “使用者”或“資料庫”
⚖️ 資料的平衡與守恆
DFD設計中最關鍵的規則之一是平衡。當您將父流程分解為子流程時，輸入與輸出必須保持一致。
什麼是平衡？
想像您有一個稱為「處理訂單」的第1層流程。此流程接收「客戶訂單」並輸出「出貨確認」。如果您將「處理訂單」分解為第2層的子流程，這些子流程合起來仍必須接收「客戶訂單」並產生「出貨確認」。
這為什麼重要？
- 一致性： 它確保在分解過程中不會遺失任何資料。
- 可追蹤性： 它讓您能夠從頂層追蹤到底層的每一筆資料。
- 驗證： 它可作為檢查遺漏需求的依據。
如何檢查平衡？
- 列出父流程的所有輸入與輸出。
- 列出所有子流程的輸入與輸出。
- 比較兩個清單。它們必須完全匹配。
🚫 需要避免的常見錯誤
即使是經驗豐富的分析師也會犯錯。避免這些常見的陷阱將顯著提升您圖表的品質。
1. 將控制流與資料流混合
DFD 不是流程圖。不要使用箭頭來表示事件或決策的順序。如果做出決策，資料仍會流向處理結果的流程。箭頭代表資料，而非控制。
2. 黑洞與奇蹟
- 黑洞： 一個有輸入但無輸出的流程。這意味著資料正在消失，這在邏輯上是不可能的。
- 奇蹟： 一個有輸出但無輸入的流程。這意味著資料憑空產生。
3. 未連接的元件
每個元件都必須透過資料流與至少一個其他元件相連。浮動的流程或斷開的資料儲存表示邏輯上有錯誤。
4. 無流程的資料儲存
資料儲存無法直接相互溝通。兩個資料儲存之間必須始終存在一個流程。這確保資料在儲存或取出前經過驗證或轉換。
📋 DFD 檢查清單
在最終確定圖表前，使用此表格來驗證您的工作。這可確保高標準的準確性。
| 檢查 | 標準 | 通過/失敗 |
|---|---|---|
| 實體命名 | 所有外部實體是否都以名詞命名？ | ⬜ |
| 流程命名 | 所有流程是否都以動詞+名詞命名？ | ⬜ |
| 流程命名 | 所有資料流是否都以具體名詞標示？ | ⬜ |
| 守恆 | 每個流程是否至少有一個輸入和一個輸出？ | ⬜ |
| 平衡 | 子圖是否與父圖的輸入/輸出相符？ | ⬜ |
| 連通性 | 是否有任何浮動元件？ | ⬜ |
| 資料儲存 | 資料儲存是否僅與處理程序相連？ | ⬜ |
| 外部實體 | 外部實體是否永遠不會與其他實體相連？ | ⬜ |
🔄 邏輯與物理資料流程圖
區分系統的邏輯觀點與物理觀點非常重要。兩者皆有效，但用途不同。
邏輯資料流程圖
這著重於業務需求。它忽略系統實際是如何建構的。它回答「業務做什麼？」
- 範例：「處理付款」是一個處理程序。
- 優點：即使技術改變，它依然有效。
物理資料流程圖
這著重於實作。它回答「系統是如何建構的？」它包含特定的硬體、軟體模組或手動任務。
- 範例：「執行信用卡 API」或「在雷射印表機上列印收據」。
- 優點：它能直接引導開發人員和工程師。
🤝 利益相關者參與
資料流程圖是一種溝通工具。如果利益相關者無法理解它，或它未能反映他們的現實，則毫無用處。
- 走查： 安排會議，逐步引導利益相關者了解圖表。
- 反饋迴圈： 允許利益相關者指出遺漏的資料流程或錯誤的流程名稱。
- 驗證： 確保圖表與他們對業務運作方式的心理模型相符。
當利益相關者驗證圖表後，它便具有某種合約的性質。這確認了系統設計符合業務需求。這能降低開發週期後期返工的風險。
🛠️ 長期維護圖表
系統會演進，需求會變動。昨天準確的資料流程圖，今天可能已過時。為了讓您的文件保持價值，必須持續維護。
- 版本控制： 記錄不同版本的資料流程圖，以追蹤隨時間的變更。
- 更新觸發條件： 制定規則，明確何時需要更新資料流程圖（例如：新增功能請求、流程變更）。
- 中央儲存庫： 將圖表儲存在全體團隊都能存取的位置。
🔎 深入探討：處理複雜的資料流程
有時，資料流程相當複雜，可能攜帶多項資訊，或根據條件而改變。以下是不使圖表混亂的處理方式。
資料分組
不要為每個資料欄位都畫一條箭頭。將相關資料整合成一個邏輯資料包。
- 範例： 不要分別為「姓名」、「地址」和「電話」畫箭頭，改為畫一條標示為「客戶資訊」的箭頭。
條件性流程
雖然資料流程圖通常不會顯示決策邏輯，但有時資料僅在特定條件下才會流動。您可以在箭頭上標註以表示此情況。
- 範例： 將箭頭標示為「已批准訂單」，以區別於「已拒絕訂單」。
📝 文件編寫最佳實務
圖表只是故事的一部分。您必須記錄元件的定義，以確保清晰明確。
- 術語表： 為圖表中使用的所有術語建立術語表（例如：什麼定義了「已驗證使用者」？）
- 流程規格： 對於複雜流程，撰寫一段簡短的邏輯說明。
- 資料字典： 定義資料儲存和流程的結構。
文件支援圖表。它提供了視覺符號無法傳達的必要背景資訊。若無此資訊，圖表將容易產生多種解讀。
🎯 主要重點摘要
精確的資料流程圖建立在一致性、清晰度以及嚴格遵守規則的基礎上。遵循本文所述的實務做法，您便能創建出能有效傳達系統邏輯的圖表。
- 專注於資料： 專注於資料的移動，而非控制流程。
- 使用一致的命名： 流程使用動詞，資料使用名詞。
- 仔細分解： 保持各層級之間的平衡。
- 與相關方共同驗證： 確保模型反映現實情況。
- 徹底記錄： 在視覺圖示之外提供背景資訊。
花時間繪製精確的資料流程圖，能減少開發錯誤並提升溝通清晰度，為任何系統分析專案奠定堅實基礎。