Visual Paradigm教程:數(shù)據(jù)流程圖示例-客戶服務(wù)系統(tǒng)
Visual Paradigm是包含設(shè)計共享、線框圖和數(shù)據(jù)庫設(shè)計新特性的企業(yè)項目設(shè)計工具。Visual Paradigm公司在其核心產(chǎn)品Visual Paradigm for UML更新到v11.1的時候,把三個原始的系列產(chǎn)品(Agilian、Visual Paradigm for UML和Logizian)融合在一起,將最初為不同建模功能服務(wù)的多個獨立產(chǎn)品整合成的一個產(chǎn)品,其名字被命名為Visual Paradigm——與公司的名字相同。現(xiàn)在你只需要這樣單獨的一款模型軟件 Visual Paradigm就可以完成用UML設(shè)計軟件,用BPMN去執(zhí)行業(yè)務(wù)流程分析,用ERD企業(yè)設(shè)計數(shù)據(jù)庫的任務(wù)。
Visual Paradigm現(xiàn)已更新至最新版本16.0,新版本引入了大型Scrum畫布和幾十種新的圖案,同時還增強了在線圖表功能和支持從Customer Journey Map打開完整圖表編輯器的功能。新版本,新功能,趕快下載體驗吧!(Visual Paradigm現(xiàn)已加入在線訂購,現(xiàn)在搶購立享優(yōu)惠!)
帶有示例的數(shù)據(jù)流程圖-客戶服務(wù)系統(tǒng)
數(shù)據(jù)流圖(DFD)提供了系統(tǒng)內(nèi)信息(即數(shù)據(jù))流的直觀表示。通過創(chuàng)建數(shù)據(jù)流程圖,您可以告訴參與系統(tǒng)流程的人員所提供并傳遞給其的信息,完成流程所需的信息以及需要存儲和訪問的信息。數(shù)據(jù)流程圖在軟件工程中被廣泛使用。您可以在建模信息系統(tǒng)中使用DFD。本文以客戶服務(wù)系統(tǒng)為例介紹和解釋數(shù)據(jù)流程圖(DFD)。
推薦閱讀:
CS系統(tǒng)示例
數(shù)據(jù)流程圖是圖的層次結(jié)構(gòu),包括:
1、上下文圖(概念上為零級)
2、1級DFD
3、以及可能的2級DFD和進一步的功能分解級別,具體取決于系統(tǒng)的復(fù)雜性
上下文DFD
下圖顯示了為鐵路公司的客戶服務(wù)系統(tǒng)繪制的上下文數(shù)據(jù)流程圖。它包含一個過程(形狀),代表要建模的系統(tǒng),在本例中為“ CS系統(tǒng) ”。它還顯示了將與系統(tǒng)交互的參與者,稱為外部實體。在此示例中,CS Assistant和Passenger是將與系統(tǒng)交互的兩個實體。在流程與外部實體之間,存在數(shù)據(jù)流(連接器),這些數(shù)據(jù)流指示實體與系統(tǒng)之間存在信息交換。
上下文DFD是數(shù)據(jù)流模型的入口。它僅包含一個進程,并且不顯示任何數(shù)據(jù)存儲。
1級DFD
下圖顯示了1級DFD,它是上下文DFD中顯示的CS系統(tǒng)過程的分解(即分解)。通讀該圖,然后我們將基于此圖介紹一些
CS系統(tǒng)數(shù)據(jù)流程圖示例包含四個流程,兩個外部實體和四個數(shù)據(jù)存儲。盡管沒有設(shè)計指南可以控制形狀在數(shù)據(jù)流程圖中的位置,但是我們傾向于將過程放在中間,而將數(shù)據(jù)存儲和側(cè)面的外部實體放在一邊,以便于理解。
根據(jù)該圖,我們知道乘客可以從“ 查詢運輸明細”流程中接收運輸明細,并且該明細由數(shù)據(jù)存儲“ 運輸明細”和“ 鐵路實時統(tǒng)計”提供。雖然存儲在“ 運輸詳細信息”中的數(shù)據(jù)是持久性數(shù)據(jù)(用標簽“ D”表示),但是“ 鐵路實時統(tǒng)計”中存儲的數(shù)據(jù)是短暫的瞬態(tài)數(shù)據(jù)(用標簽“ T”表示)。標注形狀用于列出乘客可以查詢的詳細信息的種類。
CS Assistant可以啟動“ 購買紀念品”流程,這將導(dǎo)致將訂單詳細信息存儲在“ 訂單”數(shù)據(jù)存儲區(qū)中。盡管客戶是購買紀念品的真實人,但是由CS助手訪問系統(tǒng)來存儲訂單詳細信息。因此,我們使數(shù)據(jù)從CS助手流向購買紀念品流程。
CS Assistant還可以通過提供訂單明細來啟動“ 購買憑單”流程,該明細將再次存儲在“ 訂單”數(shù)據(jù)存儲區(qū)中。數(shù)據(jù)流圖是一個高度抽象的高級圖。此處繪制的數(shù)據(jù)存儲Order不一定表示真實的訂單數(shù)據(jù)庫或數(shù)據(jù)庫中的訂單表。訂單詳細信息的物理存儲方式將在以后實現(xiàn)系統(tǒng)時確定。
最后,CS Assistant可以通過提供事件和項目詳細信息來啟動“ 報告丟失”過程,并且該信息將存儲在“ 丟失的項目”數(shù)據(jù)庫中。
數(shù)據(jù)流程圖提示和注意事項
用D,M和T聲明數(shù)據(jù)類型
在數(shù)據(jù)流程圖中繪制的每個數(shù)據(jù)存儲都以字母為前綴,默認情況下為“ D”。該字母表示數(shù)據(jù)存儲區(qū)保存的數(shù)據(jù)類型。字母“ D”用于表示持久的計算機化數(shù)據(jù),這可能是典型信息系統(tǒng)中最常見的數(shù)據(jù)類型。除了計算機化數(shù)據(jù)外,數(shù)據(jù)還可以暫時保留一小段時間。我們稱這種數(shù)據(jù)為暫態(tài)數(shù)據(jù),用字母“ T”表示。有時,無需使用計算機即可存儲數(shù)據(jù)。我們稱這種數(shù)據(jù)為手動數(shù)據(jù),用字母“ M”表示。最后,如果數(shù)據(jù)是在不使用計算機的情況下存儲的,并且也保留了很短的時間,則稱為手動瞬態(tài)數(shù)據(jù),并用T(M)表示。
注意細節(jié)級別
在此數(shù)據(jù)流程圖示例中,標記數(shù)據(jù)時,多次使用“細節(jié)”一詞。我們有“運輸詳細信息”和“訂單詳細信息”。如果我們將其明確寫為“路線信息,火車時間和延誤”,“紀念品名稱,數(shù)量和數(shù)量”以及“機票類型和數(shù)量”怎么辦?這個對嗎?好吧,這個問題沒有確定的答案,但是在做出決定時嘗試問自己一個問題。為什么要繪制DFD?
在大多數(shù)情況下,數(shù)據(jù)流程圖是在系統(tǒng)開發(fā)的早期階段繪制的,其中許多細節(jié)尚待確認。諸如“詳細信息”,“信息”,“憑證”之類的通用術(shù)語的使用無疑為討論留下了空間。但是,使用通用術(shù)語可能會缺少細節(jié),從而使設(shè)計失去用處。因此,這實際上取決于您設(shè)計的目的。
不要透支
在數(shù)據(jù)流程圖中,我們專注于系統(tǒng)與外部各方之間的交互,而不是接口之間的內(nèi)部通信。因此,接口與所使用的數(shù)據(jù)存儲之間的數(shù)據(jù)流被認為是超出范圍的,因此不應(yīng)在圖中顯示。
不要混淆數(shù)據(jù)流和流程流
一些設(shè)計人員在遇到從數(shù)據(jù)存儲區(qū)到流程的連接器時可能會感到不舒服,而沒有在圖表上指定數(shù)據(jù)請求的步驟。一些設(shè)計人員將嘗試將附加到連接器的請求放置在流程和數(shù)據(jù)存儲之間,將其標記為“請求”或“對某物的請求”,這肯定是不必要的。
請記住,數(shù)據(jù)流程圖是為表示信息交換而設(shè)計的。數(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)流或流程進行建模,則可以使用“ 活動圖”或“ BPMN業(yè)務(wù)流程圖”代替。如果要對數(shù)據(jù)存儲的內(nèi)部結(jié)構(gòu)建模,可以使用Entity Relationship Diagram。
=====================================================
更多Visual Paradigm相關(guān)資源,請點擊此處進行查看~
想要購買Visual Paradigm正版授權(quán)的朋友可以。