最經常使用的UML圖包括：用例圖、類圖、序列圖、狀態圖、活動圖、組件圖和部署圖

(轉)

用例圖

用例圖描述了系統提供的一個功能單元。用例圖的主要目的是幫助開發團隊以一種可視化的方式理解系統的功能需求，包括基於基本流程的"角色" （actors，也就是與系統交互的其餘實體）關係，以及系統內用例之間的關係。用例圖通常表示出用例的組織關係--要麼是整個系統的所有用例，要麼是完 成具備功能（例如，全部安全管理相關的用例）的一組用例。要在用例圖上顯示某個用例，可繪製一個橢圓，而後將用例的名稱放在橢圓的中心或橢圓下面的中間位 置。要在用例圖上繪製一個角色（表示一個系統用戶），可繪製一我的形符號。角色和用例之間的關係使用簡單的線段來描述，如圖1所示。

圖1：示例用例圖

圖字（從上到下）：CD銷售系統；查看樂隊CD的銷售統計；樂隊經理；查看Billboard 200排行榜報告；唱片經理；查看特定CD的銷售統計；檢索最新的Billboard 200排行榜報告；排行榜報告服務

用例圖一般用於表達系統或者系統範疇的高級功能。如圖1所示，能夠很容易看出該系統所提供的功能。這個系統容許樂隊經理查看樂隊CD的銷售統計報告 以及Billboard 200排行榜報告。它也容許唱片經理查看特定CD的銷售統計報告和這些CD在Billboard 200排行榜的報告。這個圖還告訴咱們，系統將經過一個名爲"排行榜報告服務"的外部系統提供Billboard排行榜報告。

此外，在用例圖中，沒有列出的用例代表了該系統不能完成的功能。例如，它不能提供給樂隊經理收聽Billboard 200上不一樣專輯中的歌曲的途徑 -- 也就是說，系統沒有引用一個叫作"收聽Billboard 200上的歌曲"的用例。這種缺乏不是一件小事。在用例圖中提供清楚的、簡要的用例描述，項目贊助商就很容易看出系統是否提供了必須的功能。

 

 

類圖

類圖表示不一樣的實體（人、事物和數據）如何彼此相關；換句話說，它顯示了系統的靜態結構。類圖可用於表示邏輯類，邏輯類一般就是業務人員所 談及的事物種類--搖滾樂隊、CD、廣播劇；或者貸款、住房抵押、汽車信貸以及利率。類圖還可用於表示實現類，實現類就是程序員處理的實體。實現類圖或許 會與邏輯類圖顯示一些相同的類。然而，實現類圖不會使用相同的屬性來描述，由於它極可能具備對諸如Vector和HashMap這種事物的引用。

類在類圖上使用包含三個部分的矩形來描述，如圖2所示。最上面的部分顯示類的名稱，中間部分包含類的屬性，最下面的部分包含類的操做（或者說"方法"）。

圖2：類圖中的示例類對象

根據個人經驗，幾乎每一個開發人員都知道這個類圖是什麼，可是我發現大多數程序員都不能正確地描述類的關係。對於像圖3這樣的類圖，您應該使用帶有頂 點指向父類的箭頭的線段來繪製繼承關係1，而且箭頭應該是一個徹底的三角形。若是兩個類都彼此知道對方，則應該使用實線來表示關聯關係；若是隻有其中一個 類知道該關聯關係，則使用開箭頭表示。

圖3：一個完整的類圖，包括了圖2所示的類對象

在圖3中，咱們同時看到了繼承關係和兩個關聯關係。CDSalesReport類繼承自Report類。一個CDSalesReport類與一個 CD類關聯，可是CD類並不知道關於CDSalesReport類的任何信息。CD類和Band類都彼此知道對方，兩個類彼此均可以與一個或者多個對方類 相關聯。

一個類圖能夠整合其餘許多概念，這將在本系列文章的後續文章中介紹。

 

回頁首

 

序列圖

序列圖顯示具體用例（或者是用例的一部分）的詳細流程。它幾乎是自描述的，而且顯示了流程中中不一樣對象之間的調用關係，同時還能夠很詳細地顯示對不一樣對象的不一樣調用。

序列圖有兩個維度：垂直維度以發生的時間順序顯示消息/調用的序列；水平維度顯示消息被髮送到的對象實例。

序列圖的繪製很是簡單。橫跨圖的頂部，每一個框（參見圖4）表示每一個類的實例（對象）。在框中，類實例名稱和類名稱之間用空格/冒號/空格來分隔，例 如，myReportGenerator : ReportGenerator。若是某個類實例向另外一個類實例發送一條消息，則繪製一條具備指向接收類實例的開箭頭的連線，並把消息/方法的名稱放在連 線上面。對於某些特別重要的消息，您能夠繪製一條具備指向發起類實例的開箭頭的虛線，將返回值標註在虛線上。就我而言，我總喜歡繪製出包括返回值的虛線， 這些額外的信息可使得序列圖更易於閱讀。

閱讀序列圖也很是簡單。從左上角啓動序列的"驅動"類實例開始，而後順着每條消息往下閱讀。記住：雖然圖4所示的例子序列圖顯示了每條被髮送消息的返回消息，但這只是可選的。

圖4：一個示例序列圖

經過閱讀圖4中的示例序列圖，您能夠明白如何建立一個CD銷售報告（CD Sales Report）。其中的aServlet對象表示驅動類實例。aServlet向名爲gen的ReportGenerator類實例發送一條消息。該消息 被標爲generateCDSalesReport，表示ReportGenerator對象實現了這個消息處理程序。進一步理解可發 現，generateCDSalesReport消息標籤在括號中包括了一個cdId，代表aServlet隨該消息傳遞一個名爲cdId的參數。當 gen實例接收到一條generateCDSalesReport消息時，它會接着調用CDSalesReport類，並返回一個aCDReport的實 例。而後gen實例對返回的aCDReport實例進行調用，在每次消息調用時向它傳遞參數。在該序列的結尾，gen實例向它的調用者aServlet返 回一個aCDReport。

請注意：圖4中的序列圖相對於典型的序列圖來講太詳細了。然而，我認爲它纔是足夠易於理解的，而且它顯示瞭如何表示嵌套的調用。對於初級開發人員來講，有時把一個序列分解到這種詳細程度是頗有必要的，這有助於他們理解相關的內容。

 

回頁首

 

狀態圖

狀態圖表示某個類所處的不一樣狀態和該類的狀態轉換信息。有人可能會爭論說每一個類都有狀態，但不是每一個類都應該有一個狀態圖。只對"感興趣的"狀態的類（也就是說，在系統活動期間具備三個或更多潛在狀態的類）才進行狀態圖描述。

如圖5所示，狀態圖的符號集包括5個基本元素：初始起點，它使用實心圓來繪製；狀態之間的轉換，它使用具備開箭頭的線段來繪製；狀態，它使用圓角矩 形來繪製；判斷點，它使用空心圓來繪製；以及一個或者多個終止點，它們使用內部包含實心圓的圓來繪製。要繪製狀態圖，首先繪製起點和一條指向該類的初始狀 態的轉換線段。狀態自己能夠在圖上的任意位置繪製，而後只需使用狀態轉換線條將它們鏈接起來。

圖5：顯示類經過某個功能系統的各類狀態的狀態圖

圖5中的狀態圖顯示了它們能夠表達的一些潛在信息。例如，從中能夠看出貸款處理系統最初處於Loan Application狀態。當批准前（pre-approval）過程完成時，根據該過程的結果，或者轉到Loan Pre-approved狀態，或者轉到Loan Rejected狀態。這個判斷（它是在轉換過程期間作出的）使用一個判斷點來表示--即轉換線條間的空心圓。經過該狀態圖可知，若是沒有通過Loan Closing狀態，貸款不可能從Loan Pre-Approved狀態進入Loan in Maintenance狀態。並且，全部貸款都將結束於Loan Rejected或者Loan in Maintenance狀態。

 

回頁首

 

活動圖

活動圖表示在處理某個活動時，兩個或者更多類對象之間的過程控制流。活動圖可用於在業務單元的級別上對更高級別的業務過程進行建模，或者對 低級別的內部類操做進行建模。根據個人經驗，活動圖最適合用於對較高級別的過程建模，好比公司當前在如何運做業務，或者業務如何運做等。這是由於與序列圖 相比，活動圖在表示上"不夠技術性的"，但有業務頭腦的人們每每可以更快速地理解它們。

活動圖的符號集與狀態圖中使用的符號集相似。像狀態圖同樣，活動圖也從一個鏈接到初始活動的實心圓開始。活動是經過一個圓角矩形（活動的名稱包含在 其內）來表示的。活動能夠經過轉換線段鏈接到其餘活動，或者鏈接到判斷點，這些判斷點鏈接到由判斷點的條件所保護的不一樣活動。結束過程的活動鏈接到一個終 止點（就像在狀態圖中同樣）。做爲一種選擇，活動能夠分組爲泳道（swimlane），泳道用於表示實際執行活動的對象，如圖6所示。

圖6：活動圖，具備兩個泳道，表示兩個對象的活動控制：樂隊經理，以及報告工具

圖字（沿箭頭方向）：樂隊經理；報告工具；選擇"查看樂隊的銷售報告"；檢索該樂隊經理所管理的樂隊；顯示報告條件選擇屏幕；選擇要查看其銷售報告的樂隊；從銷售數據庫檢索銷售數據；顯示銷售報告。

該活動圖中有兩個泳道，由於有兩個對象控制着各自的活動：樂隊經理和報告工具。整個過程首先從樂隊經理選擇查看他的樂隊銷售報告開始。而後報告工具 檢索並顯示他管理的全部樂隊，並要求他從中選擇一個樂隊。在樂隊經理選擇一個樂隊以後，報告工具就檢索銷售信息並顯示銷售報告。該活動圖代表，顯示報告是 整個過程當中的最後一步。

 

回頁首

 

組件圖

組件圖提供系統的物理視圖。它的用途是顯示系統中的軟件對其餘軟件組件（例如，庫函數）的依賴關係。組件圖能夠在一個很是高的層次上顯示，從而僅顯示粗粒度的組件，也能夠在組件包層次2上顯示。

組件圖的建模最適合經過例子來描述。圖7顯示了4個組件：Reporting Tool、Billboard Service、Servlet 2.2 API和JDBC API。從Reporting Tool組件指向Billboard Service、Servlet 2.2 API和JDBC API組件的帶箭頭的線段，表示Reporting Tool依賴於那三個組件。

圖7：組件圖顯示了系統中各類軟件組件的依賴關係

 

回頁首

 

部署圖

部署圖表示該軟件系統如何部署到硬件環境中。它的用途是顯示該系統不一樣的組件將在何處物理地運行，以及它們將如何彼此通訊。由於部署圖是對物理運行狀況進行建模，系統的生產人員就能夠很好地利用這種圖。

部署圖中的符號包括組件圖中所使用的符號元素，另外還增長了幾個符號，包括節點的概念。一個節點能夠表明一臺物理機器，或表明一個虛擬機器節點（例 如，一個大型機節點）。要對節點進行建模，只需繪製一個三維立方體，節點的名稱位於立方體的頂部。所使用的命名約定與序列圖中相同：[實例名稱] : [實例類型]（例如，"w3reporting.myco.com : Application Server"）。

圖8：部署圖。因爲Reporting Tool組件繪製在IBM WebSphere內部，後者又繪製在節點w3.reporting.myco.com內部，於是咱們知道，用戶將經過運行在本地機器上的瀏覽器來訪問 Reporting Tool，瀏覽器經過公司intranet上的HTTP協議與Reporting Tool創建鏈接。

圖8中的部署圖代表，用戶使用運行在本地機器上的瀏覽器訪問Reporting Tool，並經過公司intranet上的HTTP協議鏈接到Reporting Tool組件。這個工具實際運行在名爲w3reporting.myco.com的Application Server上。這個圖還代表Reporting Tool組件繪製在IBM WebSphere內部，後者又繪製在w3.reporting.myco.com節點內部。Reporting Tool使用Java語言經過IBM DB2數據庫的JDBC接口鏈接到它的報告數據庫上，而後該接口又使用本地DB2通訊方式，與運行在名爲db1.myco.com的服務器上實際的DB2 數據庫通訊。除了與報告數據庫通訊外，Report Tool組件還經過HTTPS上的SOAP與Billboard Service進行通訊。

 

結束語

儘管本文僅提供了對統一建模語言UML的簡要介紹，但仍是鼓勵你們把從這裏學到的基本信息應用到本身的項目中，同時更深刻地鑽研UML。已 經有多種軟件工具能夠幫助您把UML圖集成到軟件開發過程當中，不過即便沒有自動化的工具，您也可使用白板上的標記或者紙和筆來手工繪製UML圖，仍然會 獲益匪淺。