UML的哪些事兒

HTML IDE UML C/C++ Go 9144 次瀏覽

有人說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.1 類

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

如圖2-2所示，定義員工(worker)類之后，便可以依據此類的描述產生一群對象。這些:Worker對象不僅可以共用類所定義的屬性，擁有自己的屬性值，還可以共用類所定義的操作，或者共用約束。

圖2-1 類圖

圖2-2 類與對象

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

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

圖2-3 類圖示

圖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所示。在

UML 2中，關聯的箭頭端代表具有導航性。打個小叉就是不可導航;單純直線代表還未指定可導航或不可導航。所以，回到圖2-11的例子中，可以看到

? AB是雙向關聯。

? CD兩端都不具有導航性。

? EF尚未指定兩端是否具導航性。

? GH為單向關聯，可由G導航到H。

? I端還未決定可否導航，可以確定的是，可由I導航到J。

圖2-11 關聯圖示

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接口。

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

圖2-18 接口

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

圖2-34 活動圖

圖2-35 活動圖

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

2.4.1 動作與控制流

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

連接動作的帶箭頭實線稱為控制流(control flow)。當來源動作結束之后，控制流會啟動目標動作。如圖2-37所示，寄送發票(send invoice)的動作執行完之后，會通過控制流啟動付款(make payment)動作。

圖2-36 動作

圖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所示。在提款流程結束之前，會詢問顧客是否需要打印收據，所以打印收據不是一段必要的流程，而是一段可選擇的流程。