6.2 核心視圖

前面我們介紹了 UML 的核心元素，這些元素分別應用于面對對象分析設計的各個階段，正是它們之間的相互組合，才形成了 UML 里的各種視圖，最終指導軟件設計。

接下來講講核心視圖里的結構視圖和行為視圖，下圖是大綱。

6.2.1 結構視圖

結構視圖也稱為靜態視圖。靜態視圖就是表達靜態事物的。它只描述事物的靜態結構，而不描述其動態行為。這里簡要介紹的靜態視圖包括用例圖，對象圖，類圖，組件圖，包圖和部署圖。

6.2.1.1 用例圖

用例圖包含參與者、用例和關系這三種核心元素，不同的視角可以得到不同的用例視圖，它展現了系統的功能性需求。

所謂不同的視角，可以對應面向對象分析設計的三階段。

• 建立業務模型階段，產出業務用例視圖。
• 建立概念模型階段，產出概念用例視圖。
• 建立設計模型階段，產出系統用例視圖。

就借閱圖書的用例而言，業務用例視圖如下，它是完全從業務角度出發，和計算機系統無關。

而我們在業務用例分析的過程中，可以分解出一些關鍵的概念用例，并建立它們之間的關系，如下圖(bu 表示業務用例，cu 表示概念用例)。

我們對業務用例進行分析以后，就可以繪制系統用例視圖。但不是所有的業務用例都有系統用例對應，比如檢查借閱證可能是手工工作，就不需要納入系統建設范圍。

下圖是借閱圖書的系統用例視圖。

6.2.1.2 類圖

類圖用于展示系統中的類及其相互之間的關系。

類圖建模常用的方式是從概念層，到說明層，最后到實現層這么一個抽象層次逐步降低和細化的過程。

概念層類圖位于業務建模階段，這個階段采用業務實體這個核心元素來表示。

下圖是網上購物的業務實體圖。

網上購物主要由商品、訂單、支付賬戶這幾個關鍵類構成，這幾個類的交互能夠完成網上購物這個業務目標。

說明層類圖位于概念建模階段，這個階段采用分析類這個核心元素來表示。

下圖展示了網上購物的說明層類圖，這個類圖表達了從計算機的視角來說，網上購物這個業務目標是由哪些類來完成的，這些類的接口保證了這個業務目標的達成。

實現層類圖位于設計建模階段，這個階段采用設計類這個核心元素來表示。

到了這一層，類圖可視作偽代碼，因此，在這個層次上，類必須明確采用哪種實現語言、什么設計模式、什么通信標準、遵循什么規范等。

下圖展示了查詢商品功能的類圖。可以看到，到了實現層類圖，類描述和類關系已經是偽代碼級別了。

由此可見，在軟件生命周期的不同階段，類圖也有三種不同的表達，他們分別是概念層類圖，說明層類圖和實現層類圖。

很多朋友在建模的時候只會用到實現層類圖，并非他們對問題領域足夠了解，而是不清楚類圖也分了這么三層。

6.2.1.3 對象圖

對象圖是類圖的實例，標識和類圖基本相同。由于對象存在生命周期，對象圖只能在系統某一時間段存在，因此對象圖可以被想象成正在運行的系統在某一時刻的快照。

比如一個正在運行的列車，如果用對象圖來描述，某個時間點你會發現以下靜態圖片：

• 當前的運行狀態（運行中或停車中）
• 當前的乘客數量。（如果捕捉在不同的時間，該值會變化）

6.2.1.4 包圖

在實際的項目中，建模過程獲得的元素可能是非常多的，如果將這些元素的關系都繪制出來，看上去就會特別亂，特別復雜，也難以識別。

那為了更好的理解和管理這些建模元素，我們就需要有規律的對元素進行組織。包圖就起到了這么一個作用，通過包這個容器，可以從大到小、從粗到細地將建模元素組織起來，便于我們的分析，交流和細化。

下圖是網上購物的領域包圖，它表達了關鍵業務領域及其依賴關系。

下圖展示了查詢商品功能的類層次，它表達了實現類位于哪個層次的軟件架構的觀點。

6.2.1.5 組件圖

當有些包能夠被多個場景重復使用，那這個包就可以認為有著特定的功能，能夠完成特定的目標。

這種情況下，包就可以定義為組件，組件是一種特殊的包，既起到了普通包組織和容納的作用，又能完成特定的功能。

比如模塊（登錄模塊），類庫（Java Guava 包）。

下圖可以表達組件實現的過程，通過第三方軟件或者面向對象分析設計過程中產生的各種包，可以定義組件。

組件可以按功能分為以下幾類：模塊、子系統、庫、可執行文件和程序包等等。

6.2.1.6 部署圖

部署圖描述了物理上系統運行時的結構，包括系統中硬件的分布以及軟件部署到硬件上的具體方式。

部署圖用于設計建模階段，采用節點和關系兩種核心元素來繪制。常用于分布式應用環境和多設備應用環境。

上圖是一個簡單的部署圖，表達了客戶端比如瀏覽器這個節點，會請求到 Web 服務器節點，最后通過數據庫服務器節點返回數據。如果涉及分布式環境，就要考慮多個 Web Server，多個 Database Server，甚至考慮多機房，異地等物理層面的部署方式。

6.2.2 行為視圖

結構視圖介紹完，我們講講行為視圖。

行為視圖也稱為動態視圖。動態視圖就是描述事物動態行為的。動態視圖不能獨立存在，它必須基于一個靜態視圖或者 UML 元素，說明在靜態視圖規定的事物結構下它們的動態行為。

這里簡要介紹的動態視圖包括狀態圖、活動圖、時序圖和協作圖。

6.2.2.1 狀態圖

狀態圖也稱狀態機，它描述了一個對象的生命周期，你可以把它理解成一臺運行中的機器，這臺機器負責這個對象在固定幾個狀態間的流轉。

這個對象可以是業務實體對象，也可以是分析類對象，還可以是設計類對象。也就是說，在面向對象分析設計的三個階段（業務建模，概念建模，設計建模），都可以用狀態圖來表達。

下圖是一個產品的生命周期狀態圖。綠色部分是狀態圖相關的元素，紅色部分是元素的解釋。

從圖中，我們可以看到，狀態圖有以下關鍵元素：

1. 初始狀態：它是狀態機的起始位置，不需要事件的觸發。用實心圓圈表示。
2. 狀態：狀態是對象執行某項活動或者等待某個事件時的條件。比如要想執行產品入庫動作，產品得是未入庫的狀態，如果想銷售某個產品，產品得是入庫的狀態。
3. 轉移：轉移是兩個狀態之間的關系，它表示當發生指定事件并且滿足指定條件時，第一個狀態中的對象將執行某些操作并進入第二個狀態。比如產品入庫這個動作，就將產品的狀態從未入庫轉移到了已入庫。
4. 事件：事件是一個特定的動作或行為，有時候也包括系統時鐘之類的定時器。如果條件滿足，事件的發生將觸發一個轉移。比如產品銷售這個動作，出發產品從已入庫狀態轉移至已銷售狀態。
5. 條件：條件是一個布爾表達式，當事件發生時將檢查這個表達式的值。條件求值結果可能決定轉移的分支，或者拒絕轉移。條件有可能引用當前狀態。比如產品合不合格這個布爾判斷，決定了產品是可被銷售，還是不可被銷售。
6. 最終狀態：最終狀態表示狀態機執行結束，或者對象生命周期結束。用帶環的實心圓圈表示。

6.2.2.2 活動圖

活動圖描述了為了完成某一個目標需要做的活動以及這些活動的執行順序。

UML 中有兩個層面的活動圖，一種是用例活動圖，它用于描述用例場景，常用于業務建模階段，另一種是對象活動圖，用于描述對象交互，常用于設計建模階段。

下圖是一個登機手續辦理的用例活動圖。綠色部分是活動圖相關的元素，紅色部分是元素的解釋。

從圖中，我們可以看到，活動圖有以下幾個關鍵元素：

• 起始點：起始點標記業務流程的開始。一個活動圖僅有一個。用實心圓圈表示。
• 活動：活動是業務流程中的一個執行單元。比如辦理登機手續需要出示機票和身份證這樣的動作。
• 判斷：判斷根據某個條件進行決策，執行不同的流程分支。比如身份核對決定了你能否繼續辦理登機手續。
• 基本流：基本流表示最主要、最頻繁使用的、默認的業務流程分支。比如身份核對的正常分支。
• 支流：支流是進行判斷后走進的業務流程分支。比如圖中無行李分支。
• 異常流：異常流表示非正常的、不是業務目標期待的、容錯性的、處理意外情況的業務流程分支。比如身份證核對錯誤。
• 同步：同步分為同步起始和同步匯合。
• 同步起始表示從它開始多個支流并行執行。比如托運行李的處理和登機牌的打印操作，可以并行。
• 同步匯合表示多個支流同時到達后再執行后續活動。
• 結束點：結束點表示業務流程的終止。一個或多個。

用例活動圖常常是從業務的角度上，分析要完成某個目標，要執行哪些活動。如果在系統設計的角度上，要表達完成目標需要的活動，就需要用到對象活動圖。

比如根據查詢商品的對象交互過程，就能繪制出以下的對象活動圖。

雖然 UML 允許用活動圖繪制對象交互，但實際工作中，我從來沒用過。因為 UML 有其他更好的工具來繪制對象交互圖，比如接下來要講的時序圖。

6.2.2.3 時序圖

時序圖用于描述按時間順序排列的對象之間的交互模式。

前面類圖那一節有提過類有三個層次的觀點：概念層、說明層和實現層，分別對應于面向對象分析設計的業務建模階段、概念建模階段和設計建模階段，相應的，也可以在這三個層次上分別對業務實體對象、分析類對象和設計類對象繪制業務模型時序圖、概念模型時序圖和設計模型時序圖。

接下來介紹三種時序圖。

業務模型時序圖用于為領域模型中的業務實體交互建模，目標是實現業務用例。

上一節提到的活動圖，可以幫助我們發現業務實體，活動圖也可以很輕易的轉換成時序圖，下圖是網上購買商品的業務模型時序圖。

時序圖中會涉及一些 UML 元素，這里列舉常用的幾個：

• 對象：表示參與交互的對象。每個對象都有一條生命周期線，對象被激活時，生命周期線上會出現一個長條（會話），表示對象的存在。
• 生命周期線：表示對象的存在。當對象被激活時，生命周期線上出現會話，表示對象參與了這個會話。
• 消息：表示對象間交互所發生的動作。由一個對象的生命周期線指向另一個對象的生命周期線。常見的消息類型有以下幾種：
• 簡單消息：向右的實線箭頭，這種最為常用。
• 返回消息：源消息的返回體，并非新消息。用向左的單向虛線箭頭表示。一般不需要為每個源消息都繪制返回消息，一方面源消息默認情況下都有返回消息，另一方面過多的返回消息會讓圖變得更復雜。
• 同步消息：表示發出消息的對象將停止所有后續動作，一直等到接收消息方響應。用向右帶×的單向實線箭頭表示。同步消息將阻塞源消息所有行為。通常程序之間的方法調用都是同步消息。
• 異步消息：表示源消息發出消息后不等待響應，而可以繼續執行其他操作。用向右的單向上箭頭表示。異步消息一般需要消息中間件的支持，如 MQ 等。
• 會話：表示一次交互，在會話過程中所有對象共享一個上下文環境。例如操作上下文。
• 銷毀：表示生命周期的終止。繪制在生命周期線的末端，一般沒有必要強調。

業務模型時序圖是業務建模階段的產物，它展現了業務的實際需求，因此使用的描述語言應當采用業務術語。

進入概念建模階段，可以采用分析類繪制概念模型時序圖。和業務模型時序圖相比，同樣是展現業務需求，不同點在于分析類代表了系統原型，所以這個階段的時序圖已經帶有了計算機層面的理解。

因此，概念模型時序圖既保留了實際業務需求，又得到了計算機實現的基本理念。如下圖所示。

可以看到，在概念模型時序圖里，相對于業務模型時序圖，我們的表達增加了安全認證和商品目錄。這是因為我們實際在做登錄這個功能時，我們的軟件系統需要關心身份核驗。我們在獲取商品時，為了避免雜亂需要對其進行分類。

另外，我們的業務實體轉為分析類進行表達，網站作為邊界類，用于隔離用戶操作和系統行為。安全認證作為控制類，用于決定是否能成功登錄網站。商品目錄和商品作為實體類，用于表達用戶實際想看到或者操作的實體信息。

分析類展示出來的已經是系統實現的原型，進入設計建模階段，我們做的工作就是要選擇合適的實現方式來實現這個原型。

設計建模階段，我們采用設計模型時序圖來實現概念模型中的交互。

設計模型時序圖使用設計類作為對象繪制，也是我們日常開發設計中最為常用的動態視圖。以下是商品查詢的設計模型時序圖。

可以看到，在設計模型時序圖里，消息會細致到方法級別。因為在這個階段，相關的技術選型，比如編程語言，交互協議，中間件等已經比較明確了。

時序圖除了在建模的三個階段使用外，當你需要表達對象的交互，或者想分析對象的職責和接口時，都可以使用時序圖。

6.2.2.4 協作圖

協作圖和時序圖一樣，也是描述對象之間的交互模式，不同的是，時序圖在意的是對象交互的執行順序，而協作圖在意的是對象間的結構關系。

因此，時序圖適用于獲得對調用過程的理解，而協作圖適用于獲得對對象結構的理解。

協作圖可以和時序圖互相轉換，對應時序圖的三種表達方式，協作圖也分為業務模型協作圖，概念模型協作圖和設計模型時序圖。本文只介紹業務模型協作圖，另外兩種協作圖可以由相應的時序圖推導，這里就不贅述了。

業務模型協作圖同樣采用業務實體來繪制，目標也是實現用例場景。下圖是網上購買商品的業務模型協作圖。

可以看到，協作圖和時序圖相比，對象間的結構一目了然，很容易知道哪些消息會影響哪些對象或者哪些對象需要提供哪些接口。但在執行順序的表達上就很弱，必須依賴消息文本里的數字。

以下是協作圖常用的 UML 元素：

• 對象：表示參與協作的對象。
• 對象關聯：用于連接兩個對象，表示二者的關聯。這種關聯是臨時的，只在本次交互中有效。
• 消息：和時序圖中的消息定義一致。
• 消息序號：表明消息傳遞的先后順序。

6.2.3 小結

本節介紹了 UML 的核心視圖，我們再看下核心視圖的大綱。

核心視圖分靜態視圖和動態視圖。靜態視圖表達事物的結構性觀點，動態視圖表達事物的行為性觀點。

一個好的建模，結構性和行為性都不可或缺，既要說明該事物長什么樣子，又要說明該事物應該怎么用。

七、總結

本文從一個示例開始，引入了 UML 的概念，介紹了什么是 UML，為什么要用 UML以及什么時候用 UML。我們了解一個事物，知其然也要知其所以然。

然后介紹了 UML 的組成結構，從元素和視圖的角度出發，講解了繪制圖形的方法和相關概念。文中也給出了很多我親手繪制的樣例視圖，如有錯誤之處，還望讀者指摘。

紙上得來終覺淺，絕知此事要躬行。知道和做到總有一段距離，重在實踐。

希望這篇文章對從事面向對象編程的讀者朋友能夠有所啟發。