如何绘制逻辑图——要素的属性：内聚与解耦（6）

松耦合和高内聚，是决定最终完成系统是否具有应变性、复用性的重要设计原则，作为在分析和设计一线的需求工程师也必须要理解和掌握；因为在需求分析和业务设计中没有做到，那么到了后面的开发阶段再考虑就晚了。

后期仅用技术手段让系统获得同等的应变/复用能力，可能要付出很大的成本、同时系统可能也因此变得更加复杂；所以，松耦合与高内聚的设计，是从需求工程师的工作开始的。

属性4：解耦与内聚，是描述要素归集原则的重要概念。

分层与粒度说明了要素的大小；系统与模块说明了要素的归集单位。下面讨论形成系统的原则是什么。

打个比方说：将不该放到一起的要素放到了同一个盒子内，就会造成每个盒子内的要素总会受到另一个盒子内的要素牵扯，造成无法将盒子盖上盖子形成黑盒（的状态）；在黑盒与白盒一篇中讲到了，如果研究对象处于这样的状态就无法对同一层的要素进行黑盒状态的分析和研究。

那么什么样的要素可以放在一起，什么样的要素不能放在一起呢？解决这个问题需要引入解耦和内聚的概念。

一、解耦的概念

耦合：是指两个或两个以上的系统（要素的集合体）的输入与输出之间存在紧密配合与相互影响，某一方的变动会影响到另一方的变化。

解耦：指的就是解开耦合的状态，去掉两者之间造成耦合的连接关系。

耦合有两种状态：紧耦合、松耦合，举例说明两者的概念和关系。

假定某个对象的内部是由4个子系统构成的，分别为系统1、系统2、系统3、系统4。如图1所示。

图1 紧耦合与松耦合的示意

1. 紧耦合

从系统1、系统2、系统3这三者之间的关系可以看出，不同系统内部的要素之间发生了密切关联，三个系统之间两两成对地形成了非常复杂的依赖关系，三个系统因“盖不上盖子”都不能形成黑盒，这种状态就是“紧耦合”状态。

2. 松耦合

系统4与其它系统之间的关系是非常清晰、简单的，分别只有一个接口，可以看出系统4 内部的要素并不直接与其他系统中的要素直接关联，而是由统一的接口进行关联；也就是说，系统4和其它和系统之间虽然有关联，但不是复杂的依赖关系，这种由唯一或是标准关联形成的关系就是松耦合。

解耦，简单地说，就是将上述的“紧耦合”状态解开，形成“松耦合”的状态。

解耦概念说明，当分析对象内部的系统之间都是紧耦合关系时，那么各个系统就不能在“黑盒状态”下进行分析设计了；因为，各个系统都存在着系统内要素之间的依赖关系，也不可能在不考虑这些依赖关系的前提下，将各个系统看成是黑盒了。

解耦概念对后续分析与设计有着非常实际的指导意义，比如：某个产品的生产过程在企业内部大都是由多部门协同完成的，业务流程大多要跨部门才能完成；最佳的流程设计是部门之间的交互最少，最大限度地减少不同部门内部工种之间发生的直接依赖，避免由于某个部门内部某个工种的作业内容发生了变化而引起其它部门的连锁反应。

二、内聚的概念

内聚：是说明同一个系统中各个要素之间的关联性。

理想的内聚状态，如图2所示，对象中的每个系统都可以独立地完成一个业务领域的工作，且各个系统内部的要素之间关系紧密；也就是说，每个系统内所有的要素都是为了完成同一个目标而存在的；比如：对于财务系统来说，既不要把财务系统的功能划分到其他系统中，也不将其它系统中的非财务功能拉入到财务系统中来。

内聚的概念说明，各个系统内部的要素要按照“内聚”的标准放在一起，各个系统之间通过一定的接口进行相互调用，而各系统内的要素之间没有直接关联；这样在进行讨论时一个系统就可以用一个黑盒来表示。

图2 内聚概念的示意

内聚的实际意义在于，在设计时让每个系统具有的功能都相对独立、单一，这样就容易进行拆分、并通过不同的组合灵活地满足各种需求。

三、高内聚与松耦合

系统内要素间的内聚程度高就称之为“高内聚”，系统间的关联程度低就称之为“松耦合（或低耦合）”，参见图3的对比可以看出来，内聚和耦合之间的关系。

图3 高内聚与松耦合的示意

1. 高内聚

高内聚的系统内的功能要素要做到高度的相似聚合，共同为一个目标服务。图3（a）中系统1、2、3就没有做到高内聚，而是紧耦合，系统内部之间的交互非常繁杂；而图3（b）的情况就完全不同了，各个系统的内部都做到了高内聚。

2. 松耦合

在同一对象内的各个系统之间要尽量做到松耦合，系统之间具有最小的相关度，图3（a）中系统之间没有做到，对图3（b）内系统之间实现了松耦合，因此图3（b）构造看上去就非常的干净、舒服。

判断信息系统架构优劣的重要原则之一就是：系统之间是否进行了松耦合的设计，它关系到系统运行后的维护成本，而且还极大地影响到系统的扩展性、对需求变化的响应能力、甚至是系统的生命周期。

四、内聚与解耦的作用

内聚和解耦的作用，不但对于从事编码开发的工程师重要，对于从事需求分析和软件设计的工程师来说更为重要也不为过。

因为完成一个好的系统是从分析和设计开始，如果前期的分析和设计将业务都耦合在一起了，那么后续从技术架构和开发层面再怎么努力，可能也挽回不了系统整体的紧耦合状态；或是需要花费巨大的成本（时间、资源）才能收到很小的效果。

图4给出了一个企业架构的框架示意图，这个图是由不同的子系统、模块构成的，在绘制过程中注意了高内聚、松耦合的设计原则，每个子系统、或是模块都可以随着需求的变化而被替换。

图4 企业架构的框架图（不同系统的组合关系）

扩展说明：

“功能做到模块化、快速响应客户的需求变化”是软件行业一直追求的目标，不能快速地响应时代的变化的系统，随着时间的推移就失去了存在的价值。

但是很多软件工程师并不清楚达成这个目标与业务人员的相关性，不清楚业务人员对系统的模块化设计和结果起着非常重要的作用；因为这些目标的达成都需要一个非常重要前提，那就是对“业务的拆分”，首先要将研究对象拆分成为若干个小的可以独立的要素，才可能实现“将一个大的系统分解成多个小的、独立的功能/组件，然后通过它们的不同组合来处理复杂的、大型的、多变的问题”。

也就是说，业务人员能否将研究对象进行有效的拆分、并给出变化的规律性是关键；如果业务人员做不到，那么在后续的技术设计和开发时就很难做系统的模块化，更别谈让系统具有强应变能力了。

系统的模块化设计，不是从程序员开始的，是从需求工程师开始的。

五、要素属性小结

对于绘制逻辑图中的三元素之一“要素”的属性描述，使用了很多的概念（粒度/分层、黑/白盒、系统/模块、解耦/内聚），这些概念使得对逻辑图中的要素块（图标符号）有了更深入的理解，应用这些概念不但可以在逻辑图绘制过程中让图中传递的信息更加清晰、准确、简洁。

而且在分析、交流问题的过程中也有着很好实用价值，这些概念运用可以让的软件工程师的眼、脑、耳、嘴、手等器官在理解、分析和描述问题时具有了立体感、维度感和层次感。

本系列下一篇博文：如何绘制逻辑图 — 7.逻辑的表达：业务逻辑

作者：李鸿君；《大话软件工程—需求分析与软件设计》一书作者。

本文作者 @李鸿君

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！