UML學習入門就這一篇文章
1.1 UML基礎知識掃盲
UML這三個字母的全稱是Unified Modeling Language，直接翻譯就是統一建模語言，簡單地說就是一種有特殊用途的語言。
你可能會問：這明明是一種圖形，為什麼說是語言呢?偉大的漢字還不是從圖形(象形文字)開始的嗎?語言是包括文字和圖形的!其實有很多內容文字是無法表達的，你見過建築設計圖紙嗎?裡面還不是很多圖形，光用文字能表達清楚建築設計嗎?在建築界，有一套標準來描述設計，同樣道理，在軟體開發界，我們也需要一套標準來幫助我們做好軟體開發的工作。UML就是其中的一種標準，注意這可不是唯一標準，只是UML是大家比較推崇的一種標準而已，說不定以後有一個更好的標準可能會取代她呢!UML並不是強制性標準，沒有法律規定你在軟體開發中一定要用UML，不能用其它的，我們的目標是善用包括UML在內的各種標準，來提高我們軟體開發的水平。
UML由1.0版發展到1.1、1.2、...，到現在的2.0、2.x，本書將會以2.x版本為基礎開展討論。網路上、書籍、還有各種UML工具軟體，各自基於的UML版本可能會不一樣，大家在學習過程中可能會有一些困惑，不過沒關係，本課程在某些關鍵地方會描述1.x與2.x的差異。
UML有什麼用?
有很多人認為，UML的主要用途就是軟體設計!也有人認為，如果你不是開發人員，是難以理解UML的。
然而我第一次在實際工作中應用UML的卻不是軟體設計，而是軟體需求分析!當時我們和客戶面對面溝通調研需求的時候，直接用類圖、順序圖、活動圖、用例圖等UML。我們並沒有因此和客戶無法溝通，反而是溝通得更加順暢。客戶在我們的引導下，很快就會讀懂這些UML圖，因為UML圖，讓我們和客戶的溝通效率和效果更好!你可能覺得很神奇，在後續章節中，我將會為你逐一揭開神奇背後的“祕密”。
UML可幫助我們做軟體需求分析和軟體設計的工作，在我工作中大概各佔了50%的比例，當然在你的實際工作中不一定是這樣的比例。UML會讓你的需求分析或者軟體設計工作更上一層樓，本書將會介紹UML在需求分析方面的最佳實踐。
告訴你一個祕密，UML應用於軟體需求分析時，其學習門檻將會大大降低!語法複雜度會降低，而且你基本不需要掌握軟體開發的知識。只要你對軟體需求分析感興趣，認真學習和應用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各種圖的中文譯名，因為翻譯的原因可能會有所不一樣，如：Sequence Diagram和Timing Diagram有時候都會被譯成“時序圖”，這是最讓人困擾的地方!Sequence Diagram 除了被譯為順序圖，還有序列圖的譯法。
中國軟體行業協會(CSIA)與日本UML建模推進協會(UMTP)共同在中國推動的UML專家認證，兩個協會共同頒發認證證書、兩國互認，CSIA與UMTP共同推出了UML中文術語標準，該標準全稱為：CSIA-UMTP UML中文術語標準v1.0(本書後文將會簡稱為UML中文術語標準)。本書將會遵循UML中文術語標準，並且我們會同時給出中文譯名和英文原名，大家要留意看英文名字噢，這樣能幫助你不會被眾多的中文譯名混淆。
UML圖為什麼會分為結構型和行為型兩種呢?
顧名思義，結構型的圖描述的是某種結構，這種結構在某段時間內應該是穩定的，“靜態”的;而結構型的圖描述的是某種行為，是“動態”的。
分析系統需求時，我們會面對很多業務概念，它們之間會有某些關係，這些內容可以看成是“靜態”的，我們可以利用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.3 Person類的物件圖
物件圖和類圖的樣子很相似，物件是類的例項化，“person : Person”表示物件person是類Person的例項。物件圖往往只在需要描述複雜演算法時才會使用，畫出來的物件圖往往不會只有一個物件，該圖只畫了一個物件，其目的是儘量簡化以便讀者的理解什麼是物件圖。
在需求分析工作中基本上不需要使用物件圖，從嚴謹的角度來看某些情況下應該使用物件圖，但我往往還是會用類圖來處理，這樣更加簡便而且容易理解。我們將在類圖一章再次講解物件圖。
構件圖(Component Diagram)
構件圖也叫元件圖，兩個名字均符合UML中文術語標準。
一輛汽車由輪子、發動機等物理部件組成，一個軟體往往也是由很多“物理部件”(如：控制元件、重用構件等)組成的，構件圖就是用來描述軟體內部物理組成的一種圖。下圖是某許可權構件設計圖：
圖 1.4 某許可權構件設計圖
圖1.4右上方有這樣標誌 的矩形表示一個構件，構件可以再包含構件。
軟體需求分析工作中，需要用到構件圖的情況不是很多，以下情況除外：
1. 待開發的系統需要與第三方的系統、原有系統、某些老系統等互動，這時可用構件圖描述互動要求。
2. 客戶對軟體設計有某些特殊要求，這時可用構件圖來描述要求。
構件圖有時不會單獨使用，還會和部署圖一起結合使用。
部署圖(Deployment Diagram)
部署圖是用來描述系統如何部署、本系統與其他系統是怎樣的關係的一種圖，如下圖：
圖 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。
在那個專案以後，我便獨立擔當了多個專案管理及需求分析工作，沒有一個專案不應用UML，而且我毫不保留地傳授UML知識給專案組的其他成員。多年的工作進一步磨練了自己，對UML在實際工作中的應用有了更深刻的認識，形成自己的一套方法。
我的UML知識絕大部分來自於工作實踐，期間雖然也看過一些書籍，但對我的幫助很少。當然我最大的得益還是來自我的UML啟蒙老師，他在實際工作中教會了我UML，幫助我踏上自我成長的道路。
我的UML學習最大體會就是：實踐太重要了!如果有名師指導則會讓你事半功倍!希望本書能成為你在實際工作中學習和應用UML的好幫手!
UML學習難點
學UML之難，不在於學習語法，關鍵是要改變思維習慣。UML是一種新的工具，但同時也是代表了一種新的先進的思考方法，如果不能掌握這樣的方法，只能學到了UML的形，而沒有掌握其神髓。
要用好UML，你需要在平時多多培養下面的能力：
1. 書面表達能力。
2. 歸納總結能力。
3. “面向物件”的思維能力和抽象能力。
平時你可以利用各種機會來提升第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的需求分析高手不遠矣!