簡介
設計包是由類、關係、用例實現、圖和其他包組成的集合；它可用於將設計模型分成更小的部分，從而建立設計模型的結構。包主要用於模型組織，並且通常用作配置管理的單元。
為了便於理解，可以將設計模型分成更小的單元。通過將設計模型元素分組，將其歸入到包和子系統中，然後顯示這些分組之間的相互關係，就可以更容易地了解模型的整體結構。請注意，設計子系統是一種特殊的包，它具有行為語義（即實現一個或多個接口）；有關詳細信息，請參見工件：設計子系統和指南：設計子系統。設計子系統具有不同於設計包的目的，後者是靜態的東西，在邏輯上類似於實施子系統。
設計特點
包內容可見性
一個包中可以包含公有類，也可以包含私有類。公有類可以與任何其他類相關聯。私有類只能與其所在包中包含的類相關聯。
包接口由包的公有類組成。包接口（公有類）隔離並實施對其他包的依賴關係。平行開發可通過這種方式得以簡化，因為您可以及早建立接口，並且開發人員只需要了解其他包接口的變化。
包分區標準
您可以出於以下原因劃分設計模型：
您可以在完成系統後將包和子系統用作訂購、配置或交付單元。
由於資源分配以及不同開發團隊的能力不同，可能要求將該項目劃分給處於不同位置的不同組。通過帶有明確定義的接口的子系統，可以在各團隊之間以有控制、有協調的方式劃分工作，從而使設計和實施能夠平行地進行。
子系統可用於按照用戶類型來建立設計模型的結構。許多變更需求都來自於用戶；子系統可確保來自特定用戶類型的變更需求只影響系統中與該用戶類型對應的部分。
在某些套用程式中，某些特定信息應該只能由少數幾個人訪問。子系統使您能夠在需要保守秘密的地方保守秘密。
如果您正在構建一個支持系統，就可以利用子系統和包向該支持系統提供一個與要支持的系統相似的結構。這樣，您就可以使兩個系統的維護實現同步。
子系統用於代表系統所使用的現有產品和服務（例如 COTS 產品和庫），正如以下幾節所述。
將邊界類打包
在將邊界類分發給各個包時，可以套用兩種不同的策略。要確定選擇哪種策略，取決於系統接口將來是否可能發生重大的變化。
如果系統接口可能被替換，或者可能經歷相當大的更改，就應將接口與設計模型的其他部分隔離開。在更改用戶界面時，只有這些包會受到影響。這種較大更改的示例是從基於行的接口轉換為基於視窗的接口。
如果主要目的是簡化較大的接口更改，就應在一個（或幾個）單獨的包中放置邊界類。
·如果不打算進行任何較大的接口更改，指導原則的就應是對系統服務進行更改，而不是對接口進行更改。然後，應該將邊界類和在功能上與它們相關的實體類及控制類放置在一起。這樣，如果特定的實體類或控制類發生變化，就很容易看出哪些邊界類受到影響。
如果要簡化對系統服務的更改，就要將邊界類和在功能上與它們相關的類打包到一起。
對於在功能上與任何實體類或控制類都不相關的必選邊界類，應將它們和屬於同一接口的邊界類放置在單獨的包中。
如果某一邊界類與一項可選服務相關，就要在單獨的子系統中將此邊界類與協同提供該服務的類歸為一組。該子系統將映射到在預定可選功能時所提供的可選構件上。
示例展示
將功能相關的類打包
應該為每一組在功能上相關的類確定一個包。在判斷兩個類是否在功能上相關時，可以套用以下幾項實用標準。這些標準按重要性遞減的順序排列：
如果一個類的行為和（或）結構的變化使得另一個類也必須相應地變化，這兩個類就在功能上相關。
示例
如果向實體類 Order 添加一項新屬性，則很有可能使控制類 Order Administrator 必須進行更新。所以，它們屬於同一個包 Order Handling。
從某個類開始（例如一個實體類），檢查從系統中將該類刪除所帶來的影響，這就有可能查明一個類與另一個類是否在功能上相關。如果在某個類刪除後出現了多餘的類，這些類就和與已刪除的類存在一定的聯繫。之所以會變得多餘，是因為該類只由已刪除的類使用，或者它完全依賴於已刪除的類。
示例
Depot Handling System 中有一個包 Order Handling，它包括兩個控制類：Order Administrator 和 Order Registrar。這兩個控制類都用於為庫房中的訂單處理服務建模。 所有的訂單屬性和關係都由實體類 Order 存儲，它只為訂單處理而存在。如果刪除該實體類，將不再需要 Order Administrator 或 Order Registrar，因為它們只有在存在 Order 時才有用。因此，實體類 Order 應該與這兩個控制類包含在同一個包中。
因為一旦從系統中刪除 Order，Order Administrator 和 Order Registrar 就會變得多餘，所以它們和 Order 屬於同一個包。
如果兩個對象進行大量的訊息互動，或者以其他複雜的方式互相通信，這兩個對象就可能在功能上相關。
示例
控制類 Task Performer 和 Transporter Interface 之間要收發大量的訊息。這也表示了它們應包含在同一個包 Task Handling 中。
如果某個邊界類的功能是顯示一個特定的實體類，它就可能在功能上與該實體類相關。
示例
Depot Handling System 中有一個邊界類 Pallet Form，它用於向用戶顯示實體類 Pallet 的實例。現在更改了該類的接口。在螢幕上，每個 Pallet 都由一個標識號來代表。如果更改了有關某個 Pallet 的信息（例如為該 Pallet 還指定了一個名稱），就可能還必須更改該邊界類。因此，Pallet Form 應包含在 Pallet 所在的同一個包中。
如果兩個類與同一個主角進行互動，或受到對同一個主角更改的影響，這兩個類就可能在功能上相關。如果這兩個類不涉及同一個主角，它們就不應存在於同一個包中。當然，如果有更加重要的原因，也可以忽略最後一條規則。
示例
在 Depot Handling System 中有一個包 Task Handling，它包含有控制類 Task Performer。這是唯一與主角 Transporter 相關的包，Transporter 是在庫房中運輸托盤的實際運輸機。此主角通過邊界類 Transporter Interface 與控制類 Task Performer 進行互動。因此，此邊界類應包含在包 Task Handling 中。
Transporter Interface 和 Task Performer 都會受到對 Transporter 主角更改的影響，所以它們屬於同一個包。
如果兩個類之間存在某些關係（關聯關係、聚合關係等），這兩個類就可能在功能上相關。當然，不能不假思索地遵從這一標準，但在其他標準都不適用時，就可以使用它。
一個類可能與創建其實例的類在功能上相關。
以下兩條標準可確定何時不應將兩個類放在同一個包中：
與不同主角相關的兩個類不應放在同一個包中。
可選類和必選類不應放在同一個包中。
評估包的內聚度
首先，一個包中的所有元素必須具有相同的可選性：在必選的包中不能有可選的模型元素。
示例
必選的實體類 Article Type 包括一項名為 restock Threshold 的屬性。但重新進貨功能在系統中是可選的。因此，Article 應分成兩個實體類，其中的可選類與必選類相關。
被視為必選的包不能依賴於任何被視為可選的包。
一般來說，單個包不能由兩個不同的主角使用。其原因是，一個主角行為的變更不應同時影響其他主角。此規則也有例外，例如對於那些構成可選服務的包。無論有多少主角在使用這種類型的包，都不應對其進行劃分。因此，如果包不是可選的，就應拆分所有由幾個主角使用的包或類。
同一個包中的所有類都必須在功能上相關。如果您遵循了“從功能上相關的類中查找包”部分中的標準，則一個包中的各個類將彼此在功能上相關。但特定的類可能會自行包含“過多”行為或包含不屬於該類的關係。在這種情況下，應該將該類的一部分移出去變成全新的類，或者併入可能屬於另一個包的其他類。
示例
一個包中控制類 A 的行為不應過多依賴於另一個包中的類 B。為了隔離 B 專有的行為，控制類 A 必須分成兩個控制類 A' 和 A"。將 B 專有的行為放在新控制類 A" 中，並將 A" 和 B 放在同一個包中。另外，新類 A" 還獲得了與初始對象 A' 的關係（如泛化關係）。
為了隔離 B 專有的行為，將缺乏同種性的控制類 A 分成兩個控制類 A' 和 A''。
說明包依賴關係
如果一個包中的類與另一個包中的類之間存在關聯關係，這兩個包就互相依賴。包依賴關係的模型是使用包之間的依賴關係來建立的。依賴關係可以幫助我們評估更改的結果：一個由許多包所依賴的包要比一個沒有包依賴的包更難於更改。
因為在對包進行說明時會發現幾種與此類似的依賴關係，這些關係必然會在工作過程中發生變化。對依賴關係的說明可以包括有關哪些類關係導致了該依賴關係的信息。由於這種信息很難得到，因此只有在該信息相關並具有一定價值時才應將其包括。
示例
在 Depot Handling System 中，從包 Order Handling 到包 Item Handling 存在依賴關係。之所以會發生這種關聯關係，是因為 Order Handling 中的實體類 Order 與另一個包中的實體類 Item Type 存在關聯關係。
包 Order Handling 依賴於 Item Handling，因為這兩個包中的兩個類之間存在關聯關係。
評估包的耦合度
包耦合有利有弊：其利在於耦合代表著復用，其弊在於耦合代表了使系統更難變更和演進的依賴關係。可以遵循以下的一般原則：
不應對包進行交叉耦合（即互相依賴），例如兩個包不應互相依賴。
在這種情況下，需要對包進行重組，刪除交叉依賴關係。
較低層中的包不應依賴於較高層中的包。包只應依賴於同一層及下一層中的包。
在這種情況下，需要對功能進行重新劃分。一種解決方案是，按照接口說明依賴關係，並在較低層中組織接口。
通常，依賴關係不應跳層，除非依賴行為在所有層之間都是共同的，另一種方法是簡化各層之間的傳遞操作調用。
包不應依賴於子系統，而應只依賴於其他包或接口。
