UML組件圖的詳細(xì)介紹

這篇文章主要講解了“UML組件圖的詳細(xì)介紹”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“UML組件圖的詳細(xì)介紹”吧！

組件關(guān)系的建模

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

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

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

子系統(tǒng)

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

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

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

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

超越基礎(chǔ)

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

顯示組件的內(nèi)部結(jié)構(gòu)

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

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

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

結(jié)論

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

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

腳注

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

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

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

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

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

感謝各位的閱讀，以上就是“UML組件圖的詳細(xì)介紹”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對UML組件圖的詳細(xì)介紹這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！