UML學習筆記（一）

為什麼重要

您應該使用UML嗎？一個字：是！……新的書、文章等等將會全部以UML作為符號。……如果你正要開始使用建模符號，您就應該直接學習UML。

—— Martin Fowler 1997

整合模組化語言UML（Unified Modeling Language）是一套用於物件導向系統建模的標準符號，在20世紀90年代幾經波折，終於得到對象管理組織OMG（Object Management Group）的支援，成為業界符號系統的統一標準。

因此，瞭解它是學習後面技術的前提。這並不是誇張，在看懂（並非精通）UML以前，我壓根沒明白《設計模式》，因為《設》裡面就用到象UML那樣的語言——OMT。

那UML無疑是重要，但它能很好的勝任建模工作嗎？關於這個問題，我沒有能力給您一個完美的回覆，相關的“討論”也在繼續，但下面的幾個事實相信會給您信心。

1。UML吸取多種建模語言的優點，包括三位全球頂級方法學家的貢獻。

2。它在風雨中崛起，經受考驗。

3。UML得到OMG組織及其成員的支援。

4。相當多的業界巨頭們也在使用著它。

學習旅程

UML體系是如此複雜，可能會讓您覺得難以把握。但是我們只要有選擇性的學習就足夠了，剩下的當日後有需要時再深入研究。

在學習之前，我們先來做一個說明，UML僅是一門語言，學習UML不等同於學習系統建模，它們的關係就好比學習中文和學習文章寫作那樣。只是很多情況下，我們都會把它們聯絡在一起而已。

那好，就讓我們開始吧，先來瀏覽一下UML的全貌。由於我們很難只從一個角度去完整描述一個系統的所有方面。因此UML提供了以下五種視圖，它們分工合作，又互相補充。

1)用況視圖（Use Case View）

2)設計檢視（Design View）或邏輯視圖（Logical View）

3)進程視圖（Process View）

4)實現視圖（Implementation View）或組件視圖（Component View）

5)實施視圖（Deployment View）

而這五個視圖又分別用到以下九種圖中的一種或幾種。

1)用況圖

2)類圖

3)對象圖

4)順序圖

5)共同作業圖表

6)狀態圖

7)活動圖表

8)構件圖

9)實施圖

總體關係如所示：

好，看一下相關資源。

1)《UML使用者指南》

此書出自名家，只是部分翻譯欠佳。閱讀時弄清楚上述五個視圖的概念和幾種常用的圖的表示即可，初次閱讀不必深究。

2)《UML和模式應用》

書中示範如何結合UML以增量方式開發一個系統，著重介紹了OO分析的技巧和法則。內容稍嫌羅嗦，但不失為一本好書。

3)《UML Distilled》

另一本入門好書，作為普通使用已經足夠。

4)《非程式員》第二期之《用UML設計Java應用程式》

閱讀這一短篇文章，可以快速瞭解如何在實際項目中使用UML。

5)http://www.uml.org/

UML的官方網站，可以找到很多有用資料。

6)http://www.umlchina.com/

它發行《非程式員》電子雜誌和記錄很多中文文檔，還有一個非常活躍的討論群組。

7)http://www.csdn.net/develop/

8)http://www-900.ibm.com/developerworks/cn

這兩個網站可以搜尋到很多UML的中文文章，只是比較零散，不大適合系統學習。

再來看一下UML工具。在這方面我沒有很好的經驗，且看看別人怎麼說。

1)《非程式員》第一期的“選擇一種UML建模工具”介紹了評價UML工具的一系列標準。

2)UML官方網站資源頁的“UML Tools”欄（連結）列出了極多的UML工具，可供選擇。

最後，我們討論一下幾個具有“爭議”性的概念——彙總（Aggregation）、組合（Composition）、相識
（Acquaintance）、關聯（Association）、依賴（Dependence）和引用（Reference）。它們極具相似性，在代碼的
實現上有些甚至是完全一樣的，然而從概念上理解和區分它們對我們的系統分析和設計是有重要意義的。

彙總是指一個對象擁有另一個對象，僅強調“擁有”。而組合是指一個對象是另一個對象的一部分，強調“不可分割”，兩個對象具有相同的生命週期。兩者的差別就好比創立一間公司時您可以不要僱員（擁有），但創造一個人時您卻不能丟掉了他的心（不可分割）。

關聯和依賴都是指一個對象知道另一個對象。區別在於關聯是一種結構關係，表現為一個對象能夠獲得另一個對象的執行個體引用並調用它的服務（即使用它）；依賴是一種使用關係，表現為一個對象僅僅是調用了另一個對象的服務。相識既可能是關聯，也可能是依賴。

引用是指那些指向對象的類屬性。實現組合、彙總和關聯時無可避免的要用到引用，但實現依賴時卻不一定用到。

總的來說，關聯和依賴是同級的；組合是一種彙總，而彙總是一種關聯；引用則是相對獨立的。

與此相關的文章有：

1)《UML使用者指南》第10章，Booch+詳細講述了依賴和關聯的含義和區別。

2)《設計模式》中文版第15~16頁，Gof講述了彙總和相識的差別。

3)《非程式員》第二期之《類之間設定成“關聯”OR“依賴”似乎全在個人喜好》是幾位朋友就彙總、關聯和依賴的區別進行的很好的討論。

至此，如果您對它們的定義持不同意見，又或者覺得難以理解的話，不妨把別人的那一套都拋開，自己把它們重定義一遍。反正我們又不是理論家，就算定義得不科學也沒關係，只要和我們的項目有關的人員都一致的理解和接受就可以了。畢竟有效溝通才是我們真正的目的。

實踐建議

按需剪裁。項目要用到什麼就學習什麼，暫時不用的就放下。我們的目的是當前的系統建模，而不是一下子成為UML高手。

自由擴充。結合我們的實際情況，在使用的過程中，要明確UML的重點是“溝通”，其次才是“公用”。UML本身有許多規則和約定，但沒必要一一遵守。只要有利於溝通的，我們就採用，否則就摒棄。通常我們的文檔只是在小範圍裡傳播，要統一理解並不困難。當然，當規則定好了後，最好就不要隨意更改了。