RUP4+1架構方法

　　RUP4+1架構方法采用用例驅動，在軟件生命周期的各個階段對軟件進行建模,從不同視角對系統(tǒng)進行解讀，從而形成統(tǒng)一軟件過程架構描述.

圖 1. RUP4+1架構圖

　　用例視圖（Use Cases View）,最初稱為場景視圖,關注最終用戶需求,為整個技術架構的上線文環(huán)境.通常用UML用例圖和活動圖描述。

　　邏輯視圖（Logical view），主要整個系統(tǒng)的抽象結構表述主要關注系統(tǒng)提供最終用戶的功能，不涉及具體的編譯即輸出和部署,通常在UML中用類圖,交互圖,時序圖來表述,類似與我們采用OOA的對象模型。

　　開發(fā)視圖(Development View), 描述軟件在開發(fā)環(huán)境下的靜態(tài)組織，從程序實現(xiàn)人員的角度透視系統(tǒng),也叫做實現(xiàn)視圖(implementation view).開發(fā)視圖關注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類庫，以及開發(fā)的系統(tǒng)將運行于其上的系統(tǒng)軟件或中間件, 在UML中用組件圖,包圖來表述. 開發(fā)視圖和邏輯視圖之間可能存在一定的映射關系：比如邏輯層一般會映射到多個程序包等。

　　處理視圖（Process view）處理視圖關注系統(tǒng)動態(tài)運行時,主要是進程以及相關的并發(fā)、同步、通信等問題。處理視圖和開發(fā)視圖的關系：開發(fā)視圖一般偏重程序包在編譯時期的靜態(tài)依賴關系，而這些程序運行起來之后會表現(xiàn)為對象、線程、進程，處理視圖比較關注的正是這些運行時單元的交互問題,在UML中通常用活動圖表述。

　　物理視圖（Physical view ）物理視圖通常也叫做部署視圖(deployment view),是從系統(tǒng)工程師解讀系統(tǒng)，關注軟件的物流拓撲結，以及如何部署機器和網絡來配合軟件系統(tǒng)的可靠性、可伸縮性等要求。物理視圖和處理視圖的關系：處理視圖特別關注目標程序的動態(tài)執(zhí)行情況，而物理視圖重視目標程序的靜態(tài)位置問題；物理視圖是綜合考慮軟件系統(tǒng)和整個IT系統(tǒng)相互影響的架構視圖。

　　RUP4+1架構方法從1995年提出后在業(yè)界獲得廣泛應用，并得以發(fā)展完善,在具體應用的時候結合公司環(huán)境和項目實際進行適當裁剪。

　　微軟VSTS2010 UML增強

　　Visual Studio 2010絕對不是單一的一個IDE環(huán)境, 將應用程序開發(fā)生命周期的方方面面與 Team Foundation Server 集成, VS2010提供了相對完備的UML開發(fā)軟件設計模型功能。目前VS2010支持新建UML模型如下包：  

　　而且微軟提供了VS2010旗艦版的可視化建模功能包，加強UML建模能力和便捷性。

　　實現(xiàn)RUP4+1架構案例背景說明

　　IDM是一家家電制造商,目前企業(yè)已經有ERP系統(tǒng),外部系統(tǒng)可以通過JDBC訪問該系統(tǒng)授權的數據,同時該公司的有電子郵件系統(tǒng)也提供SMTP方式讓外部程序調用。該公司計劃開發(fā)一個電子化采購系統(tǒng)(EPS),基本需求如下：

IDM生產計劃在ERP設定后，會自動產生原料請購記錄到EPS，EPS自動產生采購要求(Request For Purchase;RFP),并利用短信系統(tǒng)已經電子郵件通知注冊的供應商。

　　供應商收到通知后必須先到IDM的EPS中在采購要求規(guī)定的時間內提供報價單

　　IDM的采購人員(Buyer)通過EPS比價策略進行供應商選擇產兩家供應商并生采購單,同時通過短信和郵件通知該兩家供應商。

　　供應商收到短信后,若要確認供貨，到EPS中確認采購單,EPS通過電子郵件通知該采購負責人(Buyer)

　　采購人員在EPS中確認該采購后，EPS回傳該訂單到IDM的ERP系統(tǒng)中和該兩家供應商。

　　用例視圖

　　根據需求初步描述，抽象出該采購系統(tǒng)涉及的角色有IDM的EPR系統(tǒng)，采購人員(Buyer)，供應商涉及用例有產生采購需求,確定供應商,報價等。步驟如下:

　　1.打開VS2010,新建項目，選擇建模項目,并合理命名和解決方案位置，點擊確定。

　　2．添加新項，選擇添加新項目，選擇UML用例圖并命名，點擊確定下一步

　　3.從工具箱中拖入如圖各個用例和角色，并命名

　　4.按Crtl+S保存，在迭代開發(fā)過程中做到這一步和用戶進一步溝通,發(fā)現(xiàn)IDM公司已經有通知系統(tǒng)平臺可以調用發(fā)送短信和郵件通知,同時,采購人員分為采購經理和普通職員,采購確認由采購經理完成。用例圖進一步調整如下：

　　5．圖例說明：在系統(tǒng)中,用例送貨位于系統(tǒng)邊界外,不作為系統(tǒng)開發(fā)范圍，其存在為了更好的解釋系統(tǒng)的流程的完整行, 參與者不一定是人，ERP和通知系統(tǒng)作為參與者存在，另外比價作為單獨用例存在意義不大，細心的讀者可能會問 “產生原料請購記錄”怎么沒有作為系統(tǒng)用例存在？分析下可知，“產生原料請購記錄“是ERP功能，EPS承擔轉化 “請購記錄”到“采購請求”功能，因此沒有作為EPS用例出現(xiàn)。 更多的關于用例分析請參考《Think in UML大象》

NET技術：VS2010實踐RUP4+1架構模型，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。