UML(UnifiedModeling Language)是一種建模語言，更是一種系統分析設計的最佳實踐方法。我從2003年開始接觸UML，從UML1.1到2.0，感受到了UML的獨特魅力，它不僅僅成爲在項目和產品分析設計過程中的統一標準，還逐步成爲了從需求到測試的最常用公共語言。
我記得在最早接觸UML的那段時間，項目組還在辛苦的用着面向結構化的設計思想，寫着SRS，畫着流程圖和數據流圖；對OO的設計思想還未真正接觸，對於UML只知道系統的設計可以通過9種不同的圖來解剖系統，9種圖代表了系統的9種緯度，至於如何用到項目中是完全沒有概念。
後來，隨着Java盛行，OO的思想佔據主導，因此接觸UML更多了。發覺瞭解UML越深入就越被其吸引，UML不僅僅是一些圖，不僅僅是系統的不同剖面，更是一種業務和系統模型的構造過程。並開始在項目中推動使用UML的標準語言，比如用例圖，比如類圖。
直到現在，基於UML2.0的應用設計思想仍然是團隊中需求、設計、開發人員的主要指導思想。雖然UML1.0的9種圖如今擴展到2.0的13種圖，然而思想卻沒有太大變化，在設計中我們依然以用例爲驅動，在設計中注重對象的狀態變化的分析，注重類的分析和對象間的關係行爲分析。
如下圖所示，概括了基於UML2.0的APP設計思想。
Ø UML的用法
在我所接觸到的項目中，UML是一種設計的指導思想，是一種標準。我經常把UML，CMMI和Prototype合稱爲項目成功的三駕馬車。（現在Agile比較流行，特別是在需求容易變化，項目規模不大的前提下，RUP和Scrum爲代表的敏捷方法是可以取代CMMI的一些做法。）
² CMMI負責對項目的各個過程域提供最佳實踐方法指導，通過流程、模版和規範來約束和指導操作行爲，以減少項目風險和提升項目質量，同時確保組織級的資產成爲可持續發展的財富。
² Prototype是對需求過程最好的一種檢驗，我一直認爲需求捕獲和分析的能力是項目是否能夠交付的最大保障。所以，我迷信通過Prototype來與用戶迭代的確認，與開發測試人員按原型來驗收成果。
² UML不用多說了，是指導需求，設計和開發過程的一種思想。
另一方面，Martin把UML的用法從深淺分作三個層次：
² 草稿：是最常用的一種方法，主要用於溝通系統的某些層面。如果希望使用的更深入一些，可以通過正向工程和反向工程，實現模型和程序框架的互相推導。
² 藍圖：展現完整的系統設計細節，能夠指導開發。與草稿的區別在於，草稿並不是完整，而是注重強調需要交流的重點；而藍圖是完整的，把程序工作變得更簡單。草圖是探索式的，藍圖是系統性的。
² 程序：以MDA（模型驅動開發）爲基礎，能夠自動從PIM轉化爲PSM，再從PSM轉化爲程序代碼的過程。
下面談談從我的理解如何把UML的思想映射到項目的各個過程中，這些圖又如何配合起來使用。
UML2.0包括13種圖，其中類圖，組件圖，合成結構圖，部署圖，對象圖和包圖被歸於爲靜態結構圖；活動圖，用例圖，狀態機圖，時序圖，通訊圖，交互概覽圖和時間軸圖歸屬於動態行爲圖。
在需求分析階段，可以用到的是用例圖，類圖，活動圖和狀態圖。
在設計階段，一般用到類圖，時序圖，包圖，狀態圖和部署圖。
Ø 用例圖（use case）
用例圖，用來描述人機交互，與系統的互動。是定義和描述需求的最好方法，同時一個好的用例設計，一定是將用例映射到系統實現的類，用例說明了類的遷移和操作。
如下面的用例圖所示，
在用例中描述了這些內容：
² 用例的關聯角色是：Customer；
² 系統邊界是:TeeMall OnlineSystem；
² 基礎用例是：Place Order；
² Place Order用例包了(Include)了Supply Customer Data ,Order Product, Arrange Payment用例；
² Request Catalog用例是Place Order用例的擴展(Extend)用例；
² Arrange Payment用例概括了Pay Cash和Arrange Credit兩個子用例。
Ø 狀態機圖（State Machine）
狀態機圖是類的對象生命週期進行建模。狀態機是由狀態和遷移構成，是對象局部化視圖。
通常，使用狀態機圖來反映對象狀態的變化和其生命週期的模型。比如，以一個信用卡自助電影票購買終端的狀態控制機爲例。
在一般情況下，終端爲空閒狀態Idle；
當用戶插入卡後，進入買票流程。
狀態1：驗證。信用卡密碼驗證，如果驗證失敗，則購票過程結束，終端退出用戶的信用卡，狀態變爲空閒。
狀態2：選擇。信用卡密碼驗證成功後，進入選擇狀態。選擇電影場次和座位，並添加到自己的選擇箱中。
狀態3：確認。用戶選擇是否確認選擇的電影票，如果選擇繼續，則返回到狀態2；如果選擇支付，進入狀態4。
狀態4：購買。系統完成支付扣賬和打印出票，購買過程完成。
特殊操作，在上述四個狀態中，都可以進行cancel操作，則進入Idle狀態。
如下圖所示，
畫狀態機圖有幾個需要注意的地方：
² 狀態的變遷原因要在圖上說明清楚；
² 最好標明清楚狀態的開始和結束；
² 不要遺漏任何狀態之間的切換。
狀態機是一種深度關注細節的圖，是觀察對象狀態變化的緊縮型視圖。然而，通過狀態機圖很難看到全局，系統的整體行爲一定是通過多個狀態機的結果來決定的，交互視圖則正好起到了這個作用。
Ø 活動圖（Activity）
活動圖用來表示用例的執行流程，一般活動圖和狀態機圖結合使用，很多狀態的變遷都是一個活動單元。
很多人將UML的活動圖理解成爲大家經常使用的業務流程圖，特別在活動圖中也可以使用泳道，就認爲這個和Visio流程圖中泳道的意義一樣。其實，UML的活動圖和一般的流程圖最大區別在於，活動圖是以OOAD爲指導的，是以對象爲分析基礎，配合狀態機圖使用，爲的是對用例的執行流程進行描述，而並不是以現實中的業務流程爲視角。
如下圖所示，描述了一個並行的泳道活動圖。以訂單爲核心的對象，並基於訂單的幾種不同狀態進行的流程活動。
角色有：Customer，Sales，Stockroom。
訂單狀態有：Placed，Entered，Filled，Delivered。
訂單活動有：Request Service, Pay, Take Order, Fill Order, Deliver Order, CollectOrder。
Ø 序列圖（Sequence Diagram）
序列圖用來表示系統內部一羣對象之間互傳信息的情況，配合用例來使用的話，可以針對每一個用例設計系統內部的一羣對象實現用例的運行情況。
對於程序員的編碼工作來說，類圖和序列圖是最值得參考的兩款圖。
例如下圖所示：
Ø 交互概覽圖（Interaction Overview）
交互概覽圖是活動圖和序列圖的混合使用形式，其主要結構像活動圖，表示流程，但是參與流程的節點不是一般的動作(action)，取而代之的是“交互”(interaction)片段。一個交互片段的內容，正是序列圖的一小段交互片段。
對於複雜的對象交互，交互概覽圖可以用來表示交互片段之間的控制流程，其實可以彌補序列圖不易表示控制流程的缺點。不過，換個角度來看，假如序列圖複雜到需要搭配交互概覽圖的話，這張序列圖可能就需要拆解成兩張圖，或者進行重構以降低複雜度。
下圖即是一個交互概覽圖的示例：
Ø 對象圖（Object）和類圖（Class）
如要搞清楚類，先要明白什麼是對象：“帶有良好定義的邊界、封裝了狀態和行爲的具體實體，就是對象。“，也稱作類的實例；類是有相同屬性、操作、方法、關係或行爲的一組對象的描述符。
類和對象之間的關係就是《instantiate》。比如，
上面圖中BankAccount就是一個標準的實體類表示方法，包括了類名，屬性（屬性類型，多重性，初始值），操作（操作名，參數，返回類型），類範圍等。
除了實體類《Entity》外，還有接口類《Boundary》和控制類《Control》。
下圖是一個典型的類圖，描述了衆多類之間的關係。
除此之外，還有多重性，自反關聯等多種用法。
Ø 包圖（Package）
包是模型元素的容器和物主，每個包都具有自身的命名空間，所有名稱必須唯一。
包可以包含用例和類。在設計過程中，一般設計好的包圖，都將和程序源代碼包目錄結構一一對應起來。
如下圖所示，就是一個包的關係圖，反應包之間，包與邊界，包內等關係。
下圖是更爲詳細的類包關係圖，反應了包所包含的類，及包之間的依賴關係。
Ø 通訊圖（Communication）
通信圖跟序列圖的功用相似，都是用來表示一羣對象互傳信息的交互情況。只是，通信圖採用網狀圖形，強調對象之間的鏈接。而序列圖採用柵欄狀圖形，強調依次發送信息。
Ø 合成結構圖（Composite Structure）
組合結構圖算也是一種類圖，但是它的實用性並不是在一般的業務系統，而是側重於實時系統或嵌入式系統。類圖用來表示系統內部的靜態結構，而且它表示的不是系統某一個時刻的靜態結構，它表示的是系統在任何時刻下都必須遵守的靜態結構。而組合結構圖，它表示某一對象的內部結構，其內部由一組小對象組成。這種圖有兩個特色：其一，它鎖定的範圍是對象內部，而不是一般業務系統的系統內部；其二，它強調對象內部的組成對象，一般在業務系統中對象是平等的。
Ø 部署圖（Deployment）
組件圖和部署圖都是用來表示實際元素的圖，前者表示實際的軟件程序，後者表示實際的硬件設備。實際上，部署圖最常用來表示系統的硬件設備及架構。如下圖所示：
Ø 組件圖（Component）
組件圖表示系統的組成組件(component)、組件所提供的接口(interface)或者是所需要的接口，以及組件之間的依賴關係。組件指一個具體的模塊單元(modular unit)，但是必須具備定義明確的接口(well-definedinterface)，並且易於替換(replaceable)。如下圖所示：
Ø 時間圖（Timing）
前面提到的狀態圖用來表示對象因爲事件的觸發而轉換狀態，所以它着重於事件與狀態的關係。而時間圖也是在表示狀態變化，但是它着重於狀態與時間的關係，用來表示對象在某一狀態停留了多久的時間後，將轉換到下一個狀態。時間圖很像心電圖，通過高高低低的曲線來強調狀態的變化。如下圖所示：
本文參考了：
《UML精粹：UML Distilled Third Edition》
ByMatin Fowler
《The Unified ModelingLanguage Reference Manual》
By Jacobson,Booch, Rumbaugh
《UML 2.0 and UnifiedProcess》
By Jim Arlow, Ila Neustadt