今天呢，主要是跟大家一起初步回顧和學習一下 UML。以及如何從入門到放棄……
首先跟大家說明一下，選擇跟大家分享UML，我覺得是我做的一個錯誤的選擇……
一、UML簡史
隨着市場所要求的軟件的複雜度不斷增大，軟件開發的方法學也在不斷進化。從沒有方法到簡單的功能分解法，再到數據流/實體關係法。進入20世紀90年代，面向對象分析設計（OOAD）方法學開始受到青睞，許多方法學家紛紛提出了自己的OOAD方法學。流行度比較高的方法學主要有Booch、Shlaer/Mellor、Wirfs-Brock負責驅動設計、Coad/Yourdon、Rumbaugh OMT和Jacobson OOSE。
這種百花齊放的局面帶來了一個問題：各方法學有自己的一套概念、定義和標記符號。造成了混亂，開發人員無從選擇，也妨礙了面向對象分析設計方法學的推廣。於是經過各方努力，1997年11月，OMG 組織（Object Management Group對象管理組織）發佈了統一建模語言（Unified Modeling Language，UML）
UML 是一種爲面向對象開發系統的產品進行說明、可視化、和編制文檔的標準語言
UML 作爲一種模型語言，它使開發人員專注於建立產品的模型和結構
UML 是不同於其他常見的編程語言，如Java等，它是一種繪畫語言，用來做軟件藍圖
UML 提出了一套 統一的，標準的建模符號，用於類的層次結構設計。
二、UML邏輯原理
UML是面向對象程序設計的建模語言。
基本邏輯是很簡單的：
將面向對象程序設計中的元素進行抽象，比如類還是接口，UML中稱之爲事物，就如同積木的基礎形狀。
將元素之間的聯繫關係進行抽象，比如到底是繼承還是組合（聚合），如同積木中的卡扣，可能有多種卡扣連接形式。
事物和關係，這兩者是UML的主體。事物就是面向對象程序設計中的元素，關係則是他們的相互聯繫形式，圖則是按照不同事物的組織形式進而產生的分類。
三、UML組成
上圖是UML的大致基本組成部分，並未全部列舉，只是一個大致的列舉。
事物是是實體抽象化的最終結果，是 UML 構建塊最重要的組成部分。最基本的是類和接口。關係是事物之間的聯繫的抽象分類。有了事物和聯繫，就可以繪製出各種各樣的UML圖。按照他們的邏輯功能性質，又有了圖的分類。
四、UML常用關係
|
關聯關係使用一條直線表示，比如 A與B關聯 
用於描述不同類的對象之間的結構關係，將多個類的實例聯繫在一起 是一種靜態關係，基本與程序的運行沒有關係 比如，部門與員工的關係，就是關聯關係 關聯關係一般不強調方向，表示互相“知道”對方，也就是存在引用 關聯關係有多重性 比如一對一關聯 一對多關聯等 可以任意關聯N對N關聯 如果特別強調方向，就使用箭頭，比如 那麼表示A知道B但是B不知道A。也就是說，關聯關係有兩種圖形。直線或者直線箭頭
關聯關係表示存在引用，比如員工類的定義中有“部門”屬性字段 |
實現關係是帶空心箭頭的虛線表示的，比如A實現B，箭頭指向父類、接口 實現可以狹隘的認爲是一種實現類與父類、接口的關係（其實在UML中實現的含義遠不止實現類這層含義） |
泛化關係是帶空心箭頭的直線表示的，比如A繼承B 用於說明繼承關係 泛化關係是從子類到父類的關係，箭頭指向的是父類 |
聚合關係是帶空心的菱形的直線表示的，比如 A聚合到B上，也就是B由A組成 聚合關係用於類圖，表達整體由部分構成的語義，比如部門由許多人員組成 整體和部分不是強依賴的，即使整體不存在，依然可以存在部分，即使沒有部門，人員仍舊存在 |
組合關係是帶實心的菱形的直線表示的，比如A組合成B，或者說B由A構成 表達整體擁有部分的含義，組合關係是一種特殊的強依賴的聚合關係 如果整體不存在，那麼部分也不存在了 比如，汽車由輪胎底盤發動機構成，汽車不存在了，自然也不存在發動機了 |
依賴關係使用帶箭頭的虛線表示，比如 A依賴B 用於描述一個對象在運行期間會使用到另外一個對象的關係 依賴關係是一種臨時性的，簡言之就是不同場景會發生變化 比如人和車 如果是駕駛場景，車依賴人（駕駛員），如果是乘車出行，那就是人依賴車（公交、出租） 很顯然，依賴關係比關聯關係更加弱 依賴關係是一種使用關係 比如一個類的方法中的局部變量、方法的參數或者對靜態方法的調用，都是一種依賴 |
五、UML基本表示法
下面的圖表示的 UML 類，該圖被分爲四個部分。
- 頂端部分被用來命名類。
- 第二個是用來顯示類的屬性。
- 第三部分是用來描述由類執行的操作。
- 第四部分是可選的顯示附加組件。
Student 類的 UML 大致如下：
六、UML 示例
下圖是從網上找的一個 UML 建模的示例。
七、思考
上圖看上去感覺還可以，條理清晰，但是這個東西真的有用嗎？我們需要去學習嗎？
作爲程序員我們做的事情是什麼呢，我們目前在做應該是編寫面嚮對象語言——也就是我們說的“源代碼”。
最初的源代碼是機器語言。程序員在紙帶或者卡片上打孔來表達0和1。後來，發現這個太累了，於是發明了一些助記符，這就是彙編語言。後來抽象級別提升，有高級語言C，面嚮對象語言Java 等。
如果人腦只需要編輯 UML模型就可以實現系統，那麼“模型就是源代碼”。當然最終這個模型也可以是X模型、Y模型。
UML是軟件需求分析、設計的強大工具，並非簡單介紹就可以認知的，學習成本和使用成本其實並不低。從我覺得這個可以分享並着手去學習了之後，個人認爲這個工具的使用簡單瞭解一下就可以，具體要去學習的應該是它的思想：如何去建模。至於根據 UML 生成代碼等功能沒有必要去了解，工具會過時，會被淘汰，但是思想可以一直髮光發熱。
今天回顧UML呢，並不是技術分享，就是聊一聊軟件方法。順帶拋出“建模”這個概念。在做一個系統的時候，我們要不要建模、怎樣去建模？很多人說建模是可以帶來競爭優勢的。這個也是我接下來要去了解、驗證和學習的。
Windows建議下載工具： WhiteStarUML
後記：
問大家一個問題：你們覺得編程語言發展的目的是爲了什麼？
個人感覺這個和我爲什麼而工作，爲什麼而加班是一樣的。我工作就是爲了不工作，加班也是爲了不加班。編程語言的發展就是爲了消除編程語言，一直是在追求一種簡單高效的方式去改變這個世界。爲此，當下我覺得軟件方法中的業務建模是很重要的。老大在年終總結上曾說過，有些人工作兩三年可能有行業三到五年的經驗，有些人工作了十年，可能只有兩年的行業經驗。成長是一個不斷審視自己、和自己對話的一個過程。