模型
- 功能模型：從用戶的角度展示系統的功能，包括用例圖。
- 對象模型：采用對象，屬性，操作，關聯等概念展示系統的結構和基礎，包括類別圖、對象圖。
- 動態模型：展現系統的內部行為。包括序列圖，活動圖，狀態圖。
圖形
UML 2.2中一共定義了14種圖示（diagrams）。為方便了解，可分類成右側的結構。
結構性圖形（Structure diagrams） 強調的是系統式的建模：
- 類圖 (Class Diagram)
- 組件圖(Component diagram)
- 復合結構圖(Composite structure diagram)
- 部署圖(Deployment diagram)
- 對象圖(Object diagram)
- 包圖(Package diagram)
行為式圖形（Behavior diagrams） 強調系統模型中觸發的事件：
- 活動圖(Activity diagram)
- 狀態機圖 (State Machine diagram)
- 用例圖 (Use Case Diagram)
溝通性圖形（Interaction diagrams）, 屬於行為圖形的子集合，強調系統模型中的資料流程：
- 通信圖(Communication diagram]]
- 交互概述圖(Interaction overview diagram) (UML 2.0)
- 循序圖(Sequence diagram)
- 時間圖(UML Timing Diagram) (UML 2.0)
對於結構而言
對於行為而言
對於關系而言
順序圖
順序圖是交互圖的一種形式，它顯示對象沿生命線發展，對象之間隨時間的交互表示為從源生命線指向目標生命線的消息。順序圖能很好地顯示那些對象與其它那些對象通信，什么消息觸發了這些通信，順序圖不能很好顯示復雜過程的邏輯。
生命線
一條生命線在順序圖中代表一個獨立的參與者。表示為包含對象名的矩形，如果它的名字是"self"，則說明該生命線代表控制帶順序圖的類元。
有時，順序圖會包含一個頂端是執行者的生命線。這情況說明掌握這個順序圖的是用例。健壯圖中的邊界，控制和實體元素也可以有生命線。
消息
消息顯示為箭頭。消息可以完成傳輸，也可能丟失和找回，它可以是同步的，也可以是異步的，即可以是調用，也可以是信號。在下圖中，第一條消息是同步消息(標為實箭頭)完成傳輸，並隱含一條返回消息。第二條消息是異步消息 (標為實線箭頭)，第三條是異步返回消息(標為虛線)。
執行發生
向下延伸的細條狀矩形表示執行事件或控制焦點的激活。在上圖中有三個執行事件。第一個是源對象發送兩條消息和收到兩條回復。第二個是目標對象收到一條同步消息並返回一條回復。第三個是目標對象收到一條異步消息並返回一條回復。
內部通信
內部消息表現為一個操作的遞歸調用，或一個方法調用屬於同一個對象的其他方法。顯示為生命線上執行事件的嵌套控制焦點。
迷路消息和拾取消息
迷路消息是那些發送了卻沒有到達指定接收者，或者到達的接收者不再當前圖中。拾取消息是收到來自那些未知的發送者，或者來自沒有顯示在當前圖的發送者的消息。它們都表明是去往或來自一個終點元素。
生命線開始與結束
生命線可以在順序圖時間刻度范圍內創建和銷毀，在下面的例子中，生命線被停止符號（叉號）終止。在前面的例子中，生命線頂端的符號（Child）顯示在比創建它的對象符號（parent）沿頁面要低的位置上。下圖顯示創建和終止對象。
時間和期限約束
消息默認顯示為水平線。因為生命線顯示為沿屏幕向下的時間通道，所以當給實時系統建模，或是有時間約束的業務過程建模，考慮執行動作所需時間長度是很重要的。因此可以給消息設置一個期限約束，這樣的消息顯示為下斜線。
復合片段
如前面所說，順序圖不適合表達復雜的過程邏輯。在一種情況下，有許多機制允許把一定程度的過程邏輯加入到圖中，並把它們放到復合片段的標題下。復合片段是一個或多個處理順序被包含在一個框架中，並在指定名稱的環境下執行。 片段可以是:
- 選擇性片段 (顯示 “alt”) 為 if…then…else 結構建模。
- 選項片段 (顯示 “opt”) 為 "switch"(開關) 結構建模。
- 中斷片段對被處理事件的可選擇順序建模，而不是該圖的其他部分。
- 並行片段(顯示 “par”) 為並發處理建模。
- 弱順序片段 (顯示 “seq”) 包含了一組消息，這組消息必須在后繼片段開始之前被處理。但不會把片段內消息的先后順序強加到不共享同一條生命線的消息上。
- 嚴格順序片段 (顯示 “strict”) 包含了一系列需要按照給定順序處理的消息。
- 非片段 (顯示 “neg”) 包含了一系列不可用的消息。
- 關鍵片段 具有關鍵部分。
- 忽略片段 聲明一個沒有意義的消息，如果它出現在當前上下文中。
- 考慮片段與忽略片段相反，不包含在考慮片段內的消息都應該被忽略。
- 斷言片段 (顯示 “assert”)標明任何沒有顯示為聲明操作數的順序都是無效的。
- 循環片段 包含一系列被重復的消息。
下圖顯示的是循環片段：
這也是一個類似於復合片段的交互發生。 交互發生被其他圖參考，顯示為左上角帶"ref"，將被參考圖名顯示在方框的中間。
門
門是連接片段內消息和片段外消息的連接點。 在EA中，門顯示為片段框架上的小正方形。作用為順序圖與頁面外的連接器。 用來表示進來的消息源，或者出去消息的終點。下面兩個圖顯示它們在實踐中的使用。注意：" top level diagram"中的門用消息箭頭指向參考片段，在這里沒有必要把它畫成方塊。
部分分解
一個對象可以引出多條生命線，使得對象內部和對象之間的消息顯示在同一圖上。
狀態常量 / 延續
狀態常量是生命線的約束，運行時始終為"真"。顯示為兩側半圓的矩形，如下圖：
延續雖與狀態常量有同樣的標注，但是被用於復合片段，並可以延伸跨越多條生命線。
**********************************************************
UML狀態圖描述一個實體基於事件反應的動態行為，顯示了該實體如何根據當前所處的狀態對不同的時間做出反應的。通常我們創建一個UML狀態圖是為了以下的研究目的：研究類、角色、子系統、或組件的復雜行為。建模實時系統。
通用准則
當行為的改變和狀態有關時才創建狀態圖。
敏捷建模( AM) ( Ambler 2002)的原則－－最大化項目干系人的投資－－建議你只有當模型能夠提供正面價值的時候才創建模型。 如果一個實體，比如一個類或組件，表示的行為的順序和當前的狀態無關，那么畫一個UML狀態圖可能是沒有什么用處的。例如一個SurfaceAddress類就很簡單，表示了那些你將會在系統中顯示和操作的數據，因此一個UML狀態圖就沒有任何相關之處。而一個Seminar對象就非常的復雜，學生注冊這樣一個事件將會根據它的當前狀態有不同的反應，就像你在圖１中看到的。
圖⒈班級注冊的一個UML狀態圖。
把初始狀態放置在左上角。
如你在圖１所見的，初始狀態被建模成一個實心圈，把初始狀態放在左上角反映西方人的閱讀文化的習慣。
把最終狀態放置在右下角。
如你在圖１所見，最終狀態被建模為一個帶邊界的實心圓。把最終狀態放右下角反映了西方的文化的從左到右，從上到下的閱讀習慣。
狀態指南
狀態是一個實體的行為模式的某個階段。 狀態的表示是通過實體的屬性值。 例如，在圖１中，當seminar被標記為open，並且存在空位的時候，seminar就處於Open For Enrollment的狀態。
狀態名稱要簡單但應具有描述性。
象Open For Enrollment和Proposed這種的狀態名稱很容易理解，從而提高了圖⒈的溝通價值。理論上狀態名稱應該是現在時，但是用過去式寫成的諸如Proposed的名稱要比用現在時寫成的諸如Is Proposed的名稱好的多。
避免"黑洞"狀態。
黑洞狀態是那種只有變換進來但沒有任何變換發出的狀態，這種情況要么由於該狀態是一個最終狀態，要么就是你已經錯過了一個或多個變換變換。
避免"奇跡"狀態。
奇跡狀態是那種只有變換發出但沒有任何變換進來的狀態，這種情況要么由於該狀態是一個起點，要么就是你已經錯過了一個或多個變換變換。
子狀態建模指南
為復雜的目標建模子狀態。
圖１中展示的UML狀態圖是不完整的，因為它沒有建模Seminar的post - enrollment（注冊后）狀態。 圖２建模了一個Seminar的完整的生命周期，把圖１描述為一個新的包括子狀態集合的Enrollment的復合狀態，也稱作超狀態。 注意按理說你會像圖１的模型那樣處理標記，但為了簡化起見在原先變換上的標記都沒有包括在內。當一個現有狀態表現出復雜的行為時，建模子狀態就是有意義的，從而促使你來研究它的子狀態。 當幾個現有狀態共用一個通用的入口條件或出口條件( Douglass 1999)時，引入超狀態是有意義的，在圖１中你可以看到所有的狀態共用一個通用的closed變換，以到達最終狀態。
圖⒉Seminar的完整生命周期
把通用的子狀態變換放在一起
和圖１中每一個子狀態都擁有一個cancelled變換不同，在圖２中你可以看到cancelled變換僅用於描述Enrollment超狀態，這使圖形得到簡化。 如果子狀態都共享一個入口變換或出口變換，都可以使用一個同樣的方法。 變換上的警戒點和動作（如果有）也應該使相等的。
為復雜的實體創建一個分層的狀態圖
雖然這種表現子狀態的方法是很好使的，但是最終的圖可能變得相當復雜－－我們只要設想一下如果Being Taught狀態也有子狀態的話，圖２會變成什么樣就知道了。 一個替代的方法是創建一個分層的UML狀態圖。 例如，圖３表示高階視圖，而圖１描述了一個細節視圖。這種方法的好處是如果需要的話，馬上就可以建立一張詳圖來研究Being Taught狀態。
圖⒊Seminar的高階狀態圖。
最高階的狀態圖總有初始態和最終態
一個高階的UML狀態圖，例如圖2描述的這樣，應該表示實體的完整的生命周期，包括"出生"和最后的"死亡"。 低階的圖未必包含初始狀態和最終狀態，特別是那些建模一個實體的生命周期的"中間狀態"的圖。
變換和動作
變換是從一種狀態到另一種狀態的序列，它可能是通過一個事件觸發的。簡而言之就是被建模的實體的內部或外部的行為。 對一個類來說，變換一般是將會導致狀態的重要改變的操作調用的結果，因此我們需要了解一點，並不是所有的方法調用都會導致變換產生的，這一點非常重要。 一個動作就是某個東西，對類來說就是一個操作，被建模的實體所調用的操作。
用實現語言的命名規則命名軟件動作
圖１中的動作遵循Java操作的命名規則( Vermeulen et. 2000)，因為系統使用<java做為實現語言，如果我們的目標是兩外一種語言，那么我們也需要遵循適當的命名規則。
用敘述性文字命名角色動作
UML狀態圖可用於建模非軟件實體的生命周期，特別是UML圖上的角色。 例如學生角色就可能有諸如Accepted、Full Time、Part Time、Graduated、Masters、Doctoral、和Post - Doctoral等狀態，以顯示各人的不同行為。 當你在建模現實世界的角色時，與軟件中Student類不同的是，狀態間的變換最好是使用敘述性文字來描述，例如drop seminar和pay fees，而不是dropSeminar ()和payFees ()，因為現實生活中的人是做事情，而不是執行操作。
只有對所有的入口變換都合適時才注明入口動作
在圖１中你可以看到Closed To Enrollment狀態的入口中操作notifyInstructor ()都是經由entry/動作標記來調用的。 這暗示着每次進入狀態時都需要調用該操作，如果你不希望每次都發生，那么就把動作關聯到特定的入口變換。 例如，addStudent ()動作是在student enrolled變換到Open For Enrollment變換發生，而在到opened變換則不會發生，這是因為每次你在進入該狀態並不需要增加一個學生。
只有對所有的出口變換適合時才注明出口動作
出口動作，用exit/標記來表示，工作方式類似於入口動作。
只有當你想終止並再進入該狀態時才建模遞歸變換
一個遞歸的變換是那些兩個端點都擁有相同狀態的變換。 一個重要的暗示是實體從狀態出來，又回到原有的狀態，因此，那些由於entry/或exit/動作標記而被調用的任何一種操作都可能被自動調用。 圖１的Open For Enrollment狀態就是這種遞歸變換的例子，因此當前班級大小就在入口處被記錄下來。
用過去式命名轉換事件
圖１中的轉換事件，例如seminar split和cancelled，是使用過去式命名的，反映了這樣一個事實：變換是事件的結果－－因為事件發生在變換之前，因此應該用過去式命名。
把轉換標記放在接近源狀態的地方
雖然圖１比較復雜，變換標記盡可能放在靠近來源的地方，例如seminar split和student enrolled。 Furthermore, the labels were justified (left and right respectively) to help visually place them close to the source state.
以轉換方向為基礎放置變換標記
為了更易於判斷哪個標記和變換是一起的，按照如下的規則來放置變換標記：
在變換線條上的從左到右。
在變換線條下的從右到左。
變換線條右邊的往下。
變換線條左邊的往上。
警戒點
一個警戒點是為了穿過一個轉換而必須為真的一個條件。
警戒點不應該重疊
離開狀態的相似變換上的警戒點必須彼此一致。 舉例來說，x <0, x = 0,以及x > 0的警戒點是一致的，而x < = 0和x > = 0的警戒點就不是一致的，因為他們重疊了，它並沒有明確的指出當x為0時將發生什么。在圖1中，你可以看到警界點的一致性，從填寫注冊表活動出發的該學生划線變換上的警戒點沒有重疊，決策點上的警戒點也一樣。
為可視化的定位警戒點而引入接合點。
在圖２中你可以看到從Being Taught觸發student dropped事件存在兩個變換，而圖３中僅有一個，變換被合並了，因此我們需要一個接合點（填滿的圓）。 這種方法的好處是現在圖上的兩個警戒點更彼此接近了，更容易看出警戒點是否重疊。
警戒點不必配套
一個狀態的變換警戒點有可能是不完整的。例如，一個bank account對象可能從Open狀態變換到Needs Authorization狀態，這時需要一個大額存款"large deposit"的警戒點。可是，一個帶有"small deposit"的警戒點的deposit變換可能並不需要建模，它是被隱含的，我們遵循了AM的實踐－－簡單的描述模型和僅僅包括相關的信息。
一致的命名警戒點
圖１包含了諸如seat available和no seat available的警戒點，兩個警戒點的描述是一致的。 然而，諸如seats left、no seat left、no seats left、no seats available、seat unavailable之類的描述就是不一致，而且難於理解的。