Source code inspection device

The present invention relates to techniques for assisting the analysis of computer programs, in particular the analysis of source code.

Business systems that support the operation of companies and public facilities, so-called enterprise systems, are now being introduced as the foundation of organizations of various sizes. The business system aggregates, accumulates, analyzes, and processes data obtained from node terminals and databases, and then outputs higher value-added information. The number of program files that make up a business system can reach hundreds of thousands, sometimes millions. Business systems continue to evolve to make complex organizational management more efficient.<patcit num="1"><text>JP-A-2007-156791</text></patcit>

<p> Business systems require source code inspection and correction not only during development but also during maintenance work and reconstruction. In particular, in the modification of the source code, the work for identifying the part to be modified from the huge amount of source code is more burdensome than the modification work itself.</p><p> In addition, in the development of large-scale business systems involving multiple programmers, coding rules are often established. For example, if the naming of functions and variables, the way of writing comments, etc. are unified, the readability of the source code can be improved and correction mistakes can be prevented. However, the current situation is that compliance with coding rules depends on the programmer's awareness of legal compliance.</p><p> The present invention is an invention completed based on the above-mentioned problem recognition by the present inventor, and a main object thereof is to provide a technique for supporting efficient analysis of source code.</p>

<p> One aspect of the present invention relates to a source code inspection device. This device obtains the source code, extracts the nodes corresponding to the components of the source code, and structures the nodes according to the arrangement of the components, so that the logical structure of the source code is shown by a set of nodes. Generate a model. Then, each node in the syntax model is scanned to identify a part of the source code component that matches the preset detection conditions, and an annotation node is set.</p><p> Any combination of the components shown above, and a representation of the present invention by a method, a system, a recording medium, or a computer program are also effective as aspects of the present invention.</p>

<p> According to the present invention, it becomes easy to efficiently analyze the source code.</p>

FIG. 1 is a schematic diagram showing the language conversion process of the source code. In this embodiment, the process of converting the source code written in Hitachi COBOL (hereinafter referred to as "Hitachi Source 200") into the source code written in IBM / COBOL (hereinafter referred to as "IBM Source 202"). Will be described as an example.

There are three main functions for realizing language conversion of source code, which are called parser, processor, and writer, respectively. Each function is in charge of analysis processing, conversion processing, and generation processing. Analysis process (S1): First, Hitachi Source 200 is acquired as the first source code, the parser parses it, and the abstract syntax tree as the first syntax model (hereinafter, "AST (Abstract Syntax)"). Tree) ) is generated. AST is formed as a tree structure in which nodes are associated with components of source code such as operators and their operands. AST can be generated by applying existing technologies used in general compilers and interpreters. The source code that is the conversion source like Hitachi Source 200 is the "conversion source", the AST generated from the conversion source is the "conversion source AST", and the nodes included in the conversion source AST are the "basic nodes" or " It is called "conversion source node". The conversion source AST may be an AST corresponding to the language structure of the conversion source source, or may be an AST as a standard model corresponding to another programming language, for example, a standard COBOL language structure. The analysis process will be described in detail in relation to FIG.

Conversion process (S2): The processor converts the conversion source AST to an AST corresponding to IBM source 202 as the second source code. The source code that is the conversion destination like IBM source 202 is called "conversion destination source", the AST generated for the conversion destination source is called "conversion destination AST", and the nodes included in the conversion destination AST are called "conversion destination node". Call. The destination AST as the second syntax model corresponds to the language structure of the destination source. The conversion process will be described in detail in relation to FIGS. 3 and 4.

Generation process (S3): The writer generates IBM source 202, which is the conversion destination source, from the conversion destination AST. The generation process will be described in detail in relation to FIG. As shown above, the conversion source AST is generated from the conversion source source Hitachi source 200, the conversion destination AST is generated from the conversion source AST, and the conversion destination source IBM source 202 is generated from the conversion destination AST. Converts Hitachi Source 200 to IBM Source 202.

To realize the language conversion process, 1. To generate the conversion source AST from the conversion source source (hereinafter referred to as the "1st AST rule"), 2. To generate the conversion destination AST from the conversion source AST. Rule (hereinafter referred to as "second AST rule") and 3. Rule for generating conversion destination source from conversion destination AST (hereinafter referred to as "source generation rule") are required. By providing these rules for various programming languages as a library, language conversion processing between various programming languages can be realized.

FIG. 2 is a functional block diagram of the source code processing device 100. Each block shown here can be realized by elements such as the CPU of a computer or a mechanical device in terms of hardware, and can be realized by a computer program or the like in terms of software, but here, it is realized by cooperation between them. The functional block is drawn. Therefore, it is understood by those skilled in the art that these functional blocks can be realized in various forms by combining hardware and software. The source code processing device 100 is a device that functions as a parser, a processor, and a writer shown in FIG. In this embodiment, the main function of the source code processing apparatus 100 will be described as being realized as software on a computer. More specifically, each function of the source code processing device 100 in this embodiment is mainly described by JAVA (registered trademark) or Scala, and is realized by a computer program executed on a JVM (Java Virtual Machine). ..

The source code processing device 100 includes a UI (user interface) unit 110, a data processing unit 120, and a data holding unit 140. The UI unit 110 is in charge of user interface processing. The data processing unit 120 executes various data processing based on the data acquired from the UI unit 110 and the data holding unit 140. The data processing unit 120 also serves as an interface between the UI unit 110 and the data holding unit 140. The data holding unit 140 is a storage area for holding various types of data.

UI part 110: The UI unit 110 includes an input unit 112 and an output unit 116. The input unit 112 detects various inputs of the user and acquires data such as a file from an external device. The output unit 116 displays various information and transmits data such as a file to an external device. The input unit 112 includes a code acquisition unit 114. The code acquisition unit 114 acquires a conversion source such as the Hitachi source 200 in FIG. The output unit 116 includes a code output unit 118. The code output unit 118 outputs a conversion destination source such as the IBM source 202 in FIG.

Data processing unit 120: The data processing unit 120 includes a first syntax model generation unit 122, a second syntax model generation unit 124, a code generation unit 126, an inspection unit 128, and an annotation node setting unit 130. The first syntax model generator 122 includes the first AST rule 152. The first syntax model generation unit 122 generates the conversion source AST from the conversion source source with reference to the first AST rule 152. The second syntax model generator 124 includes the second AST rule 154. The second syntax model generation unit 124 generates the conversion destination AST from the conversion source AST with reference to the second AST rule 154. The code generation unit 126 includes the source generation rule 156. The code generation unit 126 refers to the source generation rule 156 and generates the conversion destination source from the conversion destination AST.

The inspection unit 128 scans the node of the conversion source AST or the conversion destination AST to identify a portion that matches a predetermined detection condition. Inspection unit 128 includes coding rule 158. All or part of the detection conditions are defined as coding rule 158. The detection conditions will be described in detail in connection with FIG. 5 and after. The annotation node setting unit 130 sets the "annotation node" in AST when a part that matches the detection condition is detected. The annotation node setting unit 130 includes an annotation node setting rule 160. Annotation node setting rule 160 associates a detection condition with an annotation node. What kind of annotation node should be set when a part that matches a certain detection condition is detected is set in this annotation node setting rule 160. The details of the annotation node setting will be described in detail in reference to FIG. 6 and after. Detection conditions and annotation nodes are introduced to determine whether the AST is subject to the prescribed coding rules and whether there are any programming structurally inappropriate descriptions.

Data holding unit 140: The data holding unit 140 includes a first syntax model holding unit 142 and a second syntax model holding unit 144. The first syntax model holding unit 142 holds the conversion source AST generated by the first syntax model generating unit 122. The second syntax model holding unit 144 holds the conversion destination AST generated by the second syntax model generation unit 124.

The analysis process (S1), that is, the function as a parser is mainly realized by the input unit 112 and the first syntax model generation unit 122. The conversion process (S2), that is, the function as a processor is mainly realized by the second syntax model generator 124. The generation process (S3), that is, the function as a writer is mainly realized by the code generation unit 126 and the output unit 116.

The source code processing device 100 has a function as a "source code conversion device" that converts a source source into a language of a conversion destination source, and also a "source code" that inspects the description contents of the source code by setting detection conditions. It also has a function as an "inspection device". Hereinafter, the function as a "source code conversion device" and the function as a "source code inspection device" will be described separately.

[Function as a source code converter] FIG. 3 is a schematic diagram for explaining the process of generating the conversion source AST from Hitachi Source 200. The Hitachi Source 200 shown in the figure compares the variable "A" and the variable "B", and when the condition "A and B are both 1" is satisfied, the character string "Y" is set in the variable "FLAG". However, in other cases, the variable "FLAG" is set to the character string "N". The syntax "EVALUATE AB" on the first line indicates the processing content that "A" and "B" are to be compared.

When the code acquisition unit 114 acquires the Hitachi source 200, the first syntax model generation unit 122 first acquires the syntax "EVALUATE AB". The components of this syntax are "EVALUATE", "A", and "B". First, the first syntax model generation unit 122 sets the conversion source node EvaluateStatement206 corresponding to "EVALUATE" and sets the conversion node EvaluateTagList208 corresponding to the variable list declaration of "EVALUATE" based on the first AST rule. A component is a statement such as a variable, a constant, a declaration, or a function described in the source code, and a node is an element of AST associated with those components. Some nodes, such as EvaluateStatement206, are set corresponding to the components explicitly described in the source code, while others, such as EvaluateTagList208, accompany other nodes such as EvaluateStatement206. Some nodes are set up.

Two nodes, Expression: "A" 210 and Expression: "B" 212, are set as child nodes of EvaluateTagList208, corresponding to the arguments "A" and "B" of "EVALUATE". Furthermore, a node "None214" for indicating the juxtaposition of the arguments "A" and "B" is also set. In Hitachi Source 200, arguments can be written side by side like "EVALUATE AB", but in IBM Source 202, "EVALUATE A ALSO" A component called "ALSO" is described between the arguments "A" and "B" like "B". When generating the conversion source AST204 from Hitachi Source 200, not only Expression: "A" 210 and Expression: "B" 212, but also a node called None214 is set. More specifically, for the expression "EVALUATE", EvaluateStatement206, EvaluateTagList208, and the node corresponding to the argument and the node for connecting the argument (None214) are associated with each other in the first AST rule. The first syntax model generator 122 assembles an appropriate conversion source node corresponding to the expression "EVALUATE" according to this first AST rule. If the conversion source AST204 is a standard and unified syntax model, if the first AST rule is prepared for each programming language of the conversion source source, the conversion source AST204 as a standard syntax model can be obtained from any conversion source source. Can be generated.

FIG. 4 is a schematic diagram for explaining the process of generating the conversion destination AST and the IBM source 202 from the conversion source AST. First, the second syntax model generation unit 124 generates the conversion destination AST220 from the conversion source AST204. In IBM source 202, which is the conversion destination source, the argument of "EVALUATE" is connected by the component "ALSO" like "EVALUATE A ALSO B". Therefore, the second syntax model generation unit 124 converts the conversion source node None214 of the conversion source AST204 to the conversion destination node ALSO222. The association between the conversion source node and the conversion destination node is set as the second AST rule for each programming language. The second syntax model generator 124 generates the conversion destination AST220 from the conversion source AST204 according to this second AST rule. If the conversion source AST204 has a standard and unified syntax model, it is possible to convert to an arbitrary conversion destination AST by preparing a second AST rule for each programming language of the conversion destination source.

The code generation unit 126 identifies the corresponding component of the IBM source 202 for each conversion destination node, and assembles the specified component according to the structure of the conversion destination AST220. Such rules are defined as source generation rules. In this way, the IBM source 202 containing the ALSO representation is generated from the Hitachi source 200 that does not contain the ALSO representation. As a result, Hitachi Source 200 can be analyzed by the analysis tool for IBM / COBOL.

The basic idea is the same when IBM source 202 is the conversion source source and Hitachi source 200 is the conversion destination source. When creating the conversion source AST from IBM source 202, set the node "ALSO222" from the component "ALSO". When converting the conversion source AST to the conversion destination AST for Hitachi COBOL, ALSO222 is converted to None214. Alternatively, the node corresponding to ALSO222 may not be set in the conversion destination AST. In any case, the node corresponding to ALSO222 may be invalidated in the conversion destination AST. The code generation unit 126 does not describe the components corresponding to None 214 in the Hitachi source 200. By such a processing method, "EVALUATE A ALSO B" of IBM source 202 will be expressed as "EVALUATE A B" in Hitachi source 200. Here, the presence or absence of ALSO222 is mentioned as an example of the difference between Hitachi Source 200 and IBM Source 202, but the 1st AST rule, 2nd AST rule, and source generation rule are properly defined for the differences between various other languages. By doing so, conversion becomes possible.

[Function as a source code inspection device] Figure 5 shows the AST generated from the variable declaration statement "int num, iNumber". The AST to be inspected may be the conversion source AST or the conversion destination AST. Here, it is described that the inspection is executed for the conversion source AST. The content of the inspection can be set arbitrarily by the user. For example, suppose that the following coding rules are set for the development and maintenance of business systems. R1.int type variable names must start with the letter "i" R2. In variable declaration, do not define multiple variables in one type declaration R3. Variable name must be 4 characters or more

The establishment of coding rules is important for improving the readability of source code and preventing correction mistakes. In particular, it is important to establish appropriate coding rules in the development of large-scale business systems involving multiple software engineers.

In the declaration statement "int num, iNumber" in the figure, the variable "num" does not satisfy the above rule R1 because its first character is "n". Also, since two variables "num" and "iNumber" are defined together in one int type declaration, rule R2 is not satisfied either. Furthermore, since the variable "num" has only 3 characters, it does not satisfy rule R3. The source code processing device 100 can inspect whether the coding rules are actually followed and where the coding rules are not followed.

AST230 shown in the figure corresponds to the declaration statement "int num, iNumber". When the first syntax model generator 122 encounters the variable declaration statement, it first sets LocalVariableDeclaration232 to AST230 based on the first AST rule. IntType234, which is a node indicating an int type, and VariableDeclarators236, which is a node indicating a variable list, are set as child nodes. VariableDeclarator238 and Identifier: "num" 240, VariableDeclarator242 and Identifier: "iNumber" 244 are set for the variable "num" and the variable "iNumber", respectively.

FIG. 6 is a diagram showing the AST 230 in which the annotation node is set according to the rule R1. The above-mentioned rules R1 to R3 are set as detection conditions in the inspection unit 128. The inspection unit 128 first searches the AST230 for a variable node that violates rule R1 "variable names of int type start with the character" i "". When the inspection unit 128 scans AST230 and finds IntType234, it searches for an identifier node among the child nodes of its parent node, LocalVariableDeclaration232, and checks the variable name. The variable "num" violates rule R1. The annotation node setting unit 130 sets the annotation node 250 in Identifier: "num" 240.

Finally, the annotation node setting unit 130 collects the annotation nodes 250 in the AST 230, lists them, and outputs them to the output unit 116. Further, the code generation unit 126 may generate the source code from the AST 230 including the annotation node 250. The code generation unit 126 may add a comment indicating the content of the annotation to the corresponding portion of the annotation node 250 in the source code.

FIG. 7 is a diagram further showing AST230 when the annotation node is set corresponding to the rules R2 and R3. The inspection unit 128 then searches for a part that violates rule R2 "in a variable declaration, do not define multiple variables in one type declaration". When the inspection unit 128 scans AST230 and finds LocalVariableDeclaration232, it searches for an identifier node among its child nodes and checks the number of declared variables. The statement "int num, iNumber" violates rule R2. The annotation node setting unit 130 sets the annotation node 254 in Variable Declarators 236.

The inspection unit 128 searches for a part that violates the rule R3 "variable name must be 4 characters or more". When the inspection unit 128 scans AST230 and finds LocalVariableDeclaration232, it searches for an identifier node among its child nodes and checks the number of characters of the declared variable. Since the variable "num" violates rule R3, the annotation node setting unit 130 sets the annotation node 252 in Identifier: "num" 240.

The detection conditions are not limited to the conditions related to the coding rules. For example, a condition that should be satisfied as the structure of a computer program may be set as a detection condition. Two examples are shown below.

Example 1. Checking the statements that appear at the beginning and end of a particular process For example, in C ++, the "new" operator dynamically allocates memory. The operator that frees memory is "delete". The memory allocated by the new operator must be released by delete after use. Also, after opening a file descriptor with the "open" operator, the file descriptor must be closed with the "close" operator. As described above, before and after a specific process such as "dynamic allocation of memory" or "use of file descriptor", predetermined statements must be described as a pair. Hereinafter, components such as new and open that should be described at the start of a specific process are referred to as "start elements", and components that should be described at the end are referred to as "end elements". The number of start and end elements should be the same in one source file. If the node corresponding to the start element is called the "leading node" and the node corresponding to the ending element is called the "terminating node", the number of leading nodes and the number of terminating nodes should be the same in AST. From this point of view, the source code processing device 100 may inspect for defects in the program structure based on the front node and the end node.

Here, open is described as a start element and close is described as a terminal element. First, the inspection unit 128 scans the AST, and when it detects a tip node corresponding to open, it increments the number of tip nodes. Also, when a terminal node corresponding to close is detected, the number of terminal nodes is incremented. When scanning all the nodes of the AST, if the number of leading nodes and the number of ending nodes are not the same, there may be a defect in the source code description. When the number of leading nodes is greater than the number of terminating nodes, there may be file descriptors that are open and not closed. In such a case, the annotation node setting unit 130 sets an annotation node to warn that fact.

Example 2. Checking the range of overrides Suppose you define its member function method1 () in a class A. ClassB, which inherits this class, can provide the member function method1 () of classA as its own member function without defining its own member function method1 (). So to speak, classB borrows a member function of classA. The processing content executed when classA.method1 () is called is exactly the same as the processing content executed when classB.method1 () is called. Therefore, if the content of method1 () defined in classA is modified, not only classA.method1 () but also the behavior of classB.method1 () will change.

On the other hand, in classB, method1 () with the same name may be redefined independently. This is called an override. In this case, the processing content executed when classA.method1 () is called is defined by method1 () of classA, and the processing content executed when classB.method1 () is called is defined by method1 () of classB. Defined. While classA and classB provide the interface method1 () with the same name, the processing contents can be different between classA and classB. The programming technique called override is often used when the processing contents of method1 () of classB and method1 () of classA are almost the same but slightly different.

If method1 () is redefined in classB, that is, it is overridden, if the contents of classA.method1 () are modified, the behavior of classA.method1 () will naturally change, but the behavior of classB.method1 () will change. It does not change. If you want to change classB.method1 () along with the modification of the content of classA.method1 (), you need to remember to make the same modification to classB.method1 (). From this point of view, the source code processing device 100 supports the source code analysis by identifying the overridden part of the member function of each class.

Specifically, the inspection unit 128 first identifies a subclass group that inherits class A, and searches for member functions defined in these subclasses. Then, specify the member function named method1 () from this. If method1 () is defined in a subclass of classA, you can see that it is overridden here. The annotation node setting unit 130 sets the annotation node at the corresponding location. When you modify method1 () of classA, you can identify the location of the member function that may need to be modified by checking the annotation node set in this way.

The annotation node setting unit 130 finally lists the annotation node group. The list preferably includes information indicating the location of the annotation node, such as the content of the annotation node, the source file name to which the annotation node belongs, the line number, the column position, the line text, and the parent node name. From this list of annotation nodes, the user can grasp the parts to be focused on from the huge amount of source code, which facilitates the development and maintenance of the source code.

The source code processing apparatus 100 has been described above based on the examples. If the source code processing device 100 prepares the "1st AST rule", the "2nd AST rule", and the "source generation rule", the source code written in various programming languages can be converted into the source code written in another programming language. Can be converted to. Therefore, it becomes easy to apply various analysis tools to a business system in which various programming languages are mixed. Since it is a conversion between ASTs that reflects the logical structure of the source code rather than directly converting the source codes, it is easy to reflect the logical structure of the conversion source source in the conversion destination source.

In addition, the source code can be easily analyzed by identifying the relevant part from the AST according to the detection conditions and setting the annotation code. Since it is not a text search of the source code but an inspection targeting the AST that reflects the logical structure of the source code, there is a possibility that there is a coding rule violation or a coding error in the huge amount of source code. It will be easier to find the location accurately.

The present invention has been described above based on examples. Embodiments are examples, and it will be understood by those skilled in the art that various modifications are possible for each of these components and combinations of each processing process, and that such modifications are also within the scope of the present invention. ..

<figref num="1">It is a schematic diagram which shows the language conversion process of a source code.</figref><figref num="2">It is a functional block diagram of a source code processing apparatus.</figref><figref num="3">It is a schematic diagram for demonstrating the process of generating the conversion source AST from Hitachi source.</figref><figref num="4">It is a schematic diagram for demonstrating the process of generating the conversion destination AST and the IBM source from the conversion source AST.</figref><figref num="5">It is a figure which shows the AST generated from the variable declaration statement "int num, iNumber".</figref><figref num="6">It is a figure which shows the AST which the annotation node was set corresponding to the rule R1.</figref><figref num="7">Furthermore, it is a figure which shows the AST when the annotation node is set corresponding to the rule R2 and R3.</figref>

Code description

100 Source code processor, 110 UI, 112 Input, 114 Code acquisition, 116 Output, 118 Code output, 120 Data processing, 122 1st syntax model generator, 124 2nd syntax model generator, 126 Code generation part, 128 inspection part, 130 annotation node setting part, 140 data holding part, 142 first syntax model holding part, 144 second syntax model holding part, 200 Hitachi source, 202 IBM source, 204 conversion source AST, 220 conversion Destination AST.