標籤: 暫無標籤

子系統是一種模型元素,它具有包(其中可包含其他模型元素)和類(其具有行為)的語義。子系統的行為由它所包含的類或其他子系統提供。子系統實現一個或多個介面,這些介面定義子系統可以執行的行為。

子系統是一種模型元素,它具有包(其中可包含其他模型元素)和類(其具有行為)的語義。子系統的行為由它所包含的類或其他子系統提供。子系統實現一個或多個介面,這些介面定義子系統可以執行的行為。

子系統的使用

可以通過多種互補的方法來使用子系統,將系統分為若干個單元,這些單元:

可以獨立預定、配置或交付
可以獨立開發(只要介面保持不變)
可以在一組分散式計算節點上獨立部署
可以在不破壞系統其他部分的情況下獨立地進行更改
此外,子系統還可以:

將系統分為若干單元,以提供對關鍵資源的有限安全保護
在設計中代表現有產品或外部系統

從類協作中確定子系統

如果某個協作中的各個類只是在相互之間進行交互,並且可生成一組定義明確的結果,就應將該協作和它的類封裝在一個子系統中。

這一規則同樣適用於協作的子集。可以對協作的任何部分或全部進行封裝和簡化,這將會使設計更易於理解。

提示

 

提示

詳細說明

注意可選性如果特定的協作(或子協作)代表可選行為,則應將其封裝在一個子系統中。如果可以將某些功能刪除、升級或替換為其他功能,就應該認為這些功能是獨立的。
注意系統的用戶界面。如果用戶界面相對獨立於系統中的實體類(即二者都可以且將要獨立地變更),則應創建橫向集成的子系統:將相關的用戶界面邊界類歸入一個子系統,而將相關的實體類歸入另一個子系統。
如果用戶界面和它所顯示的實體類緊密耦合(即一方的變更會觸發另一方的變更),則應創建縱向集成的子系統:將相關的邊界類和實體類裝入共同的子系統中。
注意主角將兩個不同主角使用的功能分開,因為每個主角可能會獨立變更自己對系統的需求。
查找類與類之間的耦合和內聚耦合度或內聚度較高的類彼此協作,以提供某一組服務。將耦合度較高的類組織成子系統,沿著弱耦合的界線將類分開。在某些情況下,可以將類分成更小的類,使其具有內聚度更高的職責,從而完全消除弱耦合。
注意替換如果為某項特定功能指定了幾個服務級別(例如,高、中、低可用性),則要將每個服務級別表示成一個獨立的子系統,每個子系統都將實現同一組介面。這樣,子系統就可互相替換。
注意分佈雖然一個特定子系統可能有多個實例,每個實例都在不同的節點上執行,但不可能在各節點間拆分子系統的單個實例。如果必須在各節點間拆分子系統行為,則需要將子系統分成更小的子系統,使其具有限制更嚴格的功能。確定必須存在於每個節點上的功能,並創建一個新的子系統,使其「擁有」該功能,然後相應地在該子系統內分佈職責和相關元素。

一旦將類組織成子系統,就要相應地更新用例實現。

記錄子系統

一旦創建了子系統:供一個名稱和一段簡短說明。
如果工具支持包但不支持子系統,可以用包來記錄子系統;在此環境中應使用包構造型 «subsystem» 表示子系統。
應將原始分析類的職責轉移給新建的子系統,並使用該子系統的說明來記錄職責。

子系統和構件

構件屬於實施範疇;為了在設計中表示構件,可以將子系統用作構件的代理。

系統的每個部分都應儘可能獨立於系統的其他部分。
從理論上說,應該可以用新的部分替換系統的任何部分,但前提是新部分必須支持相同的介面。
應該可以使系統的不同部分獨立地演進,而不受系統其他部分的影響。
為此,設計子系統提供了一種在設計模型中表示構件的理想方法:它們是用來封裝許多類的行為的設計元素(就象構件封裝許多類實例的行為一樣),並且只能通過它們所實現的介面訪問它們的行為(構件就是這樣)。

代表現有產品的子系統

如果現有產品是用來導出介面(即操作,也許會導出接收)的產品,但卻隱藏了實施的所有細節,就可以在邏輯視圖中將該產品建模為子系統。您可以用子系統表示系統所使用的產品,例如:

通信軟體(中間件)。
資料庫訪問支持(RDBMS 映射支持)。
應用程序專用產品。
某些現有的產品,如類型集合和數據結構(例如,棧、列表、隊列)最好用包來表示,因為它們所展示的不僅僅是行為。既重要又有用的是包中的特定內容,而不是包本身,包不過是一個容器而已。

對於常用的實用程序(如數學庫),如果它們只導出介面,就可以將其表示成子系統,但這是否有必要或有意義,還要取決於設計人員對建模對象性質的判斷。子系統是面向對象的構造,它們不僅是分類器,還是包:子系統可以具有實例(如果設計人員作出這樣的指定)。通過 UML,也可以在作為構造型類的實用程序(該實用程序沒有實例)中建立多組全局變數和過程的模型。

當定義子系統來代表產品時,還要定義一個或多個介面來表示產品介面。

子系統依賴關係限制

子系統與包在語義上具有差異:子系統是一種通過一個或多個它所實現的介面來提供行為的包。包並不提供行為;它們只不過是用來容納提供行為的對象的容器。

之所以要使用子系統而不使用包,是因為子系統完全封裝自己的內容,只通過自己的介面提供行為。其好處在於,與包不同,只要子系統的介面保持不變,就可以完全自由地更改子系統的內容和內部行為。另外,子系統還提供了一種「可替換的設計」元素:任何兩個實現相同介面的子系統(或類,就此而論)都可以互換。

為確保子系統在模型中是可互換的元素,需要執行以下幾條規則:

子系統不應暴露自己的任何內容(即,子系統所包含的元素都不應有「公有」的可見性);子系統外部的元素都不應依賴於子系統內部特定元素的存在。
子系統只應依賴於其他模型元素的介面,因此它不直接依賴於子系統外部的任何特定模型元素。例外情況是,許多子系統共享一組類定義。在這種情況下,這些子系統將「導入」包含公共類的包中的內容。這一操作只應對位於構架低層的包執行,並且只能是為了確保必須在子系統之間傳遞的公共類定義保持一致。
以下顯示了子系統和包的依賴關係的示例:

子系統

設計模型中子系統和包的依賴關係
© 1987 - 2001 Rational Software Corporation。版權所有。

上一篇[對象]    下一篇 [光圈範圍]

相關評論

同義詞:暫無同義詞