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