簡介： 回顧20世紀晚期--準確地說是1997年，OMG組織（Object Management Group對象管理組織）發佈了統一建模語言（Unified Modeling Language，UML）。UML的目標之一就是爲開發團隊提供標準通用的設計語言來開發和構建計算機應用。UML提出了一套IT專業人員期待多年的統一的標準建模符號。通過使用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進行通信。
