北京软件公司Coupling因其对软件设计的贡献而备受好评。它可以对系统集成和维护成本产生重大影响。理想情况下，交互对象应尽可能松散地相互耦合。
 
Fyson和Boldyreff [1]认为，软件开发生命周期成本的高达80％通常在维护阶段消耗。在（a）预测各种软件过程成本（如系统集成）时，在维护期间测量类之间的耦合是重要的; （b）确定哪些预防性维护可能适用于在相互作用的类别的系统中的较佳效果;（c）评估变更对软件系统的影响 - 所谓的影响分析[2]。
 
类之间的耦合测量提供了一种预防与影响分析相关的一些问题的方法。在联轴器确定的阶段，要做出的精确的改变通常是不知道的。然而，当已经生成了变更请求时，类之间的精确耦合的知识可以通过突出应用的区域来帮助后续的影响分析过程，如果必须修改可能导致非常显着的连锁效应。
 
本研究中测量的联轴器与聚合和关联关系有关。没有考虑继承关系。Lindvall [3]已经调查了Ericsson Radio Systems对商业C ++系统的变化的性质。他的研究结果表明，在维护阶段，“阶级和继承结构是稳定的，大体上保持不变”。这个发现与我们自己的研究结果一致[4]，例如，Chidamber和Kemerer [5]的继承深度（DIT）和儿童数量（NOC）度量分别只改变了两个和四个班，的114套，对于这里研究的应用，超过了2 1/2年的维护期。
 
测量内部系统耦合可以通过多种方式实现[6]。目前尚不清楚哪些方法可以提供较佳的诊断能力。据推测，较详细的耦合措施将是较好的，但是基本的Chidamber和Kemerer [5]耦合度量CBO的改进是否有任何小的改进？
 
耦合的较基本的测量方法是简单地计算给定类具有链接的其他类的数量。如果CAR 存储在 GARAGE中并由 PERSON 拥有，则假设CAR，PERSON和GARAGE是三个类，CAR将具有2的耦合值。通过此措施，了解哪些类在系统中较耦合做成
 
关于协会的方向存在一个问题：只应该将双向关联计算在内或单方向关联？这个约束在后面的论文中被删除，所以从一个类到另一个类的任何链接构成一个耦合，而不管耦合类中是否存在相互引用。在本文中，我们通过单独测量前向和后向关联来明确地考虑关联的方向。
 
Briand等人 [6]建议两类之间的耦合强度可以从两个方面确定：类之间的连接频率和类之间的连接类型。接下来，对耦合的更彻底的处理可能包括对从一类对象传递到所有与之相连的对象的不同消息的数量的分析。Li和Henry [9]的消息传递耦合（MPC）度量解决了这个问题，参考文献中提出的CCF度量也是如此。[4]并在此使用。
 
在这方面，我们还可以计算每个类别中给出的消息通过次数。在关联使用方面的进一步分析要求我们从静态到动态分析 - 为给定的执行场景测量每个消息通过的使用频率。为此，已经提出了几种动态耦合度量[10]。这些指标是测量对象耦合而不是类级耦合[11]，超出了本文的范围。
 
返回到静态耦合度量，进一步细化考虑了消息传递中涉及的参数的数量和性质（无论是只读还是读写）。在C ++的情况下，如果调用“friend”函数，则会出现耦合中增加的复杂性。
 
总结了可以测量的逐渐更详细的耦合处理。因此，可以将多个级别的细化和细节添加到耦合度量。问题是：需要什么级别的细化来使耦合度量具有足够的有用的预测软件维护特性？在本文的上下文中，北京软件公司调查了在维修期为2 1/2年的应用程序变更引起的商业C ++应用程序中的波动效应。在参考文献。[12]，使用了Chidamber和Kemerer CBO度量的基本实现，仅使用类连接计数。该文件的结论是，虽然CBO测量确定了较易发生变化的课程，但并没有确定那些较容易受到涟漪效应变化的课程。