UML基礎

shankusu2017發表於2021-01-04

以下內容轉載自 https://www.ibm.com/developerworks/cn/rational/r-uml/

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

參考 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圖，仍然會獲益匪淺。

備註

  1. 欲瞭解關於繼承和其他物件導向原理的更多資訊，請參閱：
    http://java.sun.com/docs/books/tutorial/java/concepts/inheritance.html
  2. "元件包層次"這個短語以一種與程式設計語言無關的方式，指代諸如.Net的名稱空間（例如System.Web.UI）或者Java的包（例如java.util）這樣的類容器層次。

參考資料

欲瞭解有關本文所討論的產品或者服務的更多資訊，請點選 這裡並遵照所提供的指示操作。謝謝！

相關文章