6.2 核心視圖

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

接下來講講核心視圖里的結(jié)構(gòu)視圖和行為視圖，下圖是大綱。

6.2.1 結(jié)構(gòu)視圖

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

6.2.1.1 用例圖

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

所謂不同的視角，可以對應(yīng)面向?qū)ο蠓治鲈O(shè)計的三階段。

• 建立業(yè)務(wù)模型階段，產(chǎn)出業(yè)務(wù)用例視圖。
• 建立概念模型階段，產(chǎn)出概念用例視圖。
• 建立設(shè)計模型階段，產(chǎn)出系統(tǒng)用例視圖。

就借閱圖書的用例而言，業(yè)務(wù)用例視圖如下，它是完全從業(yè)務(wù)角度出發(fā)，和計算機系統(tǒng)無關(guān)。

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

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

下圖是借閱圖書的系統(tǒng)用例視圖。

6.2.1.2 類圖

類圖用于展示系統(tǒng)中的類及其相互之間的關(guān)系。

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

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

下圖是網(wǎng)上購物的業(yè)務(wù)實體圖。

網(wǎng)上購物主要由商品、訂單、支付賬戶這幾個關(guān)鍵類構(gòu)成，這幾個類的交互能夠完成網(wǎng)上購物這個業(yè)務(wù)目標。

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

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

實現(xiàn)層類圖位于設(shè)計建模階段，這個階段采用設(shè)計類這個核心元素來表示。

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

下圖展示了查詢商品功能的類圖。可以看到，到了實現(xiàn)層類圖，類描述和類關(guān)系已經(jīng)是偽代碼級別了。

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

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

6.2.1.3 對象圖

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

比如一個正在運行的列車，如果用對象圖來描述，某個時間點你會發(fā)現(xiàn)以下靜態(tài)圖片：

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

6.2.1.4 包圖

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

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

下圖是網(wǎng)上購物的領(lǐng)域包圖，它表達了關(guān)鍵業(yè)務(wù)領(lǐng)域及其依賴關(guān)系。

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

6.2.1.5 組件圖

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

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

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

下圖可以表達組件實現(xiàn)的過程，通過第三方軟件或者面向?qū)ο蠓治鲈O(shè)計過程中產(chǎn)生的各種包，可以定義組件。

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

6.2.1.6 部署圖

部署圖描述了物理上系統(tǒng)運行時的結(jié)構(gòu)，包括系統(tǒng)中硬件的分布以及軟件部署到硬件上的具體方式。

部署圖用于設(shè)計建模階段，采用節(jié)點和關(guān)系兩種核心元素來繪制。常用于分布式應(yīng)用環(huán)境和多設(shè)備應(yīng)用環(huán)境。

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

6.2.2 行為視圖

結(jié)構(gòu)視圖介紹完，我們講講行為視圖。

行為視圖也稱為動態(tài)視圖。動態(tài)視圖就是描述事物動態(tài)行為的。動態(tài)視圖不能獨立存在，它必須基于一個靜態(tài)視圖或者 UML 元素，說明在靜態(tài)視圖規(guī)定的事物結(jié)構(gòu)下它們的動態(tài)行為。

這里簡要介紹的動態(tài)視圖包括狀態(tài)圖、活動圖、時序圖和協(xié)作圖。

6.2.2.1 狀態(tài)圖

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

這個對象可以是業(yè)務(wù)實體對象，也可以是分析類對象，還可以是設(shè)計類對象。也就是說，在面向?qū)ο蠓治鲈O(shè)計的三個階段（業(yè)務(wù)建模，概念建模，設(shè)計建模），都可以用狀態(tài)圖來表達。

下圖是一個產(chǎn)品的生命周期狀態(tài)圖。綠色部分是狀態(tài)圖相關(guān)的元素，紅色部分是元素的解釋。

從圖中，我們可以看到，狀態(tài)圖有以下關(guān)鍵元素：

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

6.2.2.2 活動圖

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

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

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

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

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

用例活動圖常常是從業(yè)務(wù)的角度上，分析要完成某個目標，要執(zhí)行哪些活動。如果在系統(tǒng)設(shè)計的角度上，要表達完成目標需要的活動，就需要用到對象活動圖。

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

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

6.2.2.3 時序圖

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

前面類圖那一節(jié)有提過類有三個層次的觀點：概念層、說明層和實現(xiàn)層，分別對應(yīng)于面向?qū)ο蠓治鲈O(shè)計的業(yè)務(wù)建模階段、概念建模階段和設(shè)計建模階段，相應(yīng)的，也可以在這三個層次上分別對業(yè)務(wù)實體對象、分析類對象和設(shè)計類對象繪制業(yè)務(wù)模型時序圖、概念模型時序圖和設(shè)計模型時序圖。

接下來介紹三種時序圖。

業(yè)務(wù)模型時序圖用于為領(lǐng)域模型中的業(yè)務(wù)實體交互建模，目標是實現(xiàn)業(yè)務(wù)用例。

上一節(jié)提到的活動圖，可以幫助我們發(fā)現(xiàn)業(yè)務(wù)實體，活動圖也可以很輕易的轉(zhuǎn)換成時序圖，下圖是網(wǎng)上購買商品的業(yè)務(wù)模型時序圖。

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

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

業(yè)務(wù)模型時序圖是業(yè)務(wù)建模階段的產(chǎn)物，它展現(xiàn)了業(yè)務(wù)的實際需求，因此使用的描述語言應(yīng)當采用業(yè)務(wù)術(shù)語。

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

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

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

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

分析類展示出來的已經(jīng)是系統(tǒng)實現(xiàn)的原型，進入設(shè)計建模階段，我們做的工作就是要選擇合適的實現(xiàn)方式來實現(xiàn)這個原型。

設(shè)計建模階段，我們采用設(shè)計模型時序圖來實現(xiàn)概念模型中的交互。

設(shè)計模型時序圖使用設(shè)計類作為對象繪制，也是我們?nèi)粘ｉ_發(fā)設(shè)計中最為常用的動態(tài)視圖。以下是商品查詢的設(shè)計模型時序圖。

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

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

6.2.2.4 協(xié)作圖

協(xié)作圖和時序圖一樣，也是描述對象之間的交互模式，不同的是，時序圖在意的是對象交互的執(zhí)行順序，而協(xié)作圖在意的是對象間的結(jié)構(gòu)關(guān)系。

因此，時序圖適用于獲得對調(diào)用過程的理解，而協(xié)作圖適用于獲得對對象結(jié)構(gòu)的理解。

協(xié)作圖可以和時序圖互相轉(zhuǎn)換，對應(yīng)時序圖的三種表達方式，協(xié)作圖也分為業(yè)務(wù)模型協(xié)作圖，概念模型協(xié)作圖和設(shè)計模型時序圖。本文只介紹業(yè)務(wù)模型協(xié)作圖，另外兩種協(xié)作圖可以由相應(yīng)的時序圖推導(dǎo)，這里就不贅述了。

業(yè)務(wù)模型協(xié)作圖同樣采用業(yè)務(wù)實體來繪制，目標也是實現(xiàn)用例場景。下圖是網(wǎng)上購買商品的業(yè)務(wù)模型協(xié)作圖。

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

以下是協(xié)作圖常用的 UML 元素：

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

6.2.3 小結(jié)

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

核心視圖分靜態(tài)視圖和動態(tài)視圖。靜態(tài)視圖表達事物的結(jié)構(gòu)性觀點，動態(tài)視圖表達事物的行為性觀點。

一個好的建模，結(jié)構(gòu)性和行為性都不可或缺，既要說明該事物長什么樣子，又要說明該事物應(yīng)該怎么用。

七、總結(jié)

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

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

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

希望這篇文章對從事面向?qū)ο缶幊痰淖x者朋友能夠有所啟發(fā)。