簡介

統一建模語言（UML）已成為跨產業軟體系統視覺化、規格化與文件化的事實標準。其核心並非僵化的開發方法論，而是一種靈活的視覺語言，旨在彌合抽象需求與具體實作之間的差距。UML 2.0 透過將圖表類型組織成兩個互補的類別，明確化了這一目的：結構圖，用以捕捉系統的靜態架構與實體關係，以及行為圖，用以模擬組件如何互動、狀態如何改變，以及邏輯如何隨時間執行。本指南根據《UML 2.0 精要》（O’Reilly）所闡述的基礎原則，全面概述了每一種主要的 UML 圖表類型，包括其核心概念、符號規則與實際應用情境。無論您是設計物件導向系統、繪製部署拓撲，還是模擬複雜的業務工作流程，了解何時以及如何應用每種圖表，將使您能以清晰、精確且共識一致的方式傳達技術解決方案。UML 2.0 精要（O’Reilly），本指南全面概述了每一種主要的 UML 圖表類型，包括其核心概念、符號規則與實際應用情境。無論您是設計物件導向系統、繪製部署拓撲，還是模擬複雜的業務工作流程，了解何時以及如何應用每種圖表，將使您能以清晰、精確且共識一致的方式傳達技術解決方案。

概觀

UML 2.0 將圖表分為兩個主要類別:

類別	目的
結構圖	捕捉元件的實體組織——物件之間的關聯方式
行為圖	著重於元件如何互動、狀態如何改變，以及行為如何隨時間演進

💡 關鍵原則：UML 模型由一個或多個圖表組成。每個圖表代表系統中某個特定的視角或關注點於所建模的系統中。單一元件通常會出現在多個圖表中。

🔷 結構圖

結構圖模擬您系統的靜態架構——關注「是什麼」，而非「如何」。

1. 類別圖

目的: 模型類別、介面及其靜態關係。

主要元素:

具有屬性和操作的類別
介面與實作關係
關聯、聚合、組合與一般化
可見性修飾詞（+, -, #, ~)
多重性規範（1, 0..*, 1..5)

範例使用:何時使用:

類別的類型與類別型態

該圖表使用類型（以尖括號內的文字表示，例如 <<entity>>）來分類每個類別的角色：

邊界類別（<<邊界>>): 這些處理系統與其參與者（使用者或外部系統）之間的互動。
範例： 主控台視窗 和 對話方塊.
控制類別（<<控制>>): 這些管理應用程式的協調、交易與商業邏輯流程。
範例： 繪圖內容 和 資料控制器.
實體類別（<<實體>>): 這些代表系統所追蹤的核心資料或持久性資訊。
範例： 框架, 視窗, 事件, 形狀, 圓形, 矩形, 多邊形，以及點.
抽象類別： 該 形狀 類別代表一個抽象概念。它作為特定形狀的基礎藍圖，無法獨立直接實例化。

類別的結構

標準的UML類別方框被劃分為不同區塊。以 圓形 類別為例：

類別名稱： 位於頂部區塊（圓形).
屬性： 位於中間區塊，代表資料欄位。
-半徑：浮點數 （減號 - 表示私有屬性）。
-中心：無符號整數
操作（方法）： 位於底部區塊，代表行為或功能。
+area(半徑 : 浮點數) : 雙精度浮點數 (加號+ 表示公開方法)。
+circum(), +setCenter()，以及 +setRadius().

關係與連結

連接類別的線條與箭頭定義了它們之間如何互動與相互依賴：

泛化（繼承）

以一條實線搭配一個 空心箭頭 指向父類別。這表示「是-一種」關係，其中子類別從父類別繼承屬性和行為。

視窗 繼承自 框架.
控制台視窗 以及 對話方塊 繼承自 視窗.
圓形, 矩形，以及 多邊形 繼承自抽象類別 形狀 （例如：圓形是形狀）。

聚合

以一條實線搭配一個 空心菱形 位於容器端。這表示一種鬆散的「擁有」或整體-部分關係，其中子物件可以獨立於父物件存在。

視窗 聚合 形狀 （多重性 1 至 *）。一個 視窗 可以包含多個（*）形狀，但如果視窗關閉，這些形狀本身在概念上仍可存在於記憶體或其他情境中。

組合

以一條實線搭配一個 實心（黑色）菱形 位於容器端。這表示一種強烈的「擁有」關係，且生命週期一致——若容器被銷毀，其組成部分也會一同被銷毀。

圓形 由 點 物件（多重性 1 到 *). 一個圓形無法在沒有其圓心或邊界點的情況下存在；破壞圓形也會破壞這些特定點的參考。

依賴

以表示虛線箭頭。它顯示了一個類依賴於另一個類，這意味著對目標類的更改可能會影響源類。

視窗 依賴於 事件 （由指向的虛線箭頭表示）事件）。視窗依賴於事件觸發來執行如 handleEvent().

關聯

以一條簡單的實線表示。它表示一種結構關係，其中一個類的對象與另一個類的對象相連接。

對話方塊 與關聯資料控制器，表示它們彼此之間進行通訊以傳遞資訊或協調行為。

文件元素

注意： 該圖示包含一個帶有折角的註解方框，透過虛線連接到 視窗 類。它提供了人類可讀的上下文： 「應用程式的主視窗。」

What is Class Diagram?

設計物件導向的軟體架構
記錄領域模型
生成程式碼骨架

2. 模組圖

目的: 展示實作單元的組織結構與依賴關係。

主要元素:

模組（以 «component»)
提供的/所需的介面（球與插座符號）
組裝連接器與依賴關係
實體（編譯輸出：JAR、DLL、可執行檔）

範例用途:何時使用:

模組與模組邊界

圖表的核心概念是模組，即系統中一個自主且模組化的單元，它封裝內部內容，並透過明確的介面展現其行為。外層的大型邊界代表整體的終端模組，作為子系統或容器。在此容器內包含較小且專門化的內部模組——分別為 安全檢查, 人員, 缺陷，以及地圖。這些內部單元中的每一項都代表一個模組化的軟體或資料管理邏輯，共同協作以完成終端的責任。

介面作為合約

模組不會直接暴露其內部邏輯；相反地，它們透過明確定義的介面進行互動，這些介面作為架構合約。

提供的介面： 以「棒棒糖」或圓形符號表示，這些代表組件所實作並提供給環境的服務、資料或作業。例如，外部的 Terminal 組件會公開外部提供的介面，如狀態, 詳細資訊，以及檢驗項目，表示外部客戶可向其請求的內容。
所需的介面： 以「插座」或半圓形符號表示，這些指定組件為正常運作而需來自其他實體的服務或資料。在圖表的右側，Terminal 組件明確地公開了對帳戶與檢驗編號的所需介面，顯示其對外部子系統的依賴關係。

埠與內部接線

為了在維持封裝性的同時管理資料與控制的流動，系統使用埠與委派關係。

埠：位於組件邊界上的小方塊代表埠。它們作為獨特的互動點，使組件的內部結構與外部世界相連。埠讓組件能將其內部接線與外部環境隔離，表示內部組件可被取代或修改，而不會改變父組件對外部的呈現方式。
委派與組裝： 在 Terminal 內部，線條將這些介面連接起來，形成結構性組裝。外層埠上的提供介面會將傳入的請求直接委派給內部組件的提供介面（如狀態與詳細資訊通往安全檢驗的路徑）。相反地，內部組件會將其所需的插座介面直接接至鄰近組件的提供棒棒糖介面。例如，安全檢驗組件依賴檢驗員介面，由員工，該缺陷詳情 介面由缺陷，以及位置介面由地圖，創造出一個緊密協調但鬆散耦合的內部生態系統。

What is Component Diagram?

規劃模組化系統架構
管理建構相依性
記錄可重複使用的元件程式庫

3. 組合結構圖（於 UML 2.0 中新增）

主要元素:

零件（具有整體-部分關係的屬性）
介面（與提供/所需介面互動的點）
連接器（零件之間的執行時期連結）
合作出現

範例用途：建模一個汽車:

封裝分類器（類別）

外層矩形代表包含的分類器，在此情況下為汽車類別。在組合結構圖中，此邊界作為容器，封裝系統的內部執行時期設定。它定義了個別實例合作以達成更廣泛行為目的的環境，將「汽車」內部運作的複雜性隱藏起來，避免外部實體察覺。

零件（內部結構）

車輛邊界內的內部矩形代表零件。一個零件說明在包含分類器執行期間，一組實例所扮演的角色。與顯示靜態編譯時間關係（如標準類圖）不同，這些零件表示填滿特定架構槽的執行時期實例：

-t：變速箱：扮演變速系統角色的實例。
-e：引擎：扮演引擎動力來源角色的實例。
-s：方向系統：扮演方向機制角色的實例。

冒號符號表示這些是根據其對應類別定義的結構角色，明確規定了運作中的車輛內部必須存在的組件。

介面與邊界

嵌入在外部分類器邊界和內部零件邊界上的小方塊代表介面。介面是獨特的互動點，將分類器的內部結構與外部環境分離。

車輛邊界上的外部介面——例如：輪子, ：油門踏板，以及：方向盤——顯示車輛如何與外部世界或物理環境互動，而不揭露哪些內部零件負責處理這些互動。
內部零件上的介面（如變速箱或引擎模組上的介面）控制這些子系統之間，或與父邊界之間的通訊方式。

連接器與內部布線

將介面連結在一起的實線代表連接器。連接器定義了零件之間，或零件與外部介面之間在執行時期的通訊路徑。

委派連接器：將容器的外部介面直接連接到零件的內部介面。例如，外部: 輪子 接口直接連接到 變速箱，以及外部的 : 方向盤 直接連接到 轉向系統。這確保外部刺激能無縫地委派給正確的內部執行者。
組裝連接器： 將內部組件連結在一起以促進協作。介於 變速箱 和引擎的連接器顯示這兩個不同的執行階段角色直接交換信號、資料或機械力，使汽車能作為一個整體運作。

何時使用:

記錄設計模式
模擬複雜的內部協作
橋接類別設計與組件實作

4. 部署圖

目的: 將軟體實體映射到硬體執行環境。

主要元素:

節點（裝置、執行環境）
實體（可部署單元）
節點之間的通訊路徑
部署規格（設定細節）

範例用途:何時使用:

節點與實體基礎設施

與模擬程式碼佈局或類結構的邏輯設計圖不同，部署圖專注於硬體拓撲。主要的構建模塊是節點，以三維立方體的視覺形式表示。節點說明實際執行軟體元件的實體計算資源或執行環境：

<<處理器>> 節點： 立方體以特定類型標記為<<處理器>>（例如快取伺服器, 主伺服器，以及通用的伺服器模塊）代表具有計算能力、記憶體和處理能力，能夠執行軟體二進位檔案的節點。
<<網路>> 節點： 標籤為本地網路 代表通訊路徑或路由基礎設施，而非單一電腦。它表示物理主幹，使連接的處理器能夠交換資料封包流。
裝置節點： 未標記類型的節點，例如網際網路以及調制解調器銀行 代表邊界硬體組件或外部實體基礎設施，用於將外部流量路由至核心系統環境。

關聯與通訊路徑

連接三維立方體的實線代表關聯在部署圖中，這些關聯描繪出節點之間的物理通訊路徑、網路連結或硬體連接。

介於網際網路與調制解調器銀行顯示外部公開資料進入硬體堆疊的入口點。
從調制解調器銀行延伸至快取伺服器描繪出進來流量的物理路由，向下至邊緣快取層。
連結快取伺服器與其下層的主伺服器叢集至區域網路建立內部元件如何透過共用的高速區域匯流排或網路交換機基礎設施進行通訊。

拓撲分層與冗餘

圖中節點的配置明確顯示了部署拓撲以及高可用性與負載分散的架構設計選擇。

邊緣快取層：位於入口調制解調器硬體正下方的是兩個獨立且平行的快取伺服器節點。此配置以視覺方式展示了一個冗餘的邊緣層，旨在分散進入的流量負載，並在請求到達深層基礎設施前快取資源。
內部伺服器農場：位於堆疊底部，透過區域網路連接，是一個核心伺服器叢集。主伺服器 和相鄰的通用 伺服器 節點以視覺方式呈現主從或主備架構佈局，確保資料持久性與大量運算工作負載能在內部資料中心環境中安全協調。

目的：模擬分類器與複雜模式的內部結構。

規劃系統基礎架構
記錄分散式架構
指定故障轉移與冗餘策略

5. 套件圖

目的：透過邏輯分組來組織與管理命名空間。

主要元素:

套件（帶有標籤的矩形）
匯入/存取關係（«匯入», «存取»)
合併關係（«合併»)
可見性（+ 公開， - 私有）

範例用途:

子系統與套件邊界

該圖表嚴重依賴「資料夾」符號來表示設計元素的邏輯分組。

子系統： 大型外部資料夾以「」符號表示<<子系統>> 訂購 代表物理系統中一個主要且封裝的行為單元。它作為一個高階容器，將執行訂單管理所需的相關組件和套件進行分組。
套件： 子系統內部和外部的較小資料夾（例如UI, 訂單處理，以及GUIManager）都是標準套件。它們用於將元素組織成可管理的群組，建立命名空間，並定義架構內的可見性邊界。

依賴關係與層次結構

虛線箭頭表示依賴關係，表明一個套件（目標）的變更可能影響原始套件（來源）的功能。

內部依賴關係： 在訂購子系統內，可見清晰的自上而下的架構層次結構。UI 套件依賴於訂單處理，而該套件又依賴於價格計算器以及外部儲存。這代表了一種架構流程，其中較高階的呈現元件依賴於核心業務邏輯與資料存取層。
對外部套件的依賴： 套件也可以依賴於其直接子系統邊界以外的元件。例如，UI 套件依賴外部 GUIManager。同樣地，隨機儲存 和 串流儲存 底部的套件跨越子系統邊界，依賴外部資料結構，突顯出該子系統如何整合至更大的軟體生態系統中。

抽象與繼承（泛化）

該圖表使用特殊樣式與關係箭頭，展示應用於模組化架構的抽象設計模式。

抽象套件與具體套件： 包含抽象元素或定義類似介面結構的套件，以斜體名稱表示（例如 外部儲存 和 儲存管理）。相反地，包含運作程式碼實作的套件，例如 儲存庫 和 檔案儲存，則使用標準文字表示它們為具體套件。
泛化： 以一條實線搭配開口的空心三角形指向父套件來表示。這表示繼承或實作關係。在子系統內部，隨機儲存 和 串流儲存 專化或實作抽象的 外部儲存 介面。在子系統外部，具體的 儲存庫 和 檔案儲存 套件將抽象化向上推廣 儲存管理 套件，顯示如何在套件層級上模擬多型行為與結構分類。
何時使用:
管理大型程式碼庫
定義模組邊界
控制編譯相依性

6. 物件圖

目的: 展示特定時刻的實例及其連結的快照。

主要元素:

物件（底線命名：myCar:Car)
物件實例之間的連結
執行時期的屬性值

範例用途:

物件與具體實例

與顯示抽象、藍圖層級設定的類別圖不同，物件圖捕捉的是記憶體中實際存在的實例。物件以矩形表示，其名稱總是加上底線，以表示實例化。

命名物件： 這些遵循語法 實例名稱 : 類別名稱。例如，c : Company 代表名為「c」的特定公司實例，而p : Person 代表名為「p」的特定個人實例。
匿名物件： 當特定實例識別符被省略或與情境無關時，僅提供類別名稱，並以冒號開頭（例如，: ContactInformation）。這表示存在一個具體的聯絡資訊實例，並與結構相關聯，但在此情境中不需要獨特的變數名稱。

狀態與屬性值

物件矩形的下層 compartment 包含其特定狀態，由該時刻賦予屬性的明確值所定義。這些項目不只列出資料類型，而是使用屬性 = 值指派格式來反映現實：

部門實例d1持有屬性值name = 銷售.
另一個獨立的部門實例d2持有值name = 研發.
個人實例p持有完整的狀態資料，勾勒出特定的個人檔案：name = 德瑞克, employeeID = D-12821，以及title = 經理.

連結與關係

連接物件的實線代表連結連結是類別之間定義的關聯的具體實例。如果類別圖顯示公司擁有部門，物件圖則展示了它們之間實際的執行時期連接。

公司實例c與部門實例積極連結d1（銷售）以及d2（研發）。
該圖也展示了層級實例接線，其中d1 : 部門（銷售）向下連結至一個同樣被定義為部門的子部門實例（名稱 = 美國銷售).
最後，人員實例p（德里克）連結至美國銷售部門實例，同時也維持與一個匿名：聯絡資訊實例，其中包含他的實體地址。

何時使用:

驗證類別圖設計
調試複雜的物件關係
展示範例執行時期狀態

🔶 行為圖

行為圖用來模擬動態方面——系統隨時間的行為方式。

7. 活動圖

目的：模擬工作流程、業務流程與演算法邏輯。

主要元素:

動作（圓角矩形）
控制節點：初始、決策、合併、分支、匯合、最終
物件節點與插槽
區隔（泳道）用於責任分配
例外處理程序與可中斷區域

範例使用：訂單處理工作流程

結構組織（泳道與區隔）

該圖表垂直組織成大型欄位，可互換稱為泳道或區隔。這些邊界對其所包含動作的責任進行分類，將步驟對應到特定角色或業務單位：

客戶銷售介面：負責客戶端的生命周期，處理客戶初始化、替代路由及最終呈現。
提案負責人：管理核心規劃、運營分析以及正式提案資料結構的整合。
報價負責人：專注於財務估值並準備具體的報價指標。

控制流程與動作狀態

逐步的程序執行由控制節點與方向性路徑引導。

初始節點：以頂部的實心黑圓圈表示，標示整個活動工作流程的起始點。
動作： 圓角矩形（例如，初始化聯絡人, 搜尋替代方案，以及整合額外資訊) 代表執行序列中的單一、不可分解的步驟或任務。
控制流程： 連接各元素的實線箭頭決定了工作流程的順序推進，明確指出哪一個操作必須完成後，下一個操作才能開始。
活動終止節點： 底部的靶心符號（實心圓圈位於空心環內）標示整個流程執行的絕對終止點。

路由與受保護邏輯（決策節點）

菱形符號代表決策節點，用於模擬工作流程中的條件分支。

進入的控制路徑會根據特定輸入，分裂為多條互斥的輸出路徑。
決定選擇哪條路徑的條件被包圍在方括號內，稱為守衛條件（例如[已接受], [已拒絕]，以及[與其他供應商合併或更改需求])。流程在執行時評估這些守衛條件，以將執行導向適當的功能路徑。

並行處理（分叉與合併節點）

圖中的實心黑條作為同步點，用於管理並行或同時執行的流程。

分叉節點（圖示指標中標示為流程節點）： 單一的進入控制流進入黑條後，分裂為多個獨立且同時執行的執行線程。在此處，創建專案計畫後，流程分叉，允許提案負責人執行分析與交付規劃，同時報價負責人處理報價準備工作。
合併節點： 一個將多個並行路徑重新合併為單一控制流的同步條。流程無法通過合併節點，直到所有進入的並行資料流都成功抵達條狀位置，確保報價編譯與提案撰寫完全完成後，才可繼續進行最終包裝的編譯。

資料整合（物件節點）

標準矩形代表物件節點，用於將資料流引入以控制為導向的活動圖中。

物件節點代表由動作產生或消耗的特定資料或實體物件的實例，使用實例名稱：類別名稱慣例（例如，一個提案：提案 和 一個計畫：交付專案計畫).
明確標記建立箭頭顯示動作何時實例化或更新資料結構，展現資料如何隨著操作執行從一項任務流動到另一項任務。

Activity Diagram, UML Diagrams Example: Relationships between Activates and Business Entities - Visual Paradigm Community Circle

何時使用:

記錄商業流程
模擬用例實現
指定複雜演算法

8. 狀態機圖（狀態圖）

目的：模擬物件的生命週期與狀態相關行為。

主要元素:

狀態（帶有進入/離開/執行活動的圓角矩形）
轉移（觸發條件[守衛]/效果）
虛擬狀態：初始、選擇、分叉、匯合、歷史、終止
複合狀態與正交區域

範例應用：電話系統設定

狀態與系統條件

此圖表透過描繪系統（特別是電話系統設定）的各種獨立情境或條件，來捕捉系統的行為。

狀態： 圓角矩形代表狀態（例如，閒置, 撥號音, 撥號中, 連接中，以及已連接）。狀態代表物件生命週期中的一段期間，在此期間物件滿足某種條件、執行活動或等待事件。
初始虛擬狀態： 最左側的實心黑圓點代表狀態機的起始點。它是一個虛擬狀態，而非真正的狀態，僅作為物件實例化時指向預設活躍狀態的指標（空閒).
終止狀態： 最右側的靶心符號代表狀態機執行的終止，表示物件已完成其生命週期。

轉移與事件驅動的路由

連接各狀態的有向線段為轉移，代表因特定觸發事件而從一個狀態移動到另一個狀態。

標準轉移：由特定事件觸發，例如使用者操作或系統回應，並標示於線段上。例如，從空閒轉移到撥號音發生於掛機事件被觸發時，以及從撥號音轉移到撥號中 在收到一個 digit(n) 事件時發生。
自我轉移： 一個從狀態中跳出並直接返回到同一狀態的轉移箭頭（如在撥號狀態中，以 digit(n) 觸發條件下可見）。這表示事件已被處理，並更新內部狀態上下文（例如，記錄一個新撥號的數字），而不會導致物件離開或改變其整體運作狀態。

替代路徑與錯誤處理

狀態機擅長展現執行期間根據不同條件產生的行為邏輯與錯誤分支。

成功執行路徑： 中央水平流程圖顯示了最佳路徑：空閒 $rightarrow$ 撥號音 $rightarrow$ 撥號 $rightarrow$ 連接中 $rightarrow$ 響鈴 $rightarrow$ 已連接 $rightarrow$ 已斷開.
例外與錯誤處理狀態： 系統透過分支至專用處理狀態來應對失敗或延遲。若在連接期間號碼忙線，系統將觸發 numberBusy 轉換以進入忙音狀態。如果使用者在撥號時暫停太久，就會觸發一個 逾時 事件，使系統轉換至警告或逾時狀態。如果偵測到錯誤的序列，就會觸發一個 無效號碼 觸發器會將系統導向 錄音訊息 狀態，確保系統能安全處理所有現實世界中的邊界情況。

State Diagram - A Quick Tutorial - Visual Paradigm Blog

何時使用:

建模嵌入式系統或協定實作
指定UI狀態管理
記錄物件生命週期規則

9. 互動圖

四種圖表類型強調物件協作的不同方面：

a) 序列圖 (最常見)

目的: 展示生命線之間時間順序的消息交換。

主要元素:

生命線（垂直虛線）
訊息（實線/虛線箭頭並帶標籤）
執行發生（激活條）
合併片段： alt, opt, loop, par, break

範例使用:

生命線與執行環境

該圖表從左到右讀取以建立參與者，並從上到下表示時間的流逝。

生命線： 頂部附著於虛線垂直線的方框代表生命線。它們遵循「實例名稱 : 類別名稱」慣例（例如，window : UI, aChain : HotelChain，以及aHotel : Hotel）。虛線用來追蹤該參與者在整個序列中的存在。
激活條： 位於生命線上方的細長彩色垂直矩形表示一個激活（或執行發生）。這些條狀圖顯示物件正在積極執行作業，或等待巢狀子呼叫返回的確切時間。
已停止： 在window : UI 生命線表示破壞或終止，顯示此特定參與者的生命週期已結束，其資源已被釋放。

訊息類型與通訊

參與者之間的通訊透過水平箭頭來模擬，代表訊息，並使用層級編號系統（例如：1、1.1、1.1.1）依序排列。

同步訊息： 實線搭配實心箭頭（例如 1：makeReservation 和 1.1：makeReservation）表示同步呼叫。發送者會阻塞執行，並等待接收物件完成其處理。
自我訊息： 一個訊息迴圈，起始與結束於同一個激活條上（例如 1.1.1：available(roomId, date)：isRoom 由 aHotel）代表一個 自我訊息。這表示物件內部方法的執行，即物件呼叫自身的一個操作。
建立訊息： 一條虛線搭配開口箭頭，直接指向物件方框（例如訊息 1.1.2: 指向 aReservation : Reservation）代表物件建立。這顯示 aHotel 實例在執行時期的該時刻動態建立 aReservation 物件。

合併片段與控制流程

包圍序列部分的大型矩形方框稱為 合併片段，使用互動運算符來管理複雜邏輯、分支和迭代。

迴圈片段： 外層方框標記為 迴圈 且具有守衛條件 [每天] 代表迭代。此方框內包含的所有互動將根據預訂請求中指定的每一天持續重複。
替代性組合片段（Alt）： 嵌入迴圈內部的是一個 alt 片段（圖示指標中標註為「如果」），用於處理條件分支。它會評估守衛條件 [isRoom = true]。如果條件成立，序列將執行該區塊內的特定路徑——建立 aReservation 實例，並隨後觸發訊息 2: 以建立 aNotice : 確認。如果條件為假，則會採取替代路徑（或不執行任何動作）。

b) 通訊圖

目的：強調物件關係，而非訊息時序。

What is Communication Diagram?

主要元素:

物件作為節點
帶有編號、有方向的訊息連結
著重於「誰與誰對話」

c) 互動概觀圖

目的：使用活動圖符號表示高階控制流程。

Interaction Overview Diagram Example

關鍵元素:

互動發生作為活動節點
決策/合併用於分支
分叉/匯合用於平行處理

d) 時序圖

目的: 建模精確的時序約束（即時系統）。

What is Timing Diagram?

關鍵元素:

每個生命線的狀態時間軸
時間尺度與約束
帶有持續時間標記的訊息箭頭

何時使用互動:

指定用例實現
調試複雜的訊息流程
記錄 API 使用模式
建模即時協定時序

10. 用例圖

目的: 從外部參與者的角度捕捉功能需求。

關鍵元素:

用例（橢圓或分類器矩形）
參與者（人形圖示或分類器）
關聯（參與者 ↔ 用例）
關係：«include», «擴展»，一般化
系統邊界框

範例使用：自動櫃員機系統

A Comprehensive Guide to Use Case Modeling - Visual Paradigm Guides

何時使用:

與利益相關者共同收集需求
定義系統範圍與邊界
規劃測試情境

🎯 選擇正確圖表：決策指南

目標	推薦圖表
設計類別結構	類別、物件、套件
模擬執行時互動	順序圖、通訊圖
記錄業務流程	活動圖、用例
指定物件生命週期	狀態機
規劃系統部署	部署圖、元件圖
模擬複雜的內部結構模式	組合結構
捕捉即時限制	時序圖
定義需求	用例、活動圖

🔑 關鍵建模原則

從簡單開始: 從最符合您當前目標的圖表類型開始。
迭代: 隨著理解的加深，不斷優化模型——第一稿中沒有任何圖表是「最終」的。
受眾很重要: 根據讀者（開發人員與利益相關者）的需求調整細節層級。
結合視角: 使用多個圖表來完整敘述一個故事（例如：用例 → 序列圖 → 類圖）。
謹慎擴展: 為特定領域的需求使用樣式、標籤值和範本——但請記住記錄下慣用規範。
保持可讀性: 忽略不相關的細節；使用註解補充上下文。

📌 請記住: 「UML 是一種語言，而不是一種方法論。」 它提供符號表示——而非流程。選擇能釐清溝通的圖表，而非僅僅為了填滿方框。

結論

掌握 UML 的重點不在於記住每一項語法規則，而在於學會清楚且有目的性地講述關於您系統的故事。正如本指南所示，每種 UML 圖表類型都提供了一個獨特的視角：類圖與套件圖揭示靜態架構，序列圖與狀態機圖展現動態行為，而部署圖與組合結構圖則連結設計與執行。UML 真正的威力在於其適應性——它能從白板草圖擴展到工具驅動的可執行模型，並能適應開發人員、架構師與業務利益相關者的各種需求。請記住，有效的建模是迭代的、以受眾為導向的，且具有明確的選擇性。從最簡單、能傳達您意圖的圖表開始，隨著理解的加深不斷優化，當單一圖表無法完整呈現時，便結合多個視角。UML 是一種溝通語言，而非合規性檢查清單；應使用它來釐清模糊之處，而非製造混淆。透過謹慎應用這些原則，您將能把抽象概念轉化為可執行的藍圖，使團隊目標一致，加速開發進程，並確保系統在演進過程中保持韌性。