01

引 言

數據耦合和控制耦合是復雜軟件設計中常見的一種情況。DO-178C要求高安全等級軟件( DAL A/ B /C) 的測試覆蓋分析，必須要確認基于需求的測試執行了代碼組件之間的數據耦合和控制耦合。如果控制耦合未被正確分析，可能會導致系統在某些情況下做出錯誤的決策。因此當測試覆蓋率未滿足要求時，還要給出相關的解決方案。

02

定 義

從DO-178C中得到數據耦合與控制耦合的定義。

數據耦合：The dependence of a software component on data not exclusively under the control of that software component.某個軟件組件對該軟件組件控制下的非獨占數據的依賴性。

控制耦合：The manner or degree by which one software component influences the execution of another software component. 某個軟件組件對其它軟件組件的執行所產生的影響方式或程度。

其中component的定義如下：

Component：A self contained part,combination of parts,subassemblies,or units that perform a distinct function of a system. 系統中能執行明確功能的獨立部件、部件的組合、子組件或單元。

一般來說，Component可被解釋為：過程、函數、子程序、模塊和其他類似的編程構造。

具體目標在DO-178及其補充文件的目標矩陣表A-7中有詳細的條目說明，完整表格參見附錄A。

6.4.4.d：Test coverage of software structure, both data coupling and control coupling, is achieved. 軟件結構測試覆蓋的實現應該包含數據耦合和控制耦合。

在6.4.4.2.c中有著如下進一步的定義。

6.4.4.2.c：Analysis to confirm that the requirements-based testing has exercised the data and control coupling between code components. 分析以確認基于需求的測試已經實現了代碼組件之間的數據和控制耦合。

DO-178B和DO-178C標準中的示例主要說明了：代碼組件之間的數據和控制耦合的結構覆蓋率分析應通過評估基于需求的測試結果來實現（見6.4.4.2.c）。但這些定義并沒有清晰地確定要進行的實際檢查。在一般情況下，它們針對的是其他覆蓋技術無法檢測到的故障。在接下來的討論中，將詳細探討這些概念，以制定實現這些目標的實用技術。但是能夠清晰得知的是，航空機載軟件是需要針對數據耦合與控制耦合進行靜態的分析，以及基于需求的測試覆蓋。

03

實例解析

本章結合一些具體例子進行控制耦合與數據定義的詳細說明。

3.1 控制耦合

例子1

以下具有三個文件的模型，每個文件中至少有一個對函數foo的調用。然而，其中兩個文件包含函數foo的定義。這兩個定義可以相同或可能相似（相同的接口）。

圖1 文件及其定義示意圖

鏈接器可以選擇解析對文件A中的函數定義的所有調用（情況1），也可以對文件A中對其包含的定義的調用、文件B中對其包含的定義的引用和文件C中的調用中的任何一個進行解析（情況2）。這是一個控制耦合缺陷的例子，因為這導致了定義的模糊性。

例子2

第二個例子是參數的控制耦合。一個具有函數指針參數的函數foo，即可以通過foo的參數列表傳遞另一個函數的名稱（地址）。

圖2 例子2代碼展示圖

對于這段示例代碼來說，通過下方兩個用例可以實現代碼動態執行的完全語句覆蓋。

圖3 例子2代碼全覆蓋用例圖

可能有兩個函數（func1與func2）在調用，而對于上述兩個數據集，每個只調用一個函數，在用例1調用func1，在用例2調用func2。控制耦合要求在每個用例執行所有潛在的調用。為了確保執行所有控制流調用，基于需求的測試數據因此需要包括兩個額外的數據集。這個概念可以應用于使用指向函數的指針的所有情況。如果通過指針解引用調用函數，則必須執行所有可以調用的潛在函數。同樣，在C++等面向對象程序中，所有可以在特定調用的虛函數都必須要有基于需求的測試數據執行。

3.2數據耦合

數據耦合完全取決于整個系統或子系統的控制流圖結構。

例子1

如下圖所示為官方文檔給出的一個數據耦合的例子。

圖4 數據耦合示例圖

如上圖所示Calculate Air Speed和Display Air Speed兩個函數都是從同一個主程序調用的，并且共享一個全局變量“AirSpeed”。Calculate Air Speed計算變量“速度”的值，即設定操作，而功能Display Air Speed“速度”值輸出到顯示設備，即使用操作。代碼可能采用下圖所示的形式。

圖5 數據耦合代碼1展示圖

可以構建一個執行Display Air Speed的測試用例，然后構建另一個執行計算空速的測試實例。在這種情況下，控制耦合按要求進行測試（即執行的每個語句和執行的每個分支/決策，在這種情況中沒有MC/DC要求），但呼叫的順序有缺陷，因為顯示空速沒有有效的顯示速度。同樣，如果一個測試用例調用Calculate Airspeed，而隨后沒有調用Display Airspeed，則很可能存在另一個缺陷。

這個例子表明，需要證明給定過程的所有輸入在調用時都有有效值，并且使用了分配給全局變量的所有值。在這種情況下，全局變量可以看做在使用過程中外部聲明和設置的變量。

例子2

如下所示，這個函數多次使用了變量x。

圖6 數據耦合代碼2展示圖

主函數同樣多次調用了foo函數。

圖7 數據耦合代碼3展示圖

運行main函數，由于循環通過參數y調用foo可以讓foo中的每條語句都被執行，此外還有每個分支/決策。然而使用參數z調用foo單個用例無法達到語句與分支/決策的全覆蓋，因此需要多個測試用例來保證在z的值改變的情況下，foo函數的語句會被全部覆蓋。根據上述的分析，主函數main與函數foo含有數據耦合，它們通過調用參數y與z，形參x而產生了耦合。

04

耦合度啟示

在這個紛繁復雜的世界中，耦合度分析的核心思想——系統思維、關注隱藏依賴、預防優于修復、優化資源分配以及透明性和可追溯性——不僅適用于軟件開發和航空安全領域，還能為生產工作和生活帶來深刻的啟示。

1. 系統思維的重要性

耦合度分析強調從整體出發，理解各部分之間的相互關系。在生產中，這意味著要關注生產流程的全局，而不僅僅是單個環節。例如，工廠中每個車間的工作并非孤立存在，它們通過物料流轉、信息傳遞等方式緊密相連。只有從系統層面優化這些耦合關系，才能真正提升效率。

2. 關注隱藏的依賴關系

耦合度分析提醒我們關注那些不明顯但可能引發問題的隱藏依賴關系。在生產工作中，團隊成員之間可能因職責劃分不清而產生隱性依賴，例如某個部門的工作進度可能依賴于另一個部門的數據輸出，但這種依賴并未明確說明。提前識別這些潛在問題，可以避免項目延誤。

3. 預防優于修復

耦合度分析的核心是通過提前分析和測試，發現潛在問題，避免問題在后期放大。這種“預防優于修復”的理念在生產中體現為定期設備維護和流程優化，減少因設備故障或流程問題導致的生產中斷。

4. 優化資源分配

耦合度分析可以幫助識別系統中的關鍵耦合點，從而優化資源分配，提高系統整體性能。在生產中，通過分析各部門之間的耦合關系，可以合理分配人力、物力資源，避免資源浪費。例如，優化供應鏈管理可以減少庫存成本，同時提高響應速度。

5. 透明性和可追溯性

耦合度分析要求對系統中的耦合關系進行詳細記錄和分析，這種透明性和可追溯性有助于快速定位問題和優化系統。在生產中，通過記錄生產流程中的各個環節及其耦合關系，可以快速追溯質量問題的根源，從而采取有效的改進措施。

05

耦合度應用

隨著科技發展與技術創新，近年來軌交、汽車、航空航天等領域的發展非常迅猛，伴隨而來的是各類安全問題。以上領域涉及的安全關鍵軟件的質量與效率都受到了高度重視。因此，高可信嵌入式軟件建模開發工具SmartRocket Modeler應運而生，誕生自質量，扎根于安全。通過模型語言的圖形化建模、模型靜態檢查、仿真與調試與C代碼生成等等功能為用戶提供一套基于模型的高安全性嵌入式軟件解決方案。在更進一步的前提下逐漸替代相關國外軟件，為解決卡脖子難題做出貢獻。

圖8 SmartRocket Modeler主頁圖

在耦合度分析理論的基礎上，上海控安SmartRocket Modeler團隊，通過充分的調研與實踐，實現了該功能的具體落地。

工程師根據上層需求，通過可視化建模方法得到其設計模型，其設計模型能夠通過圖形化或者代碼字符串的方式進行展示，如下圖所示為示例項目Roll Control的圖形化界面。

圖9 SmartRocket Modeler設計模型圖形化展示界面

Modeler使用同步數據流語言Lustre代碼進行設計模型的一致性描述，Lustre是一種經過嚴格形式化驗證的設計模型語言，它能夠充分描述機載軟件在固定時鐘下的運行情況，其示例 lustre 代碼如下所示。

圖10 RollControl飛機控制模塊Lustre代碼示意圖

Modeler通過針對設計模型的分析給出其控制耦合與數據耦合的結果，并通過圖形化與表格的多維度展示，為用戶確認模型預期性提供便捷。

圖11 SmartRocket Modeler耦合度分析圖

Modeler通過耦合分析圖來展示方法或函數間的控制的耦合，如圖11所示。圖中的點與邊分別代表著函數與函數間的調用關系，正如第三章控制耦合的示例中從起點函數出發，存在多個調用的關系，也存在不同函數共同調用統一函數的關系。通過圖的表現形式，生動展示了設計中的控制耦合關系。在其中，入度為零的點為全局變量和輸入變量，出度為零的點為輸出變量。該圖可以便于用戶快速定位搭建的模型與原始需求是否相一致。

圖12 SmartRocket Modeler全局變量使用情況展示圖

圖12中的信息將函數調用關系以表格的形式進行了展示，該表中另外對實際調用過程中傳遞的參數進行映射，該表不僅展示了調用關系（控制耦合），更進一步包含了調用的參數及其類型（數據耦合），便于用戶根據表格和需求進行比對。

圖 13 SmartRocket Modeler全局變量使用情況展示圖

此外Modeler還支持對全局變量的使用情況進行統計與展示，全局常量與傳感器等變量在模塊間進行著數據傳輸，如下圖所示。此表目的用于方便用戶映射需求的數據字典對應的全局變量使用情況是否符合用戶預期。

Modeler 工具通過對系統中各個組件間的依賴關系進行深度分析，實現了對系統耦合度的全景式展示。具體而言，它會分析變量之間的相互依賴、函數調用鏈的深層次聯系，以及函數對全局數據的依賴情況，并以直觀的圖形和層次結構展現出來。通過這種方式，設計者不僅可以清晰地看到哪些模塊之間存在緊密耦合，還能識別出那些可能導致后期維護和擴展困難的高耦合區域。Modeler 工具的多層次、分組顯示依賴關系，允許用戶根據實際需求進行過濾和聚類，從而精準定位那些與需求設計偏離的部分。在模型設計的早期階段，就能通過實時反饋機制發現潛在風險，及時調整設計策略，確保整個系統架構與業務需求保持高度一致。這樣不僅提升了系統設計的效率，也為后續的系統優化和升級奠定了堅實基礎。

參考文獻

[1] Johnson L A． Software Considerations in Airborne Systems and Equipment Certification［Z］． Document RTCA/DO 178B，1998．

[2] RTCA．DO－248C－2011，Supporting Information for DO 178C and DO－278A［S］． USA: RTCA，2011．

[3] CAST．CAST－19－2004，Clarification of Structural Coverage Analyses of Data Coupling and Control Coupling［S］． USA: CAST，2004．

[4] 孔德岐，鐘珊 ．淺談DO-178C中數據耦合與控制耦合目標的實現[J] ．航空計算技術，2018，48(5):57-60．


審核編輯 黃宇