UML(Unified Modeling Language)夥伴組織於1996年由Rational公司創立。對象管理組織（OMG）於1997年11月採納了它。此後，UML繼續改進，目前最 新的版本是UML1.3。 UML是多種方法相互借鑑、相互融合、趨於一致、走向標準化的產物。這樣的統一建模語言將爲軟件開發商及其用戶帶來諸多便利。美國等計算機技術發達國家已 有大量的軟件開發組織開始用UML進行系統建模，學習和使用UML已經成爲一種潮流。我國軟件界對UML 也相當關注，許多研究人員和技術人員已在幾年前就開始了對UML的學習和研究。
-- --現在有更多的人想學習UML，但由於UML的複雜性，僅通過UML的標準文獻和國內目前的關於UML的資料來掌握使用它不是一件輕鬆的事。對它的使 用，關鍵是要用它簡明準確地建立模型。這樣，人們就可以從全局把握複雜系統的全貌及其組成間的聯繫。爲了達到這樣的目的，本文要闡明UML的要點，並對 UML所推薦的軟件建模過程RUP（Rational Unified Process）做一簡介，以作爲一種應用UML的過程指導。
-- --UML的定義有兩個主要組成部分：語義和表示法。UML 的語義用自然語言描述，表示法定義了UML的可視化標準表示符號，這決定了UML是一種可視化的建模語言。這些圖形符號和文字用於建立應用級的模型，在語 義上，模型是元模型的實例。此外UML的定義還給出了語法結構的精確規約。對於一般建模者，應重點掌握基本的概念與表示法，並熟練運用它們，建立元模型則 是研究方法學的人的研究重點。
----要點：對系統的組織
----UML是一種可視化的建模語言，對其各建模元素 可進行詳細說明，並能生成所建模型的文檔。使用UML時，要從不同的角度觀察系統，爲此定義了一個概念“視圖”。視圖是對系統的模型在某方面的投影，注重 於系統的某個方面。每個視圖是圖的協作，UML定義了9種圖。下表是UML中的5種視圖，各視圖在靜態和動態方面表示了系統的模型。
-- --用況視圖由用況圖組成，描述可被最終用戶、分析人員和測試者看到的系統行爲；設計視圖包含類圖、對象圖、交互圖、狀態圖和活動圖，主要反映系統的功能 需求；進程視圖包含類圖、對象圖、交互圖、狀態圖和活動圖，主要描述形成系統併發與同步機制的線程和進程；實現視圖包含構件圖、交互圖、狀態圖和活動圖， 反映用於裝配與發佈物理系統的構件和文件，主要針對系統發佈的配置管理，可以用各種方法裝配它們。部署視圖包含部署圖、交互圖、狀態圖和活動圖，主要描述 對組成物理系統的部件的分佈、交付和安裝。根據實際需要，可以組合使用這些視圖。
----由視圖可以定義模型，模型在語義上是閉合的，它從特定的角度（系統的規約或者設計）在一定抽象層次上描述目標系統。可以把視圖組織成模型，開發人員可從各視角觀察使用模型。
-- --用以描述系統的模型可以是結構性的，強調系統的組織；也可以是行爲性的，強調系統的動態方面。例如，RUP有9種模型，分別是業務模型、領域模型、用 況模型（也稱需求模型）、分析模型、設計模型、過程模型、部署模型、實現模型和測試模型，用於從不同的角度表示系統。
----系統是一組反映不同側面的子系統的集合，爲了完成特定的目的要對這些子系統進行組織（在邏輯、功能和物理位置上是高內聚、低耦合的）。
----子系統是一組元素的聚集，其中的元素還可以是子系統。它由一組模型從不同的角度進行描述。子系統本身幾乎應是獨立的，有自己應用的環境，相互間不重疊，它們之間用接口聯繫。
UML的概念模型
----爲了理解UML，需要掌握UML的概念模型，這要求學習三個要素：UML的基本構造塊、支配這些構造塊如何放在一起的規則和一些運用於整個UML的機制，下面逐一予以介紹。
----1. 基本構造塊
----UML中有三種基本構造塊，分別是事物、關係和圖。
----事物分結構事物（包括類、接口、協作、用況、主動類、構件和節點）、行爲事物（包括交互和狀態機）、分組事物（包）和註釋事物（註解）。
----UML中有四種關係，分別是依賴、關聯、泛化和實現關係。
----對於上述兩種構造塊，通過研讀相應的書籍，絕大多數不難掌握，這裏就不再贅述。下面對UML中的圖的要點進行闡述。
-- --類圖 類圖展示了一組類、接口和協作及它們間的關係，在建模中所建立的最常見的圖就是類圖。用類圖說明系統的靜態設計視圖，包含主動類的類圖——專注於系統的靜 態進程視圖。系統可有多個類圖，單個類圖僅表達了系統的一個方面。要在高層給出類的主要職責，在低層給出類的屬性和操作。
----對象圖 對象圖展示了一組對象及它們間的關係。用對象圖說明類圖中所反應的事物實例的數據結構和靜態快照。對象圖表達了系統的靜態設計視圖或靜態過程視圖，除了現實和原型的方面的因素外，它與類圖作用是相同的。
----用況圖 用況圖展現了一組用況、參與者以及它們間的關係。可以用用況圖描述系統的靜態使用情況。在對系統行爲組織和建模方面，用況圖的是相當重要的。
----交互圖 交互圖展現了按一定的目的進行的一種交互，它由在一個上下文中的一組對象及它們間交互的信息組成。交互圖也可用於描述一個用況的行爲。順序圖和協作圖都是交互圖，順序圖和協作圖可以相互轉換。
----順序圖 展現了一組對象和由這組對象收發的消息，用於按時間順序對控制流建模。用順序圖說明系統的動態視圖。
----協作圖 展現了一組對象，這組對象間的連接以及這組對象收發的消息。它強調收發消息的對象的結構組織，按組織結構對控制流建模。
----狀態圖 展示了一個特定對象的所有可能狀態以及由於各種事件的發生而引起的狀態間的轉移。一個狀態圖描述了一個狀態機，用狀態圖說明系統的動態視圖。它對於接口、類或協作的行爲建模尤爲重要，可用它描述用況實例的生命週期。
----活動圖 活動圖是一種特殊的狀態圖，描述需要做的活動、執行這些活動的順序（多爲並行的）以及工作流（完成工作所需要的步驟）。它對於系統的功能建模特別重要，強調對象間的控制流程。
-- --高層活動圖用於表示需要完成的一些任務，即用於分析用況，理解涉及多個用況的工作流、多線程及並行，顯示相互聯繫的行爲整體，還可用於對企業過程建 模，對系統的功能建模。低層活動圖用於表示類的方法。但活動圖不適用於描述動作與對象間的關係，顯示對象間的合作以及顯示對象在生命週期內的運轉情況。
----構件圖 構件圖展現了一組構件之間的組織和依賴，用於對原代碼、可執行的發佈、物理數據庫和可調整的系統建模。
-- --部署圖 部署圖展現了對運行時處理節點以及其中構件的配署。它描述系統硬件的物理拓撲結構(包括網絡佈局和構件在網絡上的位置)，以及在此結構上執行 的軟件（即運行時軟構件在節點中的分佈情況）。用部署圖說明系統結構的靜態部署視圖，即說明分佈、交付和安裝的物理系統。
----2. 運用構造塊的規則
-- --UML用於描述事物的語義規則分別是：爲事物、關係和圖命名；給一個名字以特定含義的語境，即範圍；怎樣使用或看見名字，即可見性；事物如何正確、一 致地相互聯繫，即完整性；運行或模擬動態模型的含義是什麼，即執行。另外， UML還允許在一定的階段隱藏模型的某些元素、遺漏某些元素以及不保證模型的完整性，但模型逐步地要達到完整和一致。
----3. 機制
----有四種在整個語言中一致應用的機制，使得該語言變得較爲簡單。這四種機制是詳細說明、修飾、通用劃分和擴展機制。
----UML不只是一種圖形語言。實際上，在它的圖形表示法的每部分背後都有一個詳細說明，提供了對構造塊的語法和語義的文字敘述。
----UML表示法中的每一個元素都有一個基本符號，這些圖形符號對元素的最重要的方面提供了可視化表示，對元素的描述還包含其他細節。例如，一個類是否是抽象類，或它的屬性和操作是否可見。要把這樣的修飾細節加到基本符號上。
----在對面向對象的系統建模中，至少有兩種通用的劃分世界的方法：對類和對象的劃分；對接口和實現的劃分。UML中的構造塊幾乎都存在着這樣的兩分法。
----UML是開放的，可用一種受限的方法擴展它。UML的擴展機制包括構造型、標記值和約束。
----UML的應用
----UML是一種建模語言，不是一種方法，它獨立於過程。利於它建模時，可遵循任何類型的建模過程。該建模語言的作者們給出了一種推薦性的建模過程指導，即RUP。本部分闡述RUP如何支持UML的應用。
----RUP是以用況爲驅動、體系結構爲中心、迭代和增量的過程。RUP包括四個階段，每個階段又分爲若干次迭代，每次迭代都有一個核心工作流（包括5個活動），請參見下圖。
-- --用況驅動旨在爲到最終產品爲止的每個階段都可以回溯到用戶的真正需求。以體系結構爲中心是指關注體系結構模式的開發，以引導後續系統，保證系統的平滑 演進。每一次迭代包括迭代計劃、迭代評價和一些具體活動。關於核心工作流中的五個活動：需求、分析、設計、實現和測試較好理解，這裏不再贅述。下面對 RUP的四個階段要做的工作做一闡述。
----1. 初始階段
----本階段確定所設立的項目是否可行，具體要做如下工作：
對需求有一個大概的瞭解，確定系統中的大多數角色和用況，但此時的用況是簡要的。對給出的系統體系結構的概貌，細化到主要子系統即可。
識別影響項目可行性的風險。
考慮時間、經費、技術、項目規模和效益等因素。
關注業務情況，制訂出開發計劃。
----2. 細化階段
識別出剩餘的大多數用況。對當前迭代的每個用況進行細化，分析用況的處理流程、狀態細節以及可能發生的狀態改變。細化流程時，可以使用程序框圖和合作圖，還可以使用活動圖、類圖分析用況。
對風險的處理。
----需求風險 考慮項目的目標是否偏離了用戶的需求。爲解決需求風險要充分了解用戶需求以及各需求的優先度，還應儘量列出所有的用況，至少列出重要的用況，並要建立領域的概念模型。
----技術風險 考察所選的技術方案是否可行。建立原型是解決技術風險的一種有效方法。
----技能風險 考慮實施項目的人員素質能否勝任項目的要求。
----政策風險 考慮政策性的因素對項目的影響。
----● 進行高層分析和設計，並作出結構性決策。
----所產生的基線體系結構包括用況列表、領域概念模型和技術平臺等。以後的階段對細化階段建立的體系結構不能進行過大的變動。
----● 爲構造階段制訂計劃。
-- --細化階段完成，意味着已經完成了如下的任務：用況完全細化並被用戶接受；完成概念驗證；完成類圖；開發人員能給出項目估算（可分爲精確、人月和無法估 算）；基於用況考慮了所有風險（可分爲高風險、可能的風險和不可能的風險），並制訂了相應的對策和計劃；對用況標出優先級（可分爲必須先實現、短期內實現 和長期實現）。
----3. 構造階段
----識別出剩餘的用況。每一次迭代開發都針對用況進行分析、設計、編碼（如類聲明、屬性聲明、範圍聲明、函數原型聲明和繼承的聲明等）、測試和集成過程，所得到產品滿足項目需求的一個子集。由於細化階段的軟件設計已經完成，這樣各項目組可以併發開發。
----在代碼完成後，要保證其符合標準和設計規則，並要進行質量檢查。對於新出現的變化，要通過逆向工具把代碼轉換爲模型，對模型進行修改，再重新產生代碼，以保證軟件與模型同步。
----此階段要建立類圖、交互圖和配置圖；如一個類具有複雜的生命週期，可繪製狀態圖；如算法特別複雜，可繪製活動圖。
----4. 移交階段
----這一階段完成最後的軟件產品和最後的驗收測試，並完成用戶文檔編制以及用戶培訓等工作。
結束語
-- --可以說，UML對系統模型的表達能力超出了以往任何一種面向對象的分析和設計方法。隨之出現的問題是，它的複雜性也超出了以往任何一種方法。由於 UML的複雜性，對它的掌握和使用確實不是一件輕鬆的事。建議對UML掌握和使用本着由簡至難的原則，即熟練掌握基本的概念與表示法後，再學習使用UML 的更深入部分。UML的三位創始人所著述的《The Unified Modeling language》也是這樣組織內容的。關於UML的作者所推薦的過程指導，請閱讀他們著述的《The Unified Software Development Process》。此外北京大學也推出了一套青鳥面向對象軟件開發規範，其中包括有一套很完整的過程指導。
-- --現在有更多的人想學習UML，但由於UML的複雜性，僅通過UML的標準文獻和國內目前的關於UML的資料來掌握使用它不是一件輕鬆的事。對它的使 用，關鍵是要用它簡明準確地建立模型。這樣，人們就可以從全局把握複雜系統的全貌及其組成間的聯繫。爲了達到這樣的目的，本文要闡明UML的要點，並對 UML所推薦的軟件建模過程RUP（Rational Unified Process）做一簡介，以作爲一種應用UML的過程指導。
-- --UML的定義有兩個主要組成部分：語義和表示法。UML 的語義用自然語言描述，表示法定義了UML的可視化標準表示符號，這決定了UML是一種可視化的建模語言。這些圖形符號和文字用於建立應用級的模型，在語 義上，模型是元模型的實例。此外UML的定義還給出了語法結構的精確規約。對於一般建模者，應重點掌握基本的概念與表示法，並熟練運用它們，建立元模型則 是研究方法學的人的研究重點。
----要點：對系統的組織
----UML是一種可視化的建模語言，對其各建模元素 可進行詳細說明，並能生成所建模型的文檔。使用UML時，要從不同的角度觀察系統，爲此定義了一個概念“視圖”。視圖是對系統的模型在某方面的投影，注重 於系統的某個方面。每個視圖是圖的協作，UML定義了9種圖。下表是UML中的5種視圖，各視圖在靜態和動態方面表示了系統的模型。
-- --用況視圖由用況圖組成，描述可被最終用戶、分析人員和測試者看到的系統行爲；設計視圖包含類圖、對象圖、交互圖、狀態圖和活動圖，主要反映系統的功能 需求；進程視圖包含類圖、對象圖、交互圖、狀態圖和活動圖，主要描述形成系統併發與同步機制的線程和進程；實現視圖包含構件圖、交互圖、狀態圖和活動圖， 反映用於裝配與發佈物理系統的構件和文件，主要針對系統發佈的配置管理，可以用各種方法裝配它們。部署視圖包含部署圖、交互圖、狀態圖和活動圖，主要描述 對組成物理系統的部件的分佈、交付和安裝。根據實際需要，可以組合使用這些視圖。
----由視圖可以定義模型，模型在語義上是閉合的，它從特定的角度（系統的規約或者設計）在一定抽象層次上描述目標系統。可以把視圖組織成模型，開發人員可從各視角觀察使用模型。
-- --用以描述系統的模型可以是結構性的，強調系統的組織；也可以是行爲性的，強調系統的動態方面。例如，RUP有9種模型，分別是業務模型、領域模型、用 況模型（也稱需求模型）、分析模型、設計模型、過程模型、部署模型、實現模型和測試模型，用於從不同的角度表示系統。
----系統是一組反映不同側面的子系統的集合，爲了完成特定的目的要對這些子系統進行組織（在邏輯、功能和物理位置上是高內聚、低耦合的）。
----子系統是一組元素的聚集，其中的元素還可以是子系統。它由一組模型從不同的角度進行描述。子系統本身幾乎應是獨立的，有自己應用的環境，相互間不重疊，它們之間用接口聯繫。
UML的概念模型
----爲了理解UML，需要掌握UML的概念模型，這要求學習三個要素：UML的基本構造塊、支配這些構造塊如何放在一起的規則和一些運用於整個UML的機制，下面逐一予以介紹。
----1. 基本構造塊
----UML中有三種基本構造塊，分別是事物、關係和圖。
----事物分結構事物（包括類、接口、協作、用況、主動類、構件和節點）、行爲事物（包括交互和狀態機）、分組事物（包）和註釋事物（註解）。
----UML中有四種關係，分別是依賴、關聯、泛化和實現關係。
----對於上述兩種構造塊，通過研讀相應的書籍，絕大多數不難掌握，這裏就不再贅述。下面對UML中的圖的要點進行闡述。
-- --類圖 類圖展示了一組類、接口和協作及它們間的關係，在建模中所建立的最常見的圖就是類圖。用類圖說明系統的靜態設計視圖，包含主動類的類圖——專注於系統的靜 態進程視圖。系統可有多個類圖，單個類圖僅表達了系統的一個方面。要在高層給出類的主要職責，在低層給出類的屬性和操作。
----對象圖 對象圖展示了一組對象及它們間的關係。用對象圖說明類圖中所反應的事物實例的數據結構和靜態快照。對象圖表達了系統的靜態設計視圖或靜態過程視圖，除了現實和原型的方面的因素外，它與類圖作用是相同的。
----用況圖 用況圖展現了一組用況、參與者以及它們間的關係。可以用用況圖描述系統的靜態使用情況。在對系統行爲組織和建模方面，用況圖的是相當重要的。
----交互圖 交互圖展現了按一定的目的進行的一種交互，它由在一個上下文中的一組對象及它們間交互的信息組成。交互圖也可用於描述一個用況的行爲。順序圖和協作圖都是交互圖，順序圖和協作圖可以相互轉換。
----順序圖 展現了一組對象和由這組對象收發的消息，用於按時間順序對控制流建模。用順序圖說明系統的動態視圖。
----協作圖 展現了一組對象，這組對象間的連接以及這組對象收發的消息。它強調收發消息的對象的結構組織，按組織結構對控制流建模。
----狀態圖 展示了一個特定對象的所有可能狀態以及由於各種事件的發生而引起的狀態間的轉移。一個狀態圖描述了一個狀態機，用狀態圖說明系統的動態視圖。它對於接口、類或協作的行爲建模尤爲重要，可用它描述用況實例的生命週期。
----活動圖 活動圖是一種特殊的狀態圖，描述需要做的活動、執行這些活動的順序（多爲並行的）以及工作流（完成工作所需要的步驟）。它對於系統的功能建模特別重要，強調對象間的控制流程。
-- --高層活動圖用於表示需要完成的一些任務，即用於分析用況，理解涉及多個用況的工作流、多線程及並行，顯示相互聯繫的行爲整體，還可用於對企業過程建 模，對系統的功能建模。低層活動圖用於表示類的方法。但活動圖不適用於描述動作與對象間的關係，顯示對象間的合作以及顯示對象在生命週期內的運轉情況。
----構件圖 構件圖展現了一組構件之間的組織和依賴，用於對原代碼、可執行的發佈、物理數據庫和可調整的系統建模。
-- --部署圖 部署圖展現了對運行時處理節點以及其中構件的配署。它描述系統硬件的物理拓撲結構(包括網絡佈局和構件在網絡上的位置)，以及在此結構上執行 的軟件（即運行時軟構件在節點中的分佈情況）。用部署圖說明系統結構的靜態部署視圖，即說明分佈、交付和安裝的物理系統。
----2. 運用構造塊的規則
-- --UML用於描述事物的語義規則分別是：爲事物、關係和圖命名；給一個名字以特定含義的語境，即範圍；怎樣使用或看見名字，即可見性；事物如何正確、一 致地相互聯繫，即完整性；運行或模擬動態模型的含義是什麼，即執行。另外， UML還允許在一定的階段隱藏模型的某些元素、遺漏某些元素以及不保證模型的完整性，但模型逐步地要達到完整和一致。
----3. 機制
----有四種在整個語言中一致應用的機制，使得該語言變得較爲簡單。這四種機制是詳細說明、修飾、通用劃分和擴展機制。
----UML不只是一種圖形語言。實際上，在它的圖形表示法的每部分背後都有一個詳細說明，提供了對構造塊的語法和語義的文字敘述。
----UML表示法中的每一個元素都有一個基本符號，這些圖形符號對元素的最重要的方面提供了可視化表示，對元素的描述還包含其他細節。例如，一個類是否是抽象類，或它的屬性和操作是否可見。要把這樣的修飾細節加到基本符號上。
----在對面向對象的系統建模中，至少有兩種通用的劃分世界的方法：對類和對象的劃分；對接口和實現的劃分。UML中的構造塊幾乎都存在着這樣的兩分法。
----UML是開放的，可用一種受限的方法擴展它。UML的擴展機制包括構造型、標記值和約束。
----UML的應用
----UML是一種建模語言，不是一種方法，它獨立於過程。利於它建模時，可遵循任何類型的建模過程。該建模語言的作者們給出了一種推薦性的建模過程指導，即RUP。本部分闡述RUP如何支持UML的應用。
----RUP是以用況爲驅動、體系結構爲中心、迭代和增量的過程。RUP包括四個階段，每個階段又分爲若干次迭代，每次迭代都有一個核心工作流（包括5個活動），請參見下圖。
-- --用況驅動旨在爲到最終產品爲止的每個階段都可以回溯到用戶的真正需求。以體系結構爲中心是指關注體系結構模式的開發，以引導後續系統，保證系統的平滑 演進。每一次迭代包括迭代計劃、迭代評價和一些具體活動。關於核心工作流中的五個活動：需求、分析、設計、實現和測試較好理解，這裏不再贅述。下面對 RUP的四個階段要做的工作做一闡述。
----1. 初始階段
----本階段確定所設立的項目是否可行，具體要做如下工作：
對需求有一個大概的瞭解，確定系統中的大多數角色和用況，但此時的用況是簡要的。對給出的系統體系結構的概貌，細化到主要子系統即可。
識別影響項目可行性的風險。
考慮時間、經費、技術、項目規模和效益等因素。
關注業務情況，制訂出開發計劃。
----2. 細化階段
識別出剩餘的大多數用況。對當前迭代的每個用況進行細化，分析用況的處理流程、狀態細節以及可能發生的狀態改變。細化流程時，可以使用程序框圖和合作圖，還可以使用活動圖、類圖分析用況。
對風險的處理。
----需求風險 考慮項目的目標是否偏離了用戶的需求。爲解決需求風險要充分了解用戶需求以及各需求的優先度，還應儘量列出所有的用況，至少列出重要的用況，並要建立領域的概念模型。
----技術風險 考察所選的技術方案是否可行。建立原型是解決技術風險的一種有效方法。
----技能風險 考慮實施項目的人員素質能否勝任項目的要求。
----政策風險 考慮政策性的因素對項目的影響。
----● 進行高層分析和設計，並作出結構性決策。
----所產生的基線體系結構包括用況列表、領域概念模型和技術平臺等。以後的階段對細化階段建立的體系結構不能進行過大的變動。
----● 爲構造階段制訂計劃。
-- --細化階段完成，意味着已經完成了如下的任務：用況完全細化並被用戶接受；完成概念驗證；完成類圖；開發人員能給出項目估算（可分爲精確、人月和無法估 算）；基於用況考慮了所有風險（可分爲高風險、可能的風險和不可能的風險），並制訂了相應的對策和計劃；對用況標出優先級（可分爲必須先實現、短期內實現 和長期實現）。
----3. 構造階段
----識別出剩餘的用況。每一次迭代開發都針對用況進行分析、設計、編碼（如類聲明、屬性聲明、範圍聲明、函數原型聲明和繼承的聲明等）、測試和集成過程，所得到產品滿足項目需求的一個子集。由於細化階段的軟件設計已經完成，這樣各項目組可以併發開發。
----在代碼完成後，要保證其符合標準和設計規則，並要進行質量檢查。對於新出現的變化，要通過逆向工具把代碼轉換爲模型，對模型進行修改，再重新產生代碼，以保證軟件與模型同步。
----此階段要建立類圖、交互圖和配置圖；如一個類具有複雜的生命週期，可繪製狀態圖；如算法特別複雜，可繪製活動圖。
----4. 移交階段
----這一階段完成最後的軟件產品和最後的驗收測試，並完成用戶文檔編制以及用戶培訓等工作。
結束語
-- --可以說，UML對系統模型的表達能力超出了以往任何一種面向對象的分析和設計方法。隨之出現的問題是，它的複雜性也超出了以往任何一種方法。由於 UML的複雜性，對它的掌握和使用確實不是一件輕鬆的事。建議對UML掌握和使用本着由簡至難的原則，即熟練掌握基本的概念與表示法後，再學習使用UML 的更深入部分。UML的三位創始人所著述的《The Unified Modeling language》也是這樣組織內容的。關於UML的作者所推薦的過程指導，請閱讀他們著述的《The Unified Software Development Process》。此外北京大學也推出了一套青鳥面向對象軟件開發規範，其中包括有一套很完整的過程指導。
