RUP4+1架構方法
RUP4+1架構方法採用用例驅動，在軟件生命週期的各個階段對軟件進行建模,從不同視角對系統進行解讀，從而形成統一軟件過程架構描述.
圖 1. RUP4+1架構圖
用例視圖（Use Cases View）,最初稱爲場景視圖,關注最終用戶需求,爲整個技術架構的上線文環境.通常用UML用例圖和活動圖描述。
邏輯視圖（Logical view），主要是整個系統的抽象結構表述，關注系統提供最終用戶的功能，不涉及具體的編譯即輸出和部署,通常在UML中用類圖,交互圖,時序圖來表述,類似與我們採用OOA的對象模型。
開發視圖(Development View), 描述軟件在開發環境下的靜態組織，從程序實現人員的角度透視系統,也叫做實現視圖(implementation view).開發視圖關注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現成框架、類庫，以及開發的系統將運行於其上的系統軟件或中間件, 在UML中用組件圖,包圖來表述. 開發視圖和邏輯視圖之間可能存在一定的映射關係：比如邏輯層一般會映射到多個程序包等。
處理視圖（Process view）處理視圖關注系統動態運行時,主要是進程以及相關的併發、同步、通信等問題。處理視圖和開發視圖的關係：開發視圖一般偏重程序包在編譯時期的靜態依賴關係，而這些程序運行起來之後會表現爲對象、線程、進程，處理視圖比較關注的正是這些運行時單元的交互問題,在UML中通常用活動圖表述。
物理視圖（Physical view ）物理視圖通常也叫做部署視圖(deployment view),是從系統工程師解讀系統，關注軟件的物流拓撲結，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性等要求。物理視圖和處理視圖的關係：處理視圖特別關注目標程序的動態執行情況，而物理視圖重視目標程序的靜態位置問題；物理視圖是綜合考慮軟件系統和整個IT系統相互影響的架構視圖。
RUP4+1架構方法從1995年提出後在業界獲得廣泛應用，並得以發展完善,在具體應用的時候結合公司環境和項目實際進行適當裁剪。
微軟VSTS2010 UML增強
Visual Studio 2010絕對不是單一的一個IDE環境, 將應用程序開發生命週期的方方面面與 Team Foundation Server 集成, VS2010提供了相對完備的UML開發軟件設計模型功能。目前VS2010支持新建UML模型如下包：
|
UML關係圖 |
主要作用 |
|
活動圖 |
業務流程中的操作和參與者之間的工作流 |
|
組件圖 |
系統的組件、組件的接口、端口和關係 |
|
類圖 |
用於在系統中存儲和交換數據的類型及其關係 |
|
序列圖 |
對象、組件、系統或參與者之間的交互序列 |
|
用例圖 |
系統支持的用戶目標和任務 |
而且微軟提供了VS2010旗艦版的可視化建模功能包，加強UML建模能力和便捷性。
實現RUP4+1架構
案例背景說明
IDM是一家家電製造商,目前企業已經有ERP系統,外部系統可以通過JDBC訪問該系統授權的數據,同時該公司的有電子郵件系統也提供SMTP方式讓外部程序調用。該公司計劃開發一個電子化採購系統(EPS),基本需求如下：
l IDM生產計劃在ERP設定後，會自動產生原料請購記錄到EPS，EPS自動產生採購要求(Request For Purchase;RFP),並利用短信系統已經電子郵件通知註冊的供應商。
l 供應商收到通知後必須先到IDM的EPS中在採購要求規定的時間內提供報價單
l IDM的採購人員(Buyer)通過EPS比價策略進行供應商選擇產兩家供應商並生採購單,同時通過短信和郵件通知該兩家供應商。
l 供應商收到短信後,若要確認供貨，到EPS中確認採購單,EPS通過電子郵件通知該採購負責人(Buyer)
l 採購人員在EPS中確認該採購後，EPS回傳該訂單到IDM的ERP系統中和該兩家供應商。
用例視圖
根據需求初步描述，抽象出該採購系統涉及的角色有IDM的EPR系統，採購人員(Buyer)，供應商涉及用例有產生採購需求,確定供應商,報價等。步驟如下:
1.打開VS2010,新建項目，選擇建模項目,併合理命名和解決方案位置，點擊確定。
2．添加新項，選擇添加新項目，選擇UML用例圖並命名，點擊確定下一步
3.從工具箱中拖入如圖各個用例和角色，並命名
4.按Crtl+S保存，在迭代開發過程中做到這一步和用戶進一步溝通,發現IDM公司已經有通知系統平臺可以調用發送短信和郵件通知,同時,採購人員分爲採購經理和普通職員,採購確認由採購經理完成。用例圖進一步調整如下：
5．圖例說明：在系統中,用例送貨位於系統邊界外,不作爲系統開發範圍，其存在爲了更好的解釋系統的流程的完整行, 參與者不一定是人，ERP和通知系統作爲參與者存在，另外比價作爲單獨用例存在意義不大，細心的讀者可能會問 “產生原料請購記錄”怎麼沒有作爲系統用例存在？分析下可知，“產生原料請購記錄“是ERP功能，EPS承擔轉化 “請購記錄”到“採購請求”功能，因此沒有作爲EPS用例出現。 更多的關於用例分析請參考《Think in UML大象》
<待續>
參考：
Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.
用例描述
用例實現規約
根據需求初步描述，我們給出來EPS的系統用例圖.如果業務流程過於複雜，並且涉及不同的角色,可以採用帶有泳道的活動圖去表達.
目前VS2010還不支持帶有泳道的活動圖，如何要展示更精確的用例細節，必須使用用例規約來進行描述。基本上用例圖+用例規約足夠用了。
一般用例規約敘述要包含以簡要說明，用例的正常流,替代事件流，業務規則，涉及實體等,用戶在使用的時候可以參考RUP文檔模型模板，請切記，您的目的是要闡明問題，而不是混淆問題。
|
用例名稱 |
產生採購請求 |
|
用例描述 |
系統根據ERP原材料請求記錄產生請購單 |
|
執行者 |
ERP |
|
前置條件 |
1.ERP系統被EPS授權訪問 |
|
後置條件 |
1. 創建新的採購請求單並生成唯一編號 2. 觸發通知系統給合格供應商發送採購需求 |
|
正常流 |
1. ERP提供[物料採購計劃]給系統 2. 系統根據業務規則1 生成[採購請求單] 3. 系統根據業務規則 2 產生[推薦詢價廠商名單] 4. 系統觸發通知系統按照[推薦詢價廠商名單]發送[物料請購需求] |
|
替代流以及異常處理 |
2a.系統找不到該物料的[詢價廠商] 1.系統標示該物料爲[缺料] |
|
業務規則 |
1. 對於每個物料找出所有該物料的供應商並且其交易評級爲”A”,如果符合條件的供應商小於<2,找出所有交易評級爲”B”且供應該物料的供應商。 2. 編號規則 以 “RPF”開頭加上年月日+遞增序號：RPF2010120900000002 |
|
涉及實體 |
1. 物料採購計劃 物料編號，期望採購月份,數量,底標價格 2. 採購請求單 採購請求單號,物流採購計劃單號 3. 物流請購需求單 物料編號，廠商物料編號，預計採購月份，預計採購數量 4. 推薦詢價廠商 物料編號，廠商，聯繫人，電話
|
表1產生採購請求用例實現規約
注意：我們在一直強調迭代開發，在用例規約描述中, 替代事件流以及異常處理遠遠多於正常事件流,因此我們這個規約是個逐步完善的過程,早期千萬不要窮盡分析他們而忽視了正常流這一系統主要因素。
用例實現集成到VS2010
下面我們把用例規約文檔集成到VS2010，並建立和相應的用例聯繫。
1. 用Word用例規約描述,可以把所有的用例規約放在一個Word文檔，也可以分類別各自描述，這樣在我們實施Scrum開發時候方便任務分配。參考表1.
2. 打開我們上一節保存的項目方案,選擇添加現有項目,把你的用例規約Word文檔添加到項目中來。
3. 選擇添加新建用例圖項目命名爲EPSUsecaseDescribe，這個圖我們主要是描述用例和用例實現規約對應關係
4. 從項目解決方案中拖入word文檔到EPSUsecaseDescribe工作區。
5. 打開UML資源管理器，拖入相關用例並建立聯繫。
6. Ctrl+S保存。
我們說過，RUP4+1是基於用例驅動實現架構視圖，而VSTS2010實現了軟件全生命週期管理，如果我們基於Scrum開發,我們的用例可以方便轉化爲我們Product Backlog,我們這裏做的用例規約很容易轉化爲我們的測試Task，而且他們的關係可以方便通過VSTS進行管理。
UML模型資源管理器
隨着我們項目越來越大,項目的Item越來越多，從可讀性和可維護性的角度，我們要整理下我們項目了。
UML資源管理器方便我們對UML資源進行管理，既然我們是基於Rup4+1模型進行架構，那麼我們可以UML資源管理器的設置如下：
1. 打開UML資源管理器，右擊添加包，並從新命名爲Scenarios
2. 依次添加如下包，結構如下：
3. 在UML資源瀏覽器中以此把Actor和用例拖入相應的包。
4. 打開解決方案瀏覽器窗口，整理我們解決方案文件夾。
小技巧
微軟支持項目模板重用功能，你可以參考：http://msdn.microsoft.com/zh-cn/library/dd393742(en-us).aspx
《待續》
參考：
Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.
《UML與Enterprise Architect 團隊開發實用手冊》
轉自：http://www.cnblogs.com/Leo_wl/archive/2010/12/09/1901715.html