JP5775829B2 - Software structure visualization program and system - Google Patents

Description

  The present invention relates to a software tool for analyzing the structure of software, and more particularly to a method for visualizing analysis results and a software tool capable of executing processing according to the method.

  The scale of software has grown and the complexity of structure and processing has increased, making it difficult for designers and verifiers to understand the entire software. In addition, software development is sometimes performed by adding to past assets, which causes unwritten code descriptions and makes it difficult to understand the effects of additions and modifications to software.

  Especially in the control device, the increase in the scale of the control software accompanying the electrification of the device has the potential to cause problems in the electronic control device including the software and increase the risk of impairing the safety of the system. Functional safety standards such as ISO 26262 have been established.

  In order to ensure the safety of the system, it is preferable that the designer and the verifier understand the structure and processing of the software, particularly the past assets and the source code described by other designers. For the purpose of facilitating understanding by designers and verifiers, there are methods and tools for performing static analysis and dynamic analysis on programs and visualizing the results as figures such as function call graphs. Among the visualization objects, as one of important information on the software configuration, there is a dependency relationship between variables. Here, the dependency relationship is a relationship in which the execution result may change depending on the execution order. The software operation is a series of processes that calculate using data such as input and change other data that leads to output, so variable dependencies are important in understanding the software configuration and process overview. is there.

  As prior arts that are close to analyzing variable dependency relationships from source code and displaying them as graphs, Patent Literature 1 and Patent Literature 2 generate a data flow graph from source code. Here, the data flow graph shows a data flow (variable dependency) in a certain statement, not a data flow between a plurality of statements.

  Non-Patent Document 1 introduces PDG (Program Dependence Graph). In PDG, data dependency existing between source code and statements (dependency that arrives at the instruction being referenced from the instruction that defines the variable, that is, determines the value) and control dependency (conditional expression of branch or loop) The dependency relationship between the instruction referring to the variable and the instruction defining the variable by the instruction included in the branch / loop is indicated by a directed graph, and the nodes of the graph are statements.

  Non-patent documents 2 and 3 analyze and display variable dependency relationships. However, variables are not distinguished by description positions in dependency analysis / display. Even for variables with the same name and substance (storage area), if the description position (file, function, row, column) is different, it is necessary to treat them separately in terms of dependency.

Japanese Unexamined Patent Publication No. 7-93144 JP 2003-50722 A

"Program Slicing Technology and Applications" Kyoritsu Publishing (1995) Osaki, Yamamoto, Aso: “Dependency Display Tool for Program Understanding” (FOSE'96) ** Inoue Laboratory **

  In the above prior art, consideration is not given to providing the user with the analysis result of the variable dependency in consideration of the processing order at the time of execution.

  The present invention analyzes dependencies between variables over a wide range of source code, such as between multiple statements and functions, and visually understands the influences and dependencies between variables determined by the processing order during software execution It is also intended to provide a user with information on the software configuration and processing overview by enabling a user to display a variable as a unit (node) on a graph.

  In order to solve the above problems, the present invention provides a software structure visualization program for causing a computer to input a software source code, analyzing the source code, and outputting an analysis result. Dependency relationship between variables for a plurality of variables distinguished for each description position in the source code from a syntax analysis unit for causing the source code to analyze the syntax and a result of the syntax analysis by the computer A variable dependency analysis unit for deriving and a variable dependency relationship derived by the variable dependency relationship analysis unit together with description position information in the source code of the plurality of variables displayed on the display device on the computer, Or a variable dependency output unit for executing output to the outside of the computer It is configured to have a.

  According to the present invention, it is possible for a designer or a verifier to easily understand the software structure and processing outline from the viewpoint of variable dependency.

The basic function block diagram of this invention. The functional block diagram of a variable dependence analysis part. Processing flow of variable dependency analysis. Source code to be analyzed in the first embodiment. The source code syntax tree of the first embodiment. The database regarding the control flow of the source code of Example 1. FIG. 2 is a control flow graph of source code of the first embodiment. The database regarding the substitution dependency of the source code of Example 1. FIG. The database regarding the data dependency of the source code of Example 1. FIG. The database regarding the control dependence relationship of the source code of Example 1. FIG. 3 is a graph showing a variable dependency relationship (network) of source code according to the first embodiment. The extended function block diagram which extracts a variable dependency (tree) from a variable dependency (network). Process flow to extract variable dependency (tree). 3 is a graph showing a variable dependency (tree) of source code according to the first embodiment. Linked display example of variable dependency (tree) and source code. 5 is a display example of the execution path count result of the source code of the first embodiment. A processing flow that extracts variable dependencies (trees) that indirectly affect different execution paths. Source code to be analyzed in the second embodiment. The example which extracted the variable dependence relationship (tree) indirectly influenced in the different execution path from the source code of Example 2. FIG. The expansion functional block diagram which compares two variable dependencies. A processing flow for comparing two variable dependencies. Comparison example of variable dependency, when there is a difference. Comparison example of variable dependency, when there is no difference. Compound display example of function call graph and variable dependency (tree). The system configuration of the present invention. Display example of slicing processing result based on variable dependency.

  The syntax analysis unit in the present invention analyzes the source code and outputs syntax information. The variable dependency relationship analyzing unit includes a control flow deriving unit, an assignment dependency deriving unit, a data dependency deriving unit, a control dependency deriving unit, and a variable dependency deriving unit. The control flow deriving unit outputs a control flow from the syntax information. The substitution dependency relationship deriving unit outputs a substitution dependency relationship between two variables from the control flow. The data dependency relationship deriving unit outputs a data dependency relationship between two variables from the control flow. The control dependency relationship deriving unit outputs a control dependency relationship between two variables from the control flow. The variable dependency relationship deriving unit outputs a variable dependency relationship between a plurality of statements from the substitution dependency relationship, the data dependency relationship, and the control dependency relationship. The variable dependency relationship output unit displays the variable dependency relationship as a graph. The variables in each of the above sections are distinguished from each other not only by variable names and variable entities (storage areas) but also by description positions in the source code.

[Example 1]
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a basic functional configuration diagram for realizing the present invention, and is common to all embodiments in the present specification. The present invention is implemented as a software tool. Each function is implemented as software, and is executed on a computer including a display screen, a main arithmetic device, a main storage device (main memory), a storage medium such as a hard disk, and an input device such as a keyboard and a pointing device.

  The file input unit 11 has a function that allows the user to select one or more source code files to be analyzed, and reads the source code file from a computer storage medium in accordance with the file designation by the user. When the user instructs execution of analysis, the syntax analysis unit 12 analyzes the syntax of the source code file read by the file input unit 11, and generates syntax syntax tree data. In the embodiment of the present specification, source code written in C language is handled. In the syntax tree, in addition to the description position, an entity (area in the storage medium) is assigned to each variable distinguished by the description position in the form of an ID. The entity is analyzed from the name, type, and scope (global, local, etc.) of the variable.

  The function extraction unit 13 extracts attributes such as a name and a description position for each function described in the source code from the syntax tree generated by the syntax analysis unit 12, and outputs the function attribute data. The execution start point selection unit 14 displays the function name from the function attribute data output by the function extraction unit 13. The user can select one or more functions as the execution start point from the display of the execution start point selection unit 14, and the execution start point selection unit 14 outputs the selected function as execution start point data. The variable dependency relationship analysis unit 15 analyzes the variable dependency relationship from the syntax tree generated by the syntax analysis unit 12 and the execution start point data output from the execution start point selection unit 14 and outputs the data as data. The variable dependency relationship output unit 16 displays the variable dependency relationship data output from the variable dependency relationship analysis unit 15 as a graph. The source code output unit 17 displays the contents of the source code file read by the file input unit 11. In addition, it is possible to display a linkage with the variable dependency relationship of the variable dependency relationship output unit 16. At the time of the cooperative display, the syntax tree data generated by the syntax analysis unit 12 is also used.

FIG. 25 shows a system configuration when the present invention is realized as a system.
The software described in FIG. 1 is stored as, for example, a ROM 2513 on the computer 251 as the software structure visualization program 25131, and is read and executed by the CPU 2512. The computer 251 executes processing defined by the software structure visualization program 25131, that is, processing of each unit described in FIG. The source code file to be analyzed is stored in the hard disk 2514 on the computer 251. User operations such as analysis execution instructions can be performed from an input device 252 such as a keyboard.

  The output from the source code output unit 17 is output to a display device 253 such as a display, for example, but is output via a network to an external computer (not shown) or in a data file format to an external storage medium such as a CD-ROM. May be output by writing.

  FIG. 2 shows details of the variable dependency relationship analysis unit 15. The control flow derivation unit 21 follows the syntax tree output from the syntax analysis unit 12 from the execution start point data output from the execution start point selection unit 14, analyzes the control flow, and outputs the data as data. The substitution dependency derivation unit 22, the data dependency derivation unit 23, and the control dependency derivation unit 24 derive the substitution dependency, the data dependency, and the control dependency from the control flow data output from the control flow derivation unit 21, respectively. And output as data.

  Note that the substitution dependency, data dependency, and control dependency in the present invention have variables as units (nodes), but each variable is distinguished not only by the variable name and entity but also by the description position in the source code. For example, global variables a, b, and c are declared, and the source code file src. In the function func described in c, if there is an expression b = a on the third line (of src.c) and an expression c = a on the fifth line, a in the third line and a in the fifth line Is treated as a different node. In this specification, “a” in the third line is expressed as “a (L3 @ func)”. The description position attribute of a variable includes not only a row but also a column. In this specification, column information is omitted in some notations. In addition, a file name or a file path may be used for the description position attribute instead of the function name. “Variable” includes a variable for accessing a register of a microcomputer that performs input / output with a peripheral circuit. The variable dependency includes a dependency between a variable and a constant.

  In this specification, “assignment dependency” means dependency by assignment processing between two variables. As an example, if there is a statement a = b for variables a and b, there is a dependency relationship a ← b (a depends on b. B affects a). An assignment dependency can be extracted by searching an assignment statement from a syntax tree. In software analysis, a variable to be defined (value determination) is called def, and a variable to be referenced is called use. In the above example, the variable a is def and the variable b is use.

  The data dependency relationship is a dependency relationship that reaches from a certain def to the same entity use that is closest in the processing order in each execution path that can be transitioned from a statement including the def. For this reason, for each def of the syntax tree, the data dependency is derived by tracing the execution path through the syntax tree from the def according to the control flow and searching for the entity use appearing before the def of the entity. Can do. As an example of a specific processing method, the syntax tree is traced from each statement including def in the syntax tree. A branch statement such as an if statement follows each branch. When the same entity use as the def is found, the data dependency relationship to that use is stored, and the search is terminated for the branch currently being followed.

  The control dependency relationship is a dependency relationship that reaches a def described in the branch statement or loop statement from a use statement described in a conditional statement of a branch statement such as an if statement or a loop statement such as a while statement. . Therefore, for each use described in the conditional expression of the branch statement / loop statement in the syntax tree, each execution path is traced from the use according to the control flow through the syntax tree, and def described in the branch statement / loop statement. By searching for, control dependence can be derived. For example, the if statement includes a clause when the conditional expression is true and a clause when the conditional expression is false. The def included in each clause is searched. At this time, even if use and def are different, a control dependency relationship is generated.

  The variable dependency relationship deriving unit 25 connects the dependency relationships output by the substitution dependency relationship deriving unit 22, the data dependency relationship deriving unit 23, and the control dependency relationship 24, and derives a variable dependency over a wide area of the source code to be analyzed. And output as data. More precisely, it is a variable dependency over the entire execution path starting from the function of the execution start point selected by the user in the execution start point selection unit 14. The output variable dependency relationship data is passed to the variable dependency relationship output unit 16.

  FIG. 3 shows a flow of processing for deriving a variable dependency relationship by the functions shown in FIGS. In step 31, the syntax analysis unit 12 outputs syntax tree data. The syntax tree data may be temporarily stored in a storage medium such as the RAM 2511 or may be created as a data file on the hard disk 2514. In step 32, the function extraction unit 13 extracts the function name from the syntax tree data generated in step 31, and the execution start point selection unit 14 displays the function name and accepts the execution start point selection by the user. In step 33, the control flow deriving unit 21 outputs control flow data from the syntax tree data and the execution start point data input in step 32. Similarly, regarding the control flow data, any output destination such as the RAM 2511 and the hard disk 2514 may be used. In step 34, the substitution dependency relationship deriving unit 22 derives and outputs the substitution dependency relationship from the control flow data output in step 33. In step 35, the data dependency derivation unit 23 derives and outputs the data dependency from the control flow data output in step 33. In step 36, the control dependency relationship deriving unit 24 derives and outputs the control dependency relationship from the control flow data output in step 33. In step 37, the variable dependency relationship deriving unit connects the substitution dependency output in step 34, the data dependency output in step 35, and the control dependency output in step 36. Derives and outputs variable dependencies over a wide area of the source code. Similarly, for each of the data dependency relationship, the control dependency relationship, and the variable dependency relationship, any output destination such as the RAM 2511 or the hard disk 2514 may be used.

  In the following, an example of analysis and display of variable dependency on sample source code will be described. FIG. 4 shows a source code file to be analyzed. The numerical value at the left end of the file indicates the line number. FIG. 5 is a graph showing the syntax tree data output by the parsing unit 12 with the sample source code of FIG. 4 as an input (however, declarations of variables and functions are omitted. The assignment statement is also decomposed into a tree). Yes, but omitted) The syntax tree data 51 to 54 correspond to the functions f1, f2, f3, and f4, respectively, and each node of the syntax tree means one syntax element. Each syntax node is assigned a unique ID (syntax ID) in the entire source code to be analyzed. A numerical value written in parentheses to the right of each syntax node in FIG. 4 is a syntax ID. To explain a part of the structure of the syntax tree, an if statement (101) is placed below the function f1 (syntax ID 100), and a conditional expression “x> 0” (103) is placed below the if statement. A clause (104) when true and a clause (106) when the conditional expression is false are arranged. Although not drawn in FIG. 5, each node of the syntax tree has a described file name, description start position (row / column), and description end position (row / column) as attributes. For example, the file name “src01.c”, the description start position “5th row and 2nd column”, and the description end position “9th row and 2nd column” are recorded in the node of the “if” statement (syntax ID = 101).

  FIG. 6 shows an example of control flow data output from the control flow deriving unit 21. This is data when the user selects the functions f1 and f4 in the execution start point selection unit 14. In the control flow data 61, one data set (one line) means one syntax element, syntax ID, source code file path (not shown in the figure), function name (or function ID), and start row / column. The description position, the statement, the entity ID of the variable included in the statement, and the “passing point” items. The variable entity IDs are uniquely assigned by the parsing unit 12 in the order in which the variable declarations are extracted in the parse tree data. The “passing point” is data in which syntax IDs such as a function call statement, a function entry, and a branch statement that have passed through until reaching the syntax are arranged in the passing order. Explaining the passing point data for several syntax elements, the function f1 (syntax ID 100) and the function f4 (400) are the execution start points, so the passing point is empty. Conditional expression x> 0 (103), true sentence a = 1 (105), and fake sentence a = 0 (107) have a function f1 (100) and an if sentence (101) as passing points. The conditional statement (102), the TRUE clause (104), and the FALSE clause (106) are passing points, respectively. Conditional expression y> 0 (403), assignment statement z + = y (405), y-(406) has function f4 (400) and while statement (401) as passing points. In addition, the conditional statement (402) and the inside of the loop (404) are passing points. Thus, the passing point data can be derived from the parent-child relationship of each node in the syntax tree.

  In the control flow data 61, the data of each syntax is arranged in a semi-order based on the execution order. That is, the execution order is basically the same, but, for example, there is no order relation between the true sentence and the false sentence of the if statement, and one of them is arranged first on the data. Whether there is an order relationship between the two syntaxes can be determined from the passing point data and the statement type. For example, the true sentence (syntax ID 105) and the fake sentence (107) have the same passing point data up to the if sentence (101), but are different in the subsequent TRUE clause (104) and the FALSE clause (106). ) Shows that they are parallel. The assignment statement (108) and the function call statement (109) have the same passing point data, and thus are understood to have an order relationship.

  FIG. 7 shows the control flow data 61 in a directed graph. The numerical value of the node is a syntax ID. The variable dependency relationship deriving unit 25 can obtain information equivalent to the control flow shown in the control flow graphs 71 and 72 from the control flow data 61. For example, in the control flow data 72, the flow that returns from the assignment statement (406) to the conditional statement (403) is assigned the passage statement data “in-loop (404)”. It can be judged from that.

  FIG. 8 shows the assignment dependency relationship data output by the assignment dependency relationship deriving unit 22. In the substitution dependency relationship data 81, one data set (one line) means one dependency relationship, and is composed of dependency destination variable (def) and dependency source variable (use) data. It consists of items of variable name or immediate value, entity ID of variable (or immediate value), description position represented by function name and start row / column. Note that the variable z of the statement z + = y described in the fifth line of the function f4 is broken down into two, def and use. The assignment dependency 81 can be derived by extracting an assignment statement from the control flow data 61 (or syntax tree data 51 to 54).

  FIG. 9 shows data dependency relationship data output from the data dependency relationship deriving unit 23. In the data dependency 91, one data set (one line) means one dependency, and is composed of the dependency destination variable (use) and the dependency source variable (def), and the data item of each variable is assigned. This is the same as the dependency relationship data 81.

  As a derivation example of the data dependency relationship data 91, “z (L8 @ f4) ← z (L5 @ f4)” and “z (L5 @ f4) ← z (L5 @ f4)” will be described. The control flow data 61 searches for a use having the same entity (ID12) as z (L5 @ f4), starting with z (L5 @ f4), which is def of the syntax ID 405. z (L5 @ f4) is in the loop (404) of the while statement (syntax ID 401), but this loop is up to syntax ID 406. Since no corresponding use is found up to syntax ID 406, two execution paths, syntax IDs 403 to 406 and syntax ID 407, are searched. Since the corresponding use first found in each execution path is z (L5 @ f4) of syntax ID 405 and z (L8 @ f4) of syntax ID 407, data having z (L5 @ f4) def as a dependency source Judge that there is a dependency.

  FIG. 10 shows control dependency relationship data output from the control dependency relationship deriving unit 24. In the control dependency relationship data 101, one data set (one line) means one dependency relationship, and consists of dependency destination variable (use) and dependency source variable (def) data. This is the same as the substitution dependency relationship data 81.

  As a derivation example of the control dependency relationship data 101, “a (L6 @ f1) ← x (L5 @ f1)” and “a (L8 @ f1) ← x (L5 @ f1)” will be described. In the control flow data 61, the def described in the if statement (101) to which the conditional expression (103) belongs is searched from x (L5 @ f1) which is a use used in the conditional expression x> 0 (syntax ID 103). Then, since a (L6 @ f1) and a (L8 @ f1) in the syntax (105, 107) in which the passage point data includes the if statement (101) are found as corresponding defs, there is a control dependency relationship. judge.

  FIG. 11 shows data obtained by integrating substitution dependency relationship data 81, data dependency relationship data 91, and control dependency relationship data 101, with variable dependency relationships represented as a directed graph. In the data integration method, def / use is attribute information of each variable, and the dependence source and the dependence destination are combined into one table regardless of the distinction of def / use. The variable dependency relationship output unit 16 performs display equivalent to that in FIG. When the functions f1 and f4 are designated as the execution start points for the source code in FIG. 4, two variable dependency relationships 111 and 112 are derived. The root node of the variable dependency relationship 111 is f (L14 @ f1), and the root node of the variable dependency relationship 112 is e (L8 @ f4). As can be seen between z (L5 @ f4) def and z (L5 @ f4) use in variable dependency 112, there may be a loop in the dependency. For this reason, when the variable dependency is graphed as shown in FIG.

  FIG. 12 shows a difference from FIG. 1 in a functional configuration diagram for extracting and displaying a graph of data in a tree format with a certain node (variable distinguished by position) as a root from a variable dependency in the network format. Yes.

  The variable extraction unit 121 searches the variable declaration unit from the syntax tree data output by the syntax analysis unit 12, extracts attribute information of the declared variable, and outputs it as variable attribute data. In variable attribute data, variables are distinguished by substance and not by description position. The variable selection unit 122 displays the variable attribute data output from the variable extraction unit 121. From the display of the variable selection unit 122, the user can select one or a plurality of variables to be the root of the variable dependency relationship, and the variable selection unit 122 outputs attribute data regarding the selected variable. The variable dependency relationship extraction unit 123 uses a variable included in the variable attribute data as a route from the network format variable dependency data output from the variable dependency relationship analysis unit 15 and the variable attribute data output from the variable selection unit 122. Extract variable dependency in tree format and output as data. The variable dependency relationship output unit 16 displays tree format variable dependency relationship data output from the variable dependency relationship extraction unit 123.

  FIG. 13 shows a flow of processing for extracting the variable dependency relationship in the tree format by the variable dependency relationship extracting unit 123. The process flow starts from process 1. In step 131, the variable dependency relationship extracting unit 123 is included in the variable attribute data output from the variable selecting unit 122, starting from the root node of the network type variable dependency relationship output from the variable dependency relationship analyzing unit 15 (description position). The node of the variable that has the same entity as the variable (not distinguished by the description position) is identified. Further, a copy of the searched node is set as a root node of a tree-type variable dependency output from the variable dependency extraction unit 123. In step 132, the variable dependency relationship extraction unit 123 calls process 2 using the tree root node set in step 131 and the node searched from the network format dependency relationship as arguments. Here, the nodes that are the dummy arguments of the process 2 are “addition point node” and “search point node”. Steps 133 to 135 are performed for all the child nodes of the search point node (nodes on which the search point node depends), and are not performed if there are no child nodes. In step 133, the variable dependency relationship extraction unit 123 connects the copy of the child node as a dependency destination to the additional point node. In step 134, it is confirmed whether or not a child node of the child node, that is, a grandchild node of the target node has been added to the tree. In the confirmation method, the tree is traced from the root node, and the presence / absence of a node that matches the grandchild node (including not only the entity but also the description position) is determined. If a matching node exists, it has been added. If it has been added, step 135 is skipped, and if it has not been added, the process proceeds to step 135. In step 135, the variable dependency relationship extraction unit 123 calls process 2 using the node added in step 133 and the child node as arguments. The process 2 has a recursive structure, and when all the processes 2 are completed, the process 2 returns to the process 1 and the process 1 is terminated.

  FIG. 14 is an example in which variable dependency relationship data in the tree format extracted by the variable dependency extraction unit 123 according to the processing flow of FIG. 13 is displayed as a directed graph, and the variable dependency output unit 16 displays the same display as in FIG. Do. The tree-type variable dependency relationships 141 and 142 are data obtained by extracting the variable e as a root node from the network-type variable dependency relationships 111 and 112 described in FIG. 11, and the dependency relationship loop is lost.

  If a grandchild node in step 134 has been added to the tree, the same node as the grandchild node in the tree can be connected as a dependency destination to the node added in step 133. Dependency can be extracted.

  In addition, in the processing flow of FIG. 13, dependency child nodes are traced and added, which is “variable dependency that affects the selected variable”. Contrary to the processing flow of FIG. 13, the tree is extracted by tracing the parent node, and when the same display as in FIG. 14 or FIG. 15 is performed, “the dependency that the selected variable affects” is extracted and displayed. Can do.

  By displaying the variable dependency relationship in a tree format as shown in FIG. 14, the user can trace the dependency relationship in one direction from the variable serving as the root node, so the display is simpler than when there is a loop in the dependency relationship. Thus, the user can easily follow the dependency relationship and understand the structure of the software.

  FIG. 24 is a graph in which the variable dependency relationship 111 of FIG. 11 is drawn in different formats, and is a composite graph of the variable dependency relationship and the function call. The variable dependency relationship output unit 16 performs display equivalent to that in FIG.

  Connections (arrows) indicating the function nodes 241 to 243 and the calling order thereof indicate a function call graph. The function call graph data is created by the variable dependency derivation unit 25 by extracting and linking the function call syntax from the control flow data 61 by the control flow derivation unit 21. Specifically, f1 → f2 (syntax ID 109) and f2 → f3 (201) are extracted and connected.

  Each variable node of the variable dependency relationship 240 is arranged in a function node corresponding to the function in which the variable node is described among the function nodes 241 to 243. The notation of each node in the variable dependency relationship 240 is different from the variable dependency relationship 111, and the function name is omitted from the description position information.

  By displaying the graph as shown in FIG. 24, the user can see the function call order, the variable dependency relationship, and the relationship between both at the same time, so that the software structure can be understood from a different point of view than the variable dependency relationship alone. can do.

  FIG. 15 shows an example in which variable dependency and source code are displayed in cooperation with each other. The variable dependency relationship display area 151 is a part of the variable dependency relationship output unit 16 and displays the variable dependency relationship 141 in the tree format of FIG. The points from c (L6 @ f2) are aggregated and not displayed. When the user uses the cursor 152 to select a node having a variable dependency relationship display area 151 (variable identified by description position), the selected variable is displayed in the source code display area 153 that is a part of the source code output unit 17. The source code including the description is displayed. In FIG. 15, the selected d (L13 @ f1) is described as src01. c is displayed, the line 13 is further underlined, and the variable d is highlighted, which makes it easy for the user to identify the location where the selected variable is written.

  Processing for realizing the display of FIG. 15 will be described below. When the variable dependency relationship output unit 16 detects that a variable is selected by the cursor 152 in the variable dependency relationship display area 151, the variable dependency relationship output unit 16 notifies the source code output unit 17 of attribute information of the selected variable. The source code output unit 17 displays the file in the source code display area 153 from the file path included in the notified variable attribute information. Also, underline display and highlight display are performed from the description position of the variable included in the notified variable attribute information.

  In addition, the variable selected by the cursor 152 in the source code display area 153 can be searched from the dependency relation in the variable dependency display area 151 and displayed. When a certain description position is selected by the cursor 152 in the source code display area 153, the source code output unit 17 selects a variable at the same position as the selected description position from the syntax tree data output by the syntax analysis unit 12. Explore. If the corresponding variable exists, the variable dependency output unit 16 is notified of the attribute information of the variable. The variable dependency relationship output unit 16 searches for matching variable nodes using attribute information (entity ID, description position) notified from the variable dependency as a key. If the node exists, the node is highlighted in the variable dependency display area 151.

  In FIG. 15, the variable dependency relationship and the function call graph are also displayed in a linked manner. In the function call graph display area 154, the node of the function f1 in which d (L13 @ f1) selected in the variable dependency relation display area 151 is described is underlined. The function call graph display area 154 receives notification of the attribute information of the variable selected from the variable dependency relationship output unit 16, and searches the function call graph for a function node that matches the function name (or function ID) included in the attribute information. And underlined.

  As described above, by deriving dependencies between variables over a wide area of the source code, such as between multiple statements and functions, and displaying the variable as a unit (node) at the description position in the source code and displaying it in a graph It is possible to provide the user with information on the software configuration and processing overview from the viewpoint of variable dependency. This makes it easy for the designer and verifier to understand the software structure and processing outline.

  FIG. 16 is a display example of variable attribute information by the variable selection unit 122. In the variable display area 161, if the user selects a variable (not distinguished by the description position) with the cursor 152 in the variable selection area 162, the tree-type variable dependency with the selected variable as the root node is extracted as the variable dependency relation. Extracted by the unit 123.

  In the variable display area 161, an execution path number display field 163 can be provided. The execution path number display field 163 displays the number of execution paths for each of the variables a to e and x to z. The number of execution paths can be obtained from the network-type variable dependency output from the variable dependency relationship analysis unit 15. Tracing from the root node of each dependency relationship, the presence / absence of each variable entity is checked, and when it appears, 1 is set when it appears, and 0 is set when it does not appear. However, in order to prevent the search from being terminated due to a dependency loop, the node traced once is temporarily stored, and the node is not traced beyond that node. Even if variables with the same entity appear multiple times in one variable dependency tree, the number of execution paths is one.

  When the variable dependencies 111 and 112 are traced from the root node, the variable e appears in both variable dependencies, so the number of execution paths is 2, the variables a to d and f are only the variable dependency 111, and the variables x to Since z appears only in the variable dependency relationship 112, the number of execution paths is 1, respectively.

  With the display as shown in FIG. 16, the user can select the variable to be the root node of the tree-type variable dependency by looking at the number of execution paths of each variable. A variable accessed from a plurality of execution paths may cause problems due to interference between processes that are not assumed at the time of design, such as data access contention and exclusive control failure, depending on the processing timing of each execution path. In this embodiment, the function f1 () is executed in the periodic task, and the function f4 () is executed by interrupt processing immediately before referring to the value of the variable e by the syntax ID 111, and the value of the variable e is rewritten. Can be assumed. The user extracts variables that can cause software defects, displays variable dependency relationships corresponding to the execution paths of processes that can cause failure events, and displays source code related to the execution paths from variable dependency relationships. Thus, it is possible to visually check a candidate for a defect occurrence location and confirm whether a defect can actually occur.

[Example 2]
FIG. 17 shows a flow of processing that the variable dependency relationship extracting unit 123 can implement after the processing of FIG. Through this processing flow, a tree of variable dependency relationships that can affect the variables selected by the variable selection unit 122 “indirectly” is extracted. Here, “indirectly” means that a variable is different from the selected variable, and a variable existing in a different execution path has a dependency relationship with the selected variable depending on processing timing.

  The flow starts from process 1. Step 171 is performed for each root node of the tree-type variable dependency extracted by the processing of FIG. In step 171, the variable dependency relationship extracting unit 123 calls process 2 using one root node of the variable dependency relationship in the tree format as an argument. Here, a node that is a dummy argument of the process 2 is a “search point node”. Steps 172 to 175 are performed for all child nodes of the target node, and are not performed if there are no child nodes. In step 172, the variable dependency relationship extraction unit 123 determines whether the child node is a use, and if it is a use, the process proceeds to step 173, and if not, the process proceeds to step 175. In step 173, the variable dependency relationship extracting unit 123 searches the variable dependency relationship in the network format output by the variable dependency relationship analyzing unit 15 for a variable node having the same entity as the child node and having a def (identified by a description position). To do. However, the variable dependency including the same node as the target root node in step 171 is excluded from the search target. If the def exists, the process proceeds to step 174. If not, the process proceeds to step 175. In step 174, the variable dependency extraction unit 123 extracts a tree-type variable dependency having the def searched in step 173 as a root. The extraction method is the same as the processing flow of FIG. In addition, it is determined whether or not the extracted tree-type variable dependency and the already-extracted tree-type variable dependency are duplicated, and the overlapping tree is discarded. The method for determining the overlap between two trees is that the former tree is redundant and can be discarded if the root node of one tree is included in the same or lower level as the root node of the other tree. This determination is performed between the newly extracted tree and all the already extracted trees. In step 175, the variable dependency relationship extraction unit 123 calls process 2 with the child node as an argument. The process 2 has a recursive structure, and when all the processes 2 are completed, the process 2 returns to the process 1 and the process 1 is terminated.

  In the following, an example will be described in which variable dependency is extracted and displayed for the sample source code by the process of FIG. FIG. 18 shows a source code file to be analyzed. 19, variable dependency relationships 191 and 192 are network type variable dependency relationships extracted by the variable dependency relationship extracting unit 123 when the execution start points are the functions f5 and f6. If the variable d is selected as a root node by the variable selection unit 122 by the user with respect to these variable dependency relationships, the variable dependency relationship extraction unit 123 uses the processing flow in FIG. The dependency relationship 193 is extracted. Further, the variable dependency relationship extracting unit 123 extracts c (L6 @ f5), which is a use included in the variable dependency relationship 193, c (L4 @ f6) from the variable dependency relationship 192 according to the processing flow of FIG. The search is performed, and a variable dependency 194 in a tree format is extracted with c (L4 @ f6) as a root node.

  When the functions f5 and f6 are executed in parallel as interrupts or OS (Operating System) tasks, the value of c (L6 @ f5) use is not c (L5 @ f5) def depending on the execution timing of each process. It becomes the value of c (L4 @ f6) def. That is, c (L4 @ f6) indirectly affects c (L5 @ f5) and can further affect d (L6 @ f5).

  As described above, by indirectly extracting and displaying the variable dependency that has an influence, the user can easily find from the source code a location that may cause a failure due to the failure of exclusive control or data competition depending on the execution timing of the processing. Moreover, the possibility of an actual malfunction can be confirmed by displaying the variable dependency relationship and the source code in cooperation with each other as shown in FIG.

[Example 3]
FIG. 20 shows the difference from FIG. 1 in the functional configuration diagram for comparing and comparing the variable dependency of two source codes to display the difference. The variable dependency relationship analysis unit 15 analyzes the variable dependency relationship between the two source codes. The variable dependency comparison unit 201 compares the variable dependency of two source codes by the variable dependency analysis unit 15. Each node of the variable dependency relationship data has a difference presence / absence item, and it is assumed that the value is “difference / no difference / undefined (initial value)”. The variable dependency comparison unit 201 sets a value in the presence / absence of the difference from the comparison result. The variable dependency relationship output unit 16 adds a difference in the variable dependency of the two source codes compared by the variable dependency relationship comparison unit 201, that is, colors the difference presence / absence item to a node having “difference”. Etc. to display.

  The variable dependency relationship data compared by the variable dependency comparison unit 201 includes the description position of the variable. However, when comparing the variable dependency relationship between two source codes, the description position of the variable is ignored. On the other hand, when displaying the variable dependency, the variable description position is displayed.

  FIG. 21 shows a processing flow executed by the variable dependency comparison unit 201 for comparing the variable dependency of two source codes. Here, for simplicity, it is assumed that there is one root node for variable dependency in each source code. The flow starts from process 1. In step 211, the variable dependency comparison unit 201 extracts root nodes of the variable dependency relationships of the two source codes. One root node is “node 1”, and the other root node is “node 2”. In step 212, the variable dependency comparison unit 201 compares the entities of the node 1 and the node 2. If the entities are the same, the process proceeds to step 213, and if they are different, the process proceeds to step 215. In step 213, process 2 is called with node 1 and node 2 as arguments. In step 214, regarding the subordinate node of node 2, the node for which the difference presence / absence item is “indeterminate” is set to “difference”, and the process 1 ends. In step 215, it is determined that there is a difference between all the nodes of the two variable dependencies, and the process 1 is terminated.

  Next, process 2 will be described. The formal argument of process 2 is also assumed to be node 1 and node 2. Steps 216 to 220 are performed for all the child nodes of node 1, and are not performed if there are no child nodes. In step 216, the variable dependency comparison unit 201 starts from the lower node of node 2, the child node of node 1 has the same entity and def / use type, and the variable presence / absence item is “unconfirmed”. Search for a node. In step 217, if the corresponding node exists in step 216, the process proceeds to step 218, and if not, the process proceeds to step 219. In step 218, the variable dependency comparison unit 201 determines a difference in variable dependency. The child node of the node 1 currently being processed is designated as the node 1 ′, the node searched at the step 215 is designated as the node 2 ′, and it is determined that there is no difference between the node 1 ′ and the node 2 ′. When there is a node between the node 2 and the node 2 ′, it is determined that there is a difference between the nodes. After the determination, the process proceeds to step 220. In step 219, the variable dependency comparison unit 201 determines that there is a difference between the child nodes of the node 1 that is currently being processed. Further, the child node is designated as the node 1 ′ and the node 2 is designated as the node 2 ′. In step 220, process 2 is called with node 1 'and node 2' as arguments. The process 2 has a recursive structure, and when all the processes 2 are completed, the process 2 returns to the process 1 and the process 1 is terminated.

  FIG. 22 shows an example in which the variable dependency comparison unit 201 analyzes the difference between two variable dependencies along the processing flow of FIG. 21 and displays the variable dependency output unit 16 for two sample source codes. . The source code 221 and the source code 222 describe a function f7, which is a first version and a second version, respectively. The variable dependency relationship 223 is a directed graph of data derived from the source code 221 and the variable dependency relationship 224 is derived from the source code 222 as the execution start point f7. From the source code 221 to the source code 222, the fifth line is changed from c = b to c + = b. The variable dependency comparison unit 201 determines that there is a difference in c (L5 @ f7) use of the variable dependency relationship 224, and there is no difference between the other nodes of the variable dependency relationship 224 and all the nodes of the variable dependency relationship 223. Is determined. The variable dependency relationship output unit 16 displays c (L5 @ f7) use of the variable dependency relationship 224 with a color different from that of other nodes, and displays the difference of the variable dependency to the user so that it can be easily distinguished visually. To do.

  FIG. 23 shows an example in which two sample source codes different from FIG. 22 are analyzed and displayed in the same manner as FIG. The source code 231 and the source code 232 describe the function f8, which is the first version and the second version, respectively. The variable dependency relationship 233 is a directed graph of data derived from the source code 231 and the variable dependency relationship 234 is derived from the source code 232 with the execution start point as f8. In the source code 232, a blank line is inserted in the sixth line with respect to the source code 231. With this change, c (L6 @ f8) and d (L6 @ f8) of the variable dependency relationship 233 are changed to c (L7 @ f8) and d (L7 @ f8) in the variable dependency relationship 234. Yes. However, the variable dependency comparison unit 201 determines that there is no difference for all the nodes of the two variable dependency relationships 233 and 234. Actually, there is no difference in processing contents between the source code 231 and the source code 232. This is because there is no difference other than the variable position information in the variable dependency relations 233 and 234, so that the user can easily understand visually. Yes.

  As described above, by extracting the variable dependency from the two source code, ignoring the position information of the variable and comparing and displaying the difference, the difference in the software configuration and processing outline can be seen from the viewpoint of the variable dependency. Can be provided to the user. This makes it easy for the designer and verifier to understand the software structure and processing outline.

[Example 4]
In this embodiment, source code slicing and model checking are performed using the variable dependency analysis result of the present invention. Since the variable dependency analysis method is the same as in the first to third embodiments, the description thereof is omitted. Slicing means a process of extracting only the description of the source code that affects a certain variable and deleting the description of the source code that does not affect the variable. Model checking can be taken when the software to be verified actually operates (in the case of control software that controls the device, the hardware that operates the software or the combined operation with the device to be controlled is assumed) It means that the state is exhaustively searched and a defect is found.

  In slicing, it is necessary to specify a statement that is a starting point of extraction, a statement that is an end point, and variables in the statement as “slicing criteria”.

  In this embodiment, as a slicing criterion, the variable selected by the variable selection unit 122 by the user and the statement including the variable are the end points, among the variable dependency relationships displayed by the variable dependency output unit 16, by the end or the user. Set the statement containing the selected variable as the starting point and perform slicing. As a result, the variable that the user wants to verify (hereinafter referred to as “verification point”) is specified by the variable selection unit 122, so that the source code to be model-checked can be narrowed down only to the portion related to the verification point. It can avoid the explosion of the state during model checking. In addition, since the user can select a statement having a dependency relationship with the statement at the end point as the start point, it is possible to reliably extract the code related to the verification point. In addition, since the variable selected as the starting point on the display of the variable dependency output unit 16 becomes a boundary between software and the external environment (hardware, control target device, etc.) at the time of model checking, This makes it easy to create a model for the external environment and select from existing models.

  FIG. 26 shows an example in which slicing according to the present invention is performed on a sample code. The source code output unit 17 displays the source code 261. At this stage, no variable is selected by the variable selection unit 122, and slicing is not performed.

  Next, when the variable c is selected by the user in the variable selection unit 122, the variable dependency relationship output unit 16 displays the variable dependency relationship 264, and the source code output unit 17 displays the source code 262. In the source code 262, y = x in the fifth line and z = y in the seventh line are hatched. This indicates that the variables x, y, and z are not included in the variable dependency 264, and thus are codes excluded by slicing. At this stage, when the user instructs the source code output unit 17 to output a file, the source code from which the fifth and seventh lines are deleted is output as a file.

  In the display of the source code 262 and the file output of the sliced source code, the syntax tree data by the syntax analysis unit 12 is used. For each syntax node of the syntax tree data, the source code output unit 17 determines that the syntax remains by slicing if the variable included in the syntax is included in the variable dependency 264, and is excluded if the variable is not included.

  Next, in the variable dependency relationship output unit 16, the user designates b (L4 @ f9) to be excluded by slicing. Then, in the display of the variable dependency relationship output unit 16, b (L4 @ f9) and its lower a (L4 @ f9) are excluded as in the variable dependency relationship 265. In the source code output unit 17, the source code 263 is displayed. In the source code 263, b = a in the fourth line is further deleted. This shows the influence of the exclusion designation of b (L4 @ f9) by the user. In this case, b (L9 @ f9) is selected as a starting point variable for slicing. When the user instructs the source code output unit 17 to output a file at this stage, the source code from which the fourth, fifth, and seventh lines are deleted is output as a file.

  For the source code extracted as described above, the source code output unit 17 converts it into a language for model checking using syntax tree data and a specified conversion rule if necessary, and inputs it to the model checker. By doing so, the possible states when the source code related to the verification point operates are exhaustively searched. For the model checker, the user can specify a state that should not be taken by the source code to be checked as a property or assertion, and if necessary, can find a problem by assigning an external environment model.

11 File input unit 12 Syntax analysis unit 13 Function extraction unit 14 Execution start point selection unit 15 Variable dependency analysis unit 16 Variable dependency output unit 17 Source code output unit 123 Variable dependency extraction unit 201 Variable dependency comparison unit

Claims (12)

In a software structure visualization program for causing a computer to input software source code, analyzing the source code, and outputting an analysis result,
The program includes a syntax analysis unit for causing the computer to execute syntax analysis of the source code;
A variable dependency analysis unit for deriving a dependency relationship between variables for a plurality of variables distinguished for each description position in the source code from a result of the syntax analysis by the syntax analysis unit;
A variable dependency relationship derived by the variable dependency relationship analyzing unit, together with description position information in the source code of the plurality of variables, for causing the computer to display on a display device or to output to the outside of the computer A software structure visualization program comprising: a variable dependency output unit. A source code output unit for displaying the source code input to the computer on a display device;
The source code output unit causes the computer to highlight a description in the source code corresponding to a variable specified by a user in the variable dependency displayed or output by the variable dependency output unit. The software structure visualization program according to claim 1. A variable extraction unit that causes the computer to extract a variable included in the source code based on a result of the syntax analysis by the syntax analysis unit;
Displaying a variable attribute extracted by the variable extraction unit on the computer and accepting a user variable selection;
A variable dependency extraction unit that causes the computer to extract a variable dependency having a variable selected by the user in the variable display unit as a root from the variable dependency derived by the variable dependency analysis unit; ,
The software structure visualization program according to claim 1, wherein the variable dependency relationship output unit causes the computer to display or output the variable dependency relationship extracted by the variable dependency relationship extraction unit. The variable dependency extraction unit is a variable dependency whose root is a variable that is defined and has the same entity as the variable that is referenced and included in the variable dependency extracted by the variable selected by the user in the variable display unit. A relationship is extracted by the computer from the variable dependency derived by the variable dependency analysis unit;
The software structure visualization program according to claim 3. In claim 3,
4. The software structure visualization program according to claim 3, wherein the variable display unit causes the computer to display or output the number of execution paths of each variable.   The software structure visualization program according to claim 1, wherein the variable dependency relationship analysis unit causes the computer to analyze a syntax tree by the syntax analysis unit from an execution start point input by a user.   4. The software structure visualization program according to claim 3, wherein the variable dependency relationship output unit displays or outputs the variable dependency relationship in a tree format on the computer.   The variable dependency relationship extraction unit has a variable dependency that is different in substance from the variable selected by the user and exists in a different execution path and affects the variable selected by the user only at a specific processing timing. The structure visualization program according to claim 3, wherein the structure is extracted by the computer.   2. The structure according to claim 1, further comprising: a variable dependency comparison unit that causes the computer to compare the result of analyzing the variable dependency of each of the plurality of source codes by the variable dependency relationship analysis unit and determine a difference. Visualization program.   The structure visualization program according to claim 6, wherein the computer is caused to perform slicing on a portion of the source code that does not affect the execution start point based on an analysis result by the variable dependency analysis unit.   11. The structure visualization program according to claim 10, wherein model verification of the sliced source code is performed.   A storage medium storing the structure visualization program according to any one of claims 1 to 11, comprising a computer that executes the structure visualization program, an input device that receives input from a user, and an output from the computer And a structure visualizing system.