CN117033161A

CN117033161A - Data coupling and control coupling analysis method meeting DO-178B target

Info

Publication number: CN117033161A
Application number: CN202310474924.4A
Authority: CN
Inventors: 李晓虹; 肖前远; 孙大伟; 汪勇结
Original assignee: China Aeronautical Radio Electronics Research Institute
Current assignee: China Aeronautical Radio Electronics Research Institute
Priority date: 2023-04-27
Filing date: 2023-04-27
Publication date: 2023-11-10

Abstract

The application provides a data coupling and control coupling analysis method meeting DO-178B targets, which comprises the following steps: step 1: analyzing the data coupling and control coupling coverage in the component, and judging whether the test of the software high-low layer requirements, the software architecture, the software codes and the software-based high-low layer requirements meets the expected target or not; step 2: if the test of the software high-low layer requirements, the software architecture, the software codes and the software-based high-low layer requirements meets the expected targets, analyzing the data coupling coverage among the components, obtaining the coverage condition of the data coupling points of the actual execution path of the software codes when the input condition of the test case is met, and forming a coverage conclusion; step 3: if the test of the software high-low layer requirements, the software architecture, the software codes and the software-based high-low layer requirements meets the expected targets, analyzing the control coupling coverage among the components, obtaining the coverage condition of the actual execution path of the software codes on the control coupling points when the input condition of the test case is met, and forming a coverage conclusion.

Description

Data coupling and control coupling analysis method meeting DO-178B target

Technical Field

The invention relates to the field of civil aircraft software airworthiness verification, in particular to a data coupling and control coupling analysis method meeting DO-178B targets.

Background

DO-178B defines software verification process targets, verification methods, verification activities, process implementation targets, process generation data, data indicating targets. The software test is mainly used for carrying out requirement-based test (low-level test, software integration test and software and hardware integration test), software requirement coverage analysis and software structure coverage analysis.

The DO-178B Tabel-7 defines software with the software grade of A, B, C, and the test structure covers the data coupling and control coupling relation between components in the analysis target to be analyzed and confirmed code. The purpose of data coupling and control coupling overlay analysis is specified in CAST-19 to provide a measure and guarantee of correctness of interactions and dependencies between modules/components.

Definition in DO-178B:

data coupling: the dependency of a software component on data, which is not only controlled by the software component;

control coupling: one software component affects the manner or extent to which another software component performs;

and (3) assembly: and an independent component, consisting of a component, a sub-component or a unit, realizes the unique function of the system and realizes the unique function of the system.

At present, the coverage target of DO-178B data coupling and control coupling can be met, and two methods of manual analysis and tool combination manual analysis can be adopted. The method comprises the steps of adopting a tool and manual analysis method, carrying out data coupling and control coupling pile insertion on a software source code, testing integration, dynamically executing an integrated test case developed based on requirements, collecting a data coupling and control coupling coverage result, manually analyzing the coverage result, and carrying out additional supplementary verification and regression verification on uncovered coupling points; tools need to perform tool authentication activities and meet tool authentication objectives. For large-scale complex software, the code scale is large, the testing environment resources are tense, the testing execution period is long, if the adverse effects directly brought by combining a tool with a manual analysis method are large in project resource requirement and long in project period, and the actual project engineering requirement cannot be met.

Disclosure of Invention

The invention provides a data coupling and control coupling analysis method meeting DO-178B targets, which comprises the steps of carrying out target compliance analysis from two dimensions between components and in the components, carrying out data coupling and control coupling coverage target compliance in the components along with requirement and design review, software high/low-layer requirement test and requirement test coverage and code structure coverage target compliance activity in the verification process, and taking corresponding life cycle data as data coupling and control coupling target compliance evidence in the components; the data coupling and control coupling coverage analysis among the components is performed by checking and analyzing a software architecture, checking and analyzing a software source code, identifying a coupling point realized based on the software architecture in the code, determining a software low-level requirement corresponding to the coverage coupling point, determining a software high-level requirement corresponding to the coverage coupling point, analyzing and determining an integrated test case based on the software high-level requirement, and analyzing and testing an execution path based on the integrated test case to cover the data coupling and control coupling point so as to indicate the data coupling and control coupling coverage target consistency among the components.

The technical scheme is as follows: a data coupling and control coupling analysis method that satisfies a DO-178B objective, the method comprising:

step 1: analyzing the data coupling and control coupling coverage in the component, and judging whether the test of the software high-low layer requirements, the software architecture, the software codes and the software-based high-low layer requirements meets the expected target or not;

step 2: if the test of the software high-low layer requirements, the software architecture, the software codes and the software-based high-low layer requirements meets the expected targets, analyzing the data coupling coverage among the components, obtaining the coverage condition of the data coupling points of the actual execution path of the software codes when the input condition of the test case is met, and forming a coverage conclusion;

step 3: if the test of the software high-low layer requirements, the software architecture, the software codes and the software-based high-low layer requirements meets the expected targets, analyzing the control coupling coverage among the components, obtaining the coverage condition of the actual execution path of the software codes on the control coupling points when the input condition of the test case is met, and forming a coverage conclusion.

Further, the step 1 specifically includes:

step 11: judging whether the software high-level requirements meet the expected targets or not;

step 12: judging whether the low-level requirements of the software meet the expected targets or not;

Step 13: judging whether the software architecture meets the expected target;

step 14: judging whether the software source code accords with an expected target;

step 15: judging whether the software high-level demand test meets an expected target or not;

step 16: and judging whether the software low-level requirement test meets the expected target.

Further, step 2 specifically includes:

step 21: judging the consistency of the software architecture and the software high-low layer requirements and the software architecture;

step 22: judging the consistency of the source code and the software architecture, and identifying data coupling related information;

step 23: identifying data coupling points corresponding to software high/low layer requirements;

step 24: and searching the test case and analyzing the coverage of the data coupling points to obtain a coverage conclusion.

Further, step 21 specifically includes:

step 211: checking and analyzing a data flow diagram in the software architecture, taking the software architecture and the software low-level requirements as input, and checking the number of components defined in the data flow diagram and the consistency of the component names and the software low-level requirements;

step 212: checking and analyzing a data flow interface table in a software architecture, taking the software architecture as input, and checking the number of components between a data flow diagram defined in the software architecture and the data flow interface table, the data flow between the components and the consistency of the names of the components; taking a software architecture and a software low-level requirement as input, and checking consistency of a data dictionary which is defined in a data flow interface table and is subjected to data coupling and the software low-level requirement;

Step 213: and acquiring data name, source component and destination component information in the data coupling coverage analysis report attribute column from the attribute column corresponding to the data flow interface table in the software architecture.

Further, step 22 specifically includes:

step 221: identifying a data coupling object, taking a software architecture data flow interface table and a software source code as inputs, checking the consistency of a data dictionary name defined in the data flow interface table and a variable name defined in the software source code, ensuring one-to-one correspondence between data flow entities and actual code realization among components defined in the software architecture, and identifying and determining the data coupling object;

step 222: identifying the read-write position of a data coupling object in a software source code, taking a software architecture data flow interface table and the software source code as inputs, searching code lines for writing the data coupling object, and checking the consistency of a component to which the software source code for writing belongs and a source component defined by the software architecture; searching a code row for performing read operation on the data coupling object, and checking consistency of a component to which a software source code for performing the read operation belongs and a target component defined by a software architecture;

Step 223: identifying and determining a data coupling point, and determining whether the group of data coupling object read/write operations are data coupling points by analyzing whether the data of the identified data coupling object subjected to the write operation in the source component source code is directly subjected to the read operation by the target component source code; if the data coupling point is determined, the coupling point information is described in a manner that the data coupling object is written in the source code and then read.

Further, step 23 specifically includes:

step 231: identifying a software low-level requirement corresponding to the data coupling point, taking a software source code, the software low-level requirement, a tracking matrix of the software source code and the software low-level requirement as input, and determining the software low-level requirement corresponding to a code row where the data coupling point is located by searching a tracking relation between the software source code and the software low-level requirement;

step 232: and identifying that the data coupling point corresponds to a software high-level requirement, taking a tracking matrix of the software high-level requirement, the software low-level requirement and the software high-level requirement as input, and determining the software high-level requirement corresponding to the data coupling point by searching a traceability relation between the software low-level requirement and the software high-level requirement.

Further, step 24 specifically includes:

step 241: searching a test case, taking the test case, the software high-level requirement and a tracking matrix of the test case as input, and determining a test case corresponding to a data coupling point by searching a tracking relation between the software high-level requirement and the test case;

step 242: the method comprises the steps of analyzing the coverage of a test case to a data coupling point, wherein the first step is to analyze the actual execution path of a software code when the input condition of the test case is met by adopting a manual code reading mode according to the input condition of the test case, and identify the calling path of a main function related to the data coupling point; secondly, analyzing the coverage condition of writing operation on the data coupling object on the actual execution path of the software code according to the low-level software requirement; thirdly, analyzing the coverage condition of the reading operation of the data coupling object on the actual execution path of the software code according to the low-level software requirement; the fourth step is based on the function call path description and the read and write operation coverage analysis description when the test case is executed to form coverage conclusion description, and the function call path description, the read and write operation coverage analysis description data and the coverage conclusion description are used as data coupling coverage analysis description contents;

Step 243: and (3) obtaining a coverage conclusion, and obtaining whether the data coupling points cover the conclusion according to the coverage conclusion description in the coupling coverage analysis description: covered/uncovered, and as a conclusion in the data coupling coverage analysis report properties column.

Further, the step 3 specifically includes:

step 31: judging the consistency of the software architecture and the software source code;

step 32: identifying a control coupling object and corresponding software high/low layer requirements thereof;

step 33: searching a test case according to the identified software high/low layer requirements for controlling the coupling object;

step 34: and according to the searched test cases, analyzing the coverage of the test cases on the control coupling points to obtain a coverage conclusion.

Further, the step 32 specifically includes:

step 321: identifying a control coupling object and acquiring a software low-level demand number, using the software low-level demand as input, identifying function calls existing between different components through software low-level demand description, determining components to which a calling function and a called function belong and corresponding low-level demands, taking the name of the called function as the control coupling object and acquiring a corresponding software low-level demand number;

step 322: identifying the position of a software source code where a control coupling object definition and a call are located, taking a software low-level requirement, a software source code and a software source code to software low-level requirement tracking matrix as input, and determining a software source code C file and a code row where the control coupling object definition is located by searching a trace relation between the control coupling object definition corresponding to the low-level requirement and the software source code; determining a software source code C file and a code row where the control coupling object call is located by searching the software source code which corresponds to the low-layer requirement trace back of the control coupling object call;

Step 323: identifying a control coupling object corresponding to a software high-level requirement, taking a software low-level requirement, a software low-level requirement and a tracking matrix of the software high-level requirement as input, and determining the definition of the control coupling object and calling the corresponding software high-level requirement by searching a tracking relation between the software low-level requirement and the software high-level requirement;

step 324: the control coupling object, the calling component, the called component, the C file and the code position where the calling is located, the C file and the code position where the definition is located, the software low-level demand number and the software high-level demand number information in the data coupling coverage analysis report attribute column are synchronously acquired through the processes.

Further, step 34 specifically includes:

step 341: analyzing the execution path of the test case, analyzing the actual execution path of the software source code when the input condition of the test case is met by adopting a mode of manually reading the software source code according to the input condition of the test case, and identifying a main function call path related to a control coupling object;

step 342: controlling the coverage analysis of the coupling points, wherein in the first step, a software source code static analysis mode is adopted to illustrate the function call of the control coupling object in the called component; secondly, describing software behaviors or software functions when the function call control coupling object in the calling component is performed according to the low-level software requirements; thirdly, analyzing and controlling the condition that the software behavior or the software function is verified when the coupling object is called according to the test result; fourthly, forming a conclusion description of a test case coverage control coupling point based on the execution path analysis of the test case, the description of the control coupling object when the calling component is called, and the condition that the software behavior or the software function of the control coupling object is verified; the method comprises the steps of taking an execution path analysis of a test case, a description of a control coupling object when a calling component is called, a condition that a software behavior or a software function of the control coupling object is verified and a coverage conclusion description of a control coupling point as control coupling coverage description content;

Step 343: and (3) obtaining an overlay conclusion, and obtaining whether the coupling is in an overlay conclusion or not according to the overlay conclusion description in the overlay analysis description: overlay/not, and as a conclusion in the control coupling overlay analysis report properties column.

In summary, the in-component data coupling and control coupling target compliance is directly verified and satisfied by requirement review, design review and code review, requirement-based test, requirement test coverage analysis, structure coverage analysis activities and the like, and corresponding verification life cycle data are simultaneously used for indicating data coupling and control coupling compliance evidences, so that part of in-component coupling analysis activities in tool analysis are directly omitted, additional manual analysis work is not needed, the completeness of data coupling and coupling is further indicated, and manpower, material resources and financial resources for independently developing analysis are saved.

The method for analyzing the data coupling and the control coupling among the components takes the framework document and the source code as input identification coupling points, and rapidly positions the coupling point source code from design- > design to requirement- > requirement to integrated test cases through the tracking matrix, so that the method is clear in process, high in operability and suitable for all software developed by taking DO-178 as a compliance method.

In the invention, the data coupling and control coupling analysis process between the components is equivalent to the acquisition of the coupling point coverage result by adopting the tool instrumentation to dynamically execute the test case by analyzing and clearly describing the code execution path of the test case for covering the coupling point through the system, thereby fully indicating the accuracy and the effectiveness of the analysis and ensuring the navigation authentication confidence.

The invention provides an analysis process method of data coupling and control coupling meeting the airworthiness requirement, which is accompanied with large aircraft model software to complete airworthiness evidence collection, and can be used as a successful experience for guiding the development of a civil aircraft in the future.

Compared with an analysis method combining tools and manpower, the method does not need to develop dynamic execution of the test cases, avoids the problem of environmental resource requirement of model project test, saves manpower resources and labor hour investment required by complete execution of the test cases, can greatly save project test environmental resources and manpower resource investment cost especially in large-scale complex system software, and shortens the software verification period to a great extent.

Drawings

FIG. 1 is a diagram of an inter-component data coupling overlay analysis process;

FIG. 2 is a diagram illustrating the process of data coupling between components in a check analysis software architecture;

FIG. 3 is a diagram of a process of analyzing source code for inter-component data coupling checking;

FIG. 4 is a diagram of an inter-component control coupling overlay analysis process;

FIG. 5 is a diagram of an inter-component control coupling object and its corresponding software high/low level requirements identification process.

Detailed Description

The application provides a data coupling and control coupling analysis method meeting DO-178B targets, which comprises the following steps:

the in-component data coupling and control coupling cover target compliance, and the evidence of the code structure cover target compliance shows that no additional verification activity is required to be carried out through software high-level demand review, software architecture and low-level demand review, software code review, software high-level/low-level demand test (including demand test coverage) based in the verification process; the test strategy is based on software high-level requirement integrated test and obtains and completes integrated test code structure coverage analysis, the software high-level requirement which cannot be covered based on the high-level requirement integrated test and the low-level requirement corresponding to the code structure which cannot be covered based on the high-level test are identified, and then the low-level test is carried out and the structure coverage analysis is carried out in a complementary mode based on the part of software low-level requirement and the derived software low-level requirement.

specifically, a first step of checking and analyzing a software architecture, taking a software architecture and a software low-level requirement as input, checking and analyzing consistency among a data flow diagram defined in the software architecture, a data flow interface table defined in the software architecture and the software low-level requirement, and acquiring data name, source component and destination component information of data coupling; checking and analyzing a software source code, taking a software architecture and the software source code as input, checking and analyzing consistency between a data coupling object and a data flow relation defined in the software architecture and the software source code, identifying the data coupling object and acquiring data coupling points of the data coupling object and position information of a source/destination component code; the third step of identifying the software high/low layer requirements corresponding to the data coupling points, taking the software high/low layer requirements, the software source codes, the software low layer requirement tracking matrix and the software high/low layer requirement tracking matrix as inputs, identifying the software high/low layer requirements corresponding to the data coupling points, and acquiring the software high/low layer requirement numbering information; fourth, searching test cases and analyzing the coverage of the data coupling points, taking the software high-level requirements and the test case tracking matrix as input, searching the test cases corresponding to the software high-level requirements and obtaining test case numbers, test descriptions and test result information; and analyzing the coverage condition of the actual execution path of the software code to the data coupling point when the input condition of the test case is met by taking the test case, the software high-level requirement and the source code as input, and forming a coverage conclusion.

The first step is to check the software architecture and the software source code, and to check the consistency of the calling sequence of the functions in the software source code and the definition of the control flow graph in the software architecture and the correctness of the definition of the control flow in the software architecture by taking the software architecture and the software source code as input. And secondly, identifying the control coupling object and corresponding software high/low level requirements, taking a software source code, a software low level requirement, a software source code to software low level requirement tracking matrix, a software low level requirement and high level requirement tracking matrix and a software high level requirement as inputs, identifying the control coupling object, acquiring the name of a function calling component, the name of the called component and the position information of a calling component/called component, searching the corresponding software high/low level requirements and acquiring the software high level requirement number and the software low level requirement number information. And thirdly, searching the test cases, taking the software high-level requirements, the test case tracking matrix and the test cases as inputs, searching the test cases corresponding to the high-level requirements, and acquiring test case numbers, test case descriptions and test result information. And fourthly, analyzing the coverage of the test case to the control coupling point, taking the test case and the software source code as input, analyzing the coverage condition of the actual execution path of the software code to the control coupling point when the input condition of the test case is met, and forming a coverage conclusion.

Further, the step 1 specifically includes:

the software high-level requirement review ensures that the software high-level requirement meets the system requirement, is accurate and consistent, meets the software requirement standard, can verify, is compatible with the target machine, and the requirement of the system allocation to the software is developed into the target meeting of the software high-level requirement, the algorithm is correct and the like, and forms a review record.

the low-level software requirement review ensures that the low-level software requirement meets the high-level software requirement, is accurate and consistent, meets the software design standard, can be verified, and the high-level software requirement (including derivative requirement) is developed to meet the targets of the low-level software requirement, the correct algorithm and the like, so as to form a review record.

Step 13: judging whether the software architecture meets the expected target;

and the software architecture is reviewed to ensure that the software architecture meets the requirements of a software high layer, the data flow and control flow relationship among the components are defined correctly, the software architecture is compatible with a target machine, meets the requirements of software design standards and other targets, and a review record is formed.

and the software source code review ensures that the source code accords with the low-level requirements of the software, the source code accords with the software architecture, can be verified, accords with the coding standard, and all low-level requirements develop the target satisfaction of the source code and the like to form a review record.

developing a software-based high-level demand test, completing development and review of high-level demand test cases/test programs, integrating test execution, test result review, completing high-level demand test coverage analysis and code structure coverage analysis, and forming high-level demand test case/test programs/test results, review records, demand coverage analysis results and high-level demand test code structure coverage results.

Step 16: judging whether the software low-level demand test meets an expected target or not;

developing a software-based low-level demand test, wherein the low-level demand test range comprises: HLR which cannot be covered based on high-level demand integrated test, low-level demand corresponding to code structure which cannot be covered based on high-level test, derived low-level demand, and multiplexing high-level demand test cases by other low-level demands; and (3) completing development and evaluation of the low-level requirement test case/test program, low-level test execution, test result evaluation, low-level requirement test coverage analysis and supplementary code structure coverage analysis to form a low-level requirement test case/test program/test result, evaluation record, a requirement coverage analysis result and a high/low-level test complete code structure coverage result.

It should be noted that, based on the above execution results, a relationship between evidence indicating the compliance of the in-component data coupling and the control coupling target is established.

The step 2 specifically comprises the following steps:

step 211: and checking and analyzing a data flow diagram in the software architecture, taking the software architecture and the software low-level requirements as input, and checking the consistency of the number of components defined in the data flow diagram and the names of the components and the software low-level requirements.

Step 212: checking and analyzing a data flow interface table in a software architecture, taking the software architecture as input, and checking the number of components between a data flow diagram defined in the software architecture and the data flow interface table, the data flow between the components and the consistency of the names of the components; taking a software architecture and a software low-level requirement as input, checking the consistency of a data dictionary which is defined in a data flow interface table and is subjected to data coupling and the software low-level requirement.

Step 221: and identifying the data coupling object, taking a software architecture data flow interface table and a software source code as inputs, checking the consistency of the data dictionary name defined in the data flow interface table and the variable name defined in the software source code, ensuring one-to-one correspondence between data flow entities and actual code realization among components defined in the software architecture, and identifying and determining the data coupling object.

Step 222: identifying the read-write position of a data coupling object in a software source code, taking a software architecture data flow interface table and the software source code as inputs, searching code lines for writing the data coupling object, and checking the consistency of a component to which the software source code for writing belongs and a source component defined by the software architecture; and secondly, searching a code row for performing read operation on the data coupling object, and checking consistency of a component to which the software source code for performing the read operation belongs and a target component defined by the software architecture.

Step 223: and identifying and determining the data coupling point, and determining whether the group of data coupling object read/write operations are data coupling points by analyzing whether the data of which the data coupling object is subjected to write operations in the source component source code is directly subjected to read operations by the target component source code. If the data coupling point is determined, the coupling point information is described in a manner that the data coupling object is written in the source code and then read.

The data coupling object, the source component C file and the code position, the destination component C file and the code position, and the coupling point information in the data coupling coverage analysis report attribute column are synchronously acquired through the above processes.

step 231: and identifying the software low-level requirements corresponding to the data coupling points, taking a software source code, the software low-level requirements, a software source code and a tracking matrix of the software low-level requirements as input, and determining the software low-level requirements corresponding to the code row where the data coupling points are positioned by searching a traceability relation between the software source code and the software low-level requirements.

It should be explained that, the software low-level requirement number and the software high-level requirement number information in the data coupling coverage analysis report attribute column are synchronously acquired through the above processes.

Step 241: and searching the test cases, taking the test cases, the software high-level requirements and the tracking matrix of the test cases as input, and determining the test cases corresponding to the data coupling points by searching the tracking relation between the software high-level requirements and the test cases.

Step 242: the method comprises the steps of analyzing the coverage of a test case to a data coupling point, wherein the first step is to analyze the actual execution path of a software code when the input condition of the test case is met by adopting a manual code reading mode according to the input condition of the test case, and identify the calling path of a main function related to the data coupling point; secondly, analyzing the coverage condition of writing operation on the data coupling object on the actual execution path of the software code according to the low-level software requirement; thirdly, analyzing the coverage condition of the reading operation of the data coupling object on the actual execution path of the software code according to the low-level software requirement; and fourthly, forming a coverage conclusion description based on the function call path description and the read and write operation coverage analysis description when the test case is executed, and taking the function call path description, the read and write operation coverage analysis description data and the coverage conclusion description as the data coupling coverage analysis description content.

The test case number, test case description, test result, coverage analysis description and conclusion information in the data coupling coverage analysis report attribute column are synchronously acquired through the processes.

The step 3 specifically comprises the following steps:

the method comprises the steps of taking a control flow graph and a software source code in a software architecture as inputs, checking the consistency of a function call sequence in the software source code and a control flow graph definition in the software architecture, and the correctness of the control flow definition in the software architecture, and mainly comprises the correctness of components of functions in the control flow graph, the consistency of control flow external function call and interface requirements and the like.

step 321: and identifying a control coupling object and acquiring a software low-level demand number, using the software low-level demand as input, identifying function calls existing between different components through software low-level demand description, determining the components to which the calling function belongs and the called function belong and the corresponding low-level demands, taking the name of the called function as the control coupling object and acquiring the corresponding software low-level demand number.

Step 322: identifying the position of a software source code where a control coupling object definition and a call are located, taking a software low-level requirement, a software source code and a software source code to software low-level requirement tracking matrix as input, and determining a software source code C file and a code row where the control coupling object definition is located by searching a trace relation between the control coupling object definition corresponding to the low-level requirement and the software source code; and determining a software source code C file and a code row where the control coupling object call is positioned by searching the software source code which corresponds to the lower-layer demand trace back of the control coupling object call.

Step 323: identifying a control coupling object corresponding to a software high-level requirement, taking a software low-level requirement, a software low-level requirement and a tracking matrix of the software high-level requirement as input, and determining the definition of the control coupling object and calling the corresponding software high-level requirement by searching a traceability relation between the software low-level requirement and the software high-level requirement.

and searching the test cases covering the coupling points by taking the tracking matrix and the test cases of the software high-level requirements and the test cases as inputs, and acquiring the test case numbers, the test case descriptions and the test result information in the control coupling coverage analysis report attribute column.

Step 341: and analyzing the execution path of the test case, analyzing the actual execution path of the software source code when the input condition of the test case is met by adopting a mode of manually reading the software source code according to the input condition of the test case, and identifying a main function call path related to the control coupling object.

Step 342: controlling the coverage analysis of the coupling points, wherein in the first step, a software source code static analysis mode is adopted to illustrate the function call of the control coupling object in the called component; secondly, describing software behaviors or software functions when the function call control coupling object in the calling component is performed according to the low-level software requirements; thirdly, analyzing and controlling the condition that the software behavior or the software function is verified when the coupling object is called according to the test result; fourthly, forming a conclusion description of a test case coverage control coupling point based on the execution path analysis of the test case, the description of the control coupling object when the calling component is called, and the condition that the software behavior or the software function of the control coupling object is verified; and taking the execution path analysis of the test case, the description of the control coupling object when the calling component is called, the condition that the software behavior or the software function of the control coupling object is verified and the coverage conclusion description of the control coupling point as the control coupling coverage description content.

The overlay analysis description and conclusion information in the control coupling overlay analysis report attribute column is synchronously acquired through the processes.

Example two

Step 1: the data coupling and control coupling coverage in the analysis component are analyzed, the related verification activities and the compliance evidence are developed and generated when other DO-178B verification targets are met, the review, analysis and test verification activities mentioned in the technical scheme are all required to be developed in actual projects, and the related verification activities adopt general mature processes and methods, which are not disclosed in detail in the invention; after the related verification activities are completed and the target compliance evidences are generated, in the software verification result file, the data coupling and control coupling analyze the compliance evidences, and the description is added to establish the association relationship between the life cycle data (the compliance evidences) indicating the compliance.

Step 2: the data coupling coverage among the components is analyzed, and the data coupling coverage analysis of the invention is described by taking global variables as data coupling objects as examples. An implementation process of the inter-component data coupling analysis is shown in fig. 1. The data coupling overlay analysis report contains the following list of attributes: the method comprises the steps of data name, data coupling object, source component C file and code position, target component C file and code position, data coupling point, software high-level demand number, software low-level demand number, test case number, test description, test result, coupling coverage analysis description and coverage conclusion. The method comprises the following specific steps:

Step 21: the consistency of the software architecture, the software high-low layer requirements and the software self is judged, and the input, output and implementation processes are shown in figure 2. The software architecture data coupling part mainly comprises a data flow diagram and a data flow interface table, wherein the number of components of the software, the name of each component and the data flow (the flow is indicated by an arrow, the arrow tail is a source component, and the arrow is a target component) relationship are marked in the data flow diagram; the data stream interface table comprises three attribute columns, wherein the first column is a source component name, the second column is a destination component name, and the third column is a data dictionary with a data stream relation in the source/destination component.

Step 211: and checking the data flow diagram of the analysis software architecture to detect the consistency of the data flow diagram and the low-level requirements of the software. The software low-level requirement comprises a three-level chapter structure, wherein the first-level chapter is a main chapter named by a component name, and the number of the first-level chapter is the same as the number of the components; the second level chapter is a sub-chapter named by function name; the third level is a functional low-level demand description indexed by the low-level demand number. The method comprises the steps of checking and analyzing a software architecture data flow graph, wherein the number of components in the data flow graph is the same as the number of first-level chapters in low-level requirements, and the names of the components in the data flow graph are consistent with the names of the first-level chapters in the low-level requirements. For the condition that the inspection results are inconsistent, a problem report that the software architecture and the definition of the low-level requirements of the software are inconsistent needs to be submitted, and after the problem is repaired, the subsequent analysis work is carried out.

Step 212: checking a data flow interface table of the analysis software architecture, wherein each group of components with data flow relation in the first checking data flow graph is defined in the data flow interface table, and the data flow direction of each group of components in the data flow graph is consistent with the source and destination in the data flow interface table; the second check analyzes that the data dictionary defined in the data stream interface table is consistent with the definition in the low-level requirements, i.e., the global variable names in the data interface table are consistent with the global variable names in the software low-level requirements. For the condition of inconsistent analysis results, a problem report of inconsistent software architecture and software low-level requirements needs to be submitted, and after the problem is repaired, the subsequent analysis work is carried out.

Step 213: and acquiring data name, source component and destination component information in the data coupling coverage analysis report attribute column from the attribute column corresponding to the data flow interface table in the software architecture. Examples are as follows:

data name: g_FlightPhase_ConvertetTime

Source component name: initialization component

Destination component name: INFOProcess assembly

Step 22: and judging the consistency of the source code and the software architecture, identifying the data coupling related information, and inputting, outputting and implementing the process as shown in figure 3.

Step 221: and identifying the data coupling object, and searching the variable name corresponding to the data dictionary in the software source code as the data coupling object in the data coupling coverage analysis report attribute column.

Step 222: the method comprises the steps of identifying the read-write position of a data coupling object in a software source code, searching a C file and a code line which write variables in the software source code through variable names, searching a function of the software source code line in the source code, and checking the consistency of a component name of the function and a source component name defined by a software architecture. For the condition of inconsistent checking, submitting a problem report for inconsistent implementation of a software architecture and a software source code, and carrying out subsequent analysis work after the problem is repaired; and secondly, searching a C file and a code row which perform read operation on the variable in the software source code through the variable name, searching a function of the code row in the software source code, and checking the consistency of the component name of the function and the destination component name defined by the software architecture. For the condition of inconsistent checking, a problem report of inconsistent software architecture and software source code implementation is submitted, and after the problem is repaired, the subsequent analysis work is carried out.

Step 223: identifying and determining data coupling points, and describing the read-write relationship of the data coupling objects as the coupling points in a data coupling coverage analysis report attribute column according to the following form: the value of the data coupling object is written in the source component C file and code line and read in the destination component C file and code line.

Step 224: and synchronously acquiring the data coupling object, the source component C file and the code position, the destination component C file and the code position and the coupling point information in the data coupling coverage analysis report attribute column through the processes. Examples are as follows:

data coupling object: g_FlightPhase_ConvertetTime;

source component C file and code location: the file name is the code line number;

destination component C File and code location: the file name is the code line number;

coupling point: the value of the data coupling object g_FlightPhase_ConvertTime is written at the C filename of the source component, the code line number, and then read at the C filename of the destination component, the code line number.

Step 23: identifying data coupling points corresponding to software high/low layer requirements

Step 231: searching a software low-level requirement corresponding to a code line for writing a data coupling object in a software source code and software low-level requirement tracking matrix according to a source component C file and the code line; and searching the software low-level requirements corresponding to the code line for performing the reading operation on the data coupling object in the software source code and the software low-level requirement tracking matrix according to the file and the code line of the target component C.

Step 232: and according to the software low-level demand numbers of the read-write operation on the data coupling object, searching the software high-level demand for realizing the read-write operation of the data coupling object by combining the software high-level demand in the software low-level demand and software high-level demand tracking matrix.

Step 233: and synchronously acquiring the software low-layer demand number and the software high-layer demand number information in the data coupling coverage analysis report attribute column through the processes. Examples are as follows:

software high-level demand number: HLR_503

Software low-level demand number: LLR_138, LLR_1142

Step 24: searching a test case and analyzing the coverage of the data coupling points to obtain a coverage conclusion, wherein the method specifically comprises the following steps of:

step 241: and searching and verifying the test cases of the high-level requirements in the software high-level requirements and the test case tracking matrix according to the software high-level requirements numbers.

Step 242: the method comprises the steps of analyzing the coverage of a test case to a data coupling point, wherein in the first step, according to the input condition in the test case, a function call path for performing read-write operation on a data coupling object is analyzed in a mode of manually reading a software source code; secondly, analyzing the function coverage condition of the write operation of the data coupling object by the function call path of the test case according to the low-level software requirement of the write operation of the data coupling object, and if the function coverage condition is not covered, submitting a problem report of the supplementary test case to carry out subsequent analysis work after the problem is repaired; thirdly, analyzing the coverage condition of a function for performing read operation on the data coupling object by a function call path of the test case according to the low-level software requirement for performing read operation on the data coupling object (the read operation function is after the write operation function), and if the function is not covered, submitting a problem report for supplementing the test case, and then carrying out subsequent analysis work after the problem is repaired; fourth, forming coverage conclusion description based on the function call path description and the read and write operation coverage analysis description when the test case is executed: the data coupling points of the data coupling object are covered or the data coupling points of the data coupling object are uncovered. And the function call path description, the read and write operation coverage analysis description data and the coverage conclusion description are used as the content of the data coupling coverage analysis description when the test case is executed.

Step 243: and (3) obtaining a coverage conclusion, and obtaining whether the data coupling points cover the conclusion according to the coverage conclusion description in the coverage analysis description: covered/uncovered, and as a conclusion in the data coupling coverage analysis report properties column.

The test case number, the test case description, the test result, the coverage analysis description and the conclusion information in the data coupling coverage analysis report attribute column are synchronously acquired through the processes. Examples are as follows:

test case number: testFile_TestCase_005

Test case description: the output parameter opINFO42AcpsRdiu7 state will be set to active, the value set to 1 when the alarm IMA is set to active not inhibited (g_flightphase_converttime value 0)

Test results: by passing through

Overlay analysis description:

according to the input setting condition of TestFile_TestCase_005, the function call relation of the test case is as follows: application Init- > reset_global_vars- > application step- >

AlertStatusEvaluator->runAlertEngine->aen_computeInhibition Status->aen_applyFlightPhaseInhibition；

The following steps are performed in a source component (Initialization component):

step1 the data coupling object g_FlightPhase_ConvertTime value is written as 0 at C filename. C/reset_global_vars: code line number (in accordance with LLR_138);

[g_FlightPhase_ConvertTime＝0；]

the following steps are performed in the destination component (info process component):

Step2 the data coupling object g_FlightPhase_ConvertTime value is read at the C filename. C/aen _applied FlightPhaseinhibit: code line number (according to LLR_1142);

[if(g_FlightPhase_ConvertTime>0)]

conclusion: the test case covers the coupling point.

Conclusion: covering of

Step 3: analysis of inter-component control coupling coverage the inter-component control coupling coverage analysis implementation is illustrated in fig. 4. The control coupling coverage analysis report contains the following list of attributes: the method comprises the steps of controlling a coupling object, a calling component C file and a code position, a called component C file and a code position, a software high-level requirement number, a software low-level requirement number, a test case number, a test description, a test result, a coupling coverage analysis description and a coverage conclusion.

Step 31: and judging the consistency of the software architecture and the software source code, defining the function execution sequence of partial functions in the software in a control flow graph of the software architecture, and checking the consistency of the function call sequence in the source code and the function execution sequence in the control flow graph in the software architecture. If the problems are inconsistent, a problem report that the software architecture is inconsistent with the source code needs to be submitted, and after the problems are repaired, the subsequent analysis work is carried out.

Step 32: the input, output and implementation processes of the recognition control coupling object and the corresponding software high/low layer requirements are shown in fig. 5. The specific implementation process is as follows:

identifying a control coupling object and a software low-level demand number, wherein calling relations among functions are described in software low-level demand content, and the software low-level demand is taken as input; the second step, the first-level chapter name of the calling function is obtained in the low-level requirement of the software, and the first-level chapter name of the called function is obtained as the component to which the calling function belongs; thirdly, determining whether the calling function and the called function belong to the same component, if so, taking the name of the called function as a control coupling object, taking the component to which the calling function belongs as a calling component, taking the component to which the called function belongs as the called component, and acquiring a low-level requirement number describing the calling relation of the function; otherwise, the two functions have no control coupling relation, are not identified as coupling objects, and do not need to carry out control coupling analysis.

Determining the position of a software source code where a control coupling object definition and a call are located, taking a software low-level requirement, a software source code and a software source code to software low-level requirement tracking matrix as inputs, searching a control coupling object (function name) in a software source code file, and determining the source code file where a function definition is located and the position of a code row; and searching a source code file and a code line position of a calling control coupling object (function name) in the software source code file according to the software low-level demand number and the software source code and low-level demand tracking matrix.

Identifying that the control coupling object corresponds to the software high-level requirement, and searching the corresponding software high-level requirement according to the software low-level requirement number in a tracking matrix of the software low-level requirement and the software high-level requirement.

The control coupling object, the calling component, the called component, the C file and the code position where the calling is located, the C file and the code position where the definition is located, the low-layer demand number and the high-layer demand number information in the data coupling coverage analysis report attribute column are synchronously acquired through the processes. Examples are as follows:

control the coupling object: function name read_alert DB

Calling a component: initialization component

The invoked component: INFOProcess assembly

Calling the file and the code position of the C: c File name code line number

Defining the C file and the code position: c File name code line number

Low-level demand number: LLR_125

High-level demand number: HLR_62

Step 33: according to the identified software high/low layer requirements of the control coupling object, searching test cases, searching corresponding test cases according to software high layer requirement numbers in a tracking matrix of the test cases and the software high layer requirements, and acquiring test case numbers, test case descriptions and test result information in a control coupling coverage analysis report attribute column. Examples are as follows:

Test case number: testFile_TestCase_010

Test case description: the "31FDAS NO DISPATCH"i information is displayed on the screen when the associated alarm DS-11 is set to active and not suppressed.

Test results: by passing through

Step 34: the method for analyzing the coverage of the test case to the control coupling point specifically comprises the following steps:

Step 342: controlling the coverage analysis of the coupling points, wherein the first step is to explain the functions and code lines of the control coupling objects which are called in the calling component by adopting a software source code static analysis mode; secondly, describing the software behavior or the software function of the calling function call control coupling object according to the low-level software requirement description; thirdly, if the test result passes the path indicating that the execution path of the test case covers the path for controlling the call function of the coupling object, if the test result does not pass, the test result cannot be explained to be executed, and the execution path of the test case covers the path for controlling the call function of the coupling object; fourth, based on the analysis of the above steps, forming a coverage conclusion description: test case covered/uncovered control coupling points; and taking the execution path analysis of the test case, the description of the control coupling object when the calling component is called, the condition that the software behavior or the software function of the control coupling object is verified and the coverage conclusion description of the control coupling point as the control coupling coverage description in the control coupling coverage analysis report attribute column.

Step 343: and (3) obtaining an overlay conclusion, and obtaining whether the coupling is in an overlay conclusion or not according to the overlay conclusion description in the overlay analysis description: coverage/uncovering as a conclusion in the control coupling coverage analysis report properties column.

Step 344: the test case number, the test case description, the test result, the coverage analysis description and the conclusion information in the control coupling coverage analysis report attribute column are synchronously acquired through the processes. Examples are as follows:

overlay analysis description:

according to the input setting condition of TestFile_TestCase_010, the function call relation of the test case is as follows: application init- > read_alert db- > application step- >

AlertStatusEvaluator->runAlertEngine->aen_computeInhibition Status；

In the called component (info process component):

read_ alertDB is defined in C File name, c line number

In the call component (Initialization component):

step 1. According to the static analysis of the code, the read_alert DB is called by the application Init to call the component C file C/application Init: line number.

[read_alertDB(alertDB,&INFOModelInput.AlertsNum,&INFOModelInput.AlertsDef)；]

Step 2. Application init calls read_alert db to read the alert definition configuration information (in terms of llr_125).

Step3, according to the TestFile_TestCase_010, the DS-11 alarm configuration information 31FDAS NO DISPACH is correctly displayed;

step4 so the function application init calls the function read_alert DB

Conclusion: the test case covers the coupling point.

Conclusion: covering of

In summary, the invention provides a data coupling and control coupling analysis method meeting DO-178B targets, which is applied to large-scale complex software of domestic large aircraft and successfully airworthiness evidence-obtaining landing, not only solves the problem of insufficient engineering application of tools combined with manual methods, but also provides a compliance strategy and a compliance method meeting data coupling and control coupling coverage targets by adopting a systematic analysis method approved by a censoring party, and forms data coupling and control coupling target compliance engineering application experience and practice covering the large-scale complex software.

Claims

1. A data coupling and control coupling analysis method that satisfies a DO-178B objective, the method comprising:

2. The method according to claim 1, wherein step 1 specifically comprises:

step 13: judging whether the software architecture meets the expected target;

3. The method according to claim 1, wherein step 2 specifically comprises:

4. A method according to claim 3, wherein step 21 comprises:

5. A method according to claim 3, wherein step 22 comprises:

6. A method according to claim 3, wherein step 23 comprises:

7. A method according to claim 3, wherein step 24 comprises:

8. The method according to claim 1, wherein step 3 specifically comprises:

9. The method according to claim 8, wherein step 32 specifically comprises:

10. The method according to claim 8, wherein step 34 specifically comprises: