構件: 封裝體
這個構件是一種特殊的設計型樣,代表系統中封裝的控制緒。
工作成果類型: 模型元素
關係
說明
主要說明

封裝體代表一種特殊型式的類別結構和組合,在塑造和設計高度並行性的系統時,已證實很有用。 對特定、證實的設計型樣,以封裝體做為簡略的符號,可讓設計更簡單又不易出錯。

封裝體以「類別」表示,且以 <<capsule>> 為模板。如下圖所示,封裝體是複合元素。

圖解說明詳見隨附的文字。

封裝體組合

如上所示,封裝體可能有埠,還可能「包含」被動類別及/或子封裝體。 也可能有狀態機,完整地描述封裝體的行為。 準則:封裝體中說明封裝體的特殊分類架構及各種用途。

調整
表示法選項UML 表示法:類別,以 <<capsule>> 為模板。請注意,此表示法以 UML 1.5 符號為根據。 其中有許多可以在 UML 22.0 中以概念:結構化類別來表示。 如需相關資訊,請參閱UML1.x 和 UML 2.0 的差異

如下圖所示,封裝體是複合元素。

複合元素圖

封裝體組合

封裝體可能有埠,還可能「包含」被動類別及/或子封裝體。 也可能有狀態機,完整地描述封裝體的行為。 準則:封裝體中說明封裝體的特殊分類架構及各種用途。

內容

一個封裝體中封裝一個控制緒。封裝體代表系統中獨立控制緒的抽象概念;是系統中主要的並行單元。 利用作業系統流程和執行緒,將封裝體對映到特定的作業系統流程執行緒,可以加強隔離控制緒。 訊息會透過埠而送到封裝體,然後循序處理;如果封裝體實例很忙碌,訊息會排隊等候。 封裝體採取「完整執行」的語意,在收到一個事件時,一定會完全處理,而不論其他抵達事件的數量或優先順序。

封裝體透過埠與週遭環境互動。埠是以信號為主的界限物件;居中調解封裝體和外界的互動。 埠會實作特定的介面,且可能依賴特定的介面。 除了埠以外,封裝體不能有操作或其他公開部分,埠是與外界互動的唯一管道。

每一個埠在合作中扮演特定的角色。合作描述封裝體和其他物件如何互動。 為了捕捉這些互動的複雜語意,埠和通訊協定之間有關聯,通訊協定在連接的封裝體埠之間定義有效的資訊流程(信號)。 通訊協定捕捉存在封裝體之間明訂的義務。 強制封裝體只能透過埠來溝通,就有可能將封裝體的內部實作和封裝體週遭的環境完全隔離。 於是,提高封裝體的重複使用性。

簡單封裝體的功能直接由封裝體的狀態機來實現。較複雜的封裝體不僅有狀態機, 還會結合分工合作的子封裝體(以連接器銜接)所形成的內部交錯網路。 這些子封裝體是獨立的封裝體,本身可以再拆解為子封裝體。這樣的分解不限深度,只要有這組基本的結構化建模構件,不論多複雜的結構,都可以塑造。 狀態機(複合封裝體可選用的)、子封裝體及其連線網路,代表封裝體的實作部分,外部觀察者無法得知。

封裝體可能是複合元素。封裝體可能由其他封裝體和被動式類別構成。 封裝體和被動式類別由合作關係裡的連接器或鏈結串連起來;此合作關係定義封裝體的「結構」, 因此稱為「規格合作」。封裝體可能有狀態機,可以透過封裝體的端點埠來接送信號,並控制內部結構的某些元素。 因此,此狀態機可能用來實作反射行為,亦即,控制封裝體本身操作的行為。

 

埠是物件,用途是扮演封裝體實例的界限物件。由於埠會隨著封裝體一起建立,也隨著封裝體一起消失,由此可知,封裝體實例「擁有」埠。 每一個埠有身分和狀態,不同於擁有此埠的封裝體實例的身分和狀態(就好比任何零件不同於容器一樣)。

雖然埠是扮演介面的界限物件,但不直接對映到 UML 介面。UML 介面純粹只是行為事物 - 沒有實作結構。 相反地,埠包含結構和行為,為封裝體結構的組成部分,不只是行為的限制而已。 埠可以實現所謂的「資訊清單介面」的架構型樣。

在 UML 中,我們將埠塑造為 <<port>> 模板的類別。 如先前所述,埠的類型由此埠扮演的通訊協定角色來定義。 因為通訊協定角色是抽象類別,對應於此實例的實際類別就是實作此埠的相關通訊協定角色的類別。 在 UML 中,埠和通訊協定角色之間的關係稱為實現關係。 以虛線加上規格端點上的實心三角箭頭為表示法。 這是一種一般化,來源元素(埠)只繼承目標(通訊協定角色)的行為規格,不繼承結構。

封裝體和埠之間存在組合關係。如果此關係在目標端的多重性大於 1, 則表示埠在執行時期存在多個實例,每一個埠實例參與不同的通訊協定實例。 如果多重性是一個值範圍,則表示埠的數目在執行時期會改變,且可能動態地建立和銷毀(可能根據限制而定)。

封裝體和埠的圖解

埠、通訊協定及通訊協定角色

上圖顯示單一埠 b 和所屬的封裝體類別 CapsuleClassA。此埠實現通訊協定類別 ProtocolA 所定義的主控通訊協定角色。 請注意,在實作階段以前,建模人員通常不會注意實際的埠類別 PortClassX(在不同的實作中可能不同的實作類別)。 相反地,資訊重點在於此埠實作的通訊協定角色。 基於這個理由及為了方便表達,通常不會採用圖 1 顯示的表示法,而會改採下節中更簡潔的格式。

表示法

在類別圖中,封裝體的埠會列在特殊的標籤清單隔間,如圖所示。清單隔間通常出現在屬性和運算子清單隔間後面。 此表示法利用 UML 特性,可以增加特別命名的隔間。

埠的類別圖

埠表示法 - 類別圖呈現

所有對外埠(轉接埠和公用端點埠)都有公開的可見度,而內在埠的可見度受到保護(例如,埠 b2)。 埠的通訊協定角色(類型)通常以路徑名稱來識別,因為通訊協定角色名稱只在特定通訊協定的範圍內才是唯一的。 例如,埠 b 扮演通訊協定類別 ProtocolA 中定義的主控角色。 對於很常見的二進位通訊協定,採用更簡單的表示法慣例: 字尾波浪符號 ("~") 表示共軛通訊協定角色(例如埠 b2), 無特殊註解則表示基本的角色名稱(例如埠 b1)。 多重性不是 1 的埠以方括弧括住多重性因數。 例如,埠 b1[3] 的多重性因數剛好是 3,而 b5[0..2] 指定的埠有不固定數量的實例,但不超過 2。

連接器

連接器代表通訊通道,提供傳輸設備來支援特定的信號式通訊協定。 連接器的一項重要特性是只能與在連接器相關的通訊協定中扮演輔助角色的埠交互連接。 尤其,通訊協定角色不一定屬於相同的通訊協定,但如果是此情況,則必須與連接器的通訊協定相容。

連接器是信號式通訊通道的抽象觀念,將兩個以上的埠互相連接起來。 經由連線來連結的埠在通訊協定中必須扮演互補又相容的角色。 在合作圖中,以關聯角色來表示,這些角色將適當的埠互相連接起來。 如果從這個圖中抽掉埠,連接器實際上會呈現封裝體之間的重要通訊關係。 這些關係對架構影響重大,因為可指出哪些封裝體會透過直接通訊而彼此影響。 加入埠之後,可以依照資訊隱藏和問題隔離的原則,將封裝體封裝起來。

連接器和通訊協定的相似性可能讓人以為兩種概念相同。 事實上並非如此,因為通訊協定是所需行為的抽象規格,而連接器是實體物件,用途只是將信號從一個埠傳送至另一個埠。 連接器本身通常是被動式導線管。(實際上,實體連接器有時偏離指定的行為。例如,由於內部故障,連接器可能失去、重新排序或重複訊息。 這樣的故障在分散式通訊通道中很常見。)

在相對應的封裝體類別上,連接器塑造為兩個以上的埠之間存在的關聯。 (在進階的應用程式中,連接器具有實體內容,可能會使用關聯類別,因為連接器實際上是具有狀態和身分的物件。 就像埠一樣,用來實現連接器的實際類別是實作上的問題。) 連接的埠隱含表示相對於支援通訊協定的關係。 因此,不需要 UML 延伸來表示連接器。

規格合作

封裝體的完整內部結構以規格合作來表示。此合作包含所有的埠、子封裝體及連接器的詳細規格。 就像埠一樣,子封裝體和連接器由封裝體直接擁有,不能在封裝體之外獨立存在。 也是隨著封裝體一起建立,隨著封裝體一起消失。

結構中有些子封裝體可能不會隨著所屬封裝體一起建立。 而是後來在必要時,由封裝體的狀態機建立。 狀態機也可能隨時銷毀這些封裝體。 這符合 UML 的組合規則。

封裝體的結構可能包含所謂的外掛程式角色。 事實上,子封裝體有保留的位置可以動態地填入。 這有必要,因為事前無法得知哪些特定物件會在執行時期扮演這些角色。 取得這項資訊之後,適當的封裝體實例(由其他一些複合封裝體擁有)可以「插入」這個插槽, 接著就會自動建立在合作中將埠連結到其他子封裝體的連接器。 不再需要動態關係時,封裝體會從外掛程式插槽中「移除」,也會卸下連接器。

動態建立的子封裝體和外掛程式可以塑造動態變化的結構,同時確保明確地指出封裝體之間有效的所有通訊和包含關係。 在複雜的即時系統中,這是確保架構完整性的關鍵。

埠也可能在規格合作圖中描述。在這些圖中,物件以適當的分類器角色來表示,亦即,以封裝體角色來表示子封裝體,以埠角色來表示埠。 為了避免太雜亂,埠角色通常以圖示呈現,以黑色或白色的小方框表示。 公用埠以埠角色圖示來表示,橫跨在相對應的封裝體的界限上,如上圖所示。 如此的簡略符號可以從封裝體的內外連接到埠,不致於線條盤根錯節,也可以很清楚地表達為界限物件。

公用埠和封裝體角色圖

埠表示法 - 規格合作圖

請注意,標籤是埠角色的裝飾品,請勿與連接器的關聯端點名稱混淆。 另外,由於埠是以名稱來辨識唯一性,為了方便描繪,很可能沿著子封裝體方框的邊緣,以任意順序排列公用埠角色。 如此可以儘量減少連接器線條交叉。

對於二進位通訊協定,可以使用額外的模板圖示:扮演共軛角色的埠以白色實心(相對於黑色實心)方框表示。 在此情況下,通訊協定名稱和波浪字尾就足以表示通訊協定角色是共軛角色;通訊協定角色名稱顯得多餘,應該省略。 同樣地,在黑色方框上只使用通訊協定名稱,表示通訊協定的基本角色。 比方說,如果通訊協定 ProtQ 的「主控」角色宣告為基本,則下圖和下圖中的圖型相同。 此慣例很容易看出輔助通訊協定角色何時連接。

通訊協定角色圖

二進位通訊協定的符號慣例

多重性因數大於 1 的埠也可以利用標準 UML 的多物件表示法來描繪,如下圖所示。 這不是絕對必要(多重性字串就足夠),但可以強調埠有多重實例的可能性。

多物件的 UML 圖

多重性因數大於 1 的埠

狀態機

封裝體相關的選用性狀態機只是封裝體實作的另一部分。不過,仍然有一些特殊內容,可以區分狀態機與封裝體的其他成份:

  • 無法再進一步拆解為子封裝體。直接指定行為。不過,利用標準的 UML 功能,狀態機可以拆解為更簡單的狀態機階層。
  • 每一個封裝體最多只有一個狀態機(但子封裝體可以有自己的狀態機)。 不具狀態機的封裝體是子封裝體的簡單容器。
  • 處理在封裝體的任何端點埠上抵達的信號,也可以透過這些埠傳送信號。
  • 唯一可存取封裝體內在保護部分的實體。這表示扮演其他所有子封裝體的控制器。 因此,可以建立和銷毀這些指定為動態的子封裝體,也可以視情況插入和移除外部子封裝體。

動態建立的子封裝體直接以可變的多重性因數來表示。就像外掛程式插槽一樣,這些也可以用純介面類型來指定。 這表示在實例化時,可以實例化支援此介面的任何實作類別。 這樣可以形成結構化規格的一般化。

姑且不論其他限制,封裝體相關的狀態機是以「UML 分類器」和「狀態機」之間的標準鏈結來塑造。 封裝體的實作/分解是由可透過分類器產生關聯的標準 UML 合作元素來塑造。  

詳細資訊
核對清單
準則