概念: 元件
元件是系統的封裝組件,理論上是一個特殊、近乎獨立且可更換的系統組件,在定義嚴謹的架構環境下,可以實現一項完整的功能。
關係
主要說明

定義

軟體業界和文獻採用「元件」一詞來代表許多不同的事物。廣義上,通常泛指「一個構成組件」。在狹義上,也經常用來表示在較大型系統中允許更換和組合的特殊特性。

在 RUP 中,「元件」一詞代表系統的封裝組件,理論上是一個特殊、近乎獨立且可更換的系統組件,在定義嚴謹的架構環境下,可以實現一項完整的功能。包括:

  • 設計元件 - 重要的設計封裝組件,包括設計子系統,有時也代表重要的設計類別和設計套件。
  • 實作元件 - 重要的實作封裝組件,通常是一個設計元件的實作程式碼。

理論上,設計會反映實作,所以只說「元件」即可,因為每一個元件都有設計和實作。

UML ([UML04]) 對「元件」的定義如下:

系統的模組化組件,封裝本身的內容且在環境內可更換表徵。元件根據供應和需求介面來定義行為。因此,元件就是一種類型,由這些供應和需求介面來定義相符度(包含靜態及動態語意)。

元件定義為結構化類別的子類型,因此元件具有屬性和操作、可參與關聯和一般化,也具有內部結構和埠。如需詳細資訊,請參閱概念:結構化類別

元件有許多適用的 UML 標準模板,例如 <<subsystem>> 適合為大量元件建立模型,<<specification>> 和 <<realization>> 適合對規格和實現定義截然不同的元件建立模型 而一種規格可能會有多種實現。

RUP 在「元件」一詞的用法上比 UML 定義更廣泛。我們不贊成將元件定義為具有特性,例如模組性、部署性及更換性,只建議將這些特性視為元件的理想特性即可。請參閱下節「元件更換性」。

元件更換性

在 RUP 和 UML 術語中,元件是可更換的。不過,這僅表示元件公開一組介面,而將底層的實作隱藏起來。

還有其他更強大的更換性。列示如下。

程式檔更換性

如果單一程式碼檔案中有兩個實作類別,則通常無法分開建立各類別的版本或單獨控制類別。

然而,如果有一組檔案完全只實作單一元件,不含其他任何元件,則此元件可更換程式檔。這種特性讓元件程式碼變得很容易進行版本控制、設定基準線及重複使用。

部署更換性

如果以單一執行檔來部署兩個類別,則各類別在部署的系統中無法獨立更換。

粗略元件的理想特性是「部署更換性」,直接可部署元件的新版本,不必重建其他元件。這通常表示由一支檔案或一組檔案來部署此元件,且不會部署其他任何元件。

執行時期更換性

如果元件可重新部署到正在執行的系統,則稱為具有「執行時期更換性」。 如此一來,軟體可以在不損及可用性的情況下直接升級。

位置透通性

提供網路可定址介面的元件稱為具有「位置透通性」。如此,元件可以重新安置在其他伺服器上,或抄寫至多個伺服器上,以支援容錯、負載平衡等等。這種元件通常稱為「分散式」或「可分散」的元件。

建立元件的模型

UML 元件是一個提供下列功能的建模區塊:

  • 可以將類別組合起來定義一個系統的粗略組件
  • 可以將可見的介面和內部實作分開
  • 可以具有在執行時期執行的實例

一個元件有許多供應和需求「介面」,形成元件串連在一起的基礎。供應「介面」是指由元件直接實作或由其中一個實現類別或子元件實作的介面,或指「元件」的供應「埠」的類型。需求介面是以「元件」或其中一個實現類別或子元件提出的「使用相依關係」來表示,或指需求「埠」的類型。

元件透過公開的可見內容和操作而構成其外部觀點(或「黑箱」觀點)。(選擇性)介面、埠及元件本身可以附加行為,例如通訊協定狀態機,經由在一連串操作呼叫中明確定義動態限制,更精確地定義外部觀點。元件在一個系統或其他環境中相互佈線結構,則可利用元件介面之間的相依關係來定義(通常在元件圖上)。

(選擇性)利用組合結構中的組件和連接器,指定元件之間的角色或實例層次的合作,可以建立更詳細的結構化合作規格。這就是元件經由私有內容和實現類別或子元件所形成的內部觀點(或「白箱」觀點)。此觀點指出內部如何實現外部的行為。內外部觀點之間的對映關係主要是透過相依關係(在元件圖上)或指向內部組件的委派連接器指向內部組件(在組合結構圖)來呈現。

RUP 建議以元件做為「設計子系統」的表示法。如需詳細資訊,請參閱:工作成果:設計子系統作業:子系統設計,及 準則:設計子系統。另外,請參閱概念:結構化類別中的定義。

建立元件的實例

元件不一定會在執行時期直接建立實例。

間接建立實例的元件是由一組類別、子元件或組件來實作或實現。元件本身不存在實作中;只是做為實作必須遵循的設計。這組實現類別、子元件或組件必須含括元件的供應介面中指定的整組操作。實作元件的方式由實作人員自行決定。

直接實例化的元件指定本身封裝的實作;實例化為可定址物件。這表示設計元件在實作語言中有相對應的建構,因此可以明確地參照。

UML 1.x 表示法

UML 1.5 對「元件」的定義如下:

系統中的一個模組化、可部署且可更換的組件,封裝實作並公開一組介面。元件通常由本身的一或多個類別或子元件來指定,且可能透過一或多個構件來實作(例如,二進位、執行檔或 Script 檔)。

請注意,在 UML 1.3 及舊版的 UML 中,以「元件」表示法來代表實作的檔案。最新的 UML 定義不再將檔案視為「元件」。不過,仍然有許多工具和 UML 設定檔以元件表示法來代表檔案。如需在 UML 中代表檔案的相關討論,請參閱 準則:實作元素

從建模的觀點來看,元件相當於 UML 1.5 中的「UML 子系統」,因為同樣提供模組性、封裝,且實例可以在執行時期執行。RUP 將 UML 1.5 的元件建模架構視為表示「設計子系統」的替代表示法。如需詳細資訊,請參閱 工作成果:設計子系統準則:設計子系統

如需相關資訊,請參閱 UML 1.x 和 UML 2.0 的差異