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

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

點擊下載Visual Paradigm最新試用版

數(shù)據(jù)流圖（DFD）提供了系統(tǒng)內(nèi)信息（即數(shù)據(jù)）流的直觀表示。通過繪制數(shù)據(jù)流程圖，您可以了解參與系統(tǒng)流程的人員所提供和傳遞的信息，完成流程所需的信息以及需要存儲和訪問的信息。本文以證券交易平臺為例，介紹和解釋數(shù)據(jù)流圖（DFD）。

證券交易平臺示例

上下文DFD

下圖顯示了為證券交易平臺繪制的上下文數(shù)據(jù)流程圖。它包含一個過程（形狀），代表要建模的系統(tǒng)，在本例中為“ 證券交易平臺 ”。它還顯示了將與系統(tǒng)交互的參與者，稱為外部實體。在此示例中，CS Assistant，客戶和經(jīng)紀人是將與系統(tǒng)進行交互的實體。在流程與外部實體之間，存在數(shù)據(jù)流（連接器），這些數(shù)據(jù)流指示實體與系統(tǒng)之間存在信息交換。

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

1級DFD

下圖顯示了1級DFD，它是上下文DFD中所示的證券交易平臺流程的分解（即分解）。通讀該圖，然后我們將基于此圖介紹一些關鍵概念。

證券交易平臺數(shù)據(jù)流程圖示例包含五個流程，三個外部實體和三個數(shù)據(jù)存儲。盡管沒有設計指南可以控制形狀在數(shù)據(jù)流程圖中的位置，但是我們傾向于將過程放在中間，而將數(shù)據(jù)存儲和側(cè)面的外部實體放在一邊，以便于理解。

根據(jù)該圖，我們知道客戶服務助理會向“ 開設帳戶”流程提供客戶詳細信息。結(jié)果是將客戶詳細信息存儲在客戶數(shù)據(jù)存儲中，將帳戶詳細信息存儲在帳戶數(shù)據(jù)存儲中。盡管我們說過嘗試在客戶服務助理提供詳細信息后進行存儲客戶和帳戶詳細信息的嘗試，但是數(shù)據(jù)流程圖并不意味著這種情況。我們的常識使我們以自然理解圖表的方式來解釋它。嚴格來說，該圖僅告訴我們“ 開設帳戶”流程收到的信息客戶詳細信息，并生成客戶和帳戶詳細信息，但未指定訂單。請注意，數(shù)據(jù)流圖不會以什么方式和順序來回答整個系統(tǒng)中使用的信息。如果此信息很重要且值得一提，請考慮使用諸如BPMN業(yè)務流程圖或UML活動圖之類的圖對其進行建模。

流程Check Transaction從交易數(shù)據(jù)存儲中接收交易詳細信息，并將其傳遞給客戶。

一個客戶可存入現(xiàn)金通過提供存款金額，結(jié)果是更新的帳戶余額存儲在客戶數(shù)據(jù)存儲。

同樣，客戶可以提取現(xiàn)金。結(jié)果是他將收到提款金額，并且更新的帳戶余額將存儲在帳戶數(shù)據(jù)存儲區(qū)中。

最后，客戶和經(jīng)紀人都可以啟動下訂單過程，這導致交易明細存儲在交易數(shù)據(jù)存儲中。下訂單處理還將交易詳細信息傳遞到證券交易所中心，該中心是系統(tǒng)范圍之外的實體。在下一節(jié)中，我們將介紹一種表示這種實體的方法。

2級DFD

就像上下文DFD中的流程一樣，級別1 DFD中的流程也可以分解為更深層次的流程，甚至可以分解成更多層次的流程詳細信息。下圖顯示了下訂單流程的2級DFD 。

該DFD中的外部實體和數(shù)據(jù)存儲與上層所示的外部實體和數(shù)據(jù)存儲相對應（即，上圖）。與眾不同的是，將下達訂單流程細分為下達訂單（在線）流程和下達訂單（離線）流程。

根據(jù)此圖表，我們知道，客戶可以進行下訂單（在線）通過提供訂購詳細而經(jīng)紀人可以進行下訂單（電話）通過提供也令細節(jié) ; 在兩種情況下，都將交易細節(jié)存儲在交易數(shù)據(jù)存儲中并傳遞到證券交易中心。

使用構(gòu)造型為“特殊類型”實體建模

刻板印象和標記值是對象管理組（OMG）引入的一種可擴展性機制。它允許設計人員擴展UML的詞匯表，以創(chuàng)建新的模型元素。作為一種軟件設計工具，Visual Paradigm將對原型的支持擴展到非UML標準，例如DFD和ERD。以證券交易平臺為例，我們可以為外部實體定義構(gòu)造型“第三方”。具有指定原型的外部實體被稱為“一種第三方實體”。

注意細節(jié)級別

在此數(shù)據(jù)流程圖示例中，標記數(shù)據(jù)時，多次使用“細節(jié)”一詞。我們有“客戶詳細信息”，“交易詳細信息”等。如果我們將其明確寫為“客戶名稱，電子郵件地址，工作，地址”和“庫存數(shù)量，金額，投標價格”怎么辦？這個對嗎？好吧，這個問題沒有確定的答案，但是在做出決定時嘗試問自己一個問題。為什么要繪制DFD？

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

不要透支

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

不要混淆數(shù)據(jù)流和流程流

有些設計人員看到連接器從數(shù)據(jù)存儲連接到流程時可能會感到不舒服，而看不到圖中以某種方式顯示數(shù)據(jù)請求的步驟。其中一些會嘗試通過在流程和數(shù)據(jù)存儲之間添加連接器來表示請求，將其標記為“請求”或“對某物的請求”，這是錯誤的。

請記住，數(shù)據(jù)流程圖是為表示信息交換而設計的。數(shù)據(jù)流程圖中的連接器用于表示數(shù)據(jù)，而不用于表示流程，步驟或其他任何內(nèi)容。當我們將以數(shù)據(jù)存儲結(jié)尾的數(shù)據(jù)流標記為“請求”時，從字面上看，這意味著我們正在將請求作為數(shù)據(jù)傳遞到數(shù)據(jù)存儲中。盡管在實現(xiàn)級別可能是這種情況，因為某些DBMS確實支持使用函數(shù)，這些函數(shù)會吸收一些值作為參數(shù)并返回結(jié)果，但是在數(shù)據(jù)流程圖中，我們傾向于將數(shù)據(jù)存儲視為唯一的數(shù)據(jù)存儲，而不是具有任何處理能力。如果要對系統(tǒng)流或流程進行建模，請改用UML活動圖或BPMN業(yè)務流程圖。如果要對數(shù)據(jù)存儲的內(nèi)部結(jié)構(gòu)建模，請使用實體關系圖。

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

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

想要購買Visual Paradigm正版授權(quán)的朋友可以。