2.4 UML 2概念模型

UML 2規范按照語義結構組織，詳細闡述了各類模型元素的語法結構，然而規范中的介紹面面俱到，普通用戶很多時候只使用那些最常用的屬性，例如圖2-2中有關類結構中的內部類就很少使用。因此，對于普通建模用戶來說，更多的還是從業務角度考慮問題，例如為目標系統建模，需要哪些建模元素、涉及哪些基本概念等。這些核心概念形成了UML的概念模型。開發人員通過概念模型掌握UML建模的基本思想，從而能夠讀懂并建立一些基本模型；當有了豐富的應用UML的經驗時，開發人員就能夠在這些概念模型之上理解UML 2結構，從而使用更深層次的語言特征開展構造工作。

UML概念模型主要由三部分組成：基本的構造塊、運用于這些構造塊的通用機制和組織UML視圖的架構。每個部分又包含不同的子部分，具體的組成結構如圖2-4所示。

2.4.1 構造塊

構造塊（Building Blocks）是指UML的基本建模元素，包括事物（Thing）、關系（Relationship）和圖（Diagram）3個方面的內容。事物是對模型中核心要素的抽象；關系把事物緊密聯系在一起；而圖是由很多相互關聯的事物組成的。

1．事物

在UML中，事物代表了基本的面向對象構造塊，主要包括以下4種類型的事物。

（1）結構事物（Structural Thing）是UML模型中的名詞。它們通常是模型的靜態部分，用于描述概念元素或物理元素。常見的結構事物包括類、接口、用例、協作、構件、工件、節點等。在以后應用的時候，我們會對大部分概念做詳細講解，也可以參考其他UML參考書籍。

（2）行為事物（Behavioral Thing）是UML模型中的動詞。它們是模型的動態部分，代表了跨越時間和空間的行為。常見的行為事物包括交互、狀態機、活動等。

（3）分組事物（Grouping Thing）是UML模型的組織部分，用于將模型元素組織在一起。主要的分組事物是包，還有其他的諸如子系統、層等基于包的擴展事物。

（4）注釋事物（Annotational Thing）是UML模型的解釋部分，用來描述、說明和標注模型的任何元素。最重要的注釋事物就是注解（Note），它是依附于一個元素或一組元素之上對元素進行約束或解釋的簡單符號，所有的UML圖形元素均可以用注解來說明。

2．關系

關系將UML的事物連接起來，構造出結構良好的UML模型。在UML中有4種基本關系：依賴、關聯、泛化和實現。圖2-5列出了這4種關系的圖形表示符號。

（1）依賴（Dependency）是兩個事物間的弱語義關系，表明兩個事物之間存在著一種使用關系，其中一個事物（獨立事物）發生變化會影響另一個事物（依賴事物）的語義。依賴關系的箭頭表明了依賴的方向，即沒有箭頭端的事物依賴于有箭頭端的事物。

（2）關聯（Association）是一種強語義聯系的結構關系，表明兩個事物之間存在著明確的、穩定的語義聯系。它描述了一組鏈接（link），鏈接是事物的具體實例之間的關聯（如類之間的關聯，則意味著類的對象之間存在鏈接）。聚合（Aggregation）是一種特殊類型的關聯，它表明關聯的兩個事物之間還存在一種整體和部分的語義聯系。圖2-5中的關聯關系兩端都沒有標注箭頭，這并不意味著關聯關系沒有方向，默認情況下關聯的方向是雙向的，也就是說，兩個關聯的事物之間互相依賴。如果要標注單方向的依賴，則需要在關聯的一端標注箭頭。有關關聯關系的方向問題，將在第9.3.7小節進行詳細介紹。

（3）泛化（Generalization）是一種特殊—一般關系，特殊元素（子元素）的對象可替代一般元素（父元素）的對象。通過這種關系，子元素共享了父元素的結構和行為（參見第1.4.3小節）。

（4）實現（Realization）是兩個事物之間的一種契約關系，其中的一個事物（箭頭指向的事物）描述了另一個事物必須實現的契約。在兩種位置會遇到實現關系：一種是在接口和實現它們的類或構件之間；另一種是在用例和實現它們的協作之間。

這4種元素是UML模型中可以包含的基本關系事物。它們也有擴展和變體，例如，依賴關系就可以擴展為包含、擴展、精化、跟蹤等關系，而關聯關系還有聚合、組合等變體的形式。

3．圖

在所有UML CASE工具中，當用戶創建了新事物或者新關系時，它們就被加入模型中。模型是所有事物和關系的知識庫，創建模型有助于描述正在設計的軟件系統的所需行為。模型中有很多元素、元素之間有很多關系，這些都需要展示給用戶，這種展示就是通過UML的圖來實現的。

圖（Diagram）是一組元素的圖形表示，它是模型內的視圖，可以通過圖將模型展示給用戶。圖不是模型本身，有的模型元素可以出現在所有圖中，有的模型元素可以出現在一些圖中（很常見），還有的模型元素不能出現在圖中（很少見）。此外，事物或關系可能從圖中被刪除，甚至從所有的圖中被刪除，但是它們仍然可以存在于模型中。

UML 2提供了14種不同類型的圖（UML 1.x中為9種），如圖2-4所示。需要說明的是，此處圖的分類是根據UML 2.5規范的附錄A給出來的。在UML 2.5中還給出了信息流圖（Information Flow Diagram）的元模型，但目前這種圖形并沒有被確定為一種獨立的圖形而放入這個分類中。此外，還有諸如行為狀態機圖、協議狀態機圖、模型圖、內部結構圖等一些現有圖的子圖，這些圖形也都沒有放入分類。因此，本書還是圍繞UML 2之前版本的14種圖來介紹。

針對這14種圖，按照UML 2.5的分類方法可以劃分成兩類：一類描述系統的靜態結構模型；另一類描述系統的動態行為模型。結構模型捕獲事物及事物之間的靜態關系，而行為模型則捕獲事物是如何交互以產生軟件系統所需的行為。有關各類UML圖的使用，我們將在第2.5節中結合具體的案例進行系統的介紹，并且在后續章節中會對一些重要圖形的使用方法進行詳細論述。

2.4.2 通用機制

UML提供了4種通用機制，它們被一致地應用到模型中，描述了達到對象建模目標的4種策略，并在UML的不同語境中被反復運用。這4種機制如下所示。

（1）規格說明（Specifications）：文本維度的模型描述。

（2）修飾（Adornments）：描述建模元素的細節信息。

（3）通用劃分（Common Divisions）：建模時對事物的劃分方法。

（4）擴展機制（Extensibility Mechanisms）：用于擴展UML建模元素，包括構造型、約束和標記值3類機制。

1．規格說明

UML不僅僅是一種圖形語言，實際上，在UML表示法的每部分背后都有一個文本維度的規格說明，這個規格說明提供了對構造塊的語法和語義的文字敘述。例如，在一個類圖符背后就有一個規格說明，它提供了對該類所擁有的屬性、操作（包括完整的特征標記）和行為的全面描述；而在視覺上，類圖符可能僅展示了這個規格說明的一小部分。此外，還可能存在著該類的另一個視圖，其中提供了一個完全不同的部件集合，但是它仍然與該類的基本規格說明相一致。

UML的規格說明承載模型的語義背板，它包含了一個系統的各模型的所有部分，而且各部分相互聯系，并保持一致。因此，UML的圖只不過是對背板的簡單視覺投影，每一個圖展現了系統的一個特定的方面。

使用UML建模，通常是開始于一個主要的圖形模型，它允許用戶可視化系統；然后，隨著模型演化，向背板中加入越來越多的語義。然而，對于任何一個有價值的或者完整的模型，在背板中必須存在模型語義，否則這些圖形僅僅是由線所連接的無意義方框的集合。實際上，新手所犯的常見錯誤可能被稱作“因圖形而死亡”——模型被過度圖形化而沒有文本說明。

2．修飾

UML表示法中的每一個元素都有一個基本符號，可以把各種修飾細節添加到這些符號上。這意味著，能夠僅使用帶有一個或兩個修飾的基本記號來構造非常高級的模型。然后，可以精化模型，添加越來越多的信息，直到模型元素對于目標來說是足夠詳細的。

在使用修飾時，需要注意的是，任何UML圖僅是模型的視圖，只有在修飾增強了圖的整體清晰性和可讀性或者突出模型的某些重要特征時，才應該表示那些修飾。圖2-6展示了一個沒有修飾元素和有部分修飾元素的類。這兩個元素都表示一個Window類，它們內部含義是一樣的，只不過在當前視圖中展示了不同的信息。

3．通用劃分

在對面向對象系統建模中，通常有以下3種對元素進行分類的通用方法。

第一種是類元（Classifier）和實例的劃分。類元表示一種抽象，實例則是這種抽象的一個具體表現。在UML中，很多概念都是基于這種劃分方法建立的，例如，類和對象、用例和場景、構件和構件實例等。

第二種是接口和實現的分離。接口聲明行為的契約（做什么），實現表示對該契約的具體實現細節（如何做）。例如，接口和子系統、用例和用例實現、操作和方法等。

第三種是類型和角色的分離，這是UML 2新增的劃分方法。類型聲明實體的種類（如對象、屬性、參數），而角色描述實體在語境（如類、構件、協作、組合結構）中的含義。任何作為其他實體結構的一部分實體（如屬性）都具有兩個方面的特性：從固有類型派生出來的含義和在語境中的角色派生出來的含義。圖2-7展示了組合結構中的customer對象，作為Person類，customer對象具有Person類所提供的屬性和行為；同時，作為組合結構TickOrder（訂票系統）中的角色，customer是一個訂票的顧客。

4．擴展機制

UML提供了一種繪制軟件藍圖的標準語言，但是不可能簡單地設計一種能滿足現在和將來所有人需要的完全通用的建模語言。為此，UML提供了靈活的擴展機制，可以以受控的方式擴展該語言。UML提供了3種擴展機制。

（1）構造型（Stereotype）：基于已有的建模元素引入新的建模元素。

（2）標記值（Tagged Value）：擴展UML構造型的特性，可以用來創建構造型的詳細信息。

（3）約束（Constraint）：擴展UML構造塊語義，可以用來增加新的規則或修改現有規則。

圖2-8展示了在類EventQueue上添加這3種擴展機制。其中類名前面的“<<authored>>”是構造型（名稱被放在“<< >> ”里面），表明該類不同于其他的類，它具有版權信息（具體的含義在擴展時定義）；信息的細節通過注解框中的標記值來表示；該類的add（）操作添加了{ordered}約束（名稱被放在“{ }”里面），表明在插入數據時需要排序。

構造型是一種應用非常廣泛的擴展機制，而且UML標準自身也提供了一些預定義的構造型。它是建立在UML已定義的模型元素基礎上，其目標是根據模型中的其他元素定義一個新元素。構造型可以用于所有的UML模型元素，如類、關聯、用例、構件等。此外，為了更形象地表示構造型，很多建模工具也以可視化的形式來表示不同的構造型。例如“<<entity>>”構造型，這是一個在分析建模過程中被大家廣泛認可的針對類的擴展概念，表示分析模型中的一個實體類。圖2-9展示了該構造型可能的3種表現形式。其中第一種是標準表示（在類名前面用“<< >> ”表示），第二種是在類的右上角用特殊的圖標表示，第三種是直接采用全新的圖形符號表示。

5．外廓和外廓圖

隨著UML應用的日益廣泛，UML 2標準所定義的元素不一定能夠滿足特定應用場景的需求，為此需要利用擴展機制對UML 2進行擴展或裁減。而在不同的應用領域，可以有不同擴展，例如針對實時嵌入式領域，可以定義一組特定的構造型、元類等，以描述實時、安全、可靠性等一般應用中不需要考慮的特征。這一組擴展機制就形成了UML的外廓。

外廓（Profile）是基于UML元素的子集為特定領域定義UML的一個特定版本，即定義了一組對UML已有模型的擴展和限定機制，以用于某個特定領域。這些擴展和限定機制包括：預定義的構造型、標記值、約束、基類等。外廓是建立在普通的UML元素基礎上，是對UML標準的裁剪和擴展，并不代表一種新的建模語言。針對一些常用的應用領域，OMG推出了一些標準的擴展，如用于實時嵌入式建模的MARTE（UML Profile for Modeling and Analysis of Real-time and Embedded Systems）、用于測試的UML Testing Profile、用于硬件設計的UML Profile for System on a Chip等。

為了便于用戶定義外廓，自UML 2.3起，UML標準新增了外廓圖。外廓圖（Profile Diagram）是一種用于描述UML擴展機制的結構圖。用戶可以針對不同的平臺（如Java EE、.NET等）或領域（如實時嵌入式領域、業務建模領域、測試領域、硬件設計領域等）定義符合UML元模型的擴展內容。表2-1列出了外廓圖中的主要元素及其圖形表示。

為了便于理解外廓圖的應用，下面以擴展UML類圖以用于數據庫建模為例，說明具體的擴展過程。

數據庫建模的核心概念是表、字段和關系等，這些概念在UML標準規范中并沒有定義，無法直接利用UML建模。為此，我們需要通過擴展UML類圖中的相關概念，如可以利用UML類建模表，利用類的屬性建模表的字段，利用類之間的關聯關系來建模實體間的關系。這里，我們利用外廓圖定義了3個構造型MyTable、MyColumn和MyRelationship，分別表示數據庫表、字段和關系，它們各自從UML元類中的類（Class）、屬性（Attribute）和關聯關系（Association）上擴展而來；此外，對于MyColumn構造型，我們還添加了兩個布爾類型的標記值PK和IsNULL，分別表示該字段是否為主鍵（默認值為false）、是否可以為空（默認值為true）。定義這套擴展機制的外廓圖如圖2-10所示。需要說明的是，該圖采用Enterprise Architect繪制，圖中3個擴展的構造型沒有采用表2-1中的標準表示形式（即名稱前面加“<<stereotype>>”的方式），而是采用右上角添加“《》”的方式表示，這是該建模工具所提供的特定圖形符號。

在定義這個用于數據庫建模的外廓后，即可以借助UML類圖進行數據庫建模。圖2-11列出了兩個簡單的數據庫表的建模示例，這是一個UML類圖，但通過前面定義的3個構造型即可以進行數據庫表結構和關系的表示。需要注意的是，MyColumn構造型的標記值可以通過建模工具提供的手段設置相應的值，但該圖中并沒有可視化展現出來（這依賴于建模工具的支持）。例如在Enterprise Architect中，通過屬性設置中單獨的標記值（Tagged Values）屬性也可以設置具體的標記值，圖2-12列出的是Student表中StuNo字段的兩個標記值的設置情況截圖，可以看出，其PK設置為true, IsNull設置為false，這表明StuNo字段是這個表的主鍵，同時不允許為空。

2.4.3 架構

UML提供了豐富的模型圖來表達系統的各個方面，這些圖形之間并不是完全獨立的，它們之間存在著千絲萬縷的聯系。在軟件開發的各個階段，每種圖形都有不同的用法和側重點，這就給普通用戶的使用帶來了很大的困擾。

UML標準只是提出了這些圖形的語法模型和語義模型，并沒有針對這些圖形的使用提供很好的支持。為了有效地利用這些模型，我們就需要結合不同的軟件工程過程，定義組織圖形的架構。

一種被大家廣泛接受的UML架構是源自統一過程中所提供的“4+1”架構模型，該架構如圖2-13所示。

在這種架構中一共提供了5個視圖（View）來組織UML模型，每個視圖面向不同的用戶，提供不同的UML模型，以實現不同的建模目標。視圖可以理解為系統在某個視角的模型，正如前面在“建模的基本原則”中提到的，往往需要從多個視角建立不同的模型，而這些視角就構成了UML建模的基本架構，也將知道后續的建模活動。

◆ 用例視圖（Use-Case View）：建模過程的起點和依據，面向最終用戶，描述系統的功能性需求。所有其他視圖都是從用例視圖派生而來的，該視圖把系統的基本需求捕獲為用例并提供構造其他視圖的基礎。

◆ 邏輯視圖（Logical View）：面向系統分析和設計人員，描述軟件結構。它來自功能需求，用于描述問題域的結構。作為類和對象的集合，它的重點是展示對象和類是如何組成系統、實現所需系統行為的。

◆ 進程視圖（Process View）：面向系統集成人員，描述系統性能、可伸縮性、吞吐量等信息。其目標是為我們系統中的可執行線程和進程建模，使它們作為活動類。事實上，它是邏輯視圖面向進程的變體，包含所有相同的工件。

◆ 實現視圖（Implementation View）：面向編碼人員，描述系統的組裝和配置管理。其目標是對組成基于系統的物理代碼的文件和構件進行建模。

◆ 部署視圖（Deployment View）：面向系統工程師，描述系統的拓撲結構、分布、移交、安裝等信息。建模的目標是把組件物理地部署到一組物理的、可計算的節點（如計算機）上。

使用Rational Rose建模工具的用戶，在開始一個新項目后，在默認情況下將提供這些視圖（有些細節并不一致，如默認不提供進程視圖，因為這些視圖本質上是邏輯視圖的變體），用戶按照這些視圖的組織結構逐步完成整個建模過程。

除了“4+1”架構視圖外，很多UML工具還提供了其他的模型組織架構。例如，當使用Enterprise Architect新建UML模型時，建模向導可以幫助開發人員建立基本的模型結構，并提供相應的視圖。有時候，甚至可以按照系統的開發階段或活動來組織模型。按照在第3.1.1小節中所定義的UML分析設計過程，可以定義如圖2-14所示的UML架構。

該架構采用Enterprise Architect建模，按照開發階段劃分模型（其中“06．部署模型”在設計階段的架構設計中完成，在開發后的部署階段使用），與本書后面的章節內容對應。讀者也可以參照這個架構組織自己的模型。