UML那些事兒：六類UML圖

2.1 類圖

2.2 對象圖

2.3 包圖

2.4 活動圖

2.5 序列圖

2.6 用例圖

 

　　

　　本章介紹六類UML圖的主要用途，以及常見的概念及圖示，以便對這六類圖有一個初步的認識。

　　2.1 類圖

　　若是投票選最重要的UML圖，我必定會把票投給類圖( class diagram)。類圖是一款結構圖(structure diagram)，如圖2-1所示，咱們能夠用它來表達系統內部重要的組成結構。一個穩定且具彈性的內部結構能夠同時支撐系統對外提供的各式服務，以及系統內部複雜的運做，因此我認爲類圖特別重要。

                                                    

                                                         圖2-1 類圖

　　接下來的各小節會談到類圖中最多見的概念及圖示。

　　2.1.1 類

　　一羣對象(object)享有相同的結構、行爲、約束和語義時，稱它們是同類(class)的對象。換句話說，定義一個類就至關於描述了一羣對象。在類中， 使用屬性(attribute)表達對象的結構， 使用操做(operation)表達對象的行爲。

　　如圖2-2所示，定義員工(worker)類以後，即可以依據此類的描述產生一羣對象。這些:Worker對象不只能夠共用類所定義的屬性，擁有本身的屬性值，還能夠共用類所定義的操做，或者共用約束。

　　

　　圖2-2 類與對象

    類採用三格的矩形圖示，頂格放置類名稱，中格放置屬性名稱，底格放置操做名稱。不過，也能夠將類的屬性格或操做格隱藏起來，節省空間，如圖2-3所示。

                                    

                                                            圖2-3 類圖示

　大多數的UML工具都有隱藏功能。以StarUML爲例，點選任何一個類圖示均可以選擇是否隱藏屬性或操做，如圖2-4所示。

　　

　　圖2-4 隱藏屬性或操做

　2.1.2 可見性

　　對象具備封裝(encapsulation)屬性，能夠把數據結構和行爲細節封裝起來，外界沒法隨意存取。對應UML的類概念，咱們會看到類中有屬性和操做，同時能夠設定這些成員是否能被外界存取的可見性(visibility)。以圖2-5爲例，單筆申購(purchase)封裝了一個外界沒法存取的私有屬性—金額(amount)，以及一個外界能夠調用的公開操做—計算(calculate)。

　　

　　圖2-5 私有屬性與公開操做

　　目前，UML預設了四種可見性，分別爲公開(public)、私有(private)、保護(protected)

　　和包(package)。公開和私有可見性最多見，也最容易懂，如圖2-5所示，減號(-)爲私有可見性，加號(+)爲公開可見性。

　　私有可見性滴水不漏，就連子類也沒法看見超類的私有成員，這樣，其實不利於繼承機制。因此，UML設置保護等級的可見性，特別開放子類能夠看見超類的保護等級的屬性及操做，以便提供更方便的繼承機制。保護可見性的符號是井號(#)，如圖2-6所示。

　　

　　圖2-6 保護等級的屬性

　　最後來談包可見性。顧名思義，它是爲了包而設置的，它的符號是否認號(~)，如圖2-7所示。同包的類能夠看見其餘類內部的包屬性及操做。因此，從圖中能夠得知，帳戶能夠看見顧客類的姓名和地址，可是分行(branch)卻沒法看見，由於分行不是S包的成員。

　　

　　圖2-7 包等級的屬性

　　2.1.3 關聯

　　關聯(association)是對象之間最多見的關係，用來鏈接有結構關係的對象。請看圖2-8的例子，關聯的圖示爲實線，實線兩端能夠鏈接兩個不一樣的類，如圖中的我的(person)類和公司(company)類。

　　不過，關聯的兩端也能夠鏈接相同的類，如圖2-8中的我的類。雖然，關聯兩端鏈接相同的類，但它的連接(link)實際上是鏈接兩個不一樣的實例(instance)，只不過這兩個實例誕生自相同的類。

　　

　　圖2-8 關聯

　　關聯不必定是二元關聯(binary association)，也能夠是多元關聯(n-ary association)。多元關聯的圖示是鏈接大菱形的實線，如圖2-9所示爲三元關聯(ternary association)。

　　

　　圖2-9 三元關聯

　　有時候會看到帶箭頭實線，那是在標示導航性(navigation)，意味着能夠由來源端(source end)導航到箭頭所在處的目標端(target end)。如圖2-10所示，:Member對象能夠連接到:Password對象，可是反向則不成立，也就是說，沒法從:Password對象連接到:Member對象，由於二者之間是單向的關聯。

　　

　　圖2-10 導航性

　　特別注意，關聯端的標記在UML 2中有所變更，與UML 1版略有不一樣，如圖2-11所示。

                      

　　圖2-11 關聯圖示

   在UML 2中，關聯的箭頭端表明具備導航性。打個小叉就是不可導航;單純直線表明還未指定可導航或不可導航。因此，回到圖2-11的例子中，能夠看到

　　• AB是雙向關聯。

　　• CD兩端都不具備導航性。

　　• EF還沒有指定兩端是否具導航性。

　　• GH爲單向關聯，可由G導航到H。

　　• I端還未決定能否導航，能夠肯定的是，可由I導航到J。

2.1.4 多重性

　　多重性元素(multiplicity element)主要包含一組上下限數，用來指出可被容許生成的實例(instance)數量，即最多能夠生成多少數目(上限)，最少不得低於多少數目(下限)。關聯的兩端以「下限..上限」的格式標示出多重性，如圖2-12中的1..*。星號(*)表明無指定上限，下限最低爲0。若是上下限數相同，標示出一個數目就能夠了。所以，能夠解讀爲：

　　一個顧客(customer)能夠擁有一個到多個的帳戶(account)，可是一個帳戶只能由一個顧客所擁有。

　　

　　圖2-12 多重性

　　2.1.5 聚合與組合

　　關聯的兩端是平等的，沒有孰輕孰重的分別。若想表達總體-部分(whole-part)關係，能夠改用聚合關係(aggregation)或組合關係(composition)。

　　聚合與組合都具備總體-部分的特性，惟一的差異在於能否分享(share)。聚合關係中的部件(part object)能夠與其餘總體(whole object)分享，可是組合關係中的部件則由總體獨自擁有。先來看聚合關係，聚合端爲空心小菱形，如圖2-13所示。

　　

　　圖2-13 聚合關係

　　由於船(boat)和引擎(engine)之間採用聚合關係，意味着船爲總體，而引擎爲它的部件。並且，假若a船被刪除了，或者a船再也不須要這個引擎而刪除之間的連接，b船能夠接手使用這個引擎部件，如圖2-14所示。

　　

　　圖2-14 部件可重用

　　可是，若是圖2-14改爲組合關係，b船就沒法重用引擎部件了。由於組合關係中的總體不會分享部件，因此一旦a船被刪除，或者a船再也不須要這個引擎時，a船都會負責將引擎銷燬掉。請看圖2-15的例子，組合端爲實心小菱形，意味着視窗(window)被刪除時，構成視窗的部件都會連帶被刪除，這是常見的組合關係。

　　

　　圖2-15 組合關係

　2.1.6 泛化

　　實際上，經常使用繼承(inheritance)一詞，可是UML沒有使用繼承這個詞彙，不過UML提供了泛化(generalization)，來達到子類(subclass)繼承超類(superclass)的目的。

　　泛化將類分爲較爲泛化的類和較爲特化的類，如圖2-16所示。經過泛化，子類能夠繼承超類預先定義好的聲明。泛化的圖示爲帶有大三角形箭頭的實線，由特化的子類鏈接指向泛化的超類。

　　

　　圖2-16 泛化

　　2.1.7 依賴

　　某一模型元素須要另外一個模型元素所提供的規格(specification)或實現(implementation)時，二者之間的關係稱爲依賴(dependency)。也就是說，少了供應者元素(supplier element)的話，依賴元素(depending element)在語義上(semantically)或者結構上(structurally)可能會不完整(imcomplete)。所以，一旦供應者元素變更，極可能會影響到依賴元素。

　　例如，結帳時須要用到信用卡，因此結帳(check out)類依賴信用卡(credit card)類，如圖2-17所示。依賴的圖示是帶箭頭虛線，由依賴元素指向供應者元素。

　　

　　圖2-17 依賴

　　2.1.8 接口

　　接口(interface)如同契約，負責的類必須負責實現它的公開操做，以及負責維護它的公開屬性。以圖2-18爲例，ProximitySensor類負責實現ISensor接口內部的active操做與read操做，而TheftAlarm類則可使用ISensor接口。

　　圖2-18 接口

   

實際上，可能會先設計出接口與實現者，這種接口特別稱爲供給接口(provided interface)，指由實現類所供給的接口，也能夠改用接口獨特的圓形圖示，如圖2-19所示。也能夠先設計出使用者以及所須要的接口，這時稱這類的接口爲需求接口(required interface)，其圖示爲半圓形，如圖2-20所示，以便可以一眼區分出該接口爲供給接口或需求接口。

　　

　　圖2-19 供給接口

　　

　　圖2-20 需求接口

　　若是把實現者、使用者、需求接口和供給接口全都湊在一塊兒，可使用圖2-21的簡圖，以

　　節省圖面空間。

　　

　　圖2-21 簡圖

　　2.1.9 註釋

　　註釋(comment)能夠附加在任何元素上，其內放置說明文字，就像3M的便利貼(Post-it)

　　同樣。註釋能夠用在任何圖中，不侷限於類圖。註釋的圖示是右上角有折角的矩形，經過虛線鏈接被註釋的元素，如圖2-22所示。

　　

　　圖2-22 註釋的圖示

　　2.2 對象圖

　　對象圖(object diagram)也是一種結構圖，如圖2-23所示，用來呈現系統在特定時刻的對象(object)，以及對象之間的連接(link)。

　　

　　圖2-23 對象圖

　　常說的實例(instance)也會使用對象(object)一詞來替換，二者爲同義詞。系統運行期間，會依據類的定義建立對象，如圖2-24所示。

　　

　　圖2-24 類與對象

　　對象和類共用矩形圖示，不過對象名稱下方有底線，類名稱下方沒有底線，如圖2-25所示。對象名稱常常被省略，因此常見帶有冒號的類名稱，這實際上是個缺名的對象。

　　

　　圖2-25 :Worker是缺名的對象

　　兩個對象之間的關係線稱爲連接(link)，如圖2-26所示。

　　

　　圖2-26 連接

　　2.3 包圖

　　類圖、對象圖和包圖(package diagram)，如圖2-27所示。包圖主要用來爲相關的元素分組。對於擁有大量繁雜元素的項目而言，適合用包圖來維護管理元素。

　　

　　圖2-27 包圖

　　2.3.1 包

　　包(package)就像通常的紙箱，能夠將相關、欲放置在一塊兒的東西打包成箱。包的圖示是上小下大的兩個重疊矩形，能夠將元素放置其內，如圖2-28a所示。也能夠將包的內容隱藏起來，造成如圖2-28b所示，以節省圖面空間。

　　

　　     a)                                                     b)

　　圖2-28 包

　　2.3.2 元素導入

　　元素導入(element import)能夠將包內的任一元素導入到另外一個包中。如圖2-29所示，元素導入採用帶箭頭的虛線表示，旁邊標上<>關鍵字，意味着Program包導入了Time數據類型。

　　

　　圖2-29 元素導入

　　2.3.3 包導入

　　若是一次導入整個包裏的全部元素，可使用包導入(package import)。如圖2-30所示，Order System與Domain DataType之間有包導入的關係，因此Order System內的Employee和Order能夠直接使用Domain DataType裏的Address和Date。

　　

　　圖2-30 包導入

　　2.3.4 包合併

　　顧名思義，包合併(package merge)可將一個包的內容所有合併到另外一個包中。換言之，能夠經由合併目標包(target package)的內容來擴展來源包(source package)。這比如合併公司，原公司合併了另外一家公司，因此原公司就成爲一家擁有更多資產的公司了。

　　如圖2-31所示，包合併的圖示爲帶箭頭虛線，且於虛線旁標記<>，並由來源包指向目標包，意指將目標包的內容併入來源包。

　　

　　圖2-31 包合併圖示

　　再看圖2-32和圖2-33所示的例子，會更加清楚。圖2-32中的S包合併了Q包以後，造成圖2-33。下面一一解釋新的S包的內容：

　　

　　圖2-32 包合併

　　

　　圖2-33 S包

　　• A—原先的A，加上Q::A。假設原先的A有一個名爲name的屬性，而Q::A擁有一個名爲

　　address的屬性，合併後的新A將同時擁有name和address兩個屬性。

　　• B—沒有變化。

　　• C—原先在S包中並不存在C，合併了Q::C。特別是Q::C與Q::A的關聯，也會一塊併入。

　　• D—沒有變化。

　　2.4 活動圖

　　活動圖是一款行爲圖(behavior diagram)，如圖2-34所示，一般用來表達業務流程、工做流或系統流程中一連串的動做。

                            

　　圖2-34 活動圖

    如圖2-35所示，這是一張簡單的活動圖，用來表達訂單的流程。接到訂單(receive order)後，決定是否接受這張訂單。接受(oreder accepted)，就出貨(ship order);不接受(order rejected)，則結束訂單(close order)。

　　

　　圖2-35 活動圖

　　活動圖涵蓋的概念和圖示很是繁雜，在接下來的各小節中，會談到使用比較多的概念。

　　2.4.1 動做與控制流

　　在活動圖中，動做(action)是最重要的組成元素，它表明一個執行步驟。動做的圖示是圓角矩形，如圖2-36所示。

　　圖2-36 動做

鏈接動做的帶箭頭實線稱爲控制流(control flow)。當來源動做結束以後，控制流會啓動目標動做。如圖2-37所示，寄送發票(send invoice)的動做執行完以後，會經過控制流啓動付款(make payment)動做。

　　

　　圖2-37 控制流

2.4.2 對象節點與對象流

　　對象節點(object node)爲矩形圖示，對象流(object flow)的圖示與控制流相同，不過它的其中一個端點必須是對象節點，而另外一端必須是其餘節點。控制流的兩個端點不能夠都是對象節點。

　　對象流不一樣於控制流，對象流能夠攜帶數據或對象。若在寄送發票動做結束後，一併傳送發票(invoice)到付款處，能夠經過對象流，如圖2-38所示。

　　

　　圖2-38 對象流

　　2.4.3 活動參數節點

　　通常的對象節點出如今活動範圍內。若是將對象節點當成活動的參數，用於輸入或輸出活動，就能夠改用活動參數節點(activity parameter node)。

　　如圖2-39所示的範例，放置於活動邊框上的三個矩形都是活動參數節點。訂單(order)、信用卡(card)和發票(invoice)都是訂購處理(order process)活動的參數，它們分別屬於Order、CreditCard和Invoice類型。

　　

　　圖2-39 活動參數節點

　　2.4.4 引腳

　　引腳(pin)和活動參數節點很像，二者都做爲輸入/輸出使用。差異在於引腳用在動做處，活動參數節點則用在活動處。引腳會提供值(values)給動做，且從動做處接受返回值。

　　引腳有兩種，一種稱爲輸出引腳(output pin)，另外一種稱爲輸入引腳(input pin)。如圖2-40所示，輸出引腳用來保存動做的輸出值，輸入引腳則用來保存動做的輸入值。若是想一眼就辨識出輸出/輸入引腳，也能夠採用圖2-41的表示法，附箭頭的引腳。箭頭朝動做外的引腳爲輸出引腳;箭頭朝動做內的引腳爲輸入引腳。

　　

　　圖2-40 輸出引腳與輸入引腳

　　

　　圖2-41 帶有箭頭的引腳

　　有一種特殊的輸入引腳，沒有進入線，能夠自行提供值，這種輸入引腳稱爲值引腳(value

　　pin)。以圖2-42爲例，填寫訂購交易(fill order)的日期永遠都是當日(today)。因此，適合使用值引腳來提供固定的值。值引腳的圖示與輸入引腳相同，可是需在引腳旁邊標記值。

　　

　　圖2-42 值引腳

　　2.4.5 起點與終點

　　起始節點(initial node)表明活動流程的起點，整個活動由起始節點開始循着活動邊的箭頭方向前進。如圖2-43所示，起始節點的圖示是實心小圓，它沒有進入線，可是能夠有多條離開線。善始善終，有起始節點，固然就會有終止節點(final node)。UML定義了兩種終止節點，如圖2-44所示，其一是活動終點(activity final)，表明整個活動的終止;另外一種是流終點(flow final)，表明單一條支流的終止。

　　

　　圖2-43 起始節點

　　

　　圖2-44 活動終點與流終點

　　活動終點能夠有多條進入線，可是無離開線，如圖2-45所示。一個活動也能夠有多個活動終點，可是任何一條活動邊進入任何一個活動終點時，全部支流都會被終止。

　　

　　圖2-45 活動終點

　　2.4.6 合併

　　一座山有不少條不一樣的步道，時而交匯，時而分離。活動流程中，也須要這樣的流程交匯點，稱爲合併節點(merge node)。能夠想見，一個合併節點會有多條進入線，可是隻有一條離開線，如圖2-46所示，合併節點的圖示是大的空心菱形，全部進入合併節點的支流都會經歷同一條離開線。

　　

　　圖2-46 合併節點圖示

　　2.4.7 判斷

　　判斷節點(decision node)與合併節點共用圖示，二者都是大的空心菱形。不過，判斷節點只有一個進入線，但有多條離開線，如圖2-47所示，恰好跟合併節點相反。

　　

　　圖2-47 判斷節點圖示

　　雖然判斷節點有多條離開線，但只有其中一條離開線能夠經過警惕條件(guard)進入下一個活動節點，如圖2-48所示。因此，判斷節點的離開線上都會附有警惕條件，用來決定一條離開路徑。

　　

　　圖2-48 判斷節點與警惕條件

　　2.5 序列圖

　　序列圖用來表達系統內部一羣對象的交互狀況，它是一種行爲圖，如圖2-49所示。

　　

　　圖2-49 序列圖

　　在接下來的各小節中，僅談論序列圖中常見的概念及圖示。

　　2.5.1 交互

　　交互(interaction)是一個行爲單元(behavior unit)，用來呈現一羣對象互相交換信息的狀況。如圖2-50所示，使用大方框將一羣對象圍起來，表明一個交互單元，在大方框內部左上角的框內標示帶有關鍵字sd的交互名稱。

　　

　　圖2-50 交互

　　序列圖一般省略交互的大方框，一張序列圖的內容就是一個交互單元。既然交互是一個行爲單元，固然但願能夠重用(reuse)預先設計好的交互，經過組合多個交互單元，造成另外一個更大的交互單元。

2.5.2 生命線

　　生命線(lifeline)表明一個參與交互的實例，它的圖示是頂端鏈接矩形的虛線，如圖2-51所示，虛線頂部的矩形能夠放置生命線的名稱。

　　

　　圖2-51 生命線

　　2.5.3 執行發生

　　對象在接收到消息以後執行一項活動，執行期間稱爲執行發生(execution occurrence)，如圖2-52所示，它的圖示是長條矩形。

　　

　　圖2-52 執行發生

　　2.5.4 消息

　　消息(message)的圖示是一條帶箭頭的線段，橫跨在兩個生命線上，如圖2-53所示，對象之間經過發送消息來交互。

　　

　　圖2-53 消息

　　如圖2-54所示，序列圖中有四種常見的消息，說明以下：

　　• 建立消息(createMessage)—顧名思義，用來建立對象的消息稱爲建立消息。它的圖

　　示是帶開放性箭頭的虛線，箭頭指向目標對象。

　　• 同步調用(synchCall)—這是最多見的消息。它的圖示是帶實心箭頭的實線，由發送

　　消息的來源對象指向負責執行的目標對象。

　　• 回覆消息(replyMessage)—目標對象執行結束時，會發出回覆消息給來源對象。它的

　　圖示是帶開放式箭頭的虛線，從負責執行的目標對象反向指回來源對象。

　　• 異步信號(asynchSignle)—同步與異步的差異在於，來源對象是否等待目標執行結束

　　才繼續往執行。來源對象若是發送同步消息，會等待，若是發送異步消息，就不等待了。

　　

　　圖2-54 四種消息

　　2.5.5 終止

　　生命線有生有滅，終止(stop)就是用來表達生命線終止的時刻。終止的圖示是一個大叉，放置在生命線的虛線底部，表明生命線已經終止，可鏈接元素已經不存在，如圖2-55所示。

　　

　　圖2-55 終止

　　2.5.6 通常次序

　　一般，不一樣生命線上的事件的發生順序互不相干。可是，若是想指定順序，就得使用通常次序(general ordering)。通常次序的圖示爲中間附箭頭的虛線，如圖2-56所示，:C接到消息p以後，:O纔會發送消息q給:E。

　　

　　圖2-56 通常次序

　　2.5.7 狀態不變式

　　狀態不變式(state invariant)是一種用在生命線上的約束(constraint)。以圖2-57爲例，購物刷卡時，金額(amount)不能超過信用額度(available credit)。能夠在信用卡(credit card)生命線處放置狀態不變式。

　　

　　圖2-57 狀態不變式

　　2.6 用例圖

　　用例圖(use case diagram)是行爲圖的一種，如圖2-58所示。

　　

　　圖2-58 用例圖

　　用例圖用來表達系統對外提供的服務或功能，適合用來做爲需求蒐集階段的工件。在接下來的各小節中，會看到用例圖中常見的概念及圖示。

　　2.6.1 用例與執行者

　　針對系統所執行的一連串動做，把它記錄起來，即成爲用例(use case)。特別注意，用例是行爲的規格記錄，它除了記載一連串的動做外，還必須記載一連串動做的生成結果，且這個生成可知足系統的執行者(actor)或涉衆(stakeholder)。實際上，經常使用用例來表達系統需求(requirements)或者系統對外呈現的行爲(behaviors)。請看圖2-59，這是一個自動櫃員機的範例，用例採用橢圓圖示，名稱可放在橢圓內部或底部。執行者是人型圖示，因爲它會參與系統的運做，所以它跟用例之間有鏈接線段。

　　

　　圖2-59 用例與執行者

　　能夠將自動櫃員機的行爲分別記載成三個不一樣的用例，分別爲提款(withdraw)、轉帳

　　(transfer funds)和存款(deposit money)。並且，自動櫃員機外部一共有兩個執行者會參與自動櫃員機的行爲，一個名爲顧客(customer)，另外一個名爲銀行(bank)。顧客會參與這三個用例，其中只有存款用例會有兩個執行者。

　　2.6.2 包含關係

　　基用例(base use case)所描述的行爲被定義在另外一個被包含用例(included use case)處，二者之間就具備包含關係(include)。以圖2-60爲例，包含關係是一條有<>的帶箭頭虛線，由基用例(base use case)指向被包含用例(included use case)。

　　在圖2-60範例中，提款(withdraw)用例中的部分行爲定義在卡片驗證(card identification)用例裏。換言之，卡片驗證的行爲會被插入到提款的行爲中。

　　

　　圖2-60 包含關係

　　須要特別注意，對於基用例而言，若是缺乏被包含用例將沒法正確執行，因此只要是採用

　　包含關係，則意味着被包含用例內的行爲必定會被執行。

　　2.6.3 擴展關係

　　相對於包含關係必定要執行的特性，擴展關係(extend)則是一種可選擇執行的關係。繼續以自動櫃員機(ATMSystem)爲例，打印收據(print receipt)與提款之間的關係就比較適合採用擴展關係，如圖2-61所示。在提款流程結束以前，會詢問顧客是否須要打印收據，因此打印收據不是一段必要的流程，而是一段可選擇的流程。

　　

　　圖2-61 打印收據適合擴展用例

　　擴展關係的圖示與包含關係雷同， 都是帶箭頭虛線， 差異在於前者的虛線旁設置<>，後者設置<>。另外一個很容易混淆的是箭頭的方向，擴展關係是由擴展用例(extending use case)指向基用例(base use case)，如圖2-62所示，包含關係則是由基用例指向被包含用例。

　　

　　圖2-62 擴展關係

　　2.6.4 擴展點

　　擴展關係一般會搭配擴展點(extension point)來指明擴展的時機點。以圖2-63爲例，提款用例記載了名爲打印(print)的擴展點，意味着打印收據(print receipt)的行爲會插入到打印擴展點處。

　　

　　圖2-63 擴展點