2.概要設計階段

如果細分為總體設計、概要設計、詳細設計，這裡的概要設計包括總體設計+概要設計。與需求分析只討論業務需求分析類似，本文的設計階段也只考慮針對業務需求的設計，不考慮網路等整合架構方面的設計。

概要設計階段一般首先確定要用的技術架構（系統技術架構同時包含了系統模組的劃分以及模組間的關係)、系統模組部署、對外介面等關鍵資訊，然後會根據需求文件的User Case與Sequence圖 將業務流程細化到系統層面，此時應該包括在系統內的模組間怎麼流轉。技術架構一般用框圖就夠了，而系統模組部署可以使用Deployment圖，對外介面可以使用Component圖，細化的業務流程仍然是Sequence圖.

2.1 Deployment圖

部署圖用於靜態建模，是表示執行時過程節點結構、構件例項及其物件結構的圖。
如果含有依賴關係的構件例項放置在不同節點上，部署檢視可以展示出執行過程中的瓶頸。

部署圖的兩種表現形式：例項層部署圖和描述層部署圖

例項層部署圖描述各節點和它們之間的連線。如果每個節點都是一臺主機，那麼這種圖可以邏輯的表達主機之間的通訊關係（此時不考慮物理的網路架構，不考慮中間的防火牆、交換機、路由器）：

描述層部署圖表示了系統中的各節點、每個節點包含的構件、對外提供的介面、對外的依賴關係：

圖中包括的各種關係如下：

通訊鏈關係(不帶箭頭的直線):TicketServer票伺服器與Kiosk資訊廳之間存在一對多的通訊關聯；與SalesTerminal售票終端也存在一對多的通訊關聯；依賴關係(帶箭頭的虛線):TicketSeller售票構件依賴CreditCardCharges信用卡付款構件和TicketDB票資料庫構件提供的服務。

圖中顧客購票的情景如下(下面的描述是需要拿Sequence圖和部署圖結合著看的）：

顧客通過位於Kiosk節點的顧客介面控制元件進行購票的操作，該顧客介面構件的購票操作依賴於處於TicketServer節點上的售票構件提供的服務，售票構件要完成售票操作，又要依賴統一節點上信用卡付款構件提供的付款服務和票資料庫構件

2.2 Component圖

構件圖用於靜態建模，是表示構件型別的組織以及各種構件之間依賴關係的圖。

構件圖通過對構件間依賴關係的描述來估計對系統構件的修改給系統可能帶來的影響。

可替換的物理部分包括軟體程式碼、指令碼或命令列檔案，也可以表示執行時的物件，文件，資料庫等(這句話表明component的粒度

可粗可細，運用之妙，在乎一心)。

部署圖與構件圖的關係：

  部署圖表現構件例項；

  構件圖表現構件型別的定義。

  部署圖偏向於描述構件在節點中執行時的狀態，描述了構件執行的環境；

  構件圖偏向於描述構件之間相互依賴支援的基本關係。

我們可以看到他們不體現部署圖的”部署“特性，因為節點消失了，然而有了更多的介面細節。

那麼我們是先有部署圖後有構件圖，還是先有構件圖，後有部署圖？本文的思路是top down，所以是從部署圖到構件圖，實際上也應該如此，因為我們在需求確定後，一般就會確定大體的技術架構、程式模組劃分。而此時一般系統整合的工作也要相應的啟動：要買主機、網路裝置，所以要提供給系統整合人員相應的資料，那麼就需要先把部署圖做出來，然後再細化構件圖。

2.3 Sequence圖

2.4 State Machine圖(狀態圖或者狀態機圖)

有些較為複雜的、需要重點說明的，且有actor參與的流程（在sequence圖中可能只是一條線)，可以使用state Machine圖再詳見闡述。

狀態圖：說明物件在它的生命期中響應事件所經歷的狀態序列，以及它們對那些事件的響應。狀態圖用於揭示Actor、類、子系統和元件的複雜特性。

如下是個網上銀行登入系統的例子：

登陸要求提交個人社會保險號(SSN)和密碼(PIN)經驗證有效後登陸成功。

2.5 Activity圖(活動圖)

活動圖比狀態機圖好玩的地方在於有”泳道圖“，泳道圖可以在展現邏輯執行過程的同時展現出每個活動的負責者，所以實際上比狀態機圖用起來更受客戶的歡迎。

活動圖可以方便的表述多執行緒、多程序：

一般的活動圖：

帶泳道的活動圖：

2.6 關於Communication圖

Communication圖是Sequence圖的另外一種表示形式，主要作用是顯示某個元件/物件是否有過多的互動，是否應該繼續分拆。Rational的RUP可以直接根據Sequence圖生成通訊圖（也叫協作圖），所以我把他單做是一個輔助的形式。