Visual Studio 2010項(xiàng)目實(shí)例講解RUP4+1架構(gòu)方法
RUP4+1架構(gòu)方法
RUP4+1架構(gòu)方法采用用例驅(qū)動(dòng)，在軟件生命周期的各個(gè)階段對(duì)軟件進(jìn)行建模,從不同視角對(duì)系統(tǒng)進(jìn)行解讀，從而形成統(tǒng)一軟件過程架構(gòu)描述.
圖 1. RUP4+1架構(gòu)圖
用例視圖（Use Cases View）,最初稱為場景視圖,關(guān)注最終用戶需求,為整個(gè)技術(shù)架構(gòu)的上線文環(huán)境.通常用UML用例圖和活動(dòng)圖描述。
邏輯視圖（Logical view），主要整個(gè)系統(tǒng)的抽象結(jié)構(gòu)表述主要關(guān)注系統(tǒng)提供最終用戶的功能，不涉及具體的編譯即輸出和部署,通常在UML中用類圖,交互圖,時(shí)序圖來表述,類似與我們采用OOA的對(duì)象模型。
開發(fā)視圖(Development View), 描述軟件在開發(fā)環(huán)境下的靜態(tài)組織，從程序?qū)崿F(xiàn)人員的角度透視系統(tǒng),也叫做實(shí)現(xiàn)視圖(implementation view).開發(fā)視圖關(guān)注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類庫，以及開發(fā)的系統(tǒng)將運(yùn)行于其上的系統(tǒng)軟件或中間件, 在UML中用組件圖,包圖來表述. 開發(fā)視圖和邏輯視圖之間可能存在一定的映射關(guān)系：比如邏輯層一般會(huì)映射到多個(gè)程序包等。
處理視圖（Process view）處理視圖關(guān)注系統(tǒng)動(dòng)態(tài)運(yùn)行時(shí),主要是進(jìn)程以及相關(guān)的并發(fā)、同步、通信等問題。處理視圖和開發(fā)視圖的關(guān)系：開發(fā)視圖一般偏重程序包在編譯時(shí)期的靜態(tài)依賴關(guān)系，而這些程序運(yùn)行起來之后會(huì)表現(xiàn)為對(duì)象、線程、進(jìn)程，處理視圖比較關(guān)注的正是這些運(yùn)行時(shí)單元的交互問題,在UML中通常用活動(dòng)圖表述。
物理視圖（Physical view ）物理視圖通常也叫做部署視圖(deployment view),是從系統(tǒng)工程師解讀系統(tǒng)，關(guān)注軟件的物流拓?fù)浣Y(jié)，以及如何部署機(jī)器和網(wǎng)絡(luò)來配合軟件系統(tǒng)的可靠性、可伸縮性等要求。物理視圖和處理視圖的關(guān)系：處理視圖特別關(guān)注目標(biāo)程序的動(dòng)態(tài)執(zhí)行情況，而物理視圖重視目標(biāo)程序的靜態(tài)位置問題；物理視圖是綜合考慮軟件系統(tǒng)和整個(gè)IT系統(tǒng)相互影響的架構(gòu)視圖。
RUP4+1架構(gòu)方法從1995年提出后在業(yè)界獲得廣泛應(yīng)用，并得以發(fā)展完善,在具體應(yīng)用的時(shí)候結(jié)合公司環(huán)境和項(xiàng)目實(shí)際進(jìn)行適當(dāng)裁剪。
微軟VSTS2010 UML增強(qiáng)
Visual Studio 2010絕對(duì)不是單一的一個(gè)IDE環(huán)境, 將應(yīng)用程序開發(fā)生命周期的方方面面與 Team Foundation Server 集成, VS2010提供了相對(duì)完備的UML開發(fā)軟件設(shè)計(jì)模型功能。目前VS2010支持新建UML模型如下包：
|
UML關(guān)系圖 |
主要作用 |
|
活動(dòng)圖 |
業(yè)務(wù)流程中的操作和參與者之間的工作流 |
|
組件圖 |
系統(tǒng)的組件、組件的接口、端口和關(guān)系 |
|
類圖 |
用于在系統(tǒng)中存儲(chǔ)和交換數(shù)據(jù)的類型及其關(guān)系 |
|
序列圖 |
對(duì)象、組件、系統(tǒng)或參與者之間的交互序列 |
|
用例圖 |
系統(tǒng)支持的用戶目標(biāo)和任務(wù) |
而且微軟提供了VS2010旗艦版的可視化建模功能包，加強(qiáng)UML建模能力和便捷性。
實(shí)現(xiàn)RUP4+1架構(gòu)案例背景說明
IDM是一家家電制造商,目前企業(yè)已經(jīng)有ERP系統(tǒng),外部系統(tǒng)可以通過JDBC訪問該系統(tǒng)授權(quán)的數(shù)據(jù),同時(shí)該公司的有電子郵件系統(tǒng)也提供SMTP方式讓外部程序調(diào)用。該公司計(jì)劃開發(fā)一個(gè)電子化采購系統(tǒng)(EPS),基本需求如下：
IDM生產(chǎn)計(jì)劃在ERP設(shè)定后，會(huì)自動(dòng)產(chǎn)生原料請(qǐng)購記錄到EPS，EPS自動(dòng)產(chǎn)生采購要求(Request For Purchase;RFP),并利用短信系統(tǒng)已經(jīng)電子郵件通知注冊(cè)的供應(yīng)商。
供應(yīng)商收到通知后必須先到IDM的EPS中在采購要求規(guī)定的時(shí)間內(nèi)提供報(bào)價(jià)單
IDM的采購人員(Buyer)通過EPS比價(jià)策略進(jìn)行供應(yīng)商選擇產(chǎn)兩家供應(yīng)商并生采購單,同時(shí)通過短信和郵件通知該兩家供應(yīng)商。
供應(yīng)商收到短信后,若要確認(rèn)供貨，到EPS中確認(rèn)采購單,EPS通過電子郵件通知該采購負(fù)責(zé)人(Buyer)
采購人員在EPS中確認(rèn)該采購后，EPS回傳該訂單到IDM的ERP系統(tǒng)中和該兩家供應(yīng)商。
用例視圖
根據(jù)需求初步描述，抽象出該采購系統(tǒng)涉及的角色有IDM的EPR系統(tǒng)，采購人員(Buyer)，供應(yīng)商涉及用例有產(chǎn)生采購需求,確定供應(yīng)商,報(bào)價(jià)等。步驟如下:
1.打開VS2010,新建項(xiàng)目，選擇建模項(xiàng)目,并合理命名和解決方案位置，點(diǎn)擊確定。
2．添加新項(xiàng)，選擇添加新項(xiàng)目，選擇UML用例圖并命名，點(diǎn)擊確定下一步
3.從工具箱中拖入如圖各個(gè)用例和角色，并命名
4.按Crtl+S保存，在迭代開發(fā)過程中做到這一步和用戶進(jìn)一步溝通,發(fā)現(xiàn)IDM公司已經(jīng)有通知系統(tǒng)平臺(tái)可以調(diào)用發(fā)送短信和郵件通知,同時(shí),采購人員分為采購經(jīng)理和普通職員,采購確認(rèn)由采購經(jīng)理完成。用例圖進(jìn)一步調(diào)整如下：
5．圖例說明：在系統(tǒng)中,用例送貨位于系統(tǒng)邊界外,不作為系統(tǒng)開發(fā)范圍，其存在為了更好的解釋系統(tǒng)的流程的完整行, 參與者不一定是人，ERP和通知系統(tǒng)作為參與者存在，另外比價(jià)作為單獨(dú)用例存在意義不大，細(xì)心的讀者可能會(huì)問 “產(chǎn)生原料請(qǐng)購記錄”怎么沒有作為系統(tǒng)用例存在？分析下可知，“產(chǎn)生原料請(qǐng)購記錄“是ERP功能，EPS承擔(dān)轉(zhuǎn)化 “請(qǐng)購記錄”到“采購請(qǐng)求”功能，因此沒有作為EPS用例出現(xiàn)。 更多的關(guān)于用例分析請(qǐng)參考《Think in UML大象》
原文鏈接：http://www.cnblogs.com/Roping/archive/2010/12/08/1900251.html
【編輯推薦】
