子系統的外部行為主要是由它所實現的介面來定義。當子系統實現介面時,它會確定支援介面所支援的每項作業。這個作業則由子系統所包含之設計元素(也就是 設計類別或 設計子系統)的作業來實現;這項作業可能需要與其他設計元素協同作業。
您應該利用顯示如何實現子系統行為的序列圖來產生子系統內模型元素之協同作業的文件。子系統所實現之介面的每項作業都應該有一或多個產生文件的序列圖。這個圖是子系統所擁有的,用來設計子系統的內部行為。
如果子系統的行為非常依賴狀態,且代表一或多個控制緒,在說明子系統的行為時,狀態機通常比較有用。這個環境的狀態機通常會結合主動類別,用來代表系統(這裡是子系統)控制緒的分解,這些狀態機是用狀態圖來說明,請參閱準則:狀態圖。在即時系統中,工作成果:封裝體的行為也是利用狀態機來說明。在子系統內,可能會有主動類別所代表的獨立執行緒。
在即時系統中,會利用工作成果:封裝體來封裝這些執行緒。
範例:
子系統執行某些系統必要行為的協同作業可以用序列圖來表示:
這個圖顯示如何利用子系統的介面來執行情境。明確地說,對於網路處理子系統而言,我們會看到子系統必須支援的特定介面(這裡是 ICoordinator)和作業。另外,我們也會看到 NetworkHandling 子系統會相依於
IBHandler 和 IAHandler 介面。
查看子系統內部,我們會看到 ICoordinator 介面的實現方式:
Coordinator 類別扮演 ICoordinator 介面的 "Proxy" 角色,它會處理介面的作業及協調介面的行為。
這個「內部」序列圖確切顯示哪些類別提供介面、內部必須發生什麼才能提供子系統的功能,以及哪些類別會從子系統中送出訊息。這個圖闡明內部的設計,對於含複雜內部設計的子系統而言,非常重要。另外,它也使子系統行為更容易被瞭解,使它成為可跨越不同環境來重複使用。
建立這些「介面實現化」圖之後,可能需要建立新的類別和子系統來執行必要的行為。這個流程類似於使用案例分析中所定義的流程,但我們是在處理介面作業,而不是使用案例。請針對每一項介面作業來識別現行子系統內必須用來執行作業的類別(在某些情況下,當所需行為很複雜時,也可能是內含的子系統)。當現有的類別/子系統無法提供必要的行為時,請建立新的類別/子系統(但要先嘗試重複使用)。
建立新的設計元素時,應該強制重新考量子系統的內容和界限。請小心避免在兩個不同的子系統中,有效使用相同的類別。這類類別的存在,隱含了子系統界限畫得不好。請定期重訪作業:識別設計元素來重新平衡子系統的責任。
建立兩個分開的內部子系統模型,將規格鎖定子系統的用戶端,將實現化鎖定實作者,有時會很有幫助。規格可包括「理想」的類別和協同作業,以便透過理想的類別和協同作業來描述子系統的行為。另一方面,實現化則更密切對應於實作,也許會發展成實作。如需設計子系統規格和實現化的相關資訊,請參閱工作成果準則:設計子系統、子系統規格和實現化。
|