UML代表統一建模語言。它是一種標準化的建模語言，由一組整合的圖表組成，旨在幫助系統和軟體開發人員指定、視覺化、構建和記錄軟體系統的各項成果，同時也適用於業務建模及其他非軟體系統。
UML代表了一套經過實踐證明在建模大型複雜系統方面成功的最佳工程實踐。UML是開發物件導向軟體及軟體開發流程的重要組成部分。UML主要使用圖形符號來表達軟體專案的設計。使用UML有助於專案團隊溝通、探索潛在設計，並驗證軟體的架構設計。在本文中，我們提供有關UML的詳細資訊。
UML的起源
UML的目標是提供一種可被所有物件導向方法使用的標準符號，並選取和整合先前符號的最佳元素。UML設計用於廣泛的應用範圍，因此它提供了適用於各種系統與活動的構造（例如：分散式系統、分析、系統設計與部署）。
UML源自於三種領先的物件導向建模符號的整合：
- 物件建模技術（OMT） [James Rumbaugh 1991] – 最適合用於分析與資料密集型資訊系統。
- Booch [Grady Booch 1994] – 在設計與實作方面非常強大。Grady Booch長期與Ada語言合作，並是該語言物件導向發展的重要貢獻者。儘管Booch方法非常強大，但其符號並不太受歡迎（其模型中充滿雲形圖示——看起來不太整潔）。
- OOSE（物件導向軟體工程 [Ivar Jacobson 1992]）——以稱為「使用案例」的模型為特徵。使用案例是一種強大的技術，可用於理解整個系統的行為（這正是物件導向傳統上較弱的領域）。
1994年，軟體界震驚於OMT創作者Jim Rumbaugh離開通用電氣，加入Rational Software的Grady Booch。這項合作旨在將兩人的理念整合成一種統一的方法（暫定名稱為「統一方法」）。
到了1995年，OOSE創作者Ivar Jacobson也加入Rational，他的想法（特別是「使用案例」的概念）被納入新的統一方法中——現稱為統一建模語言1.0。Rumbaugh、Booch與Jacobson三人團隊被親切地稱為「三劍客」。
UML也受到當時其他物件導向符號的影響：
- Mellor與Shlaer [1998]
- Coad與Yourdon [1995]
- Wirfs-Brock [1990]
- Martin與Odell [1992]
UML還包含了當時其他主要方法中所沒有的一些新概念，例如擴展機制與約束語言。
UML的歷史
- 1996年期間，物件管理小組（OMG）發出了第一份提案請求（RFP），這成為促使這些組織合作提出聯合RFP回應的催化劑。
- Rational與數個願意投入資源以制定強大UML 1.0定義的組織共同組成UML合作夥伴聯盟。對UML 1.0定義貢獻最大的包括：
- 數位設備公司
- 惠普
- I-Logix
- IntelliCorp
- IBM
- ICON Computing
- MCI Systemhouse
- Microsoft
- Oracle
- Rational Software
- 德州儀器
- Unisys
- 此合作產生了 UML 1.0，一種定義明確、表達力強、功能強大且通用的建模語言。它於 1997 年 1 月作為最初的 RFP 回應提交給 OMG。
- 1997 年 1 月，IBM、ObjecTime、Platinum Technology、Ptech、Taskon、Reich Technologies 和 Softeam 也分別向 OMG 提交了 RFP 回應。這些公司加入 UML 合作夥伴，貢獻其想法，合作夥伴共同制定了更新的 UML 1.1 回應。UML 1.1 重點在於提升 UML 1.0 語義的清晰度，並納入新合作夥伴的貢獻。該版本提交給 OMG 進行審查，並於 1997 年秋季被採用。版本從 1.1 逐步發展至 1.5，隨後推出 UML 2.0 至 2.5（目前最新版本為 UML 2.5）。
為什麼使用 UML？
隨著軟體對許多公司的戰略價值不斷提升，產業界尋求能自動化軟體生產、提升品質，同時降低成本與縮短上市時間的技術。這些技術包括元件技術、視覺化程式設計、設計模式與框架。企業也正在尋找方法來管理日益增加的複雜性。特別是，他們意識到需要解決反覆出現的架構問題，例如實體分散、並行性、複製、安全性、負載平衡與容錯能力。此外，萬維網的發展雖然簡化了某些方面，卻也加劇了這些架構問題。統一建模語言（UML）正是為滿足這些需求而設計。
- 為使用者提供一個即用型、具表達力的視覺化建模語言，以開發和交換有意義的模型。
- 提供可擴充性和特殊化機制，以擴展核心概念。
- 獨立於特定的程式語言與開發流程。
- 為理解建模語言提供正式基礎。
- 促進物件導向工具市場的發展。
- 支援更高階的開發概念，例如合作、框架、模式與元件。
- 整合最佳實務。
UML – 概觀
在深入探討 UML 理論之前，讓我們先簡要介紹一些 UML 中的主要概念。
關於 UML，第一件需要注意的事是，有許多不同的圖表（模型）需要適應。原因在於系統可以從許多不同的角度來觀察。軟體開發涉及許多利害關係人。
例如：
- 分析師
- 設計師
- 程式設計師
- 測試人員
- 品質保證
- 客戶
- 技術作者
這些人對系統的不同方面都感興趣，而每個方面都需要不同程度的細節。例如，程式設計師需要理解系統的設計，並能將設計轉換為低階程式碼。相反地，技術作者則關注系統的整體行為，並需要理解產品的功能。UML試圖提供一種足夠具表達力的語言，讓所有利益相關者都能從至少一個UML圖表中受益。
以下是UML 2圖表結構中所顯示的13種圖表的快速概覽：
結構圖顯示系統及其各部分在不同抽象層級與實作層級下的靜態結構，以及它們之間的關聯。結構圖有七種類型：
行為圖顯示系統中物件的動態行為，可描述為一系列隨時間產生的變化。時間。行為圖共有七種類型：
什麼是類別圖？
類別圖是幾乎所有物件導向方法中使用的中心建模技術。該圖描述了系統中物件的類型，以及它們之間存在的各種靜態關係。
關係
有三種重要的主要關係：
- 關聯 – 表示類型實例之間的關係（例如，一個人為公司工作，一家公司擁有多个辦公室）。
- 繼承 – 在物件導向設計中使用的實體關係圖最明顯的新增項目。它與物件導向設計中的繼承有直接對應關係。
- 聚合 – 物件導向設計中的一種物件組合形式。
類圖範例
如需了解更多關於類圖的資訊，請閱讀本文什麼是類圖？
什麼是元件圖？
在統一模型語言中，元件圖描述了元件如何連接以形成更大的元件或軟體系統。它展示了軟體元件及其相依性的架構。這些軟體元件包括執行時期元件、可執行元件，以及原始碼元件。
元件圖範例
如需了解更多關於元件圖的資訊，請閱讀本文什麼是元件圖？
什麼是部署圖？
部署圖有助於模擬物件導向軟體系統的實體面向。它是一種結構圖，顯示系統架構作為軟體實體部署（分佈）至部署目標的結果。實體代表開發過程中產生的實體世界中的具體元素。它以靜態視圖模擬執行時期的設定，並可視化應用程式中實體的分佈。在大多數情況下，它涉及模擬硬體設定以及其上運行的軟體元件。
部署圖範例
如需了解更多關於部署圖的資訊，請閱讀本文什麼是部署圖？
什麼是物件圖？
物件圖是包含物件和資料值的實例圖。靜態物件圖是類圖的一個實例；它顯示系統在某一時刻的詳細狀態快照。差別在於，類圖代表由類及其關係組成的抽象模型，而物件圖則代表某一特定時刻的實例，具有本質上的具體性。物件圖的使用相當有限，主要用於展示資料結構的範例。
類圖與物件圖對照 – 一個範例
有些人可能難以理解 UML 類圖與 UML 物件圖之間的差異，因為它們都包含帶有屬性和彼此連結的命名「矩形方塊」，這使得兩種 UML 圖看起來很相似。有些人甚至認為它們是相同的，因為在 UML 工具中，類圖與物件圖的符號都放在同一個圖形編輯器中——也就是類圖編輯器。
但實際上，類圖與物件圖代表程式碼庫的兩個不同面向。在本文中，我們提供一些關於這兩種 UML 圖的觀點，它們是什麼、有何差異，以及何時應使用它們。
類圖與物件圖之間的關係
你在程式設計時會建立「類別」。例如，在線上銀行系統中，你可能會建立如「使用者」、「帳戶」、「交易」等類別。在教室管理系統中，你可能會建立如「教師」、「學生」、「作業」等類別。每個類別都包含代表該類別特徵與行為的屬性和運算。類圖是一種 UML 圖，可用來視覺化這些類別、它們的屬性、運算以及彼此之間的關係。
UML 物件圖顯示類別的物件實例（在 UML 類圖中繪製）在某一特定狀態下的「外觀」。換句話說，UML 物件圖可視為類別（在 UML 類圖中）在特定狀態下被使用的實例。
如果你不喜歡這些定義，請看看下面的 UML 圖示範例。我相信你會在幾秒內就理解它們的差異。
類圖範例
以下的類圖範例代表兩個類別——使用者與附件。使用者可以上傳多個附件，因此這兩個類別在附件端以多重性為 0…* 的關聯相連。
物件圖範例
以下的物件圖範例顯示當彼得（也就是一位使用者）試圖上傳兩個附件時，User 和 Attachment 類別的物件實例「長什麼樣子」。因此，有兩個待上傳附件的實例規格。
如需了解更多關於物件圖的資訊，請閱讀本文什麼是物件圖？
什麼是套件圖？
套件圖是一種UML結構圖，用於顯示套件及其之間的依賴關係。套件圖可呈現系統的不同視圖，例如多層（也稱為多層）應用程式——多層應用程式模型。
套件圖範例
如需了解更多關於套件圖的資訊，請閱讀本文什麼是套件圖？
什麼是組合結構圖？
組合結構圖是UML 2.0新增的其中一種物件。組合結構圖類似於類圖，是一種主要用於以微觀角度建模系統的元件圖，但其重點在於呈現單一組件的內部結構，而非整個類別。它是一種靜態結構圖，用以顯示類別的內部結構及其所促成的協作關係。
該圖可包含內部組件、介面（用於組件之間互動或類別實例與外部世界互動），以及組件或介面之間的連接器。組合結構是一組在執行時協作以達成某項目的的相互連結元素。每個元素在協作中都有其明確的角色。
組合結構圖範例
如需了解更多關於組合結構圖的資訊，請閱讀本文什麼是組合結構圖？
什麼是範型圖？
透過範型圖，您可以建立領域與平台特定的特殊型態，並定義它們之間的關係。您可透過繪製特殊型態的形狀，並透過以資源為中心的介面，將其與組合或一般化關聯起來。您也可以定義並視覺化特殊型態的標籤值。
範型圖範例
如需了解更多關於範型圖的資訊，請閱讀本文在UML中，什麼是範型圖？
什麼是使用案例圖？
使用案例模型以使用案例的方式描述系統的功能需求。它是系統預期功能（使用案例）及其環境（參與者）的模型。使用案例可讓您將系統所需執行的內容與系統如何滿足這些需求聯繫起來。
將使用案例模型想像成一張菜單，就像你在餐廳看到的那種。透過查看菜單，你可以知道有哪些菜式可供選擇、單一菜式及其價格。你也會知道餐廳提供哪種菜系：義大利、墨西哥、中國等。透過查看菜單，你就能大致了解在該餐廳用餐的整體體驗。菜單實際上是在「模擬」餐廳的行為。
由於它是一種強大的規劃工具，因此使用案例模型會被所有團隊成員在開發週期的各個階段使用。
使用案例圖範例
如需了解更多關於使用案例圖的資訊，請閱讀本文什麼是使用案例圖？
什麼是活動圖？
活動圖是逐步活動與動作的工作流程之圖形化表示，支援選擇、迭代與並行。它描述目標系統的控制流程，例如探索複雜的商業規則與操作、描述使用案例與商業流程。在統一模型語言中，活動圖旨在模擬計算與組織流程（即工作流程）。
活動圖範例
如需了解更多關於活動圖的資訊，請閱讀本文什麼是活動圖？
什麼是狀態機圖？
狀態圖是一種在UML中用於根據大衛·哈爾的狀態圖概念描述系統行為的圖表類型。狀態圖顯示允許的狀態和轉移，以及影響這些轉移的事件。它有助於可視化物件的整個生命週期，從而幫助更好地理解基於狀態的系統。
狀態機圖範例
如需了解更多關於狀態機圖的資訊，請閱讀本文什麼是狀態機圖？
什麼是順序圖？
順序圖根據時間順序模擬物件之間的協作。它顯示物件在特定使用案例情境中如何相互互動。借助先進的視覺化建模功能，您只需點幾下即可建立複雜的順序圖。此外，某些建模工具（例如Visual Paradigm）可根據您在使用案例描述中定義的事件流程生成順序圖。
順序圖範例
如需了解更多關於順序圖的資訊，請閱讀本文什麼是順序圖？
什麼是通訊圖？
與順序圖類似，通訊圖也用於模擬使用案例的動態行為。與順序圖相比，通訊圖更著重於展示物件之間的協作，而非時間順序。它們在語義上是等價的，因此某些建模工具（例如Visual Paradigm）允許您從一個圖生成另一個圖。
通訊圖範例
如需了解更多關於通訊圖的資訊，請閱讀本文什麼是通訊圖？
什麼是互動概觀圖？
互動概觀圖專注於互動控制流程的整體概觀。它是活動圖的一種變體，其中節點為互動或互動發生。互動概觀圖描述了隱藏訊息和生命線的互動。您可以在互動概觀圖中連結至「真實」圖表，從而實現圖表間的高導航性。
互動概觀圖範例
如需了解更多關於互動概觀圖的資訊，請閱讀本文什麼是互動概觀圖？
什麼是時序圖？
時序圖顯示物件在一段給定時間內的行為。時序圖是順序圖的一種特殊形式。時序圖與順序圖的差別在於座標軸是反向的，因此時間從左向右增加，生命線則以垂直排列的獨立區隔顯示。
時序圖範例
如需了解更多關於時序圖的資訊，請閱讀本文什麼是時序圖？
學習UML。繪製UML。
取得Visual Paradigm社群版——一款免費的UML工具，可幫助您更快、更有效地學習UML。Visual Paradigm社群版支援所有UML圖表類型。其獲獎的UML建模工具直覺且易於使用。
UML詞彙與術語
- 抽象類別 – 一個永遠不會被實例化的類別。此類別從不存在任何實例。
- 角色 – 一個啟動與系統相關事件的物件或人。
- 活動：活動圖中的一個步驟或動作。代表系統或角色執行的操作。
- 活動圖：一種升級版的流程圖，用以顯示流程中的步驟與決策，以及並行操作，例如演算法或商業流程。
- 聚合 – 是另一個類別的一部分。在圖中以空心菱形標示於包含類別旁邊。
- 工件 – 描述設計過程中某一步驟輸出的文件。描述內容可以是圖形、文字，或兩者的組合。
- 關聯 – 模型中兩個元素之間的連接。這可能代表程式碼中的成員變數、人員記錄與其所代表的人之間的關聯、兩類工作者之間的關係，或任何類似的關係。預設情況下，關聯中的兩個元素彼此皆知且地位相等。關聯也可以是可導航的關聯，表示源端知道目標端，但反之則不然。
- 關聯類別：一個代表兩個其他類別之間關聯並為其添加資訊的類別。
- 屬性 – 物件的一種特徵，可用來參考其他物件或儲存物件狀態的資訊。
- 基底類別：透過泛化關係，定義子類別所繼承的屬性和操作的類別。
- 分支：活動圖中的一個決策點。多個轉移從分支產生，每個都帶有守衛條件。當控制到達分支時，必須恰好有一個守衛條件為真，控制將遵循對應的轉移。
- 類別：一類相似物件，皆由相同的屬性和操作描述，且全部可相容指派。
- 類別圖 – 顯示系統中的類別及其之間的關係。
- 分類器：具有屬性和操作的UML元素。具體而言，包括角色、類別與介面。
- 合作：通訊圖中兩個物件之間的關係，表示訊息可以在物件之間互相傳遞。
- 通訊圖 – 一種顯示操作如何完成的圖表，同時強調物件的角色。
- 組件：系統中可部署的程式碼單元。
- 組件圖：顯示各種組件與介面之間關係的圖示。
- 概念 – 需包含在領域模型中的名詞或抽象概念。
- 建構階段 – Rational統一過程的第三階段，在此階段於建構的系統中建立多個功能迭代。這正是大部分工作的進行階段。
- 依賴：表示一個分類器了解另一個分類器的屬性和操作，但並未直接與第二個分類器的任何實例連接的關係。
- 部署圖：顯示各種處理器之間關係的圖示。
- 領域 – 系統所涉及的論述宇宙部分。
- 精化階段 – Rational統一過程的第二階段，允許進行額外的專案規劃，包括建構階段的迭代。
- 元素：模型中顯示的任何項目。
- 封裝 – 物件內的資料是私有的。
- 泛化 – 表示一個類別是另一個類別（超類別）的子類別。空心箭頭指向超類別。
- 事件：在狀態圖中，這代表會導致系統採取行動或改變狀態的訊號、事件或輸入。
- 終止狀態：在狀態圖或活動圖中，這代表圖示完成的點。
- 分叉：活動圖中多個平行控制流程開始的點。
- 泛化：一種繼承關係，其中子類別繼承並擴展基類的屬性和操作。
- GoF – 四人組設計模式。
- 高內聚 – 一種 GRASP 評估模式，確保類別不會過於複雜，也不執行不相關的功能。
- 低耦合 – 一種 GRASP 評估模式，用於衡量一個類別對另一個類別的依賴程度或連結程度。
- 啟動階段 – Rational Unified Process 的第一個階段，處理初步概念化以及專案的啟動。
- 繼承 – 子類別從其父類別（超類別）繼承屬性或特徵。這些屬性可以在子類別中被覆蓋。
- 初始狀態：在狀態圖或活動圖中，這代表圖的起始點。
- 實例 – 物件是類別的一個實例。類別如同建立物件的範本。可以建立任意數量的該類別實例。
- 介面：一種分類器，定義形成行為合約的屬性和操作。提供者類別或組件可選擇實作該介面（即實作其屬性和操作）。客戶端類別或組件便可依賴該介面，從而使用提供者，而無需了解實際提供者類別的任何細節。
- 迭代 – 專案中的一小部分，用於加入某些小功能。包含分析、設計和編碼的開發週期。
- 合併：活動圖中多個平行控制流程同步並重新結合的點。
- 成員：分類器中的屬性或操作。
- 合併：活動圖中不同控制路徑匯集的點。
- 訊息 – 一個物件向另一個物件提出的請求，要求接收物件執行某項操作。這本質上是對接收物件中方法的呼叫。
- 方法 – 物件中的函式或程序。
- 模型 – 核心的 UML 資產。由各種元素組成，以層次結構排列，元素之間具有相互關係。
- 多重性 – 顯示在領域模型中外部概念框旁邊，表示物件與其他物件之間的數量關係。
- 導航：表示關係的哪一端知道另一端。關係可以具有雙向導航（雙方互相知道）或單向導航（僅一端知道另一端，反之則不然）。
- 符號 – 用於建立分析與設計方法的圖形化文件，並附有規則。
- 註解：附加於圖表上的文字註解，用以更詳細地說明圖表內容。
- 物件 – 在活動圖中，指接收來自或提供資訊給活動的物件。在合作圖或序列圖中，指參與圖中所描述情境的物件。一般而言：某個分類器（角色、類別或介面）的實例或範例。
- 套件 – 一組在邏輯上屬於同一類的UML元素。
- 套件圖：所有元素皆為套件與依賴關係的類別圖。
- 模式 – 解決物件互動責任分配問題的解決方案。是一種針對常見且廣為人知問題的命名解決方案。
- 參數：某項操作的參數。
- 多型 – 相同訊息，不同方法。亦可作為一種模式使用。
- 私有：應用於屬性或操作的可見性層級，表示僅包含該成員的分類器內的程式碼才能存取此成員。
- 處理器：在部署圖中，代表可部署程式碼的電腦或其他可程式化裝置。
- 保護：應用於屬性或操作的可見性層級，表示僅包含該成員的分類器或其子類別內的程式碼才能存取此成員。
- 公開：應用於屬性或操作的可見性層級，表示任何程式碼皆可存取此成員。
- 閱讀方向箭頭 – 表示領域模型中關係的方向。
- 實現：表示元件或類別提供特定介面。
- 角色：在領域模型中使用，是關於實體所扮演角色的選擇性描述。
- 序列圖：顯示物件在時間中存在狀態，以及物件之間傳遞訊息以執行某種行為的圖形。狀態圖 – 顯示物件所有可能狀態的圖形。
- 狀態：在狀態圖中，這代表系統或子系統的某種條件或狀態：在某一時刻正在執行的動作及其資料值。
- 狀態圖：顯示系統或子系統的狀態、狀態之間的轉移，以及引發轉移的事件的圖形。
- 靜態：應用於屬性時，表示該屬性僅有一個副本，由分類器的所有實例共享。應用於運算時，表示該運算獨立於特定實例，不作用於分類器的特定實例。
- 立體圖示：應用於模型元素時，表示無法通常以UML表達的事物。基本上，立體圖示允許您定義自己的「UML方言」。
- 子類別：透過泛化關係繼承超類別所定義的屬性和運算的類別。
- 泳道：活動圖中的一個元素，表示系統或領域中負責特定活動的部分。泳道中的所有活動皆由泳道所代表的物件、組件或參與者負責。
- 時間區塊：每次迭代都有固定的時間限制與明確目標。
- 轉移：在活動圖中，這代表從一個活動、分支、合併、分支或匯集到另一個的控制流程。在狀態圖中，這代表從一個狀態轉移到另一個狀態的變化。
- 轉移階段：理性統一流程的最後階段，使用者在此階段接受訓練以使用新系統，且系統在此時對使用者開放。
- UML：統一模型語言透過文字與圖形文件，使物件之間的關係更緊密，進而提升軟體專案的分析與設計。
- 使用案例：在使用案例圖中，這代表系統對參與者某項請求所採取的動作。
- 使用案例圖：顯示參與者與使用案例之間關係的圖形。
- 可見性：用於屬性或操作的修飾符，表示哪些程式碼可以存取成員。可見性層級包括公開、保護和私有。
- 工作流程 – 一組產生特定結果的活動。
熱門的UML書籍
以下是一些暢銷的UML書籍，您可以閱讀以學習UML：
- UML精要：標準物件模型語言簡明指南
- UML 2與統一過程：實用的物件導向分析與設計
- 學習UML 2.0
- 使用UML建構Web應用程式
- 統一模型語言參考手冊
- UML™ 2.0風格要點
- 適用於Java程式設計師的UML
- Schaum’s UML概要
- 統一模型語言使用者指南
- UML 2認證指南：基礎與進階考試
- UML中的物件導向設計基礎
- 運用用例驅動的UML物件模型：一個帶註解的電子商務範例
- 使用UML設計彈性物件導向系統
- 用例驅動的UML物件模型
- 使用UML 2.0的系統分析與設計：物件導向方法
- UML 2.0速成
- 應用於物件導向分析與設計
- UML解析
- 設計模式：可重用物件導向軟體的要素
- 物件入門：使用UML 2.0的敏捷模型驅動開發
相關連結
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish