一、UML介紹
UML（統一建模語言）是當前軟件開發中使用最爲廣泛的建模技術之一
UML中的視圖包括用例視圖（Use Case View）、邏輯視圖（Logical View）、實現視圖（Implementation View）、進程視圖（Process View）、部署視圖（Deployment View），這5個視圖被稱作”4+1”視圖。
每一個視圖只關心繫統的一個側面，5個試圖結合在一起才能反映系統的軟件體系結構的全部內容。
每個視圖需要用一組圖（diagram）來描述，圖中包含的是代表系統模型元素的各種圖形符號，不同的圖體現出着系統的不同的方面。正如我們觀察一個物體一樣，從不同的角度看到的局部圖像可能會出現重疊，不同的視圖之間也可能出現重疊的狀況，所以同一個圖可以從屬於不同的視圖。
二、用例圖
用例圖Use case diagrams描述了作爲一個外部的觀察者的視角對系統的印象。強調這個系統是什麼而不是這個系統怎麼工作。
用例圖與情節緊緊相關的。情節scenario是指當某個人與系統進行互動時發生的情況。下面是一個醫院門診部的情節。
“一個病人打電話給門診部預約一年一次的身體檢查。接待員找出在預約記錄本上找出最近的沒有預約過的時間，並記上那個時間的預約記錄。”
用例Use case是爲了完成一個工作或者達到一個目的的一系列情節的總和。角色actor是發動與這個工作有關的事件的人或者事情。角色簡單的扮演着人或者對象的作用。下面的圖是一個門診部Make Appointment用例。角色是病人。角色與用例的聯繫是通訊聯繫communication association（或簡稱通訊communication）
角色是人狀的圖標，用例是一個橢圓，通訊是連接角色和用例的線。
一個用例圖是角色，用例，和它們之間的聯繫的集合。我們已經把Make Appointment作爲一個含有四個角色和四個用例的圖的一部分。注意一個單獨的用例可以有多個角色。
用例圖在三個領域很有作用：
- 決定特徵（需求）。當系統已經分析好並且設計成型時，新的用例產生新的需求 客戶通訊。
- 使用用例圖很容易表示開發者與客戶之間的聯繫。
- 產生測試用例。一個用例的情節可能產生這些情節的一批測試用例。
三、類圖
類圖Class diagram通過顯示出系統的類以及這些類之間的關係來表示系統。類圖是靜態的－它們顯示出什麼可以產生影響但不會告訴你什麼時候產生影響。
下面是一個顧客從零售商處預定商品的模型的類圖。中心的類是Order。連接它的是購買貨物的Customer和Payment。Payment有三種形式：Cash，Check，或者Credit。訂單包括OrderDetails（line item），每個這種類都連着Item。
UML類的符號是一個被劃分成三塊的方框：類名，屬性，和操作。抽象類的名字，像Payment是斜體的。類之間的關係是連接線。
類圖有三種關係。
- 關聯association－表示兩種類的實例間的關係。如果一個類的實例必須要用另一個類的實例才能完成工作時就要用關聯。在圖中，關聯用兩個類之間的連線表示。
- 聚合aggregation－當一個類屬於一個容器是的一種特殊關係。聚合用一個帶菱形的連線，菱形指向具有整體性質的類。在我們的圖裏，Order是OrderDetails的容器。
- 泛化generalization－一個指向以其他類作爲超類的繼承連線。泛化關係用一個三角形指向超類。Payment是Cash，Check和Credit的超類。
一個關聯有兩個尾端。每個尾端可以有一個角色名role name來說明關聯的作用。比如，一個OrderDetail實例是一個Order實例的項目。
關聯上的方向性navigability箭頭表示該關聯傳遞或查詢的方向。OrderDetail類可以查詢他的Item，但不可以反過來查詢。箭頭方向同樣可以告訴你哪個類擁有這個關聯的實現；也就是，OrderDetail擁有Item。沒有方向性的箭頭的關聯是雙向。
關聯尾端的數字表示該關聯另一邊的一個實例可以對應的數字端的實例的格數，通過這種方式表達關聯的多樣性multiplicity。多樣性的數字可以是一個 單獨的數字或者是一個數字的範圍。在例子中，每個Order只有一個Customer，但一個Customer可以有任意多個Order。
下面這個表給出了最普遍的多樣性示例。
多樣性 意義
0..1 0或1個實例. n..m符號表示有n到m個實例
0..* or * 沒有實例格數的限制（包括沒有）.
1 只有一個實例
1..* 最少一個實例
每個類圖包括類，關聯和多樣性表示。方向性和角色是爲了使圖示得更清楚時可選的項目。
四、包和對象圖
爲了簡單地表示出複雜的類圖，可以把類組合成包packages。一個包是UML上有邏輯關係的元件的集合。一般用於展示高層次的觀點。
下面這個圖是是一個把類組合成包的一個商業模型。
dependencies關係。如果另一個的包B改變可能會導致一個包A改變，則包A依賴包B。包是用一個在上方帶有小標籤的矩形表示的。包名寫在標籤上或者在矩形裏面。點化線箭頭表示依賴。
對象圖Object diagrams用來表示類的實例。他們在解釋複雜關係的細小問題時（特別是遞歸關係時）很有用。
這個類圖示一個大學的Department可以包括其他很多的Departments。
下面的對象圖表示上面類圖的實例。（大學：統計學，數學。UML中實例名帶有下劃線。只要意思清楚，類或實例名可以在對象圖中被省略。）
每個類圖的矩形對應了一個單獨的實例。實例名稱中所強調的UML圖表。類或實例的名稱可能是省略對象圖表只要圖的意義仍然是明確的。
五、 組合結構圖
描述系統中某一部分（組合部分）的內部結構，包括該部分與系統其它部分的交互點。
（借書內部結構）
六、組件圖
描述在系統實現環境中的軟件構件和它們之間的關係。
七、部署圖
描述系統所需的硬件構件的物理部署。
八、活動圖
活動圖主要目的是陳述活動與活動之間流程控制的轉移。一般用於描述企業的本質性工作流程（Essential Workflow）。
活動是沒有複用性的，爲了能夠清晰易懂地描述整個流程，爲了避免一張圖裏包含太多信息，可以對其進行拆分。活動圖是描述用例場景最常用的圖，因爲它可以最方便地描述角色職責（每一個泳道對應一個角色）。
應用：
業務場景建模：以業務主角（客戶代表）爲泳道，以從業務主角處獲取的業務用例爲活動來編排活動圖。有助於發現及檢查業務用例
用例場景建模：以業務主角和業務工人爲泳道，以工作單元作爲活動來編排活動圖以描述用例場景。有助於獲取概念用例、角色、業務對象，建立領域模型。
領域模型：
對業務有着重要意義的業務對象。如果在同一個或多個用例場景的不同活動中某個名稱重複出現，那麼它很可能是一個關鍵的業務對象，這個業務對象在不同活動中的狀態以及它與活動圖中其他名詞間的關係很可能就決定了業務的結構。繪製出這個結構就能獲得領域模型。
（對象交互泳道圖）
（帶角色職責的活動圖）
九、狀態圖
狀態圖顯示一個狀態機。用於對模型元素的動態行爲進行建模，具體地說就是對系統行爲中受事件驅動的方面進行建模。可以說明業務主角和業務實體可能的狀態。狀態圖可以簡化對類的設計的確認。
我們可以用狀態機描述業務實體對象、分析類對象和設計類對象。通常只用於描述單個對象的行爲，如果要描述對象間的交互，最好採用時序圖或協作圖。
關鍵元素：
初始狀態（起始位置，不需要事件的觸發）、狀態（entry/do/event/exit四個特定事件）、複合狀態、轉移、事件、條件、最終狀態。
（圖書生命週期狀態圖）
十、時序圖
時序圖用於描述按時間順序排列的對象之間的交互模式，它按照參與交互的對象所具有的“生命線”和它們相互發送的消息來顯示這些對象。在時序圖中包含對象和主角實例，以及說明它們如何交互的消息。
時序圖對我們確定對象職責和接口有着顯著的作用。
因爲類有三個層次：概念層、說明層、實現層。分別對應三個建模階段，相應的時序圖也有3個層次。
- 業務模型時序圖：採用業務實體來繪製，其目標是實現業務用例。一般是先通過活動圖發現業務實體，然後再繪製業務實體時序圖。
- 概念模型時序圖：採用分析類來繪製，目標是實現業務用例。但因爲分析類本身代表了系統原型，這個階段的時序圖已經帶有了計算機理解。
- 設計模型時序圖：使用設計類爲對象繪製，目標是顯示概念模型中的某個事件流，一般以一個完整交互爲單位，消息細緻到方法級別。一般用於描述典型的交互場景。
（網上購買商品業務模型時序圖）
（購買商品概念模型時序圖片斷）
（登錄和查詢事件流設計模型時序圖片斷）
十一、協作圖
時序圖強調消息事件的發生順序，更方便於闡述事件流的過程，適於獲得對調用過程的理解，而難以表達表達對象之間的關係。而協作圖可以直觀地展現對象間的關係，更適於獲得對對象結構的理解。二者是可以互相轉換的。
（網上購買商品業務模型協作圖）
（購買商品概念模型協作圖片斷）
（登錄和查詢事件流設計模型協作圖片斷）
