一、上章回顧

　　上篇文章《系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模1》主要簡(jiǎn)單的介紹了建模中使用的標(biāo)準(zhǔn)建模語(yǔ)言UML的相關(guān)內(nèi)容，包括用例圖與類圖的使用方法及如何建模。相信大家對(duì)UML建模語(yǔ)言已經(jīng)有了初步的認(rèn)

　　識(shí)，還請(qǐng)大家謹(jǐn)記UML不同的建模圖形的用處。比如，用例圖主要用來描述系統(tǒng)的功能需求。類圖主要用來描述實(shí)體間的關(guān)系。謹(jǐn)記這些就可以幫助我們?cè)谙到y(tǒng)架構(gòu)的

　　過程中深入的分析。

　　首先向大家道歉，上篇中有部分描述錯(cuò)誤的地方，可能對(duì)大家造成一定的錯(cuò)誤引導(dǎo)。

這是上篇給出的圖，我描述的是組合關(guān)系。

　　特別更正為：

　　這是正確的結(jié)果。箭頭指向聚合類。描述的信息并無任何錯(cuò)誤。希望能對(duì)大家指正。

　　二、摘要

　　本文主要從系統(tǒng)架構(gòu)中的建模開始講解，本文講述的內(nèi)容主要是我在工作和學(xué)習(xí)過程中的總結(jié)和經(jīng)驗(yàn)，不足之處還請(qǐng)大家多多批評(píng)指出，有更好的建議也可以留言

　　說明。本意主旨是為不熟悉系統(tǒng)架構(gòu)建模過程和不知道如何使用建模工具，或者不熟悉如何根據(jù)需求去建立模型的角度出發(fā)，簡(jiǎn)單的闡述了在系統(tǒng)架構(gòu)的過程中我們應(yīng)

　　該從什么樣的角度出發(fā)去分析需求并且建立抽象模型。這應(yīng)該說是架構(gòu)師必備的技能。

　　本文由淺入深，本篇將簡(jiǎn)單的介紹如何使用使用UML建模中的各個(gè)結(jié)構(gòu)圖與行為圖，去完成抽象模型的建立。

　　本文主要講解以下幾個(gè)建模圖形：順序圖、組件圖、狀態(tài)圖、活動(dòng)圖、部署圖。當(dāng)然本文也只是講述了基本理論介紹及如何設(shè)計(jì)使用，系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)

　　用架構(gòu)-系統(tǒng)建模[下篇] 將會(huì)詳細(xì)的講解通過具體實(shí)例講解如何使用這些已經(jīng)介紹的抽象模型圖形去描述。

　　三、本章內(nèi)容

　　1、上章回顧。

　　2、摘要。

　　3、本章內(nèi)容。

　　4、建模中的抽象模型圖。

　　5、本章總結(jié)。

　　6、系列進(jìn)度。

　　7、參考文獻(xiàn)。

　　8、下篇預(yù)告。

　　四、建模中的抽象模型圖。

　　1、順序圖。

　　介紹

　　順序圖也稱序列圖，主要用來系統(tǒng)中的某個(gè)流程的詳細(xì)步驟。順序圖能夠給出流程中一系列對(duì)象的交互順序。通過順序圖可以讓我們更好的了解如何實(shí)現(xiàn)某個(gè)用例

　　的方法。我們知道用例圖用來描述系統(tǒng)的功能需求。而順序圖清晰的描述了某個(gè)用例也就是系統(tǒng)功能的的實(shí)現(xiàn)方法。

　　詳解

　　在順序圖中包含的元素：

對(duì)象：用來標(biāo)識(shí)流程中的詳細(xì)步驟中的對(duì)象。

　　活動(dòng)條：用來標(biāo)識(shí)當(dāng)前對(duì)象是活動(dòng)的，如果想表示某個(gè)對(duì)象是活動(dòng)的，那么必須使用一個(gè)虛線+活動(dòng)圖的形式來構(gòu)建。

　　例如我們現(xiàn)在要標(biāo)示一個(gè)簡(jiǎn)單的做公交車的刷卡流程：

IC卡刷卡操作。

　　相關(guān)解釋說明：

　　公交卡,首先放在刷卡終端上，終端讀取卡中的余額信息，然后刷卡終端與終端中的扣款程序?qū)ο蠼换?，扣款程序根?jù)讀取的余額信息，與刷卡終端中的固定刷卡

　　金額對(duì)比，如果當(dāng)前IC卡的余額大雨刷卡終端的固定金額則,扣除金額，并且返回一個(gè)消息，提示刷卡成功的操作。

　　途中的實(shí)線表示調(diào)用被調(diào)用對(duì)象的方法，虛線表示當(dāng)被調(diào)用對(duì)象執(zhí)行成功后，返回的虛線上表示返回值的邏輯名稱，這樣可以提高了可讀性。

　　在公交卡與活動(dòng)條之間，應(yīng)有一個(gè)虛線鏈接。

　　在上圖中我們使用了活動(dòng)條，活動(dòng)條作為生命線的一部分。我們并沒有定義對(duì)象的創(chuàng)建和銷毀，因此我們來看UML建模語(yǔ)言提供的描述對(duì)象的創(chuàng)建與銷毀實(shí)例。

　　上圖中的X符號(hào)的圖標(biāo)代表的時(shí)候?qū)ο蟮匿N毀。創(chuàng)建對(duì)象通過new來創(chuàng)建，上圖中，我用中文描述“創(chuàng)建對(duì)象”來完成對(duì)象的創(chuàng)建，那么在生命線下的的X符號(hào)代

　　表銷毀對(duì)象，從內(nèi)存中移除對(duì)象。當(dāng)然這個(gè)對(duì)象的銷毀對(duì)不同的開發(fā)語(yǔ)言有這不同的處理方式。C++中的銷毀對(duì)象，必須調(diào)用析構(gòu)函數(shù)來銷毀對(duì)象。C#與JAVA語(yǔ)言中

　　則只是說明當(dāng)前需要銷毀的對(duì)象沒有被其他的對(duì)象引用，那么這類語(yǔ)言編譯器提供垃圾回收器來完成回收。

　　注意：當(dāng)某個(gè)對(duì)象引用了另外一個(gè)對(duì)象，該對(duì)象有責(zé)任銷毀被引用對(duì)象并且必須顯示銷毀該被引用對(duì)象時(shí)，那么必須要顯示的發(fā)送被引用對(duì)象銷毀的通知消息。白

　　話文來說就是顯示的調(diào)用被引用對(duì)象的銷毀方法。

　　順序途中的同步與異步。

　　順序圖中的同步與異步與我們平時(shí)書寫代碼中的同步與異步的解釋意思差不多。這里不過多解釋，通過圖例說明：

　　客戶去餐廳吃飯，首先要點(diǎn)餐，必須等待點(diǎn)餐完了才能上菜。意思就是可以這樣簡(jiǎn)單描述。A簡(jiǎn)單調(diào)用B方

　　法，必須等待，等到B方法執(zhí)行完畢后,繼續(xù)執(zhí)行。

　　函數(shù)A調(diào)用函數(shù)B，如果B需要的時(shí)間特別長(zhǎng)，那么此時(shí)A可以去繼續(xù)執(zhí)行做其他的事情比如做和函

　　數(shù)C交互，等B函數(shù)執(zhí)行完了，只需要回調(diào)通知A，B函數(shù)執(zhí)行完了即可。在函數(shù)調(diào)用中的術(shù)語(yǔ)就是回調(diào)。

　　UML建模語(yǔ)言中同步與異步消息的標(biāo)識(shí)格式：

　　UML提供了一些順序圖的高級(jí)功能：例如可以通過順序圖實(shí)現(xiàn)流程的控制。具體的實(shí)現(xiàn)工具是通過UML提出的交互框來實(shí)現(xiàn)流程條件的控制。

　　交互框其實(shí)就是定義了流程控制圖中的控制邏輯，基于交互框定義流程執(zhí)行的條件。如果滿足這個(gè)條件，那么則執(zhí)行交互框中已定義好的順序步驟。否則不做任何

　　操作。交互框中除了定義流程控制的條件外，還有一些自己特殊的操作符，具體的操作符及其作用，如下列表：

　　每個(gè)關(guān)鍵字代表的含義都有相應(yīng)的描述。大家應(yīng)該都可以看明白，上述的所有含義都是針對(duì)交互框來說的。

　　總結(jié)

　　如果在系統(tǒng)功能中有特殊需求，那么順序圖中的交互框是可以支持嵌套的。嵌套交互框的話，會(huì)提高順序圖的復(fù)雜度，降低可讀性。因此我們?cè)O(shè)計(jì)時(shí)的原則盡量把復(fù)

　　雜的流程拆分成幾個(gè)簡(jiǎn)單的，分別繪制順序圖來完成相應(yīng)步驟。

　　2、組件圖。

　　簡(jiǎn)介

　　眾所周知，組件圖是用來描述系統(tǒng)中的各組件之間的關(guān)系。首先我們必須知道組件的定義是什么，然后組件之間有哪些關(guān)系。理清楚這些，我們?cè)谝院蟮脑O(shè)計(jì)中才能

　　派上用場(chǎng)。UML語(yǔ)言對(duì)組件的定義已發(fā)生了巨大變化。在之前的版本里面，UML如下定義組件的：

　　UML1.1語(yǔ)言中對(duì)組件的描述：把某個(gè)文件或者可以運(yùn)行的程序稱之為組件。但是我們知道，UML出現(xiàn)組件圖以前，組件一般用來描述COM組件或者其他的組件，因此造成沖突，所以隨著后續(xù)UML語(yǔ)言的發(fā)布，修改了原有的含義。

　　UML2.x語(yǔ)言中對(duì)組件的的描述：組件是獨(dú)立的，是運(yùn)行在一個(gè)系統(tǒng)中的封裝單位，提供了一系列的服務(wù)。

　　通過上述UML語(yǔ)言中的變遷，目前的理解是：一個(gè)系統(tǒng)，可以隨意更換系統(tǒng)中的某個(gè)組建。而不會(huì)影響系統(tǒng)的運(yùn)行。這可以理解為類似，大家熟悉IOC容器的都應(yīng)該

　　知道，運(yùn)行在IOC容器中的對(duì)象，可以看作組件，那么替換其中的提供某一服務(wù)的組件，只要滿足該組件服務(wù)的相關(guān)契約就能自動(dòng)完成替換。而不會(huì)影響系統(tǒng)的運(yùn)行。

　　每個(gè)組件都封裝了一些特殊的行為,實(shí)現(xiàn)了特定的服務(wù)。

　　組件之間的關(guān)系有哪些呢？我們通過下圖來看看，組件直接可能存在的關(guān)系：

組件直接的關(guān)系基本上來說就這2種。下面會(huì)舉例區(qū)別2中關(guān)系。

　　組件圖提供的服務(wù)：組件圖為系統(tǒng)架構(gòu)師提供了解決方案的自然形式。組件圖允許架構(gòu)師驗(yàn)證系統(tǒng)的必需功能是由組件來完成的。組件是可以復(fù)用的。

　　詳解

　　組件圖中包含的元素：

下面我們分別講解：

　　(1)、組件：我們知道組件是組件圖中最基本的組成元素，組件上面已經(jīng)講述了組件的定義。這里就不在多介紹，組件圖組成的基本單位即組件。

　　(2)、容器：可以為多個(gè)組件提供服務(wù)的管理容器，容器中的組件相互交互。

　　(3)、包：可以看作一個(gè)子系統(tǒng),其實(shí)也可以看作是特殊的組件。

　　(4)、約束：用于定義接口規(guī)范。

　　(5)、給組件圖中的相應(yīng)元素添加相應(yīng)注釋信息。

　　組件上可以定義自己的接口。例如上圖，人這個(gè)組件提供了2個(gè)接口。Thinking與Sleep接口。

　　組件關(guān)系的建模：

　　我們來看看組件之間的關(guān)系的表示，根據(jù)上面講解的組件的關(guān)系有依賴和泛化，參考類圖中的依賴和泛化。

　　依賴關(guān)系，標(biāo)識(shí)一個(gè)組件依賴另外一個(gè)組件，如果被依賴組件無法正常運(yùn)行，那么該組件也無法運(yùn)行。

泛化關(guān)系。標(biāo)識(shí)一個(gè)組件與其他多個(gè)組件的關(guān)系為繼承關(guān)系。

　　總結(jié)：

　　通過上面的學(xué)習(xí)我們知道：組件圖主要是為系統(tǒng)架構(gòu)師對(duì)整個(gè)系統(tǒng)的解決方案的自然形成，可以通過組件圖的形式把系統(tǒng)的大體功能進(jìn)行區(qū)分和設(shè)計(jì)。通過組件圖把

　　系統(tǒng)功能進(jìn)行抽象和分離。然后通過順序圖把功能流程細(xì)分成多個(gè)步驟，然后通過類圖去構(gòu)建每個(gè)流程步驟中的每個(gè)類應(yīng)具有的個(gè)方法。***形成一個(gè)完整的設(shè)計(jì)文

　　檔。

　　3、狀態(tài)圖。

　　簡(jiǎn)介

　　狀態(tài)圖其實(shí)是針對(duì)一個(gè)對(duì)象(實(shí)體、組件其他元素等)來說的。主要是描述了，對(duì)象的行為如何改變狀態(tài)的反映。我們研究UML狀態(tài)圖的目的就是為了搞清楚，對(duì)

　　象狀態(tài)的變化與行為的關(guān)系。建模對(duì)象的實(shí)時(shí)行為。創(chuàng)建狀態(tài)圖的條件：當(dāng)對(duì)象行為的改變與狀態(tài)有關(guān)的時(shí)候才創(chuàng)建狀態(tài)圖。狀態(tài)圖反映了對(duì)象如何改變狀態(tài)相應(yīng)行為

　　的變化和展示對(duì)象的生命周期的創(chuàng)建和刪除的全過程。

　　詳細(xì)

　　狀態(tài)圖可建模的對(duì)象：

用例：可以描述用例圖中的某個(gè)用例狀態(tài)的變化。

　　類：可以描述某個(gè)類的狀態(tài)的變化。

　　子系統(tǒng)：可以描述某個(gè)子系統(tǒng)中狀態(tài)的變化。

　　整個(gè)系統(tǒng)：類似(WF)工作流中的流程，每個(gè)節(jié)點(diǎn)其實(shí)就相當(dāng)于一個(gè)狀態(tài)。

　　上面簡(jiǎn)單的繪制了一個(gè)去餐廳吃飯的狀態(tài)變化，每個(gè)狀態(tài)變化的行為都有描述，當(dāng)然我這里只是簡(jiǎn)單的舉例說明狀態(tài)圖的變化，并沒有詳細(xì)分析的所有可能狀態(tài)都畫出來。

　　具體的狀態(tài)還請(qǐng)大家自己練習(xí)畫出來，此處只是簡(jiǎn)單的舉例說明。

　　狀態(tài)圖中的元素：

　　狀態(tài)標(biāo)記：

狀態(tài)圖中可以標(biāo)識(shí)一個(gè)或多個(gè)初始狀態(tài)，也可以包含一個(gè)或多個(gè)結(jié)束狀態(tài)。

　　狀態(tài)圖中不同狀態(tài)之間的關(guān)系：

　　轉(zhuǎn)移關(guān)系，用來描述對(duì)象的狀態(tài)從一個(gè)狀態(tài)轉(zhuǎn)移到另外一個(gè)狀態(tài)的處理流，箭頭指向轉(zhuǎn)移后的狀態(tài)。

　　狀態(tài)圖中提供了類似流程圖中的判定的功能元素：決策點(diǎn)。

　　通過元素決策點(diǎn)來完成：

決策點(diǎn)，用來決策跳向不同的狀態(tài)。

　　具體用例如下：

就是起到了一個(gè)決策的作用。這里不在復(fù)述。

　　狀態(tài)圖中的同步：

　　狀態(tài)圖中的同步主要是為了說明并發(fā)工作流的分岔和聯(lián)合。下圖描述了狀態(tài)圖中的同步條：

　　初始狀態(tài)進(jìn)入到同步條中分岔同步執(zhí)行操作A與B，分別進(jìn)入A狀態(tài)、B狀態(tài)，然后分別執(zhí)行A1,B1聯(lián)合進(jìn)入到結(jié)束狀態(tài)。

　　一個(gè)對(duì)象可以通過同步操作同事?lián)碛卸鄠€(gè)狀態(tài)。有時(shí)候一個(gè)對(duì)象還可以擁有不同層次的多個(gè)狀態(tài)。當(dāng)單個(gè)狀態(tài)擁有獨(dú)立的附加子狀態(tài)時(shí)就可以在狀態(tài)圖中使用層次結(jié)

　　構(gòu)的狀態(tài)。

　　組合狀態(tài)就是這樣的比較復(fù)雜的狀態(tài)結(jié)構(gòu)圖，有時(shí)候我們需要把一個(gè)復(fù)雜的狀態(tài)細(xì)化成多個(gè)子狀態(tài)的合成，那么這個(gè)復(fù)雜的狀態(tài)就可以叫組合狀態(tài)。

　　下面舉例說明：

　　組合狀態(tài)B，也即復(fù)合狀態(tài)B，內(nèi)部可能有比較復(fù)雜的狀態(tài)(C-D狀態(tài))。這種只是組合狀態(tài)B中存在單個(gè)狀態(tài)變化流程的情況，還可能組合狀態(tài)B中包含更多的狀態(tài)流。

　　那么我們就要用如下的狀態(tài)圖完成:

上圖中1代表的是下單的流程，2代表付款流程。

　　總結(jié)

　　通過上面的學(xué)習(xí)我想大家對(duì)狀態(tài)圖有了一定的了解，那么我們來總結(jié)下，如何建模狀態(tài)圖。

　　***步：我們知道建模狀態(tài)圖，首先需要抽象出來要建模的對(duì)象。

　　第二步：我們基于這個(gè)對(duì)象分析出該對(duì)象具有的所有狀態(tài)及發(fā)生狀態(tài)改變的行為。

　　第三步：標(biāo)識(shí)每個(gè)對(duì)象狀態(tài)的起始狀態(tài)與結(jié)束狀態(tài)。

　　第四步：開始創(chuàng)建對(duì)象的狀態(tài)圖，分析是否有必要?jiǎng)?chuàng)建復(fù)雜的組合狀態(tài)。

　　系統(tǒng)架構(gòu)設(shè)計(jì)的過程中，我們首先要分析出哪些對(duì)象需要使用狀態(tài)圖來描述。如果某個(gè)對(duì)象具有復(fù)雜的行為，那么可以使用活動(dòng)圖來建模比使用狀態(tài)圖更適合。每個(gè)

　　狀態(tài)圖必須至少有一個(gè)起始狀態(tài)和結(jié)束狀態(tài)。并且詳細(xì)的分析對(duì)象發(fā)生狀態(tài)改變的行為。從某個(gè)狀態(tài)轉(zhuǎn)移到另外一個(gè)狀態(tài)的行為是什么。在某些情況下，如果對(duì)象的某

　　個(gè)狀態(tài)無法清晰的表達(dá)時(shí)，可以通過創(chuàng)建組合狀態(tài)來進(jìn)一步細(xì)化該狀態(tài)，這樣能更清晰的表達(dá)對(duì)象的狀態(tài)變化。

　　五、本章總結(jié)。

　　本章主要講述了UML建模圖形中的順序圖、狀態(tài)圖、組件圖。并且分析了什么情況下使用各種UML建模圖進(jìn)行建模。并且通過簡(jiǎn)單實(shí)例說明如何使用。等UML所有的

　　建模圖形介紹完畢后，我將針對(duì)如何我目前遇到一些問題進(jìn)行分析講解，如何遇到功能需求進(jìn)行功能的分離及建模。希望大家多多提出寶貴意見。

　　六、系列進(jìn)度。

　　1、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)系列之--開卷有益

　　2、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)建模[上篇]

　　3、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)建模[中篇](上)

　　4、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)建模[中篇](下)

　　5、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)建模[下篇]

　　不斷更新中(請(qǐng)持續(xù)關(guān)注…)

　　七、參考文獻(xiàn)。

　　http://www.uml.org--官方UML Web站點(diǎn)。

　　http://www.rational.com/uml/resources/documentation/index.jsp--提供具體UML規(guī)范的多種不同版本。

　　http://www.rational.com/rose--關(guān)于IBM Rational Rose ?這個(gè)商業(yè)UML建模工具的信息。

　　http://www.rational.com/xde--關(guān)于IBM Rational XDE?這個(gè)與IBM的Eclipse開發(fā)平臺(tái)緊密集成的商業(yè)UML建模工具的信息。

　　http://argouml.tigris.org--關(guān)于Argo UML這個(gè)用Java構(gòu)建的開放源代碼UML建模工具的信息。

　　http://uml.sourceforge.net/index.php--關(guān)于Umbrello UML Modeller這個(gè)用于KDE的開放源代碼UMl建模工具的信息。

　　八、下篇預(yù)告。

　　下一篇將把本章沒有講述完畢的活動(dòng)圖與部署圖講解完畢，其他的不常用的建模圖形可能只是簡(jiǎn)單的講解，不會(huì)像這幾篇文章那樣具有說明的講解。由于本人才疏

　　學(xué)淺，可能對(duì)UML建模的認(rèn)識(shí)不夠深入，還請(qǐng)各位多多支出寶貴意見，我將在后續(xù)的文章中不斷的改進(jìn)和學(xué)習(xí)，將自己掌握的內(nèi)容寫出來，一方面是幫助不熟悉UML的

　　朋友盡快的上手，另外也可以讓自己加深印象。

　　作者：CallHot-何戈洲

　　出處：http://www.cnblogs.com/hegezhou_hot/

　　關(guān)于作者：專注于微軟平臺(tái)項(xiàng)目架構(gòu)、管理和企業(yè)解決方案。熟悉設(shè)計(jì)模式、極限編程、架構(gòu)設(shè)計(jì)、敏捷開發(fā)和項(xiàng)目管理。現(xiàn)主要從事WinForm、ASP.NET、等方面的項(xiàng)目開發(fā)、架構(gòu)、管理工作。如有問題或建議，請(qǐng)多多賜教！

【編輯推薦】

1. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之開卷有益
2. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模1
3. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模2
4. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模3
5. 系統(tǒng)架構(gòu)師談企業(yè)應(yīng)用架構(gòu)之系統(tǒng)建模4