轉自： https://www.cnblogs.com/wj033/p/5861709.html
1、UML
http://www.umlchina.com/index.htm
統一建模語言（UML）始於1997年的一個OMG（對象管理組織）標準，它是一種圖形化、可視化的語言，爲軟件開發的所有階段提供模型化和可視化支持，包括由需求分析到規格，到構造和配置。
UML是一種建模語言，而不是一個開發過程。
UML統一了各種方法對不同類型的系統、不同開發階段以及不同內部概念的不同觀點，從而有效的消除了各種建模語言之間不必要的差異。它實際上是一種通用的建模語言。
UML的目標是以面向對象圖的方式來描述任何類型的系統，具有很寬的應用領域。其中最常用的是建立軟件系統的模型，但它同樣可以用於描述非軟件領域的系統，如機械系統、企業機構或業務過程，以及處理複雜數據的信息系統、具有實時要求的工業系統或工業過程等。總之，UML是一個通用的標準建模語言，可以對任何具有靜態結構和動態行爲的系統進行建模。
2、 視圖（View）
UML中的視圖包括用例視圖（Use Case View）、邏輯視圖（Logical View）、實現視圖（Implementation View）、進程視圖（Process View）、部署視圖（Deployment View），這5個視圖被稱作”4+1”視圖。
每一個視圖只關心繫統的一個側面，5個試圖結合在一起才能反映系統的軟件體系結構的全部內容。
4+1視圖方法告訴我們【通過哪些視角、每個視角關注什麼】，以此指導架構設計實踐。
2.1、 用例視圖（Use-Case View）
從角色的視角來展示系統的功能。角色與系統進行交互，它可以是一個用戶，也可以是另外一個系統。用例是對系統功能需求的概括描述，系統的使用被描述爲用例視圖中的多個用例。用例視圖常常通過用例圖進行描述，有時也需要活動圖的輔助。用例視圖在系統建模中處於中心地位，是其他視圖的驅動因素。用例視圖在系統需求分析時起着重要的作用，系統開發的最終目標就是要與用例視圖中的描述相一致。
1. 問題系統是用例的集合，一般含有10~50個用例。
2. 需求 = 功能 + 質量 + 約束
用例是功能性需求實際上的標準，用例涉及、但不涵蓋非功能性需求。
2.2、 邏輯視圖（Logical View）
用系統的靜態結構和動態行爲來展示系統內部的功能是如何實現的，其側重點在於如何得到功能，這就要求邏輯視圖能夠剖析和展示系統的內部。系統的靜態結構通過類圖和對象圖，而動態行爲使用交互圖和活動圖進行描述。
邏輯視圖指導邏輯架構設計，邏輯架構關注功能，不僅包括用戶可見的功能，還包括爲實現用戶功能而必須提供的“輔助功能模塊”；它們可能是邏輯層、功能模塊、類等。
2.3、 實現視圖（Implementation View）
展示代碼的組織和執行，描述系統的主要功能模塊和個模塊之間的關係，主要被開發人員使用。
實現視圖指導開發架構設計，開發架構關注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現成框架、類庫，以及開發的系統將運行於其上的系統軟件或中間件。開發架構和邏輯架構之間可能存在一定的映射關係：比如邏輯架構中的邏輯層一般會映射到開發架構中的多個程序包；再比如開發架構中的源碼文件可以包含邏輯架構中的一到多個類。
2.4、 進程視圖（Process View）
捕捉設計的併發和同步特徵。展示與系統處理性能相關的主要元素，包括可伸縮性、吞吐量、基本時間性能。過程視圖將系統劃分爲進程和處理器，通過這種方式來分析和設計系統如何有效利用資源、並行執行、處理來自外界的異步事件，除了要將系統劃分爲併發運行的線程以外，還要處理線程的通信和同步。進程視圖包括動態圖（狀態機、交互圖、活動圖）和實現圖（交互圖和部署圖）
進程視圖指導運行架構設計，運行架構關注進程、線程、對象等運行時概念，以及相關的併發、同步、通信等問題。運行架構和開發架構的關係：開發架構一般偏重程序包在編譯時期的靜態依賴關係，而這些程序運行起來之後會表現爲對象、線程、進程，運行架構比較關注的是這些運行時單元的交互問題。
2.5、 部署視圖（Deployment View）
利用節點來展示系統部署的物理架構。節點可以是電腦或者設備，將這些節點相互連接起來就可以分析和展示在物理架構中系統是如何部署的。
部署視圖指導物理架構設計，物理架構關注“目標程序及其依賴的運行庫和系統軟件”最終如何安裝或部署到物理機器，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性等要求。物理架構和運行架構的關係：運行架構特別關注目標程序的動態執行情況，而物理架構重視目標程序的靜態位置問題；物理架構還要考慮軟件系統和包括硬件在內的整個IT系統之間是如何相互影響的。
——————————————————
有了視圖，我們可以每次把注意力集中在系統的一個方面，通過對多個視圖的理解，我們在大腦中把不同方面的信息拼接起來，最終把握系統的全貌。
每個視圖需要用一組圖（diagram）來描述，圖中包含的是代表系統模型元素的各種圖形符號，不同的圖體現出着系統的不同的方面。正如我們觀察一個物體一樣，從不同的角度看到的局部圖像可能會出現重疊，不同的視圖之間也可能出現重疊的狀況，所以同一個圖可以從屬於不同的視圖。
3、 圖（diagram）
3.1、 （13種圖）
3.2、 靜態視圖
用例圖
採用參與者和用例作爲基本元素，以不同的視角展現系統的功能性需求。
業務用例視圖
用業務主角和業務用例展現業務建模的結果。可能會有不同視角的版本。
（業務主角視角） （業務視角）
業務用例實現視圖
展現業務用例有哪些實現途徑。
概念用例視圖
展現從業務用例中經過分析，分解出來的關鍵概念用例，並表示概念用例和業務用例之間的關係。這些關係一般有擴展、包含、精化。
系統用例視圖
展現系統範圍，將對業務用例進行分析得到的系統用例展現出來。一般系統用例視圖以業務用例爲單位來展現。表達了從系統需求到業務需求的映射，保證了過程的可追溯性。
系統用例實現視圖
如果一個系統用例有多種實現方法，則應繪製實現視圖。
類圖
展現系統中類及其相互關係
概念層類圖
着重對問題領域的概念化理解，類名通常是問題領域中實際事物的名稱。對應業務建模階段，用業務實體圖表示。
（寄信）
說明層類圖
對問題領域在接口層次抽象的描述，是現實世界與最終實現間的一座橋樑。對應概念模型階段，用分析類和分析類型圖表示。
實現層類圖
明確採用的語言，設計模式，通信標準，遵循的規範等。直接映射可執行代碼。可視爲僞代碼，甚至可以用工具直接生成可執行代碼。
包圖
一般用於展示高層次的觀點。
（領域包圖）
（子系統包圖）
（組織結構包圖）
（層次包圖）
對象圖
組合結構圖
（借書內部結構）
（ATM）
組件圖
部署圖
3.3、 動態視圖
動態視圖無法獨立存在，必須特指一個靜態視圖或UML元素，說明在規定的事物結構下它們的動態行爲。
活動圖
關鍵元素：
起始點、結束點、活動（entry/do/event/exit四個特定事件）、分支、分叉、會合、基本流、支流、異常流、組合活動。
泳道： 由上述元素構建的活動圖中描述了業務流程中活動的執行順序，卻沒有描述出由誰來執行這些活動，即執行業務流程的職責被遺漏了。在面向過程的分析觀點裏，重要的是業務的執行過程，但在面向對象的分析觀點中，業務的執行過程不是最重要的，對象職責才重要。因此在面向對象分析和設計中繪製活動圖一定要添加泳道。
組合活動：
活動圖主要目的是陳述活動與活動之間流程控制的轉移。一般用於描述企業的本質性工作流程（Essential Workflow）。
活動是沒有複用性的 爲了能夠清晰易懂地描述整個流程，爲了避免一張圖裏包含太多信息，可以對其進行拆分。
活動圖是描述用例場景最常用的圖，因爲它可以最方便地描述角色職責（每一個泳道對應一個角色）。
應用：
- 業務場景建模：以業務主角（客戶代表）爲泳道，以從業務主角處獲取的業務用例爲活動來編排活動圖。有助於發現及檢查業務用例
- 用例場景建模：以業務主角和業務工人爲泳道，以工作單元作爲活動來編排活動圖以描述用例場景。有助於獲取概念用例、角色、業務對象，建立領域模型。
領域模型：
對業務有着重要意義的業務對象。如果在同一個或多個用例場景的不同活動中某個名稱重複出現，那麼它很可能是一個關鍵的業務對象，這個業務對象在不同活動中的狀態以及它與活動圖中其他名詞間的關係很可能就決定了業務的結構。繪製出這個結構就能獲得領域模型。
活動圖示例：
（對象交互泳道圖）
（帶角色職責的活動圖）
狀態圖
狀態圖顯示一個狀態機。用於對模型元素的動態行爲進行建模，具體地說就是對系統行爲中受事件驅動的方面進行建模。可以說明業務主角和業務實體可能的狀態。狀態圖可以簡化對類的設計的確認。
我們可以用狀態機描述業務實體對象、分析類對象和設計類對象。通常只用於描述單個對象的行爲，如果要描述對象間的交互，最好採用時序圖或協作圖。
關鍵元素：
初始狀態（起始位置，不需要事件的觸發）、狀態（entry/do/event/exit四個特定事件）、複合狀態、轉移、事件、條件、最終狀態。
（圖書生命週期狀態圖）
活動圖與狀態圖的比較
1. 活動和狀態圖標的版型很像，但還是不一樣的
2. 活動圖裏一般有泳道
3. 活動圖中活動間的 連線 表示流程控制權的轉移，線上不會有文字；而狀態圖衆狀態間的 連線 表示引起狀態改變的事件，每一條線上都有事件名稱。
4. 活動圖的判斷會爲每一個支流的連線上附上條件，而狀態圖的判別條件附在事件的後面[中括號中]，表示的是事件發生的條件。
5. 狀態圖裏沒有“分支”、“分叉”、“會合”這種表流程控制的元素。
時序圖
時序圖用於描述按時間順序排列的對象之間的交互模式，它按照參與交互的對象所具有的“生命線”和它們相互發送的消息來顯示這些對象。在時序圖中包含對象和主角實例，以及說明它們如何交互的消息。
時序圖對我們確定對象職責和接口有着顯著的作用。
因爲類有三個層次：概念層、說明層、實現層。分別對應三個建模階段，相應的時序圖也有3個層次。
業務模型時序圖：採用業務實體來繪製，其目標是實現業務用例。一般是先通過活動圖發現業務實體，然後再繪製業務實體時序圖。
概念模型時序圖：採用分析類來繪製，目標是實現業務用例。但因爲分析類本身代表了系統原型，這個階段的時序圖已經帶有了計算機理解。
設計模型時序圖：使用設計類爲對象繪製，目標是顯示概念模型中的某個事件流，一般以一個完整交互爲單位，消息細緻到方法級別。一般用於描述典型的交互場景。
（網上購買商品業務模型時序圖）
（購買商品概念模型時序圖片斷）
（登錄和查詢事件流設計模型時序圖片斷）
協作圖
時序圖強調消息事件的發生順序，更方便於闡述事件流的過程，適於獲得對調用過程的理解，而難以表達表達對象之間的關係。而協作圖可以直觀地展現對象間的關係，更適於獲得對對象結構的理解。二者是可以互相轉換的。
（網上購買商品業務模型協作圖）
（購買商品概念模型協作圖片斷）
（登錄和查詢事件流設計模型協作圖片斷）
交互縱覽圖
時間圖
（打電話的時序圖，帶時間約束）
（利用時間圖描述時間約束）
4、 核心元素
4.1、 版型 stereotype
UML中幾乎每一個元模型都有很多版型。例如：用例有 "業務用例"、"業務用例實現"、“用例”等版型，類有"接口"、"邊界類","實體類"、“控制類”等版型。甚至“參與者本身”也是類的一個特殊版型。而參與者又有參與者和業務主角等版型。
4.2、 模型元素
包
常見的版型：
組件
組件是系統中可更換的部件，表達軟件的一組功能。它符合一套接口標準並實現一組接口。組件之間的關係只有一種：依賴關係。
而按SOA架構的標準，一個組件應當是一個獨立的業務模塊，有着完備的功能，可獨立部署，可以看成是一個完備的服務。一個SOA服務和其他服務是沒有依賴關係的，服務與服務之間僅保持松耦合的通信關係。系統功能由一個個的服務向外部暴露。這些服務是松耦合的，它們之間通過企業總線按照標準的通信協議來交互完成業務功能。
節點
節點是至少帶有一個處理器、內存，可能還帶有其他設備的處理元素。一個服務器、工作站、客戶機都可稱爲節點。
節點是應用程序的部署單元。節點元素特別用於部署視圖，描述應用程序在屋裏結構上是如何部署到應用環境中的。是一種包括軟、硬件在內的拓撲結構描述。
參與者（actor）
信息來源提供者，第一驅動者。
對比：涉衆、業務主角、業務工人、用戶、角色。
可能存在的關係：繼承、代理、實現
- 業務主角之所以加上業務二字，是因爲業務主角確實有區別於系統參與者，後者參與構建系統用例圖，也就是通常所說用例圖。前者參與構建業務用例圖。
- 業務工人不是參與者，它是和業務主角對比理解的，業務主角位於系統邊界之外，而業務工人在系統邊界之內，相當系統中的一枚螺絲釘，參與需求的實現。
- 他們都源於涉衆（stakeholder）,涉衆是與要建設的這個系統有利益關係的一切人和事。
- 用戶是系統的直接使用者，他是參與者的代表（參與者的某個實例或者代理）。
- 角色是參與者的職責，是一個抽象概念，一個用戶可以擁有多個角色，多個用戶也可以擁有某些相同的角色。
用例（use case）
一個用例就是與參與者交互，並給參與者提供可觀測的有意義的結果的一系列活動的集合。
用例是功能性需求，也是抽象的角度。必須有參與者（動作的發起人），必需有動作的受體，必須有對參與者來說有意義可觀察的結果。
一個用例就是一個獨立的分析單元、設計單元、開發單元、測試單元、部署單元。一旦決定了用例，軟件開發工作的其他活動都以這個用例爲基礎，圍繞着它進行。也就是用例驅動開發。
- 業務用例拋開系統，真實地反映參與者在現實世界的行爲。準確而完備地描述客戶的現存或預想業務。
- 用例（系統用例）描述的是系統要實現的那部分功能。它的粒度一般會更小。
- 概念用例用於精化業務用例，使系統用例的分析更容易些。
- 用例實現是用例的一個實例，如匯款是一個用例，則線下銀行匯款和網上銀行匯款就是兩種用例實現。
業務實體
是類的一種版型，用於業務建模階段繪製類圖或建立領域模型。作爲類的版型，具有對象的所有特徵，包括屬性和方法及對象的獨立性。
業務實體至少被一個業務用例場景使用或創建，對業務用例場景沒有貢獻的事物是沒必要建模的。
分析類
分析類用於概念建模或系統建模階段
邊界類 -> 操作界面或系統接口
控制類 -> 計算程序或控制程序，如工作流、算法體等
實體類 -> 數據庫表、Xml文檔或其他帶持久化特徵的類
類、對象
用於設計實現階段，會涉及具體到程序語言。
類用帶有類名、屬性和操作的矩形框來表示。
對象是類的實例，其名字有下劃線。
接口
接口描述了一個類或組(構)件的一個服務操作集，亦即定義了元素的外部可見行爲。
接口定義的是一組操作的描述，而不是操作的實現。
在圖形上，接口用一端帶有小圓圈的直線來表示，它通常依附在實現接口的類或組(構)件之上。
註解、狀態、活動
4.3、 關係
關聯關係
描述不同類的對象之間的一種靜態的強關聯關係。用一條直線表示（A、B互相知道對方的存在），有時會帶箭頭（A知道B,B不知道A），
關聯除可以具有方向外，也可以帶有多重性標註和角色名這類修飾符。
依賴關係
描述對象之間的依賴關係。依賴關係是一種臨時的關係，通常在運行期產生。用帶箭頭的虛線表示
泛化（繼承）關係
一條帶空心箭頭的直線，表類繼承
實現關係
一條帶空心箭頭的虛線
實現是泛化關係和依賴關係的結合，通常在接口和實現它們的類或組(構)件之間用到這種關係。
用在用例模型中，表示基本用例的一種實現。
包含關係
一條帶箭頭的虛線 + 版型<<include>> ，用在概念用例模型中，表用例的分解、重用。
擴展關係
一條帶箭頭的虛線 + 版型<<extend>> ，用在概念用例模型中，表用例的功能擴展：某個支流，某個可選的系統功能。
包含(include)、擴展(extend)、泛化(Inheritance) 的區別
- extend中的延伸用例表示的是某個支流，某個可選功能。用例的發生一般是有條件的。延伸用例並不包含基礎用例的內容，基礎用例也不包含延伸用例的內容。
- include中被包含的用例爲參與者提供間接服務 ，而泛化和擴展提供直接的服務。因爲包含的目的往往是爲了分解、重用。
- 對Inheritance而言，子用例包含基礎用例的所有內容及其和其他用例或參與者之間的關係。
精化關係
一條帶箭頭的虛線 + 版型<<refine>>，表一個基本用例可以分解成許多更小的精化用例。更細緻地表示基本用例的核心業務。也可以用於模型之間或對象之間。
聚合關係
帶空心菱形箭頭的直線，聚合是一種特殊的關聯，它描述了整體和部分之間的結構關係。指明一種類型的對象是另一種類型的對象的一部分。
組合關係
帶實心菱形箭頭的直線，一種強關聯關係，它所描述的“部分”對象是依賴於“整體”對象的。組合是一種特殊的聚合關係，當整體不存在時，部分也隨之消亡。
多重性關聯
|
表示方式
|
多重性說明
|
|
1..1
|
表示另一個類的一個對象只與該類的一個對象有關係 |
|
0..*
|
表示另一個類的一個對象與該類的零個或多個對象有關係 |
|
1..*
|
表示另一個類的一個對象與該類的一個或多個對象有關係 |
|
0..1
|
表示另一個類的一個對象沒有或只與該類的一個對象有關係 |
|
m..n
|
表示另一個類的一個對象與該類最少m，最多n個對象有關係 (m≤n) |
類圖中的關係示例
5、 補充知識
5.1、 UML的體系結構
5.2、 UML的模型結構
根據UML語義，UML的模型結構可分爲四個抽象層次；下一層是上一層的基礎，上一層是下一層的實例。
元元模型示例
元元模型是組成UML的最基本事物，代表要定義的所有事物，如一些元類、元屬性、元操作等概念。
元元模型示例是一個“元類”的元元模型描述，其中事物概念可代表任何定義的東西。
概念
元模型：
元模型是關於模型的模型。這是特定領域的模型，定義概念並提供用於創建該領域中的模型的構建元素。
5.3、 UML建模規則
UML模型圖按特定的規則有機地組成。
一個完備的UML模型圖必須在語義上是一致的，並且和一切與它相關的模型和諧地組合在一起。
UML建模規則的內容
①名字：任何一個UML成員都必須包含一個名字。
②作用域：UML成員所定義的內容起作用的上下文環境。某個成員在每個實例中代表一個值，還是代表這個類元的所有實例的一個共享值，由上下文決定。
③可見性：UML成員能被其他成員引用的方式。
④完整性：UML成員間互相連接的合法性和一致性。
⑤運行屬性：UML成員在運行時的特性。
UML建模的原則
在系統的開發過程中，模型可以：
①被省略：即模型本身是完備的，但在圖上某些屬性被隱藏起來，以簡化表達；
②不完全：即在設計過程中某些元素可以暫時不存在；
③不一致：即在設計過程中暫時不保證設計的完整性。
5.4、 UML公用機制
規約
在UML中，每個模型元素的圖形表示法之後都存在一個規約(規範說明 )，它以文字的形式描述基本模型元素的語法和語義。
UML的圖形表示法可視化地描述系統，而UML的規約則用來描述系統的細節。
修飾
在圖的模型元素上添加修飾，可爲模型元素附加一定的語義。
1 . 在UML衆多的修飾符中，註釋是一種最重要的並且能單獨存在的修飾符，它是附加在模型元素或元素集上用來表示約束或註解 信息的圖形符號。
2. 類的圖形符號
- 用斜體類名錶示它是抽象類。
- 用+表示public，用-表示private,用#表示protected。
- 上圖的Member是內部類
- 屬性的表示方式 ： 可見性 名稱:類型 [ = 缺省值 ]
- 操作的表示方式： 可見性 名稱(參數列表) [ : 返回類型]
通用劃分
類/對象二分法
對象和類使用同樣的圖形符號。類用長方形表示，並用名字加以標識，當類的名字帶有下劃線時，則它代表該類的一個對象。
接口定義一種協議，實現是此協議的實施。UML裏這樣的接口與實現的兩分劃分包括接口/類或組件、用例和協同，以及操作和方法。
擴展機制
⑴衍型(構造型)：對UML的詞彙的擴展，用於創建與已有的模型元素相似且針對特定問題的新種類的模型元素。用書名號括起來的名字表示，其位置在其他元素之上。
⑵標記值：對UML元素的特性的擴展，用於在模型元素的規約中創建新的信息。用花括號括起來的字符串表示，其位置在其他元素之下。
⑶約束：對UML元素的語義的擴展，用於增加新規則或修改已有規則。用花括號括起來的字符串表示，且放在所關聯的元素附近或通過依賴關係連接相應元素。
6、 博文收集
UML實踐詳細經典教程----用例圖、順序圖、狀態圖、類圖、包圖、協作圖