北京軟件公司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測量確定了較易發生變化的課程，但并沒有確定那些較容易受到漣漪效應變化的課程。