到了21世紀——準確地說是2003年，uml已經獲得了業界的認同。在我所見過的專業人員的簡歷中，75%都聲稱具備uml的知識。然而，在同絕大多數求職人員面談之后，可以明顯地看出他們并不真正了解uml。通常地，他們將uml用作一個術語，或對uml一知半解。大家對uml缺乏理解的這種狀況，促進我撰寫這篇關于uml 1.4的快速入門文章。當閱讀完本文時，您還不具備足夠的知識可以在簡歷上聲稱自己掌握了uml，但是您已具有了進一步鉆研該語言的良好起點。

　　背景知識

　　正如前面曾提到過的，uml的本意是要成為一種標準的統一語言，使得it專業人員能夠進行計算機應用程序的建模。uml的主要創始人是jim rumbaugh、ivar jacobson和grady booch，他們最初都有自己的建模方法（omt、oose和booch），彼此之間存在著競爭。最終，他們聯合起來創造了一種開放的標準。（聽起來是不是很熟悉？這個現象類似j2ee、soap和linux的誕生。）uml成為"標準"建模語言的原因之一在于，它與程序設計語言無關。（ibm rational的uml建模工具被廣泛應用于j2ee和.net開發。）而且，uml符號集只是一種語言而不是一種方法學。這點很重要，因為語言與方法學不同，它可以在不做任何更改的情況下很容易地適應任何公司的業務運作方式。

　　既然uml不是一種方法學，它就不需要任何正式的工作產品（即ibm rational unified process術語中所定義的"工件"）。而且它還提供了多種類型的模型描述圖（diagram），當在某種給定的方法學中使用這些圖時，它使得開發中的應用程序的更易理解。uml的內涵遠不只是這些模型描述圖，但是對于入門來說，這些圖對這門語言及其用法背后的基本原理提供了很好的介紹。通過把標準的uml圖放進您的工作產品中，精通uml的人員就更加容易加入您的項目并迅速進入角色。最常用的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圖，仍然會獲益匪淺。