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

Abstract

<P>PROBLEM TO BE SOLVED: To check whether or not a source program is created in conformity with framework specifications. <P>SOLUTION: A check engine 120 checks whether or not the source program is created in conformity with the framework specifications on the basis of a check rule stored by a check rule storing part 125. A tool adapter 110 activates an external tool to carry out checking by the external tool, and a report output part 130 collects a check result by the external tool and a check result by the check engine 120, and outputs a report. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a rule inspection program, a rule inspection method, and a rule inspection device for diagnosing the quality of a framework use document created using a framework.

  In software development, after checking a source program created using a programming language such as Java (registered trademark, the same applies below) or C ++ with a compiler, a load module is created and a test is performed by executing the created load module. Done.

  Various technologies and tools that support such software development have been developed so far. For example, Patent Document 1 describes a program inspection system that efficiently performs an inspection of whether or not restrictions on the data type of each instruction constituting a program are correctly observed.

Japanese Patent No. 3360635

  In recent years, in the development of software, instead of developing a source program from scratch using a programming language, development using a framework has been performed. Here, the framework is a framework for developing software, and includes coding rules, component usage rules, templates, and the like. For example, Java or VB. Each NET includes a database access framework, a screen operation description framework, a form processing framework, and the like.

  Whether or not to develop a source program according to the framework specification not only affects the software development efficiency, but also greatly affects the standardization of the source program. In addition, if the source program is not developed according to the framework specification, the execution performance may be greatly reduced, and it is very important to develop the source program according to the framework specification.

  A compiler can check whether a source program created using a programming language is created in accordance with the language specification. However, it is impossible for a compiler to check whether a source program created using a framework is created according to the framework specification.

  Therefore, it is necessary to manually check whether the source program is created according to the framework specification, but it is difficult to accurately check various framework specifications manually. .

  The present invention has been made to solve the above-described problems caused by the prior art, and examines a framework use document such as a source program created using the framework to diagnose the quality, and It is an object of the present invention to provide a rule inspection program, a rule inspection method, and a rule inspection device that can improve the quality of a used document.

  In order to solve the above-described problems and achieve the object, the present invention stores in a storage device whether or not a source program created using a framework for a business application is created according to the framework specification. A framework inspection procedure for inspecting the read check rule by invoking the check module specified by the read check rule, and an inspection result output procedure for outputting a result inspected by the framework inspection procedure; As a check whether or not the framework inspection procedure has been created in accordance with the framework specifications, the consistency of the usage method between the common parts, the consistency between the business logic and the usage method of the common parts It is characterized by performing a test including sex.

  In addition, the present invention reads a check rule stored in a storage device to check whether a source program created using a framework for a business application is created according to the framework specification, and the read check A framework inspection step for inspecting by activating a check module specified by a rule; and an inspection result output step for outputting a result inspected by the framework inspection step. As an inspection of whether or not it is created in accordance with the work specification, an inspection including consistency of the usage method of the common parts and consistency of the business logic and the usage method of the common part is performed.

  In addition, the present invention reads a check rule stored in a storage device to check whether a source program created using a framework for a business application is created according to the framework specification, and the read check A framework inspection unit that inspects by activating a check module specified by a rule; and an inspection result output unit that outputs a result inspected by the framework inspection unit. As an inspection of whether or not it is created in accordance with the work specification, an inspection including consistency of the usage method of the common parts and consistency of the business logic and the usage method of the common part is performed.

  According to this invention, it is configured to inspect whether or not the source program is created in accordance with the framework specification and to output the inspection result, so that the quality of the source program can be diagnosed.

  According to the present invention, since the quality of the source program is diagnosed, the software developer's skill can be evaluated and the quality can be improved.

  Exemplary embodiments of a rule inspection program, a rule inspection method, and a rule inspection apparatus according to the present invention will be described below in detail with reference to the accompanying drawings.

  First, the concept of quality diagnosis according to the first embodiment will be described. FIG. 1 is an explanatory diagram for explaining the concept of quality diagnosis according to the first embodiment. As shown in FIG. 6A, in the quality diagnosis according to the first embodiment, it is checked whether a source program created using a framework such as a business application is created in accordance with the language specification. In addition, the quality of the source program is diagnosed by checking whether it is created according to the framework specifications. That is, it is checked whether or not the source program is created according to the rules to be observed when using the framework.

  In this way, by checking whether the source program is created according to the framework specification and diagnosing the quality of the source program, the standardization of the application development is promoted and the technical skill of the developer is evaluated. can do. In the case of outsourcing application development, the quality diagnosis according to the first embodiment can be used for acceptance inspection of a delivered source program, and can also be used for skill evaluation of a consignee.

  In the quality diagnosis according to the first embodiment, as shown in FIG. 1B, a language-dependent part such as Java or PL / SQL is plugged into a basic quality diagnosis apparatus that performs quality diagnosis based on a framework specification. To configure the quality diagnosis apparatus. Therefore, the quality diagnosis apparatus according to the first embodiment can flexibly cope with a source program created in any language.

  In the quality diagnosis according to the first embodiment, the quality diagnosis of the source program is performed using check rules. Therefore, the quality diagnostic apparatus can be easily customized by adding a specific check rule.

  Next, the configuration of the quality diagnostic apparatus according to the first embodiment will be described. FIG. 2 is a functional block diagram illustrating the configuration of the quality diagnostic apparatus according to the first embodiment. As shown in the figure, the quality diagnosis apparatus 100 includes a tool adapter 110, a check engine 120, a check rule storage unit 125, a report output unit 130, a common message management unit 140, and a main controller 150. .

  Tool adapter 110 includes FxCop,. This is a processing unit that activates other check tools such as TEST, converts check result data, and the like, and makes it possible to use various check tools from the quality diagnosis apparatus 100. The tool adapter 110 operates as an adapter for other check tools, so that various check tools can be used from the quality diagnosis apparatus 100.

  The check engine 120 is a processing unit that checks whether a source program is created according to the framework specification based on the check rule. The check rule storage unit 125 is a storage unit that stores check rules. The check engine 120 reads the check rules from the check rule storage unit 125, and checks the source program using the check rules in the read order. Details of the processing of the check engine 120 using the check rule will be described later.

  The report output unit 130 is a processing unit that outputs a tool activated from the tool adapter 110 and a check result by the check engine 120 in a unified format as one report. The common message management unit 140 is a management unit that manages messages handled by the quality diagnosis apparatus 100 in common.

  The main controller 150 is a control unit that controls processing of the entire quality diagnosis apparatus 100, and performs initialization of the quality diagnosis apparatus 100, activation of the tool adapter 110, the check engine 120, the report output unit 130, and the like.

  Next, details of processing of the check engine 120 using the check rule will be described. FIG. 3 is an explanatory diagram for explaining processing of the check engine 120 using check rules. As shown in the figure, the check engine 120 performs a static check of the source program by sequentially starting check modules corresponding to the respective check rules. The check rule is described in XML, and each check rule describes a name of a check module to be activated, a parameter passed to the check module, and the like. In FIG. 3, the check modules corresponding to the rules A to D are sequentially activated by the check engine 120 to perform quality diagnosis.

  FIG. 4 is a diagram showing a method for creating check rules and check modules. As shown in the figure, when a new check rule is created, a rule ID for identifying each check rule is assigned and a check process performed by the check rule is defined. Then, a specific procedure of the check process is described in a document, and a check module for performing the check process is created based on this description.

  For example, a check rule whose rule ID is “20102” is a rule that “confirms whether there is a description of a parameter class other than“ * ManagerParam ”in the View layer (* .aspx.vb) file”. Performs the check process of “getting the * .aspx.vb file as the processing target, obtaining the type of the variable where the variable is declared, and NG if the type of the variable is other than ManagerParam”. In FIG. 4, the corresponding check module is described in the Ruby language.

  FIG. 5 is a diagram illustrating an example of a check rule. As shown in the figure, each check rule includes a rule ID, a check module name, and the like. FIG. 5 shows check rules having rule IDs “20102”, “20103”, and “20104”.

  FIG. 6 is a diagram illustrating a check module corresponding to a check rule having a rule ID “20102” among the check rules illustrated in FIG. 5. By this check module, the process of “check if there is a description of a parameter class other than“ * ManagerParam ”in the View layer (* .aspx.vb) file” is performed.

  FIG. 7 is a diagram showing the correspondence between the specific processing of the check rule whose rule ID is “20102” and the source code of the corresponding check module. As shown in the figure, “* .aspx.vb file is the target of processing” corresponds to “if getFileName.execute ...” and “gets the type of the variable where the variable is declared” Corresponds to “variables = getVariableType.execute...” And “NG if the variable type is other than ManagerParam” corresponds to “re = Regexp.new (/ ManagerParam /)... FindWordResult.result”.

  FIGS. 8-1 to 8-3 show an outline (part) of other check rules. FIG. 8-1 shows an overview of check rules related to coding style, comments, databases, etc., FIG. 8-2 shows an overview of check rules related to SQL and exception processing, and FIG. 8-3 shows naming rules, declarations, etc. The outline of the check rule about is shown.

  For example, as a check rule related to SQL, as shown in FIG. 8-2, “in order to check the description rule of the SQL statement, detect whether uppercase and lowercase letters are unified in the description of the reserved word of SQL”, “ Detect whether a short name is specified after the table name, Detect whether * is present in the SELECT clause, Detect whether an arithmetic operation is targeted for comparison in the WHERE clause ”And“ Detect whether there is a description of JOIN ”.

  Next, a processing procedure of the quality diagnostic apparatus 100 according to the first embodiment will be described. FIG. 9 is a flowchart illustrating the processing procedure of the quality diagnostic apparatus 100 according to the first embodiment. As shown in the figure, in the quality diagnosis apparatus 100, the main controller 150 performs initialization processing (step S1), and starts the tool adapter 110, the check engine 120, and the report output unit 130 in order to perform quality diagnosis processing. .

  That is, the tool adapter 110 activates another check tool to perform a check (step S2), the check engine 120 performs a static check based on the check rule (step S3), and the report output unit 130 performs another check. The check result by the check tool and the check result by the check engine 120 are collected and output as a report (step S4).

  As described above, the main controller 150 sequentially activates the tool adapter 110, the check engine 120, and the report output unit 130 to perform quality diagnosis processing, thereby making it easier for the user to execute each tool individually. Various checks can be performed efficiently by operation.

  Next, a processing procedure of static check processing by the check engine 120 will be described. FIG. 10 is a flowchart showing a processing procedure of static check processing by the check engine 120. As shown in the figure, the check engine 120 acquires a list of target sources which are source programs to be checked (step S31). Also, a list of check rules and a list of check modules are acquired (steps S32 to S33).

  Then, while the check rule exists (step S34, Yes), the check module corresponding to each check rule is executed (step S35), and the execution result of each check module is temporarily saved (step S36).

  When all the check rules have been checked (No in step S34), the temporarily saved check results are collectively stored in a file (step S37), and the process is terminated.

  As described above, the check engine 120 sequentially executes the check modules corresponding to the respective check rules, thereby making it possible to check whether or not the source program is created in accordance with the framework specification.

  Next, a processing procedure of report output processing by the report output unit 130 will be described. FIG. 11 is a flowchart illustrating a processing procedure of report output processing by the report output unit 130. As shown in the figure, the report output unit 130 acquires a list of target sources (step S41).

  And while the result file with respect to a target source exists (step S42, Yes), a result file is read, a list of results is acquired (step S43), and a report is output (step S44). The report is output in the format (s) specified by the user from the CSV format, HTML format, and XML format.

  When processing of all the result files is completed (No at Step S42), it is determined whether or not there is HTML format output (Step S45). If there is HTML format output, Index.htm is set. Output (step S46).

  As described above, in the first embodiment, the check engine 120 checks whether the source program is created according to the framework specification and diagnoses the quality of the source program. As well as assessing the skill level of the person, the quality of the source program can be improved. Further, when entrusting the development of the source program, it is possible to evaluate the skill of the entrusted party and perform the acceptance inspection efficiently.

  In the first embodiment, since the check engine 120 checks the source program based on the check rules stored in the check rule storage unit 125, various checks can be flexibly performed only by creating the check rules. be able to.

  In the first embodiment, the tool adapter 110 activates another check tool and performs a check using another check tool, and the report output unit 130 summarizes the check result obtained by the other check tool and the check result obtained by the check engine 120. Therefore, the user need not execute each tool individually, and can efficiently check the source program.

  Although the quality diagnosis apparatus has been described in the first embodiment, a quality diagnosis program having the same function can be obtained by realizing the configuration of the quality diagnosis apparatus with software. Therefore, a computer that executes the quality diagnosis program will be described.

  FIG. 12 is a functional block diagram illustrating the configuration of the computer that executes the quality diagnosis program according to the first embodiment. As shown in the figure, the computer 200 includes a RAM 210, a CPU 220, an HDD 230, a LAN interface 240, an input / output interface 250, and a DVD drive 260.

  The RAM 210 is a memory that stores a program and a program execution result, and the CPU 220 is a central processing unit that reads the program from the RAM 210 and executes the program. The HDD 230 is a disk device that stores programs and data, and the LAN interface 240 is an interface for connecting the computer 200 to other computers via the LAN. The input / output interface 250 is an interface for connecting an input device such as a mouse or a keyboard and a display device, and the DVD drive 260 is a device for reading / writing a DVD.

  The quality diagnosis program 211 executed in the computer 200 is stored in the DVD, read from the DVD by the DVD drive 260, and installed in the computer 200. Alternatively, the quality diagnosis program 211 is stored in a database or the like of another computer system connected via the LAN interface 240, read from these databases, and installed in the computer 200. The installed quality diagnosis program 211 is stored in the HDD 230, read into the RAM 210, and executed by the CPU 220.

  In the first embodiment, the case where the quality of a source program created using a framework is checked has been described. However, the present invention is not limited to this and is created using a framework. The same can be applied to checking the quality of any framework-based document.

  Details of the framework according to the first embodiment will be described below. FIG. 13 is an explanatory diagram for explaining the framework according to the first embodiment. FIG. 2A shows a general framework, and FIG. 2B shows a framework according to the first embodiment.

  As shown in FIG. 2A, generally, a program is composed of a portion that performs different processing in each program and a portion that performs common processing in any program. A part that performs different processing in each program needs to be developed for each program, but a part that performs common processing in any program can be developed as a common part. Such common parts are generally called frameworks.

  On the other hand, as shown in FIG. 5B, the framework according to the first embodiment includes development standards and development tools in addition to the common parts. Here, the development standard is a document indicating a standard for software development, and in particular, a system design document describing an ideal usage method of common parts and a processing method that should not be performed is important. The development tool automatically generates source code that uses common parts. For example, when using the input check component, the development tool automatically generates a program described in an ideal usage method of the common component when the screen item for input check and the input check type are set.

  As described above, since the framework according to the first embodiment includes development standards and development tools in addition to the common parts, the quality diagnosis apparatus 100 uses the common parts used as a general framework check. Perform checks other than checks.

  FIG. 14 is an explanatory diagram for explaining a check performed by the quality diagnosis apparatus 100 other than the check of the usage method of the common parts. FIG. 2A shows a consistency check performed by the quality diagnosis apparatus 100 for a common part for which two input checks are performed. The quality diagnosis apparatus 100 checks the consistency of common parts and the usage method. Do. Even when the usage methods of the input check A and the input check B are correct, there is a case where inconsistency or unintentional operation occurs by combining the both, and the quality diagnosis apparatus 100 has the consistency of such common parts. Check.

  FIG. 5B shows an example of checking the usage method of common parts in relation to business logic. In this example, the quality diagnosis apparatus 100 performs a check such that the “screen type” is checked by the input check while the A screen item is described as “character type” in the business logic.

  FIG. 5C shows another example of checking the usage method of common parts in relation to business logic. In this example, the quality diagnosis apparatus 100 performs a check as to whether an input check or the like that should use a common component is originally implemented by business logic.

  FIG. 4D shows a check performed based on the system design document. The quality diagnosis apparatus 100 checks whether the contents defined in the system design document are correctly reflected in the source code.

  FIG. 15 is a diagram illustrating an example of a check rule for performing the check illustrated in FIG. Each check rule includes a check rule number, check rule classification information, and check contents. FIG. 15A shows a check rule for checking inconsistencies between input checks. For example, this check rule checks whether both a numerical check and a character check are performed.

  FIG. 15B shows a check rule for checking the usage method of common parts in relation to business logic. For example, in the business logic part, when the screen character position alignment is set to right alignment, the expected input character is assumed to be “numeric value (amount etc.)”, but the input check component “ Check whether or not “character check” is performed.

  FIG. 15C shows another check rule for checking the usage method of common parts in relation to business logic. This check rule checks whether screen item transcription parts are used when substituting screen data into variables. You can assign a screen item to a variable by using an assignment statement. However, when transferring a large number of screen items, it is more efficient to use a screen item transfer component.

  FIG. 15D shows a check rule for performing a check based on the method design document. This check rule checks whether or not five or more arguments are passed when data is transferred between the controller C and the manager M. When passing 5 or more data, it is described in the system design document that a variable is incorporated into an object and assigned.

  FIG. 16 is a diagram illustrating the effect of the quality check performed by the quality diagnostic apparatus 100. As shown in the figure, when the quality check by the quality diagnosis apparatus 100 is not performed, a program whose description method is different depending on the individual performs the quality check by the quality diagnosis apparatus 100, so that the program is based on a unified description method. The program is described as follows. Therefore, the readability and maintainability of the program can be improved.

  In the first embodiment, the case where all the check rules are checked has been described. However, if all check rules are applied to all programs, there is a problem as shown in FIG. FIG. 5A shows a case where all check rules are applied to all programs. In this case, there is a problem that the processing time of quality diagnosis is long.

  Therefore, as shown in FIG. 5B, it is conceivable to roughly determine the type of program and change the check rule to be applied according to the program type. FIG. 4B shows a case where a screen system check rule is applied to a screen system program. However, if the check rule to be applied is changed according to the roughly determined program type, there is a possibility that the check rule may be omitted.

  In addition, as shown in FIG. 5C, the user may select a check rule to be used for each rule. However, when the number of check rules increases, the operation of selecting becomes complicated.

  Therefore, in the second embodiment, a quality diagnosis apparatus that automatically selects a check rule to be used and performs a quality diagnosis will be described. FIG. 18 is an explanatory diagram for explaining automatic selection of a check rule by the quality diagnostic apparatus according to the second embodiment. As shown in the figure, the quality diagnostic apparatus according to the second embodiment checks the characteristics of all programs to be diagnosed, and automatically selects and selects only the necessary check rules from all the check rules. Apply the check rule only and perform quality diagnosis. As described above, the quality diagnosis is performed by automatically selecting only the check rules that are required by the quality diagnosis apparatus, so that accurate quality diagnosis can be performed efficiently.

  FIG. 19 is a diagram illustrating the structure of the check rule according to the second embodiment. As shown in the figure, each check rule includes an automatic selection function unit and a check processing implementation unit. The automatic selection function unit is used to select check rules, and the check processing implementation unit is used to check programs.

  For example, a normal business application program is classified into three layers of “screen”, “controller”, and “logic”, and the file name of the screen system program always ends with “.aspx.vb”. Therefore, the automatic selection function part of the check rule used for checking the screen system program describes that the check process is performed for the file whose file name ends with ".aspx.vb". .

  Therefore, the quality diagnosis apparatus according to the second embodiment determines whether or not the automatic selection function unit describes that the check process is performed on the file whose file name ends with “.aspx.vb”. By this, it is possible to automatically select a check rule to be used for checking screen programs.

  FIG. 20 is an explanatory diagram for explaining the processing procedure of the quality diagnostic apparatus according to the second embodiment. As shown in the figure, the quality diagnostic apparatus according to the second embodiment first executes a rule automatic selection function for selecting a check rule, and selects a check rule necessary for checking a program to be diagnosed. Here, since the target program is a screen-type program, a check rule for checking a file whose file name ends with “.aspx.vb” is selected.

  Then, the quality diagnosis apparatus according to the second embodiment executes only the selected check rule. Here, only the check rule for checking the screen program is executed. As described above, the quality diagnosis apparatus according to the second embodiment can efficiently perform a quality diagnosis by selecting a check rule necessary for checking a diagnosis target program and executing only the selected check rule. .

  FIG. 21 is a functional block diagram illustrating the configuration of the quality diagnostic apparatus according to the second embodiment. Here, for convenience of explanation, functional units that play the same functions as the respective units shown in FIG.

  As illustrated in FIG. 21, the quality diagnosis apparatus 300 according to the second embodiment is different from the quality diagnosis apparatus 100 illustrated in FIG. 2 in that a check engine 320 and a check are used instead of the check engine 120 and the check rule storage unit 125. Each has a rule storage unit 325.

  The check rule storage unit 325 is a storage unit that stores the check rule having the configuration illustrated in FIG. The check engine 320 selects and executes only the check rules necessary for checking the diagnosis target program from the check rules stored in the check rule storage unit 325.

  As described above, in the second embodiment, the check rule storage unit 325 stores the check rule including the automatic selection function unit and the check processing implementation unit, and the check engine 320 stores the check rule stored in the check rule storage unit 325. Since only the check rules necessary for checking the diagnosis target program are selected and executed from the rules, the quality diagnosis can be performed efficiently and accurately.

  In quality diagnosis using check rules, it is possible to check a framework suitable for each user by adding a check rule specialized for each user.

  However, as shown in FIG. 22, the check rule created for each user is more likely not to be strictly verified / inspected as compared to the commonly used check rule, and the accuracy / quality of the check rule itself is high. May not be expensive. For this reason, the result of the quality diagnosis performed using the check rule defined by the user is not always correct. Therefore, in order to perform a quality diagnosis with high accuracy, it is necessary to check the quality of the check rule itself.

  Therefore, in the third embodiment, a quality diagnostic apparatus having a function for evaluating the quality of a check rule will be described. FIG. 23 is an explanatory diagram for explaining automatic evaluation of check rules by the quality diagnostic apparatus according to the third embodiment.

  As shown in the figure, the quality diagnosis apparatus according to the third embodiment totals the check results of the program for each check rule. For example, in FIG. 23, for “rule A”, the number of times of application, the number of times that the check result is OK (+), and the number of times that the check result is NG (−) are tabulated.

  Then, the quality diagnosis apparatus according to the third embodiment compares the total value of OK and NG, that is, the number of times of application with the predetermined threshold range, and if the number of times of application is outside the predetermined threshold range, the check rule is invalid. It is determined that there is a problem with the check rule because it is a case where a large amount is applied appropriately or a case where a small amount is applied inappropriately.

  On the other hand, when the number of applications is within a predetermined threshold range, it is determined that the quality of the program to be checked is high when OK is high, and the quality of the program to be checked is high when NG is high. Is determined to be low.

  Further, the quality diagnosis apparatus according to the third embodiment compares OK and NG with respective predetermined threshold values, and determines that the program is good by applying the check rule when both are equal to or higher than the respective predetermined threshold values. Since there are many cases where it is determined that the check rule is bad, it is determined that there is a problem with the check rule.

  In addition, the quality diagnosis apparatus according to the third embodiment classifies the check rules into categories, and totals the number of application times for each category. Then, the difference between the number of times of applying the check rule belonging to a certain category and the average value of the number of times of applying all the check rules belonging to the category is compared with a predetermined threshold value, and if it exceeds the predetermined threshold value, there is a problem with the check rule. Is determined.

  The quality diagnosis apparatus according to the third embodiment outputs a check rule determination result and a program quality determination result as a report. Thus, the quality diagnostic apparatus according to the third embodiment can improve the quality of the check rule itself by counting the application results of the check rules and evaluating the check rules based on the total results.

  FIG. 24 is a functional block diagram of the configuration of the quality diagnostic apparatus according to the third embodiment. Here, for convenience of explanation, functional units that play the same functions as the respective units shown in FIG.

  As shown in FIG. 24, the quality diagnosis apparatus 400 according to the third embodiment has a check engine 420 instead of the check engine 320 as compared with the quality diagnosis apparatus 300 shown in FIG. A storage unit 460 and a rule evaluation unit 470 are included.

  The check engine 420 checks the program and counts the number of applied check rules for each application result (OK and NG) and stores it in the application result storage unit 460.

  The application result storage unit 460 is a storage unit that stores the number of times for each application result for each check rule. Further, the application result storage unit 460 stores the category classification result of the check rule.

  The rule evaluation unit 470 is a processing unit that evaluates each check rule based on the data stored in the application result storage unit 460. In other words, the rule evaluation unit 470 compares the number of times each check rule is applied with a predetermined threshold range, and evaluates each check rule. Also, the rule evaluation unit 470 evaluates the quality of the program and the check rules by comparing OK and NG with a predetermined threshold value.

  Further, the rule evaluation unit 470 calculates an average value of the number of application times for each category, compares the difference between the number of application times of each check rule belonging to the category with a predetermined threshold value, and evaluates each check rule. The rule evaluation unit 470 outputs a check rule evaluation result and a program quality determination result as a report.

  As described above, the number of times is calculated for each application result (OK and NG) for the check rule applied by the check engine 420, and the rule evaluation unit 470 evaluates each check rule based on the total result of the application result of each check rule. By doing so, the quality of the check rule can be improved.

(Appendix 1) A framework inspection procedure for inspecting whether a framework use document created using the framework is created in accordance with the framework specification;
An inspection result output procedure for outputting a result inspected by the framework inspection procedure;
A quality diagnosis program characterized by causing a computer to execute.

(Additional remark 2) The said framework test | inspection procedure test | inspects a framework utilization document based on the check rule which inspects whether the framework utilization document is produced according to framework specification, It is characterized by the above-mentioned. The quality diagnostic program described in

(Supplementary Note 3) The check rule includes an identifier for identifying a check module that executes a check,
The quality diagnosis program according to appendix 2, wherein the framework inspection procedure inspects a framework use document by executing a check module identified by an identifier included in a check rule.

(Supplementary Note 4) The quality diagnosis program according to Supplementary Note 1, 2, or 3, wherein the framework use document inspected by the framework inspection procedure is a source program.

(Additional remark 5) The quality diagnostic program of Additional remark 4 characterized by the test | inspection by the said framework test | inspection procedure including the test | inspection of whether the access to a database is performed according to framework specification.

(Additional remark 6) The other tool execution procedure which starts other check tools and inspects with other check tools is made to perform further on a computer,
6. The quality diagnosis program according to appendix 4 or 5, wherein the inspection result output procedure collectively outputs a result of the inspection by the framework inspection procedure and a check result by the other tool execution procedure as a report.

(Appendix 7) A framework inspection step for inspecting whether a framework use document created using the framework is created in accordance with the framework specification;
An inspection result output step for outputting a result of inspection by the framework inspection step;
A quality diagnostic method characterized by comprising

(Additional remark 8) The said framework inspection step inspects a framework utilization document based on the check rule which inspects whether the framework utilization document is produced according to framework specification, It is characterized by the above-mentioned. The quality diagnosis method described in 1.

(Supplementary note 9) The check rule includes an identifier for identifying a check module that executes a check,
9. The quality diagnosis method according to appendix 8, wherein the framework inspection step inspects the framework use document by executing a check module identified by an identifier included in the check rule.

(Supplementary note 10) The quality diagnosis method according to supplementary note 7, 8 or 9, wherein the framework utilization document inspected by the framework inspection step is a source program.

(Supplementary note 11) The quality diagnosis method according to supplementary note 10, wherein the inspection in the framework inspection step includes an inspection of whether or not access to the database is performed in accordance with a framework specification.

(Additional remark 12) The other tool execution step which starts other check tools and inspects with other check tools is further included,
12. The quality diagnosis method according to appendix 10 or 11, wherein the inspection result output step collectively outputs a result of the inspection in the framework inspection step and a check result in the other tool execution step as a report.

(Supplementary note 13) Framework checking means for checking whether or not a framework use document created using the framework is created in accordance with the framework specification;
Inspection result output means for outputting the result of inspection by the framework inspection means;
A quality diagnosis apparatus comprising:

(Additional remark 14) The said framework inspection means inspects a framework utilization document based on the check rule which inspects whether the framework utilization document is produced according to framework specification, The additional remark 13 characterized by the above-mentioned. The quality diagnostic apparatus described in 1.

(Supplementary note 15) The check rule includes an identifier for identifying a check module that executes a check,
15. The quality diagnosis apparatus according to appendix 14, wherein the framework inspection unit inspects a framework use document by executing a check module identified by an identifier included in a check rule.

(Supplementary note 16) The quality diagnosis apparatus according to supplementary note 13, 14 or 15, wherein the framework utilization document inspected by the framework inspection means is a source program.

(Supplementary note 17) The quality diagnosis apparatus according to supplementary note 16, wherein the inspection by the framework inspection unit includes an inspection of whether or not access to the database is performed in accordance with a framework specification.

(Additional remark 18) The other tool execution means which starts other check tools and inspects with other check tools is further provided,
18. The quality diagnosis apparatus according to appendix 16 or 17, wherein the inspection result output unit collectively outputs a result of the inspection by the framework inspection unit and a check result by the other tool execution unit as a report.

  As described above, the rule inspection program, the rule inspection method, and the rule inspection apparatus according to the present invention are useful for software development using a framework.

It is explanatory drawing for demonstrating the concept of the quality diagnosis which concerns on the present Example 1. FIG. 1 is a functional block diagram illustrating a configuration of a quality diagnostic apparatus according to a first embodiment. It is explanatory drawing for demonstrating the process of the check engine using a check rule. It is a figure which shows the creation method of a check rule and a check module. It is a figure which shows the example of a check rule. FIG. 6 is a diagram illustrating a check module corresponding to a check rule having a rule ID “20102” among the check rules illustrated in FIG. 5. It is a figure which shows a response | compatibility with the specific process of the check rule whose rule ID is "20102", and the source code of a corresponding check module. It is a figure (1) which shows the outline (part) of other check rules. It is a figure (2) which shows the outline (part) of other check rules. It is FIG. (3) which shows the outline | summary (part) of another check rule. It is a flowchart which shows the process sequence of the quality diagnostic apparatus which concerns on the present Example 1. FIG. It is a flowchart which shows the process sequence of the static check process by a check engine. It is a flowchart which shows the process sequence of the report output process by a report output part. FIG. 2 is a functional block diagram illustrating a configuration of a computer that executes a quality diagnosis program according to the first embodiment. It is explanatory drawing for demonstrating the framework which concerns on the present Example 1. FIG. It is explanatory drawing for demonstrating the check which a quality diagnostic apparatus performs other than the check of the usage method of a common component. It is a figure which shows the example of the check rule which performs the check shown in FIG. It is a figure which shows the effect of the check by a quality diagnostic apparatus. It is explanatory drawing for demonstrating the subject of the quality diagnosis using a check rule. It is explanatory drawing for demonstrating the automatic selection of a check rule. It is a figure which shows the structure of the check rule which concerns on the present Example 2. FIG. It is explanatory drawing for demonstrating the process sequence of the quality diagnostic apparatus which concerns on the present Example 2. FIG. It is a functional block diagram which shows the structure of the quality diagnostic apparatus which concerns on the present Example 2. It is explanatory drawing for demonstrating the other subject of the quality diagnosis using a check rule. It is explanatory drawing for demonstrating the automatic evaluation of a check rule. It is a functional block diagram which shows the structure of the quality diagnostic apparatus which concerns on the present Example 3.

Explanation of symbols

100, 300, 400 Quality diagnosis device 110 Tool adapter 120, 320, 420 Check engine 125, 325 Check rule storage unit 130 Report output unit 140 Common message management unit 150 Main controller 200 Computer 210 RAM
211 Quality diagnosis program 220 CPU
230 HDD
240 LAN interface 250 Input / output interface 260 DVD drive 460 Application result storage unit 470 Rule evaluation unit

Claims (7)

Reads the check rule stored in the storage device and checks whether the source program created using the framework for the business application is created according to the framework specification and specified by the read check rule A framework inspection procedure to inspect by launching the module;
An inspection result output procedure for outputting a result inspected by the framework inspection procedure;
To the computer,
In the framework inspection procedure, as an inspection whether or not it is created according to the framework specification, an inspection including consistency of the usage method of the common parts and consistency of the business logic and the usage method of the common part is performed. A rule inspection program characterized by that.   The rule inspection program according to claim 1, wherein the framework inspection procedure selects a check rule based on characteristics of a source program to be inspected to inspect the source program. The check rule is composed of an automatic selection function unit used for rule selection and a check processing implementation unit that executes inspection,
The framework inspection procedure includes:
A rule selection procedure for selecting a check rule using the automatic selection function unit;
The rule inspection program according to claim 2, further comprising: causing a computer to execute an inspection execution procedure for executing an inspection based on a check processing implementation unit of a check rule selected by the rule selection procedure. The framework inspection procedure collects data related to the application result of the check rule and writes it to the storage device for each applied check rule.
The rule inspection program according to claim 1, further causing a computer to execute a rule evaluation procedure for reading data written for each check rule by the framework inspection procedure from a storage device and evaluating each check rule. The framework inspection procedure writes the number of times each check rule is applied to a storage device. The rule evaluation procedure evaluates each check rule based on whether or not the number of times each check rule is applied falls outside a predetermined threshold range. The rule inspection program according to claim 4, wherein: Reads the check rule stored in the storage device and checks whether the source program created using the framework for the business application is created according to the framework specification and specified by the read check rule A framework inspection step for inspecting by invoking the module;
An inspection result output step for outputting a result of inspection by the framework inspection step;
Including
In the framework inspection step, as an inspection of whether or not it is created according to the framework specification, an inspection including consistency of the usage method of the common parts and consistency of the business logic and the usage method of the common parts is performed. A rule inspection method characterized by that. Reads the check rule stored in the storage device and checks whether the source program created using the framework for the business application is created according to the framework specification and specified by the read check rule Framework inspection means for inspecting by activating the module;
Inspection result output means for outputting the result of inspection by the framework inspection means;
With
The framework inspection means performs an inspection including consistency between the usage methods of the common components and consistency between the business logic and the usage methods of the common components as an inspection whether or not the framework is created according to the framework specification. A rule inspection device characterized by that.

Images