UML由視圖(View)、圖(Diagram)、模型元素(Model Element)和通用機制(General Mechanism)等幾個部分組成。
a) 視圖(View)： 是表達系統的某一方面的特徵的UML建模元素的子集，由多個圖構成，是在某一個抽象層上，對系統的抽象表示。
b) 圖(Diagram)： 是模型元素集的圖形表示，通常是由弧（關係）和頂點（其他模型元素）相互連接構成的。
c) 模型元素(Model Element)：代表面向對象中的類、對象、消息和關係等概念，是構成圖的最基本的常用概念。
d) 通用機制(General Mechanism)：用於表示其他信息，比如註釋、模型元素的語義等。另外，UML還提供擴展機制，使UML語言能夠適應一個特殊的方法（或過程），或擴充至一個組織或用戶。
2. UML視圖的分類
UML是用來描述模型的，用模型來描述系統的機構或靜態特徵，以及行爲或動態特徵。從不同的視角爲系統構架建模，形成系統的不同視圖。
(1) 用例視圖(Use Case View)，強調從用戶的角度看到的或需要的系統功能，是被稱爲參與者的外部用戶所能觀察到的系統功能的模型圖。
(2) 邏輯視圖(Logical View)，展現系統的靜態或結構組成及特徵，也稱爲結構模型視圖(Structural Model View)或靜態視圖(Static View)。
(3) 併發視圖(Concurrent View)，體現了系統的動態或行爲特徵，也稱爲行爲模型視圖(Behavioral Model View)或動態視圖(Dynamic View)。
(4) 組件視圖(Component View)，體現了系統實現的結構和行爲特徵，也稱爲實現模型視圖(Implementation Model View)。
(5) 配置視圖(Deployment View)，體現了系統實現環境的結構和行爲特徵，也稱爲環境模型視圖(Environment Model View)或物理視圖(Physical View)。
視圖是由圖組成的，UML提供9種不同的圖：
(1) 用例圖(Use Case Diagram)，描述系統功能；
(2) 類圖(Class Diagram)，描述系統的靜態結構；
(3) 對象圖(Object Diagram)，描述系統在某個時刻的靜態結構；
(4) 組件圖(Component Diagram)，描述了實現系統的元素的組織；
(5) 配置圖(Deployment Diagram)，描述了環境元素的配置，並把實現系統的元素映射到配置上；
(6) 狀態圖(State Diagram)，描述了系統元素的狀態條件和響應；
(7) 時序圖(Sequence Diagram)，按時間順序描述系統元素間的交互；
(8) 協作圖(Collaboration Diagram)，按照時間和空間順序描述系統元素間的交互和它們之間的關係；
(9) 活動圖(Activity Diagram)，描述了系統元素的活動；
建模方法由建模語言和建模過程兩部分構成。其中建模語言是用來表述設計方法的表示法，建模過程是對設計中所應採取的步驟的描述。UML是一種建模語言，它在很大程度上獨立於建模過程。在實際建模中，建模人員最好把UML用於以用案驅動的、以體系機構爲中心的、迭代的和漸增式的開發過程中。
一般而言，軟件系統的體系結構給出了軟件系統的組織、組成系統的構造元素及其接口的選擇、系統的行爲和體系結構風格等信息。也就是說，它不僅關心繫統的結構和行爲等功能性需求，而且也涉及系統的性能、易理解性、易複用性等非功能性需求。如下圖所示，UML利用用戶模型視圖、結構模型視圖、行爲模型視圖、實現模型視圖和環境模型視圖來描述軟件系統的體系結構。
根據它們在不同架構視圖的應用，可以把9種圖分成：
(2) 結構模型視圖：類圖和對象；
(3) 行爲模型視圖：狀態圖、時序圖、協作圖和活動圖（動態圖）；
(4) 實現模型視圖：組件圖；
(5) 環境模型視圖：配置圖。
用戶模型視圖由專門描述最終用戶、分析人員和測試人員看到的系統行爲的用案組成，它實際上是從用戶角度來描述系統應該具有的功能。用戶模型視圖所描述的系統功能依靠外部用戶或者另外一個系統來激活，爲用戶或者另一系統提供服務，從而實現用戶或另一系統與系統的交互。系統實現的最終目標是提供用戶模型視圖中所描述的功能。在UML中，用戶模型視圖是由用案圖組成。
結構模型視圖描述組成系統的類、對象以及它們之間的關係等靜態結構，用來支持系統的功能需求，即描述系統內部功能是如何設計的。結構模型視圖由類圖和對象圖構成，主要供設計人員和開發人員使用。
行爲模型視圖主要用來描述形成系統併發與同步機制的線程和進程，其關注的重點是系統的性能、易伸縮性和系統的吞吐量等非功能性需求。行爲模型視圖利用併發來描述資源的高效使用、並行執行和處理異步事件。除了講系統劃分爲併發執行的控制線程之外，行爲模型還必須處理通信和這些線程及進程之間的同步問題。行爲模型視圖主要供系統開發人員和系統集成人員使用，它由序列圖、協作圖、狀態圖和活動圖組成。
實現模型視圖用來描述系統的實現模塊它們之間的依賴關係以及資源分配情況。這種視圖主要用於系統的配置管理，它是由一些獨立的構件組成的。實現模型視圖由構件圖組成。其中構件是代碼模塊，不同類型的代碼模塊形成不同的構件。實現模型視圖主要供開發人員使用。
環境模型視圖用來描述物理系統的硬件拓撲結構。例如，系統中的計算機和設備的分佈情況以及它們之間的連接方式，其中計算機和設備統稱爲節點。在UML中環境模型視圖是由部署圖來表示的。系統部署圖描述了系統構件在節點上的分佈情況，即用來描述軟件構件到物理節點的映射。部署圖主要供開發人員、系統集成人員和測試人員使用。
上面每一種視圖反映了系統的一個特定方面，不同人員可以單獨的使用其中每一種視圖，從而可以關注特定的體系結構問題。但在通常情況下，由於系統的最終目標是提供用戶模型視圖中描述的功能以及其它一些非功能性需求，因此，用戶模型視圖是其它視圖的核心基礎，其它視圖的構造都依賴與用戶模型視圖中所描述的類容。
細心的讀者已經發現，每一種UML圖都是由多個圖組成的，每一種圖都是體系結構某個側面的表示，各種圖實際上是一致的，所有的圖在一起組成了系統的完整視圖。如下圖所示，UML中總共提供了用案圖、類圖、對象圖、序列圖、協作圖、狀態圖、活動圖、構建圖和部署圖9種圖。根據它們描述的是系統的靜態結構還是動態行爲，可以將它們分爲靜態圖和動態圖兩類。再進一步介紹這9中UML圖時，先了解下什麼是模型元素：
3. UML的建模機制
UML有兩套建模機制：靜態建模機制和動態建模機制。靜態建模機制包括用例圖、類圖、對象圖、包、組件圖和配置圖。動態建模機制包括狀態圖、時序圖、協作圖、活動圖。
(1) 用例圖：用例的可視化工具，它提供計算機系統的高層次的用戶視圖，表示以外部活動者的角度來看系統將是怎樣使用的。
用例圖（用案圖）是用於描述一組用案，參與者以及它們之間的連接關係。一個用案圖描述了一組動作序列，每一個序列表示系統的外部設施（系統的參與者）與系統本身的交互。從一個特定參與者的角度看，一個用案完成對其有價值的工作。如圖2.5所示，用案圖僅僅是從參與者使用系統的角度來描述系統中的信息，即站在系統外部查看系統應該具有什麼功能，而並不描述該功能在軟件內部是如何實現的。用案可以應用於整個系統，也可以應用於系統的一個部分，包括子系統、單個的類或者接口。通常，用案不僅代表這些元素所期望的行爲，而且還可以把這些元素用作開發過程中測試用案的基礎。
用例圖包括以下3方面內容：
(a) 用例(Use Case)
(b) 參與者(Actor)
(c) 依賴、泛化和關聯關係
用例圖示例：
(2) 類圖：描述類、接口、協作以及它們之間關係的圖。
類圖是用於描述一組類、接口、協作以及它們之間的靜態關係。在面向對象系統的建模中，類圖是最爲常用的圖，它用來闡明系統的靜態結構。事實上類是對一組具有相同屬性、操作、關係和語義的對象的描述，其中對類的屬性和操作進行描述時的一個最重要的細節就是它的可見性。
類可以以多種形式連接，例如關聯、泛化、依賴和實現等。一個典型的系統中通常有若干個類圖。一個類圖不一定要包含系統中所有的類，一個類可以加到幾個類圖中。
類圖示例：
(3) 對象圖：表示在某一時間上一組對象以及它們之間的關係的圖。對象圖可以被看做是類圖在系統某一時刻的實例。
對象圖是類圖的實例，用來描述特定運行時刻一組對象之間的關係。也就是說，對象用於描述交互的靜態部分，它由參與協作的有關對象組成。但不包括在對象之間傳遞的任何消息。
在創建對象圖時，建模人員並不需要用單個的對象圖來描述系統中的每一個對象。事實上，絕大多數系統中都會包含成百上千的對象。用對象來描述系統的所有對象以及它們之間的關係一般是不太現實的。因此，建模人員可以選擇所感興趣的對象極其之間的關係來描述。
對象圖中所使用的符號和類圖中使用的符號幾乎完全相同，區別僅在於對象圖的對象名帶有下劃線，而且類與類之間關係的所有的實例都要畫出來。
(4) 組件圖：描述軟件組件以及組件之間的關係，組件本身是代碼的物理模塊，組件圖則顯示了代碼的結構。
組件圖（構件圖）是用於描述一組構件之間的組織和依賴關係，用於建模系統的靜態實現視圖。構件可以是可執行程序集、庫、表、文件和文檔等，它包含了邏輯類或者邏輯類的實現信息，因此結構模型視圖和實現模型視圖之間存在映射關係。
構建圖中也可以包括包或子系統，它們都是用於將模型元素組成較大的組塊。
組件圖例圖：
(5) 配置圖：描述系統硬件的物理拓撲結構以及在此結構上執行的軟件。配置圖可以顯示計算節點的拓撲結構和通信路徑、結點上運行的軟件組件、軟件組件包含的邏輯單元（對象、類）等。配置圖常常用於幫助理解分佈式系統。
配置圖（部署圖）用來描述系統運行是進行處理的節點以及在節點上活動的構件的配置。部署圖用來對系統的環境模型視圖進行建模。在大多數情況下，部署圖用來描述系統硬件的擴普結構。
在UML中，建模人員可以用類圖來描述系統的靜態結構，可以用序列圖、協作圖、狀態圖、活動圖來描述系統的動態行爲，而用部署圖來描述軟件所執行所需的處理器和設備的拓撲結構。
(6) 狀態圖：通過類對象的生命週期建立模型來描述對象隨時間變化的動態行爲。
狀態圖實際上是一種由狀態、變遷、事件和活動組成的狀態機。狀態圖描述從狀態到狀態的控制流，常用於系統的動態特性建模。在大多數情況下，它用來對反應型對象的行爲建模。
在UML中，狀態圖可以用來對一個對象按事件排序的行爲建模。一個狀態圖是強調從狀態到狀態的控制流的狀態機的簡單表示。一般而言，狀態圖是對類所描述的設施的補充說明，它描述了類的所有對象可能具有的狀態以及引起狀態變化的事件。
(7) 時序圖：交互圖描述了一個交互，它由一組對象和它們之間的關係組成，並且還包括在對象間傳遞的信息。交互圖表達對象之間的交互，是描述一組對象如何協作完成某個行爲的模型化工具。
序列圖和協作圖統稱爲交互圖。其中，序列圖用來描述對象之間消息發送的先後次序，闡明對象之間的交互過程以及在系統執行過程中的某一具體時刻將會發生什麼事件。序列圖是一種強調時間順序的交互圖，其中對象沿橫軸方向排列，消息沿縱軸方向排列。
序列圖中的對象生命線是一條垂直的虛線，它表示一個對象在一段時間內存在。由於序列圖中大多數對象都存在於整個交互過程中，因此這些對象全部排列在圖的頂部，它們的生命線從圖的頂部畫到圖的底部。每個對象的下方有一個矩形條，它與對象的生命線重疊，它表示該對象的控制焦點。序列圖中的消息可以有序號，但由於這種圖上的消息已經從縱軸上按時間順序排序，因此消息序號通常予以省略。
(8) 協作圖：包含類元角色和關聯角色，而不僅僅是類元和關聯。協作圖強調參加交互的各對象的組織。協作圖只對相互間有交互作用的對象和這些對象間的關係建模，而忽略了其他對象和關聯。協作圖也是一種交互圖，它強調收發消息的對象的組織結構。
協作圖和序列圖是協作的，它們可以互相轉換。在多數情況下，協作圖主要對單調的、順序的控制流建模，但它也可以用來對包括迭代和分支在內的複雜控制流進行建模。
一般而言，建模人員可以創建多個協作圖，其中一些是主要的，另外一些是可選擇的路徑或者異常條件。建模人員可以用包來組織這些協作圖，並給每個圖起一個合適的名字，以便與其它圖區別開。
(9) 活動圖：用於展現參與行爲的類的活動或動作。
活動圖是狀態圖的一種特殊情況，其中幾乎所有或大多數狀態都處於活動狀態，而且幾乎所有或者大多數變遷都是由源狀態中活動的完成觸發的。活動圖本質上是一種流程圖，它描述了從活動到活動的控制流。
可以把活動圖看作是新樣的交互圖，但交互圖觀察的是傳遞消息的對象，而活動圖觀察到的是對象之間傳送的消息。儘管兩者在語義上的區別很細微，但它們使用不同的方式來看系統的。
![Product-seq[6]](http://images.cnitblog.com/blog/151517/201308/30164856-109d189e6a2a4b179fe75af8949825ae.png)
