上接:UML中图出现顺序
上回讲到用例图,UML中各个图之间的关系.接着根据UML建模中图出现的顺序来总结包图.
用例图确定以后.用户的需求基本上就确定了.接下来要根据用户的要求去设计系统.建模的顺序是由大到小.逐层解析.首先确定的就是系统的整体构架.系统的整体构架基本上就是包图.
包图的解释:
当然包图有非常官方的解释.但是那些解释都是比较抽象的.这里我都是用自己的语言来叙述包图的意义.
在UML中,包图看起来很像是一个文件夹.其实个人感觉包图就是一个文件夹.它是UML中的专用文件夹.用来把一些相似的物件放到一起.这个就是包图.
个人认为大家完全不必要拘泥于形式.大可以灵活的使用包图.只要为了让我们的建模看起来更简单.更有层次感就好.
一般来说用到包图的有两个地方.用例包 类包.顾名思义.
用例包:是把一些相似的用例放到一起,这个当然你可以从多个角度给他分类.比如角色,功能等.
类包:当然是把一组的类放到一起.也可以说是联系紧密的类.这个其实是我们经常用到的.我们用它来把系统的架构划分出来.把不同作用的类放到不同的包中.把系统分层处理.每个包代表一层或者一个独立的模块.
说到这里,不能不说经典的三层架构中的包图.一般的mis系统.把不同的层放到不同的包中.这样让读者很容易看明白你系统的框架.
比如:
其中的UI BLL DAL 分别是三层架构中的用户界面层 商业逻辑层 数据处理层
Entity表示实体类. 这样对应以后,我们很容易看清楚系统的框架.根据每个包进行设计.减少了模块之间的耦合性.
PS:
1:包应该连贯
��你插入包中的任何东西都应该有意义，都需要考虑包中的其余内容。为了确定一个包是否连贯，一个好的经验法则是你是否能够用一个短的，描述性的名称为包命名。 如果你做不到这一点，你或许就已经把几个不相关的事务放到包中了。
2: 避免包间的循环依赖
��包A依赖于包B，包B依赖于包C，而包C依赖于包A，这就形成了一个循环：A－B－C- A，建议尽量避免出现这种情况。因为包之间彼此紧密耦合，将来的维护和改进将变得困难。 循环依赖是一个很好的信号，意味着你需要重构一个或多个的包，把导致循环依赖的因素从包中除掉。
3: 包依赖应该反映内部关系
��当一个包依赖于另一个是，这意味着两个包的内容间存在着一个或多个的关系。 例如：如果是一个用例包图，那么就有可能两个用例之间存在includes、 extends、或继承关系，而两个用例分别处于不同的包中。
转自：http://blog.csdn.net/lsh6688/article/details/6246752