Visual Paradigm是包含設計共享、線框圖和數據庫設計新特性的企業項目設計工具。Visual Paradigm公司在其核心產品Visual Paradigm for UML更新到v11.1的時候，把三個原始的系列產品（Agilian、Visual Paradigm for UML和Logizian）融合在一起，將最初為不同建模功能服務的多個獨立產品整合成的一個產品，其名字被命名為Visual Paradigm——與公司的名字相同。現在你只需要這樣單獨的一款模型軟件 Visual Paradigm就可以完成用UML設計軟件，用BPMN去執行業務流程分析，用ERD企業設計數據庫的任務。

Visual Paradigm現已更新至最新版本16.0，新版本引入了大型Scrum畫布和幾十種新的圖案，同時還增強了在線圖表功能和支持從Customer Journey Map打開完整圖表編輯器的功能。新版本，新功能，趕快下載體驗吧！（Visual Paradigm現已加入在線訂購，現在搶購立享優惠！）

點擊下載Visual Paradigm最新試用版

數據流圖（DFD）提供了系統內信息（即數據）流的直觀表示。通過創建數據流程圖，您可以告訴參與系統流程的人員所提供并傳遞給其的信息，完成流程所需的信息以及需要存儲和訪問的信息。數據流程圖在軟件工程中被廣泛使用。您可以在建模信息系統中使用DFD。本文以客戶服務系統為例介紹和解釋數據流程圖（DFD）。

推薦閱讀：

• Visual Paradigm教程：數據流程圖示例

• Visual Paradigm教程：如何創建數據流圖（DFD）？

CS系統示例

數據流程圖是圖的層次結構，包括：

1、上下文圖（概念上為零級）
2、1級DFD
3、以及可能的2級DFD和進一步的功能分解級別，具體取決于系統的復雜性

上下文DFD

下圖顯示了為鐵路公司的客戶服務系統繪制的上下文數據流程圖。它包含一個過程（形狀），代表要建模的系統，在本例中為“ CS系統 ”。它還顯示了將與系統交互的參與者，稱為外部實體。在此示例中，CS Assistant和Passenger是將與系統交互的兩個實體。在流程與外部實體之間，存在數據流（連接器），這些數據流指示實體與系統之間存在信息交換。

上下文DFD是數據流模型的入口。它僅包含一個進程，并且不顯示任何數據存儲。

1級DFD

下圖顯示了1級DFD，它是上下文DFD中顯示的CS系統過程的分解（即分解）。通讀該圖，然后我們將基于此圖介紹一些

CS系統數據流程圖示例包含四個流程，兩個外部實體和四個數據存儲。盡管沒有設計指南可以控制形狀在數據流程圖中的位置，但是我們傾向于將過程放在中間，而將數據存儲和側面的外部實體放在一邊，以便于理解。

根據該圖，我們知道乘客可以從“ 查詢運輸明細”流程中接收運輸明細，并且該明細由數據存儲“ 運輸明細”和“ 鐵路實時統計”提供。雖然存儲在“ 運輸詳細信息”中的數據是持久性數據（用標簽“ D”表示），但是“ 鐵路實時統計”中存儲的數據是短暫的瞬態數據（用標簽“ T”表示）。標注形狀用于列出乘客可以查詢的詳細信息的種類。

CS Assistant可以啟動“ 購買紀念品”流程，這將導致將訂單詳細信息存儲在“ 訂單”數據存儲區中。盡管客戶是購買紀念品的真實人，但是由CS助手訪問系統來存儲訂單詳細信息。因此，我們使數據從CS助手流向購買紀念品流程。

CS Assistant還可以通過提供訂單明細來啟動“ 購買憑單”流程，該明細將再次存儲在“ 訂單”數據存儲區中。數據流圖是一個高度抽象的高級圖。此處繪制的數據存儲Order不一定表示真實的訂單數據庫或數據庫中的訂單表。訂單詳細信息的物理存儲方式將在以后實現系統時確定。

最后，CS Assistant可以通過提供事件和項目詳細信息來啟動“ 報告丟失”過程，并且該信息將存儲在“ 丟失的項目”數據庫中。

數據流程圖提示和注意事項

用D，M和T聲明數據類型

在數據流程圖中繪制的每個數據存儲都以字母為前綴，默認情況下為“ D”。該字母表示數據存儲區保存的數據類型。字母“ D”用于表示持久的計算機化數據，這可能是典型信息系統中最常見的數據類型。除了計算機化數據外，數據還可以暫時保留一小段時間。我們稱這種數據為暫態數據，用字母“ T”表示。有時，無需使用計算機即可存儲數據。我們稱這種數據為手動數據，用字母“ M”表示。最后，如果數據是在不使用計算機的情況下存儲的，并且也保留了很短的時間，則稱為手動瞬態數據，并用T（M）表示。

注意細節級別

在此數據流程圖示例中，標記數據時，多次使用“細節”一詞。我們有“運輸詳細信息”和“訂單詳細信息”。如果我們將其明確寫為“路線信息，火車時間和延誤”，“紀念品名稱，數量和數量”以及“機票類型和數量”怎么辦？這個對嗎？好吧，這個問題沒有確定的答案，但是在做出決定時嘗試問自己一個問題。為什么要繪制DFD？

在大多數情況下，數據流程圖是在系統開發的早期階段繪制的，其中許多細節尚待確認。諸如“詳細信息”，“信息”，“憑證”之類的通用術語的使用無疑為討論留下了空間。但是，使用通用術語可能會缺少細節，從而使設計失去用處。因此，這實際上取決于您設計的目的。

不要透支

在數據流程圖中，我們專注于系統與外部各方之間的交互，而不是接口之間的內部通信。因此，接口與所使用的數據存儲之間的數據流被認為是超出范圍的，因此不應在圖中顯示。

不要混淆數據流和流程流

一些設計人員在遇到從數據存儲區到流程的連接器時可能會感到不舒服，而沒有在圖表上指定數據請求的步驟。一些設計人員將嘗試將附加到連接器的請求放置在流程和數據存儲之間，將其標記為“請求”或“對某物的請求”，這肯定是不必要的。

請記住，數據流程圖是為表示信息交換而設計的。數據流程圖中的連接器用于表示數據，而不用于表示流程，步驟或其他任何內容。當我們將以數據存儲結尾的數據流標記為“請求”時，從字面上看，這意味著我們正在將請求作為數據傳遞到數據存儲中。盡管在實現級別可能是這種情況，因為某些DBMS確實支持使用函數，這些函數會吸收一些值作為參數并返回結果，但是，在數據流程圖中，我們傾向于將數據存儲視為唯一的數據持有人沒有任何處理能力。如果要對系統流或流程進行建模，則可以使用“ 活動圖”或“ BPMN業務流程圖”代替。如果要對數據存儲的內部結構建模，可以使用Entity Relationship Diagram。

=====================================================

更多Visual Paradigm相關資源，請點擊此處進行查看~

想要購買Visual Paradigm正版授權的朋友可以。