大系統提供特殊挑戰。為大型系統繪製班級模型，而且它太大而難以理解。類之間有太多的聯繫要理解。您可以將圖表分成幾個頁面，但儘管這使得查看圖表變得更加容易，但底層軟件可能會有很多鏈接，導致代碼難以理解和易碎。
處理這個問題的一個有用的技術是UML的包：它基於Booch的類類。在這種技術中，每個類都被放入一個包中。如果一個班級希望在同一個班級中使用另一個班級，一切都很好。如果一個類想要在一個不同的包中使用一個類，它就必須為該包提供一個依賴（由Booch稱為可見性）。系統的總體情況是包和它們依賴關係的圖片，目的是將依賴關係降到最低。
在一個包中，類可以是公共的或私有的。公共類被具有可見性的包所看到，私有類只能被相同包中的類使用。軟件包可以全球化，在這種情況下，所有其他軟件包都可以看到它們。對於諸如整數，字符串和集合等常規組件，這是必需的。
這種方法的一個重要組成部分是依賴關係不是傳遞性的。我的意思是，如果投資組合UI對投資組合應用程序有依賴性，而投資組合應用程序對位置有依賴性，則投資組合UI可以在職位中使用類。事實上，這個系統的全部重點都是一個分層架構，其中投資組合應用程序將組件用戶界面中的職位隱藏起來。
這種傳遞性的缺乏很重要，它是包依賴性與C ++包含的重要區別，也是Smalltalk Envy的先決條件。編譯先決條件必須是可傳遞的，但良好的包體系結構使用分層。程序包依賴性與Java的包和導入語句（不是傳遞性的）相同。它比Java更強大，因為如果在沒有導入語句的情況下使用類，則存在依賴關係。
使用這種方案，包的接口是域中所有公共類型的接口的聯合。這可能是因為這個界面太寬泛了。也可能是不同的客戶端軟件包需要不同的接口。在這兩種情況下[Wirfs-Brock]的合同概念都是有用的。合同本質上是一個已發布的軟件包界面。合同列出了可用的功能。每個功能都由包內的類實現。一個包可能有多個合同。
何時使用它們
包是任何大型系統的重要技術。對於小型系統，無需使用它們就可以很好地管理。對於Smalltalk來說，它們並不重要，它是一個動態環境，其中包含快速查找方法級別依賴關係的工具。
UML和[Booch]都不將包圖視為一種單獨的技術，而是將它們視為類圖中的圖標。我更願意將它們作為單獨的技術來處理，但通過在同一圖上顯示類和包來組合它們通常很有用。
哪裡可以找到更多
所有這些技術都是最少討論的方法之一。 [Booch]是最受關注的人，但他對他的技術的描述令人沮喪。對於這種方法的最佳描述是[Martin]給出的 ，他在書中的大型示例中包含了幾個使用包的例子（在Booch的舊類名稱下）。[Fowler]也討論了使用這種技術的幾種模式。
尋找在線uml編輯器？ 點擊打開並立即編輯
- What is UML?
- Why UML Modeling?
- Overview of the 14 UML Diagram Types
- What is Class Diagram?
- What is Component Diagram?
- What is Deployment Diagram?
- What is Object Diagram?
- What is Package Diagram?
