kapok

Donald Bell
IBM 全球服務(wù), IBM
2005 年 2 月 15 日

來自 Rational Edge：這篇文章介紹組件圖，一個在新的統(tǒng)一建模語言 2.0中規(guī)定的結(jié)構(gòu)圖。

該文是關(guān)于在統(tǒng)一建模語言 2.0或UML中使用的基本圖的一系列文章中的一部分。在以前關(guān)于 UML 類圖中，我描述了類圖的標(biāo)記集如何作為所有UML 2結(jié)構(gòu)圖的基礎(chǔ)。隨著UML 2的軌跡，本文介紹組件圖。

圖的目的
組件圖的主要目的是顯示系統(tǒng)組件間的結(jié)構(gòu)關(guān)系。在 UML 1.1 中，一個組件表現(xiàn)了實施項目，如文件和可運行的程序。不幸地，這與組件這個術(shù)語更為普遍的用法、指象COM組件這樣的東西相沖突。隨著時間的推移及UML的連續(xù)版本發(fā)布， UML 組件已經(jīng)失去了最初的絕大部分含義。UML 2 正式改變了組件概念的本質(zhì)意思；在 UML 2 中，組件被認(rèn)為是獨立的，在一個系統(tǒng)或子系統(tǒng)中的封裝單位，提供一個或多個接口。雖然 UML 2 規(guī)范沒有嚴(yán)格地聲明它，但是組件是呈現(xiàn)事物的更大的設(shè)計單元，這些事物一般將使用可更換的組件來實現(xiàn)。但是，并不象在 UML 1. x中，現(xiàn)在，組件必須有嚴(yán)格的邏輯，設(shè)計時構(gòu)造。主要思想是，你能容易地在你的設(shè)計中重用及/或替換一個不同的組件實現(xiàn)，因為一個組件封裝了行為，實現(xiàn)了特定接口。 ¹

在以組件為基礎(chǔ)的開發(fā)（CBD）中，組件圖為架構(gòu)師提供一個開始為解決方案建模的自然形式。組件圖允許一個架構(gòu)師驗證系統(tǒng)的必需功能是由組件實現(xiàn)的，這樣確保了最終系統(tǒng)將會被接受。

除此之外，組件圖對于不同的小組是有用的交流工具。圖可以呈現(xiàn)給關(guān)鍵項目發(fā)起人及實現(xiàn)人員。通常，當(dāng)組件圖將系統(tǒng)的實現(xiàn)人員連接起來的時候，組件圖通常可以使項目發(fā)起人感到輕松，因為圖展示了對將要被建立的整個系統(tǒng)的早期理解。

開發(fā)者發(fā)現(xiàn)組件圖是有用的，因為組件圖給他們提供了將要建立的系統(tǒng)的高層次的架構(gòu)視圖，這將幫助開發(fā)者開始建立實現(xiàn)的路標(biāo)，并決定關(guān)于任務(wù)分配及（或）增進需求技能。系統(tǒng)管理員發(fā)現(xiàn)組件圖是有用的，因為他們可以獲得將運行于他們系統(tǒng)上的邏輯軟件組件的早期視圖。雖然系統(tǒng)管理員將無法從圖上確定物理設(shè)備或物理的可執(zhí)行程序，但是，他們?nèi)匀粴g迎組件圖，因為它較早地提供了關(guān)于組件及其關(guān)系的信息（這允許系統(tǒng)管理員輕松地計劃后面的工作）。

符號
在現(xiàn)在，組件圖符號集使它成為最容易畫的 UML 圖之一。圖 1 顯示了一個使用前 UML 1.4 符號的簡單的組件圖；這個例子顯示兩個組件之間的關(guān)系：一個使用了Inventory System組件的Order System組件。正如你所能見到的，在UML 1.4 中，用一個大方塊，并且在它的左邊有兩個凸出的小方塊，來表示組件。

圖 1：這個簡單的組件圖使用 UML 1.4 符號顯示Order System的一般性依賴關(guān)系

上述的 UML 1.4 符號在 UML 2 中仍然被支持。然而，UML 1.4 符號集在較大的系統(tǒng)中不能很好地調(diào)節(jié)。關(guān)于這一點的理由是，如同我們在這篇文章的其余部分將會見到一樣，UML 2 顯著地增強了組件圖的符號集。在維持它易于理解的條件下，UML 2 符號能夠調(diào)節(jié)得更好，并且符號集也具有更多的信息。

讓我們依照 UML 2 規(guī)范一步步建立組件圖。

基礎(chǔ)
現(xiàn)在，在 UML 2 中畫一個組件很類似于在一個類圖上畫一個類。事實上，在 UML 2 中，一個組件僅僅是類概念的一個特殊版本。這意味著適用于類分類器的符號規(guī)則也適用于組件分類器。（如果你已經(jīng)讀了并理解了我以前的關(guān)于大體上的結(jié)構(gòu)圖和類圖細(xì)節(jié)的文章 [http:// www. ibm.com/developerworks/cn/rational/rationaledge/content/feb05/bell/index.html]，你就會很易理解組件圖）。

在 UML 2 中，一個組件被畫成堆積著可選擇小塊的一個立著的長方形。UML 2 中，組件的一個高層次的抽象視圖，可以用一個長方形建模，包括組件的名字和組件原型的文字和/或圖標(biāo)。組件原型的文本是“?component?”，而組件原型圖標(biāo)是在左邊有兩個凸出的小長方形的一個大長方形（UML 1.4 中組件的符號元素）。圖 2 顯示，組件可以用UML 2規(guī)范中的三種不同方法表示。

圖 2：畫組件名字區(qū)的不同方法

當(dāng)在圖上畫一個組件時，重要的是，你總要包括組件原型文本（在雙重尖括號中的那個component，如圖 2 所示）和/或圖標(biāo)。理由呢？在 UML 中，沒有任何原型分類器的一個長方形被解釋為一個類組件。組件原型和/或圖標(biāo)用來區(qū)別作為組件元素的長方形。

為組件提供/要求接口建模
在圖 2 中所畫的Order組件表現(xiàn)了所有有效的符號元素；然而，一個典型的組件圖包括更多的信息。一個組件元素可以在名字區(qū)下面附加額外的區(qū)。如前面所提到的，一個組件是提供一個或更多公共接口的獨立單元。提供的接口代表了組件提供給它的用戶/客戶的服務(wù)的正式契約。圖 3 顯示了Order組件有第二個區(qū)，用來表示Order組件提供和要求的接口。 ²

圖 3：這里額外的區(qū)顯示Order組件提供和要求的接口。

在圖 3 中的Order組件例子中，組件提供了名為 OrderEntry 和 AccountPayable 的接口。此外，組件也要求另外一個組件提供Person接口。 ³

組件接口建模的其它方法
UML 2 也引入另外一種方法來顯示組件提供并要求的接口。這個方法是建立一個里面有組件名的大長方形，并在長方形的外面放置在 UML 2 規(guī)范中稱為接口符號的東西。這第二種方法在圖 4 中舉例說明。

圖 4: 一種可選擇的方法（與圖3相比）：使用接口符號顯示組件提供/要求的接口

在這第二種方法中，在末端有一個完整的圓周的接口符號代表組件提供的接口 -- “棒棒糖”是這個接口分類器實現(xiàn)關(guān)系符號的速記法。在末端只有半個圓的接口（又稱插座）符號代表組件要求的接口（在兩種情況下，接口的名字被放置在接口符號本身的附近）。即使圖 4 看起來與圖 3 有很大的不同，但兩個圖都提供了相同的信息 -- 例如，Order組件提供兩個接口：OrderEntry 和 AccountPayable，而且Order組件 要求 Person接口。

組件關(guān)系的建模
當(dāng)表現(xiàn)組件與其他的組件的關(guān)系時，棒棒糖和插座符號也必須包括一支依存箭頭（如類圖中所用的）。在有棒棒糖和插座的組件圖上，注意，依存箭從強烈的（要求的）插座引出，并且它的箭頭指向供應(yīng)者的棒棒糖，如圖 5 所示。

圖 5：顯示Order系統(tǒng)組件如何依賴于其他組件的組件圖

圖 5 顯示，Order系統(tǒng)組件依賴于客戶資源庫和庫存系統(tǒng)組件。注意在圖 5 中復(fù)制出的接口名 CustomerLookup 和 ProductAccessor。 在這個例子中，這看起來可能是不必要的重復(fù)，不過符號確實允許在每個依賴于實現(xiàn)差別的組件中有不同的接口（和不同的名字）（舉例來說，一個組件提供一個較小的必需的接口子類）。

子系統(tǒng)
在 UML 2 中，子系統(tǒng)分類器是組件分類器的一個特別版本。因為這一點，子系統(tǒng)符號元素象組件符號元素一樣繼承所有的組件符號集規(guī)則。唯一的差別是，一個子系統(tǒng)符號元素由subsystem關(guān)鍵字代替了component，如圖 6 所示。

圖 6：子系統(tǒng)元素的一個例子

UML 2 規(guī)范在如何區(qū)別子系統(tǒng)與組件方面相當(dāng)含糊。從建模的觀點，規(guī)范并不認(rèn)為組件與子系統(tǒng)有任何區(qū)別。與 UML 1. x 相比較，這個 UML 2 模型歧義是新的。但是有一個理由。在 UML 1. x 中，一個子系統(tǒng)被認(rèn)為是一個軟件包，而且這個軟件包符號正對許多 UML 實踐者造成困惑；因此，UML 2中把子系統(tǒng)作為特殊的組件，因為這是最多的 UML 1. x 使用者了解它的方式。這一改變確實把模糊引入圖中，但是這一模糊更多的是 UML 2 規(guī)范中對抗錯誤的一個現(xiàn)實反射。

到這里，你可能正在抓著頭皮并感到疑惑，什么時候該用組件元素，什么時候又該用子系統(tǒng)元素。相當(dāng)坦率地說，我沒有一個直接的答案給你。我可以告訴你，UML 2 規(guī)范中說，何時該使用組件或子系統(tǒng)決定于建模者的方法論。我個人很喜歡這個答案，因為它幫助確保UML與方法論相互獨立，這在軟件開發(fā)中將幫助保持它的普遍可使用。

超越基礎(chǔ)
組件圖是比較容易理解的圖之一，因此沒有很多超越基礎(chǔ)的內(nèi)容。然而，有一個方面你可以認(rèn)為是略微困難的。

顯示組件的內(nèi)部結(jié)構(gòu)
有時候顯示組件的內(nèi)部結(jié)構(gòu)是有意義的。在關(guān)于類圖的我的前面的文章中，我顯示了該如何為類的內(nèi)部結(jié)構(gòu)建模；這里，當(dāng)它由其他組件組成的時候，我將會關(guān)注如何為組件的內(nèi)部結(jié)構(gòu)建模。

為了顯示組件的內(nèi)部結(jié)構(gòu)，你只需把組件畫得比平常大一些并在名字區(qū)內(nèi)放置內(nèi)部的部分。圖 7 顯示Store組件的內(nèi)部結(jié)構(gòu)。

圖 7: 這個組件的內(nèi)部結(jié)構(gòu)由其他組件組成。

使用在圖 7 中顯示的例子，Store組件提供了 OrderEntry 接口并要求Account接口。Store組件由三個組件組成：Order，Customer和Product組件。注意Store的 OrderEntry 和Account接口符號在組件的邊緣上為何有一個方塊。這一個方塊被稱為一個端口。單純感覺來說，端口提供一種方法，它顯示建模組件所 提供/要求 的接口如何與它里面的部分相關(guān)聯(lián)。 ⁴ 通過使用端口，我們可以從外部實例中分離出Store組件的內(nèi)部部件。在圖 7 中，對于過程而言，OrderEntry 端口代表Order組件的 OrderEntry 接口。同時，內(nèi)部的Customer組件要求的Account接口被分配到Store組件的必需的Account端口。通過連接Account端口，Store組件內(nèi)部部件（例如Customer組件）可以有代表執(zhí)行端口接口的未知外部實體的本地特征。必需的Account接口將會由Store組件的外部組件實現(xiàn)。 ⁵

在圖 7 中，你可能也注意到了，在內(nèi)部的組件之間的內(nèi)部連接與圖 5 中顯示的那些不同。這是因為內(nèi)部結(jié)構(gòu)的這些描繪事實是嵌套在分類器（在我們的例子中是一個組件)里的協(xié)作圖，因為協(xié)作圖顯示分類器中的實體或角色。在內(nèi)部的組件之間建模的關(guān)系以 UML 稱為的一個組合連接器表示。一個組合連接器綁定一個組件 提供 的接口到另外的一個組件的 必需 接口。組合連接器用緊緊相連的棒棒糖和插座符號表示。以這種方式畫這些組合連接器使棒棒糖和插座成為很容易理解的符號。

結(jié)論
組件圖經(jīng)常是一個架構(gòu)師在項目的初期就建立的非常重要的圖。然而，組件圖的有用性跨越了系統(tǒng)的壽命。組件圖是無價的，因為它們模型化和文檔化了一個系統(tǒng)的架構(gòu)。因為組件圖文檔化了系統(tǒng)的架構(gòu)，開發(fā)者和系統(tǒng)可能的系統(tǒng)管理員會發(fā)現(xiàn)這一工作的關(guān)鍵產(chǎn)品有助于他們理解系統(tǒng)。

組件圖也視為軟件系統(tǒng)配置圖的輸入，這將會是本系列后面的文章主題。

腳注
¹在UML1.x 中稱為組件的實際項目，在 UML 2 中稱為產(chǎn)物。一個產(chǎn)物是一個物理單位，象一個文件，可運行的程序，腳本，數(shù)據(jù)庫等等。只有一種產(chǎn)物依賴于實際的節(jié)點；類和組件沒有“位置”。然而，一個產(chǎn)物可能顯示組件和其他的分類器（例如類）。一個單一的組件可能通過多重產(chǎn)物顯示，它們可能是在相同的或不同的節(jié)點上，因此，一個單一的組件可以間接地在多重節(jié)點上被實現(xiàn)。

²即使組件是獨立的單元，它們?nèi)匀豢赡芤蕾囉谄渌M件提供的服務(wù)。由于這一點，文檔化一個組件的必需接口是很有用的。

³圖3并不顯示Order組件完整的上下文。在一個真實的模型中，OrderEntry，AccountPayable 和Person接口會呈現(xiàn)在系統(tǒng)的模型中。

⁴事實上，端口適用于任何類型的分類器（例如，一個類或者你的模型中可能會有的其他分類器）。為了使本文簡潔，我在組件分類器及它們的使用中提及端口。

⁵一般來說，當(dāng)你畫一個端口和一個接口之間的依存關(guān)系時，依賴方（要求）的接口將會在運行時間內(nèi)處理所有的處理邏輯。然而，這并不是一種硬性的規(guī)定 -- 對于周圍的組件（舉例來說，我們例子中的Store組件），使用自己的進程邏輯，而不是僅把進程委托給依賴接口，是完全可以接受的。

參考資料

1. 您可以參閱本文在 developerWorks 全球站點上的 英文原文。

關(guān)于作者 Donald Bell是IBM全球服務(wù)的一個IT專家，在那兒他和IBM的客戶一起致力于設(shè)計和開發(fā)基于軟件解決方案的J2EE。