前言

通過看視頻，對於UML也有了一些初步的了解。前面也介紹了UML的三個基本塊、規則和機制，只是這些東西就像是一個個機器的零部件。要組合起來才幹發揮作用。

所以，實例才是驗證自己學習好壞標準，以下我結合機房收費系統畫了UML的九個實例圖，如有認為不合適的地方，請大家多多不吝賜教：

類圖（Class Diagram）

類圖是描寫敘述系統中的類，以及各個類之間的關系的靜態視圖。可以讓我們在正確編寫代碼曾經對系統有一個全面的認識，在系統的整個生命周期都是有效的。

實比例如以下：

對象圖(Object Diagram)

對象圖所使用的表示符號與類圖差點兒全然同樣，它是類圖的實例，它們的不同點在於對象圖僅僅是顯示類的對象實例，而不是實際的類。一個對象是類圖的一個實例，因為對象存在生命周期，因此對象圖僅僅能在系統某一時間段存在。對象圖是類圖的一種實例化圖，描寫敘述系統在某個時刻可能包括的對象和相互關系。實比例如以下：

用例圖(Use CaseDiagram)

它從用戶角度描寫敘述系統的功能。

說明的是誰要使用這個系統，以及他們使用該系統能夠做些什麽。用例圖描寫敘述了一系列的角色和使用案例及它們之間的關系。

一個用例圖包括了多個模型元素，如系統、參與者和用例，而且顯示了這些元素之間的各種關系，如泛化、關聯和依賴。實比例如以下：

活動圖（ActivityDiagram）

描寫敘述為滿足用例要求所要進行的活動以及活動間的約束關系有利於識別並行活動。

可以演示出系統中哪些地方存在功能。以及這些功能和系統中其它組件的功能怎樣共同滿足前面使用用例圖建模的商務需求。

活動圖是使用例圖所描寫敘述的行為詳細化。

實比例如以下：

狀態圖(State Diagram)

描寫敘述一類的對象的全部可能的狀態以及事件發生時狀態的轉移條件。通常狀態圖是對類圖的補充，實際上並不須要為全部的類繪制狀態圖，而僅僅須要為那些有多個狀態、而且其行為受外界環境的影響而會發生改變的類繪制狀態圖。能夠捕捉對象、子系統和系統的生命周期。

他們能夠告知一個對象能夠擁有的狀態，而且事件（如消息的接收、時間的流逝、錯誤、條件變為真等）會怎麽隨著時間的推移來影響這些狀態。一個狀態圖應該連接到全部具有清晰的可標識狀態和復雜行為的類；該圖能夠確定類的行為，以及該行為怎樣依據當前的狀態變化，也能夠展示哪些事件將會改變類的對象的狀態。實比例如以下：

序列圖(SequenceDiagram)

用於顯示對象間的動態合作關系。它強調對象之間消息發送的順序，同一時候也顯示對象之間是怎樣交互的（交互過程），它強調的是時間和順序。

實比例如以下：

協作圖(CollaborationDiagram)

和序列圖相似。它也顯示對象間的動態合作關系，只是，除了顯示信息交換外，協作圖還顯示對象以及它們之間的關系，它強調的是通信關系（怎樣通信的）。能夠看成是類圖和順序圖的交集。

實比例如以下：

構件圖(ComponentDiagram)

描寫敘述用來建模的軟件構件（如：代碼部件，jar文件、EJB文件等）的物理結構以及各部件之間的依賴關系。一個部件可能是一個資源碼部件、產品、文件、一個二進制部件或一個可運行部件。

構件圖有助於分析和理解部件之間的相互影響程度。這些圖由構件標記符和構件之間的關系構成。實比例如以下：

部署圖(Deployment Diagram)

描寫敘述一個系統的拓撲結構，定義系統中軟硬件的物理體系結構。它能夠顯示實際的計算機和設備（用節點表示）以及它們之間的連接關系。也可顯示連接的類型及部件之間的依賴性。

在節點內部。放置可運行部件和對象，以顯示節點跟可運行軟件單元之間的相應關系。

比如計算機和設備，以及它們之間是怎樣連接的。部署圖的使用是開發者、系統集成人員和測試人員。

實比例如以下：

總結：

這九種圖在軟件開發中負擔著各自的作用。開發的不同階段，可能會用到不同的UML圖。這就須要對它有足夠的熟悉。才幹夠非常好的去完畢一個系統的完整的UML圖。所以。我僅僅是每一個圖畫了一個小樣例。認知有限，希望大家多多指導。

UML圖與機房收費系統實例