UML包图理解

        用例图确定以后，用户的需求基本上就确定了，接下来要根据用户的要求去设计系统。建模的顺序是由大到小、逐层解析。首先确定的就是系统的整体构架，系统的整体构架基本上就是包图。
包图的解释:
       当然包图有非常官方的解释，但是那些解释都是比较抽象的。这里我都是用自己的语言来叙述包图的意义。在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或继承关系，而两个用例分别处于不同的包中。