UML圖是基於UML（統一建模語言）的圖表，其目的是為了更好地理解，更改，維護或記錄信息，以可視化方式表示系統及其主角色，角色，動作，工件或類關於系統。
什麼是UML？
UML是代表統一建模語言的縮寫。簡而言之，UML是一種現代化的軟件建模和記錄方法。事實上，它是最流行的業務流程建模技術之一。
它基於軟件組件的圖形表示。正如老諺語所說：“一張圖片勝過千言萬語”。通過使用可視化表示，我們能夠更好地了解軟件或業務流程中可能存在的缺陷或錯誤。
UML是由於圍繞軟件開發和文檔的混亂而創建的。在20世紀90年代，有幾種不同的方式來表示和記錄軟件系統。需要出現一種更加統一的方式來直觀地表示這些系統，結果在1994-1996年，UML由三名在Rational Software工作的軟件工程師開發。它後來在1997年被作為標准採用，並一直保持這種標準，只獲得幾次更新。
草圖
在這種情況下，UML圖用於溝通系統的不同方面和特性。但是，這只是系統的頂層視圖，很可能不會包含執行該項目直到最後的所有必要細節。
- 前向設計- 草圖的設計在編寫應用程序之前完成。這樣做是為了更好地了解您嘗試創建的系統或工作流程。許多設計問題或缺陷都可以透露出來，從而改善整個項目的健康和福祉。
- 向後設計- 在編寫代碼之後，UML圖被繪製為不同活動，角色，參與者和工作流的文檔形式。
藍圖
在這種情況下，UML圖充當完全設計，僅需要係統或軟件的實際實施。通常，這是通過使用CASE工具（計算機輔助軟件工程工具）完成的。使用CASE工具的主要缺點是它們需要一定程度的專業知識，用戶培訓以及管理和員工承諾。
偽編程語言
UML不是像Java，C ++或Python這樣的獨立編程語言，然而，使用正確的工具，它可以變成偽編程語言。為了實現這個目標，整個系統需要在不同的UML圖中進行記錄，並且通過使用正確的軟件，圖可以直接轉換為代碼。如果繪製圖表花費的時間比編寫實際代碼花費的時間要少，那麼這種方法只能是有益的。
儘管UML是為建模軟件系統而創建的，但它已經在業務領域或非軟件系統中找到了一些採用。例如，通過活動圖形可視地表示電話銷售的流程流程。從訂單作為輸入的點開始，到完成訂單並給出特定輸出的點。
UML圖的類型
有幾種類型的UML圖，不管它是在實現之前還是之後（作為文檔的一部分）被設計，它們中的每一個都有不同的目的。包含所有其他類型的兩個最廣泛的類別是行為 UML圖和結構 UML圖。顧名思義，一些UML圖嘗試分析和描述系統或過程的結構，而其他描述系統，其參與者及其構建組件的行為。不同類型的細分如下：
行為UML圖
結構UML圖
在記錄系統和/或體系結構時，並不是所有14種不同類型的UML圖都定期使用。該帕累托原則似乎方面應用UML圖的使用，以及-圖中的20％正在使用的80％的時間開發人員。軟件開發中最常用的是：用例圖，類圖和序列圖。
活動圖
活動圖可能是進行業務流程建模的最重要的UML圖。在軟件開發中，它通常用於描述不同活動和行為的流程。這些既可以是順序的也可以是並行的。他們描述了一項活動所使用，消費或生產的物品以及不同活動之間的關係。以上所有內容在業務流程建模中都非常重要。
一個過程並不關注正在產生的東西，而是集中在導致彼此相互關聯的一系列活動上，並且開始和結束都是清楚的。上面的示例描述了在內容髮布過程中發生的一組活動。在商業環境中，這也被稱為業務流程映射或業務流程建模。
主要角色是作者，編輯和出版商。在該圖中，您可以看到如何使用菱形圖形來描述需要分支或重複過程的過程，即：循環。在本例中，當審閱者審閱草稿並確定需要完成某些更改時，會發生其中一個循環。然後作者修改草稿並再次將其拖放到管道中，供審查分析。
用例圖
系統的基石部分是系統滿足的功能要求。用例圖用於分析系統的高級需求。這些要求通過不同的用例來表達。我們注意到這個UML圖的三個主要組成部分： 功能需求- 表示為用例; 描述動作的動詞演員- 他們與系統互動; 演員可以是人，組織或內部或外部應用程序參與者和用例之間的關係- 用直線箭頭表示以下示例描述了庫存管理系統的用例UML圖。在這種情況下，我們有業主，供應商，經理，庫存管理員和庫存檢查員。
這是在線考試的一個例子: ( 單擊進行編輯 )
交互概述圖
交互概述UML圖可能是一些最複雜的圖。到目前為止，我們已經解釋了活動圖是什麼。另外，在一組行為圖中，我們有一個由四個圖組成的子集，稱為交互圖：
- 交互概述圖
- 時序圖
- 序列圖
- 通信圖
因此，交互概覽圖是由不同交互圖組成的活動圖。假設它是活動圖與交互圖的混合體，然而，大多數網站喜歡將它們視為專門的活動圖。這意味著您可以使用活動圖中使用的大多數註釋，並添加諸如交互，交互使用，時間限制，持續時間等元素。
交互概述圖側重於交互控制流程的概述。它是活動圖的變體，其中節點是交互或交互發生。交互概述圖描述了隱藏消息和生命線的交互。您可以鏈接“真實”圖表，並實現交互概覽圖內圖表之間的高度可導航性。
在下面的例子展示瞭如何使用UML圖來描述系統的動態行為，結構組織以及對象之間的交互。所有這些，同時考慮事件發生的時間和順序，從而關注事件和消息流的順序。
該圖有一個起點和終點，就像任何活動圖一樣。然後，在頂層視圖中，通過使用矩形框架描述交互和交互使用。在交互（矩形框架）內，我們包含了一個完整的獨立序列圖，其中包含三個主要角色：助理，中間件報告系統和檢查員。一旦動作序列完成，流動狀態就會分支出來，並重複以前的交互或者繼續進行新的交互，然後結束流動。
時序圖
定時UML圖表用於表示關注中心在時間上的對象關係。我們對這些對像是如何相互作用或相互改變不感興趣，而是我們想要表示對象和actor在線性時間軸上的行為。
每個參與者都是通過一條生命線表示的，這個生命線實質上是一條線，因為個體參與者從一個階段轉移到另一個階段。主要關注事件的持續時間和根據持續時間限制發生的變化。
時序UML圖的主要組件是：
- 生命線 -個人參與者
- 國家時間表 -一條生命線可以通過管道內的不同狀態
- 持續時間約束 -一個時間間隔約束，它表示要實現約束所需的持續時間
- 時間約束 -時間間隔約束，在此期間需要參與者完成某些事情
- 銷毀發生 -破壞個別參與者並描繪參與者生命線結束的消息發生
。它代表了 時序圖顯示了給定時間段內對象的行為。時序圖是序列圖的一種特殊形式。時序圖和時序圖之間的差異在於軸是反向的，以便時間從左到右增加，並且生命線顯示在分開的垂直排列的隔間中。視覺範式支持離散時間和一般價值生命線樣式。
下面給出了一個簡化的時序UML圖的例子
狀態機UML圖
狀態機UML圖（也稱為狀態圖）用於描述系統內組件的不同狀態。它採用名稱狀態機，因為該圖本質上是一台機器，它描述了一個對象的幾種狀態以及它如何根據內部和外部事件進行更改。
狀態圖是一個圖，其節點是狀態，其有向弧是狀態間的轉換，它描述由事件序列引起的序列。狀態圖通常模擬一個類的常見行為
在這個例子中，電話線路在通話開始時是空閒的。當電話從挂機中移除時，它會發出撥號音並可以接受撥號。輸入有效號碼後，電話系統會嘗試將呼叫和路由連接到適當的目的地。如果號碼或中繼線很忙，連接可能會失敗。如果連接成功，被叫電話開始振鈴。當再次挂機時，電話線路將回到閒置狀態。
序列UML圖
序列圖可能不僅是計算機科學界最重要的UML圖，而且也是商業應用程序開發的設計級模型。最近，由於其視覺上的自我解釋性，它們在描繪業務流程中變得流行起來。
顧名思義，序列圖描述了演員和對象之間發生的消息和交互的順序。參與者或對像只有在需要時或另一個對像想要與他們進行通信時才可以激活。所有通信都按照時間順序表示。為了獲得更好的想法，請查看下面的UML序列圖示例。
顧名思義，結構圖用來描述系統的結構。更具體地說，它用於軟件開發中，以表示系統的體系結構以及不同組件之間的相互關係（而不是它們的行為或通信方式，以及它們的立場）。
在這個例子中 UML 序列圖
1.客戶在搜索頁面上指定作者
2.系統驗證客戶的搜索條件
3.系統在目錄中搜索與指定作者相關的書籍
4.搜索完成後，系統在搜索結果頁面
5.如果客戶沒有輸入作者姓名，系統會顯示錯誤消息
這是在線序列圖的一個例子: ( 單擊進行編輯 )
通信圖
在UML 1.x中，通信圖以前稱為協作圖。顧名思義，這種類型的UML圖的主要焦點在於對象之間的通信。
由於核心組件是在對象之間交換的消息，我們可以像構建序列圖一樣構建通信圖。兩者之間唯一的區別在於通信圖中的對象與關聯連接一起顯示。
在視覺上，兩者的不同之處在於序列圖的結構是垂直的，消息流採用自上而下的時間順序。另一方面，通信UML圖使用數字方案和指向箭頭來描述消息流。
如果您在為流程或系統編寫文檔時必須在兩者之間進行選擇，則順序圖可能是更好的選擇。許多軟件工程師更喜歡順序圖，這不僅僅是因為它們結構更好，而且還因為它們在UML文檔中的可用註釋方面受到了更多關注。
另一方面，通信圖更容易設計，因為您可以在繪圖板上的任何位置逐字添加對象。畢竟，為了連接物體，它們只需要是編號序列的一部分，而不必彼此物理接近。
通信圖也是交互圖。它們傳遞與序列圖相同的信息，但它們專注於對象角色而不是消息發送的時間。在序列圖中，對象角色是頂點，消息是連接鏈接。
對象角色矩形標有類名或對象名（或兩者）。類名前面是冒號（：）。協作圖中的每條消息都有一個 序列號。頂級消息編號為1.同一級別的消息（在同一個呼叫期間發送）具有相同的小數前綴，但後綴為1,2等，這取決於它們何時發生。
類圖
類UML圖是軟件文檔中最常見的圖類型。由於現在大多數軟件都是基於面向對象的編程範例，所以使用類圖來記錄軟件是一種常識性的解決方案。發生這種情況是因為OOP基於類和它們之間的關係。
簡而言之，類圖包含類以及它們的屬性（也稱為數據字段）及其行為（也稱為成員函數）。更具體地說，每個類都有3個字段：頂部的類名稱，名稱下的類屬性，底部的類操作/行為。不同類別之間的關係（用連線表示）構成一個類圖。
類圖 通過顯示它的類和它們之間的關係來概述系統。類圖是靜態的-它們顯示交互的內容，但不顯示交互時會發生什麼。
下面的類圖模擬了零售目錄中的客戶訂單。中央階層是 秩序。與之相關的是 進行購買和 付款的 客戶。一個 付款 是四種之一： 現金， 檢查，信用卡或電匯。該訂單包含 OrderDetails （訂單項），每個訂單項都有相關的 項目。
對像圖
當我們討論結構UML圖時，我們別無選擇，只能深入研究與計算機科學相關的概念。在軟件開發中，類被視為抽像數據類型，而對象則是抽像類的實例。例如，如果我們有一個通用抽像類型的“Car”類，那麼“Car”類的一個實例就是“Audi”。
對象UML圖幫助軟件開發人員檢查他們創建的通用抽象結構（類圖）是否在實現時表示可行的結構，即：實例化類的對象時。一些開發人員將其視為準確性檢查的次要級別。 以下訂單管理系統顯示它們之間的關係。這個小類圖表明大學部門可以包含許多其他部門，下面的對像圖實例化類圖，並用一個具體的例子來代替它。
組件圖
在處理複雜系統的文檔時，組件UML圖可以幫助將系統分解為更小的組件。有時很難描繪系統的體系結構，因為它可能包含多個部門，或者可能採用不同的技術。
上面的示例顯示了較大組件的內部組件：
- 數據（賬戶和檢驗ID）通過右側的端口流入組件，並轉換為內部組件可以使用的格式。右側的接口被稱為必需接口，它表示組件執行其職責所需的服務。
- 然後數據通過各種連接傳遞給其他幾個組件，然後在左邊的端口輸出。左側的這些接口被稱為提供的接口，該接口代表由參展組件提供的服務。
- 需要注意的是，內部組件被一個大的“盒子”包圍著，這個盒子可以是整個系統本身（在這種情況下，右上角不會有組件符號），也可以是整個系統的子系統或組件（在這種情況下，“盒子”本身就是一個組件）。
複合結構圖
這種類型的UML圖不常用，因為它的功能非常特殊。它只表示一個類的內部結構和不同類組件之間的關係。
業務專業人員通常不會對複合結構圖感興趣，因為他們主要關注組件的頂層視圖以及它們如何與組件進行通信。經理知道某個類的特定數據成員如何與另一個類的數據成員相關幾乎是毫不相干的。
在下面，你可以找到一個簡單的例子來了解它的外觀。
- 複合結構圖顯示一個類的內部部分。
- 零件命名為：partName：partType [multiplicity]
- 聚合類是類的一部分，但部分不一定是類，部分是用於組成包含類的任何元素。
部署圖
部署圖用於可視化軟件和硬件之間的關係。更具體地說，通過部署圖，我們可以構建硬件組件（稱為節點）上的軟件組件（工件）如何部署的物理模型。
Web應用程序的典型簡化部署圖將包括：
- 節點（應用程序服務器和數據庫服務器）
- 工件（應用程序客戶端和數據庫架構
節點承載工件。數據庫模式在數據庫服務器上運行，應用程序客戶端在應用程序服務器上運行。
顧名思義，部署圖顯示了每個軟件組件的部署位置。
包圖
包圖就像我們上面解釋的用於部署UML圖的宏容器。不同的軟件包包含節點和工件。他們將模型圖和組件組織成組，與名字空間封裝不同名稱的方式相同。
最終，還可以通過其他幾個軟件包構建一個軟件包，以描繪更複雜的系統和行為。包圖的主要目的是顯示組成複雜系統的不同大型組件之間的關係。程序員發現這個抽像機會對於使用包圖來說是一個很好的優勢，特別是當一些細節可以被忽略時。
Profile圖
Profile文件圖不是典型的UML圖類型。實際上，它可以被看作是一種可擴展性機制，而不是其他任何圖表類型。
通過使用構造型，標記值和約束，您可以擴展和自定義現有的UML符號。輪廓圖就像一種語言，如果你講英語，你可以創建新的句子，如果你講輪廓圖，那麼你可以為UML圖創建新的屬性和語義。
- 定型 -用於擴展可用的UML元素。它們允許您創建，編輯或派生新的元素或構建塊，然後可以直接在圖表中使用。
- 標記值 -將此視為為已有模型添加新屬性。新的標記值將分別導致新的關鍵字。
- 約束 -這個詞是不言自明的，但是，將約束想像成可以添加到圖表中的新條件。例如，一個約束可能是：“未結餘額必須大於$ 3”。該限制可用於控制銀行系統何時應終止支票帳戶。
最近，UML圖已經成為一個非常強大的工具。在早期階段，只有IT行業的軟件開發人員和專業人員使用UML來記錄模型，系統和軟件架構。但是，現在，UML圖被用於不同行業，許多商業人士已經開始在日常工作中採用它們。
繪製UML圖的工具
就像生活中的任何其他事情一樣，為了正確地完成某件事，你需要合適的工具。為了記錄軟件，流程或系統，您需要提供正確的工具來提供UML註釋和UML圖表模板。有不同的軟件文檔工具可以幫助您繪製UML圖。它們通常分為以下幾個主要類別：
- 紙和筆 -這一個是不容易的。拿起一張紙和一支筆，從網上打開一個UML語法備忘單，並開始繪製任何你需要的圖表類型
- 在線工具 -有幾個可用於繪製UML圖的在線應用程序。他們中的大多數人免費提供免費試用版或有限數量的免費圖表。如果您正在尋找繪製UML圖表的長期解決方案，那麼為其中一個應用程序購買高級訂閱通常會更有好處。( Visual Paradigm Online Diagrammer )
- 免費在線工具 -這些工具與付費工具完全相同。主要區別在於，付費的還提供了針對特定UML圖的教程和現成模板。一個偉大的自由工具V isual Paradigm Online ( Express Edition ) 。
- 桌面應用程序 -用於UML圖表的典型桌面應用程序以及幾乎任何其他類型的圖表都是Microsoft Visio。它提供了高級選項和功能。唯一的缺點是你必須付錢。
結論
正如您現在可能已經註意到的那樣，使用UML圖來記錄流程和系統可能非常有益。不利的一面是，起初畫一個似乎很複雜。你必須學習語法，你需要選擇14種不同類型中的哪一種對工作最有效，等等。但是，一旦你開始思考UML標準，你將會更好地理解過程或系統你正在映射。
參考文獻