五、UML 的適用場景

UML 既可以描述某個問題領域，也可以表達構思中的軟件設計，還可以描述已經完成的軟件實現。

它適用于面向對象分析設計的整個過程。這個過程可以分為三個階段，如下圖。

第一個階段是通過建模將現實世界轉為業務模型。業務模型真實映射了參與者（業務活動的驅動者）在現實世界的行為。

從圖里可以看到，現實世界映射到業務模型后，是使用 參與者 和 用例 這兩個 UML 的核心元素表達的。參與者作為一個特定事件的驅動者，用例則描述了這個驅動者的業務目標。文章后邊也會提到這兩個元素。

第二個階段是對業務模型概念化，建立適合計算機理解和實現的模型，也就是概念模型，或者叫分析模型。分析模型向上映射了原始需求，向下為計算機實現規定了一種高層次的抽象，是一種過渡模型。

現實世界千差萬別的業務，都用 邊界、控制和實體這幾個核心元素來描述，同時也引入了 包、組件 這些與現實世界毫不相干的概念做包裝。

第三個階段是對概念模型實例化，得到相對詳細的設計模型。

在設計模型中，概念模型中的邊界類可以被轉化為操作界面或者系統接口；控制類可以被轉化為計算程序或控制程序，例如工作流、算法體等；實體類可以轉化為數據庫表、XML 文檔或者其他帶有持久化特征的類。

同樣的概念模型會因為選擇不同而得到不同的設計模型。比如技術選型上使用不同的編程語言，不同的中間件就會得到不同的設計。

為什么需要這一道轉換呢？

因為“邊界”、“控制”、“實體”這些對象化的概念，雖然是計算機可以理解的，但它并不是真正的對象實例，也就是說它們并不是可執行代碼，概念模型只是紙上談兵。真正的對象世界行為是由 Java 類、C++ 類、JSP 等這些可執行代碼構成的。

換句話說，設計模型是概念模型在特定環境和條件下的實例化，實例化后的對象行為執行了概念模型描述的那些信息。

以下是面向對象分析設計的完整過程，它表達了現實世界是怎么通過 UML 映射到對象世界的。

六、UML 的組成結構

前面花了比較大的篇幅分析了 UML 的定位和適用場景，目的是幫助讀者建立對 UML 整體系統性的認知，而不是過早的陷入 UML 的使用細節里。我們要應用一項技術或工具，不能單純的因為它的酷炫或者說業界都在用所以我們要用，而應該結合自己的使用場景以及技術或工具的特點，來確認這項技術或工具究竟是不是我們需要的。

在讀者了解 UML 在面向對象分析設計領域優秀的特性之后，我們再來看看 UML 的一些細節。

凡是語言，都會存在基本詞匯和語法。

那么對應到 UML 里，基本詞匯就是核心元素，語法就是核心視圖。

UML 的組成結構如下圖：

6.1 核心元素

我們先介紹核心元素，下圖是大綱。

6.1.1 版型

版型：也稱「類型」或「構造型」。是對 UML 元素基礎定義的擴展，在元素基礎定義的基礎上賦予特別的含義，使得這個元素適用于特定的場合。

比如，我們前邊提到的「邊界類」、「實體類」、「控制類」都是類的版型。

6.1.2 參與者

參與者定位：事件的第一驅動者，也是系統的服務方。比如你在電商網站購物，你就是參與者。

6.1.3 用例

用例定位：系統執行的一系列操作，并生成參與者可以觀察的值。比如你在電商網站交易，會生成在線訂單，用戶下單就是一個用例。

用例版型：

• 業務用例：用于需求階段業務領域建模。與計算機系統建模無關，比如下單可以不依賴在線服務，而只是線下簽署協議。業務建模的目標是讓需求人員和客戶能夠達成共識。
• 業務用例實現：業務用例的一種實現方式，一個業務用例可以有多種實現方式。比如下單后的支付，可以用現金，也可以銀行卡轉賬，還可以第三方支付。

• 概念用例：用于獲取業務模型中的關鍵概念，分析出核心業務結構。業務架構就是概念建模階段產生，同時為系統建模階段提供重要指導。比如用戶下單這個用例，可以從實現過程中獲得一些核心業務，并把它們展現出來。

• 系統用例：用于定義系統范圍、獲取功能性需求。也就是我們常掛在嘴邊的用例。像業務用例中提到的線下簽約的方式，就不會納入到系統用例中，但如果是電子簽約的話，就可以成為系統用例了。
• 系統用例實現：系統用例的一種實現方式，一個系統用例可以有多種實現方式。比如下單后的支付，可以接入微信支付接口，也可以接入支付寶支付接口。

你會發現，同是用例的版型，業務用例與系統用例的區別就在于業務用例是客戶業務視角，系統用例是系統視角。

6.1.4 邊界

邊界定位：用于業務建模和系統建模階段的分析，保證分析粒度在一定的范圍內，不會擴散。

比如一個電商網站按領域職責作為邊界，會有店鋪域、商品域、會員域、交易域、支付域和營銷域等。各域只負責域內的事情，就能夠減少混亂緊耦合的局面。

一個好的分析和設計如同一筐帶殼的雞蛋，清清爽爽；一個差的設計如同一堆打碎了殼的雞蛋，粘粘糊糊。殼，是好壞的關鍵。

6.1.5 業務實體

業務實體定位：它代表參與者執行業務用例時所處理或使用的事物，特別用于在業務建模階段建立領域模型。業務實體是類（class）的一種版型。

業務實體的結構：包含屬性和方法。屬性用來保存業務實體特征，方法用來訪問業務實體。比如一臺電視，把它看成一個業務實體的話，它的屬性有運行狀態和音量，它的方法就是遙控器，我們可以開、關、調聲音，但是我們不可以試圖讓它飛起來——因為它沒有這樣的方法。

6.1.6 包

包定位：容納并為其他 UML 元素分類。比如 Java 后端經常會提供 jar 包給接入方使用。

6.1.7 分析類

分析類定位：用于代表系統中主要的職責簇，由此產生系統的設計類和子系統。

• 邊界類：用于對系統外部環境和內部運作之間的交互進行建模。比如現實世界的窗戶，計算機世界的網頁。
• 控制類：用于對用例特有的控制行為進行建模。比如顯示邏輯和業務邏輯通過控制層分離的 MVC 架構。
• 實體類：用于對需要存儲的信息和相關行為進行建模。源于業務模型中的業務實體。

分析類的抽象層次較高，比設計和實現要穩定很多，因此方便維護，也更容易獲得一個穩定架構來指導整個軟件的開發。

6.1.8 設計類

設計類定位：是系統實施中一個或多個對象的抽象，由此映射到實現代碼，依賴于實施語言。

設計類結構：

• 類型：對對象某一方面特征的歸納和抽象。映射到編碼中的 class。
• 屬性：對象特征。映射到編碼中的 field。
• 方法：訪問對象屬性的唯一途徑。映射到編碼中的 method。

6.1.9 關系

關系定位：抽象出對象之間的聯系，讓對象構成某個特定的結構。

關系分為以下幾種：

• 關聯（association）
• 關系：是一種擁有的關系，即一個類知道另一個類的屬性和方法；比如老師與學生可以是雙向的，也可以是單向的。雙向的關聯可以有兩個箭頭或者沒有箭頭，單向的關聯有一個箭頭。
• 箭頭和連線：帶普通箭頭的實心線，指向被擁有者。
• 適用場景：類圖。
• 依賴（dependency）
• 關系：是一種使用的關系，即一個類的實現需要另一個類的協助，是一種弱關系，隨運行場景變化。比如削蘋果時，人依賴于刀，脫離了這個場景，依賴關系就不存在了。
• 箭頭和連線：帶箭頭的虛線，指向被使用者。
• 適用場景：類圖。
• 泛化（generalization）
• 關系：是一種繼承的關系，比如貓是動物的一種。
• 箭頭和連線：帶三角的實線，箭頭指向父類。
• 適用場景：類圖。
• 實現（realization）
• 關系：是一種實現的關系，比如用例和用例實現的關系，接口與實現類的關系。
• 箭頭和連線：帶三角的虛線，箭頭指向用例實現或接口類。
• 適用場景：用例圖，類圖。
• 聚合（aggregation）
• 關系：是整體與部分的關系，且部分可以離開整體而單獨存在。生命周期各自獨立。如車和輪胎是聚合關系，輪胎離開車仍然可以存在。
• 箭頭和連線：帶空心菱形的實線，菱形指向整體。
• 適用場景：類圖。
• 組合（composition）
• 關系：是整體與部分的關系，但部分不能離開整體而單獨存在。同生同滅。如公司和部門是組合關系，沒有公司就不存在部門。
• 箭頭和連線：帶實心(黑色實心：要死一起死，良心是黑的)菱形的實線，菱形指向整體。
• 適用場景：類圖。

關聯關系和依賴關系的區別：

• 關聯關系是靜態天然的聯系，依賴關系是動態臨時的聯系。

此外還有只用于用例中的關系：

• 擴展（extends）
• 關系：用于在用例模型中說明向基本用例中的某個擴展點插入擴展用例。
• 箭頭和連線：帶箭頭的虛線加版型<>。
• 特點：用例可選。
• 包含（include）
• 關系：用于在用例模型中說明在執行基本用例的用例實例過程中插入的行為段。
• 箭頭和連線：帶箭頭的虛線加版型<>。
• 特點：用例必需。

6.1.10 組件

組件定位：實現特定功能的邏輯代碼模塊。比如分布式應用架構下，將業務目標拆成多個功能，每個功能作為組件獨立部署。這樣這些組件也能被其他場景復用。

6.1.11 節點

節點定位：表示應用程序的部署單元。比如分布式應用的環境中，服務器或設備會有很多，就需要通過節點來體現物理部署的情況。