解析UML的要點與應用

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種視圖，各視圖在靜態和動態方面表示了系統的模型。

用況視圖由用況圖組成，描述可被最終用戶、分析人員和測試者看到的系統行為；設計視圖包含類圖、對象圖、交互圖、狀態圖和活動圖，主要反映系統的功能需求；進程視圖包含類圖、對象圖、交互圖、狀態圖和活動圖，主要描述形成系統并發與同步機制的線程和進程；實現視圖包含構件圖、交互圖、狀態圖和活動圖，反映用于裝配與發布物理系統的構件和文件，主要針對系統發布的配置管理，可以用各種方法裝配它們。部署視圖包含部署圖、交互圖、狀態圖和活動圖，主要描述對組成物理系統的部件的分布、交付和安裝。根據實際需要，可以組合使用這些視圖。

由視圖可以定義模型，模型在語義上是閉合的，它從特定的角度（系統的規約或者設計）在一定抽象層次上描述目標系統?？梢园岩晥D組織成模型，開發人員可從各視角觀察使用模型。

用以描述系統的模型可以是結構性的，強調系統的組織；也可以是行為性的，強調系統的動態方面。例如，RUP有9種模型，分別是業務模型、領域模型、用況模型（也稱需求模型）、分析模型、設計模型、過程模型、部署模型、實現模型和測試模型，用于從不同的角度表示系統。

系統是一組反映不同側面的子系統的集合，為了完成特定的目的要對這些子系統進行組織（在邏輯、功能和物理位置上是高內聚、低耦合的）。

子系統是一組元素的聚集，其中的元素還可以是子系統。它由一組模型從不同的角度進行描述。子系統本身幾乎應是獨立的，有自己應用的環境，相互間不重疊，它們之間用接口聯系。

UML的概念模型

為了理解UML，需要掌握UML的概念模型，這要求學習三個要素：UML的基本構造塊、支配這些構造塊如何放在一起的規則和一些運用于整個UML的機制，下面逐一予以介紹。

1. 基本構造塊

UML中有三種基本構造塊，分別是事物、關系和圖。

事物分結構事物（包括類、接口、協作、用況、主動類、構件和節點）、行為事物（包括交互和狀態機）、分組事物（包）和注釋事物（注解）。

UML中有四種關系，分別是依賴、關聯、泛化和實現關系。

對于上述兩種構造塊，通過研讀相應的書籍，絕大多數不難掌握，這里就不再贅述。下面對UML中的圖的要點進行闡述。

類圖 類圖展示了一組類、接口和協作及它們間的關系，在建模中所建立的最常見的圖就是類圖。用類圖說明系統的靜態設計視圖，包含主動類的類圖——專注于系統的靜態進程視圖。系統可有多個類圖，單個類圖僅表達了系統的一個方面。要在高層給出類的主要職責，在低層給出類的屬性和操作。

對象圖 對象圖展示了一組對象及它們間的關系。用對象圖說明類圖中所反應的事物實例的數據結構和靜態快照。對象圖表達了系統的靜態設計視圖或靜態過程視圖，除了現實和原型的方面的因素外，它與類圖作用是相同的。

用況圖 用況圖展現了一組用況、參與者以及它們間的關系?？梢杂糜脹r圖描述系統的靜態使用情況。在對系統行為組織和建模方面，用況圖的是相當重要的。

交互圖 交互圖展現了按一定的目的進行的一種交互，它由在一個上下文中的一組對象及它們間交互的信息組成。交互圖也可用于描述一個用況的行為。順序圖和協作圖都是交互圖，順序圖和協作圖可以相互轉換。

順序圖　展現了一組對象和由這組對象收發的消息，用于按時間順序對控制流建模。用順序圖說明系統的動態視圖。

協作圖　展現了一組對象，這組對象間的連接以及這組對象收發的消息。它強調收發消息的對象的結構組織，按組織結構對控制流建模。

狀態圖　展示了一個特定對象的所有可能狀態以及由于各種事件的發生而引起的狀態間的轉移。一個狀態圖描述了一個狀態機，用狀態圖說明系統的動態視圖。它對于接口、類或協作的行為建模尤為重要，可用它描述用況實例的生命周期。

活動圖　活動圖是一種特殊的狀態圖，描述需要做的活動、執行這些活動的順序（多為并行的）以及工作流（完成工作所需要的步驟）。它對于系統的功能建模特別重要，強調對象間的控制流程。

高層活動圖用于表示需要完成的一些任務，即用于分析用況，理解涉及多個用況的工作流、多線程及并行，顯示相互聯系的行為整體，還可用于對企業過程建模，對系統的功能建模。低層活動圖用于表示類的方法。但活動圖不適用于描述動作與對象間的關系，顯示對象間的合作以及顯示對象在生命周期內的運轉情況。

構件圖　構件圖展現了一組構件之間的組織和依賴，用于對原代碼、可執行的發布、物理數據庫和可調整的系統建模。

部署圖　部署圖展現了對運行時處理節點以及其中構件的配署。它描述系統硬件的物理拓撲結構(包括網絡布局和構件在網絡上的位置)，以及在此結構上執行的軟件（即運行時軟構件在節點中的分布情況）。用部署圖說明系統結構的靜態部署視圖，即說明分布、交付和安裝的物理系統。

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是一種建模語言，不是一種方法，它獨立于過程。利于它建模時，可遵循任何類型的建模過程。該建模語言的作者們給出了一種推薦性的建模過程指導，即RUP。本部分闡述RUP如何支持UML的應用。RUP是以用況為驅動、體系結構為中心、迭代和增量的過程。RUP包括四個階段，每個階段又分為若干次迭代，每次迭代都有一個核心工作流（包括5個活動）。

用況驅動旨在為到最終產品為止的每個階段都可以回溯到用戶的真正需求。以體系結構為中心是指關注體系結構模式的開發，以引導后續系統，保證系統的平滑演進。每一次迭代包括迭代計劃、迭代評價和一些具體活動。關于核心工作流中的五個活動：需求、分析、設計、實現和測試較好理解，這里不再贅述。下面對RUP的四個階段要做的工作做一闡述。

本階段確定所設立的項目是否可行，具體要做如下工作：對需求有一個大概的了解，確定系統中的大多數角色和用況，但此時的用況是簡要的。對給出的系統體系結構的概貌，細化到主要子系統即可。識別影響項目可行性的風險?？紤]時間、經費、技術、項目規模和效益等因素。關注業務情況，制訂出開發計劃。識別出剩余的大多數用況。對當前迭代的每個用況進行細化，分析用況的處理流程、狀態細節以及可能發生的狀態改變。細化流程時，可以使用程序框圖和合作圖，還可以使用活動圖、類圖分析用況?？紤]項目的目標是否偏離了用戶的需求。為解決需求風險要充分了解用戶需求以及各需求的優先度，還應盡量列出所有的用況，至少列出重要的用況，并要建立領域的概念模型?？疾焖x的技術方案是否可行。建立原型是解決技術風險的一種有效方法?？紤]實施項目的人員素質能否勝任項目的要求?？紤]政策性的因素對項目的影響。

● 進行高層分析和設計，并作出結構性決策。所產生的基線體系結構包括用況列表、領域概念模型和技術平臺等。以后的階段對細化階段建立的體系結構不能進行過大的變動。

● 為構造階段制訂計劃。細化階段完成，意味著已經完成了如下的任務：用況完全細化并被用戶接受；完成概念驗證；完成類圖；開發人員能給出項目估算（可分為精確、人月和無法估算）；基于用況考慮了所有風險（可分為高風險、可能的風險和不可能的風險），并制訂了相應的對策和計劃；對用況標出優先級（可分為必須先實現、短期內實現和長期實現）。識別出剩余的用況。每一次迭代開發都針對用況進行分析、設計、編碼（如類聲明、屬性聲明、范圍聲明、函數原型聲明和繼承的聲明等）、測試和集成過程，所得到產品滿足項目需求的一個子集。

由于細化階段的軟件設計已經完成，這樣各項目組可以并發開發。在代碼完成后，要保證其符合標準和設計規則，并要進行質量檢查。對于新出現的變化，要通過逆向工具把代碼轉換為模型，對模型進行修改，再重新產生代碼，以保證軟件與模型同步。此階段要建立類圖、交互圖和配置圖；如一個類具有復雜的生命周期，可繪制狀態圖；如算法特別復雜，可繪制活動圖。這一階段完成最后的軟件產品和最后的驗收測試，并完成用戶文檔編制以及用戶培訓等工作?？梢哉f，UML對系統模型的表達能力超出了以往任何一種面向對象的分析和設計方法。隨之出現的問題是，它的復雜性也超出了以往任何一種方法。

由于UML的復雜性，對它的掌握和使用確實不是一件輕松的事。建議對UML掌握和使用本著由簡至難的原則，即熟練掌握基本的概念與表示法后，再學習使用UML的更深入部分。UML的三位創始人所著述的《The Unified Modeling language》也是這樣組織內容的。關于UML的作者所推薦的過程指導，請閱讀他們著述的《The Unified Software Development Process》。此外北京大學也推出了一套青鳥面向對象軟件開發規范，其中包括有一套很完整的過程指導。(責任編輯：銘銘)