理解資訊如何在系統中流動，對任何分析師或開發人員都至關重要。資料流圖（DFD）提供了這種流動的視覺化表示。它標示出資料的來源、變化方式以及最終去向。本指南概述了以精確與清晰的方式創建這些圖表的過程。
為什麼要視覺化資料流動？ 📊
在拿起筆或打開畫布之前，必須先了解圖表的目的。DFD並非流程圖，它不會顯示控制流或邏輯決策。相反地，它專注於資料的流動。此區別對於維持準確性至關重要。
視覺化資料流動帶來多項具體效益：
- 清晰度：當複雜系統被分解為視覺化元件時，將更容易理解。
- 溝通：利益相關者可以在不需要程式碼知識的情況下討論系統行為。
- 缺口分析：遺漏的資料儲存或不必要的資料流，在繪製過程中會變得顯而易見。
- 文件化：此圖表作為系統需求的活文件。
資料流圖的核心元件 🧩
每個DFD都依賴於四種標準符號。這些符號構成了圖表的詞彙。正確使用它們，可確保任何閱讀圖表的人都能理解系統架構。
1. 外部實體（來源或目的地）
外部實體代表與流程互動的人、組織或其他系統。它們位於系統邊界之外。資料從它們流入或流出。通常以方形或矩形繪製。
2. 流程（轉換）
流程會改變資料。它接收輸入，執行計算或動作，並產生輸出。這是圖表的核心。流程通常以圓形或圓角矩形表示。每個流程都必須至少有一個輸入和一個輸出。
3. 資料儲存（資料倉庫）
資料儲存用於暫存資訊以供後續使用。與流程不同，它們不會轉換資料，僅負責安全保存。範例包括資料庫、檔案或佇列。這些通常以開口矩形或平行線表示。
4. 資料流（連結）
資料流代表資訊的移動。箭頭表示方向。每個資料流都必須以描述資料的名詞片語標示，而非動詞。例如，“訂單詳情”是正確的，而“處理訂單”則是錯誤的。
準備階段 📝
直接開始繪圖往往會導致混亂。準備階段可確保圖表保持可管理性。在繪製第一條線之前，請遵循以下步驟。
定義系統邊界
識別系統內部與外部的內容。邊界內的所有項目均由軟體或流程管理，邊界外的則為外部。此邊界有助於決定外部實體的放置位置。
收集資訊來源
檢閱現有文件、訪談利益相關者並分析現有工作流程。您必須清楚資料如何進入系統，以及預期產生哪些結果。若缺乏準確的輸入資料，圖表將僅為猜測。
步驟 1：上下文圖 🌍
上下文圖是高階視圖。它將整個系統視為單一流程，並顯示與其互動的外部實體。這是任何DFD的起點。
- 識別單一流程：繪製一個圓形或氣泡來代表整個系統，並為其命名，例如「訂單管理系統」。
- 放置外部實體：為所有涉及的使用者、部門或外部系統繪製方框。範例包括「客戶」、「倉庫」或「付款網關」。
- 繪製資料流：使用箭頭將實體連接到中央流程。為每個箭頭標示所交換的資料。若資料同時被傳送與接收，請確保箭頭為雙向。
- 驗證完整性：確認所有外部互動均已納入。若某實體傳送資料但未接收任何資料，請確認是否遺漏回應。
步驟 2：Level 0 圖（頂層） 🏗️
建立上下文後，將單一流程分解為主要的子流程。這稱為 Level 0 圖。它將系統劃分為主要的功能區域。
- 分解流程：以 3 到 7 個主要流程取代單一上下文流程。避免過多，以免造成混亂；也避免過少，以免缺乏細節。
- 識別資料儲存：判斷在此層級資料需要儲存的位置。在資訊被讀取或儲存的流程之間放置資料儲存區。
- 連接流程：在流程、實體與儲存區之間繪製箭頭。確保每個流程都有輸入與輸出。
- 保持平衡：此層級的輸入與輸出必須與上下文圖一致。若上下文圖顯示「訂單」進入，Level 0 圖必須顯示「訂單」進入某個子流程。
步驟 3：分解至 Level 1 及更進一步 🔍
若 Level 0 圖中的某個流程較為複雜，則需進一步分解。這會產生 Level 1 圖。你可以持續此過程，直到流程簡單到足以直接實作為止。
分解規則
- 一次只分解一個流程：專注於分解一個子流程後，再進行下一個。不要試圖一次繪製整個系統。
- 保留流程：當你將一個流程分解為較小的流程時，流入原流程的資料必須流入新的子流程；流出的資料必須來自新的子流程。
- 限制細節：當邏輯清晰到開發者無需進一步說明即可撰碼時，便停止分解。通常，大多數系統只需三個層級便足夠。
命名規範與最佳實務 🏷️
一致的命名可使圖表更易閱讀。命名不一致會導致混淆與錯誤。
流程名稱
流程名稱應為動詞加上名詞。例如「驗證使用者」、「計算稅額」或「產生報表」。這表示動作。避免使用模糊的名稱，如「系統」或「資料」。使用主動動詞來描述轉換。
資料流名稱
資料流名稱應為名詞或名詞片語。例如「客戶編號」、「發票」或「付款收據」。避免使用「發送發票」等動詞，因為資料流本身是資料，而非動作。動作是由流程所執行的。
實體名稱
外部實體應使用單數或複數名詞來代表行動者。應使用「客戶」而非「客戶資料」。應使用「倉庫」而非「倉庫管理」。實體是行動者，而非資料。
資料流規則與限制 ⚖️
遵守嚴格的規則可防止設計中的邏輯錯誤。這些限制確保圖表能正確反映一個有效的系統。
| 規則 | 描述 |
|---|---|
| 資料儲存輸入 | 資料只能由流程寫入儲存體。實體與儲存體之間的直接資料流通常不被允許。 |
| 資料儲存輸出 | 資料只能由流程從儲存體讀取。實體無法直接存取儲存體。 |
| 流程輸入/輸出 | 每個流程都必須至少有一個輸入和一個輸出。一個只消耗資料而不產生資料的流程稱為「黑洞」。一個不需輸入就產生資料的流程稱為「神奇來源」。兩者都是錯誤。 |
| 資料流交叉 | 資料流不應直接穿越資料儲存體或外部實體。它們必須經過一個流程。 |
驗證與審查 ✅
圖表繪製完成後，必須進行驗證。此步驟確保模型與現實相符。
檢查平衡性
將父流程的輸入與輸出與其子流程進行比較。進入父流程的資料必須等於進入子流程的資料總和。離開父流程的資料必須等於離開子流程的資料總和。若不相符，則圖表不平衡，需進行修正。
檢查完整性
審查每一筆資料流。每筆資料是否都有明確的去向？每個流程是否都有明確的來源？是否存在沒有任何連接的孤兒資料儲存體？完整的圖表應無任何未連接的末端。
利害關係人驗證
將圖表展示給使用系統的人。請他們追蹤資料流。他們是否同意此路徑？是否發現遺漏的步驟？他們的反饋是準確性的最終測試。
維護圖表 🔄
DFD 不是一次性任務。系統會演進，需求也會改變。圖表必須隨著系統一同演進。
- 版本控制： 記錄所有變更。以日期或編號標示版本。
- 定期更新：每當新增功能或流程變更時，立即更新資料流程圖。
- 存檔舊版本：保留舊的圖表以供審計或除錯時參考。
視覺準確性的結論 🎯
建立資料流程圖是一項需要紀律的邏輯與視覺化練習。它需要耐心將複雜的系統分解為可理解的部分。透過遵循上述步驟，您可以產製出一份可靠的開發與溝通藍圖。
目標不僅僅是畫線，而是理解資料流。當資料流清晰時，系統設計也會變得清晰。這種清晰度能減少錯誤，並提升最終產品品質。專注於資料，而非程式碼，圖表便能有效達成其目的。