UML是Unified Modeling Language統一塑模語言，它是用來描述物件導向的分析與設計(OOA&D)的一種方法，而使用OOA & OOD並不表示就一定是使用UML，OO的的設計觀念早在1960年代就出現了，當時是由Ole Jone Dahl所設計的Simula67語言引進這樣的思維的，類別的概念也是在Simula67帶進來的。後期1970~1980年代的為較有名的SmallTalk
UML是Unified Modeling Language統一塑模語言，它是用來描述物件導向的分析與設計(OOA&D)的一種方法，而使用OOA & OOD並不表示就一定是使用UML，OO的的設計觀念早在1960年代就出現了，當時是由Ole Jone Dahl所設計的Simula67語言引進這樣的思維的，類別的概念也是在Simula67帶進來的。後期1970~1980年代的為較有名的SmallTalk，且SmallTalk的建立者Alan Kay幾乎以Simula67為基礎的概念發展了SmallTalk，在SmallTalk中已經有物件、繼承、子類別等概念了。
到了1990年代才出現一些較著名的物件導向分析法，其中有Grady Booch的Booch方法，Ivar Jacobson的物件導向軟體工程(Object Oriented Software Engineering) OOSE、還有James Rumbaugh的物件塑模技巧(Object ModelingTechnique) OMT。
在1994年James Rumbaugh加入了Grady Booch的Rational公司，並在1995年10月發表了UM (Unified Method)，後來Ivar Jacobson也加入Rational公司並在1996年6月三個人共同發表了UML 0.9版，並正式改名稱為UML (統一塑模語言)。後來到了1997年的1月，在Rational公司的許多人一起努力之下才定義出一個完整的、功能較為強大、適合一般情況使用的UML 1.0版。並給務建管理組織 OMG (Object Management Group)審查，當中也發現一些問題並經過了近9個月的審查與改進，同年又再以UML 1.1版通過OMG的審查，成為物件塑模的標準，並且正式運用在軟體開發之上。
也因此要追朔UML發展的歷史可以追朔到這三位UML大師，Grady Booch、Ivar Jacobson和James Rumbaugh，他們也是UML軟體及描述標準的開發之父，
後來在2001年則推出了最新的UML統一模型語言1.4版，於2004年推出了2.0版。詳細的UML發展史可參考底下簡圖：
圖片取自http://w3.cyu.edu.tw/kwsheng
從圖片中可以知道UML出現在市場上可追朔到1995年。OMG組織正式採用的日期為1997年，而筆者真的開始接觸UML的時候已經是2001年的1.4版，不過當時許多的UML Case Tool還是只支援到1.3 版。
UML各版本之間的差異：
UML1.3與UML1.2版的差異主要是改善Use Case Diagram與Activity Diagramu一些表示法，如在Use Case中UML 1.2之前Actor 與 Use Case 的關係只有一種 Communicates (溝通／聯繫)關係，而在 UML 1.3 版為了與其他 UML 圖型有較為一致性的關係表示法，因此改為 Association(結合關係)。而且在Actor 之間也僅有一種關係，也就是所謂的 Generalization(一般化關係)，這也就是物件導向裡所謂的繼承的關係。然後在 Use Case(活動)之間在 UML 1.1 版時，也只有兩種關係，分別是 uses(使用關係)及 extends(延伸關係)，到了 UML 1.3 版，則拆解成三種關係，分別為 include(包含關係)，extend(延伸關係)以及 generalization(一般化關係)。後來UML 從 1.4 版到 1.5 版主要的改變是在 UML 中新加入動作語意 action semantic)，它是讓 UML 具有一些『程式語言能力』的一個必要的一個步驟，也就是所謂的MDA (Model Driven Architecture)模型驅動開發架構。這讓大家不用等到完整的 UML 2.0 版出現就可以先將 UML當成程式語言來使用。
在後來的UML 2.0其實在底層的塑模有很多的改變與擴充，比如說如狀態機擴充(state machine extension)、互動圖中的閘道(gateway)概念、與類別圖中的強力型態(power type)等等… 太細節的部分就不再深入了，一般來說最最主要的就是新增了一些圖形，如套件圖(package diagram)，互動概圖(interaction overview diagram)、時序圖(timing diagram)與合成結構圖(composite structure diagram)等，且在UML 2.0終將原先的合作圖(collaboration diagram)改名成通訊圖(communication diagram)。
目前UML最新版本為2.2版，在2.2版中共有14種圖形：
- 使用案例圖 (Use Case Diagram)
- 類別圖 (Class Diagram)
- 物件圖 (Object Diagram)
- 循序圖 (Sequence Diagram)
- 溝通圖 (Communication Diagram)
- 狀態圖 (State Diagrma)
- 活動圖 (Activity Diagram)
- 元件圖 (Component Diagram)
- 部署圖 (Deployment Diagram)
- 套件圖 (Package Diagram)
- 時序圖 (Timing Diagram)
- 互動概觀圖 (Interaction Overview Diagram)
- 複合結構圖 (Composite Structure Diagram)
- 輪廓圖 (Profile Diagram)
各圖形的用途及簡要說明如下：
使用案例圖 (Use Case Diagram)：
Use Case 是Jacobson於1994年發明了使用案例圖的方法。使用者案例是使用者觀點來看模形化的軟體設計，是由使用者觀點描述系統的行為者與系統間之互動行為與關係。從內部觀點來看，使用個案可描述系統做什麼 (What)。從外部觀點來看，可描述行為者與系統怎麼互動 (How) 。使用者案例可以幫助辨別系統服務。使用者案例可以被進一步被解構成小的使用者案例。
類別圖 (Class Diagram)：
用以表示系統存在之物件型態 (或稱類別) 及各物件型態間之靜態的資料結構或邏輯的關係，通常也表達類別之屬性、操作(Operation或稱Method)與類別間連結之限制／連結關係(Association)，要包括多重性(如：一對多、多對一、多對多..等關係)。
物件圖 (Object Diagram)：
通常用以描述系統於某一時點之靜態資料結構，該圖由一群相關物件及其連結所組成。
循序圖 (Sequence Diagram)：
這個圖形相信大家都不陌生，常使用到的一種圖形，描述系統個物件／類別運作時物件間的互動行為，著重以時間之先後順序為主軸，表達物件間的訊息傳遞與處理程序。
溝通圖 (Communication Diagram)：
此為UML 1.x 版之合作圖 (Collaboration Diagram)，在UML 2.0版的時候改名為溝通圖。它主要描述系統運作時物件間的互動行為，但比較著重表達相關物件間之連結結構的關係，並可以同時展現物件間之訊息傳遞活動。
狀態圖 (State Diagrma)：
用以表達物件在生命週期中的狀態變化。
活動圖 (Activity Diagram)：
通常用來(加強/表達)使用案例中不足以表達的部分，如：一系列事件的流程，包含工作流程和所需之作業活動，或執行某一作業之行為中之活動、轉換與條件等。一個活動可表示一個工作流程的步驟或一個運算執行的動作。
元件圖 (Component Diagram)：
通常就是描述系統之實體模組，是系統中可被替換的部分，如.NET平台可能就是Assembly、DLL等之間的關係。
部署圖 (Deployment Diagram)：
用於說明系統在實際應用時各軟硬體 ，如：處理器、處理元件，元件之配置與關聯，或甚至是硬體或網路基礎建設之拓撲等。
套件圖 (Package Diagram)：
通常用以表達系統中Package與其他群組元素的組成方式，或描述Package與Package之間的相依性。
時序圖 (Timing Diagram)：
所謂的時序圖著重物件間訊息傳遞的時間關係，並顯示詳細的時間資訊，常用於即時 (Real-time) 或嵌入式系統的塑模上。時序圖藉由狀態與時間軸、時間尺規等符號來表達物件在不同時間點上的狀態改變。
互動概觀圖 (Interaction Overview Diagram)：
而所謂的UML互動概觀圖其實是結合活動圖與互動圖來表達整體的控制流程，以活動圖為主幹，說明主要活動與控制流程 (Control Flow)，而細部活動則以互動圖 (包含循序圖、時序圖、溝通圖等) 來表示。
複合結構圖 (Composite Structure Diagram)：
用以表達某類別或元件於執行時期可能會產生之實例 (Instance) 與連結 (Link)，描述各物件如何於類別中協同合作，或各物件如何達成目標。可用於表達類別之內部結構 、使用類別之方式和物件間之合作關係三種情形。
輪廓圖 (Profile Diagram) ：
又有人稱作剖面圖，它能針對現存所謂的[基礎模型或稱超模型] (Meta-model) 中之基礎類別或稱超類別 (Meta-class) 來進行擴充，使其適用於不同用途，如此便可隨不同平台 (如JAVA、.NET等) 或領域 ，如：即時系統塑模或企業流程領域 (Business Process) 塑模來調整UML之超模型。
且Grady Booch於1999年時對UML在設計各種不同的圖形時提出五種不同的面向，因為一般而言在實際設計系統的塑模時因為觀點的不同，因此會有不同的面向，共有哪五個面向呢？使用一個經典的圖表示：
個觀點說明如下：
使用個案觀點 (Use Case View)
由描述系統行為的使用個案組成，此系統行為以使用者、分析師、測試者的觀點描述系統做什麼及操作情境，不涉及系統的軟硬體架構。
設計觀點 (Design View)
所謂的設計觀點是描述系統之類別、介面、彼此合作的情形及之間的互動方式。此觀點主要支援系統之功能面需求，意即著重表達系統應提供予使用者之服務。
流程觀點 (Process View)
此觀點較著重表達系統內部的處理程序或執行緒，比如說明系統績效 (Performance)、產出 (Throughput) 的部分與可擴充性 (Scalability) 。
實施觀點 (Implementation View)
因為通常系統在實際進行開發時可能會套用某些設計樣式，或是使用某些元件，這個面向主要在於表達系統的結構配置管理，描述系統主要由哪些元件與檔案組成的 (如實際的DLL檔案、在.NET 可能稱作Assembly)，元件與檔案如何以不同方式組合可實際執行之系統。
部署觀點 (Deployment View)
此觀點在於當系統實際運作時各子系統或元件配置的一個狀況，同一個系統有可能在同機器也可能跨機器間佈署，這時也可能牽涉到硬體部分，它表達系統執行時，硬體拓撲上或說各節點 (Nodes) 上的配置，並描述系統分析與設計的產出，及說明系統如何實作。
簽名：
學習是一趟奇妙的旅程
這當中，有辛苦、有心酸、也有成果。有時也會有瓶頸。要能夠繼續勇往直前就必須保有一顆最熱誠的心。
軟體開發之路（FB 社團）：https://www.facebook.com/groups/361804473860062/
Gelis 程式設計訓練營（粉絲團）：https://www.facebook.com/gelis.dev.learning/
如果文章對您有用，幫我點一下讚，或是點一下『我要推薦』，這會讓我更有動力的為各位讀者撰寫下一篇文章。
非常謝謝各位的支持與愛護，小弟在此位各位說聲謝謝!!! ^_^
