建立資料流程圖(DFD)是理解資訊如何在系統中流動的關鍵步驟。這些圖表為開發人員、利害關係人和分析師提供了藍圖。然而,一個構建不良的模型可能會導致混淆、開發錯誤和系統失敗。當資料流被錯誤地呈現時,整個應用程式的邏輯就會受到質疑。本指南探討了DFD中常見的錯誤,並提供權威的策略來修正它們。 許多團隊急於完成建模階段,認為視覺化呈現次於程式碼。這種做法是錯誤的。DFD在撰寫任何程式碼之前就定義了邏輯。如果圖表有問題,建立在它之上的軟體將繼承這些結構上的弱點。我們將檢視會破壞模型完整性的特定錯誤類別,並提供明確的解決途徑。 1. 上下文圖失敗 🌍 上下文圖是系統的最高層級視圖。它將整個系統表示為單一處理程序,並顯示系統如何與外部世界互動。這裡的錯誤會為所有後續層級奠定不良基礎。 遺漏外部實體 外部實體代表與你的系統互動的使用者、其他系統或組織。一個常見的錯誤是遺漏一個關鍵實體。如果你遺忘了一個使用者群組或外部API,需求就會不完整。 影響:開發過程中會遺漏關鍵功能。 修正:進行利害關係人訪談,以識別所有資料來源與終點。 清單:在繪製泡泡之前,列出所有接觸系統的參與者。 邊界不清 系統邊界必須明確界定。有時,本應在系統內部的處理程序被畫在外部,反之亦然。這會導致責任歸屬不清晰。 影響:開發人員可能會在預期範圍之外建立功能。 修正:確保上下文泡泡內的所有處理程序都屬於系統。所有泡泡外的實體都是外部的。 清單:問自己:「這個處理程序是在我們的軟體內部執行,還是外部執行?」 2. 處理程序命名與邏輯錯誤 🧠 處理程序轉換資料。它們是圖表中的主動元件。錯誤地命名和定義這些處理程序,是破壞性最大的錯誤之一。 動詞-名詞規則違背 處理程序名稱應遵循動詞-名詞結構。像「Sales」這樣的名稱是名詞。像「Calculate Sales」這樣的名稱是動詞-名詞短語。這種區分能清楚說明正在執行的動作。 影響:模糊的需求會導致不一致的實作。 修正:檢視每個處理程序標籤。它是否描述了對資料的動作? 清單: 如果名稱只是一個名詞,請加上動詞。 神奇的流程 神奇的流程是指具有輸入但無輸出,或具有輸出但無輸入的流程。它能從無到有創造資料,或消耗資料卻不回傳結果。 影響:










