UML 統一塑模語言 (Unified Modeling Language) 是一種標準化的建模語言，可用於視覺化軟體設計和架構。常被誤會的是為何他是語言 (Language)? 因為任何系統化的、用於表示資訊或表達思想的方法都可以稱為語言。
UML 的起源可以追溯到三位著名的軟體工程師：Grady Booch、Ivar Jacobson 和 James Rumbaugh。在 1990 年代初，他們創建一個統一的建模語言，即 UML。在 1997 年，OMG 採納了 UML 作為一個標準，並從此持續管理和發展它。隨著時間的推移，UML 經歷了多次修訂，以滿足不斷變化的軟體工程需求。
簡單來說，UML所涵蓋的內容是表式法而非程序，UML是與程序無關的(Process Independent)，也就是說，無論以任何程式語言來開發軟體系統，都可以使用UML來建構軟體模型。
請參考 : 什麼是物件導向與UML？
所以你拿出UML建構的模型，別的工程師就了解你的軟體功能是什麼，因此UML可以說是工程師之間溝通軟體規格的語言。
例如我們可以用UML的Use Case Diagram (案例圖) 來表示線上購物系統與行為者的關係 :
在UML系統開發中有三個主要的模型：
(1) 功能模型：從使用者的角度展示系統的功能，包括使用個案圖 (Use Case Diagram)。
(2) 物件模型：採用物件，屬性，操作，關聯等概念展示系統的結構和基礎，包括類別圖 (Class Diagram)、物件圖 (Object Diagram)。
(3) 動態模型：展現系統的內部行為。包括序列圖 (Sequence Diagram)，活動圖 (Activity Diagram)，狀態圖 (State Diagram)。
UML 模型是對整個系統或應用的完整表示，它涵蓋了所有的實體、關係、行為和互動。通常，一個 UML 模型由多個 UML 圖組成，這些圖從不同的角度和層次描述系統。因此，當我們談論 "UML 模型" 時，我們通常指的是一個完整的系統描述，它包含了以下的 UML 圖。
UML 圖 (UML Diagrams)：
UML 提供了多種不同的圖，每種圖都針對系統的某一特定方面。以下是 UML 中的主要圖類型：
使用案例圖 (Use Case Diagram) * : 描述系統的功能以及用戶和系統之間的交互。
類別圖 (Class Diagram) * : 描述系統中的類、屬性、方法以及它們之間的關係。
物件圖 (Object Diagram) : 描述系統中的物件及其關聯，常用於表示類圖的特定實例。
活動圖 (Activity Diagram) * : 描述業務流程或系統操作的順序。
序列圖 (Sequence Diagram) * : 描述物件之間的交互和消息傳遞的順序。
通信圖 (Communication Diagram) : 描述物件之間的交互，以及它們如何通過消息進行通信。
時序圖 (Timing Diagram) : 描述物件的狀態和交互在時間軸上的變化。
狀態圖 (State Diagram) * : 描述物件的生命週期和狀態變化。
組件圖 (Component Diagram) : 描述系統的物理組件和它們之間的關係。
部署圖 (Deployment Diagram) : 描述軟體的部署方式，以及它在硬體上的配置。
封裝圖 (Package Diagram) : 描述系統的模組結構和各模組之間的依賴關係。
交互概覽圖 (Interaction Overview Diagram) : 描述交互的高層次流程，結合了活動圖和序列圖的特點。
組合結構圖 (Composite structure diagram) : 組合結構圖從 UML 2.0 起開始出現，描述個別分類器內部的參與者和關係，例如物件、使用案例、類別或合作。 組合結構圖通常附屬於更大的圖型，用來描述上層圖型中單一元素的內部結構或環境定義。
概要 (Profile Diagram) : 概要圖提供了一種通用擴展機制，用於為特定領域和平台定制 UML 模型。擴展機制允許以嚴格附加的方式細化標準語義，防止它們與標準語義相矛盾。
每種 UML 圖都有其特定的用途和語法，可用於從不同的角度描述和理解系統。
從以下UML 2.2的規格裡可以更清楚看到，UML 圖可以分成三大類型 : 結構圖 (Structure Diagram)、行為圖 (Behavior Diagram)、互動圖 (Interaction Diagram)。
想知道每個UML圖的詳細樣子，可以參考這篇文章"什麼是統一建模語言?"
所以UML 統一塑模語言的作用，你可以說是用來描述軟體系統的結構、行為、互動。拿一個電子商務網站的UML給另一個工程師看，他就知道這個電子商務網站是怎麼回事。
不過並不是每個UML圖都會用到，根據下圖來看，交互概覽圖 (Interaction Overview Diagram)、時序圖 (Timing Diagram)、概要圖 (Profile Diagram) 是比較少用的圖。
類別圖 (Class Diagram)、活動圖 (Activity Diagram)、序列圖 (Sequence Diagram)、使用案例圖 (Use Case Diagram)、狀態圖 (State Diagram)則是最常使用的。
參考資料 : 14 種 UML 圖的綜合指南
你想要開發一個電子商務網站，只要把UML圖做出來給工程師，工程師就知道如何設計你的電子商務網站，所以UML也可以看成是像蓋房子的藍圖，UML在軟體工程中的作用可以與建築中的藍圖相提並論。以下是這兩者之間的一些相似之處：
設計之前的規劃：在建築物真正開始建造之前，建築師會先創建藍圖來描述建築的各個方面。同樣地，軟體工程師在開始編碼之前，會使用 UML 來規劃和設計軟體的結構和行為。
提供視覺化表示：藍圖為建築專案提供了視覺化的表示，使所有相關人員都能理解建築的設計和結構。UML 圖也為軟體專案提供了類似的視覺化，幫助團隊成員理解軟體的工作方式和結構。
標準化：建築藍圖遵循特定的標準和規範，確保它們可以被所有建築專業人員理解。UML 也是一個標準化的建模語言，被廣泛接受和使用，確保不同的軟體團隊可以理解和使用它。
修改和迭代：當建築物在建造過程中需要進行更改時，藍圖可以輕鬆地進行修改。同樣，當軟體需求變更或出現問題時，UML 圖可以輕鬆地更新，以反映新的設計決策。
多層次的詳細程度：建築藍圖可能包括從整體布局到特定組件的詳細視圖。UML 也提供了從系統的高層次概述（如用例圖）到具體交互的詳細描述（如序列圖）的多種圖。
總的來說，UML 在軟體工程中的角色與建築中的藍圖非常相似，它們都是在實際建造或實施之前進行規劃和設計的工具。
在設計之前的規劃，應該有人會去聯想到DFD (Data Flow Diagram) 與ERD (Entity Relationship Diagram)，這兩個也是在做概念塑模時常用到的方法。
請參考 :
什麼是DFD (Data Flow Diagram 資料流程圖) ?
實體關係模型(Entity-relationship model)
Database Design
Data Flow Diagram (DFD) 與 Entity Relationship Diagram (ERD) 實作練習
DFD跟ERD與UML比較起來，差異是什麼?
DFD (Data Flow Diagram)、ERD (Entity-Relationship Diagram) 和 UML (Unified Modeling Language) 都是軟體工程和資料庫設計中常用的建模工具。但它們各自專注於不同的目的和方面。以下是這三者的比較：
DFD (Data Flow Diagram)
主要目的：DFD 主要用於描述系統中資料的流動。它顯示了資料如何從一個部分流向另一個部分，以及資料在途中如何被系統的各個組件或功能處理。
元件：DFD 包含實體 (entities)、處理 (processes)、資料存儲 (data stores) 和資料流 (data flows)。
不涉及的方面：DFD 不描述資料的具體結構或資料之間的關係。
ERD (Entity-Relationship Diagram)
主要目的：ERD 主要用於描述資料庫中資料實體之間的關係。它顯示了資料庫的結構，以及資料實體之間如何互相關聯。
元件：ERD 包含實體 (entities)、關係 (relationships) 和屬性 (attributes)。
不涉及的方面：ERD 不描述資料的流動或處理。
UML (Unified Modeling Language)
主要目的：UML 是一個通用的建模語言，用於描述軟體系統的結構和行為。它提供了多種圖，可以從不同的角度和層次描述系統。
元件：UML 包含多種圖，如類圖、活動圖、序列圖等，每種圖都有其特定的元件和語法。
不涉及的方面：UML 是一個綜合性的工具，涵蓋了系統的許多方面。但是，它不像 ERD 那樣專注於資料關係，也不像 DFD 那樣專注於資料流動。
總結來說： DFD專注於資料的流動和處理。 ERD專注於資料實體之間的關係。 UML是一個綜合性的建模工具，用於描述軟體系統的結構和行為。 雖然這三者有其各自的專長和目的，但在實際的軟體開發和資料庫設計中，它們往往會一起使用，以提供系統的完整視圖。
用白話來講，我會先用DFD來描述資料，用ERD來描述資料間的關係，再來把ERD轉換為UML的Class Diagram，這樣就弄清楚了資料庫的結構，後續再用其他的UML圖來描述軟體的結構、行為、互動了。
0 留言