DFD 教程：如何在任何業務系統中建模數據流動

資料流圖（DFD）是資訊系統的視覺藍圖。與透過語法描述邏輯的程式碼不同，DFD 是透過流動來描述邏輯。它描繪資料如何進入系統，經過各種流程轉換，最終以輸出或儲存的形式離開。本指南全面介紹如何在不依賴專有工具的情況下構建這些圖表，專注於系統分析的基本原則。

無論您是在為新應用程式定義需求，還是審計現有的遺留系統，理解資料流動都至關重要。結構良好的 DFD 可消除歧義，迫使利益相關者就資訊的來源與終止點達成共識。本文探討 DFD 的結構組成、構建規則，以及將複雜系統分解為可管理視圖的方法論。

🧠 理解核心概念

資料流圖並非控制流圖。它不顯示事件的時間或順序。相反，它專注於資料本身。可將其視為一個河川系統的地圖。你不必關心水流的速度或天氣狀況，而是關心支流、水庫以及河流的河口。

在建模業務系統時，DFD 回答三個主要問題：

• 資料來自哪裡？（外部實體）
• 資料是如何被改變的？（流程）
• 資料儲存在哪裡？（資料儲存）

透過回答這些問題，您便能建立業務的邏輯表示。這種表示方式無論使用何種技術堆疊來建構系統，都保持有效。它是一種抽象語言，能夠彌合業務需求與技術實現之間的差距。

🔑 四個基本元件

每個資料流圖都是由四個特定符號構成。雖然不同方法論之間的符號表示略有差異，但其背後的概念始終一致。掌握這些元素是準確建模的基礎。

1. 外部實體 🏢

外部實體代表位於所建模系統邊界之外的資料來源或目的地。它們通常是與主系統互動的人、部門或其他系統。

• 來源： 一位客戶提交訂單。
• 目的地： 接收報告的稅務機關。
• 系統： 一個外部支付網關。

在圖表中，這些通常以方形或矩形表示。它們必須始終與流程相連；資料不能憑空出現或無聲消失。

2. 流程 ⚙️

流程將輸入資料轉換為輸出資料。它是系統的引擎。在 DFD 中，流程通常以圓形或圓角矩形表示。流程名稱應始終使用動詞-名詞短語，以表示動作。

• 有效： 「驗證訂單」、「計算稅額」。
• 無效： 「訂單」、「稅額」。

每個流程都必須至少有一個輸入和一個輸出。如果流程有輸入但無輸出，則稱為「黑洞」；如果流程有輸出但無輸入，則稱為「奇蹟」。兩者都代表建模錯誤。

3. 資料儲存 💾

資料儲存代表資訊被保存以供後續檢索的場所。這可能是資料庫、檔案系統、實體檔案櫃，或暫時緩衝區。與流程不同，資料儲存不會改變資料；它僅用來儲存資料。

• 範例：客戶資料庫、庫存日誌、暫存購物車。

這些通常繪製為開口的矩形或兩條平行線。它們通過資料流與流程相連，表示讀取或寫入操作。

4. 資料流 🔄

資料流是連接各組件的箭頭。它們代表資料在實體、流程和儲存之間的移動。箭頭頭部表示移動方向。

• 標籤：每個箭頭都必須有唯一的標籤，用以描述資料封包。
• 命名：使用名詞，例如「發票」、「登入憑證」或「庫存報表」。
• 方向：資料流是單向的。如果資料雙向流動，應繪製兩個獨立的箭頭。

📉 分解層級

複雜系統無法繪製在單一頁面上。為了管理複雜性，資料流程圖（DFD）會被分解為不同細節層級。這種層次化方法讓分析師能夠深入或跳出系統架構進行檢視。

第0層：環境圖

環境圖是最高層次的視圖。它將整個系統呈現為一個單一的流程氣泡。它說明系統與外部實體之間的互動方式。

• 範圍：一個核心流程。
• 細節：極簡。僅包含輸入與輸出。
• 目的：用以定義專案的範圍邊界。

第1層：功能分解

第1層將環境圖中的單一流程擴展為主要的子流程。此層級識別系統的主要功能區域。

• 範圍：最多5至9個流程。
• 細節：顯示主要的資料儲存與互動。
• 目的：用以勾勒系統的主要模組。

第2層：詳細邏輯

第二層會針對第一層中的特定流程進行細節放大。它會將複雜的功能分解為較小且可執行的步驟。此層通常是開發人員尋找特定邏輯需求的地方。

• 範圍：多個圖表，每個主要的第一層流程對應一個圖表。
• 細節：細粒度的資料元素與儲存點。
• 目的：用於技術規格說明與程式碼撰寫。

📐 比較符號風格

系統分析中使用兩種主要的符號風格。雖然邏輯相同，但視覺呈現方式有所不同。選擇合適的符號風格取決於團隊的熟悉程度以及組織的標準。

功能	Yourdon & DeMarco	Gane & Sarson
流程形狀	圓角矩形	圓角矩形
實體形狀	方形	方形
資料儲存形狀	開放矩形	頂部或底部較粗的開放矩形
資料流形狀	曲線箭頭	直線箭頭
流程標籤位置	線條下方	線上或線下

在 Gane & Sarson 與 Yourdon & DeMarco 之間的選擇主要屬於外觀層面。然而，一致性至關重要。在單一文件中混合使用不同符號風格會造成混淆，降低文件的清晰度。

🛠 分步建構指南

建立資料流程圖（DFD）是一個系統性的過程，需要反覆迭代與驗證。遵循以下步驟，以確保準確性與完整性。

步驟 1：定義系統邊界

在繪製任何一條線之前，請先明確系統內部與外部的內容。這通常由專案範圍決定。任何提供輸入或接收輸出的事物都是邊界條件。

步驟 2：識別外部實體

列出所有來源與目的地。透過訪談利害關係人來確認誰與系統互動。不要忽略自動化系統；它們與人類一樣，都是實體。

步驟 3：繪製上下文圖

從整體視角出發。將系統繪製為一個泡泡。用箭頭連接外部實體，並以所交換的資料標示箭頭。這將作為所有後續圖表的基礎。

步驟 4：分解主要流程

將單一泡泡擴展為第 1 層。識別主要功能，將系統分解為邏輯模組。確保第 0 層圖表的輸入與輸出，與第 1 層流程的總輸入與總輸出相符。

步驟 5：新增資料儲存

識別資料必須持久化的地點。如果某個流程需要記住前一次交易的資訊，則必須設立資料儲存。將這些儲存連接到相關的流程。

步驟 6：平衡圖表

這是一項關鍵規則。父流程的輸入與輸出必須等於其子流程輸入與輸出的總和。如果上下文圖顯示「訂單已收到」，則第 1 層圖表也必須在某處顯示「訂單已收到」進入系統。

步驟 7：審查與優化

走過整個圖表。追蹤一筆資料從開始到結束的流程。其流動是否合乎邏輯？是否存在孤立的流程？所有資料流是否都已標示？

⚠️ 應避免的常見陷阱

即使經驗豐富的分析師在建構這些模型時也會犯錯。了解常見錯誤可大幅節省審查階段的時間。

• 控制流：不要顯示系統事件、觸發條件或控制信號。資料流程圖僅顯示資料，而非控制。若需顯示觸發條件，必須以資料進入流程的方式呈現。
• 雜亂的資料流：盡可能避免線條交叉。若線條必須交叉，請使用「橋樑」符號或重新調整佈局。清晰度比美觀更重要。
• 遺漏的資料儲存：若某流程讀取資料，表示存在儲存；若某流程寫入資料，也表示存在儲存。不要讓這些連接關係隱含不顯。
• 幽靈流程：不要建立無任何作用的流程。每個流程都必須轉換資料。
• 實體間直接資料流：資料無法在系統外的兩個外部實體之間直接流動。所有互動都必須經過系統邊界。

🔍 邏輯模型與物理模型

區分系統的邏輯觀點與物理觀點非常重要。邏輯資料流程圖描述系統做什麼系統的功能。物理資料流程圖描述如何系統是如何做到的。

• 邏輯層面：專注於業務規則。「驗證付款」。不指定軟體。
• 物理層面：專注於實作。「呼叫付款 API v2」。明確指定技術。

從邏輯模型開始。不要過早引入技術限制。過早引入技術可能會限制設計選項，並在分析中產生偏見。邏輯模型獲得批准後，便可推導出物理模型，以指導開發。

📋 文件編寫的最佳實務

為確保資料流程圖在整個專案生命週期中持續有用，請遵守這些標準。

• 命名一致性：使用資料字典來統一名稱。同一張圖中，「客戶」不應稱為「客戶」或「使用者」。
• 唯一編號：為每個流程編號。1.0、1.1、1.2。這能讓文件中的引用更為容易。
• 標籤簡潔：保持資料流標籤簡潔。若標籤過長，應在術語表中定義。
• 版本控制：將圖表視為程式碼一樣對待。它們會變動。需追蹤版本變更，以了解系統的演變過程。
• 交叉參考：將資料流程圖與其他文件連結。參考實體關係圖（ERD）以了解資料結構，並參考使用案例圖以了解使用者互動。

💡 視覺思維的價值

為什麼要花時間繪製這些圖表？文字需求容易產生誤解。描述流程的一句話可能有多種詮釋方式。而圖表具有視覺與空間特性。

當利益相關者看到圖表時，能立即發現遺漏的流程。他們能察覺資料重複的位置。他們能一眼理解系統的複雜性。這種視覺確認能降低建造錯誤系統的風險。

此外，資料流程圖是業務團隊與技術團隊之間的溝通工具。業務分析師利用它來理解需求，開發人員則用它來理解架構。透過維持一個共用的文件，組織能減少資訊孤島，並提升協調性。

🚀 繼續前進

實施資料流程圖方法論需要紀律。僅僅畫出線條是不夠的；你必須理解資料守恆與分解的規則。隨著練習，你會發現圖表自然成為你思考過程的延伸。

從小處著手。先模擬一個簡單的交易。接著擴展到部門層級。最後模擬整個企業。隨著每一層級的深化，你對系統的理解也更為透徹。目標不是創造一幅完美的圖表，而是建立一幅清晰的資訊流動地圖，以引導穩健軟體解決方案的建構。

請記住，圖表是思考的工具，而不僅僅是存檔的文件。運用它來挑戰假設、發現缺口並驗證邏輯。在系統設計的領域中，清晰始終是最高形式的精確。

📝 關鍵原則摘要

• 守恆：資料從不被創造或消滅，僅被轉換。
• 分解： 將複雜的系統分解為可管理的子系統。
• 平衡： 子圖必須與父圖的輸入和輸出相匹配。
• 抽象： 將邏輯需求與物理實現分離。
• 清晰度： 优先考虑可读性，而非外觀上的複雜性。

遵循這些原則，可確保任何業務系統中的資料流動都能精確記錄，並讓專案生命週期中所有相關利益關係人充分理解。