聊聊UML静态图-包图

Posted 2021-04-17 与小婧同行

包是一种容器，如同文件夹一样，它将某些信息分类，形成逻辑单元。

使用包的目的是为了整合复杂的信息，某些语义上相关或者某方面具有共同点的信息都可以分包。

包可以容纳任何的UML元素。

例如：用例、业务实体、类图等，也包括子包。

包的关系

合并 merge

表示为一条虚线+单向空心箭头+书名号包含的merge字样, 箭头指向被合并的包。

包合并定义了一个包的内容是如何被另一个包扩展的关系(包合并定义了源包元素与目标包同名元素之间的泛化关系)。

导入(引入) import/access

表示为一条虚线+单向空心箭头+书名号包含的import/access字样, 箭头指向被合并的包。

包导入是一种允许采用非限定性名称访问来自于另一个命名空间中的元素的关系。

嵌套 nesting

表示为一条实线+带十字线的实心圆, 圆远离被合并的包。

源包和目标包间的嵌套连接符说明目标包完全包含源包。

好包的原则

UML认为好的包具有高内聚、低耦合的性质。

1.高内聚

所谓高内聚就是指同一个包内的元素目标是高度一致的。

比如将所有支付相关的用例或者类放在一个包里。

将用户相关的用例或者类放在另外一个包里。

2.低耦合

所谓低耦合就是指包和包之间关联性比较低。

我们讲面向对象，一切皆对象。

对象与对象之间有各种关系，包括包与包之间也有上面提及的关系。

但是我们要保证这种关系不是强关联的。

比如，你必须要先维护基础数据，才能运行业务流程。

那么这两者之间就不是低耦合了。

我们在敏捷的过程中，也会要求user story要尽可能的高内聚低耦合，否则在评估和实现上就会产生复杂的关系。

但是如果说两个story之间不可避免的有依赖关系，那也需要注意下面的两点。

3.依赖关系不传递

所谓依赖关系传递就是，A依赖B，B 又依赖C。

这样的关系会导致设计变得复杂，牵一发动全身。

就好像很早以前刚接触user story的task拆分的时候，总会拆分成前台任务和后台任务，后台任务还包括数据库设计和业务逻辑规则设计。

但是换个角度进行拆分其实是可以避免这个问题的。

比如新增用户模块，不要拆分成：前台设计，数据库设计和保存逻辑。

而拆分成：基本信息新增，其他信息新增。

这样的角度就会避免高耦合以及依赖关系的传递。

4.依赖关系单向、不循环

所谓依赖关系循环是指，A与B相互依赖。

就好像人体必不可少的细菌一样。

没有细菌，我们的消化、代谢等系统都会出现问题。

没有人体，一些细菌也无法存活。

在面向对象的世界里，这样的循环依赖关系是需要避免的。

以上这些都需要设计人员在进行设计的时候铭记于心。

正如我之前所言，换个角度就能尽量的避免一些问题。

常用版型

具《Thinking in UML》介绍，包图也有一些常用版型。

领域包

用于分类业务领域内的业务单元，每个包代表业务的一个领域。

领域包视图可以用来展示这些业务领域的高层级关系。

子系统

用于分类系统内的逻辑对象，并形成子系统。

组织结构

用于分类业务领域中的组织结构，可以直接用来表述企业的组织结构。

层

用于分类软件中的层次，展示软件的架构信息。

包图其实还是比较简单的，根据高内聚低耦合的要求把对象放到不同的“文件夹”中，然后标注一下关联即可。

对于产品和BA来说，使用包图的机会其实并不是很多。

好吧，可能是我使用的比较少，我更多情况下会使用构件图去建立各个分系统之间的关系。

这可能和每个人的使用习惯，还有角色有关系。

对于SA和开发人员来说，包还是比较常用的。

小婧是一名行走在实践路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！