主題
由於埠是在封裝體的界限上,因此,封裝體內外都能見到它們。當從外面看時,所有埠都呈現無法穿透的相同物件介面,除了身分識別及在通訊協定中扮演的角色各不相同之外,它們沒有任何區別。
不過,當從封裝體內部檢視時,我們發現埠有兩種:傳遞埠和端點埠。 它們的不同在於內部連線 - 傳遞埠連接到子封裝體,端點埠連接到封裝體狀態機。
一般而言,傳遞埠用來選擇性地匯出內部子封裝體的「介面」,端點埠則是封裝體狀態機的界限物件。傳遞埠和端點埠都能出現在封裝體的界限上,如上所述,從外面無法區分它們。
傳遞埠是只用來傳遞所有信號的埠。它們在封裝體的殼上提供一個「開口」,使子封裝體既不暴露於外界,又能外界通訊(反之亦然)。傳遞埠利用連接器來連接子封裝體,通常也會從外面連接到其他「同層級」封裝體。它們接收來自任何一端的信號,再遵循信號流程的方向,將信號簡單傳遞到另一端。除非另一端沒有連接器,否則,作業不會有任何延遲,資訊也不會遺失。如果另一端沒有連接器,信號就會遺失。
傳遞埠可讓針對封裝體的信號直接(零額外負荷)委派給子封裝體,封裝體狀態機並不需要介入。傳遞埠只能出現在封裝體的界限上,因此,一律會有 public 可見度。
如果要有用,連接器的鏈最後必須終止於與狀態機通訊的端點埠。端點埠是封裝體狀態機的界限物件(不過,如我們所將見到,它們有些也能作為封裝體的界限物件)。端點埠是封裝體送出的所有信號的最終來源和接收槽。
這些信號都是封裝體的狀態機所產生的。如果要傳送信號,狀態機會在它的一個端點埠上呼叫一項傳送或呼叫作業。之後,會透過相連的連接器來傳遞這個信號,可能會通過一或多個傳遞埠和鏈接的連接器,直到最後發現另一個端點埠為止,它通常是在另一個封裝體中。由於以信號為基礎的通訊可以非同步,因此,端點埠會有一個保留狀態機已收到而尚未處理之訊息的佇列(也就是說,它扮演信箱的角色)。信號的接收以及負責接收的狀態機之分派,是由狀態機根據標準
UML 語意來執行。
如同傳遞埠,端點埠也可能出現在含有 public
可見度的封裝體界限上。這些埠稱為公用端點埠。這些埠同時是狀態機和包含封裝體的界限物件。不過,端點埠也可以完全在封裝體內,成為內部實作結構的一部分。狀態機會利用這些埠來與它的子封裝體通訊,或與外部實作支援層通訊。這些內部端點埠稱為
受保護的端點埠,因為它們的可見性是 protected。
請注意,埠的種類完全取決於內部的連線及它在封裝體外的可見度;各種詞彙(傳遞埠、公用端點埠、私密端點埠)都只是速記的專有名詞。沒有內部連線的公用埠有可能成為傳遞埠或端點埠,這會隨著它後來的連接方式而不同,它也有可能維持未連接狀態,而成送入信號的接收槽。
從外部觀點來看,埠就是埠;判斷埠是傳遞埠或端點埠,既不可能,也不需要。 不過,當顯示封裝體的分解時,我們可以見到封裝體的內部,端點埠/傳遞埠會有如下圖所示的差別。
埠表示法 - 通訊圖(內部視圖)
實際上,同一個封裝體往往會有兩個或更多埠使用相同的通訊協定,但它們的語意有別。 另外,相同的信號也可能出現在封裝體的不同埠所支援的多個通訊協定角色中。
不論任何一種情況,都可能需要區分接收現行信號的特定端點埠。這使得應用程式能夠根據信號來源及狀態,用不同的方式來處理相同的信號。我們稱這類觸發程式為基於埠的觸發程式。在 UML
中,是利用檢查特定來源端埠的警戒條件來建立基於埠的觸發程式的模型。
封裝體狀態機組件的規格和有效通訊協定順序的規格利用標準 UML 狀態機來完成的。
如人們所預期,在大部分即時系統中,時間是第一優先的考量。一般而言,有兩種以時間為基礎的狀況形式需要建模:在一日特定時間觸發作業的能力,以及從給定的時間點開始,在過了特定間隔之後觸發作業的能力。
大部分即時系統都需要可明確直接存取(可控)的計時機能 -
時間服務。這項服務可利用標準埠(服務存取點)來存取,它會將時間轉換成各項事件,之後,便能依照其他基於信號之事件的相同方式來處理這些事件。例如,在這類服務之下,狀態機可能會要求在到了每天的特定時間或過了特定間隔之時,收到「逾時」事件的通知。
封裝體作為一個概念,可採許多不同的方式來使用。為了反映這一點,我們可以利用封裝體階層和分類架構來涵蓋封裝體的一般用法。
顯示一般化階層的封裝體分類架構
以下是基本的封裝體分類架構:
-
封裝體
基本封裝體沒有埠、內部結構或行為,不很有趣,也不很有幫助。 這類封裝體可用來定義能夠衍生其他封裝體的抽象封裝體。 由於未定義任何埠、結構或行為,這個封裝體類型只能用來定義稍後要修正的「位置保留符號」。
-
角色類型
封裝體「角色類型」由定義了含有一或多個埠之抽象封裝體的封裝體定義組成;未定義任何結構或行為。當需要一次定義一組封裝體的「介面」(埠)時,便使用這類封裝體,這些封裝體的特定實現化由「角色類型」封裝體的子類型來定義。
-
角色模型
「角色模型」封裝體由含有內部結構(規格協同作業所定義)的封裝體定義組成,這個內部結構含有巢狀封裝體及可能交互連接的封裝體,可能會有一或多個埠。這類封裝體用來定義系統結構的「範本」,它的「細節」會委派給所包含的封裝體。如果角色模型封裝體有埠,這些埠會定義封裝體的「介面」。
「角色模型」的行為並未指定(未定義任何狀態機);行為必須由封裝體的子類型來定義。
-
角色實現化
「角色實現化」封裝體用來定義封裝體的行為(透過狀態機),但不定義內部結構和介面。
基本上,它會提供所有衍生性封裝體之行為的抽象定義,這些衍生性封裝體又必須定義它們自己的內部服務和介面。您可以將行為定義看成一項「設計確認」,從「角色實現化」封裝體衍生而來的 所有封裝體都必須符合它。
這些基本類型有三種有用的混合形式,它們代表基本定義的混合:
-
類型角色實現化
這類封裝體用來定義一個介面和一組封裝體的行為,但不限制衍生性封裝體的內部結構。 基本上,它是用來進一步定義介面的「角色實現化」封裝體。
-
類型化角色模型
這類封裝體用來定義一個介面和一組封裝體的結構,但不限制這些封裝體的行為。 這麼做的好處是定義介面和結構的範本,之後,衍生性封裝體便可以依照需要來特殊化它們。
-
角色模型實現化
這類封裝體用來定義封裝體的內部結構及其抽象行為,但不定義介面。 當許多封裝體雖有不同介面,但可能共用大量內部結構和行為時,便可以使用這類封裝體。
還有一種封裝體類型(類型化角色模型實現化)用來定義結構和介面以及抽象(介面)和特定(內部結構)行為,它比較複雜,很難瞭解,更何況是正確實作。提到它是因為有時需要將封裝體的 單元測試定義在封裝體本身中,因而也包括兩個獨立的狀態機。
在大部分情況下,最好避免這個建構。
請注意,目前的封裝體 RUP 表示法是以 UML 1.5 表示法為基礎。在 UML 2.0 中,其中有許多可用概念:結構化類別來表示。
請參閱 UML 1.x 和 UML 2.0 之間的差異,以取得詳細資訊。
|