上篇文章主要簡單的介紹了模組化中使用的标準模組化語言UML的相關内容，包括用例圖與類圖的使用方法及如何模組化。相信大家對UML模組化語言已經有了初步的認
識，還請大家謹記UML不同的模組化圖形的用處。比如，用例圖主要用來描述系統的功能需求。類圖主要用來描述實體間的關系。謹記這些就可以幫助我們在系統架構的
過程中深入的分析。
首先向大家道歉，上篇中有部分描述錯誤的地方，可能對大家造成一定的錯誤引導。
特别更正為：
本文主要從系統架構中的模組化開始講解，本文講述的内容主要是我在工作和學習過程中的總結和經驗，不足之處還請大家多多批評指出，有更好的建議也可以留言
說明。本意主旨是為不熟悉系統架構模組化過程和不知道如何使用模組化工具，或者不熟悉如何根據需求去建立模型的角度出發，簡單的闡述了在系統架構的過程中我們應
該從什麼樣的角度出發去分析需求并且建立抽象模型。這應該說是架構師必備的技能。
本文由淺入深，本篇将簡單的介紹如何使用使用UML模組化中的各個結構圖與行為圖，去完成抽象模型的建立。
本文主要講解以下幾個模組化圖形：順序圖、元件圖、狀态圖、活動圖、部署圖。當然本文也隻是講述了基本理論介紹及如何設計使用，系統架構師-基礎到企業應
用架構-系統模組化[下篇] 将會詳細的講解通過具體執行個體講解如何使用這些已經介紹的抽象模型圖形去描述。
1、上章回顧。
2、摘要。
3、本章内容。
4、模組化中的抽象模型圖。
5、本章總結。
6、系列進度。
7、參考文獻。
8、下篇預告。
順序圖也稱序列圖，主要用來系統中的某個流程的詳細步驟。順序圖能夠給出流程中一系列對象的互動順序。通過順序圖可以讓我們更好的了解如何實作某個用例
的方法。我們知道用例圖用來描述系統的功能需求。而順序圖清晰的描述了某個用例也就是系統功能的的實作方法。
在順序圖中包含的元素：
對象：用來辨別流程中的詳細步驟中的對象。
活動條：用來辨別目前對象是活動的，如果想表示某個對象是活動的，那麼必須使用一個虛線+活動圖的形式來建構。
例如我們現在要标示一個簡單的做公共汽車的刷卡流程：
相關解釋說明：
公交卡,首先放在刷卡終端上，終端讀取卡中的餘額資訊，然後刷卡終端與終端中的扣款程式對象互動，扣款程式根據讀取的餘額資訊，與刷卡終端中的固定刷卡
金額對比，如果目前IC卡的餘額大雨刷卡終端的固定金額則,扣除金額，并且傳回一個消息，提示刷卡成功的操作。
途中的實線表示調用被調用對象的方法，虛線表示當被調用對象執行成功後，傳回的虛線上表示傳回值的邏輯名稱，這樣可以提高了可讀性。
在公交卡與活動條之間，應有一個虛線連結。
在上圖中我們使用了活動條，活動條作為生命線的一部分。我們并沒有定義對象的建立和銷毀，是以我們來看UML模組化語言提供的描述對象的建立與銷毀執行個體。
上圖中的X符号的圖示代表的時候對象的銷毀。建立對象通過new來建立，上圖中，我用中文描述“建立對象”來完成對象的建立，那麼在生命線下的的X符号代
表銷毀對象，從記憶體中移除對象。當然這個對象的銷毀對不同的開發語言有這不同的處理方式。C++中的銷毀對象，必須調用析構函數來銷毀對象。C#與JAVA語言中
則隻是說明目前需要銷毀的對象沒有被其他的對象引用，那麼這類語言編譯器提供垃圾回收器來完成回收。
注意：當某個對象引用了另外一個對象，該對象有責任銷毀被引用對象并且必須顯示銷毀該被引用對象時，那麼必須要顯示的發送被引用對象銷毀的通知消息。白
話文來說就是顯示的調用被引用對象的銷毀方法。
順序途中的同步與異步。
順序圖中的同步與異步與我們平時書寫代碼中的同步與異步的解釋意思差不多。這裡不過多解釋，通過圖例說明：
法，必須等待，等到B方法執行完畢後,繼續執行。
數C互動，等B函數執行完了，隻需要回調通知A，B函數執行完了即可。在函數調用中的術語就是回調。
UML模組化語言中同步與異步消息的辨別格式：
UML提供了一些順序圖的進階功能：例如可以通過順序圖實作流程的控制。具體的實作工具是通過UML提出的互動框來實作流程條件的控制。
互動框其實就是定義了流程控制圖中的控制邏輯，基于互動框定義流程執行的條件。如果滿足這個條件，那麼則執行互動框中已定義好的順序步驟。否則不做任何
操作。互動框中除了定義流程控制的條件外，還有一些自己特殊的操作符，具體的操作符及其作用，如下清單：
每個關鍵字代表的含義都有相應的描述。大家應該都可以看明白，上述的所有含義都是針對互動框來說的。
如果在系統功能中有特殊需求，那麼順序圖中的互動框是可以支援嵌套的。嵌套互動框的話，會提高順序圖的複雜度，降低可讀性。是以我們設計時的原則盡量把複
雜的流程拆分成幾個簡單的，分别繪制順序圖來完成相應步驟。
衆所周知，元件圖是用來描述系統中的各元件之間的關系。首先我們必須知道元件的定義是什麼，然後元件之間有哪些關系。理清楚這些，我們在以後的設計中才能
派上用場。UML語言對元件的定義已發生了巨大變化。在之前的版本裡面，UML如下定義元件的：
UML1.1語言中對元件的描述：把某個檔案或者可以運作的程式稱之為元件。但是我們知道，UML出現元件圖以前，元件一般用來描述COM元件或者其他的元件，是以造成沖突，是以随着後續UML語言的釋出，修改了原有的含義。
UML2.x語言中對元件的的描述：元件是獨立的，是運作在一個系統中的封裝機關，提供了一系列的服務。
通過上述UML語言中的變遷，目前的了解是：一個系統，可以随意更換系統中的某個組建。而不會影響系統的運作。這可以了解為類似，大家熟悉IOC容器的都應該
知道，運作在IOC容器中的對象，可以看作元件，那麼替換其中的提供某一服務的元件，隻要滿足該元件服務的相關契約就能自動完成替換。而不會影響系統的運作。
每個元件都封裝了一些特殊的行為,實作了特定的服務。
元件之間的關系有哪些呢？我們通過下圖來看看，元件直接可能存在的關系：
元件圖提供的服務：元件圖為系統架構師提供了解決方案的自然形式。元件圖允許架構師驗證系統的必需功能是由元件來完成的。元件是可以複用的。
元件圖中包含的元素：
下面我們分别講解：
(1)、元件：我們知道元件是元件圖中最基本的組成元素，元件上面已經講述了元件的定義。這裡就不在多介紹，元件圖組成的基本機關即元件。
(2)、容器：可以為多個元件提供服務的管理容器，容器中的元件互相互動。
(3)、包：可以看作一個子系統,其實也可以看作是特殊的元件。
(4)、限制：用于定義接口規範。
(5)、給元件圖中的相應元素添加相應注釋資訊。
元件關系的模組化：
我們來看看元件之間的關系的表示，根據上面講解的元件的關系有依賴和泛化，參考類圖中的依賴和泛化。
通過上面的學習我們知道：元件圖主要是為系統架構師對整個系統的解決方案的自然形成，可以通過元件圖的形式把系統的大體功能進行區分和設計。通過元件圖把
系統功能進行抽象和分離。然後通過順序圖把功能流程細分成多個步驟，然後通過類圖去建構每個流程步驟中的每個類應具有的個方法。最後形成一個完整的設計文
檔。
狀态圖其實是針對一個對象(實體、元件其他元素等)來說的。主要是描述了，對象的行為如何改變狀态的反映。我們研究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的
朋友盡快的上手，另外也可以讓自己加深印象。
本文轉自何戈洲部落格園部落格，原文連結：http://www.cnblogs.com/hegezhou_hot/archive/2010/09/11/1824084.html，如需轉載請自行聯系原作者