1.1UML基礎知識
UML這三個字母的全稱是Unified Modeling Language，直接翻譯就是統一建模語言，簡單地說就是一種有特殊用途的語言。UML由1.0版發展到1.1、1.2、...，到現在的2.0、2.x，本書將會以2.x版本爲基礎開展討論。
UML的作用：軟件設計和軟件需求分析
UML的分類：
- 結構型的圖(structure Diagram)
- 類圖（class Diagram）
- 對象圖（Object Diagram）
- 構件圖（Component Diagram）
- 部署圖（Deployment Diagram）
- 包圖（Package Diagram）
- 行爲型的圖（Behavior Diagram）
- 活動圖(Activity Diagram)
- 狀態機圖(State Machine Diagram)
- 順序圖(Sequence Diagram)
- 通信圖(Communication Diagram)
- 用例圖(Use Case Diagram)
- 時序圖(Timing Diagram)
UML圖爲什麼會分爲結構型和行爲型兩種呢?
顧名思義，結構型的圖描述的是某種結構，這種結構在某段時間內應該是穩定的，“靜態”的。
行爲型的圖描述的是某種行爲，是“動態”的。
分析系統需求是，我們會面對很多業務概念，它們之間會有某些關係，這些內容可以看成是“靜態的”，我們可以利用UML的結構性的圖來分析。同時，業務會涉及大量的流程，過程等，這些內容是“動態”的，我們可以用行爲型的UML圖來分析。
在我們軟件設計時，我們需要考慮需要那些類，哪些構件，系統最後怎樣部署等，這些內容可以看成是"靜態"的，我們可以利用UML的結構型的圖來設計。同時，我們也需要考慮軟件如何和用戶交互，類，構件，模塊之間如何聯繫等“動態”內容，我們可以利用行爲型的圖來設計。
所謂“靜態”和"動態"不是絕對的，下文我們將會進一步介紹結構型的UML和行爲型的UML。通過下面的學習，你將會初步認識UML的各種圖。
1.2結構型的UML(Structure Diagram)
- 類圖(Class Diagram)
請看下面這個類圖：
圖 1.1 某模具系統類圖
此圖截取自某模具管理系統的業務概念分析圖，圖中一個一個的矩形就是類，這些類之間有各種線條連接，這些線條表示類之間的關係。類圖是分析業務概念的首選，類圖可能是使用率最高的UML圖。
再看下面這個Person類圖，這時軟件設計時用到的一個圖：
圖 1.2 Person類圖
該Person類有以下屬性(Attribute):Name(姓名)，Sex(性別)，Department(部門)等，有以下操作(Operation):Work(工作)等。類有屬性和操作，但用類圖分析業務模型時，往往不需要使用操作，如圖1.1中的類就只有屬性。
Attribute有特性，特徵等譯法，Operation也稱作方法，但本書遵循UML中文術語標準，即Attribute爲屬性，Operation爲操作。
- 對象圖(Object Diagram)
一般情況下只有在軟件開發中才會使用到對象圖，下面的內容以開發的角度來說明對象圖，如果你沒有開發經驗，閱讀起來可能有一點難度。
圖1.2中的Person類，用代碼實例化如下：
Person person = new Person();
........
類(class)實例化後就是對象(Object),對象person是類Person的實例，上述代碼可以用對象圖表示如下：
圖 1.3Person類的對象圖
對象圖和類圖的樣子很相似，對象是類的實例化，“person::Person”表示對象person是類Person的實例。對象圖往往只在需要描述複雜算法時纔會使用，畫出來的對象圖往往不會只有一個對象，該圖只畫了一個對象，其目的是儘量簡化以便讀者的理解什麼是對象圖。
在需求分析工作中基本上不需要使用對象圖，從嚴謹的角度看某些情況下應該使用對象圖，但我往往還是會用類圖來處理，這樣更加簡便而且容易理解。我們將在類圖一章再次講解對象圖。
- 構件圖(Component Diagram)
構件圖也叫組件圖，兩個名字均符合UML中文術語標準。
一輛汽車由輪子、發動機等物理部件組成，一個軟件往往也是由很多“物理部件”(如：控件、重用構件等)組成的，構件圖就是用來描述軟件內部物理組成的一種圖。下圖是某權限構件設計圖：
圖1.4某權限構件設計圖
圖1.4右上方有這樣標誌的矩形表示一個構件，構件可以在包含構件。
軟件需求分析工作中，需要用到構件圖的情況不是很多，以下情況除外：
1.待開發的系統需要與第三方的系統，原有系統，某些老系統等交互，這時可用構件圖描述交互要求。
2.客戶對軟件設計有某些特殊要求，這時可用構件圖來描述要求。
構件圖有時不會單獨使用，還會和部署圖一起結合使用。
- 部署圖
部署圖是用來描述系統如何部署，本系統與其他系統是怎樣的關係的一種圖，如下圖：
圖 1.5 某24小時便利店的管理系統部署圖
圖中一個個立體的矩形是部署圖的“節點”，一個節點表示一個物理的設備，節點之間的線條表示節點間的物理連接關係。
部分客戶都會具備一定的IT基礎環境(如具備局域網、一些服務器、某些軟件平臺等)，軟件系統需要基於當前的IT基礎環境來規劃，這時我們可以使用部署圖來做這個規劃。
分析系統的需求，不能忽略系統架構、部署、IT架構等方面的要求，我們要基於客戶當前的IT基礎環境，做一個最符合客戶利益的規劃。
要活用構件圖、部署圖來分析需求，需要具備一定的IT基礎架構知識和軟件設計知識，如果你還不具備相關知識，那麼可以考慮抓緊補充相關知識。不過需求分析工作更多的還是分析業務，提煉功能性需求，這部分工作能做好是相當不容易的事情。對於技術方面的非功能性需求分析，可交由有技術背景的專業人士負責。
- 包圖(Package Diagram)
Package有“打包”的意思，包圖的主要用途是“打包”類圖。用類圖描述業務概念時，很多時候會因爲業務類太多，而導致類圖非常龐大，不利於閱讀，這時可以將某些類放入“包”中，通過包圖來組織業務概念圖。
下圖是包圖的一個示例：
圖 1.6包圖
圖中好像文件夾樣子的就是一個"包"，包之間的線條表示包之間的關係。
1.3 行爲型的UML(Behavior Diagram)
活動圖，狀態機圖，順序圖處於三種不同的角度來描述流程，是分析業務流程的三種不同利器，下面將會逐一說明。
- 活動圖(Activity Diagram)
我們將起牀到出門上班這個過程畫成活動圖，可能是這樣的：
圖1.7起牀到出門上班的活動圖
活動圖中的一個圓邊框框表示一個“活動”，多個活動之間的帶箭頭線條表示活動的先後順序，該圖只是表達了一個順序流程，活動圖還可以表達分支結構。如果你以前曾學過流程圖的話，你會發現活動圖和流程圖很相似。活動圖可能是三種能表示流程的UML圖中最接近我們思維習慣的一種，下面來學習另外兩種能表達流程的圖。
- 狀態機圖(State Machine Diagram)
狀態機圖又叫狀態圖，但狀態圖這個譯名並沒有譯出Machine的意思。
狀態機圖從某個物品的狀態是如何變化的角度來展示流程，下圖某請假條審批流程：
圖 1.8請假處理流程
整個請假審批流程是圍繞"請假條"這個物體進行的，隨着不同的審批階段，請假條具備不同的狀態。我們分析業務流程時會發現很多流程其實是圍繞某個物品進行的，這時可考慮使用狀態機圖。
- 順序圖(Sequence Diagram)
你去餐廳吃飯，向服務員點餐到服務員送菜上來，這個過程用順序圖可表示如下：
圖 1.9 點菜的順序圖
該圖有三個“小人”，每個“小人”下面的文字說明(如：顧客)表示其代表的角色。角色與角色之間有一些線條鏈接，表示角色之間是如何交互的。該圖表示的意思是：顧客向服務員點菜後，服務員將點菜信息傳遞給廚師，然後廚師做菜，最後再由服務員送菜給你。
點菜過程涉及幾個環節，每個環節均由不同的角色來負責，如果遇到類似的情況，你可以考慮使用順序圖來分析。用順序圖來分析的好處是能清晰表達整個過程所參與的角色，角色與角色之間的關係，各角色是如何被捲入這個過程當中的。
- 通信圖(Communication Diagram)
UML1.1時，該圖英文名爲Collaboration Diagram;UML2.x時，英文名爲Communication Diagram。將英文名字直接翻譯，原來的英文名字可譯爲協作圖，而新的英文名字譯爲通信圖。
通信圖是順序圖的另外一種畫法，點菜的順序圖，如果用通信圖來畫可表示如下：
圖 1.10點菜的通信圖
三個“小人”分表表示三種角色：顧客、服務員、廚師;角色之間有直線聯繫表示他們之間有關係;帶序號的文字和箭頭，表示角色之間傳遞的信息。
順序圖更強調先後順序，通信圖更強調相互之間的關係。我覺得順序圖實用性更好一點，比通信圖能表達更多的信息，更容易讀懂，在需求分析工作中我基本不會使用通信圖。
- 用例圖(Use Case Diagram)
下圖是用例圖的示意圖：
圖 1.11 用例圖
用例圖表達的是什麼角色通過軟件系統能做什麼事情，我們可以使用用例圖系統地表達軟件系統的絕大部分需求。
- 時序圖(Timing Diagram)
序圖也叫時間圖，時序圖是UML中文術語標準的說法，而時間圖不是標準的說法。
時序圖是表示某東西的狀態隨時間變化而變化的一種圖，參見下圖：
圖 1.12 燈的開關狀態隨時間變化圖
此圖表示在0秒到30秒，燈的狀態是關的，30-60秒燈的狀態爲開，60秒後狀態爲關。
下面通過這個表格來總結一下我在需求分析工作中應用各種UML圖的情況：
表 1.1各種UML圖實際應用情況
上表是根據我的工作經驗總結的，相信會適用於很多情況。但每個人的工作經歷、情況、環境等不太一樣，上表僅作參考。
1.4 如何學好UML?
UML的認識誤區
誤區一：認爲UML主要用於軟件設計。
前面的文章你可以看到，UML除了用於軟件設計，還能用於需求分析，而本書就是專門來說明如何在需求分析工作中活用UML的。
誤區二：客戶無法理解UML，在需求分析中應用UML實際意義不大。
我還不熟悉UML時，確實也有這樣的懷疑，而實際工作中發現UML恰恰成爲與客戶溝通的良好橋樑!UML其實不難讀懂，只要稍加解釋客戶馬上就能讀懂。我在所有的項目需求分析工作中，都直接使用UML圖與客戶溝通，並且給客戶簽署的需求規格說明書中含有大量的UML圖。
UML能直觀、形象、嚴謹地描述出業務概念、業務流程、客戶的期望和需求，只要稍加引導客戶，客戶將會很容易讀懂UML，甚至會主動使用UML與項目組交流。我曾經遇到過客戶向我們索要畫UML圖的工具，客戶見識過UML的威力後，也想在自己實際工作中使用。
誤區三：認爲UML語法繁雜，難以學習和應用。
某些UML資料和書籍可能將UML說得過於複雜了，官方的UML標準資料也確實是枯燥難懂、人見人暈。我剛開始學習UML時，也看過一些UML書籍，覺得UML的語法太多、太複雜、太容易混淆了!
在實際工作中，其實經常需要用到的UML語法並不多，而且很容易掌握。當我們在需求分析方面應用UML時，需要掌握的語法更少(在軟件設計方面應用UML時需要掌握稍多一點的語法)。“二八原則”在這裏完全適用，我們經常用到的UML語法，其實只佔全部語法的20%，而本書將會重點介紹實用性強的UML語法。
誤區四：UML用途不大。
很多人推崇UML，但也有不少人士不太認可UML。不認可的原因主要是因爲一些人士學習UML後，發現在實際工作中發揮的作用並不是很大，有時候不用UML效果更好。
我不敢說UML能幫助我們解決所有問題，至少從我的多年使用經驗上來說，UML對於提升我的需求分析能力幫助還是很大的。有人之所以感覺UML不太好用，我覺得原因還是隻掌握了UML的形而沒有領會UML的神。UML的常用語法可能幾天就能學會了，而要真正做到“thinking in UML”卻沒有這麼容易，需要長期的鍛鍊。
UML學習難點
學UML之難，不在於學習語法，關鍵是要改變思維習慣。UML是一種新的工具，但同時也是代表了一種新的先進的思考方法，如果不能掌握這樣的方法，只能學到了UML的形，而沒有掌握其神髓。
要用好UML，你需要在平時多多培養下面的能力：
- 書面表達能力。
- 歸納總結能力。
- “面向對象”的思維能力和抽象能力。
平時你可以利用各種機會來提升第1和第2種能力，如多寫寫項目文檔、寫寫日記或博客等，多思考和總結平時自己的工作得失等。
第3種能力說起來有點虛，大家在大學中可能也學過相關知識。訓練這種能力的最好方法就是多應用類圖，我們將會在類圖的章節再重點介紹，通過實例來體會什麼才叫“面向對象”!
本書將會重點培養你的這三種能力，只要你有進步之心，多練習、多實踐、多思考、多總結，一定會取得長足進步!
1.5 小結
本章的主要目標是讓你不需要閱讀全書的情況下，就可以瞭解到UML的全貌，大概知道UML各種圖的用途，同時給你說明學習UML的難點，爲最終活用UML做好準備。下面我們一起來複習一下本章的主要內容：
UML是Unified Modeling Language的簡稱，是軟件開發界的一套標準，UML不僅可用於軟件設計，也可以用於軟件需求分析。但UML並不是強制標準，我們應該善用包括UML在內的各種標準來提高我們的水平。
UML可分爲兩類：結構型、行爲型，結構性的UML有：類圖、對象圖、構件圖、部署圖、包圖，行爲型的圖有活動圖、狀態機圖、順序圖、通信圖、用例圖、時間圖。
類圖是業務概念模型分析的有利武器，也是面向對象分析能力的強有力訓練工具。
對象圖在需求分析工作中並不常用。
構件圖、部署圖是分析IT基礎架構、軟件架構等方面需求的有利分析工具，但需要你具備IT基礎架構、軟件設計方面的知識和經驗。
包圖可用來組織類圖，在需求分析工作中應用的機會不是很大。
活動圖、狀態機圖、順序圖是分析業務流程的強力武器。活動圖的表達思路與流程圖很類似，很容易掌握，而且大部分情況下都可以使用活動圖來分析業務流程;某流程如果是圍繞某個物品進行，該物品在流程中轉換多種狀態，那麼使用狀態機圖來分析是首選;用順序圖來分析的好處是能清晰表達整個過程所參與的角色，角色與角色之間的關係，各角色是如何被捲入這個過程當中的。
通信圖可以看作是順序圖的另外一種表達形式，順序圖更強調先後順序，通信圖更強調相互之間的關係。而從我的工作經驗看，順序圖更加實用一點。
有人會將用例圖稱作“公仔圖”，用例圖表達的是什麼角色通過軟件系統能做什麼事情，我們可以使用用例圖系統地表達軟件系統的絕大部分需求。
時間圖是表示某東西的狀態隨時間變化而變化的一種圖，我在實際工作中很少有機會能用到這種圖。
學UML之難，不在於學習語法，避免陷入UML的認識誤區，多練習、多實踐，培養良好的“think in UML”思想，鍛鍊面向對象分析的能力，成爲活用UML的需求分析高手不遠矣!