系統架構師談企業應用架構之系統建模2
一、上章回顧
上篇文章《系統架構師談企業應用架構之系統建模1》主要簡單的介紹了建模中使用的標準建模語言UML的相關內容，包括用例圖與類圖的使用方法及如何建模。相信大家對UML建模語言已經有了初步的認
識，還請大家謹記UML不同的建模圖形的用處。比如，用例圖主要用來描述系統的功能需求。類圖主要用來描述實體間的關系。謹記這些就可以幫助我們在系統架構的
過程中深入的分析。
首先向大家道歉，上篇中有部分描述錯誤的地方，可能對大家造成一定的錯誤引導。
這是上篇給出的圖，我描述的是組合關系。
特別更正為：
這是正確的結果。箭頭指向聚合類。描述的信息并無任何錯誤。希望能對大家指正。
二、摘要
本文主要從系統架構中的建模開始講解，本文講述的內容主要是我在工作和學習過程中的總結和經驗，不足之處還請大家多多批評指出，有更好的建議也可以留言
說明。本意主旨是為不熟悉系統架構建模過程和不知道如何使用建模工具，或者不熟悉如何根據需求去建立模型的角度出發，簡單的闡述了在系統架構的過程中我們應
該從什么樣的角度出發去分析需求并且建立抽象模型。這應該說是架構師必備的技能。
本文由淺入深，本篇將簡單的介紹如何使用使用UML建模中的各個結構圖與行為圖，去完成抽象模型的建立。
本文主要講解以下幾個建模圖形：順序圖、組件圖、狀態圖、活動圖、部署圖。當然本文也只是講述了基本理論介紹及如何設計使用，系統架構師-基礎到企業應
用架構-系統建模[下篇] 將會詳細的講解通過具體實例講解如何使用這些已經介紹的抽象模型圖形去描述。
三、本章內容
1、上章回顧。
2、摘要。
3、本章內容。
4、建模中的抽象模型圖。
5、本章總結。
6、系列進度。
7、參考文獻。
8、下篇預告。
四、建模中的抽象模型圖。
1、順序圖。
介紹
順序圖也稱序列圖，主要用來系統中的某個流程的詳細步驟。順序圖能夠給出流程中一系列對象的交互順序。通過順序圖可以讓我們更好的了解如何實現某個用例
的方法。我們知道用例圖用來描述系統的功能需求。而順序圖清晰的描述了某個用例也就是系統功能的的實現方法。
詳解
在順序圖中包含的元素：
對象：用來標識流程中的詳細步驟中的對象。
活動條：用來標識當前對象是活動的，如果想表示某個對象是活動的，那么必須使用一個虛線+活動圖的形式來構建。
例如我們現在要標示一個簡單的做公交車的刷卡流程：
IC卡刷卡操作。
相關解釋說明：
公交卡,首先放在刷卡終端上，終端讀取卡中的余額信息，然后刷卡終端與終端中的扣款程序對象交互，扣款程序根據讀取的余額信息，與刷卡終端中的固定刷卡
金額對比，如果當前IC卡的余額大雨刷卡終端的固定金額則,扣除金額，并且返回一個消息，提示刷卡成功的操作。
途中的實線表示調用被調用對象的方法，虛線表示當被調用對象執行成功后，返回的虛線上表示返回值的邏輯名稱，這樣可以提高了可讀性。
在公交卡與活動條之間，應有一個虛線鏈接。
在上圖中我們使用了活動條，活動條作為生命線的一部分。我們并沒有定義對象的創建和銷毀，因此我們來看UML建模語言提供的描述對象的創建與銷毀實例。
上圖中的X符號的圖標代表的時候對象的銷毀。創建對象通過new來創建，上圖中，我用中文描述“創建對象”來完成對象的創建，那么在生命線下的的X符號代
表銷毀對象，從內存中移除對象。當然這個對象的銷毀對不同的開發語言有這不同的處理方式。C++中的銷毀對象，必須調用析構函數來銷毀對象。C#與JAVA語言中
則只是說明當前需要銷毀的對象沒有被其他的對象引用，那么這類語言編譯器提供垃圾回收器來完成回收。
注意：當某個對象引用了另外一個對象，該對象有責任銷毀被引用對象并且必須顯示銷毀該被引用對象時，那么必須要顯示的發送被引用對象銷毀的通知消息。白
話文來說就是顯示的調用被引用對象的銷毀方法。
順序途中的同步與異步。
順序圖中的同步與異步與我們平時書寫代碼中的同步與異步的解釋意思差不多。這里不過多解釋，通過圖例說明：
客戶去餐廳吃飯，首先要點餐，必須等待點餐完了才能上菜。意思就是可以這樣簡單描述。A簡單調用B方
法，必須等待，等到B方法執行完畢后,繼續執行。
函數A調用函數B，如果B需要的時間特別長，那么此時A可以去繼續執行做其他的事情比如做和函
數C交互，等B函數執行完了，只需要回調通知A，B函數執行完了即可。在函數調用中的術語就是回調。
UML建模語言中同步與異步消息的標識格式：
UML提供了一些順序圖的高級功能：例如可以通過順序圖實現流程的控制。具體的實現工具是通過UML提出的交互框來實現流程條件的控制。
交互框其實就是定義了流程控制圖中的控制邏輯，基于交互框定義流程執行的條件。如果滿足這個條件，那么則執行交互框中已定義好的順序步驟。否則不做任何
操作。交互框中除了定義流程控制的條件外，還有一些自己特殊的操作符，具體的操作符及其作用，如下列表：
每個關鍵字代表的含義都有相應的描述。大家應該都可以看明白，上述的所有含義都是針對交互框來說的。
總結
如果在系統功能中有特殊需求，那么順序圖中的交互框是可以支持嵌套的。嵌套交互框的話，會提高順序圖的復雜度，降低可讀性。因此我們設計時的原則盡量把復
雜的流程拆分成幾個簡單的，分別繪制順序圖來完成相應步驟。
2、組件圖。
簡介
眾所周知，組件圖是用來描述系統中的各組件之間的關系。首先我們必須知道組件的定義是什么，然后組件之間有哪些關系。理清楚這些，我們在以后的設計中才能
派上用場。UML語言對組件的定義已發生了巨大變化。在之前的版本里面，UML如下定義組件的：
UML1.1語言中對組件的描述：把某個文件或者可以運行的程序稱之為組件。但是我們知道，UML出現組件圖以前，組件一般用來描述COM組件或者其他的組件，因此造成沖突，所以隨著后續UML語言的發布，修改了原有的含義。
UML2.x語言中對組件的的描述：組件是獨立的，是運行在一個系統中的封裝單位，提供了一系列的服務。
通過上述UML語言中的變遷，目前的理解是：一個系統，可以隨意更換系統中的某個組建。而不會影響系統的運行。這可以理解為類似，大家熟悉IOC容器的都應該
知道，運行在IOC容器中的對象，可以看作組件，那么替換其中的提供某一服務的組件，只要滿足該組件服務的相關契約就能自動完成替換。而不會影響系統的運行。
每個組件都封裝了一些特殊的行為,實現了特定的服務。
組件之間的關系有哪些呢？我們通過下圖來看看，組件直接可能存在的關系：
組件直接的關系基本上來說就這2種。下面會舉例區別2中關系。
組件圖提供的服務：組件圖為系統架構師提供了解決方案的自然形式。組件圖允許架構師驗證系統的必需功能是由組件來完成的。組件是可以復用的。
詳解
組件圖中包含的元素：
下面我們分別講解：
(1)、組件：我們知道組件是組件圖中最基本的組成元素，組件上面已經講述了組件的定義。這里就不在多介紹，組件圖組成的基本單位即組件。
(2)、容器：可以為多個組件提供服務的管理容器，容器中的組件相互交互。
(3)、包：可以看作一個子系統,其實也可以看作是特殊的組件。
(4)、約束：用于定義接口規范。
(5)、給組件圖中的相應元素添加相應注釋信息。
組件上可以定義自己的接口。例如上圖，人這個組件提供了2個接口。Thinking與Sleep接口。
組件關系的建模：
我們來看看組件之間的關系的表示，根據上面講解的組件的關系有依賴和泛化，參考類圖中的依賴和泛化。
依賴關系，標識一個組件依賴另外一個組件，如果被依賴組件無法正常運行，那么該組件也無法運行。
泛化關系。標識一個組件與其他多個組件的關系為繼承關系。
總結：
通過上面的學習我們知道：組件圖主要是為系統架構師對整個系統的解決方案的自然形成，可以通過組件圖的形式把系統的大體功能進行區分和設計。通過組件圖把
系統功能進行抽象和分離。然后通過順序圖把功能流程細分成多個步驟，然后通過類圖去構建每個流程步驟中的每個類應具有的個方法。***形成一個完整的設計文
檔。
3、狀態圖。
簡介
狀態圖其實是針對一個對象(實體、組件其他元素等)來說的。主要是描述了，對象的行為如何改變狀態的反映。我們研究UML狀態圖的目的就是為了搞清楚，對
象狀態的變化與行為的關系。建模對象的實時行為。創建狀態圖的條件：當對象行為的改變與狀態有關的時候才創建狀態圖。狀態圖反映了對象如何改變狀態相應行為
的變化和展示對象的生命周期的創建和刪除的全過程。
詳細
狀態圖可建模的對象：
用例：可以描述用例圖中的某個用例狀態的變化。
類：可以描述某個類的狀態的變化。
子系統：可以描述某個子系統中狀態的變化。
整個系統：類似(WF)工作流中的流程，每個節點其實就相當于一個狀態。
上面簡單的繪制了一個去餐廳吃飯的狀態變化，每個狀態變化的行為都有描述，當然我這里只是簡單的舉例說明狀態圖的變化，并沒有詳細分析的所有可能狀態都畫出來。
具體的狀態還請大家自己練習畫出來，此處只是簡單的舉例說明。
狀態圖中的元素：
狀態標記：
狀態圖中可以標識一個或多個初始狀態，也可以包含一個或多個結束狀態。
狀態圖中不同狀態之間的關系：
轉移關系，用來描述對象的狀態從一個狀態轉移到另外一個狀態的處理流，箭頭指向轉移后的狀態。
狀態圖中提供了類似流程圖中的判定的功能元素：決策點。
通過元素決策點來完成：
決策點，用來決策跳向不同的狀態。
具體用例如下：
就是起到了一個決策的作用。這里不在復述。
狀態圖中的同步：
狀態圖中的同步主要是為了說明并發工作流的分岔和聯合。下圖描述了狀態圖中的同步條：
初始狀態進入到同步條中分岔同步執行操作A與B，分別進入A狀態、B狀態，然后分別執行A1,B1聯合進入到結束狀態。
一個對象可以通過同步操作同事擁有多個狀態。有時候一個對象還可以擁有不同層次的多個狀態。當單個狀態擁有獨立的附加子狀態時就可以在狀態圖中使用層次結
構的狀態。
組合狀態就是這樣的比較復雜的狀態結構圖，有時候我們需要把一個復雜的狀態細化成多個子狀態的合成，那么這個復雜的狀態就可以叫組合狀態。
下面舉例說明：
組合狀態B，也即復合狀態B，內部可能有比較復雜的狀態(C-D狀態)。這種只是組合狀態B中存在單個狀態變化流程的情況，還可能組合狀態B中包含更多的狀態流。
那么我們就要用如下的狀態圖完成:
上圖中1代表的是下單的流程，2代表付款流程。
總結
通過上面的學習我想大家對狀態圖有了一定的了解，那么我們來總結下，如何建模狀態圖。
***步：我們知道建模狀態圖，首先需要抽象出來要建模的對象。
第二步：我們基于這個對象分析出該對象具有的所有狀態及發生狀態改變的行為。
第三步：標識每個對象狀態的起始狀態與結束狀態。
第四步：開始創建對象的狀態圖，分析是否有必要創建復雜的組合狀態。
系統架構設計的過程中，我們首先要分析出哪些對象需要使用狀態圖來描述。如果某個對象具有復雜的行為，那么可以使用活動圖來建模比使用狀態圖更適合。每個
狀態圖必須至少有一個起始狀態和結束狀態。并且詳細的分析對象發生狀態改變的行為。從某個狀態轉移到另外一個狀態的行為是什么。在某些情況下，如果對象的某
個狀態無法清晰的表達時，可以通過創建組合狀態來進一步細化該狀態，這樣能更清晰的表達對象的狀態變化。
五、本章總結。
本章主要講述了UML建模圖形中的順序圖、狀態圖、組件圖。并且分析了什么情況下使用各種UML建模圖進行建模。并且通過簡單實例說明如何使用。等UML所有的
建模圖形介紹完畢后，我將針對如何我目前遇到一些問題進行分析講解，如何遇到功能需求進行功能的分離及建模。希望大家多多提出寶貴意見。
六、系列進度。
1、系統架構師-基礎到企業應用架構系列之--開卷有益
2、系統架構師-基礎到企業應用架構-系統建模[上篇]
3、系統架構師-基礎到企業應用架構-系統建模[中篇](上)
4、系統架構師-基礎到企業應用架構-系統建模[中篇](下)
5、系統架構師-基礎到企業應用架構-系統建模[下篇]
不斷更新中(請持續關注…)
七、參考文獻。
http://www.uml.org--官方UML Web站點。
http://www.rational.com/uml/resources/documentation/index.jsp--提供具體UML規范的多種不同版本。
http://www.rational.com/rose--關于IBM Rational Rose ?這個商業UML建模工具的信息。
http://www.rational.com/xde--關于IBM Rational XDE?這個與IBM的Eclipse開發平臺緊密集成的商業UML建模工具的信息。
http://argouml.tigris.org--關于Argo UML這個用Java構建的開放源代碼UML建模工具的信息。
http://uml.sourceforge.net/index.php--關于Umbrello UML Modeller這個用于KDE的開放源代碼UMl建模工具的信息。
八、下篇預告。
下一篇將把本章沒有講述完畢的活動圖與部署圖講解完畢，其他的不常用的建模圖形可能只是簡單的講解，不會像這幾篇文章那樣具有說明的講解。由于本人才疏
學淺，可能對UML建模的認識不夠深入，還請各位多多支出寶貴意見，我將在后續的文章中不斷的改進和學習，將自己掌握的內容寫出來，一方面是幫助不熟悉UML的
朋友盡快的上手，另外也可以讓自己加深印象。
作者：CallHot-何戈洲
出處：http://www.cnblogs.com/hegezhou_hot/
關于作者：專注于微軟平臺項目架構、管理和企業解決方案。熟悉設計模式、極限編程、架構設計、敏捷開發和項目管理。現主要從事WinForm、ASP.NET、等方面的項目開發、架構、管理工作。如有問題或建議，請多多賜教！
【編輯推薦】
