A software source code data coupling coverage analysis method and device

Abstract

This invention discloses a method and apparatus for software source code data coupling coverage analysis, which integrates the results of static control flow analysis and static / dynamic data flow analysis to reduce the workload of data coupling analysis. The technical solution is as follows: Perform static control flow analysis of the source code to divide it into execution components; perform static data flow analysis of the source code, taking the execution components as objects, and summarize and calculate the input and output variable tables of the execution components; perform dynamic data flow analysis of the source code to generate definition-use pairs between different execution components, and review their effectiveness in conjunction with the control flow; expand the input and output variable tables of the execution components by adding and filling in the columns for input source and output destination, forming a data coupling relationship table for the source code execution components; determine whether the source code data flow is abnormal; complete the analysis of data coupling relationships between associated execution components and the analysis of data coupling relationships between function modules, serving as reverse input for judging whether the source code data coupling conforms to the software architecture and low-level requirements, and judging its correctness.

Description

Technical Field

[0001] This invention relates to the field of software testing and verification, and specifically to a method and apparatus for software source code data coupling coverage analysis. Background Technology

[0002] As a standard for airworthiness certification of airborne software jointly recognized by the FAA and CAAC, DO-178B / C "Software Considerations in the Certification of Airborne Systems and Equipment" defines the verification objective of "completing test coverage of the software structure (data coupling and control coupling)" in its Appendix A-7.8.

[0003] A few commercial tools, such as LDRA TESTBED, VectorCast, and SA-Covalyzer, have developed corresponding data coupling analysis plugins that support data coupling analysis. However, these plugins only assist in completing parts of the data coupling and control coupling analysis. They require preprocessing of the input objects to be analyzed, i.e., simplifying the input information provided to the commercial tools based on the manually defined functional components of the software architecture; or supplementing the analysis results (output) afterward. Whether analyzing the tool's output or providing analysis results to simplify the input, currently, a large amount of manual work involving document information extraction is required, resulting in low automation and efficiency. Regardless of the commercial tool used, further customization is needed to obtain complete coupling analysis results.

[0004] To address the aforementioned issues, a software data coupling analysis scheme was developed that approximates data from both ends of the software development lifecycle (high-level requirements, source code) towards the middle (low-level requirements, software architecture), combining forward and reverse approaches. To fully implement this scheme in airborne software verification practices, it is necessary to further decompose and refine each data coupling analysis sub-process.

[0005] For the sub-process of data coupling analysis based on source code, some commercial software static analysis tools can partially support data coupling analysis functions, such as static data flow / control flow analysis and dynamic data flow methods based on source code. However, the results obtained are difficult to directly indicate compliance with airworthiness objectives. The main problems are: 1) For global variables, only whether their declaration, definition, and usage are overridden is shown, without considering whether the order of definition and usage (i.e., the definition-use pairs of global variables) meets the requirements. Therefore, it is impossible to judge the correctness of the data coupling relationship of global variables; 2) When there are many global variables and they are scattered in various program modules, the scope of global variable definition-use pairs that need to be reviewed is too large: For example, the source code of a certain engine control software is about 50,000 lines long, with 174 C files and 4,815 global variables. There are a total of 20,798 declarations, definitions, and uses in the entire program scope. Without considering the impact of control flow, there are 206,477 sets of definition-use pairs. According to engineering experience, each person can review the correctness of 100 sets of definition-use pairs per day on average. It would take about 2,065 person-days or 8.26 person-years (an average of 250 working days per year) to complete the review of the correctness of 206,477 sets of global variable definition-use pairs. Summary of the Invention

[0006] The following provides a brief overview of one or more aspects to offer a basic understanding of them. This overview is not an exhaustive summary of all conceived aspects, nor is it intended to identify key or decisive elements of all aspects, nor to define the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form to prepare for the more detailed descriptions that follow.

[0007] The purpose of this invention is to solve the above-mentioned problems and provide a software source code data coupling coverage analysis method and apparatus, which organically integrates the results of software static control flow analysis with static / dynamic data flow analysis to form a complete data coupling analysis result, thereby reducing the workload of data coupling analysis to an engineering-feasible level.

[0008] The technical solution of this invention is as follows: This invention discloses a method for software source code data coupling coverage analysis, the method comprising:

[0009] Step 1: Perform static control flow analysis on the source code and divide it into execution units;

[0010] Step 2: Perform static data flow analysis of the source code, taking the execution component as the object, and summarize and calculate the input and output variable table of the execution component;

[0011] Step 3: Perform dynamic data flow analysis of the source code to generate definition-use pairs between different execution components, and combine the validity of the definition-use pairs generated by the control flow review;

[0012] Step 4: Expand the input and output variable table of the execution unit, add and populate the input source and output destination columns in the table to form the source code execution unit data coupling relationship table;

[0013] Step 5: Check whether there is empty data in the input source and output destination of the source code execution component data coupling relationship table to determine whether there is any abnormality in the source code data flow;

[0014] Step 6: Complete the data coupling relationship analysis between related execution components and between function modules. This serves as the reverse input for judging whether the source code data coupling conforms to the software architecture and low-level requirements, and for judging its correctness.

[0015] According to an embodiment of the software source code data coupling coverage analysis method of the present invention, step 1 further includes:

[0016] Perform static control flow analysis on the source code to find all functions that are not called by other functions. These functions are referred to as Level 0 functions, forming a list of Level 0 functions. At the same time, summarize the call relationships between all functions to obtain the original function call relationship table and generate a complete Level 0 function call tree. The called functions at each level in each Level 0 function call tree constitute the execution unit named after that Level 0 function.

[0017] According to an embodiment of the software source code data coupling coverage analysis method of the present invention, step 2 further includes:

[0018] Perform static data flow analysis of the source code, taking the execution component as the object, extract the input and output variable tables of each function to form function input and output variable tables; then combine the 0-level function call tree information to indirectly generate function-based execution component input and output variable tables, thereby simplifying the formation of execution component input and output variable tables.

[0019] According to an embodiment of the software source code data coupling coverage analysis method of the present invention, step 3 further includes:

[0020] Perform dynamic data flow analysis on the source code. By organizing the data flow by source file, merge all the separate tables in the dynamic data flow analysis table into a single complete table. Simultaneously, fill all blank cells with the nearest adjacent value per column. Then, extract the definition and usage information of each data point, generating all possible definition-use pairs with the same name. From these, filter out all definition-use pairs of global variables. Next, eliminate definition-use pairs where the definition and use belong to the same module to form a definition-use pair table between functions. Then, eliminate definition-use pairs where the definition and use belong to the same execution unit, retaining only the definition-use pairs between different execution units. Finally, combine the control flow to review the validity of the retained definition-use pairs between different functions and different execution units, obtaining valid DU pairs of global variables based on functions and execution units, respectively.

[0021] According to an embodiment of the software source code data coupling coverage analysis method of the present invention, step 4 further includes:

[0022] Using the information in the global variable effective DU pair table based on the execution unit, the execution unit input and output variable table formed in step 2 is expanded, and the input source and output destination columns are added and filled to form the source code execution unit data coupling relationship table.

[0023] According to an embodiment of the software source code data coupling coverage analysis method of the present invention, step 5 further includes:

[0024] Check if there are empty data in the input source and output destination columns of the source code execution component data coupling relationship table. If so, it indicates that there is an anomaly in the source code data flow, and the source code should be further improved.

[0025] According to an embodiment of the software source code data coupling coverage analysis method of the present invention, step 6 further includes:

[0026] Referring to steps 4 and 5, expand the function input and output variable tables, add two columns for input source and output destination, identify whether there are data flow anomalies within the execution unit, complete the data coupling relationship analysis between related function modules, and generate a source code data coupling relationship table as a basis for judging whether the source code data coupling conforms to the correctness of the software architecture and low-level requirements.

[0027] This invention also discloses a software source code data coupling coverage analysis device, the device comprising:

[0028] The execution component partitioning module is used to perform static control flow analysis of the source code and partition the execution components.

[0029] The module for summarizing the input and output variable tables of the execution components is used to perform static data flow analysis of the source code. Taking the execution components as the object, it summarizes and calculates the input and output variable tables of the execution components.

[0030] The definition-use pair generation module is used to perform dynamic data flow analysis of the source code, generate definition-use pairs between different execution components, and combine the validity of the definition-use pairs generated by control flow review;

[0031] The source code execution component data coupling relationship table generation module is used to expand the input and output variable table of the execution component, add and fill the input source and output destination columns in the table to form the source code execution component data coupling relationship table.

[0032] The source code data flow anomaly detection module is used to determine whether there are any anomalies in the source code data flow by checking whether there is empty data in the input source and output destination of the source code execution component data coupling relationship table.

[0033] The data coupling relationship analysis module between related function modules is used to analyze the data coupling relationship between related execution components and between function modules. It serves as the reverse input to determine whether the data coupling of the source code conforms to the software architecture and low-level requirements, and to judge its correctness.

[0034] According to an embodiment of the software source code data coupling coverage analysis apparatus of the present invention, the execution component partitioning module is further configured as follows:

[0035] Perform static control flow analysis on the source code to find all functions that are not called by other functions. These functions are referred to as Level 0 functions, forming a list of Level 0 functions. At the same time, summarize the call relationships between all functions to obtain the original function call relationship table and generate a complete Level 0 function call tree. The called functions at each level in each Level 0 function call tree constitute the execution unit named after that Level 0 function.

[0036] According to an embodiment of the software source code data coupling coverage analysis apparatus of the present invention, the execution component input and output variable table summary module is further configured as follows:

[0037] Perform static data flow analysis of the source code, taking the execution component as the object, extract the input and output variable tables of each function to form function input and output variable tables; then combine the 0-level function call tree information to indirectly generate function-based execution component input and output variable tables, thereby simplifying the formation of execution component input and output variable tables.

[0038] According to an embodiment of the software source code data coupling coverage analysis apparatus of the present invention, the execution of inter-component definition-use is further configured to generate the module as follows:

[0039] Perform dynamic data flow analysis on the source code. By organizing the data flow by source file, merge all the separate tables in the dynamic data flow analysis table into a single complete table. Simultaneously, fill all blank cells with the nearest adjacent value per column. Then, extract the definition and usage information of each data point, generating all possible definition-use pairs with the same name. From these, filter out all definition-use pairs of global variables. Next, eliminate definition-use pairs where the definition and use belong to the same module to form a definition-use pair table between functions. Then, eliminate definition-use pairs where the definition and use belong to the same execution unit, retaining only the definition-use pairs between different execution units. Finally, combine the control flow to review the validity of the retained definition-use pairs between different functions and different execution units, obtaining valid DU pairs of global variables based on functions and execution units, respectively.

[0040] According to an embodiment of the software source code data coupling coverage analysis apparatus of the present invention, the source code execution component data coupling relationship table generation module is further configured as follows:

[0041] By utilizing the information in the global variable effective DU pair table based on the execution unit, the execution unit input and output variable table formed by the execution unit input and output variable table summary module is expanded. The input source and output destination columns in the execution unit input and output variable table are added and filled to form the source code execution unit data coupling relationship table.

[0042] According to an embodiment of the software source code data coupling coverage analysis apparatus of the present invention, the source code data flow anomaly judgment module is further configured as follows:

[0043] Check if there are empty data in the input source and output destination columns of the source code execution component data coupling relationship table. If so, it indicates that there is an anomaly in the source code data flow, and the source code should be further improved.

[0044] According to an embodiment of the software source code data coupling coverage analysis apparatus of the present invention, the data coupling relationship analysis module between correlation function modules is further configured as follows:

[0045] Referring to the source code execution component data coupling relationship table generation module and the source code data flow anomaly judgment module, the function input and output variable tables are expanded, and two columns for input source and output destination are added. This identifies whether there are data flow anomalies within the execution component, completes the data coupling relationship analysis between related function modules, and generates a source code i.e., a data coupling relationship table between functions. This serves as the basis for judging whether the source code data coupling conforms to the correctness of the software architecture and low-level requirements.

[0046] Compared with existing technologies, the present invention has the following advantages: First, the present invention performs static control flow analysis of the source code to divide the execution components; then, it performs static data flow analysis of the source code, taking the execution components as objects, and summarizes and calculates the input and output variable tables of the execution components; next, it performs dynamic data flow analysis of the source code to generate definition-use pairs between different execution components, and reviews the validity of the definition-use pairs in conjunction with the control flow; then, it expands the input and output variable tables of the execution components, adding and filling the "input source" and "output destination" columns in the tables to form a data coupling relationship table for the source code execution components; by checking whether there is empty data in the "input source" and "output destination" columns of the data coupling relationship table for the source code execution components, it determines whether there are any anomalies in the source code data flow; finally, it completes the data coupling relationship analysis between related function modules, serving as reverse input to determine whether the source code data coupling conforms to the correctness of the software architecture and low-level requirements.

[0047] In general, the features of this invention include:

[0048] (1) By utilizing the results of control coupling analysis, the set of all functions in the software is divided into a set of execution components with larger granularity and fewer numbers, which greatly reduces the workload of reviewing the large number of definition-use pairs introduced by global variables between different functions. This overcomes the limitations of existing solutions that separate control flow analysis from data flow analysis results, resulting in a large amount of review work.

[0049] (2) Completely pair the definitions and uses of global variables in the source code to form global variable "definition-use" pairs; combined with the review and analysis of the control flow, obtain effective source code data coupling relationships. Combining the traceability relationship between the source code and low-level requirements (and thus the software architecture) and high-level requirements, quantitative criteria are provided for evaluating the correctness and consistency of software source code data coupling relationships.

[0050] Compared to existing technologies, the software source code data coupling coverage analysis method of this invention can fully utilize the advantages of the high degree of formalization of the internal structure of the source code, which facilitates the automated extraction of call relationships, variable definitions, and usage using tools. It fundamentally overcomes the limitations of existing solutions that isolate variable declarations, definitions, and usage from the constraints of control flow relationships, minimizing the workload of reviewing the correctness of source code data coupling analysis results. This helps meet the airworthiness verification objective of airborne software: "Completing test coverage of the software structure (data coupling and control coupling)."

[0051] This invention also provides a feasible solution for dividing execution components based on function call relationships, then performing source code instrumentation and integration testing on these execution components, and collecting code structure coverage information during the integration testing process. If the software codebase is large, instrumenting the entire software can cause the execution time of periodic tasks and data storage space to exceed the design margin, leading to software errors. In this case, the method of dividing execution components as described in this invention can be used to instrument only a single execution component while leaving other execution components uninstrudated, allowing for batch execution of software integration testing and structure coverage analysis. Attached Figure Description

[0052] The above-described features and advantages of the present invention will be better understood after reading the following detailed description of embodiments of the present disclosure in conjunction with the accompanying drawings. In the drawings, components are not necessarily drawn to scale, and components having similar related characteristics or features may have the same or similar reference numerals.

[0053] Figure 1 A flowchart of an embodiment of the software source code data coupling coverage analysis method of the present invention is shown.

[0054] Figure 2 A schematic diagram of an embodiment of the software source code data coupling coverage analysis device of the present invention is shown. Detailed Implementation

[0055] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. It should be noted that the aspects described below with reference to the accompanying drawings and specific embodiments are merely exemplary and should not be construed as limiting the scope of protection of the present invention in any way.

[0056] Figure 1 The flowchart of an embodiment of the software source code data coupling coverage analysis method of the present invention is shown. Please refer to... Figure 1 The implementation steps of the software source code data coupling coverage analysis method in this embodiment are detailed below.

[0057] Step 1: Perform static control flow analysis of the source code to divide the execution units. In this step, find all functions that are not called by other functions (referred to as level 0 functions) to form a list of level 0 functions. At the same time, summarize the call relationships between all functions to obtain the original function call relationship table and generate a complete level 0 function call tree. The called functions in each level of the level 0 function call tree constitute the execution unit named after that level 0 function.

[0058] Step 2: Perform static data flow analysis of the source code. Taking the execution component as the object, extract the input and output variable table 2-1 of each function. Then, combine the 0-level function call tree information to indirectly generate the function-based execution component input and output variable table, thereby simplifying the formation of the execution component input and output variable table.

[0059] Step 3: Perform source code dynamic data flow analysis, merging all separate tables (organized by source file) in the dynamic data flow analysis table into a single complete table, while filling all blank tables with the nearest adjacent value per column. Then, extract the definition and usage information of each data point, generating all possible definition-use pairs (DU pairs) with the same name. From these, filter out all definition-use pairs for global variables. Next, eliminate definition-use pairs where the definition and use belong to the same module, forming a table of definition-use pairs between functions. Then, eliminate definition-use pairs where the definition and use belong to the same execution unit, retaining only definition-use pairs between different execution units. Finally, combine this with the control flow to review the validity of the retained definition-use pairs between different functions and different execution units, obtaining a table of valid DU pairs for global variables based on functions and execution units.

[0060] Step 4: Expand the execution unit input and output variable table formed in Step 2 by using the information in the global variable effective DU pair table based on the execution unit, add and fill in the input source and output destination columns to form the source code execution unit data coupling relationship table.

[0061] Step 5: Check if there are empty data in the "Input Source" and "Output Destination" columns of the source code execution component data coupling relationship table. If so, it indicates that there is an anomaly in the source code data flow, and the source code should be further improved.

[0062] Step 6: Referring to Step 4 and Step 5, expand the function input and output variable table 2-1, add the "Input Source" and "Output Destination" columns, identify whether there are data flow anomalies within the execution component, complete the data coupling relationship analysis between related function modules, and generate source code data coupling relationship table 2-5, which serves as the basis for judging whether the source code data coupling conforms to the correctness of the software architecture and low-level requirements.

[0063] The following example illustrates each processing step in the above method.

[0064] Before describing this specific example, let's first explain the input information for the global cross-index report of the source code, as follows.

[0065] a. Input file: LDRA Testbed(R)Global Cross Reference Report.gxf.txt.

[0066] b. File Description: The source code static data flow analysis cross-index report mainly includes five parts: Table of Source Files in System, Key to Variable usage and attribute codes, Procedure Reports (Procedure call Information, Variable Usage Information), Global Variable Usage Summary, and Management Summary. For LDRA version 9.8.2, the global cross-index report for source code has certain limitations. If the total number of source files to be analyzed exceeds 100, report generation will fail. Analysis needs to be performed in groups, with each group containing no more than 100 files. The "Calls the Following Procedures" section in the Procedure Reports only contains the names of the called functions, not the names of the source files to which they belong. A list of source files and function modules needs to be added to form complete information for control coupling analysis. The "Called by the Following Procedures" section only contains information on the main calling functions in the current group of source files, not information on possible main calling functions in other groups. This incomplete data makes it difficult to use as a basis for control coupling analysis. The "Variable Usage Information" section contains the declarations, definitions, and usages of all parameters and local variables of the function, as well as the definitions and usages of global variables (the declaration and initialization of global variables are file-level, not function-level, and have no impact on data coupling analysis between function modules, so they can be ignored). The "Global Variable Usage Summary" contains information on all global variable declarations (E), definitions (D), and references / usages (R). However, because long filenames (more than 10 characters) are truncated when referencing source file line numbers, the filenames are incomplete and cannot be used as a basis for data coupling analysis.To perform function interface analysis, it is necessary to focus on analyzing the Procedure Call Information (Called by the Following Procedure / CALLS NO PROCEDURES) and Variable Usage Information sections of the Procedure Reports, and to partially refer to the content of Called by the Following Procedures / IS CALLED BY NO OTHER PROCEDURES, especially the IS CALLED BY NO OTHER PROCEDURES information. If the analysis is performed on all ungrouped source program files, then this function can be regarded as the starting point of the call tree in the control coupling analysis.

[0067] c. Variable attribute code.

[0068] Table 1 Variable Attribute Codes

[0069]

[0070]

[0071] d. Editing tools: text editing tools such as Notepad.

[0072] e. Valid data start markers: "Calls the Following Procedures" and "Variable Usage Information" for each function.

[0073] f. Valid data header, taking the PROCEDURE BIT_Init(BIT.C) function as an example:

[0074] Table 2 Function Calls the Following Procedures (Information is incomplete and requires further information)

[0075] NAME Called on Line BIT_ContDiagInit 84 BIT_DisDiagInit 85 BIT_OspDiagInit 86

[0076] Table 3 shows the functions called by the Following Procedures (information may be incomplete).

[0077] NAME FILE Called on Line BIT_GetIn BIT.C 187

[0078] Table 4 Variable Usage Information

[0079]

[0080] Table 5. Summary of Global Variable Usage

[0081]

[0082]

[0083] g. Table Feature Analysis: For functions in a specified source file, such as PROCEDURE BIT_Init(BIT.C):

[0084] 1) The Calls the Following Procedures table contains information about the functions called by functions in the specified source file. The NAME column represents the name of the called function, and the CALLED ON LINE column represents the line in the source file (e.g., BIT.C) where the call occurred.

[0085] 2) The Called by the Following Procedures table contains information about the functions called in the specified source file. The NAME column represents the name of the main function being called, the CALLED ON LINE column represents the line number in the source file where the call occurs, and the FILE column represents the file name of the source file to which the main function belongs (e.g., BIT.C).

[0086] 3) The Variable Usage Information table contains information about function variables in the specified source file. The NAME column represents the variable name, the FILE column represents the source file name where the variable is located (e.g., BIT.C), and the ATTRIB column is divided into two columns: the left column represents the variable's scope (Type Code), and the right column represents the variable's usage attribute (Attribute Code). The OCCURS ON LINE column represents the line in the source file (e.g., BIT.C) where the variable is used.

[0087] h. Table Relationship Explanation: For functions in a specified source file, they are arranged sequentially according to the function call table (Calls the Following Procedures), the function called by the following procedure table (Called by the Following Procedures), and the variable usage information table (Variable Usage Information). Even if there is no valid data, placeholders are placed in the function call table (Calls the Following Procedures) and the function called by the following procedure table (Calls NOPROCEDURES) or the function called by the following procedure table (IS CALLED BY NO OTHER PROCEDURES).

[0088] i. Key Table Field Descriptions: This solution focuses on the NAME column in the Calls the Following Procedures table and the NAME and ATTRIB columns in the Variable Usage Information table. It also focuses on functions containing the "IS CALLED BY NO OTHER PROCEDURES" information, as starting functions for independently conducting control coupling and data coupling analysis.

[0089] j. Explanation of the meaning of table data:

[0090] This solution targets all functions in each source file within Procedure Reports, focusing on extracting the NAME column from the Calls the Following Procedures table to collect a list of sub-functions called by the corresponding function. It also extracts the NAME and ATTRIB columns from the Variable Usage Information table to obtain the scope and usage attribute information of function input and output interface variables, thus clarifying the function's external interfaces.

[0091] After explaining the input information for the global cross-index report of the source code, the various processes in the aforementioned embodiments will be described in turn based on this example.

[0092] First, there is an explanation of the static control flow analysis of the source code.

[0093] a. In the "Source Code Static Data Flow Analysis Cross-Index Report", search for "IS CALLED BY NO OTHERPROCEDURES" and fill in the corresponding function information in the Level 0 function list, as shown below:

[0094] Table 6 List of Level 0 Functions

[0095] Level 0 function name file name PROCEDURE BIT_Init BIT.C

[0096] b. Summarize the "Calls the Following Procedures" information for all functions in all source files into a complete function call table. Complete the table according to the following format, removing any non-critical information. The "Main Calling Function" and "File Name" information are derived from the function titles in each source file of the Procedure Reports. The called function comes from the NAME column of the function call table (Calls the Following Procedures) contained under that function. Leave the file name information blank for now. If a function does not call any other functions (CALLS NO PROCEDURES), fill its corresponding "Called Function" column with " / ", as shown below:

[0097] Table 7 Original Function Call Relationships

[0098] Main calling function file name Called function file name DMSFaultCheck_Fun DMSFAULTCHECK_FUN.C DMSFaultCheck_In_Fun DMSFAULTCHECK_FUN.C DMSFaultCheck_In_Fun DMSFAULTCHECK_IN.C UT_GetDisValue /

[0099] c. Using the level 0 function as the first-level call relationship, search for the main calling function with the same name as the level 0 function in the "Main Calling Function" column of the "Original Function Call Relationship Table". Find the function called by it and add the called function to the same row or adjacent row or column below, forming the second-level call relationship. Continue in this manner to form the third, fourth, and so on, until the called function corresponding to the main calling function found in the "Original Function Call Relationship Table" is " / ", at which point a leaf node of the call tree is reached (the leaf node may be a library function, therefore it may not exist in the original function call relationship table, and its filename is filled with " / "). The call tree table style is shown below (the relationship between adjacent levels of call relationships is the relationship between the main calling function and the called function):

[0100] Table 8 Call Tree Table

[0101]

[0102] d. Traverse the "Level 0 function list" one by one to obtain the call tree of all Level 0 functions. Each call tree represents a "software execution component" that can independently perform software integration testing, which can serve as the basis for simplifying software control coupling and data coupling analysis. That is, the software functions contained within the software execution component are regarded as a whole. Perform software integration testing to ensure that it meets the software requirement coverage and structural coverage analysis criteria, and there is no need to further analyze the data and control coupling relationships between functions within the software execution component. Therefore, software data coupling and control coupling analysis is limited to different software execution components. By performing software integration testing based on the division of software execution components, combined with the data and control coupling analysis between software execution components, the requirements of DO-178C can be met, and the workload can be controlled within an engineering-feasible range. This is especially useful for some software that uses a large number of global variables (such as the core engine control software of a certain type of engine, which has 210,000 sets of global variable "definition-use" pairs that require manual analysis; by dividing the execution components, only 81 pairs of global variable "definition-use" pairs that require manual analysis remain).

[0103] Table 9 List of Software Execution Components

[0104]

[0105]

[0106] Next is an explanation of the static data flow analysis of the source code.

[0107] a. Expand the "Variable Usage Information" table by adding a "Function Name" column. Fill in the corresponding function names from each source file in the Procedure Reports. The expanded variable usage information table format is as follows:

[0108] Table 10 Extended Variable Usage Information Table

[0109]

[0110] b. Convert the extended variable information table into function input and output variable table 2-1. Variables with an Attribute Code (variable usage attribute code) of R in the right column of ATTRIB should be placed in the input interface of "Function Input and Output Variable Table 2-1", and variables with Attribute Codes (variable usage attribute codes) of D or E should be placed in the output interface of "Function Input and Output Variable Table 2-1".

[0111] Table 11 Function Input and Output Variables Table 2-1

[0112]

[0113] c. Expand to form a "function-based execution unit input and output variable table"

[0114] Based on the "Software Execution Component List", add the "Execution Component Name" column to the "Function Input and Output Variable Table 2-1" and fill in the corresponding information to form the "Function-Based Execution Component Input and Output Variable Table".

[0115] Table 12 Input and Output Variables of Function-Based Execution Unit

[0116]

[0117] d. Simplify and form the "Input and Output Variable Table for Execution Components"

[0118] Since functions within the same execution unit may have input and output interface variables with the same name, at the execution unit level, information about the specific function to which a variable belongs can be ignored, as well as information about variable types "P" and "L". Input and output interface variables with the same name in different functions within the same unit are considered duplicate information, and only one needs to be retained. Based on the above simplification principle, the "Function Name" column is deleted from the "Function-Based Execution Unit Input and Output Variable Table". Then, only one copy of the data for global variables (variable type "G") with the same "Execution Unit" name as "Variable Name (Usage)" or "Variable Name (Definition)" is retained. The resulting "Execution Unit Input and Output Variable Table" is as follows:

[0119] Table 13 Input and Output Variables of Execution Components

[0120]

[0121] Next, an explanation of the input information for dynamic data flow analysis of the source code.

[0122] a. Input file: LDRA Dynamic Data Flow Coverage.mht

[0123] b. File Description: After compiling and running the source code based on the instrumentation, the collected dynamic data flow coverage analysis results include all source program files in the entire project. The main contents include 5 parts: List of Variable Search Criteria, Table of Source files Analyzed, Dynamic Data Flow Table, Summary Table, and Key To Terms. The third part, "Dynamic Data Flow Table", is used as the input information for source code data coupling analysis.

[0124] c. Editing tool: Microsoft Excel

[0125] d. Valid data start marker: Dynamic Data Flow Table

[0126] e. Valid data header:

[0127] Table 14 Input Information Table for Dynamic Data Stream Analysis

[0128]

[0129] f. Table Feature Analysis: Except for the "Used on lines..." field, which corresponds to a maximum of 6 columns, fields with blank spaces containing no valid data, and fields used only to confirm the validity of data coupling pairs or to identify whether the definition, use, or declaration of data is covered during software integration testing (not covered, indicated by red text followed by 5 asterisks; covered, indicated by green text), the other 6 data fields include Variable Name, Alias ​​(Call Depth / Parameter Name), File, Procedure, Type Code, and Attribute Code. Except for Alias ​​(Call Depth / Parameter Name), which corresponds to a maximum of 6 columns, fields with blank spaces containing no valid data, and fields used only to confirm the validity of data coupling pairs or to identify whether the definition, use, or declaration of data is covered during software integration testing (not covered, indicated by red text followed by 5 asterisks; covered, indicated by green text), the other 6 data fields include Variable Name, Alias ​​(Call Depth / Parameter Name), File, Procedure, Type Code, and Attribute Code. Spaces in the Name field are valid; spaces in other fields are simplified and implicitly represent the nearest non-empty data in the same column. If there is one non-empty data in the same column, it will not be repeated in subsequent rows but will be replaced by a space. That is, spaces in these columns are by default the same as the nearest non-empty data in the same column with the smaller row number (except for the header row). (During processing, the same column can be filled upwards. That is, if there is no data in a cell in any column, non-empty data is searched in the same column in the direction of decreasing row number until non-empty data is found and filled.)

[0130] g. Table relationship description: Each table has the same column headers and a variable number of rows. The content of adjacent tables is continuous and separated by a blank line.

[0131] h. Key Table Title Field Descriptions: Type Code includes five variable scope types: P (Paremeter), G (Global), L (Local), C (Constant), and LG (Local-Global). Among them, the global variable type G (Global) needs to be focused on during source code data coupling analysis. Attribute Code includes eight variable usage types: D (Definition), R (Reference), E (Declaration), I (Input), O (Output), N (Indirect Usage), U (Unused parameter), and T (Used as the C++ 'this' parameter). Among them, the definition D (Definition) and usage R (Reference) of variables with the same name need to be analyzed in pairs.

[0132] i. Explanation of the meaning of table data: The variable name specified by the name is used as the scope type (global variable, formal parameter, local variable) in the function procedure defined in the source program file File, and is used as the attribute code (definition, use, declaration) at the specified line (Used on lines...) in the file.

[0133] Next is the data coupling analysis process based on the results of dynamic data analysis of the source code.

[0134] a. Extraction of valid input information

[0135] Before conducting source code data coupling analysis, the tables separated by blank rows in the Dynamic Data Flow Table need to be merged into a single unified table. If the data volume is too large to fit in a single table, it needs to be divided into multiple tables. However, it is essential to ensure that all definitions and usage information for any variable are contained within a single table, not scattered across different tables. To facilitate independent analysis of each changed definition and usage, the blank information in the Dynamic Data Flow Table needs to be filled in completely. The specific rule is: if one or more consecutive rows of adjacent cells in the same column of a non-empty data point are empty (blank), then the non-empty data is automatically filled down the column. After filling, the example .hmt file is converted to an Excel file, and the Type Code is simplified to the corresponding single uppercase letter. An example of the content is as follows:

[0136] Table 15 Extraction of Dynamic Data Flow Analysis Results

[0137]

[0138] b. Definition and usage information of extracted valid data

[0139] Separate the definition (Attribute Code = Definition) and usage (Attribute Code = Reference) of variables with the same name into two relatively independent areas (data for other attributes is ignored and not extracted for now), with the definition and usage information listed consecutively in different fields. Alternatively, the definition and usage of variables can be placed in two separate tables: 1) Function variable "Definition" Table 2-2; 2) Function variable "Usage" Table 2-3 (Usage is referencing). The main fields of the tables are illustrated in the following two tables (where "Variable Name" is Variable Name, "Variable Type" is Type Code, and "Function Name" is Procedure):

[0140] Table 16 Function Variable "Definition" Table 2-2

[0141]

[0142] Table 17 Function Variables "Usage" Table 2-3

[0143]

[0144] c. Generate all possible "definition-use" pairs

[0145] All definitions and all uses are paired in a multiplicative permutation. The number of table rows occupied by each variable is determined by the product of the number of definitions and the number of uses, forming all possible "definition-use" pairs for variables with the same name, referred to as the "complete DU pair table".

[0146] Table 18 Complete DU Pair Table

[0147]

[0148] d. Extract the "definition-usage" pairs of global variables

[0149] Extract the "DU pair" with "Type Code = G" from the "Complete DU Pair Table" and add a "Validity" column on the far right, and initialize all of them to "Valid", to form the "Complete DU Pair Table of Global Variables Based on Software Modules".

[0150] Table 19: Complete DU Pair Table of Global Variables Based on Software Modules

[0151]

[0152] e. Automatically eliminate the "definition-usage" pairs of global variables within the module.

[0153] In the "Complete DU Pair Table of Global Variables Based on Software Modules", retrieve the "DU pairs" whose reference (R) field has the same name as the "Procedure" defined in the definition (D). Since these "DU pairs" do not belong to the data coupling between functions, modify the content of the cell containing their "Validity" column to "Invalid" and remove them from the table, keeping only the data rows where the "Validity" column is "Valid".

[0154] f. Review the validity of the "definition-use" pairs of global variables between software modules.

[0155] Because the "DU pairs" in the "Complete DU Pair Table of Global Variables Based on Software Modules" do not consider the influence of factors such as control flow, definition and usage order, etc., and only represent potential data coupling pairs between different software modules, these data couplings may be unreachable in the control flow and require further review and analysis. Therefore, the "Validity" column of the "DU pairs" that are unreachable in the control flow will be corrected to "Invalid". Then, all data with a "Validity" column is filtered out, and the "Validity" column is deleted, forming the "Valid DU Pair Table of Global Variables Based on Software Modules" (if the number of global variables used by the software is large, this review work may be time-consuming and can be simplified to the subsequent "Review the Validity of 'Definition-Use' Pairs of Global Variables Between Software Execution Components" activity), i.e., the valid "Definition-Use" pairs between function variables, Table 2-4, is shown below:

[0156] Table 20 shows the valid "definition-use" pairs of function variables between Table 2-4.

[0157] Variable "Define-Use" (DU pair) number variable Variable type Quote(R) Definition (D) Variable Name function name function name BitFault

[0158] g. Source code module data coupling analysis

[0159] Expand the module's input and output variable tables by adding an "Input Source" column to the input interface and an "Output Destination" column to the output interface. Here, "Input Source" is equivalent to "Definition" (D), and "Output Destination" is equivalent to "Reference" (R). Using valid "DU Pair" information from the "Global Variable Valid DU Pair Table Based on Software Modules," populate the "Input Source" and "Output Destination" columns to form a source code module data coupling relationship table. The accuracy of the data coupling relationship depends on whether the previous step (i.e., step e) was pruned. If not, the result is inaccurate; otherwise, the result is accurate, as shown below:

[0160] Table 21 Data Coupling Relationships of Source Code Modules (Table 2-5)

[0161]

[0162]

[0163] Next is the processing of data coupling analysis of the software execution components.

[0164] a. Obtain the "definition-usage" pairs of global variables within the software execution component.

[0165] If global variables are used in the program, a coupling analysis should be conducted to determine whether the definitions and uses of all variables with the same name across different function templates meet the requirements and design. If the number of global variables is large, their "definition-use" pairs will expand dramatically according to the multiplicative principle, potentially exceeding the acceptable workload for review in engineering. To control the workload of analyzing the "definition-use" pairs of global variables across functions to an engineering-feasible level, it is necessary to filter out the "definition-use" pairs of global variables within the execution components, retaining only the "definition-use" pairs of global variables between execution components, based on the division of execution components. The larger the granularity of the execution component, the more "definition-use" pairs of global variables are filtered out; conversely, the smaller the granularity of the execution component, the fewer "definition-use" pairs of global variables are filtered out. Therefore, in actual projects, it is necessary to select execution components with appropriate granularity. While meeting the requirements of instrumentation bloat for software runtime and space resources, the granularity of the execution components should be expanded as much as possible to minimize the number of global variable "definition-use" pairs that need to be reviewed.

[0166] To reduce the size of the "Complete Global Variable DU Pair Table" that requires review and analysis, non-critical columns were removed. Based on the "Software Execution Component List," "Execution Component" columns were added to the Reference (R) and Definition (D) information columns, and corresponding information was added. At the same time, data rows with "Invalid" in the "Validity" column were deleted, resulting in the "Complete Global Variable DU Pair Table Based on Functions and Software Execution Components," as shown below:

[0167] Table 22 Complete DU Pair Table of Global Variables Based on Functions and Software Execution Units

[0168]

[0169] b. Automatically eliminate the "definition-usage" interference of global variables within software execution components.

[0170] In the "Complete DU Pair Table of Global Variables Based on Functions and Software Execution Components", delete the File and Procedure columns in the "Reference (R)" and "Definition (D)" columns. Also, delete identical duplicate entries in the Variable Name, Reference (R) Execution Component, and Definition (D) Execution Component columns, keeping only one valid record. This yields the "Complete DU Pair Table of Global Variables Based Only on Software Execution Components", ignoring function information, as shown below:

[0171] Table 23 Complete DU Pair Table Based Only on Global Variables of Software Execution Units

[0172]

[0173] c. Review the validity of the "definition-use" pairs of global variables between software execution components.

[0174] Because the "DU pairs" in the "Complete DU Pairs Table Based on Software Execution Components Only" do not consider the influence of factors such as control flow, definition and usage order, and only represent potential data coupling pairs between different software execution components, these data couplings may be unreachable in the control flow and require further review and analysis. Therefore, the "Validity" column of the "DU pairs" that are unreachable in the control flow will be corrected to "Invalid". Then, all data with a "Validity" column of "Valid" will be filtered out, and the "Validity" column will be deleted to form the "Valid DU Pairs Table Based on Software Execution Components", as shown below:

[0175] Table 24: Effective DU Pairs for Global Variables Based on Software Execution Units

[0176] variable Quote(R) Definition (D) Variable Name Actuating components Actuating components BitFault

[0177] d. Data coupling analysis of source code execution components

[0178] Expand the input and output variable tables of the execution unit by adding an "Input Source" column for the input interface and an "Output Destination" column for the output interface. Here, "Input Source" is equivalent to "Definition" (D), and "Output Destination" is equivalent to "Reference" (R). Using information from the "Global Variable Valid DU Pair Table Based on Software Execution Units," populate the "Input Source" and "Output Destination" columns to form a source code execution unit data coupling relationship table, as shown below:

[0179] Table 25 Data Coupling Relationships of Source Code Execution Components

[0180]

[0181] The final step is to check whether the "Input Source" and "Output Destination" columns in the "Source Code Module Data Coupling Relationship Table 2-5" and the "Source Code Execution Component Data Coupling Relationship Table" are empty. If so, there is an abnormal data coupling between modules / execution components, and the defect handling process should be submitted for correction; otherwise, the data coupling between modules / execution components is normal.

[0182] Figure 2 The principle of one embodiment of the software source code data coupling coverage analysis apparatus of the present invention is illustrated. Please refer to [link to documentation]. Figure 2 The apparatus in this embodiment includes: an execution component partitioning module, an execution component input and output variable table summarization module, an execution component definition-use pair generation module, a source code execution component data coupling relationship table generation module, a source code data flow anomaly judgment module, and an association function module data coupling relationship analysis module.

[0183] The execution component partitioning module is based on static control flow analysis of the execution source code to partition the execution components.

[0184] The execution component partitioning module is further configured as follows: it performs static control flow analysis of the source code, finds all level 0 functions (referred to as level 0 functions) that are not called by other functions, forms a list of level 0 functions, summarizes the call relationships between all functions, obtains the original function call relationship table, and generates a complete level 0 function call tree. The called functions in each level of the level 0 function call tree constitute the execution component named after that level 0 function.

[0185] The Execution Component Input and Output Variable Table Summary Module is used for static data flow analysis of the execution source code. Taking the execution component as the object, it summarizes and calculates the execution component's input and output variable table.

[0186] The module for summarizing the input and output variable tables of the execution components is further configured as follows: it performs static data flow analysis of the source code, takes the execution components as objects, extracts the input and output variable tables of each function to form function input and output variable tables, and then combines the 0-level function call tree information to indirectly generate function-based execution component input and output variable tables, thereby simplifying the formation of execution component input and output variable tables.

[0187] The Execution Component Definition-Use Pair Generation Module is used to perform dynamic data flow analysis of the source code, generate definition-use pairs between different execution components, and combine the validity of the generated definition-use pairs with the control flow review.

[0188] The definition-use pair generation module is further configured as follows: Perform source code dynamic data flow analysis, merge all separated tables (organized by source file) in the dynamic data flow analysis table into a single complete table, and fill all blank cells with the nearest adjacent value per column. Then, extract the definition and usage information of each data point, generate all possible definition-use pairs with the same name, and filter out all definition-use pairs for global variables. Next, eliminate definition-use pairs where the definition and use belong to the same module, generating a table of definition-use pairs between functions. Then, eliminate definition-use pairs where the definition and use belong to the same execution unit, retaining only those between different execution units. Finally, in conjunction with control flow, review the validity of the retained definition-use pairs between different functions and different execution units, obtaining tables of valid global variable DU pairs based on functions and execution units, respectively.

[0189] The source code execution component data coupling relationship table generation module is used to expand the input and output variable tables of the execution components, add and populate the input source and output destination columns in the table, and form the source code execution component data coupling relationship table.

[0190] The source code execution component data coupling relationship table generation module is further configured to: expand the execution component input and output variable table formed by the execution component input and output variable table summary module by using the information in the global variable effective DU pair table based on the execution component, add and fill the input source and output destination columns in the execution component input and output variable table, and form the source code execution component data coupling relationship table.

[0191] The source code data flow anomaly detection module is used to determine whether there are any anomalies in the source code data flow by checking whether there is empty data in the input source and output destination of the source code execution component data coupling relationship table.

[0192] The source code data flow anomaly detection module is further configured to: check whether there is empty data in the input source and output destination columns of the source code execution component data coupling relationship table. If so, it indicates that there is an anomaly in the source code data flow and the source code should be further improved.

[0193] The data coupling relationship analysis module between related function modules is used to analyze the data coupling relationship between related function modules, serving as reverse input to determine whether the data coupling in the source code conforms to the correctness of the software architecture and low-level requirements.

[0194] The data coupling relationship analysis module between related function modules is further configured as follows: referencing the source code execution component data coupling relationship table generation module and the source code data flow anomaly judgment module, extending the function input and output variable table 2-1, supplementing the "input source and output destination" columns, identifying whether there are data flow anomalies within the execution component, completing the data coupling relationship analysis between related function modules, and forming the source code (i.e., the data coupling relationship between function modules) data coupling relationship table, which serves as the basis for judging whether the source code data coupling conforms to the correctness of the software architecture and low-level requirements.

[0195] In summary, according to the definition in DO-178C, source code refers to code written in languages ​​such as assembly language and / or high-level languages, providing input to an assembler or compiler in a machine-readable form. The implementation of source code originates from the software architecture and low-level requirements, is directly generated from these requirements, and conforms to the software architecture. Since commonly used high-level programming languages ​​define strict lexical and syntactic rules, for highly structured source code, various common static analysis tools (such as LDRA Testbed) can be used to perform static / dynamic analysis of the source code, extracting information such as variable definitions / usages and function calls, making it easy to obtain the data coupling relationships between different modules in the source code.

[0196] In source code data coupling analysis, it is crucial to focus on the direct data coupling relationships formed by the definition and use of global variables, while also paying appropriate attention to the indirect data coupling relationships formed by local variables using global variables through pointers or references. This invention, based on static control flow analysis, static data flow analysis, and dynamic data flow analysis of the source code, utilizes function call relationships to group functions, transforming all software modules into a collection of call trees. By using the call tree as the execution component and the object of source code data coupling analysis, the granularity of the data coupling analysis object is increased, reducing the workload of reviewing the correctness of the analysis results.

[0197] Although the methods described above are illustrated and depicted as a series of actions for the sake of simplicity, it should be understood and appreciated that these methods are not limited by the order of the actions, as some actions may occur in a different order and / or concurrently with other actions from the illustrations and descriptions herein or not illustrated and described herein but which may be understood by those skilled in the art, according to one or more embodiments.

[0198] Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, the various illustrative components, blocks, modules, circuits, and steps are described above in a generalized manner in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as departing from the scope of the invention.

[0199] The various illustrative logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein can be implemented or performed using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but in alternatives, it may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors cooperating with a DSP core, or any other such configuration.

[0200] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of both. The software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor such that the processor can read and write information to / from the storage medium. In an alternative, the storage medium may be integrated into the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In an alternative, the processor and storage medium may reside as discrete components in the user terminal.

[0201] In one or more exemplary embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software as a computer program product, the functionality may be stored or transmitted as one or more instructions or code on or through a computer-readable medium. A computer-readable medium includes both computer storage media and communication media, encompassing any medium that facilitates the transfer of a computer program from one location to another. A storage medium may be any available medium accessible to a computer. By way of example and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and is accessible to a computer. Any connection is also legitimately referred to as a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of a medium. As used in this article, disk and disc include compact discs (CDs), laser discs, optical discs, digital multi-purpose discs (DVDs), floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of these should also be included within the scope of computer-readable media.

[0202] The prior description of this disclosure is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not intended to be limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for analyzing data coupling in software source code, characterized in that, The methods include: Step 1: Perform static control flow analysis on the source code and divide it into execution units; Step 2: Perform static data flow analysis of the source code, taking the execution component as the object, and summarize and calculate the input and output variable table of the execution component; Step 3: Perform dynamic data flow analysis of the source code to generate definition-use pairs between different execution components, and combine the validity of the definition-use pairs generated by the control flow review; Step 4: Expand the input and output variable table of the execution unit, add and populate the input source and output destination columns in the table to form the source code execution unit data coupling relationship table; Step 5: Check whether there is empty data in the input source and output destination of the source code execution component data coupling relationship table to determine whether there is any abnormality in the source code data flow; Step 6: Complete the data coupling relationship analysis between related execution components and the data coupling relationship analysis between function modules, as the reverse input to determine whether the source code data coupling conforms to the software architecture and low-level requirements, and to determine its correctness; Step 1 further includes: Perform static control flow analysis on the source code to find all functions that are not called by other functions. These functions are referred to as Level 0 functions, forming a list of Level 0 functions. At the same time, summarize the call relationships between all functions to obtain the original function call relationship table and generate a complete Level 0 function call tree. The called functions at each level in each Level 0 function call tree constitute the execution unit named after that Level 0 function.

2. The software source code data coupling coverage analysis method according to claim 1, characterized in that, Step 2 further includes: Perform static data flow analysis of the source code, taking the execution component as the object, extract the input and output variable tables of each function to form function input and output variable tables; then combine the 0-level function call tree information to indirectly generate function-based execution component input and output variable tables, thereby simplifying the formation of execution component input and output variable tables.

3. The software source code data coupling coverage analysis method according to claim 2, characterized in that, Step 3 further includes: Perform dynamic data flow analysis on the source code. By organizing the data flow by source file, merge all the separate tables in the dynamic data flow analysis table into a single complete table. Simultaneously, fill all blank cells with the nearest adjacent value per column. Then, extract the definition and usage information of each data point, generating all possible definition-use pairs with the same name. From these, filter out all definition-use pairs of global variables. Next, eliminate definition-use pairs where the definition and use belong to the same module to form a definition-use pair table between functions. Then, eliminate definition-use pairs where the definition and use belong to the same execution unit, retaining only the definition-use pairs between different execution units. Finally, combine the control flow to review the validity of the retained definition-use pairs between different functions and different execution units, obtaining valid DU pairs of global variables based on functions and execution units, respectively.

4. The software source code data coupling coverage analysis method according to claim 3, characterized in that, Step 4 further includes: Using the information in the global variable effective DU pair table based on the execution unit, the execution unit input and output variable table formed in step 2 is expanded, and the input source and output destination columns are added and filled to form the source code execution unit data coupling relationship table.

5. The software source code data coupling coverage analysis method according to claim 4, characterized in that, Step 5 further includes: Check if there are empty data in the input source and output destination columns of the source code execution component data coupling relationship table. If so, it indicates that there is an anomaly in the source code data flow, and the source code should be further improved.

6. The software source code data coupling coverage analysis method according to claim 5, characterized in that, Step 6 further includes: Referring to steps 4 and 5, expand the function input and output variable tables, add two columns for input source and output destination, identify whether there are data flow anomalies within the execution unit, complete the data coupling relationship analysis between related function modules, and generate a source code data coupling relationship table as a basis for judging whether the source code data coupling conforms to the correctness of the software architecture and low-level requirements.

7. A software source code data coupling coverage analysis device, characterized in that, The device includes: The execution component partitioning module is used to perform static control flow analysis of the source code and partition the execution components. The module for summarizing the input and output variable tables of the execution components is used to perform static data flow analysis of the source code. Taking the execution components as the object, it summarizes and calculates the input and output variable tables of the execution components. The definition-use pair generation module is used to perform dynamic data flow analysis of the source code, generate definition-use pairs between different execution components, and combine the validity of the definition-use pairs generated by control flow review; The source code execution component data coupling relationship table generation module is used to expand the input and output variable table of the execution component, add and fill the input source and output destination columns in the table to form the source code execution component data coupling relationship table. The source code data flow anomaly detection module is used to determine whether there are any anomalies in the source code data flow by checking whether there is empty data in the input source and output destination of the source code execution component data coupling relationship table. The data coupling relationship analysis module between related function modules is used to complete the data coupling relationship analysis between related execution components and between function modules. It serves as the reverse input to determine whether the data coupling of the source code conforms to the software architecture and low-level requirements, and to judge its correctness. The execution component partitioning module is further configured as follows: Perform static control flow analysis on the source code to find all functions that are not called by other functions. These functions are referred to as Level 0 functions, forming a list of Level 0 functions. At the same time, summarize the call relationships between all functions to obtain the original function call relationship table and generate a complete Level 0 function call tree. The called functions at each level in each Level 0 function call tree constitute the execution unit named after that Level 0 function.

8. The software source code data coupling coverage analysis device according to claim 7, characterized in that, The module for summarizing the input and output variable tables of the execution components is further configured as follows: Perform static data flow analysis of the source code, taking the execution component as the object, extract the input and output variable tables of each function to form function input and output variable tables; then combine the 0-level function call tree information to indirectly generate function-based execution component input and output variable tables, thereby simplifying the formation of execution component input and output variable tables.

9. The software source code data coupling coverage analysis device according to claim 8, characterized in that, Execute inter-component definitions - use further configuration of the generated modules as follows: Perform dynamic data flow analysis on the source code. By organizing the data flow by source file, merge all the separate tables in the dynamic data flow analysis table into a single complete table. Simultaneously, fill all blank cells with the nearest adjacent value per column. Then, extract the definition and usage information of each data point, generating all possible definition-use pairs with the same name. From these, filter out all definition-use pairs of global variables. Next, eliminate definition-use pairs where the definition and use belong to the same module to form a definition-use pair table between functions. Then, eliminate definition-use pairs where the definition and use belong to the same execution unit, retaining only the definition-use pairs between different execution units. Finally, combine the control flow to review the validity of the retained definition-use pairs between different functions and different execution units, obtaining valid DU pairs of global variables based on functions and execution units, respectively.

10. The software source code data coupling coverage analysis device according to claim 9, characterized in that, The source code execution component data coupling relationship table generation module is further configured as follows: By utilizing the information in the global variable effective DU pair table based on the execution unit, the execution unit input and output variable table formed by the execution unit input and output variable table summary module is expanded. The input source and output destination columns in the execution unit input and output variable table are added and filled to form the source code execution unit data coupling relationship table.

11. The software source code data coupling coverage analysis device according to claim 10, characterized in that, The source code data stream anomaly detection module is further configured as follows: Check if there are empty data in the input source and output destination columns of the source code execution component data coupling relationship table. If so, it indicates that there is an anomaly in the source code data flow, and the source code should be further improved.

12. The software source code data coupling coverage analysis device according to claim 11, characterized in that, The data coupling relationship analysis module between correlation function modules is further configured as follows: Referring to the source code execution component data coupling relationship table generation module and the source code data flow anomaly judgment module, the function input and output variable tables are expanded, and two columns for input source and output destination are added. This identifies whether there are data flow anomalies within the execution component, completes the data coupling relationship analysis between related function modules, and generates a source code i.e., a data coupling relationship table between functions. This serves as the basis for judging whether the source code data coupling conforms to the correctness of the software architecture and low-level requirements.

Images