1. UML基礎知識

UML這三個字母的全稱是Unified Modeling Language，直接翻譯就是統一建模語言，簡單地說就是一種有特殊用途的語言。

UML由1.0版發展到1.1、1.2、…，到現在的2.0、2.x，本書將會以2.x版本爲基礎開展討論

2. UML有什麼用?

有很多人認爲，UML的主要用途就是軟件設計!也有人認爲，如果你不是開發人員，是難以理解UML的。

然而我第一次在實際工作中應用UML的卻不是軟件設計，而是軟件需求分析!當時我們和客戶面對面溝通調研需求的時候，直接用類圖、順序圖、活動圖、用例圖等UML。我們並沒有因此和客戶無法溝通，反而是溝通得更加順暢。客戶在我們的引導下，很快就會讀懂這些UML圖，因爲UML圖，讓我們和客戶的溝通效率和效果更好!你可能覺得很神奇，在後續章節中，我將會爲你逐一揭開神奇背後的“祕密”。

UML可幫助我們做軟件需求分析和軟件設計的工作，在我工作中大概各佔了50%的比例，當然在你的實際工作中不一定是這樣的比例。UML會讓你的需求分析或者軟件設計工作更上一層樓，本書將會介紹UML在需求分析方面的最佳實踐。

UML應用於軟件需求分析時，其學習門檻將會大大降低!語法複雜度會降低，而且你基本不需要掌握軟件開發的知識。只要你對軟件需求分析感興趣，認真學習和應用UML，就很有機會成爲軟件需求分析高手。

3. UML的分類

種類	UML圖	實際應用情況
結構型的UML（Structure Diagram）	類圖（Class Diagram）	必使用，分析業務概念
	對象圖（Object Diagram）	基本不使用用
	構件圖（Component Diagram）	必使用，用於分析IT基礎架構、軟件架構等
	部署圖（Deployment Diagram）	必使用，用於分析IT基礎架構、軟件架構等
	包圖（Package Diagram）	很少使用
行爲型的UML（Behavior Diagram）	活動圖（Activity Diagram）	必使用至少其中一種用於分析業務流程，大部分情況下至少會用到其中兩種圖
	狀態機圖（State Machine Diagram）
	順序圖（Sequence Diagram）
	通信圖（Communication Diagram）	基本不使用
	用例圖（Use Case Diagram）	必使用
	時序圖（Timing Diagram）	基本不使用

3.1 UML圖爲什麼會分爲結構型和行爲型兩種呢?

顧名思義，結構型的圖描述的是某種結構，這種結構在某段時間內應該是穩定的，“靜態”的;而結構型的圖描述的是某種行爲，是“動態”的。

分析系統需求時，我們會面對很多業務概念，它們之間會有某些關係，這些內容可以看成是“靜態”的，我們可以利用UML的結構性的圖來分析。同時，業務會涉及大量的流程、過程等，這些內容是“動態”的，我們可以用行爲型的UML圖來分析。

在我們軟件設計時，我們需要考慮需要那些類、哪些構件、系統最後怎樣部署等，這些內容可以看成是“靜態”的，我們可以利用UML的結構型的圖來設計。同時，我們也需要考慮軟件如何和用戶交互，類、構件、模塊之間如何聯繫等“動態”內容，我們可以利用行爲型的圖來設計。

所謂“靜態”和“動態”不是絕對的，下文我們將會進一步介紹結構型的UML和行爲型的UML。通過下面的學習，你將會初步認識UML的各種圖，你可能還會有很多問題，本章的主要目的是讓你對UML有一個宏觀的認識，帶着你的問題繼續閱讀後面的章節吧!

4. 結構型的UML(Structure Diagram)

4.1 類圖(Class Diagram)

請看下面這個類圖：

圖 1.1 某模具系統類圖

此圖截取自某模具管理系統的業務概念分析圖，圖中一個一個的矩形就是類，這些類之間有各種線條連接，這些線條表示類之間的關係。類圖是分析業務概念的首選，類圖可能是使用率最高的UML圖。

再看下面這個Person類圖，這時軟件設計時用到的一個圖：

圖 1.2 Person類圖

該Person類有以下屬性(Attribute)：Name(姓名),Sex(性別),Department(部門)等，有以下操作(Operation)：Work(工作)等。類有屬性和操作，但用類圖分析業務模型時，往往不需要使用操作，如圖1.1中的類就只有屬性。

Attribute有特性、特徵等譯法，Operation也稱作方法，但本書遵循UML中文術語標準，即Attribute爲屬性，Operation爲操作。

4.2 對象圖(Object Diagram)

一般情況下只有在軟件開發中才會使用到對象圖，下面的內容以開發的角度來說明對象圖，如果你沒有開發經驗，閱讀起來可能有一點難度。

圖1.2中的Person類，用代碼實例化如下：

Person person = new Person();
……

類(Class)實例化後就是對象(Object)，對象person是類Person的實例，上述代碼可以用對象圖表示如下：

圖 1.3 Person類的對象圖

對象圖和類圖的樣子很相似，對象是類的實例化，“person : Person”表示對象person是類Person的實例。對象圖往往只在需要描述複雜算法時纔會使用，畫出來的對象圖往往不會只有一個對象，該圖只畫了一個對象，其目的是儘量簡化以便讀者的理解什麼是對象圖。

在需求分析工作中基本上不需要使用對象圖，從嚴謹的角度來看某些情況下應該使用對象圖，但我往往還是會用類圖來處理，這樣更加簡便而且容易理解。我們將在類圖一章再次講解對象圖。

4.3 構件圖(Component Diagram)

構件圖也叫組件圖，兩個名字均符合UML中文術語標準。

一輛汽車由輪子、發動機等物理部件組成，一個軟件往往也是由很多“物理部件”(如：控件、重用構件等)組成的，構件圖就是用來描述軟件內部物理組成的一種圖。下圖是某權限構件設計圖：

圖 1.4 某權限構件設計圖

圖1.4右上方有這樣標誌的矩形表示一個構件，構件可以再包含構件。

軟件需求分析工作中，需要用到構件圖的情況不是很多，以下情況除外：

待開發的系統需要與第三方的系統、原有系統、某些老系統等交互，這時可用構件圖描述交互要求。
客戶對軟件設計有某些特殊要求，這時可用構件圖來描述要求。

構件圖有時不會單獨使用，還會和部署圖一起結合使用。

4.4 部署圖(Deployment Diagram)

部署圖是用來描述系統如何部署、本系統與其他系統是怎樣的關係的一種圖，如下圖：

圖 1.5 某24小時便利店的管理系統部署圖

圖中一個個立體的矩形是部署圖的“節點”，一個節點表示一個物理的設備，節點之間的線條表示節點間的物理連接關係。

大部分客戶都會具備一定的IT基礎環境(如具備局域網、一些服務器、某些軟件平臺等)，軟件系統需要基於當前的IT基礎環境來規劃，這時我們可以使用部署圖來做這個規劃。

分析系統的需求，不能忽略系統架構、部署、IT架構等方面的要求，我們要基於客戶當前的IT基礎環境，做一個最符合客戶利益的規劃。

要活用構件圖、部署圖來分析需求，需要具備一定的IT基礎架構知識和軟件設計知識，如果你還不具備相關知識，那麼可以考慮抓緊補充相關知識。不過需求分析工作更多的還是分析業務，提煉功能性需求，這部分工作能做好是相當不容易的事情。對於技術方面的非功能性需求分析，可交由有技術背景的專業人士負責。

4.5 包圖(Package Diagram)

Package有“打包”的意思，包圖的主要用途是“打包”類圖。用類圖描述業務概念時，很多時候會因爲業務類太多，而導致類圖非常龐大，不利於閱讀，這時可以將某些類放入“包”中，通過包圖來組織業務概念圖。

下圖是包圖的一個示例：

圖 1.6 包圖

圖中好像文件夾樣子的就是一個“包”，包之間的線條表示包之間的關係。

5. 行爲型的UML(Behavior Diagram)

活動圖、狀態機圖、順序圖處於三種不同的角度來描述流程，是分析業務流程的三種不同利器，下面將會逐一說明。

5.1 活動圖(Activity Diagram)

我們將起牀到出門上班這個過程畫成活動圖，可能是這樣的：

圖 1.7 起牀到出門上班的活動圖

活動圖中的一個圓邊框框表示一個“活動”，多個活動之間的帶箭頭線條表示活動的先後順序，該圖只是表達了一個順序流程，活動圖還可以表達分支結構。如果你以前曾學過流程圖的話，你會發現活動圖和流程圖很相似。活動圖可能是三種能表示流程的UML圖中最接近我們思維習慣的一種，下面來學習另外兩種能表達流程的圖。

5.2 狀態機圖(State Machine Diagram)

狀態機圖又叫狀態圖，但狀態圖這個譯名並沒有譯出Machine的意思。

狀態機圖從某個物品的狀態是如何變化的角度來展示流程，下圖某請假條審批流程：

圖 1.8 請假處理流程

整個請假審批流程是圍繞“請假條”這個物體進行的，隨着不同的審批階段，請假條具備不同的狀態。我們分析業務流程時會發現很多流程其實是圍繞某個物品進行的，這時可考慮使用狀態機圖。

5.3 順序圖(Sequence Diagram)

你去餐廳吃飯，向服務員點餐到服務員送菜上來，這個過程用順序圖可表示如下：

圖 1.9 點菜的順序圖

該圖有三個“小人”，每個“小人”下面的文字說明(如：顧客)表示其代表的角色。角色與角色之間有一些線條鏈接，表示角色之間是如何交互的。該圖表示的意思是：顧客向服務員點菜後，服務員將點菜信息傳遞給廚師，然後廚師做菜，最後再由服務員送菜給你。

點菜過程涉及幾個環節，每個環節均由不同的角色來負責，如果遇到類似的情況，你可以考慮使用順序圖來分析。用順序圖來分析的好處是能清晰表達整個過程所參與的角色，角色與角色之間的關係，各角色是如何被捲入這個過程當中的。

5.4 通信圖(Communication Diagram)

UML1.1時，該圖英文名爲Collaboration Diagram;UML2.x時，英文名爲Communication Diagram。將英文名字直接翻譯，原來的英文名字可譯爲協作圖，而新的英文名字譯爲通信圖。

通信圖是順序圖的另外一種畫法，點菜的順序圖，如果用通信圖來畫可表示如下：

圖 1.10 點菜的通信圖

三個“小人”分表表示三種角色：顧客、服務員、廚師;角色之間有直線聯繫表示他們之間有關係;帶序號的文字和箭頭，表示角色之間傳遞的信息。

順序圖更強調先後順序，通信圖更強調相互之間的關係。我覺得順序圖實用性更好一點，比通信圖能表達更多的信息，更容易讀懂，在需求分析工作中我基本不會使用通信圖。

5.5 用例圖(Use Case Diagram)

下圖是用例圖的示意圖：

圖 1.11 用例圖

用例圖表達的是什麼角色通過軟件系統能做什麼事情，我們可以使用用例圖系統地表達軟件系統的絕大部分需求。

5.6 時序圖(Timing Diagram)

時序圖也叫時間圖，時序圖是UML中文術語標準的說法，而時間圖不是標準的說法。

時序圖是表示某東西的狀態隨時間變化而變化的一種圖，參見下圖：

圖 1.12 燈的開關狀態隨時間變化圖

此圖表示在0秒到30秒，燈的狀態是關的，30-60秒燈的狀態爲開，60秒後狀態爲關。

在實際工作中我基本上沒有試用過時間圖。

6. 如何學好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”卻沒有這麼容易，需要長期的鍛鍊。

7. UML學習難點

學UML之難，不在於學習語法，關鍵是要改變思維習慣。UML是一種新的工具，但同時也是代表了一種新的先進的思考方法，如果不能掌握這樣的方法，只能學到了UML的形，而沒有掌握其神髓。

要用好UML，你需要在平時多多培養下面的能力：

書面表達能力。
歸納總結能力。
“面向對象”的思維能力和抽象能力。

平時你可以利用各種機會來提升第1和第2種能力，如多寫寫項目文檔、寫寫日記或博客等，多思考和總結平時自己的工作得失等。

第3種能力說起來有點虛，大家在大學中可能也學過相關知識。訓練這種能力的最好方法就是多應用類圖，我們將會在類圖的章節再重點介紹，通過實例來體會什麼才叫“面向對象”!

本書將會重點培養你的這三種能力，只要你有進步之心，多練習、多實踐、多思考、多總結，一定會取得長足進步!

8. 小結

本章的主要目標是讓你不需要閱讀全書的情況下，就可以瞭解到UML的全貌，大概知道UML各種圖的用途，同時給你說明學習UML的難點，爲最終活用UML做好準備。下面我們一起來複習一下本章的主要內容：

UML是Unified Modeling Language的簡稱，是軟件開發界的一套標準，UML不僅可用於軟件設計，也可以用於軟件需求分析。但UML並不是強制標準，我們應該善用包括UML在內的各種標準來提高我們的水平。

UML可分爲兩類：結構型、行爲型，結構性的UML有：類圖、對象圖、構件圖、部署圖、包圖，行爲型的圖有活動圖、狀態機圖、順序圖、通信圖、用例圖、時間圖。

類圖是業務概念模型分析的有利武器，也是面向對象分析能力的強有力訓練工具。

對象圖在需求分析工作中並不常用。

構件圖、部署圖是分析IT基礎架構、軟件架構等方面需求的有利分析工具，但需要你具備IT基礎架構、軟件設計方面的知識和經驗。

包圖可用來組織類圖，在需求分析工作中應用的機會不是很大。

活動圖、狀態機圖、順序圖是分析業務流程的強力武器。活動圖的表達思路與流程圖很類似，很容易掌握，而且大部分情況下都可以使用活動圖來分析業務流程;某流程如果是圍繞某個物品進行，該物品在流程中轉換多種狀態，那麼使用狀態機圖來分析是首選;用順序圖來分析的好處是能清晰表達整個過程所參與的角色，角色與角色之間的關係，各角色是如何被捲入這個過程當中的。

通信圖可以看作是順序圖的另外一種表達形式，順序圖更強調先後順序，通信圖更強調相互之間的關係。而從我的工作經驗看，順序圖更加實用一點。

有人會將用例圖稱作“公仔圖”，用例圖表達的是什麼角色通過軟件系統能做什麼事情，我們可以使用用例圖系統地表達軟件系統的絕大部分需求。

時間圖是表示某東西的狀態隨時間變化而變化的一種圖，我在實際工作中很少有機會能用到這種圖。

學UML之難，不在於學習語法，避免陷入UML的認識誤區，多練習、多實踐，培養良好的“think in UML”思想，鍛鍊面向對象分析的能力，成爲活用UML的需求分析高手不遠矣!

（轉載）UML入門