回顧20世紀晚期--準确地說是1997年，OMG組織（Object Management Group對象管理組織）釋出了統一模組化語言（Unified Modeling Language，UML）。UML的目标之一就是為開發團隊提供标準通用的設計語言來開發和建構計算機應用。UML提出了一套IT專業人員期待多年的統 一的标準模組化符号。通過使用UML，這些人員能夠閱讀和交流系統架構和設計規劃--就像建築勞工多年來所使用的建築設計圖一樣。
到了21世紀 --準确地說是2003年，UML已經獲得了業界的認同。在我所見過的專業人員的履歷中，75%都聲稱具備UML的知識。然而，在同絕大多數求職人員面談 之後，可以明顯地看出他們并不真正了解UML。通常地，他們将UML用作一個術語，或對UML一知半解。大家對UML缺乏了解的這種狀況，促進我撰寫這篇 關于UML 1.4的快速入門文章。當閱讀完本文時，您還不具備足夠的知識可以在履歷上聲稱自己掌握了UML，但是您已具有了進一步鑽研該語言的良好起點。
<a>一些背景知識</a>
正如前面曾提到過的，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圖包括：用例圖、類圖、序列圖、狀态圖、活動圖、組 件圖和部署圖。
深入讨論每類圖的細節問題已超出了這篇入門文章的範圍。是以，下面僅給出了每類圖的簡要說明，更詳細的資訊将在以後的文章中探讨。
<a>用例圖</a>
用例圖描述了系統提供的一個功能單元。用例圖的主要目的是幫助開發團隊以一種可視化的方式了解系統的功能需求，包括基于基本流程的"角色" （actors，也就是與系統互動的其他實體）關系，以及系統内用例之間的關系。用例圖一般表示出用例的組織關系--要麼是整個系統的全部用例，要麼是完 成具有功能（例如，所有安全管理相關的用例）的一組用例。要在用例圖上顯示某個用例，可繪制一個橢圓，然後将用例的名稱放在橢圓的中心或橢圓下面的中間位 置。要在用例圖上繪制一個角色（表示一個系統使用者），可繪制一個人形符号。角色和用例之間的關系使用簡單的線段來描述，如圖1所示。
圖1：示例用例圖
圖字（從上到下）：CD銷售系統；檢視樂隊CD的銷售統計；樂隊經理；檢視Billboard 200排行榜報告；唱片經理；檢視特定CD的銷售統計；檢索最新的Billboard 200排行榜報告；排行榜報告服務
用 例圖通常用于表達系統或者系統範疇的進階功能。如圖1所示，可以很容易看出該系統所提供的功能。這個系統允許樂隊經理檢視樂隊CD的銷售統計報告以及 Billboard 200排行榜報告。它也允許唱片經理檢視特定CD的銷售統計報告和這些CD在Billboard 200排行榜的報告。這個圖還告訴我們，系統将通過一個名為"排行榜報告服務"的外部系統提供Billboard排行榜報告。
此外，在用例圖中，沒有列出的用例表明了該系統不能完成的功能。例如，它不能提供給樂隊經理收聽 Billboard 200上不同專輯中的歌曲的途徑 -- 也就是說，系統沒有引用一個叫做"收聽Billboard 200上的歌曲"的用例。這種缺少不是一件小事。在用例圖中提供清楚的、簡要的用例描述，項目贊助商就很容易看出系統是否提供了必須的功能。
<a>類圖</a>
類 圖表示不同的實體（人、事物和資料）如何彼此相關；換句話說，它顯示了系統的靜态結構。類圖可用于表示邏輯類，邏輯類通常就是業務人員所談及的事物種類 --搖滾樂隊、CD、廣播劇；或者貸款、住房抵押、汽車信貸以及利率。類圖還可用于表示實作類，實作類就是程式員處理的實體。實作類圖或許會與邏輯類圖顯 示一些相同的類。然而，實作類圖不會使用相同的屬性來描述，因為它很可能具有對諸如Vector和HashMap這種事物的引用。
類在類圖上使用包含三個部分的矩形來描述，如圖2所示。最上面的部分顯示類的名稱，中間部分包含類的屬性，最下面的部分包含類的操作（或者說"方法"）。
圖2：類圖中的示例類對象
根 據我的經驗，幾乎每個開發人員都知道這個類圖是什麼，但是我發現大多數程式員都不能正确地描述類的關系。對于像圖3這樣的類圖，您應該使用帶有頂點指向父 類的箭頭的線段來繪制繼承關系1，并且箭頭應該是一個完全的三角形。如果兩個類都彼此知道對方，則應該使用實線來表示關聯關系；如果隻有其中一個類知道該 關聯關系，則使用開箭頭表示。
圖3：一個完整的類圖，包括了圖2所示的類對象
在 圖3中，我們同時看到了繼承關系和兩個關聯關系。CDSalesReport類繼承自Report類。一個CDSalesReport類與一個CD類關 聯，但是CD類并不知道關于CDSalesReport類的任何資訊。CD類和Band類都彼此知道對方，兩個類彼此都可以與一個或者多個對方類相關聯。
一個類圖可以整合其他許多概念，這将在本系列文章的後續文章中介紹。
<a>序列圖</a>
序列圖顯示具體用例（或者是用例的一部分）的詳細流程。它幾乎是自描述的，并且顯示了流程中中不同對象之間的調用關系，同時還可以很詳細地顯示對不同對象的不同調用。
序列圖有兩個次元：垂直次元以發生的時間順序顯示消息/調用的序列；水準次元顯示消息被發送到的對象執行個體。
序列圖的繪制非常簡單。橫跨圖的頂部，每個框（參見圖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中的序列圖相對于典型的序列圖來說太詳細了。然而，我認為它才是足夠易于了解的，并且它顯示了如何表示嵌套的調用。對于初級開發人員來說，有時把一個序列分解到這種詳細程度是很有必要的，這有助于他們了解相關的内容。
<a href="http://www.ibm.com//developerworks/cn/rational/r-uml/#main"></a>
<a>狀态圖</a>
狀态圖表示某個類所處的不同狀态和該類的狀态轉換資訊。有人可能會争論說每個類都有狀态，但不是每個類都應該有一個狀态圖。隻對"感興趣的"狀态的類（也就是說，在系統活動期間具有三個或更多潛在狀态的類）才進行狀态圖描述。
如 圖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狀态。
<a>活動圖</a>
活 動圖表示在處理某個活動時，兩個或者更多類對象之間的過程控制流。活動圖可用于在業務單元的級别上對更進階别的業務過程進行模組化，或者對低級别的内部類操 作進行模組化。根據我的經驗，活動圖最适合用于對較進階别的過程模組化，比如公司目前在如何運作業務，或者業務如何運作等。這是因為與序列圖相比，活動圖在表 示上"不夠技術性的"，但有業務頭腦的人們往往能夠更快速地了解它們。
活動圖的符号集與狀态圖中使用的符号集類似。像狀态圖一樣，活動圖也從一個連接配接到初始活動的 實心圓開始。活動是通過一個圓角矩形（活動的名稱包含在其内）來表示的。活動可以通過轉換線段連接配接到其他活動，或者連接配接到判斷點，這些判斷點連接配接到由判斷 點的條件所保護的不同活動。結束過程的活動連接配接到一個終止點（就像在狀态圖中一樣）。作為一種選擇，活動可以分組為泳道（swimlane），泳道用于表 示實際執行活動的對象，如圖6所示。
圖6：活動圖，具有兩個泳道，表示兩個對象的活動控制：樂隊經理，以及報告工具
圖字（沿箭頭方向）：樂隊經理；報告工具；選擇"檢視樂隊的銷售報告"；檢索該樂隊經理所管理的樂隊；顯示報告條件選擇螢幕；選擇要檢視其銷售報告的樂隊；從銷售資料庫檢索銷售資料；顯示銷售報告。
該活動圖中有兩個泳道，因為有兩個對象控制着各自的活動：樂隊經理和報告工具。整個過程首先從樂隊經理選擇查 看他的樂隊銷售報告開始。然後報告工具檢索并顯示他管理的所有樂隊，并要求他從中選擇一個樂隊。在樂隊經理選擇一個樂隊之後，報告工具就檢索銷售資訊并顯 示銷售報告。該活動圖表明，顯示報告是整個過程中的最後一步。
<a>元件圖</a>
元件圖提供系統的實體視圖。它的用途是顯示系統中的軟體對其他軟體元件（例如，庫函數）的依賴關系。元件圖可以在一個非常高的層次上顯示，進而僅顯示粗粒度的元件，也可以在元件包層次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：元件圖顯示了系統中各種軟體元件的依賴關系
<a>部署圖</a>
部署圖表示該軟體系統如何部署到硬體環境中。它的用途是顯示該系統不同的元件将在何處實體地運作，以及它們将如何彼此通信。因為部署圖是對實體運作情況進行模組化，系統的生産人員就可以很好地利用這種圖。
部 署圖中的符号包括元件圖中所使用的符号元素，另外還增加了幾個符号，包括節點的概念。一個節點可以代表一台實體機器，或代表一個虛拟機器節點（例如，一個 大型機節點）。要對節點進行模組化，隻需繪制一個三維立方體，節點的名稱位于立方體的頂部。所使用的命名約定與序列圖中相同：[執行個體名稱] : [執行個體類型]（例如，"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進行通信。
<a>結束語</a>
盡 管本文僅提供了對統一模組化語言UML的簡要介紹，但還是鼓勵大家把從這裡學到的基本資訊應用到自己的項目中，同時更深入地鑽研UML。已經有多種軟體工具 可以幫助您把UML圖內建到軟體開發過程中，不過即使沒有自動化的工具，您也可以使用白闆上的标記或者紙和筆來手工繪制UML圖，仍然會獲益匪淺。
版權
作者：靈動生活 郝憲玮
如果你認為此文章有用，請點選底端的【推薦】讓其他人也了解此文章，
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。