在某些情況下,物件會相依於另一物件中所發生的特定事件。如果事件是在界限或控制物件內發生,這個物件會簡單通知其他物件發生了什麼事。但如果事件在實體物件內發生,狀況就有些不同。如果沒有明確要求,實體物件可能無法通知其他物件任何事情。
範例
假設建立的系統模型能夠透過轉帳,從銀行帳戶中提款。如果嘗試的提款會使帳戶餘額成為負的,就必須立即寫下一則通知,並將它傳給客戶。模型是實體物件的帳戶與客戶是否收到通知,不應有任何關聯。相反地,這時應該由界限物件來通知客戶。
在上述範例中,界限物件必須向實體物件重複提出「發生了我在等待的事件嗎?」這個問題。為了使狀況更清楚,以及將實作細節延遲到設計階段,您可以利用訂閱關聯來表示這一點,它是一項特殊關聯。
訂閱關聯會將任何類型的物件關聯於實體物件,它表示當實體物件內發生特定事件時,關聯的起始端物件會收到通知。我們建議您只利用關聯來關聯實體物件,因為正是實體物件的被動本性造成需要關聯。另一方面,介面和控制物件都可以起始通訊。因此,它們可以利用其他方式來執行它們的責任,不需要「接受訂閱」。
訂閱關聯會將任何類型的物件關聯於實體物件。當相關聯的實體物件內發生特定事件時,關聯的起始端物件會收到通知。
請注意,關聯的方向顯示只有訂閱起始端的物件知道兩個物件之間的關係。訂閱的說明完全在訂閱起始端的物件內。相關聯的實體物件則是依照一般方式來定義,完全不考慮其他物件可能對它的作業感興趣。這也隱含了您可以在不變更所訂閱之物件的情況下,在模型中新增或移除訂閱起始端的物件。
訂閱關聯會被指派一項對應關係,指出關聯起始端的物件可以同時關聯於多少目標物件實例。之後,便說明這項關聯的一或多個條件,指出必須發生什麼,才會通知關聯起始端的物件。這個事件可能是關聯值或屬性值的改變,或是作業的評估(其中一部分)。當事件發生時,訂閱起始端的物件會收到發生狀況的通知。請注意,不會傳遞任何關於事件結果的資訊,總共只有發生事件的事實。如果在事件之後,關聯起始端的物件對實體物件的結果狀態感到興趣,它便必須依照正常方式與實體物件互動。這表示它也需要指向這個實體物件的鏈結。
範例
在倉庫系統中,必須在集裝架上進行抽樣檢查,以測量它們的生命預期。因此,集裝架每從倉庫的某個位置移到另一位置一百次時,都會在特殊測試工作站來檢查集裝架。這個模型是利用從控制類別 Pallet Spot Checker 到實體類別
Pallet 的訂閱關聯來建立的。Pallet 的每個實例都會利用計數器屬性來計算它的移動次數。當它移動了一百次時,Pallet Spot Checker 會因為訂閱關聯的條件而收到通知。之後,Pallet Spot Checker
會建立一項特殊作業來將集裝架送往測試工作站。Pallet Spot Checker 不需要任何 Pallet 鏈結,但必須有 Task 鏈結,才能起始它。
在集裝架移動了一百次之後,Pallet Spot Checker 會建立一項新的 Task。
訂閱關聯的條件應該透過抽象特性來表示,而不是透過它的特定的屬性或作業來表示。在這個方式下,關聯起始端的物件會保持與所關聯之實體物件可能變動的內容無關。
訂閱關聯不一定是建立兩個物件實例之間的關聯。從類別到實例也有效,這是一種 Meta 關係。下列各小節說明這一點。另外,訂閱關聯還有建立物件類別關聯的情況,例如,當特定事件正好是類別的實例化時,便是如此。
有時候,如果實體物件發生事件,必須通知界限物件。這會要求一項訂閱關聯。
範例
請設想透過轉帳從銀行帳戶提款的情況。這裡是 Transferal Handler 控制物件負責在實體物件 Account 上執行作業。如果 Account 的餘額變成負數,客戶會收到界限物件 Notice Writer
所準備的一項通知。因此,這個物件有一項對於 Account 的訂閱關聯。指出的條件是餘額低於零。只要發生這個事件,就會通知 Notice Writer。這個特定的訂閱關聯是一項實例關聯,因為 Notice
Writer 的實例會持續監視 Account 實例的透支情況。
如果客戶不接收餘額太低以外的任何其他資訊,這便已經足夠。 但如果客戶也應該得知低的程度,Notice Writer 就必須對 Account 執行一項 作業來瞭解確切的金額。為了做到這一點,Notice Writer
必須有通往 Account 的鏈結。
界限類別 Notice Writer 訂閱在實體物件 Account 中餘額低於特定層次的事件。如果 Notice Writer 也需要知道確實的赤字總計,它必須有通往 Account 的鏈結。
當實體物件中的事件造成向使用者顯示新的視窗時,便是起始於界限類別的 Meta 關聯範例。之後,介面物件類別再訂閱實體物件的實例。
範例
在處理網路的系統中,有些工作站的功能會如同網路中的節點,在這些工作站之間,會有交互連接的線條。每個工作站都是透過許多線條來連接到其他工作站。工作站的容量取決於它有多少能夠運作的線條。如果超出 80%
都能夠運作,工作站便有高的容量,如果低於 20% 能夠運作,工作站便有低的容量,在 20% 和 80% 之間是中等。在我們的系統模型中,我們有 Station 和 Line 這兩個實體物件,其中 Station 有指向 Line
的訂閱關聯。關聯的條件是,當 Line 的狀態有了改變(可能是啟用或停用),Station 應該收到通知。
另外,如果工作站的容量變低,訂閱 Station 的控制物件也會收到通知。以下是繼續這個範例的說明。
在 Line 其中一個實例的狀態有了改變之後,Station 實例會立刻收到通知。
實體類別之間的訂閱關聯幾乎一律是實例關聯,因為所涉及者通常是已存在的實例。不過,有時在相關聯的實體物件中發生指定的事件時,會建立訂閱起始端之實體物件的實例。在這種情況下,關聯便是從類別到實例,也就是說,它是一個 Meta
關聯。另外,您也可以想像到,當某實體物件建立了新實例時,特定實體物件的實例可能會想要知道。
範例
在上述範例中,實體物件 Station 與實體物件 Line 有一項訂閱關聯。因此,每次變更 Line 實例的狀態時,Station 都會收到通知。這類狀態變更會改變 Station 的容量。如果容量變低,也就是說,低於
20% 的線路能夠運作,系統便必須透過網路來找到適當的新路徑來避開這個工作站。當然,這並不是 Station 的作業,而是必須由控制物件 Station Supervisor 來執行,它有指向 Station 各個物件實例的訂閱關聯。
控制物件 Station Supervisor 訂閱實體物件 Station,實體物件 Station 又訂閱實體物件 Line。
起始於控制物件的訂閱關聯往往都是從類別到實例的訂閱關聯,也就是說,這是一項 Meta
關聯,反之亦然。處理實體物件中之事件的控制物件實例,通常都是等到事件實際發生時才建立。但您也可以想像到,例如,當特定實體物件建立了新實例時,控制物件的實例可能會想要知道。因此,在少數情況下,訂閱關聯也可能是一項實例關聯。
範例
在上述範例中,從 Station Supervisor 到 Station 的訂閱關聯有 Meta 關聯的特性,也就是說,當 Station 容量降低時,是 Station Supervisor 類別收到通知。當
Station Supervisor 收到這個訊息時,它會建立一個處理事件的實例。
|