DFD深度：如何從上下文圖層下探至第1層圖示

資料流程圖（DFD）是系統分析與設計中的基本工具。它提供了一種視覺化方式，用以呈現資訊如何在系統中流動。理解DFD的深度對於確保需求被準確捕捉至關重要。本指南探討了從高階的上下文圖逐步下探至詳細的第1層圖的過程。我們將不依賴特定軟體工具，探討分解、資料守恆與結構完整性等原則。

理解DFD層級結構 🏗️

DFD並非平面文件；它們存在於層級結構中。這種結構使分析師能從不同細節層次觀察系統。每一層都為流程與資料流增加更多明確性。

• 上下文圖（第0層）： 最高層級。它將系統呈現為一個與外部實體互動的單一流程。
• 第1層圖示： 第一次分解。它將單一流程拆分為主要的子流程。
• 第2層圖示： 必要時對第1層流程進行進一步分解。

從上下文圖轉向第1層圖，通常是新手分析師面臨最具挑戰性的步驟。這需要在清晰度與細節之間取得平衡。若圖示過於抽象，則缺乏可執行的資訊；若過於細膩，則會變得雜亂，失去整體視野。

上下文圖：系統邊界 🚧

上下文圖是整個DFD套件的基石。它定義了被研究系統的邊界。圓圈內的所有內容均屬於系統的一部分；圓圈外的所有內容則為外部。

關鍵元件

• 中央流程： 以單一圓形或圓角矩形表示。代表整個系統。
• 外部實體： 資料的來源或目的地。這些可能是個人、部門或其他系統。
• 資料流： 連接實體與流程的箭頭。這些代表輸入或輸出。

定義邊界

建立邊界至關重要。若實體位於當前專案範圍之外，則為外部實體。例如，在薪資系統中，稅務機關可能是外部實體，但財務部門則為內部實體。錯誤識別邊界將導致範圍蔓延與混淆。

上下文圖的最佳實務

• 保持簡潔： 應僅有一個中央流程。
• 限制實體數量： 實體過多會使圖示雜亂。應專注於與系統直接互動的實體。
• 明確命名資料流： 資料流應以名詞命名（例如「發票」），而非動詞（例如「發送發票」）。
• 無資料儲存： 上下文圖通常不包含資料儲存。所有資料必須來自或前往外部實體。

分解：深入探查的藝術 📉

分解是將複雜流程拆分成較小、更易管理的子流程的過程。這是建立第1級圖表的核心機制。這不僅僅是分割任務，更在於揭示系統的內部邏輯。

分解原則

從第0級移動到第1級時，必須遵循若干規則以維持邏輯一致性。

• 資料守恆： 父流程的輸入與輸出必須與子流程的輸入與輸出總和相符。任何東西都不能憑空消失或出現。
• 邏輯分組： 子流程應按功能進行分組。例如，“驗證訂單”與“更新庫存”是不同的功能。
• 流程數量： 雖然沒有硬性限制，但第1級圖表通常應包含5到9個流程。如果超過此數量，應考慮將其分組為更高層級的第1級，或拆分圖表。
• 有意義的名稱： 流程名稱應遵循動詞-名詞格式（例如「計算稅額」）。這能清楚地區分它們與資料流的不同。

平衡的藝術

其中最重要的技術要求之一是資料流平衡。進入第0級流程的資料必須等於進入第1級流程的資料總和。同樣地，離開第0級流程的資料也必須等於離開第1級流程的資料總和。

如果上下文圖顯示「訂單表單」進入系統，則第1級圖表必須顯示同一個「訂單表單」進入某個子流程。如果第1級圖表顯示「客戶編號」在內部傳遞，則它在第0級圖表中不能是外部輸入或輸出，除非該編號已在第0級中出現。

建構第1級圖表 🛠️

一旦分解計畫準備就緒，實際建構便開始。這包括識別系統的主要功能區域。

步驟1：識別主要流程

觀察上下文圖中的單一流程。問：為實現系統目的，需要哪些主要活動？這些活動將成為第1級圖表中的氣泡或圓圈。

• 是否存在明確的資料輸入階段？
• 是否存在明確的處理或運算階段？
• 是否存在明確的報表或輸出階段？

步驟2：繪製流程

以箭頭連接各流程。這些箭頭代表內部流程之間的資料移動。你也可以繪製箭頭，將外部實體與這些新子流程連接。

• 直接流動： 資料從一個流程移動到另一個流程。
• 實體流動： 資料從外部實體移動到一個流程。
• 儲存流動： 數據從流程移動到資料儲存，或反之亦然。

步驟 3：引入資料儲存

雖然上下文圖會排除它們，但一級圖經常包含資料儲存。資料儲存是資料靜止存放的地方。它可以是資料庫、檔案，或實體的檔案櫃。

繪製資料儲存時：

• 使用開口矩形或您的方法論中定義的特定符號。
• 確保每個資料儲存至少有一個寫入它的流程和一個讀取它的流程。
• 避免創造「黑洞」，即資料進入儲存但從未離開，或「奇蹟」，即資料離開儲存但從未進入。

常見錯誤與修正 ⚠️

即使經驗豐富的分析師在建立資料流程圖時也會遇到錯誤。及早識別這些模式可節省驗證期間的時間。

1. 黑洞

黑洞是一種具有輸入但無輸出的流程。這表示資料被消耗卻未產生任何結果。在功能系統中，每個輸入都必須產生某種形式的輸出或資料儲存。

2. 奇蹟

奇蹟是一種具有輸出但無輸入的流程。這表示資料是從無中產生的。每個輸出都必須源自某種輸入資料。

3. 控制流程

資料流程圖追蹤資料流程，而非控制流程。控制流程代表啟動或停止流程的訊號（例如：「按下開始按鈕」）。如果你看到一個看似控制訊號的流程，它很可能實際上是資料（例如：「開始請求」）。資料流程圖不會明確處理時間或邏輯控制。

4. 流程不平衡

當一級圖的輸入與上下文圖的輸入不一致時就會發生此情況。繪製完一級圖後，務必驗證資料的守恆性。

資料流程圖層級比較 📊

下表總結了各層級之間的差異，以協助理解何時應使用哪一層級。

驗證與優化 🔍

完成初步草圖後，必須對圖表進行驗證。這不是一次性的檢查，而是一個反覆審查與優化的循環。

• 同儕審查：請另一位分析師檢視圖表。他們可能會發現你認為顯而易見但文件中遺漏的流程。
• 利害關係人驗證：與業務使用者一起走查圖表。詢問流程是否符合他們的日常運作。
• 完整性檢查： 確保每個外部實體都有連接。確保每個資料儲存都有存取權。
• 一致性檢查： 檢查命名慣例。確保同一處的「訂單」不會在另一處被稱為「採購請求」。

深度的進階考量 🧠

當你深入 DFD 結構時，將面臨細節層級的決策。應該深入到什麼程度？

細節層級的門檻

並無通用法則，但存在一般性指導原則：

• 功能完整性： 一個流程應代表一個完整的業務功能。
• 可管理性： 圖表應能完整顯示在標準頁面或螢幕上，無需滾動。
• 複雜度： 如果一級流程包含超過 7 個子流程，可能需要獨立的二級圖表。

資料儲存的處理

資料儲存可能使視覺流程變得複雜。請確保它們放置得合乎邏輯。不要畫一條線穿過流程。如果線必須穿過流程，請使用連接點或節點符號來表示這是經過而非互動。

外部實體與內部角色

區分系統內的參與者與系統外的參與者。如果人工操作員是系統工作流程的一部分（例如，一名職員輸入資料），他們可能是內部參與者，但通常會被視為外部實體，因為他們位於軟體邊界之外。此定義的一致性至關重要。

文件編寫最佳實務 📝

圖表僅是故事的一部分。需要文字描述來解釋邏輯。

• 流程字典：建立一份文件，描述每一項流程。包含輸入、輸出以及使用的特定邏輯（例如：「如果餘額 < 0，則標記為逾期」）。
• 資料字典：定義每一筆資料元素。明確指定資料類型、長度與允許的值。
• 圖例：若使用自訂符號，請提供圖例以說明其含義。

深入分析流程摘要 🔄

成功從上下文圖轉向一級圖，需要採取嚴謹的方法。這並非多畫幾個方框，而是要揭示系統的真實面貌。

• 從一張明確的上下文圖開始，以界定邊界。
• 識別構成系統的主要功能區域。
• 應用資料守恆原則，以確保平衡。
• 在資訊被保留的位置加入資料儲存。
• 與利害關係人核對，以確保準確性。

透過遵循這些結構化步驟，您將建立系統設計的穩固基礎。一級圖表成為開發人員的藍圖，也是業務利害關係人之間的溝通工具。它彌補了抽象需求與具體實現之間的差距。