JP2012033017A - Rule inspection device, rule inspection method and rule inspection program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To perform an inspection of a framework rule, targeting a whole system.SOLUTION: A rule inspection device comprises an analysis section and a framework inspection section. The analysis section analyzes the relations between a plurality of programs used for the generation of a business application and a general-purpose application etc. The framework inspection section inspects whether the relations between the plurality of programs analyzed by the analysis section represents the relations based on the framework rule as the specification rule of a framework.

Description

  The present invention relates to a rule inspection device, a rule inspection method, and a rule inspection program.

  Conventionally, in the development of software, development using a framework is performed for the purpose of improving work efficiency and maintaining the quality of program source code. The framework is a framework such as a program source code or a part usage rule that is used as standard in software development. For example, the framework includes Java (registered trademark), VB. Each NET includes a database access framework, a screen operation description framework, a form processing framework, and the like.

  Here, in software development, quality diagnosis is performed in order to improve software quality. For example, a program inspection system is known as a tool used for software quality diagnosis. The program inspection system inspects whether the program source code created by the designer is created according to a specific scheme design. The specific system design is, for example, a grammar or a rule defined for each program language used for creating a program source code.

  Further, the program inspection system inspects whether or not the program source code included in the software is created according to the framework rule by inspecting the call destination or inheritance source of the program source code.

Japanese Patent No. 3360635 JP 2005-056183 A JP 2009-99111 A

  However, in the above-described conventional technology, it is difficult to inspect the framework rules for the entire system. Specifically, in the conventional technology described above, since the inspection is based on a single program, it is difficult to inspect the framework rules for the entire system.

  In view of the above-described problems of the related art, the technology of the present disclosure provides a rule inspection device, a rule inspection method, and a rule inspection program that enable inspection of framework rules for the entire system. For the purpose.

  In order to solve the above-described problems and achieve the object, the disclosed apparatus includes an analysis unit and a framework inspection unit. The analysis unit analyzes a relationship between a plurality of programs used for creating an application. The framework inspection unit inspects whether or not the relationship between the plurality of programs analyzed by the analysis unit is a relationship in accordance with a framework rule that is a framework specification rule.

  The disclosed apparatus makes it possible to inspect framework rules for the entire system.

FIG. 1 is a diagram for explaining the configuration of the program rule inspection apparatus according to the first embodiment. FIG. 2 is a diagram for explaining an example of management data stored in the analysis data storage unit. FIG. 3 is a diagram for explaining an example of the class analysis result stored by the analysis data storage unit. FIG. 4 is a diagram for explaining an example of a method analysis result stored by the analysis data storage unit. FIG. 5 is a diagram for explaining an example of the instance analysis result stored by the analysis data storage unit. FIG. 6 is a diagram for explaining an example of a method call analysis result stored by the analysis data storage unit. FIG. 7A is a diagram for explaining an example (1) of the program source code relating to the screen processing. FIG. 7B is a diagram for explaining an example (2) of the program source code regarding the screen processing. FIG. 8A is a schematic diagram illustrating an example (1) of a program source code related to business processing. FIG. 8-2 is a diagram for explaining an example (2) of the program source code related to the business process. FIG. 8C is a diagram for explaining an example (3) of the program source code related to the business process. FIG. 9A is a schematic diagram illustrating an example (1) of a program source code related to database processing. FIG. 9-2 is a diagram for explaining an example (2) of the program source code relating to the database processing. FIG. 10A is a diagram for explaining an example (1) of the program check rule used for the inspection related to the program mounting method. FIG. 10-2 is a diagram for explaining an example (2) of the program check rule used for the inspection related to the program mounting method. FIG. 11 is a diagram for explaining an example of a program check rule used for a check relating to program inheritance. FIG. 12 is a diagram for explaining an example of the program check rule used for the inspection related to the program calling method. FIG. 13A is a diagram for explaining an example (1) of a framework rule regarding the calling order of programs. FIG. 13-2 is a diagram for explaining an example (2) of the framework rule regarding the calling order of programs. FIG. 13C is a diagram for explaining an example (3) of a framework rule regarding the calling order of programs. FIG. 14A is a diagram for explaining an example (1) of the inspection result report. FIG. 14-2 is a diagram for explaining an example (2) of the inspection result report. FIG. 15 is a flowchart for explaining the procedure of the program pre-analysis process performed by the program rule inspection apparatus according to the first embodiment. FIG. 16 is a flowchart for explaining the procedure of the process performed by the program rule inspection apparatus according to the first embodiment. FIG. 17 is a flowchart for explaining the procedure of the framework inspection process performed by the program rule inspection apparatus according to the first embodiment. FIG. 18 is a diagram schematically illustrating an example of a framework inspection performed by the program rule inspection apparatus according to the first embodiment. FIG. 19A is a diagram for explaining an example (1) of a framework rule regarding the processing order of a program. FIG. 19-2 is a diagram for explaining an example (2) of the framework rule regarding the processing order of the program. FIG. 20 is a flowchart for explaining the procedure of the framework inspection process performed by the program rule inspection apparatus according to the second embodiment. FIG. 21 is a diagram schematically illustrating an example of a framework inspection performed by the program rule inspection apparatus according to the second embodiment. FIG. 22-1 is a diagram for explaining a modification (1) of the inspection result report. FIG. 22-2 is a diagram for explaining a modification (2) of the inspection result report. FIG. 23 is a diagram for explaining a computer that executes a rule inspection program.

  Hereinafter, embodiments of a rule inspection device, a rule inspection method, and a rule inspection program disclosed in the present application will be described in detail with reference to the accompanying drawings. The rule inspection device, the rule inspection method, and the rule inspection program disclosed in the present application are not limited to the following embodiments.

  The program rule inspection apparatus according to the first embodiment inspects a framework rule for the entire system in an application based on a relationship between a plurality of programs used for generating an application. The application referred to here is, for example, a business application uniquely developed according to a request from a company or the like, or a general-purpose application such as general text creation software or spreadsheet software. The inspection of the framework rules for the entire system is, for example, program call relationship or inheritance relationship, or compatibility of commonly used parts usage methods.

  Specifically, the program rule inspection apparatus according to the first embodiment analyzes in advance the relationship between a plurality of programs used for generating an application. Then, the program rule inspection apparatus according to the first embodiment uses a relationship between a plurality of programs analyzed in advance as an inspection target, and adapts a calling method or inheritance relationship of each program or a commonly used method of using parts. It is inspected whether or not the property conforms to the framework rules that are the framework specification rules. Therefore, the program rule inspection apparatus according to the first embodiment can determine whether or not processing across multiple hierarchies such as a screen processing program, a business processing program, and a database processing program is appropriately executed, for example. It is possible to inspect framework rules for the whole.

  First, the configuration of the program rule inspection apparatus according to the first embodiment will be described. FIG. 1 is a diagram for explaining the configuration of the program rule inspection apparatus according to the first embodiment. As shown in FIG. 1, the program rule inspection apparatus 100 includes an analysis data storage unit 110, a program analysis processing unit 120, a program inspection processing unit 130, a program inspection rule 140, a framework inspection processing unit 150, a frame A work inspection rule 160, an inspection result storage unit 170, and an inspection result notification processing unit 180 are included. Then, the program rule inspection apparatus 100 executes various processes on the inspection target program input from an input unit (not shown), thereby executing an inspection relating to the quality of the program and displaying an inspection result report on a display unit (not shown). indicate. The program to be inspected here is a program source code.

  The analysis data storage unit 110, the program inspection rule 140, the framework inspection rule 160, and the inspection result storage unit 170 are, for example, a semiconductor memory device such as a RAM (Random Access Memory) or a flash memory, a hard disk, or an optical disk. Storage device. Further, the program analysis processing unit 120, the program inspection processing unit 130, the framework inspection processing unit 150, and the inspection result notification processing unit 180 are integrated with, for example, ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array). It is a circuit or an electronic circuit such as a CPU (Central Processing Unit) or MPU (Micro Processing Unit).

  The analysis data storage unit 110 stores a relationship between a plurality of programs used for generating an application. Specifically, the analysis data storage unit 110 stores the processing result of the program analysis processing unit 120 described later and the input inspection target program. FIG. 2 is a diagram for explaining an example of management data stored by the analysis data storage unit 110. As shown in FIG. 2, the analysis data storage unit 110 stores management data in which a file name, file update date / time, language, analyzed flag, source hash code, and analysis target flag are associated with serial numbers.

  Note that “serial number” in FIG. 2 means a number assigned to the program analyzed by the program analysis processing unit 120. Further, “file name” in FIG. 2 means the file name of the program analyzed by the program analysis processing unit 120. Further, “file update date / time” in FIG. 2 means the date and time when the file was last modified. Further, “language” in FIG. 2 means a program language used for creating a program. The “analyzed flag” in FIG. 2 is a flag indicating whether or not analysis has been performed. The “source hash code” in FIG. 2 is a hash code for uniquely identifying a program and determining whether a file has been modified. For example, since the hash code changes when the file is modified, it is used to determine whether or not the file has been modified. Further, the “analysis target flag” in FIG. 2 is a flag indicating whether or not to be an analysis target related to a framework to be executed later.

  For example, as shown in FIG. 2, the analysis data storage unit 110 associates “serial number: 001” with “file name: M_SHAINView.vb, file update date: 2010/04/03 10:23:21, Language: VB.NET, analyzed flag: 1, source hash code: 948ad32e, and analysis target flag: 1 ”are stored. That is, the above-described information is that the program analyzed by the program analysis processing unit 120 on “2010/04/03 10:23:21” has the file name “M_SHAINView.vb” and uses “VB.NET”. It has been created. And the information mentioned above has shown that the hash code for specifying a program is "948ad32e", and becomes the analysis object regarding the framework performed later. Similarly, as shown in FIG. 2, the analysis data storage unit 110 stores management data of other analysis situations for the program analyzed by the program analysis processing unit 120 described later.

  FIG. 3 is a diagram for explaining an example of the class analysis result stored by the analysis data storage unit 110. As shown in FIG. 3, the analysis data storage unit 110 displays a class analysis result in which an identification ID is associated with a file path, a package name, a class name, a start line number, an end line number, a method number, a modifier, and an inheritance source. Remember.

  The “identification ID” in FIG. 3 is an identifier for uniquely identifying the analyzed class. Further, “file path” in FIG. 3 means a relative path from an analysis file path that is a folder that is a starting point of a folder in which a program to be inspected is stored. Further, the “package name” in FIG. 3 means the name of software including the inspection target program. Further, “class name” in FIG. 3 means the class name of the program to be inspected. Further, the “starting line number” in FIG. 3 means a line number indicating the starting line of the class in the program to be inspected. Further, the “end line number” in FIG. 3 means a line number indicating the end line of the class in the inspection target program. Further, the “number of methods” in FIG. 3 means the number of methods included in the class of the inspection target program. Further, the “qualifier” in FIG. 3 means an area where the class can be referred to. Further, “inheritance source” in FIG. 3 means a class that is a source of the class.

  For example, as shown in FIG. 3, the analysis data storage unit 110 associates “classification result as“ identification ID: 1001 ”with“ file path: WebAMaster / M_SHAINView.vb, package name: WebAS, class name: M_SHAINView, "Start line number: 6, end line number: 91, number of methods: 5, qualifier: Partial, inheritance source: BasePage" is stored. Similarly, the analysis data storage unit 110 stores other class analysis results as shown in FIG.

  FIG. 4 is a diagram for explaining an example of a method analysis result stored by the analysis data storage unit 110. FIG. 4 shows the result of analyzing the methods included in the class analysis result shown in FIG. As shown in FIG. 4, the analysis data storage unit 110 stores a method analysis result in which a serial number is associated with a file name, a class name, a method name, a parameter, a return value type, a start line number, and an end line number.

  Note that “serial number” in FIG. 4 means a number assigned to each method. Further, “file name” in FIG. 4 means a file name to which the method belongs. Further, “class name” in FIG. 4 means the class name to which the method belongs. Further, the “parameter” in FIG. 4 means a parameter designated for executing the process defined in the method. Further, the “return value type” in FIG. 4 means a type of value derived when an argument is specified for a parameter. Further, the “starting line number” in FIG. 4 means a line number indicating the starting line of the method in the inspection target program. Further, the “end line number” in FIG. 4 means a line number indicating the end line of the method in the inspection target program.

  For example, as shown in FIG. 4, the analysis data storage unit 110 associates the method analysis result with “serial number: 2001” as “file name: WebASMaster / M_SHAINView.vb, class name: M_SHAINView, method name: Page_Load, Parameters: Object, EventArgs, return value type: Noting, start line number: 9, end line number: 25 "are stored. Similarly, the analysis data storage unit 110 stores other method analysis results as shown in FIG.

  FIG. 5 is a diagram for explaining an example of the instance analysis result stored by the analysis data storage unit 110. FIG. 5 shows the result of analysis regarding the instance defined in the method shown in FIG. As illustrated in FIG. 5, the analysis data storage unit 110 includes an instance analysis result in which a serial number is associated with a file name, a class name, a method name, an argument, a return value type, a declaration variable name, a declaration variable type, and a declaration line number. Remember.

  The “serial number” in FIG. 5 means a number assigned to each instance. Further, “file name” in FIG. 5 means a file name to which the instance belongs. Further, “class name” in FIG. 5 means the class name to which the instance belongs. Further, “method name” in FIG. 5 means a method name defining an instance. Further, “argument” in FIG. 5 means a value specified for a method parameter. Further, the “return value type” in FIG. 5 means a type of a value derived by an argument. The “declared variable name” in FIG. 5 means the variable name of the instance designated by the designer. The “declared variable type” in FIG. 5 means the data type or class type of a variable declared as an instance. Further, “declared line number” in FIG. 5 means a line number in which an instance variable is described in the inspection target program.

  For example, as shown in FIG. 5, the analysis data storage unit 110 associates “sequence number: 3001” as an instance analysis result with “file name: WebASMMaster / M_SHAINView.vb, class name: M_SHAINView, method name: InsertButton_Click, Argument: Object, EventArgs, return value type: Noting, declaration variable name: param, declaration variable type: M_SHAINMANAGERParam, declaration line number: 39 ”is stored. Similarly, the analysis data storage unit 110 stores other instance analysis results as shown in FIG.

  FIG. 6 is a diagram for explaining an example of a method call analysis result stored by the analysis data storage unit 110. FIG. 6 shows the analysis result of the calling method for each instance shown in FIG. As shown in FIG. 6, the analysis data storage unit 110 assigns an identification ID to a file name, a class name, a method name, an argument, a return value type, a call destination class, a call destination method name, a call destination method parameter, and a call line number. Stores the associated method call analysis result.

  Note that the “identification ID” in FIG. 6 means an identifier for uniquely identifying an instance. Further, “file name” in FIG. 6 means a file name to which the instance belongs. Further, “class name” in FIG. 6 means a class name to which the instance belongs. Further, “method name” in FIG. 6 means a method name defining an instance. Further, “argument” in FIG. 6 means a value designated for a method parameter. Further, the “return value type” in FIG. 6 means a value type derived by an argument. Further, the “call destination class” in FIG. 6 means a class called in each instance. Further, “invocation method name” in FIG. 6 means a method name to be called in each instance. Further, “call destination method parameter” in FIG. 6 means a parameter of the call destination method. Further, the “call line number” in FIG. 6 means a line number in which a method call is described in the program to be inspected.

  For example, as shown in FIG. 6, the analysis data storage unit 110 associates “file name: WebASMMaster / M_SHAINView.vb, class name: M_SHAINView., Method name: InsertButton_Click” in association with “identification ID: 4001” as a method call analysis result. , Argument: Object, EventArgs, return value type: Nothing, call destination class: Validator, call destination method name: ServerValidate, call destination method parameter: none, call line number: 34 ”. Similarly, the analysis data storage unit 110 stores other method call analysis results as shown in FIG.

  Returning to FIG. 1, the program checking rule 140 stores a program check rule that is a check rule of a single program. The framework inspection rule 160 stores framework rules that are framework check rules. The inspection result storage unit 170 stores inspection results that are processing results of the program inspection processing unit 130 and the framework inspection processing unit 150 described later. The program check rule, framework rule, and inspection result will be described in detail later.

  The program analysis processing unit 120 analyzes relationships between a plurality of programs used for creating an application. Specifically, the program analysis processing unit 120 analyzes a relationship between a plurality of programs used for creating an application as a pre-analysis for executing a rule check of a framework rule. More specifically, the program analysis processing unit 120 targets all programs designated by the user for prior analysis, analyzes the description contents, reference relationships, etc. of the targeted programs, and analyzes the analysis results as analysis data. Store in the storage unit 110. Below, the analysis process by the program analysis process part 120 is demonstrated using FIGS. 7-1 to FIG. 9-2.

  First, the program source code shown in FIGS. 7-1 to 9-2 will be described. FIG. 7A and FIG. 7B are diagrams for explaining an example of a program source code related to screen processing. FIG. 7A and FIG. 7B show one program source code related to screen processing. FIGS. 7A and 7B illustrate processing when a display unit (not shown) displays a predetermined screen. For example, as shown in FIG. 7A, the program source code related to the screen processing includes “program text: Me.ResultMessage.Text = String.Empty” corresponding to “comment: clear display message”. ing.

  8A to 8C are diagrams for explaining an example of a program source code related to business processing. FIG. 8A to FIG. 8C show one program source code related to business processing. 8A to 8C show various types of transaction processing. Similar to the program source code related to screen processing, the program source code related to business processing contains program sentences for various processes with comments.

  FIG. 9A and FIG. 9B are diagrams for explaining an example of a program source code related to database processing. FIG. 9A and FIG. 9B show one program source code related to business processing. 9A and 9B illustrate access processing for the database. Similar to the program source code related to screen processing, the program source code related to database processing includes program statements for various processes with comments.

  For example, the program analysis processing unit 120 uses program source code as shown in FIGS. The program analysis processing unit 120 sets all program source codes designated by the user as targets of prior analysis, and analyzes the description content, reference relationship, and the like of the target program. For example, when a program is stored across multiple hierarchies and the analysis file path that is the origin folder is specified by the user, the program analysis processing unit 120 first subordinates the specified analysis file path. All program source codes are set as inspection target programs, and file paths of the inspection target programs are acquired. The analysis file path is uniquely set for each project, and the user can uniquely specify and specify a desired analysis file as an analysis target of the prior analysis.

  For example, in the case of analyzing the program source code related to the screen processing shown in FIGS. 7-1 and 7-2 as a prior analysis, the program analysis processing unit 120 executes the following analysis processing, and the analysis result Is stored in the analysis data storage unit 110. First, the program analysis processing unit 120 acquires a package name from a location where the package name of the program source code is declared. For example, the program analysis processing unit 120 acquires the package name “WebAS” shown in “line 4” in FIG. 7A and stores the acquired “WebAS” in the analysis data storage unit 110.

  Then, the program analysis processing unit 120 executes class analysis of the program source code and stores the analysis result in the analysis data storage unit 110. Specifically, the program analysis processing unit 120 executes class determination in the program source code, count of the number of methods in the class, and acquisition of class modifiers and inheritance sources using regular expressions. Note that the “regular expression” referred to here is a pattern predetermined for extracting a specific character string from an arbitrary character string. For example, "" ((Public | Private | Protected | Partial) (¥ s)) * ((Shared) (¥ s)) * (Class) ¥ s (¥ [?) (¥ w +) (¥] ?) (. *) "" Is used as a regular expression for the class start line, and "" ^ End \ sClass? " "" Etc. are used as regular expressions for class end lines. For example, "" ((Public | Private | Protected | Partial) (¥ s)) * ((Shared (¥ s)) * (Class) ¥ s (¥ [?) (¥ w +) (¥]?) ( . *) "" Is a regular expression that uses "Private Class", "Personal Class", etc. as a search target character string. In other words, the program analysis processing unit 120 refers to the program source code and executes pattern matching with a predetermined regular expression to perform class determination, count the number of methods, and the like. For example, the regular expression is stored in a storage unit (not shown).

  For example, referring to FIG. 7A and FIG. 7B, the program analysis processing unit 120 converts “Partial Class M_SHAINView” in “Line 6” that matches the regular expression pattern to “End” in “Line 91”. Class up to “Class” is determined as a class. Then, the program analysis processing unit 120 determines that one method is between “Private Sub” and “End Sub” in the class, and counts the number of methods in the class. In the above case, "" ^ ((Public | Private | Protected | Friendend | Overridable) (\ s)) * ((Shared | Shadows | Overrides | Overloads) (\ s)) * (Function | Sub) | s (\ W +?) \ ((. *) \) ((\ S (As) \ s (. +)) *)? "" And "" ^ End \ s (Sub | Function) $ "" are stored in advance in, for example, a storage unit (not shown) as regular expressions of "method start line" and "method end line", respectively. . For example, the regular expression "" ^ ((Public | Private | Protected | Friendend | Overridable) (\ s)) * ((Shared | Shadows | Overrides | Overloads) (\ s)) * (Function | Sub) \ s (\ w +?) \ ((. *) \) ((\ s (As) \ s (. +)) *)? “” Is a regular expression that uses “Private Sub”, “Private Function”, or the like as a search target character string. Further, the program analysis processing unit 120 acquires the class modifier and the inheritance source using a regular expression. Specifically, the program analysis processing unit 120 acquires a class start line using a regular expression, and acquires a class qualifier and an inheritance source class included in the class start line. For example, the program analysis processing unit 120 acquires the class modifier “Partial” and the inheritance source “BasePage” using regular expressions.

  Then, the program analysis processing unit 120 assigns an identification ID to the class information acquired from the program source code and stores it in the analysis data storage unit 110. For example, as illustrated in FIG. 3, the program analysis processing unit 120 displays “identification ID: 1001, file path: WebAMaster / M_SHAINView.vb, package name: WebAS, class name: M_SHAINView, start line number: 6, end line number. : 91, number of methods: 5, modifier: Partial, inheritance source: BasePage ”is stored in the analysis data storage unit 110 as a class analysis result.

  Similarly, the program analysis processing unit 120 pre-analyzes the program source code related to the business process shown in FIGS. 8-1 to 8-3 and the program source code related to the database process shown in FIGS. 9-1 and 9-2. The program source code designated by the user as the target program is subjected to class analysis, and the analysis result is stored in the analysis data storage unit 110 (see FIG. 3).

  Then, the program analysis processing unit 120 analyzes each method included in the class. Specifically, the program analysis processing unit 120 acquires, for each method determined using the regular expression, the method name, parameter, return value type, and the like included in the method start line using the regular expression. For example, the program analysis processing unit 120 executes the analysis of the method described between “Private Sub Page_Load” shown in “9th line” and “End Sub” shown in “25th line” in FIG. To do. Then, the program analysis processing unit 120 analyzes the analysis result “file name: WebASMMaster / M_SHAINView.vb, class name: M_SHAINView, method name: Page_Load, parameter: Object, EventArgs, return value type: Nothing, start line number: 9, and end. “Line number: 25” is associated with “serial number: 2001” and stored in the analysis data storage unit 110 as a method analysis result (see FIG. 4). Similarly, the program analysis processing unit 120 analyzes all the methods included in each class and stores the analysis results in the analysis data storage unit 110. For example, regular expressions used for method analysis are stored in a storage unit (not shown).

  Further, the program analysis processing unit 120 executes analysis of the instance defined in the method. Specifically, the program analysis processing unit 120 uses a regular expression to express an instance declaration line number, an instance variable name, a declaration data type, or a class type defined between the start line and end line of a method. get. For example, the program analysis processing unit 120 is defined in a method described between “Private Sub InsertButton_Click” shown in “Line 31” and “End Sub” shown in “59th line” in FIG. Perform instance analysis. Then, the program analysis processing unit 120 stores various types of information shown in “serial number: 3001” and “serial number: 3001” in FIG. 5 in the analysis data storage unit 110 as the instance analysis result. Similarly, the program analysis processing unit 120 analyzes the instance defined in each method, and stores the analysis result in the analysis data storage unit 110 (see FIG. 5). For example, a regular expression used for instance analysis is stored in a storage unit (not shown).

  Furthermore, the program analysis processing unit 120 performs analysis of a call destination for each method. Specifically, the program analysis processing unit 120 acquires a call destination class, a call destination method, a call destination method parameter, a call line number, and the like for each method using a regular expression. For example, the program analysis processing unit 120 may call the destination of the method described between “Private Sub InsertButton_Click” shown in “Line 31” and “End Sub” shown in “59th line” in FIG. Run the analysis. Then, the program analysis processing unit 120 stores various types of information shown in “identification ID: 4001” to “identification ID: 4004” in FIG. 6 in the analysis data storage unit 110 as a method call analysis result. Similarly, the program analysis processing unit 120 analyzes the call destination of each method and stores the analysis result in the analysis data storage unit 110 (see FIG. 6). For example, a regular expression used for analysis of a call destination is stored in a storage unit (not shown).

  The program analysis processing unit 120 executes each analysis described above for all program source codes under the analysis file path specified by the user, and stores the analysis result in the analysis data storage unit 110. At the same time, the program analysis processing unit 120 stores the analyzed program source code in the analysis data storage unit 110.

  Returning to FIG. 1, the program inspection processing unit 130 inspects whether each of the plurality of programs conforms to a program rule that is a creation rule of each of the plurality of programs. Specifically, the program inspection processing unit 130 inspects the inspection target program stored in the analysis data storage unit 110 using the program check rule stored by the program inspection rule 140. Then, the program inspection processing unit 130 stores the inspection result in the inspection result storage unit 170.

  Here, the program check rule stored by the program inspection rule 140 will be described with reference to FIGS. Note that the program check rule is stored in the program inspection rule 140 in advance by processing by the designer. FIG. 10A and FIG. 10B are diagrams for explaining an example of a program check rule used for inspection related to a program mounting method. FIGS. 10A and 10B show one program check rule used for the inspection related to the program mounting method. For example, as shown in FIGS. 10A and 10B, “whether the nesting of the IF phrase exceeds the threshold” is defined in the program check rule used for the inspection related to the program implementation method. For example, in the program check rule used for the inspection related to the program implementation method, “whether the IF clause is nested in three or less layers” or the like is defined.

  FIG. 11 is a diagram for explaining an example of a program check rule used for a check relating to program inheritance. For example, in the program check rule used for checking the inheritance source of the program, as shown in FIG. 11, “whether the parent class corresponding to the program type is inherited” is defined. For example, in the program check rule used for the inspection of the inheritance source of the program, “whether the program in the Logic layer inherits the BaseLogicClass” or the like is defined.

  FIG. 12 is a diagram for explaining an example of the program check rule used for the inspection related to the program calling method. For example, in the program check rule used for the inspection relating to the program calling method, as shown in FIG. 12, “whether there is no place where SQL is executed in the loop” is defined. For example, in the program check rule used for the inspection relating to the program calling method, “whether or not the SQL issuing process is described in the For phrase” is defined.

  For example, the program inspection processing unit 130 inspects the program source code shown in FIGS. 7-1 to 9-2 using the program check rules shown in FIGS. Here, the program inspection processing unit 130 executes the inspection of the program source code with reference to the analysis results shown in FIGS. For example, when executing the inspection relating to the program mounting method shown in FIGS. 10A and 10B, the program inspection processing unit 130 refers to the method analysis result shown in FIG. Performs a check for nested within.

  Returning to FIG. 1, the framework inspection processing unit 150 determines whether the relationship between a plurality of programs analyzed by the program analysis processing unit 120 is a relationship in accordance with a framework rule that is a framework specification rule. inspect. Specifically, the framework inspection processing unit 150 uses the analysis result of the pre-analysis stored in the analysis data storage unit 110 to use the calling relationship or inheritance relationship of each program or use of commonly used components. Check whether the conformity of the method conforms to the framework regulations. For example, the framework inspection processing unit 150 inspects whether or not the calling order of a plurality of programs is the calling order when the application is executed. Note that the user can arbitrarily determine what kind of inspection is performed. For example, it may be a case where inspection is performed for all the framework rules set in advance, or a case where inspection is performed for a framework rule arbitrarily selected by the user. Moreover, it may be a case where an inspection is executed for a framework rule newly defined by the user.

  Here, the framework inspection processing unit 150 determines the content of the inspection based on the framework rules according to the inspection result of the program inspection processing unit 130. Specifically, in the inspection by the program inspection processing unit 130, the framework inspection processing unit 150 has a ratio of the number of programs determined to be created in accordance with the program rules exceeding the predetermined threshold. On the condition that the inspection is based on the framework regulations.

  For example, the framework inspection processing unit 150 refers to the processing result of the program inspection processing unit 130 stored in the inspection result storage unit 170, and the total number of programs determined to be created in accordance with the program rules. The inspection is executed when the ratio to the number of programs exceeds 80%. That is, the framework inspection processing unit 150 determines that the coding level of the program is low when the ratio of the programs whose quality is NG (bad) exceeds a predetermined threshold in all the programs, Do not perform work inspection.

  When executing the inspection related to the framework, the framework inspection processing unit 150 executes the inspection using the framework rule stored by the framework inspection rule. Here, the framework rules stored by the framework inspection rules 160 will be described with reference to FIGS. 13-1 to 13-3. FIG. 13A to FIG. 13C are diagrams for explaining an example of the framework rule regarding the calling order of programs. FIG. 13A to FIG. 13C show one framework rule used for checking the program call order. The framework rules are stored in advance in the framework inspection rules 160 by processing by the designer.

  For example, as shown in FIG. 13A, framework rules relating to the calling order of programs include “obtain screen class list”, “obtain screen class method list”, “obtain method instance list”, and “ It is defined that “call method acquisition” is executed sequentially and recursively. The framework rules relating to the calling order of programs define that “check whether the call destination class is correct” as shown in FIGS. 13-2 and 13-3. For example, as shown in FIG. 13-2, a check item that “only a Manager (business process) class or a component class method can be called from a View (screen processing) class method” is available. Is defined.

  For example, the framework inspection processing unit 150 uses the framework rules shown in FIGS. 13-1 to 13-3 to inspect the calling order between a plurality of programs. For example, the framework inspection processing unit 150 first reads out the framework rules shown in FIGS. 13-1 to 13-3 from the framework inspection rules 160. The framework inspection processing unit 150 acquires a screen processing class list from the analysis data storage unit 110 as defined in the framework rules. For example, the framework inspection processing unit 150 acquires the screen processing class “M_SHAINView” from the analysis data storage unit 110 from the class analysis result illustrated in FIG. 3.

  Then, the framework inspection processing unit 150 acquires a method list of the acquired class. For example, from the method analysis result shown in FIG.

  Thereafter, the framework inspection processing unit 150 acquires a list of instances in the acquired method. For example, the framework inspection processing unit 150 acquires “serial number: 3001” and “serial number: 3002” that are instances of the acquired method “InsertButton_Click” from the instance analysis result shown in FIG.

  Then, the framework inspection processing unit 150 sequentially acquires the call destination methods of the acquired instances, and checks whether the call destination is correct. For example, the framework inspection processing unit 150 sequentially acquires the call destination class and the call destination method of the acquired instance from the method call analysis result illustrated in FIG. That is, the framework inspection processing unit 150 sequentially acquires the call destination class and the call destination method associated with each of the identification IDs “4001” to “4004” illustrated in FIG. 6 to determine whether the call destination is correct. inspect.

  For example, in the “identification ID: 4003” illustrated in FIG. 6, the framework inspection processing unit 150 calls “class: M_SHAINView, method: InsertButton_Click” as “class: M_SHAINManager, method: Entrychain”. Therefore, it is determined that the calling order is correct. Here, if the call destination of “class: M_SHAINView, method: InsertButton_Click” is “class: M_SHAINLogic”, the framework inspection processing unit 150 determines that the calling order is not correct.

  Then, the framework inspection processing unit 150 acquires an instance list of the acquired call destination method “Entrychain”, performs the same processing as the above-described processing, and checks whether the call destination is correct. To do. That is, the framework inspection processing unit 150 acquires the instances of the serial numbers “3003” to “3006” from the instance analysis result of FIG. 5 and calls each of the identification IDs “4005” to “4012” illustrated in FIG. Get class and callee method and check whether each callee is correct. In this way, the framework inspection processing unit 150 inspects whether the calling order of all the calling methods sequentially called from the screen processing method is in accordance with the framework rule. The framework inspection processing unit 150 executes the above-described series of processing for all the methods of the acquired class, and stores the inspection result in the inspection result storage unit 170.

  Returning to FIG. 1, the inspection result notification processing unit 180 displays the inspection result of the program or the inspection result of the framework stored in the inspection result storage unit 170 as an inspection result report on a display unit (not shown). 14A and 14B are diagrams for explaining an example of the inspection result report.

  For example, as shown in FIG. 14A, the inspection result notification processing unit 180 uses a list of inspection results associating files, lines, rule IDs, indication contents, categories, importance levels, classifications, and results as a check result report. It is displayed on a display unit (not shown). Further, as shown in FIG. 14B, the inspection result notification processing unit 180 reports an overall quality evaluation obtained by integrating all the inspection results, and displays it on the display unit. FIG. 14B shows a report that determines whether the inspection result is a serious defect, a minor defect, or an indication level. Further, FIG. 14-2 shows a report in which the inspection results are aggregated by program category. By displaying such an inspection result report on the display unit, it is possible to accurately determine measures to be taken by the designer thereafter.

  Next, a processing procedure of the program rule inspection apparatus 100 according to the first embodiment will be described with reference to FIGS. FIG. 15 is a flowchart for explaining the procedure of the program pre-analysis process performed by the program rule inspection apparatus 100 according to the first embodiment.

  As shown in FIG. 15, in the program rule inspection apparatus 100 according to the first embodiment, the program analysis processing unit 120 acquires source information from the inspection target program (step S101). And the program analysis process part 120 acquires the class information for every acquired source (step S102). Thereafter, the program analysis processing unit 120 acquires method information for each acquired class (step S103).

  Further, the program analysis processing unit 120 acquires information on a method called by the acquired method (Step S104), and acquires processing contents of each method (Step S105). Further, the program analysis processing unit 120 stores the acquired information in the analysis data storage unit 110 (step S106), and ends the process.

  FIG. 16 is a flowchart for explaining the procedure of the process performed by the program rule inspection device 100 according to the first embodiment. Note that FIG. 16 shows processing after the pre-analysis processing by the program analysis processing unit 120 is completed.

  As shown in FIG. 16, in the program rule inspection apparatus 100 according to the first embodiment, when a program to be inspected is input (Yes at Step S201), the program inspection processing unit 130 creates a framework rule list from a storage unit (not shown). It is acquired (step S202), and it is determined whether or not a framework rule exists in the inspection target program (step S203). Here, when the framework rule does not exist in the inspection target program (No at Step S203), the program inspection processing unit 130 stores the result in the inspection result storage unit 170 (Step S213), and ends the processing. To do.

  On the other hand, when the framework rule exists in the inspection target program (Yes at Step S203), the program inspection processing unit 130 acquires the program check rule list from the program inspection rule 140 (Step S204), and the check rule exists. It is determined whether or not to perform (step S205). Here, when the check rule does not exist (No at Step S205), the framework inspection processing unit 150 executes the framework check module (Step S210).

  On the other hand, when the check rule exists (Yes at Step S205), the program inspection processing unit 130 executes the program check module (Step S206) and stores the result in the inspection result storage unit 170 (Step S207). When all the check rules are checked (Yes at Step S208), the framework inspection processing unit 150 determines whether or not NG of a single program is equal to or less than a predetermined ratio (Step S209).

  Here, when NG of a single program exceeds a predetermined ratio (No at Step S209), the framework inspection processing unit 150 indicates a result indicating that the processing related to the framework is not executed as the inspection result storage unit 170. (Step S214), and the process ends. On the other hand, when the NG of the single program is equal to or less than the predetermined ratio (Yes at Step S209), the framework inspection processing unit 150 executes the framework check module (Step S210), and the result is stored in the inspection result storage unit. It is stored in 170 (step S211).

  When all the framework rules are checked (Yes at step S212), the program rule inspection apparatus 100 according to the first embodiment ends the process. The program rule inspection apparatus 100 according to the first embodiment is in a standby state until an inspection target program is input (No at Step S201). Further, the program rule inspection apparatus 100 according to the first embodiment executes the program inspection until all the check rules are checked in the determination of step S208 (No in step S208). In addition, the program rule inspection apparatus 100 according to the first embodiment performs the framework inspection until all the framework rules are checked in the determination in step S212 (No in step S212).

  FIG. 17 is a flowchart for explaining the procedure of the framework inspection process performed by the program rule inspection apparatus 100 according to the first embodiment. The procedure of the framework inspection process shown in FIG. 17 corresponds to step S210 shown in FIG. As shown in FIG. 17, in the program rule inspection apparatus 100 according to the first embodiment, the framework inspection processing unit 150 acquires a class list of inspection target programs from the analysis data storage unit 110 (step S301). A method list is acquired (step S302). The framework inspection processing unit 150 acquires an instance list in the acquired method (step S303), and acquires a call destination method for each instance (step S304).

  Thereafter, the framework inspection processing unit 150 checks whether or not the call destination of the acquired call destination method is correct (step S305), and stores the test result in the test result storage unit 170 (step S306). Further, the framework inspection processing unit 150 acquires an instance list of the called method (step S307), and determines whether there is a method to be called (step S308).

  If there is a method to be called (Yes at Step S308), the framework inspection processing unit 150 returns to Step S304 and acquires a called method for each instance. On the other hand, when there is no method to call (No at Step S308), the framework inspection processing unit 150 ends the process.

  As described above, according to the first embodiment, the program analysis processing unit 120 analyzes the relationship between a plurality of inspection target programs. Then, the framework inspection processing unit 150 inspects whether or not the relationship between the plurality of inspection target programs analyzed by the program analysis processing unit 120 is a relationship in accordance with a framework rule that is a framework specification rule. . Therefore, the program rule inspection apparatus 100 according to the first embodiment can determine whether or not processing across multiple hierarchies is appropriately executed by checking the association between a plurality of programs, and the entire system It is possible to inspect framework rules for the target. Furthermore, the program rule inspection apparatus 100 according to the first embodiment makes it possible to improve the quality of software to be sold as a result by inspecting framework rules for the entire system.

  Further, according to the first embodiment, the framework inspection processing unit 150 uses the order in which a plurality of inspection target programs are called when an application is executed as a framework rule. Therefore, the program rule inspection apparatus 100 according to the first embodiment can determine whether the calling relationship, the reference relationship, and the inheritance relationship across a plurality of programs are appropriate.

  Further, according to the first embodiment, the program inspection processing unit 130 inspects whether or not each of the plurality of inspection target programs conforms to a program check rule that is a creation rule of each of the programs. Then, the framework inspection processing unit 150 determines the contents of processing for a plurality of inspection target programs according to the inspection result of the program inspection processing unit 130. Therefore, the program rule inspection apparatus 100 according to the first embodiment can change the process flexibly according to the quality of a single program.

  Further, according to the first embodiment, the framework inspection processing unit 150 has a predetermined ratio of the number of programs determined to be created according to the program rules in the inspection by the program inspection processing unit 130 to the total number of programs. The inspection based on the framework rule is executed on the condition that the threshold value is exceeded. Therefore, the program rule inspection apparatus 100 according to the first embodiment can execute a highly accurate inspection on the inspection target program. Further, the program rule inspection device 100 according to the first embodiment can execute an efficient inspection.

  For example, in the prior art, “inspection of whether or not the variable name of the program description is a command according to the convention”, “inspection of whether or not the grammar description of the program description conforms to the convention”, “ "Check whether the hierarchy of repeated processing description is less than the specified number", "Check whether an external program that is not allowed to be used by convention is used", "How to call processing methods of other programs As for "inspection of whether there is an error in the description of", etc., since the program itself was inspected, the entire system was difficult to inspect.

  In the program rule inspection apparatus 100 according to the present embodiment, the program analysis processing unit 120 analyzes in advance the relationship between programs to be inspected. Then, the framework inspection processing unit 150 performs an inspection related to the framework for the relationship between programs analyzed by the program analysis processing unit 120. As a result, in the program rule inspection apparatus 100 according to the present embodiment, it is possible to perform in the prior art, such as the calling relationship or inheritance relationship of the program source code included in the software, or the suitability of the commonly used component usage method. It is possible to inspect framework rules for the entire system that did not exist.

  FIG. 18 is a diagram schematically illustrating an example of a framework inspection performed by the program rule inspection apparatus 100 according to the first embodiment. As illustrated in FIG. 18, the program rule inspection device 100 according to the first embodiment changes the calling order in a series of processes spanning a program related to screen processing, a program related to business processing, and a program related to database processing. It is possible to determine whether or not the processing across the layers is appropriately executed by checking, and it is possible to improve the software quality.

  In the first embodiment described above, the case where the calling order of programs is used as the framework rule has been described. In the second embodiment, a case where the processing order of programs is used as a framework rule will be described.

  In the second embodiment, the contents of processing by the framework inspection processing unit 150 and the contents stored by the framework inspection rule 160 are different from those in the first embodiment. Hereinafter, these will be mainly described. The framework inspection processing unit 150 of the program rule inspection device 100 according to the second embodiment determines whether the processing order of the plurality of programs analyzed by the program analysis processing unit 120 is the processing order when the application is executed. Inspect.

  Here, the framework rules used by the framework inspection processing unit 150 according to the second embodiment will be described with reference to FIGS. 19A and 19B. FIG. 19A and FIG. 19B are diagrams for explaining an example of a framework rule regarding the processing order of programs. FIGS. 19A and 19B show one framework rule used for the inspection relating to the processing order of the program. The framework rules are stored in advance in the framework inspection rules 160 by processing by the designer.

  For example, as shown in FIG. 19-1, the framework rules regarding the processing order of the program include “obtain screen class list”, “obtain screen class method list”, “obtain method instance list”, and “ It is defined that “call method acquisition” is executed sequentially and recursively. Here, in the framework rule regarding the processing order of the program, as shown in FIG. 19A, “hold call instances in order” is defined.

  Further, as shown in FIG. 19-2, the framework rule relating to the processing order of the program defines that “check the calling order” of the calling instances held in order. That is, in the checking of the program processing order, the calling instances are held in the calling order, and the calling order is checked to check the processing order of the program.

  For example, the framework inspection processing unit 150 uses the framework rules shown in FIGS. 19A to 19B to inspect the processing order between a plurality of programs. Here, the framework inspection processing unit 150 sequentially obtains a list of classes, methods, and instances in the same manner as in the invocation order inspection. For example, the framework inspection processing unit 150 acquires “serial number: 3001” and “serial number: 3002” which are instances of the method “InsertButton_Click” from the class “M_SHAINView” of the screen processing (see FIG. 5).

  Then, the framework inspection processing unit 150 sequentially executes the call method check while sequentially obtaining the call destination class and the call destination method associated with the identification IDs “4001” to “4004” illustrated in FIG. Here, in the identification ID “4003”, since the call destination is “class: M_SHAINManager, method: Entrychain”, the framework inspection processing unit 150 next receives the identification IDs “4005” to “4012”. The methods to be called are checked in order.

  The framework inspection processing unit 150 according to the second embodiment maintains the order while sequentially checking the method of the call destination. That is, the framework inspection processing unit 150 according to the second embodiment identifies that the transaction processing is started with the identification ID “4007” after the log output processing is executed with the identification IDs “4005” and “4006”. . In this way, the framework inspection processing unit 150 according to the second embodiment inspects whether or not the processing order of a series of processes derived from the screen processing conforms to the framework rules. The framework inspection processing unit 150 according to the second embodiment executes the above-described inspection in the processing order for all the methods of the acquired class, and stores the inspection result in the inspection result storage unit 170.

  FIG. 20 is a flowchart for explaining the procedure of the framework inspection process performed by the program rule inspection apparatus 100 according to the second embodiment. The procedure of the framework inspection process shown in FIG. 20 corresponds to step S111 shown in FIG. As illustrated in FIG. 20, in the program rule inspection apparatus 100 according to the second embodiment, the framework inspection processing unit 150 acquires a class list of inspection target programs from the analysis data storage unit 110 (step S401), and class A method list is acquired (step S402). Then, the framework inspection processing unit 150 acquires an instance list in the acquired method (step S403), and acquires it in association with the calling order of the call destination method for each instance (step S404).

  Thereafter, the framework inspection processing unit 150 obtains an instance list of the called method (step 405), and determines whether there is a method to be called (step S406). If there is a method to be called (Yes at step S406), the framework inspection processing unit 150 returns to step S404 and acquires the callee method in association with the calling order.

  On the other hand, when there is no method to be called (No at Step S406), the framework inspection processing unit 150 checks the method calling order (Step S407), and stores the inspection result in the inspection result storage unit 170 (Step S407). S408), the process ends.

  As described above, according to the second embodiment, the framework inspection processing unit 150 uses the order of processes executed by a plurality of programs when an application is executed as a framework rule. Therefore, the program rule inspection apparatus 100 according to the second embodiment makes it possible to execute a detailed inspection of a program.

  FIG. 21 is a diagram schematically illustrating an example of a framework inspection performed by the program rule inspection apparatus 100 according to the second embodiment. As illustrated in FIG. 21, the program rule inspection apparatus 100 according to the second embodiment can inspect the processing order of program processing related to screen processing, program processing related to business processing, and program processing related to database processing. it can. For example, as illustrated in FIG. 21, the program rule inspection apparatus 100 according to the second embodiment performs input check processing, log output processing, transaction start processing, registration processing, transaction end processing, and screen display processing in order. It can be inspected. That is, the program rule inspection apparatus 100 according to the second embodiment can inspect whether or not the processing across each hierarchy is appropriately executed, and the framework rule for the entire system is highly accurate. Allows inspection to be performed.

  Although the first and second embodiments have been described so far, the present invention may be implemented in various different forms other than the first and second embodiments described above.

(1) Inspection Result Report In the above-described first and second embodiments, a list of inspection results and a comprehensive quality evaluation that combines all inspection results are displayed as inspection result reports that the inspection result notification processing unit 180 displays on the display unit. Explained the case. However, the present embodiment is not limited to this. For example, the inspector may select an item to be checked using an arbitrary parameter.

  FIG. 22-1 and FIG. 22-2 are diagrams for explaining a modification of the inspection result report. As illustrated in FIG. 22A, the test result notification processing unit 180 may display a GUI (Graphical User Interface) having various analysis settings on the display unit. As analysis settings, for example, as shown in FIG. 22-1, various settings used for a pre-delivery check, various settings used for a check during development, and the like may be provided. Then, as illustrated in FIG. 22-1, the inspection result notification processing unit 180 may cause the display unit to display an inspection result report showing a list of detailed inspection results for each project.

  And in the inspection result report shown in FIG. 22-1, as shown in FIG. 22-2, the display area of various settings and inspection results can be arbitrarily changed by the inspector, and according to the request of the inspector. Enable information provision.

(2) Program Inspection Processing In the first and second embodiments described above, the case where the program inspection is executed before the framework inspection has been described. However, the present embodiment is not limited to this. For example, only the framework inspection may be executed without executing the program inspection.

(3) Framework Inspection Processing In the first and second embodiments described above, the case has been described in which the program calling order and the processing order are executed separately as the framework inspection processing. However, the present embodiment is not limited to this. For example, the program calling order and the processing order may be executed simultaneously as the framework inspection process.

(4) Execution of Framework Inspection Process In the above-described first and second embodiments, the case where the framework inspection process is not executed when the quality of NG in the inspection result of the program inspection is large has been described. However, the present embodiment is not limited to this. For example, in a rule inspection device that simultaneously checks the calling order and processing order of a program, one of the inspections is executed according to the inspection result of the program inspection. You may make it do.

(5) Prior Analysis In the first and second embodiments described above, the case where the relationship between a plurality of programs used for creating an application is analyzed in advance has been described. However, the present embodiment is not limited to this. For example, each time a framework rule rule check is executed, the relationship between a plurality of programs used to create an application may be analyzed. Good.

(6) System Configuration Each component of each illustrated device is functionally conceptual and does not necessarily need to be the same as the physically illustrated component. In other words, the specific form of distribution / integration of each device is not limited to that shown in the figure, and all or a part thereof may be functionally or physically distributed or arbitrarily distributed in arbitrary units according to various loads or usage conditions. Can be integrated and configured. For example, the program inspection rule 140 and the framework inspection rule 160 shown in FIG. 1 may be integrated as one storage unit. On the other hand, the test result notification processing unit 180 illustrated in FIG. 1 may be distributed to a calculation unit that executes a calculation process using the test result and a display control unit that controls the display unit.

  In addition, all or a part of the processes described as being manually performed among the processes described in the present embodiment can be manually performed. For example, the inspection target program input process in FIG. 16 may be automatically performed. In such a case, the program may be set to be automatically input to the program rule inspection apparatus 100 when the program is created. Further, the framework inspection processing unit 150 may be connected as an external device of the program rule inspection device 100 via a network. Further, all or any part of each processing function performed in each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.

(7) Rule Inspection Program In the first embodiment, the case where various processes are realized by hardware logic has been described. However, the present embodiment is not limited to this, and a program prepared in advance is stored in a computer. May be executed. Therefore, in the following, an example of a computer that executes a rule inspection program having the same function as the program rule inspection apparatus 100 shown in the first embodiment will be described with reference to FIG. FIG. 23 is a diagram for explaining a computer that executes a rule inspection program.

  As shown in FIG. 23, the computer 1000 includes, for example, a memory 1010, a CPU (Central Processing Unit) 1020, and a hard disk drive interface 1030. As shown in FIG. 23, the computer 1000 includes, for example, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These units are connected by a bus 1080. .

  The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012 as shown in FIG. The ROM 1011 stores a boot program such as BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to the hard disk drive 1090 as shown in FIG. The disk drive interface 1040 is connected to the disk drive 1100 as shown in FIG. For example, a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100. As shown in FIG. 23, the serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120. The video adapter 1060 is connected to a display 1130, for example, as shown in FIG.

  Here, as shown in FIG. 23, the hard disk drive 1090 stores, for example, an OS (Operating System), application programs, program modules, and program data. That is, the analysis program is stored, for example, on a hard disk as a program module in which a command executed by the computer 1000 is described. Specifically, an analysis procedure for executing analysis processing similar to that of the program analysis processing unit 120 described in the above-described embodiment and a framework inspection procedure for executing inspection processing similar to that of the framework inspection processing unit 150 are described. The programmed program module is stored in the hard disk.

  Moreover, like the data stored in the analysis data storage unit 110 described in the above-described embodiment, data used for information processing by the rule inspection program is stored as, for example, a hard disk. Then, the CPU 1020 reads program modules and program data stored in the hard disk to the RAM 1012 as necessary, and executes analysis procedures and framework inspection procedures.

  Note that the program module and program data related to the rule inspection program are not limited to being stored in the hard disk, but may be stored in, for example, a removable storage medium and read out by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module and program data relating to the analysis program are stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.), and the CPU 1020 via the network interface 1070. May be read.

DESCRIPTION OF SYMBOLS 100 Program rule inspection apparatus 110 Analysis data storage part 120 Program analysis processing part 130 Program inspection processing part 140 Program inspection rule 150 Framework inspection processing part 160 Framework inspection rule 170 Inspection result storage part 180 Inspection result notification processing part

Claims (7)

An analysis unit that analyzes the relationship between multiple programs used to create the application;
A framework inspection unit that inspects whether the relationship between the plurality of programs analyzed by the analysis unit is a relationship in accordance with a framework specification that is a framework specification;
A rule inspection device characterized by comprising:   The rule checking apparatus according to claim 1, wherein the framework checking unit uses, as the framework definition, an order in which the plurality of programs are called when the application is executed.   The rule inspection device according to claim 1, wherein the framework inspection unit uses, as the framework definition, an order of processing executed by the plurality of programs when the application is executed. . Each of the plurality of programs further includes a program inspection unit that inspects whether or not each of the plurality of programs conforms to a program rule that is a creation rule of the plurality of programs.
The said framework test | inspection part determines the content of the test | inspection based on the prescription | regulation of the said framework according to the test result of the said program test | inspection part, It was described in any one of Claims 1-3 characterized by the above-mentioned. Rule inspection device.   In the inspection by the program inspection unit, the framework inspection unit is provided on the condition that the ratio of the number of programs determined to be created in accordance with the program rules exceeds the predetermined threshold. The rule inspection device according to claim 4, wherein an inspection based on the framework rule is executed. An analysis step for analyzing the relationship between multiple programs used to create the application;
A framework inspection step for inspecting whether the relationship between the plurality of programs analyzed in the analysis step is a relationship in accordance with a framework specification that is a framework specification; and
The rule inspection method characterized by including. An analysis procedure for analyzing the relationship between multiple programs used to create the application;
Whether the relationship between the plurality of programs analyzed by the analysis procedure is a relationship in accordance with the read framework specification, by reading the framework specification from the storage unit that stores the framework specification that is the specification specification of the framework A framework inspection procedure to inspect whether or not,
A rule inspection program for causing a computer to execute.

Images