聊聊UML（12）实现图-构件图

Posted 2021-04-17 与小婧同行

什么是构件图

A Component can always be considered an autonomous unit within a system or subsystem. It has one or more provided and/or required Interfaces (potentially exposed via Ports), and its internals are hidden and inaccessible other than as provided by its Interfaces. Although it may be dependent on other elements in terms of Interfaces that are required, a Component is encapsulated and its dependencies are designed such that it can be treated as independently as possible. As a result, Components and subsystems can be flexibly reused and replaced by connecting (“wiring”) them together.

——《UML2.5》

在《UML2.5》中，我们看到关于构件图的三个关键词：黑盒、接口、复用。

其中的黑盒主要体现在构件的高内聚低耦合的设计上。

其中的接口是用来实现构件与构件之间的关联的。

其中的复用是从设计的意义上来说，构件最主要的目的。

构件图和我们去售楼处看到的户型图有点像。

我们大致可以看到每个屋子的位置和大小，以及门窗的位置，但是并没有办法知道具体每间屋子的内容。

构件图由很多的组件构成，组件和组件之间有关联关系的，会通过线连接（就好像房屋的门和走道），每个组件里面的结构和设计并不在组件图中进行详细描述。

而，对于BA来说，为什么要画构件图可能有不同的原因。

为什么要画构件图

对于BA来说，构件图的重要作用是可以用来帮助定义菜单模块的。

以图书馆的系统为例，比如图书管理子系统可以作为一个组件，它相对独立，可以作为一个黑盒。

借书子系统也可以作为一个组件，它也相对独立，可以作为一个黑盒。

这两个子系统通过“图书信息”这个接口进行关联。

这也是为什么我一直觉得构件图属于比较概要性的图形，关注构件和之间的接口关系。

另外，构件图也可以帮助我们理清业务关系。

当我们进行业务访谈和调研的时候，因为收集和获取的信息是零散的，再加上业务干系人在执行一些任务上可能业务职责不清晰，交织非常多很难理清的时候，可以使用构件图来帮助你找出脉络。

比如，你可以将业务部门作为构件，尝试来理解业务职责和过程。

再比如，你可以把业务角色作为构件，来尝试理解业务职责和过程。

在经历不断的分析、调整、合并、去除之后，最终可以找出一条比较清晰的脉络。

构件图还可以作为一个有效的沟通工具，具体的我放到最后来说。

构件图的组成

构件图主要由构件、接口和依赖关系组成。

构件

就是我们之前所说的卧室、厨房；图书管理子系统、借书子系统……

它的特点是高内聚。

为BA我觉得最好能思考一下每个构件的贡献是什么，也就是说这个构件主要带来的业务价值是什么，免得后期跑偏。

依赖关系

两个构件之间可能会存在一方需要另外一方提供数据的情况，那么这两个构件之间存在依赖关系。

比如，借书子系统依赖图书管理系统提供图书基本信息，图书管理系统依赖借书子系统提供借书相关信息。

连接的方式是：箭头指向方为提供信息方。

接口

一般来说，BA在画构件图的时候会将接口省略，毕竟接口涉及到了实现层的设计，应该由SA或者技术工程师来进行设计。

但是BA最好能看得懂，哦，两个构件连线中间出现了一个节点，这个就是接口了。

构件图会标明这个接口是由哪个构件提供的，由哪个构件调用了。

另外一个用途

有一次，我接到一个需求变更，要求在原有逻辑上增加一个新的校验规则。

而这个改动涉及到大概5、6个功能入口。

当我把需求规格拿给开发看的时候，开发说，这个啊，我只用改一个地方就好了。

其实构件图可以帮助我们很好的理解开发说出这句话的隐藏的涵义。

因为共通的逻辑封装在了一个黑盒里，其他的功能都在调用这个黑盒暴露的接口，这样开发只用改黑盒就好了。

所以，构件图可以帮助我们理解一些设计的逻辑，方便我们评估方案和设计方案。

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

与小婧同行

用了这么久了，