UML入門：統一建模語言入門 - 點空間

最常使用的UML 標準圖形有：使用案例圖（use case diagram）、類別圖（class ... 一個使用案例可用來說明系統所提供的一項功能，使用案例圖主要的目的在幫助開發團隊 ... UML入門：統一建模語言入門 作者：Donald Bell  IBMGlobalService 譯者：姚長利 　 原始文章連結： http://www.therationaledge.com/content/jun_03/f_UMLintro_db.jsp 　 　 故事要回到二十世紀末葉，確切的時間就是西元1997年，物件管理協會（ObjectManagementGroup；OMG）提出了統一建模語言（UML），其中一項目的就是提供軟體開發社群使用穩定且通用的設計語言，也可以用來開發並建構電腦應用程式，UML帶給IT技術人員長久以來所需要的一個統一的標準建模表示法。

利用UML，IT技術人員能夠閱讀、傳達系統組織架構還有設計圖面，就像是建築工人多年以來使用建築物的藍圖施工一樣。

現在已經是二十一世紀，更正確的說就是西元2003年，UML已經贏得所有技術人員的注意，在我所看過的履歷表中有75%都會宣稱自己了解UML，然而在跟大多數的求職應徵者訪談過後，很明顯地就會知道他們並不是真的了解UML。

通常他們不是把UML當作專業行話，就是只認識了UML的鳳毛麟角，完全不了解實際的涵義，這也激勵我撰寫這份UML 1.4（譯註：UML在2003年3月1日已經發表1.5版http://www.omg.org/technology/documents/formal/uml.htm ）的導論。

當你讀完它時，你仍然沒有足夠的知識，能在履歷表上註明你會使用UML，但是你將會開始更深入地了解這個語言。

簡短的歷史 正如我所提及的，UML是一種大一統的語言，能讓IT技術人員建構應用程式的模型。

UML主要是由Jim Rumbaugh、IvarJacobson和GradyBooch提出的，一開始他們各自擁護自己的方法（OMT、OOSE和Booch），最終他們合力完成 UML的標準。

（聽起來好像很熟悉對嗎？因為J2EE、SOAP和Linux都有類似的現象。

）UML變成標準建模語言有一個理由，就因為它和程式語言沒有關係。

（由IBM Rational公司開發的UML建模工具，就廣泛地被J2EE與.Net社群使用。

）另外UML表示法是一種語言而不是方法論，這一點相當地重要，因為語言不同於方法論，可以簡單地導入所有公司企業經營的方式，而不需要任何改變。

既然UML 不是一種方法論，就不需要任何形式上的工作成果（就像是IBMRationalUnifiedProcess® 的奇怪用語「人造產物(artifacts)」一樣）。

但是UML確實提供了幾種圖形，用在這裡確實也讓應用程式在開發過程中更容易瞭解，其實UML不只這些圖形而已，對我來說，這些圖提供了這個語言的最佳入門，還有使用這些圖背後的原理。

將標準UML圖放入你產品的作業流程中，會讓熟悉UML的人員比較容易參與你的專案，並且很快地就會有生產力。

最常使用的UML標準圖形有：使用案例圖（use casediagram）、類別圖（classdiagram）、循序圖（sequencediagram）、狀態圖（statechartdiagram）、活動圖（activity diagram）、元件圖（componentdiagram）和部署圖（deploymentdiagram）。

要深入探討每一種圖的意義，超過了這篇介紹性文章的範圍，我將提供你足夠的資訊，大略了解每一個圖的意義，未來的文章將提供更詳細的說明。

使用案例圖（Use-case diagram） 一個使用案例可用來說明系統所提供的一項功能，使用案例圖主要的目的在幫助開發團隊設想系統功能的需求，其中包含了參與者（actor，也就是跟系統互動的人）與基本處理程序的關係，還有不同使用案例之間的關係。

使用案例圖通常會表示出一組使用案例：不是整個系統所有的使用案例，就是與使用案例相關的一組特殊的功能（例如所有和安全管理相關的使用案例）。

你必須在圖的中間畫一個橢圓，並在橢圓的中間或是下面填入這個使用案例的名稱，用來表示使用案例圖中的一個使用案例。

另外你要在圖的左邊或是右邊畫一個棒狀的小人（為了避免你會納悶，事實上有一些人會畫比棒狀小人好看的人形圖），用來表示使用案例圖的一個參與者（包括系統使用者）。

還要利用簡單的線條來描述參與者和使用案例之間的關係，就像是圖1一樣。

圖1.使用案例圖範例 使用案例圖通常用來描述系統涵蓋的範圍，和整個系統高階功能的關係，由圖1的使用案例圖來看，你可以很快地分辨出這個範例系統的功能。

這個系統可以讓樂團經理人（band manager）調閱銷售統計報表，還有告示牌200（Billboard200，朱子註：即美國告示牌專輯排行榜）對於該樂團所屬CD的專輯排行榜。

這個系統也能讓唱片經理人調閱銷售統計報表，還有告示牌200對某一張CD的專輯排行。

這個圖也告訴我們，我們的系統是由一個稱為告示牌專輯排行服務（Billboard ReportingService）的外來系統來產生告示牌的專輯排行榜。

另外，在這個圖裡面沒有描述的使用案例，就是這個系統不支援的功能。

例如它不提供可以讓樂團經理人聆聽在告示牌200（Billboard 200）裡面所有唱片歌曲的功能，換句話說，就是我們不會看到有一個稱為「從告示牌200聽歌（ListentoSongsfromBillboard 200）」的使用案例，沒有這項功能並不是很嚴重的問題。

依照這種圖所提供既簡單又清楚的使用案例描述，計劃贊助者就能夠很快地發現這個系統現有的功能，或是必要卻沒有提供的功能。

類別圖（Class diagram） 類別圖描述不同的個體（人、事物和資料）相互的關係；換句話說，它表示了系統的靜態結構。

類別圖能夠用來表示邏輯類別，通常也就是組織裡面的業務人員所談論的東西：搖滾樂團、CD、收音機；或是貸款、住宅抵押、汽車貸款和利率。

類別圖也能夠用來表示實作的類別，也就是一般程式設計師所要處理的物件。

實作的類別圖有可能跟邏輯的類別圖使用一些相同的類別。

然而實作類別圖將不會寫上相同的屬性欄位(attributes)，因為實作類別極有可能會使用到像是 Vectors和HashMaps這類東西。

在類別圖中描繪的類別，是一個有三個水平區域的長方形，就像是圖2裡面畫的一樣。

上方的區域表示類別的名稱；中間的區域包含了類別的屬性欄位；下面的區域包含了類別的操作（或是方法）。

圖2.類別圖中的類別物件範例 以我的經驗來說，大多數的開發人員都知道這些圖的意義，但是我還發現許多程式設計師把關係線段畫錯了。

對於類別圖就像是圖3來說，你應該要利用一條頂端有箭頭的線畫繼承的關係1指到上方的母類別，另外這個頂端的箭頭必須是一個正三角形。

如果兩個類別互相知道對方的聯繫（association）關係，應該是一條實線，如果只有一方知道另一方類別的聯繫關係，就一條有開放箭頭的實線。

圖3.完整的類別圖包含圖2裡面描繪的類別 在圖3中，我們觀察到繼承關係和兩個聯繫關係。

CDSalesReport類別繼承了Report類別，CDSalesReport聯繫到一個CD，但是CD類別不知道任何有關CDSalesReport類別的資訊。

CD和Band類別互相知道對方，兩個類別都以多對多的方式互相聯繫到對方。

類別圖能夠整合許多概念，我們將會在日後系列文章中討論到。

循序圖（Sequence diagram） 循序圖描述特定使用案例或是特定使用案例的一部份詳細的流程。

它們大多能讓人望圖生義；並可以依照順序描述不同物件之間的呼叫關係，也能夠詳細地描述給不同物件的各種呼叫。

循序圖有兩個象限：垂直象限依照訊息/呼叫發生的時間順序，來描述訊息/呼叫的先後次序；水平象限則描述一個物件實體（instances）傳送訊息給哪一個物件實體。

循序圖是非常容易繪製的。

在圖的最上方，把每一個類別實體放入一個方格裡面，以辨識類別實體（物件）（參考圖 4），在方格裡面，放入類別實體的名稱，還有類別的名稱，中間插入一個空白/冒號/空白“:“（例如myReportGenerator: ReportGenerator）。

如果類別實體傳送訊息給另一個類別實體，就畫一條有開放箭頭的實線，指到接收端的類別實體，在這條線的上面填入訊息/方法的名稱。

對於重要的訊息，你也可以畫上有箭頭的虛線，指回訊息來源的類別實體；在虛線上標示回傳值。

我自己總是喜歡加上回傳值的虛線，因為我發現這個額外的資訊會讓它更容易閱讀。

閱讀循序圖是非常簡單的事。

一開始，從左上方角落那個”驅動者（driver）”類別實體開始引發一連串的事件，然後跟著圖往下追蹤每一個訊息。

要記住：即使在圖4 循序圖範例對每一個傳送的訊息都繪製了回傳訊息，但這是可做可不做的。

圖4.循序圖範例 由圖4 裡面所看到的循序圖，你可以了解到要如何建立一份CD銷售報表。

aServlet物件是我們範例中的驅動者，aServlet會傳送一個訊息給稱為gen的 ReportGenerator類別實體，這個訊息被標示為generateCDSalesReport，這個名稱代表它是由ReportGenerator 物件實作的訊息處理器，再更詳細地檢視這個訊息，generateCDSalesReport訊息的括號裡面有一個cdId的標記，這表示aServlet 會在這個訊息裡面附帶傳送一個稱為cdId的變數。

當gen實體傳送一個generateCDSalesReport訊息，接下來gen會呼叫 CDSalesReport類別，會傳送回來一個稱為aCDReport的CDSalesReport實體。

然後gen實體會呼叫回傳的aCDReport 實體，再利用每一次的訊息呼叫把參數傳給aCDReport。

在這個序列的最後，gen實體會回傳aCDReport給它的呼叫者aServlet。

請注意：圖4 的循序圖對常見的循序圖來說有一點太詳細了，然而，我相信它還是很簡單易懂，同時該圖也展示巢狀呼叫怎樣畫。

另外對於資淺的開發人員來說，有時候也必須要深入每一個程序，描述越詳細清楚，越能幫助開發人員了解他們應該要做什麼。

狀態圖（Statechart diagram） 狀態圖為一個類別模擬了所有可能的狀態，還有該類別要如何從一個狀態轉換到另一個狀態。

至於是不是每一個類別都有一個狀態，是可以討論的，但是每一個類別不應該都有一個狀態圖，只有那些擁有”有趣的”狀態的類別，也就是系統活動過程中，有三個或多個可能狀態的類別應該要被模擬。

正如圖5所描述的，狀態圖的表示法有五個基本的元素：畫一個實心的圓代表最初出發點；畫一條有開放箭頭的線代表狀態之間的轉換；畫一個圓角的長方形代表一個狀態；畫一個空心的圓來代表一個決策的端點；可以有一個或多個終點，並以空心圓內含實心圓來代表終點。

繪製一個狀態圖，要從一個起點開始，然後是一條狀態轉換線指到類別的起始狀態。

在圖上的任意處畫上其他的狀態，然後用狀態轉換線把他們連接起來。

圖5.狀態圖描述類別通過系統功能的不同狀態 圖5的狀態圖範例描述了一些可能溝通的資訊，例如你會知道貸款流程是由貸款申請（Loan Application）狀態開始。

當預先批核的程序（pre-approvalprocess）完成時，要由結果來決定下一步，不是到貸款預先批核（Loan Pre-approved）的狀態，就是到拒絕貸款（LoanRejected）的狀態。

這項判斷是在轉換的過程當中決定的，並以一個決策點來表示：也就是在轉換線上面的一個空心圓圈。

在這個範例中，我們可以知道貸款部會從貸款預先批核（Loan Pre-approved）狀態轉換到貸款定期攤還（LoaninMaintenance）的狀態，而中間不經過貸款完成交易（LoanClosing）狀態。

另外藉由觀察這個範例圖，我們可以知道所有的貸款不是在拒絕貸款（Loan Rejected）狀態，就是在貸款定期攤還（LoaninMaintenance）的狀態結束。

活動圖（Activity diagram） 活動圖用來描述在進行一項活動時，兩個或是多個類別物件之間程序的控制流程。

活動圖能夠用來描述在商業單元階層的高階商業程序，也可以用來描述低階內部類別的行為。

以我的經驗來說，活動圖最好是用來描述高階處理程序，例如目前公司要如何處理商務程序，或是它要怎麼做生意。

這是因為跟循序圖比較起來，活動圖在表面上看來比較”不專業”，另外業務人員會比較快速且容易瞭解這個圖的意義。

活動圖裡面使用的表示法與狀態圖很類似。

跟狀態圖一樣，活動圖是由一個實心圓圈開始，連接到起始的活動。

活動是畫一個圓角的矩形來表示，裡面填上活動的名稱。

活動可以透過轉換線連接到其他不同的活動上，也可以連接到決策點上，然後連到有決策點把關的其他活動上。

終結所有模擬程序的活動是連接到一個終點（跟狀態圖一樣）。

活動也可以使用水道（swimlane）分出不同的群組，這可以用來表示物件實際上要怎麼執行這個活動，就像是圖6所表示的一樣。

圖6.活動圖，有兩條水道描述兩個物件（樂團經理人和報表工具）所掌控的活動 活動圖的範例當中，我們用兩個水道（swimlane），因為我們有兩個物件控制不同的活動：一個樂團經理人和一個報表工具。

整個程序是由樂團經理人選擇要看哪一個樂團的銷售報表開始，接下來報表工具會取得並展示該經理人所管理的所有樂團，並詢問他要選哪一個。

在樂團經理人選擇了一個樂團之後，報表工具會取得銷售的資訊並展示這個銷售報表。

根據活動圖的描述，展示報表是這個程序的最後一個步驟。

元件圖（Component diagram） 元件圖描述系統的實體狀況。

它的目的在於描述該系統中的軟體跟其他軟體元件的依存關係（也就是軟體函式庫），這個圖可以畫得很高階，只描述大略的元件，也可以用元件套件層（component packagelevel）2來描述。

要繪製一個元件圖，最好是藉由範例來描述。

圖7裡面表示了四個元件：報表工具（Reporting Tool）、告示牌服務（BillboardService）、Servlet2.2API和JDBCAPI。

一條有箭頭的線從報表工具（Reporting Tool）元件分別指向告示牌服務（BillboardService）、Servlet2.2API和JDBCAPI，代表報表工具（Reporting Tool）跟那三個元件有依賴的關係。

圖7.元件圖用來描述系統內不同軟體元件之間的相互依賴關係 　 部署圖（Deployment diagram） 部署圖描述一個系統要如何部署到實際的硬體環境上，它的目的是要表示系統裡面不同元件實際上所要運作的地點，還有這些元件要如何互相溝通。

這個圖描述了實際的運作狀況，所以線上系統的工作人員將會相當倚重使用這個圖。

部署圖裡面包含了元件圖表示法的元素，另外還增加了一些其他的符號，包括節點的概念。

一個節點不是代表一個實體的機器，就是一個虛擬的機器（例如中央處理機節點）。

只要畫一個三維的立方體，在立方體上面寫上節點的名稱，就可以代表一個節點。

名稱使用在循序圖中的命名習慣：[實體名稱]:[實體型別]（例如”w3reporting.myco.com:Application Server”）。

圖8.部署圖，因為報表工具（ReportingTool）元件是繪製在IBMWebSphere裡面，而IBMWebSphere接著畫在w3.reporting.myco.com節點裡面，我們知道使用者會以HTTP連接公司的內部網路，並透過他們自己機器上的瀏覽器來使用報表工具（Reporting Tool） 在圖8的部署圖中，描述使用者利用自己機器上所執行的瀏覽器，經由HTTP連上公司的內部網路來使用報表工具（Reporting Tool），這個工具實際上是運作在稱為w3reporting.myco.com的應用程式伺服器（ApplicationServer）中。

這個圖描述報表工具（Reporting Tool）元件是放在IBMWebSphere裡面，而IBMWebSphere則置於w3.reporting.myco.com節點裡面。

報表工具（Reporting Tool）會利用Java程式語言，以IBMDB2的JDBC介面連接報表資料庫，然後就會用原始的DB2連線，跟伺服器裡面稱為db1.myco.com的實體DB2資料庫互相溝通。

另外為了要跟報表資料庫（譯註：這裡是指報表工具輸出的結果）溝通，報表工具（Reporting Tool）元件會透過HTTPS上的SOAP傳送給告示牌服務（BillboardService）。

結論 這篇文章只是簡短的介紹一下統一建模語言，然而我鼓勵你開始把在這裡學到的知識 ，應用到你的專案當中，並更深入地去了解UML。

這裡有一些工具軟體，能幫助你整合UML圖到軟體開發流程當中，但是就算沒有這些自動化工具，你也可以利用白板或是紙，再用筆去畫出UML圖，這樣也可以達到一定的功效。

註 1如果想要知道繼承和物件導向其他原理的資訊，請看http://java.sun.com/docs/books/tutorial/java/concepts/inheritance.html 2元件套件層（componentpackagelevel）此慣用語是指 與程式語言無關的方式，對照到程式語言的類別容器層，就像.Net的名稱空間（例如System.Web.UI）或是Java的套件（例如java.util）。

資源 http://www.uml.org：UML官方網站。

http://www.rational.com/uml/resources/documentation/index.jsp：提供UML數個不同的版本的標準 。

http://www.rational.com/rose：有關商用UML塑模工具IBM RationalRose®的資訊。

http://www.rational.com/xde：有關商用UML塑模工具IBM RationalXDE®的資訊，此工具也整合在IBM日蝕（Eclipse）開發平台中。

http://argouml.tigris.org：有關ArgoUML的資訊，這是一個用Java寫的開放原碼UML塑模工具 。

http://uml.sourceforge.net/index.php：有關Umbrello UMLModeller的資訊，這是一個在KDE環境使用的開放原碼UML塑模工具。