簡介
統一建模語言 (UML)是一種標準化的視覺建模語言，用於分析、設計、文件化並溝通軟體系統的結構與行為。它提供一套通用的符號與圖形技術，協助開發人員、架構師、業務分析師、專案經理及其他利害關係人理解系統的運作方式。
UML並非程式設計語言。相反地，它作為軟體的視覺藍圖。團隊可以運用UML 圖形來描述需求、規劃系統架構、模擬業務流程、記錄現有應用程式，並說明系統各部分如何互動。
例如，電子商務應用程式可能包含使用者、商品、購物車、訂單、付款服務與配送服務。UML 圖形可表示這些元素、顯示其關係，並說明當顧客下單時會發生什麼事。
UML 由物件管理組 (OMG) 作為產業標準進行管理，並已透過國際標準被採用。現代 UML 通常指 UML 2.x，它定義了廣泛的結構與行為圖形集合。例如，UML 2.2 定義了 14 種圖形類型，平均分配於結構建模與行為建模。
什麼是 UML？
UML是一種適用於軟體密集型系統的通用建模語言。它提供一套標準化的記號，用於表示：
-
系統元件
-
類別與物件
-
使用者需求
-
工作流程與業務流程
-
物件之間交換的訊息
-
系統狀態與轉換
-
軟體部署環境
-
套件與元件之間的相依關係
UML 的目的並非取代原始碼；相反地，它協助團隊在實作前、實作中及實作後思考並溝通系統。
UML 模型可依據不同的詳細程度建立：
-
概念層級：描述主要業務概念，但不包含實作細節。
-
分析層級：探討需求、職責與系統行為。
-
設計層級：定義類別、介面、元件與互動。
-
實作層級：呈現與原始碼及部署基礎設施密切對應的細節。
為何 UML 至關重要？
UML至關重要，因為當軟體系統僅透過原始碼或冗長的書面文件描述時，可能會變得難以理解。
簡化複雜系統
圖形提供大型系統的視覺概覽。例如，類別圖能比數頁文字更清晰地展示數十個類別及其相互關係。
改善溝通
開發人員、設計師、架構師、測試人員、業務分析師與客戶可能擁有不同的技術背景。UML 為他們提供了一套共用的視覺語言，用於討論系統需求與設計決策。
支援規劃
團隊可在編寫程式碼之前，對工作流程、類別、服務與部署環境進行建模。這能及早發現缺失的需求、重複的職責以及架構問題。
有助於記錄軟體
UML 圖可作為長期技術文件。它們幫助新開發人員理解現有系統，並在需要變更時協助維護團隊。
鼓勵更優的設計
建立模型會迫使團隊思考以下問題：
-
哪個物件負責某項任務？
-
組件之間如何連接？
-
當操作失敗時會發生什麼事？
-
哪些類別彼此相依？
-
系統如何回應不同的事件？
UML 關鍵概念
類別
類別是定義一組物件所共用的屬性與操作的藍圖。
例如，一個訂單類別可能包含：
-
屬性：
訂單編號,訂單日期，以及狀態 -
操作：
calculateTotal()和cancelOrder()
物件
物件是類別的實際實例。如果 Order 是一個類別， order1001 可能是從該類別建立的特定物件。
屬性
屬性代表由類別或物件所持有的資料。
範例包括：
-
name -
price -
emailAddress -
orderStatus
操作
操作代表由類別所提供的行為。操作在程式語言中通常實作為方法。
範例包括：
-
addItem() -
submitPayment() -
sendNotification()
參與者
參與者是指與系統互動的外部角色。參與者可以是人、另一個系統或外部裝置。
範例包括：
-
客戶
-
管理員
-
金流閘道
-
倉儲系統
介面
介面定義了類別或元件承諾提供的一組操作。介面有助於降低相依性並支援可互換的實作。
關聯
關聯描述了 UML 元素之間的連接方式。常見的關聯包括關聯、相依、泛化、聚合與組裝。
多重性
多重性指定了參與關聯的物件數量。
常見範例包括：
-
1: 恰好一個 -
0..1: 零或一 -
*: 多 -
1..*: 一或多 -
0..*: 零或多
例如，一位客戶可能下達零或多個訂單。這可以表示為：
客戶 1 -------- 0..* 訂單
UML 圖形類別
UML 圖形通常分為兩大類別：
-
結構圖
-
行為圖
結構圖描述系統由什麼組成。行為圖描述系統做什麼以及其隨時間的行為方式。
結構型 UML 圖形
結構圖表示系統的靜態組織。它們專注於類別、物件、元件、套件、節點和關係。
1. 類別圖
類別圖是最廣泛使用的 UML 圖形之一。它透過顯示以下內容來表示系統的靜態結構：
-
類別
-
屬性
-
操作
-
介面
-
關聯
-
可見性
-
多重性
一個簡化的電子商務類別模型可能如下所示：
客戶
- customerId
- name
+ placeOrder()
訂單
- orderId
- orderDate
- status
+ calculateTotal()
產品
- productId
- name
- price
+ updatePrice()
可能的關聯包括：
客戶 1 -------- 0..* 訂單
訂單 1 -------- 1..* 產品
在更詳細的設計中，一個訂單項目類別可能會被引入於訂單與產品.
類別圖對於以下用途很有用：
-
領域建模
-
物件導向設計
-
資料庫與應用程式規劃
-
識別職責
-
說明繼承與介面
類別圖描述一般類別，而物件圖則顯示這些類別的特定實例。Visual Paradigm 將類別圖描述為物件導向系統中類別、屬性、操作與關係的模型。
2. 物件圖
物件圖顯示系統在特定時刻的快照。它代表實際的物件實例，而非一般類別。
例如：
customerA:Customer
name = "Alex"
order1001:Order
status = "Paid"
當您需要展示以下內容時，物件圖非常有用：
-
執行時物件的狀態
-
範例資料關係
-
特定情境
-
類別實例之間的連接方式
類別圖可能顯示一位客戶可以下達許多訂單。物件圖則可能顯示：customerA 目前擁有 order1001 與 order1002.
3. 組件圖
組件圖顯示可替換軟體組件的組織結構與相依關係。
電子商務組件圖可能包含：
-
網頁應用程式
-
訂單服務
-
產品服務
-
金流服務
-
通知服務
-
資料庫
範例：
網頁應用程式 --> 訂單服務
訂單服務 --> 金流服務
訂單服務 --> 通知服務
訂單服務 --> 訂單資料庫
組件圖特別適用於：
-
微服務架構
-
面向服務的系統
-
API 設計
-
應用程式架構
-
顯示服務邊界與相依關係
4. 部署圖
部署圖表示軟體執行的實體或虛擬環境。
它可能顯示：
-
客戶端裝置
-
網頁伺服器
-
應用程式伺服器
-
資料庫伺服器
-
雲端節點
-
容器
-
網路連線
-
已部署的軟體產出物
範例：
客戶端裝置
|
v
網頁伺服器
|
v
應用程式伺服器
|
v
資料庫伺服器
部署圖協助架構師了解軟體執行的位置以及基礎設施組件如何溝通。
5. 套件圖
套件圖將相關的模型元素組織成套件，並顯示這些套件之間的相依關係。
專案可能包含以下套件：
-
使用者 -
目錄 -
訂單 -
付款 -
通知
範例：
order --> user
order --> catalog
order --> payment
payment --> notification
套件圖對於以下用途很有用：
-
組織大型模型
-
顯示模組相依性
-
識別架構層級
-
防止不必要的耦合
6. 組合結構圖
組合結構圖顯示類別、元件或其他結構化分類器的內部結構。
它可以顯示：
-
內部元件
-
連接埠
-
連接器
-
內部協作
-
內部元素之間的關係
例如，一個 OrderController可能包含或連接至：
-
OrderService -
OrderRepository -
付款服務 -
通知服務
與通常聚焦於高階組件的組件圖不同，複合結構圖聚焦於分類器的內部組織。
7. 配置圖
配置圖為特定領域或技術擴展 UML。它透過標記、標籤值與約束來定義專用的建模元素。
例如，配置可能引入以下標記：
<<實體>>
<<控制器>>
<<服務>>
<<微服務>>
當需要調整標準 UML 記號以適應以下情境時，配置圖非常有用：
-
網頁應用程式
-
企業架構
-
即時系統
-
嵌入式系統
-
特定程式設計框架
-
產業專屬建模
配置圖常被省略於入門清單之外，但它屬於標準 UML 2.x 圖形類型之一。UML 2.x 通常被描述為包含七種結構圖與七種行為圖。
行為 UML 圖
行為圖描述系統的動態行為。它們顯示工作流程、事件、互動、狀態變更與回應。
1. 使用案例圖
使用案例圖從外部參與者的角度呈現系統的機能需求。
典型的線上購物系統可能包含以下參與者：
-
客戶
-
管理員
-
支付閘道
-
配送服務
可能的用例包括：
-
註冊帳戶
-
登入
-
瀏覽商品
-
將商品加入購物車
-
下訂單
-
進行付款
-
追蹤配送
-
管理商品
用例圖提供系統功能的概覽，而不描述具體的實作細節。
重要關係包括：
-
關聯：將參與者與用例連接起來。
-
包含：顯示另一個用例總是會重複使用的行為。
-
擴展：顯示可選或條件行為。
-
泛化：顯示參與者或用例之間的特化關係。
例如，下訂單可能包含進行付款，而套用折扣可能延伸下訂單.
2. 活動圖
活動圖表示流程或用例中的控制流。它可用於建模順序並發工作流。
範例：下訂單
開始
|
瀏覽商品
|
將商品加入購物車
|
前往結帳
|
輸入付款資訊
|
付款成功？
/
否 是
| |
顯示錯誤 建立訂單
|
發送確認
|
結束
活動圖可表示：
-
動作
-
決策
-
合併
-
迴圈
-
平行活動
-
起始與終止節點
-
負責任的泳道
泳道可以顯示哪個參與者或系統組件執行每個動作。例如，其中一個泳道可能代表客戶，另一個代表訂單服務，另一個代表支付閘道。
3. 序列圖
序列圖顯示物件或組件如何依時間順序進行溝通。
範例：下訂單
客戶 -> WebApp：提交訂單
WebApp -> OrderService：createOrder()
OrderService -> PaymentService：authorizePayment()
PaymentService --> OrderService：paymentApproved
OrderService -> NotificationService：sendConfirmation()
OrderService --> WebApp：orderCreated
WebApp --> 客戶：顯示確認訊息
序列圖包含：
-
參與者
-
生命線
-
訊息
-
活化條
-
回傳訊息
-
條件
-
迴圈
-
替代方案
-
平行互動
它們特別適用於解釋 API 呼叫、服務互動、驗證流程以及錯誤處理。
4. 通訊圖
通訊圖在早期 UML 版本中歷史上稱為協作圖，強調物件之間的關係以及它們之間交換的訊息。
與序列圖主要聚焦於垂直時間軸不同，它聚焦於：
-
物件
-
物件之間的連結
-
編號訊息
-
協作結構
範例：
1: submitOrder()
客戶 ----------------> WebApp
2: createOrder()
WebApp ------------------> OrderService
3: authorizePayment()
OrderService -------------> PaymentService
當物件協作的結構比精確的視覺時間軸更重要時，通訊圖非常有用。
5. 狀態機圖
狀態機圖顯示物件或系統如何根據事件改變狀態。
訂單可能經過以下狀態：
新訂單 -> 待付款 -> 已付款 -> 已出貨 -> 已送達
|
v
已取消
轉換可以標註事件或條件：
待付款 -- paymentApproved --> 已付款
待付款 -- paymentFailed --> 付款失敗
狀態機圖適用於：
-
訂單生命週期
-
使用者帳戶狀態
-
工作流程狀態
-
裝置行為
-
網路連線狀態
-
核准流程
當物件的行為高度依賴其目前狀態時，它們尤為寶貴。
6. 時序圖
時序圖說明一個或多個元素的狀態或值如何隨時間變化。
它通常用於：
-
即時系統
-
嵌入式系統
-
通訊協定
-
硬體與軟體協調
-
效能敏感互動
例如，時序圖可顯示以下項目之間的關係：
-
裝置訊號
-
控制器狀態
-
感測器數值
-
在定義時間間隔內的回應
7. 互動概覽圖
互動概覽圖透過將活動式控制流程與互動圖結合，提供互動的高階視圖。
它可以顯示：
-
主要互動的順序
-
互動片段之間的決策
-
並行互動路徑
-
對序列圖或通訊圖的參照
例如，線上訂單的互動概覽可能連接：
-
客戶身份驗證
-
產品選擇
-
結帳互動
-
付款授權
-
訂單履行
當一個流程過於複雜，無法用單一序列圖說明時，此圖非常有用。
UML 關聯
理解 UML 關聯對於建立有意義的圖形至關重要。
關聯
關聯代表兩個元素之間的結構連接。
客戶 -------- 訂單
這表示客戶與訂單之間存在關聯。
定向關聯
定向關聯顯示單向的導航性。
訂單 ------> 付款
這表明訂單知道或使用支付物件，反之則未必成立。
泛化
泛化代表繼承或特化。
使用者
/
顧客 管理員
在此，顧客 和 管理員 是「使用者.
相依性
相依性表示一個元素暫時使用或依賴另一個元素。
OrderService - - - -> PaymentGateway
對支付閘道的變更可能會影響訂單服務。
聚合
聚合代表一種整體與部分的關係，其中部分可以獨立存在。
Team ◇------ Player
即使團隊解散，球員仍可能繼續存在。
組合
組合表示一種強烈的整體與部分關係。部分通常依賴整體來管理其生命週期。
訂單 ◆------ 訂單項目
一個訂單項目可視為訂單的一部分，且可能無法在該訂單之外具有意義。
實現
實現表示某個類別或元件實作了一個介面。
付款服務 - - -|> 付款處理程序
該付款服務提供由付款處理程序介面所定義的行為。
UML 範例：線上購物系統
考慮一個線上購物應用程式。
主要參與者
-
顧客
-
管理員
-
付款閘道
-
配送服務
主要使用情境
-
建立帳戶
-
瀏覽商品
-
將商品加入購物車
-
下訂單
-
進行付款
-
追蹤配送
-
管理庫存
可能的類別
客戶
商品
購物車
購物車項目
訂單
訂單項目
付款
運送
可能的服務元件
使用者服務
目錄服務
購物車服務
訂單服務
付款服務
運送服務
通知服務
互動範例
當客戶下訂單時：
-
客戶提交購物車。
-
網頁應用程式將請求傳送給訂單服務。
-
訂單服務驗證商品。
-
付款服務授權付款。
-
訂單已儲存。
-
已通知運送服務。
-
通知服務會發送確認電子郵件。
此單一業務流程可透過多個 UML 圖表來表示：
-
使用案例圖：顯示客戶可以下訂單。
-
活動圖：顯示工作流程與決策點。
-
序列圖：顯示服務之間的訊息。
-
類別圖：顯示
客戶,訂單,產品，以及相關類別。 -
元件圖：顯示所涉及的服務。
-
部署圖：顯示這些服務執行的位置。
如何選擇合適的 UML 圖表
| 建模目標 | 建議的 UML 圖表 |
|---|---|
| 顯示類別及其關係 | 類別圖 |
| 顯示實際物件實例 | 物件圖 |
| 描述系統功能 | 使用案例圖 |
| 模擬業務或系統工作流程 | 活動圖 |
| 顯示隨時間交換的訊息 | 序列圖 |
| 顯示物件協作 | 通訊圖 |
| 顯示生命週期與狀態變更 | 狀態機圖 |
| 顯示軟體模組或服務 | 元件圖 |
| 顯示實體部署 | 部署圖 |
| 組織模型元素 | 套件圖 |
| 顯示分類器的內部結構 | 複合結構圖 |
| 顯示隨時間的變化 | 時序圖 |
| 彙總多個互動 | 互動概覽圖 |
| 為特定領域擴展 UML | 配置圖 |
良好的建模實踐是僅選擇能回答特定問題的圖表。建立所有可能的 UML 圖表會使文件變得過於複雜。
UML 與軟體開發生命週期
UML 可支援軟體開發的多個階段。
需求分析
使用案例圖有助於識別參與者與系統功能。活動圖可釐清業務流程與工作流。
系統分析
類別圖可表示領域概念。序列圖可協助分析人員理解使用案例如何被實現。
架構設計
元件圖、套件圖與部署圖有助於定義應用程式及其基礎架構的結構。
詳細設計
類別圖、序列圖、狀態機圖與複合結構圖可描述實作責任與物件互動。
開發
開發人員可在實作類別、服務、API 與資料庫結構時，將模型作為參考。
測試
測試人員可從使用案例、活動圖與序列圖推導測試情境。狀態機圖可協助識別有效與無效的狀態轉換。
維護
UML 圖形為現有系統提供文件，並協助團隊評估擬議變更的影響。
使用 Visual Paradigm 建立 UML 圖形
Visual Paradigm 是一個視覺化建模與軟體設計平台，支援 UML 圖形建立以及其他建模與開發活動。其 UML 功能包含類別、序列、使用案例、活動、元件、部署、狀態機、套件、物件及複合結構等圖形。
啟動 UML 專案
Visual Paradigm 中的一個實用工作流程如下：
-
建立新專案。
-
將模型組織成套件，例如「
需求,領域模型,服務」，以及「部署. -
建立使用案例圖以捕捉系統功能。
-
為重要工作流程新增活動圖或序列圖。
-
為領域模型建立類別圖。
-
為架構新增元件圖與部署圖。
-
與利害關係人檢視圖表。
-
隨著系統演進更新模型。
-
在需要時匯出圖表或產生文件。
建立類別圖
建立類別圖的步驟如下：
-
建立新的類別圖。
-
加入主要領域類別。
-
加入屬性與操作。
-
使用適當的關聯連接類別。
-
加入多重性。
-
在需要時標示繼承與介面。
-
排列圖表，使相關類別容易追蹤。
-
根據需求驗證模型。
例如，線上商店的類別圖可能包含 客戶, 訂單, 商品, 付款，以及 運送.
建立使用案例圖
建立使用案例圖可透過以下步驟：
-
識別外部參與者。
-
列出系統的主要功能。
-
加入系統邊界。
-
將使用案例置於邊界內部。
-
將參與者與其所參與的使用案例相連接。
-
僅在能釐清重複使用或可選行為時，才加入包含或延伸關聯。
建立序列圖
建立序列圖時：
-
識別正在建模的情境。
-
加入參與者或啟動元件。
-
加入參與的物件或服務。
-
將它們由左至右排列。
-
依時間順序加入訊息。
-
建模替代方案、迴圈與錯誤條件。
-
請確認每則訊息都對應到一項合理的職責。
協作與文件
Visual Paradigm 提供視覺建模能力、團隊協作功能、文件支援，以及旨在將建模與更廣泛的軟體開發活動相連接的整合功能。其平台亦支援協作式圖表審查與評論。
某些版本與工作流程可能還提供程式碼工程、資料庫建模、模型組織、圖表匯出及文件產生等功能。這些功能應根據專案需求進行選擇，而非自動套用到每個模型。
有效 UML 建模的最佳實踐
有目的地進行建模
每張圖表都應回答一個明確的問題。例如：
-
客戶如何下訂單？
-
哪些服務依賴於付款服務？
-
訂單可以進入哪些狀態？
-
哪些類別屬於訂單領域？
保持圖表專注
避免將整個系統放在一張圖表上。將大型模型劃分為較小的視圖，分別涵蓋需求、領域結構、行為、架構與部署。
使用一致的命名
在圖表之間使用相同的命名。如果一張圖表將某個元件稱為「OrderService」，另一張圖表就不應將其稱為「OrderManager」，除非它們確實是不同的元素。
選擇適當的詳細程度
面向利害關係人的圖表通常應比實作圖表包含較少的技術細節。除非與受眾相關，否則請勿加入方法簽章、資料庫欄位或框架特定細節。
避免不必要的關聯
加入所有可能的相依關係可能使圖表難以閱讀。請包含能傳達有意義設計資訊的關聯。
在關鍵處顯示多重性
多重性有助於釐清業務規則與資料關係。例如，顯示訂單包含一個或多個訂單項目，比單純連接這兩個類別更具資訊量。
根據需求驗證圖表
模型僅在能準確代表系統時才有用。請將圖表與需求、測試情境、原始碼及利害關係人的回饋進行比對。
將圖表視為活的文件
當重大設計決策變更時，請更新 UML 圖表。過時的圖表可能比完全沒有圖表更令人困惑。
結合互補的圖表
單一 UML 圖表無法說明系統的所有面向。類別圖可能顯示結構，而序列圖則解釋該結構在特定情境下如何運作。
應避免的常見錯誤
-
將 UML 視為原始碼
-
無特定目的而建立圖表
-
未加說明即混合概念與實作細節
-
在應使用組合之處使用繼承
-
從重要關聯中省略多重性
-
在單一圖表中加入過多元素
-
使用錯誤的包含與延伸關聯
-
未能建模錯誤流程與替代流程
-
允許不同的圖表使用不一致的名稱
-
僅因圖表看起來視覺上整齊有序，便假設其正確
UML 2.x 與圖表數量
早期的 UML 版本通常描述較少的圖表類型。UML 2.x擴充了該語言，並引入或正式規範了額外的圖表，包括：
-
組合結構圖
-
通訊圖
-
互動概覽圖
-
時序圖
它也將狀態圖（statechart diagrams）更名為狀態機圖。常見的 UML 2.x 分類包含 14 種圖表：七種結構圖和七種行為圖。行為圖組包括用例圖、活動圖、狀態機圖、序列圖、通訊圖、互動概覽圖和時序圖。結構圖組包括類別圖、物件圖、元件圖、組合結構圖、部署圖、套件圖和配置文件圖。
因此，在廣泛使用的 14 種圖表分類下，將 UML 2.x 描述為僅有 13 種圖表的列表是不完整的。
結論
UML 提供了一種實用的視覺語言，用於理解、設計和記錄軟體系統。它協助團隊溝通需求、探索架構、建立物件關係模型、描述工作流程，並解釋執行時行為。
最常被使用的圖表通常包括：
-
用於功能需求的用例圖
-
用於靜態結構的類別圖
-
用於工作流程的活動圖
-
用於互動的序列圖
-
用於架構的元件圖
-
用於基礎設施的部署圖
-
用於生命週期行為的狀態機圖
Visual Paradigm可以透過提供工具來支援此建模流程，用於建立 UML 圖、組織模型、與團隊成員協作，以及產出技術文件。最有效的方法並非不加選擇地使用所有 UML 圖，而是選擇能釐清重要設計問題的圖形。
當一致使用並與實際系統保持對齊時，UML 不僅僅是一組符號的集合：它成為一種共享的設計語言，連結業務需求、軟體架構、實作、測試與長期維護。