? ? ? ? 用例圖確定以后，用戶的需求基本上就確定了，接下來要根據用戶的要求去設計系統。建模的順序是由大到小、逐層解析。首先確定的就是系統的整體構架，系統的整體構架基本上就是包圖。
包圖的解釋:
? ? ? ?當然包圖有非常官方的解釋，但是那些解釋都是比較抽象的。這里我都是用自己的語言來敘述包圖的意義。在UML中包圖看起來很像是一個文件夾。其實個人感覺包圖就是一個文件夾。它是UML中的專用文件夾。用來把一些相似的物件放到一起，這個就是包圖。
? ? ? ? ?個人認為大家完全不必要拘泥于形式。大可以靈活的使用包圖，只要為了讓我們的建模看起來更簡單，更有層次感就好。
? ? ? ? 一般來說用到包圖的有兩個地方：用例包、類包。
用例包:是把一些相似的用例放到一起,這個當然你可以從多個角度給他分類。比如角色、功能等。
類包:當然是把一組的類放到一起。也可以說是聯系緊密的類，這個其實是我們經常用到的。我們用它來把系統的架構劃分出來，把不同作用的類放到不同的包中，把系統分層處理，每個包代表一層或者一個獨立的模塊。
說到這里,不能不說經典的三層架構中的包圖。一般的mis系統，把不同的層放到不同的包中，這樣讓讀者很容易看明白你系統的框架。 ?比如:其中的UI BLL DAL 分別是三層架構中的用戶界面層、商業邏輯層、數據處理層。 UI---> BLL----> DAL ? ? UI(BLL、 DAL)--->Entity 。 Entity表示實體類。這樣對應以后,我們很容易看清楚系統的框架。根據每個包進行設計，減少了模塊之間的耦合性。
1、包應該連貫
? ? ? ? 你插入包中的任何東西都應該有意義，都需要考慮包中的其余內容。為了確定一個包是否連貫，一個好的經驗法則是你是否能夠用一個短的，描述性的名稱為包命名。 如果你做不到這一點，你或許就已經把幾個不相關的事務放到包中了。
2、避免包間的循環依賴
? ? ? ? 包A依賴于包B，包B依賴于包C，而包C依賴于包A，這就形成了一個循環：A-B-C-A，建議盡量避免出現這種情況。因為包之間彼此緊密耦合，將來的維護和改進將變得困難。循環依賴是一個很好的信號，意味著你需要重構一個或多個的包，把導致循環依賴的因素從包中除掉。
3、包依賴應該反映內部關系
? ? ? ? 當一個包依賴于另一個是，這意味著兩個包的內容間存在著一個或多個的關系。例如：如果是一個用例包圖，那么就有可能兩個用例之間存在includes、extends或繼承關系，而兩個用例分別處于不同的包中。

總結

以上是生活随笔為你收集整理的UML包图理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。