JP6076660B2 - Program structure evaluation system, program - Google Patents

Description

  The present invention relates to an apparatus for analyzing and evaluating a program structure.

In software development, the structure of the entire software is first determined, and the program is implemented according to this structure.
In the new development, what is created according to the software structure is created, but depending on the person in charge, the structure may be ignored and the variables of other functions may be rewritten safely. In addition, a program created with a structure that conforms to the specifications will be revised on an ad hoc basis without any understanding of the overall structure by derivation development or emergency response in the event of a failure, and the changes will be reviewed. You may end up offering the software without any trouble. As a result, the so-called spaghetti program makes it impossible to know the scope of the effect of the modification, causes a malfunction of an unexpected function, and increases the number of work steps for quality assurance. In the worst case, the customer's credit may be lost and the damage may be caused.

Originally, it is known that a review by a reviewer who understands the overall structure and corrects it is desirable, but in practice, it is often not implemented due to the following reasons. However, the overall structure (the initial design concept) is not fully understood.-Due to quick delivery, the review is not conducted by experts.-The reviewer is too busy to review. This is a technique for analyzing and managing programs or evaluating scores. For example, conventional techniques described in Patent Documents 1 and 2 are known.

  The prior art of Patent Document 1 makes it easy to generate a program structure diagram that clearly shows a common part and to reuse the common part in the program structure by analyzing the common structure in the program.

  The prior art of Patent Document 2 prioritizes each evaluation index in the order in which quality improvement is required, and provides accurate and efficient quality evaluation and efficient and effective quality improvement. Work can be planned. The above score evaluation is to calculate the evaluation score according to the evaluation score calculation standard for each evaluation item unit such as checklist number density, defect number density, coverage rate, scale, difficulty, defect importance and defect analysis code. It is.

JP 2007-115155 A JP 2000-56961 A

  Here, conventionally, there are tools for scoring the program itself according to quality characteristics (for example, “Adqua (registered trademark)” of OGIS Research Institute, “eXquot (registered trademark)” of Toyo Technica, etc.). For example, Adqua is a tool that can quantitatively evaluate the quality of embedded software. Specifically, the software is scored in terms of five quality characteristics: “reliability”, “efficiency”, “maintainability”, “portability”, and “reusability”.

  Here, as a definition of the software structure, there is, for example, a restriction item related to access (calling or the like) between functions in software including a plurality of functions. This is, for example, restrictions on access between functions, restrictions on access from function to variables, and the like. Alternatively, when the plurality of functions have a hierarchical structure, restrictions related to such a hierarchy are also included.

  Even when a program is created in accordance with the definition (limitation) of the software structure in this sense, it is natural that a violation may occur for some reason. The number of violations affects quality. Moreover, when remodeling a program created in the past, it is desired to at least not deteriorate the quality.

  For example, in the case of an object-oriented program, a class diagram is created and the program is created and inherited accordingly, but old software is created based on the traditional structured design concept instead of such a modeled design concept. Moreover, in order to reuse such old software (legacy assets), there are cases where it is created as new software by remodeling. When such old software is evaluated according to the above software structure, the number of violations often becomes large. And when creating a modified version from such old software, there are many cases where it is difficult to correct even if it is known that it is a violation, and it is possible to maintain the current status (no more violations). There is a case where it is good.

  Based on the above, it is assumed that the judgment of whether or not a program is created in accordance with the software structure in the above-described sense (for example, whether or not the current status can be maintained at least) is evaluated by checking the entire program text. It would be desirable to be able to do this without the need for laborious work. For example, it is desired that an objective and accurate determination can be made by scoring the violations.

  On the other hand, in the existing tools such as the above-mentioned Adqua and the prior arts of Patent Documents 1 and 2, the definition of the software structure in the above-described meaning, that is, restrictions and hierarchies related to access between functions in the software composed of the plurality of functions. It is not considered to evaluate the restrictions related to the above by scoring.

  In addition, it is desired that the user's effort required for scoring and software evaluation regarding violations described above should be reduced as much as possible. Or, when new software is created by reusing legacy assets mentioned above, or when software is upgraded, it is desirable to be able to accurately increase and decrease violations (without overlooking). It is.

  It is an object of the present invention to easily evaluate whether or not a program has been created in accordance with a software structure design that has restrictions on access between functions in software composed of a plurality of functions by analyzing and scoring the program. Further, it is possible to provide a program structure evaluation system or the like that can reduce the labor of the user for that purpose, or eliminates oversight of a newly generated access violation.

  The program structure evaluation system according to the present invention is a function that becomes a call source and a call destination in accordance with restrictions on access between functions of software composed of a plurality of functions in a computer system for performing predetermined evaluation for arbitrary software. For each function pair that is a combination of a function type / variable type of a function, a violation presence / absence information storage means for storing violation presence / absence information in which violation presence / absence and the allowable number of violations are stored; Each time a process for calling an arbitrary function / variable of another function from an arbitrary function is detected by sequentially referring to a program source statement, the function type / variable type of the called function / variable is determined. Violation determination means for determining whether or not the call is a violation with reference to the violation presence / absence information, and determination by the violation determination means A totaling means for counting the number of violations of each function or / and the entire software to be evaluated based on the results, and the total software to be evaluated or / and / or based on the total number of violations by the counting means An evaluation score calculating means for calculating an evaluation score for each function; and a violation presence / absence information generating means for generating the violation presence / absence information and storing the violation presence / absence information storage means in advance based on the software to be evaluated; Have

  According to the program structure evaluation system and the like of the present invention, the program is analyzed and scored as to whether or not the program has been created in accordance with the software structure design with restrictions on access between functions in the software composed of a plurality of functions. By doing so, it is possible to easily evaluate, and further, it is possible to reduce the trouble of the user for that purpose, or it is possible to avoid overlooking a newly generated access violation.

It is a block diagram of the whole program evaluation system of this example. It is a figure which shows an example of a software structure (a hierarchy and a function). It is an example of a format of a hierarchy definition table. It is a specific example of a hierarchy definition table (registration). It is a specific example of an access violation exception registration file (registration). (A) is an access violation count file, and (b) is a specific example of the total result. (A), (b) is an example of information set in the operation information definition table. (A) is a totaling result after weighting, and (b) is a specific example of an access violation score file. It is a figure which shows the specific example of a deviation value calculation process. It is a figure which shows the flow of a process and work concerning semi-automatic creation of a hierarchy definition table and an access violation exception registration file. It is a specific example of a program source. It is a specific example of a setting procedure of “hierarchy registration & input check”. It is a specific example of a setting procedure of “access violation exception permission registration”. The flow of work and processing related to access violation discrimination is shown. It is a flowchart figure of a server main process part. It is a process flowchart figure of a definition access task part. It is a process flowchart figure of a definition production | generation task part. (A) is a flowchart of “program analysis processing”, and (b) is a detailed flowchart of step S61. It is a flowchart figure of a hierarchy registration check process. It is a flowchart figure of a hierarchy violation exception detection process. It is a flowchart figure of "access violation exception registration file creation processing" FIG. 11 is a flowchart of “hierarchy definition table comparison process”. It is a flowchart figure of "access exception permission file comparison process". FIG. 6 is a processing flowchart of the scoring task unit 12. It is an example of a program based on rules.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a configuration diagram of the entire program structure evaluation system of the present example, and particularly shows a functional configuration of the management server.

  The illustrated program structure evaluation system has a configuration in which an operation terminal 1 for an operator to operate and a management server 10 that executes evaluation (scoring etc.) related to a software structure related to an arbitrary program are connected to a network 2. It has become. The network 2 may be a general network such as a LAN or the Internet. Data / commands and the like are transmitted and received between the operation terminal 1 and the management server 10 via the network 2.

  However, the present invention is not limited to this example. For example, the management server 10 alone may constitute a program structure evaluation system. Of course, in this case, the management server 10 also has the function of the operation terminal 1. For example, various requests to be described later are requests that the management server 10 itself responds to this instruction to the server main processing unit 11 by a developer or the like operating the keyboard or the like of the management server 10 to give a desired instruction. Will be issued.

  The operation terminal 1 is, for example, a general personal computer or the like. Although not shown in particular, the operation terminal 1 has a function for displaying a screen for allowing an operator (user) to select and specify an arbitrary command / button, or a user selects / specifies And a function for transmitting a request (command) corresponding to the command button to the management server 10 via the network 2.

Examples of the type of request include “scoring request”, “definition setting request”, and “definition generation request” described later.
The management server 10 includes various functional units such as a server main processing unit 11, a scoring task unit 12, a definition access task unit 13, and a definition generation task unit 14. The processing functions of these various functional units are realized by a CPU (not shown) reading and executing a predetermined application program stored in advance in a storage device (hard disk, memory, etc.) not shown. The various functional units and the processes corresponding to the various requests will be described later with reference to various flowcharts and the like.

Further, the management server 10 stores and holds the deviation value counting file 15 in the storage device or the like.
In addition, the management server 10 stores various information / programs corresponding to each product (software) in the storage device or the like (this storage includes storage of temporarily generated information and the like). ).

  That is, in the example shown in the figure, for each of product A and product B, a hierarchy definition table (under construction) 21, a hierarchy definition table (registration) 22, an operation information definition table 23, an access violation count file 24, and an access violation score file 25 Various tables of the access violation exception registration file (during creation) 26, the access violation exception registration file (registration) 27, the program source 28, and the like are stored. The program source 28 is composed of a plurality of program files constituting the product A, for example.

In the figure, only various information / programs for the product A are shown, but for the product B, various information / programs corresponding to the product are stored in a similar manner.
The server main processing unit 11 accepts any request from the operation terminal 1 and calls any one of the scoring task unit 12, the definition access task unit 13, and the definition generation task unit 14 in accordance with this request to execute the process. However, in the following description, it is assumed that the server main processing unit 11 may be omitted without being described one by one.

  The scoring task unit 12 is called from the server main processing unit 11 to evaluate the program source 28 when the request from the operating terminal 1 is an evaluation (scoring etc.) regarding the program source 28 of an arbitrary product. (Scoring etc.) is performed, and in some cases, a deviation value or the like is further created. The access violation counting file 24 and the access violation scoring file 25 are generated in accordance with the scoring process of the scoring task unit 12. Details will be described later.

The definition access task unit 13 executes and manages data access (read / write) processing for tables, files, and the like in response to a request from the operation terminal 1.
The definition generation task unit 14 executes and manages setting check, automatic generation of setting data, and the like by reading out a corresponding process (program) in response to a request from the operation terminal 1.

In this example, the server main processing unit 11 manages the definition access task unit 13 and the definition generation task unit 14, but the present invention is not limited to this example.
The various tables / files are classified as follows, for example.
(A) Work file / hierarchy definition table (under construction) 21
Access violation exception registration file (under construction) 26
(B) Table and hierarchy definition table (registration) 22 defined at the time of hierarchy evaluation
-Operation information definition table 23
(C) File access violation exception registration file (registration) 27 created for hierarchical evaluation
・ Access violation count file 24
・ Access violation score file 25
Deviation value counting file 15
Here, FIG. 2 shows an example of the software structure (hierarchy and function).

The example of the software structure in FIG. 2 is an example of a software structure in which a plurality of functions have a hierarchical structure, and includes a first hierarchy (lowermost layer), a second hierarchy (intermediate hierarchy), and a third hierarchy (upper hierarchy). It is assumed that there are layers, and two functions exist as an example for each layer. That is, the first hierarchy has a function 1-1 and a function 1-2. Similarly, the second layer has functions 2-1 and 2-2, and the third layer has functions 3-1 and 3-2. As a specific example of the software structure in FIG. There may be some so-called “embedded software”. As is well known, “embedded software” is software on a computer system (embedded system) for providing a specific function incorporated in a home appliance or industrial device. The above Adqua etc. are mainly used for quality evaluation of embedded software.

  Here, as an example of the software structure related to the program for incorporation, there is a case where functions are hierarchized and classified into, for example, an application, middle (middleware), and OS (driver). That is, as for the hierarchy, the application is the upper layer, the middle is the middle layer, and the OS (driver) is the lowermost layer (lower layer). Basically, an arbitrary function at an arbitrary level calls another function at the same level as itself or another function at a level one level below. Of these, regarding the call of the hierarchy one level below, in the above example, the application calls the middle, and the middle calls the OS (driver).

  In other words, invoking a function in the lower two layers is a violation. That is, calling an OS (driver) by an application is a violation. In addition, calling a higher-order function is also a violation. That is, it is a violation for the middle to call an application and for the OS (driver) to call a middle or an application.

As will be described later, it is also a violation for another function to call a local variable / local function related to an arbitrary function.
In addition, the call of the other function from the above-mentioned arbitrary function is, for example, the call of the function of the other function from the function of the arbitrary function or the call of the variable of the other function from the function of the arbitrary function. . However, the present invention is not limited to this, and calling within the own function is also performed. That is, a function of an arbitrary function calls another function in the same function, or an arbitrary function calls an arbitrary variable in the same function. However, since calling within the own function does not basically violate, in this description, description related to calling within the own function may be omitted.

Each of the above functions is realized by a plurality of program files constituting the program source 28, respectively. As shown in FIG. 2, the functions (variables) used for program description of each program file are API functions (global functions), local functions, global variables, local variables, etc., as shown in FIG. With the features of
(I) API function; function that can be accessed from outside the function (ii) local function; function that can be accessed only within the function (iii) global variable; variable that is assumed to be accessed from outside the function (iv) Cull variable: Variable used only within the function Basically, calling a local function or a local variable in any function from another function is a violation regardless of the hierarchical structure.

The API (Application Program Interface) function and local function are examples of function types, and the global variable and local variable are examples of variable types.
As described above, what has been described with reference to FIG. 2 is a specific example of the above-mentioned “restrictions relating to access between functions and restrictions relating to hierarchies in software composed of a plurality of functions”. In this system, the evaluation target software (program source 28) can be scored for evaluation related to “restrictions related to access between functions and restrictions related to hierarchies in software consisting of a plurality of functions”. it can.

  As will be described later, in this example, the number of violations is calculated and the evaluation score is calculated for each function type / variable type. However, the present invention is not limited to this example. In this example, basically (unless there is no violation), all functions belong to either an API (function) or a local function, and all variables are either global variables or local variables. However, the present invention is not limited to this example.

  For example, a developer or the like creates a hierarchy definition table (registration) 22 in advance according to the software structure (restrictions related to the hierarchy and functions) shown in FIG. Using this hierarchy definition table (registration) 22, scoring / evaluation is performed. Here, the hierarchy definition table (registration) 22 may be created by manually inputting data by a user such as a developer, or may be created semi-automatically (as described later, Very little data is entered manually by the user).

  This is stored in the management server 10 as a hierarchy definition table (registration) 22 when the hierarchy definition table is finally completed after the hierarchy definition table 21 being created is in the process of being created. is there. Also, an access violation exception registration file (registration) 27 is created, and this file 27 is used for semi-automatic generation of the hierarchy definition table. Also in this case, after the access violation exception registration file (being created) 26 is in the process of being created, the access violation exception registration file is finally completed. Is stored as Further, the access violation exception registration file (during creation) 26 can be used for determining whether the access violation has increased or decreased. Details will be described later. Note that the access violation exception registration file (registration) 27 is also generated semi-automatically, and the work burden on the user can be reduced.

  The creation of the hierarchy definition table by a developer or the like may be performed on the operation terminal 1 side or the management server 10 side. In any case, the management server 10 semi-automatically creates the hierarchy definition table. Since it is generated, the labor of input work is reduced, and the creation efficiency is improved.

  The hierarchy definition table (registration) 22 includes, for example, an arbitrary function serving as a call source and a function type / variable type of an arbitrary function serving as a call destination in accordance with a software structure in which a plurality of functions have a hierarchical structure. It is a table in which the presence or absence of violations and the number of allowable violations are registered for each combination (pair). The hierarchy definition table (registration) 22 is a setting table for detecting an access violation.

  Here, FIG. 3 shows a format example of the hierarchy definition table. Note that FIG. 3 can also be said to show a specific example of the hierarchy definition table 21 (during creation). In other words, it is still in the process of being created and has not been completed. FIG. 4 shows a specific example of the hierarchy definition table (registration) 22. This can be said to indicate a completed state, not in the middle of creation. 3 omits the caller 36 shown in the figure, but actually, for example, as shown in FIG. 4, the caller 36 is set with a function number of each function (six functions in the example shown). .

  As shown in FIG. 3, the hierarchy definition table (during creation) 21 has an arbitrary function (calling source 36) as a calling source in accordance with a software structure in which a plurality of functions shown in FIG. ) And “each function type / variable type of each function as a call destination” (call destination 35). Further, by using an access violation exception registration file (registration) 27 as will be described later, the existence of violations for each pair ('0' and '1' in the figure) and the allowable number of violations are automatically registered. As a result, a hierarchy definition table (registration) 22 of FIG. 4 to be described later is obtained.

  The registration of the presence / absence of violation ("0" or "1" in the figure) and the allowable number of violations is not limited to automatic, and may be arbitrarily set manually by the user, for example. In this case, naturally, the effect of reducing the user's labor is reduced.

  The illustrated function name 31, function number 33, and function code 34 in the hierarchy definition table (under construction) 21 shown in FIG. 3 are all “function type / variable type of each function to be called”. "Optional function" is shown, and therefore all three are not necessarily required. The hierarchy number (layer) 32 is a number indicating the hierarchy (any one of the three hierarchies) to which the “arbitrary function” belongs.

  For each “arbitrary function”, the call destination 35 is classified into the above four items (two types of function types, two types of variables; API (function), local function, global variable, local variable) for each function. Has been. The hierarchy definition table (registration) 22 indicates whether or not there is an access violation between functions for the call destination by the caller for every four items for each hierarchy and function.

  The function name 31 is the name of the function (predetermined and registered). The function code 34 (SCI, SYS, etc.) is an identification code of the function (predetermined and registered). It can be said that the function code 34 is a code for grouping a plurality of functions by the program source 28. The function number 33 is composed of the function hierarchy and a serial number in the hierarchy.

Further, it can be said that the hierarchy number (layer) 32 and the hierarchy number (layer) 32 are data relating to the hierarchy. Both of them are not necessarily required, and only one of them may be used.
In this example, it is assumed that the function code 34 is used as the name of a program source file or function / variable associated with the function.

Here, the registration contents of the presence / absence of violation and the allowable number of violations may be numerical values, for example, or may be symbols such as A, B, C, D described later.
FIG. 4 shows an example in which numerical values are input. The numerical values are, for example, “0” and “1” indicating the presence or absence of the violation, where “0” is “no violation” and “1” is “ It means “violated”, but is not limited to this example. For example, the set values are 0, 1, 2,... N (n: an arbitrary integer), and these set values are, for example, the presence or absence of hierarchy violations and the allowable number of violations (“existence of hierarchy violations and allowable information” (It may be referred to as “the allowable number of registrations”), and may be defined as follows, for example.
“0: Not detected as abnormal.

1: If one or more violations exist, it is detected as abnormal.
2: When two or more violations exist, it is detected as an abnormality.
3: When three or more violations exist, it is detected as an abnormality.

・
・
・
n: When there are n or more violations, they are detected as abnormal. ]
For example, in the case of a program created based on a program (legacy asset) created in the past, there may be a portion that is difficult to correct even if it is known that it is a violation. Therefore, if it is known that there are two violations for a given asset in a legacy asset, two violations will always occur, so this should be set to '3' to be considered as excluded (ie If there are three or more (if there are essentially one or more new violations), only the new violations are counted).

  Alternatively, as described above, symbols such as A, B, C, and D may be used instead of the above numerical values. Although this is not particularly illustrated, for example, “no violation” in the case of a blank, and “violation” in the case of any of the following symbols, the meaning of the violation is as follows.

A: An API (external) function was called across the hierarchy.
B: A local function that is not disclosed to the outside is accessed.
C: A global (for external access) variable was called across the hierarchy.

D: A local variable that is not disclosed to the outside is accessed.
Further, not only these A to D but also numerical values may be set. The value to be set indicates an allowable range (allowable number) of violation as follows, for example.
“0: Not detected as abnormal.

1: If one or more violations exist, it is detected as abnormal.
2: When two or more violations exist, it is detected as an abnormality.
・
・
・
n: When there are n or more, an abnormality is detected. ]
The above can also be expressed as follows.

0: No error is detected.
1: An error is detected. (No error allowed)
2 or more: allowable number of errors + 1
Note that B and D are functions and variables that can be accessed from other functions because there are variables used for exchanges between functions when multiple program source files are separated in the function. In the program source file, functions and variables that can only be used there can be set, but it is assumed that other functions will be used because they can be accessed if they are not declared.

The setting example of the hierarchy definition table (registration) 22 shown in FIG. 4 corresponds to the following rules, for example.
The first hierarchy is the lowest hierarchy and the third hierarchy is the highest hierarchy.

  Basically, even global variables / functions can be called up to the hierarchy one level below, but cannot be called up to the hierarchy two levels below or higher. Of course, calls to the same hierarchy can be made, and this may not be described one by one.

Therefore, the first layer is called from the upper layer, but the upper layer cannot be called.
The second hierarchy calls the first hierarchy but cannot call the third hierarchy.
The third hierarchy calls the second hierarchy, but basically the first hierarchy cannot be called. However, since only a special function may be permitted to be called, only the function can be called when permitted by setting. For example, in the example shown in FIG. 4, when the caller is an API function of “function 3-1” and the callee is a function 1-2, the above rule cannot be called (thus “1” should be set). However, “0” is set as shown in FIG. This setting may be performed manually from the beginning, or may be manually corrected for a semi-automatically generated one.

  The purpose of providing the hierarchy definition table is to allow flexibility and allow exceptions as shown in the example shown in FIG. 4. Assumed.

  Conformity to existing products means that many errors are detected when structural evaluation is performed on legacy assets. Since it is difficult to reduce errors, by setting the existing error value +1 for the purpose of maintaining the current status so that the hierarchy will not be broken any more, the score will be less than 100 points when increasing from the existing, Considering making it easy to judge.

FIG. 5 is a format example of the access violation exception registration files 26 and 27.
As described above, the access violation exception registration file (during creation) 26 is in the process of being created, and the access violation exception registration file (registration) 27 is in a completed state, so the format itself is the same. The access violation exception registration file (registration) 27 is a file in which an access violation exceptionally allowed is registered.

  The access violation exception registration files 26 and 27 in the illustrated example include a reference source function code 41, a source name 42, a reference destination function code 43, a detection target name 44, a detection type code 45, an exception access permission flag 46, and a permission determination person 47. It consists of each data item.

  That is, the detection type code 45, the exception access permission flag 46, and the availability determination person 47 are registered for each reference source / reference destination function pair. Information on the function pair of the reference source and the reference destination is extracted from, for example, the program source 28 (program file group).

  The reference source information includes a reference source function code 41 and a source name 42. The reference source function code 41 stores the function code of the reference source function. The source name 42 stores a program file name corresponding to the function of the reference source.

  Here, in this example, it is assumed that each program file constituting the program source 28 is created in units of functions. That is, one program file is created for one function, and the function code of this function is included in the program file name (assuming that the developer has created such a function. ) Thus, the program file name is stored in the source name 42, and the function code extracted from the program file name is stored in the reference source function code 41.

  The reference destination information includes a reference destination function code 43 and a detection target name 44, and a detection type code 45 may be added. However, as will be described later, the detection type code 45 does not simply indicate the reference destination. (It also serves as an error information storage unit).

  The detection target name 44 stores an access destination variable / function from the reference source function. The reference destination function code 43 stores a function code of an access destination function (in other words, a function to which the access destination variable / function belongs) from the reference source function. For example, the function code included in the detection target name 44 is extracted and stored in the reference function code 43.

  The detection type code 45 basically includes (initially) the type of the access destination variable / function (detection type; in this example, four types of API function / local function / global variable / local variable). In some cases, an error code is stored (or rewritten to an error code). The detection type code 45 stores, for example, any numerical value of 1 to 4, 0, −1 to −6, and the meaning of each numerical value is as follows.

Detection type code: Meaning; Specific example 1: API function; SCI_INITIAL
2: Local function; Sci_FifoSet
3: Global variable; g_SciExpcntlUS
4: Local variable; gSciSendState
0: Cannot be determined (cannot be determined due to other errors such as source name rule violation)
-1: Access violation related to API function -2: Access violation related to local function -3: Access violation related to global variable -4: Access violation related to local variable -5: Function that does not satisfy the rules; For example, DebugFunc -6 : Variable that does not satisfy the rules; for example, WorkArea, WORKCounterUS, etc. In addition, the exception access permission flag 46 is set to '0' or '1'. The meaning is as follows. These settings are basically performed manually by a user (such as an administrator).

0: Access violation is not allowed.
1: Allow access violation.
Details of the exception access permission flag 46 will be described later.

  Further, information indicating the user (exception access permission permitter) who sets the exception access permission flag 46 is stored in the permission determination person 47. In order to take responsibility, the setter's name, employee number, etc. of the exception access permission flag 46 are entered by the setter.

As already mentioned above, the definition of the software structure shown in FIG. 2 is as follows, for example.
Although not described one by one, calling another function from an arbitrary function means calling a function or variable belonging to another function from a function belonging to the arbitrary function, as already described in detail. In addition, although I will not mention this one by one, naturally, calls within the same function (calling another function or variable within the same function from any function) are basically all OK (no violation) .

  The function of the first hierarchy is called from the function of the same hierarchy (first hierarchy) or the function of the hierarchy one level higher. In other words, it is a violation for the function of the first layer to call the function of the upper layer. Thus, when the caller 36 is a function of the first hierarchy (1-1 or 1-2) and the callee is a function of the second hierarchy or the third hierarchy, “no violation” as shown in the figure. There will be no pair. For local functions and local variables, calling from other functions is a violation regardless of the hierarchy.

  The function of the second layer can call the function of the same layer (second layer) and the function of the first layer that is one layer below, but the function of the third layer that is the upper layer is called I can't. Thus, for example, the function 2-1 in the second hierarchy can call the function 2-2 which is another function in the same hierarchy, and the functions 1-1 and 1-2 in the first hierarchy (of course, local Functions and local variables cannot be called), and functions 3-1 and 3-2 in the third layer cannot be called.

  The function of the third hierarchy can call the function of the second hierarchy, which is the hierarchy one level below, but cannot basically call the function of the first hierarchy, which is the hierarchy two levels below. Thus, for example, the function 3-1 in the third layer can call the function 3-2 which is another function in the same layer and the functions 2-1 and 2-2 in the second layer (of course, local Functions and local variables cannot be called), and functions 1-1 and 1-2 in the first layer cannot be called.

  However, only a special function may be allowed to be called, so that it can be prevented from being specifically violated as an exception ('0' is set as an exception) at the discretion of the developer or the like. In the example illustrated in FIG. 4, “0” is set as the exception for the pair whose caller is “function 3-1” and whose callee is “API function of function 1-2”. This is because the third layer function 3-1 calls the first layer function 1-2 (its API function). The setting that means "" is done.

  The purpose of providing a definition file such as the hierarchy definition table (registration) 22 is to allow flexibility and allow exceptions as described above. A common library that goes beyond is assumed.

  In addition, conformity to existing products means that many errors are detected when structural evaluation is performed on legacy assets, and it is difficult to reduce errors. , By setting "" Number of violations of existing products "+ 1" (the above setting value; acceptable range of violations), the definition file will be such that the evaluation score will be less than 100 points when the number of violations increases over existing products It is considered that it can be easily judged (evaluated) by setting.

  FIG. 6A is a specific example of the access violation count file 24. FIG. 6B shows a specific example of the counting result based on the access violation counting file 24 in the example shown in FIG.

First, a description will be given with reference to FIG.
As shown in FIG. 6A, the data structure of the access violation counting file 24 is substantially the same as the data structure of the hierarchy definition table (registration) 22 shown in FIG. That is, the access violation counting file 24 includes a function name 51, a hierarchy number (layer) 52, a function number 53, a function code 54, a call destination 55, and a call source 56. These are substantially the same as the function name 31, the layer number (layer) 32, the function number 33, the function code 34, the call destination 35, and the call source 36 in the hierarchy definition table (registration) 22. Violation count fields corresponding to pairs of caller 56 (functional unit) and each callee 55 (function type / variable type unit) are set.

  In the initial state, the initial value of count value = '0' is set in all the violation counting columns (24 × 6 = 144 counting columns in the figure). Each time an access violation is detected, the count value in the corresponding violation counting column is incremented by +1.

  For example, each time a program source file of a function to be evaluated is referred to sequentially from the first line to the last line of a program statement described in that file, each time a function calls another function or variable, It is determined whether or not the access is violated with reference to the hierarchy definition table (registration) 22, and if it is violated, the value in the corresponding violation count column of the access violation count file 24 is updated (+1 increment) as described above. To do.

  Here, in the following description, regarding the call destination, the function is indicated by a function number. That is, for example, as the call destination, the function number 53 is “1-1” and the call destination 55 is “API function” is expressed as “call destination is“ API function of function 1-1 ”” or the like. Shall.

In the example of FIG. 6A, for example, when the caller 56 is the function 3-1, and the callee is “global function of the function 1-1”, the violation is detected three times. .
Then, based on the access violation counting file 24 shown in FIG. 6A, the sum of the call destinations for each function / variable unit is the total result shown in FIG. 6B. It should be noted that such a totaling result may also be regarded as a part of the access violation counting file 24.

  As shown in the figure, for each function of the caller 56, the total result is the above four items ((2 types of functions, 2 types of variables; API (function), local function, global variable). , Local variables).

  In the example shown in FIG. 6B, for example, when the caller is the function 1-1, the number of violations when the callee is the API function is only one even if all six functions are combined. It will have been.

In FIG. 6 (a), the blank violation count column means that the initial value = '0' remains (no violation was found).
For example, when the caller 56 is the function 3-1, and the callee is “API function of the function 1-1”, the violation is detected five times, as shown in FIG. 6B. The total result is 3 times. This is because, for this pair, “3” (= the allowable number of violations) is set in the example shown in FIG. 4, and therefore, up to two violations are allowed, and are counted as violations from the third time onwards. It is.

7A and 7B show examples of information set in the operation information definition table 16. FIG.
FIG. 7A shows information relating to weighting, and FIG. 7B shows a threshold threshold.
Note that both FIGS. 7A and 7B are not necessarily required, and only one of them may be used. Naturally, the process described later is also a process corresponding thereto.
(I) Regarding Weighting The weighting factor shown in FIG. 7A is obtained by comparing the four evaluation items (each function type / variable type; API (function), local function, global) related to the access target (call destination). An arbitrary weight coefficient (weight value) is registered for each of the variables and local variables. This is determined and set arbitrarily by a developer, for example.

  The weighting coefficient shown in FIG. 7A indicates the relative importance of the access violation for the four evaluation items. The numerical value of the weighting coefficient is not limited to the example shown in the figure, and may be weighted such that the total of four items becomes 100%, for example. Further, when the weighting is performed finely, a setting file may be provided individually between the functions corresponding to the “hierarchy definition table”.

  These weights are given to the total number of violations for each function type / variable type (the above four evaluation items; API (function), local function, global variable, local variable) shown in FIG. The count result is corrected by multiplying each coefficient. Naturally, the aggregation result related to the API (function) is multiplied by a weighting factor (“1” in the illustrated example) for the API (function). The same applies to the other evaluation items. For example, the aggregation result related to the local variable is multiplied by a weighting coefficient ('4' in the illustrated example) for the local variable.

  When the weighting process is performed on the example of the aggregation result shown in FIG. 6B using the weighting factor for each of the four evaluation items shown in FIG. 7A, the aggregation result after the weighting shown in FIG. Will be obtained.

  Finally, as shown in FIG. 8A, the total number of violations (after weighting) for each of the four evaluation items is calculated and registered for each function of the caller. For example, for function 2-1, 1 + 0 + 4 + 12 = 17 is the total number of violations (after weighting). In this case, “12” was originally “3”, but the number of violations (after weighting) = 3 × 4 by multiplying the weighting coefficient (“4” in the illustrated example) for the local variable. = 12. Similarly, “4” is originally “2”, but the number of violations (after weighting) = 2 × 2 = 4 is obtained by multiplying the weighting coefficient (= 2) for the global variable. .

  Further, the total number of violations for each function (after weighting) is added together to obtain the total value (9 + 0 + 17 + 14 + 25 + 27 = 92 in the example shown). Further, as shown in the figure, the total value (11, 9, 12, 60) of the number of violations (after weighting) for each of four evaluation items (each function type / variable type) may be obtained.

  Each of the weighting factors indicates the importance of access violation for the four evaluation items. This can be said to indicate the relative importance among the four evaluation items. In this example, the importance is higher as the value of the weight coefficient is larger. Therefore, in the illustrated example, the local variable has the highest importance, and the API function has the lowest importance. In other words, even if there are many access violations where the call destination is an API function, it does not significantly affect the evaluation score described later (not so much), but if there are many access violations where the call destination is a local variable, It means that the evaluation score described later is greatly affected (the score becomes very low).

The numerical value of the weighting coefficient is not limited to the example shown in FIG. 7A, and for example, weighting may be performed so that the sum of the weighting coefficients of the four evaluation items becomes 100%.
Further, when the weighting is performed finely, a setting file may be provided individually between the functions corresponding to the “hierarchy definition table”.
(II) Regarding the threshold value for the threshold value The threshold value for the threshold value may be set as the upper limit of the number of violations per evaluation unit (for example, for each function of the caller). The set value of the sufficient amount may be arbitrarily determined by a developer or the like, and in the example shown in FIG. 7B, “threshold threshold value” = 10.0. In the following description, this example is used, but it is not limited to this example.

  Since the number of violation items is expected to vary depending on the system (product), the upper limit is unknown. For this reason, if there is a function with many violations due to too many differences in the score, other functions will have a relatively good score, making it easier to overlook, so a “threshold threshold” that determines the upper limit can be set. .

  The scoring task unit 12 is the sum of the weighted aggregation results shown in FIG. 8A and the number of violations (after weighting) for each function of the caller based on this (hereinafter referred to as the total score) Then, the access violation scoring file 25 is generated using this total value and the number of program steps for each function.

FIG. 8B shows an example of the access violation score file 25.
In the example shown in the figure, the access violation scoring file 25 has the following items, and numerical values corresponding to the following items are calculated and registered for each function of the caller or the entire program source 28.
(I) Number of steps [LOC]
This is the number of steps in the program for each functional unit. As shown in the figure, basically, the number of program steps of each of the functions 1-1 to 3-2 is different and greatly varies depending on the case. Therefore, simply because the number of violations is large, it cannot simply be said to be bad (the number of program steps is so large that the number of violations may be large).
(Ii) Points per unit The number of violations detected per KLOC (1000 steps).

  Since the number of steps differs for each function as described above, the weighted total point (total number of points) shown in FIG. 8A is divided by the number of steps of the program to calculate the number of points per unit (1000 LOC).

That is, it is calculated by the following formula using the total score and the step count [LOC].
Points per unit = total points / (number of steps [LOC] / 1000)
= {Total score / number of steps [LOC]} × 1000
(Iii) Number of points after footing When the number of points per unit exceeds the threshold for footing, the threshold for footing is taken as the number of points per unit. Therefore, in the example shown in the figure, since only the number of points per unit (17.73) relating to the function 3-2 exceeds the threshold value (10.0), 17.73 is corrected to 10.0. Other functions are left as they are.

Then, the score per unit is normalized to “0 to threshold ⇒ 0 to 100” to obtain the score after the completion. In other words, the number of points per unit is replaced with the number of points where the threshold value (10.0) of the above threshold is 100 points. In this example, since the threshold value is 10.0, the number of points after the addition is simply calculated by multiplying the number of points per unit by 10 (by multiplying by 10.0). it can. In addition, regarding the function 3-2, since the above-mentioned footstep is performed, the point is not 177.3 points but 100 points as illustrated.
(Iv) Evaluation score If the score after the completion of (3) remains as it is, the score is 0 so that there is no violation and the best score is obtained. Therefore, 100 points are converted to be the best score. Is the evaluation score.

In other words, the evaluation score = 100− “the score after setting”
The evaluation score is calculated by
For example, in the case of the function 1-1, since the score after setting is 38.6 points,
Evaluation score of function 1-1 = 100-38.6 = 61.4 points.

  However, the present invention is not limited to this example, and the score after the addition may be used as it is as the evaluation score (only the way of evaluation changes. That is, 0 is the best score, the closer to 0 the evaluation is Will be high).

  Moreover, you may obtain | require the evaluation score as a whole. For example, the total number of violations of the entire program (= 92) and the total number of steps of the entire program (= 30121) are used in the same manner as in the case of each function. Is calculated as necessary, and then converted into an evaluation score. In the example shown in the figure, the number of points per unit is 3.05, and it is not necessary to add a footstep, and after converting it into a scoring system of 100 points as a whole (after multiplying by 10), as a result, The evaluation score is “69.5”.

  However, the present invention is not limited to this example. For example, the evaluation score of each of the six functions from function 1-1 to function 3-2 is added to obtain a total value, and the total value is calculated by the number of functions (= 6). By dividing, the evaluation score as a whole may be obtained.

  Using the above computer processing results, for example, a developer or the like may evaluate the evaluation target program based on the above-mentioned evaluation scores or the overall evaluation scores. However, for example, in the case of an embedded program, there may be a case in which it is often necessary to violate the provisions of the software structure (hierarchy and functions) in FIG. There are cases where it cannot be said that it is bad.

  On the other hand, the program may be improved, upgraded, or diverted. In this case, the first (base) program may be old. In the case of such an old program, it is often the case that the software program (hierarchy and function) shown in FIG. In the case of a program such as an upgraded version related to such a program, it can not be expected that the evaluation score will be high, and if the evaluation score is not at least lower than before, it may be sufficient (at least keep the current status) ), But often a realistic evaluation criterion.

From such a viewpoint, it can be considered that the evaluation score is further evaluated by a deviation value. That is, relative evaluation is performed by calculating a deviation value for each product based on past product data.
An example is shown in FIG.

FIG. 9 is a diagram illustrating a specific example of the deviation value calculation process.
In FIG. 9, it is assumed that the product A is a program to be evaluated this time, and thus the score (total evaluation score) is 69.5 points as shown in the figure.

  On the other hand, the products B to E are programs related to the product A and are programs created in the past. For these products B to E, the score (total evaluation score) is determined by the same processing as that for the product A.

  The average value (38.7 in the illustrated example) of the scores of the above five products (total evaluation score) is calculated, and the deviation values of the products A to E are calculated based on this average value as shown in the figure. Ask. The method of obtaining the deviation value is well known, and is not particularly described here. However, first, the average value is obtained, and the standard deviation is obtained based on the average value, whereby the deviation value is obtained.

Then, the product A is evaluated based on the deviation value of the product A to be evaluated this time.
In the example shown in the figure, the deviation value of the product A is “61.9”, which indicates that it is improved compared to the past products.

FIG. 10 is a diagram showing a flow of processing / work related to semi-automatic creation of a hierarchy definition table and an access violation exception registration file.
FIG. 11 shows an example of the contents of a program file that constitutes the program source 28.

As shown in FIG. 10, the flow of the processing / work is roughly (1) to (6) shown in the drawing. Hereinafter, (1) to (6) will be described.
(1) Registration of New Program First, an arbitrary person in charge (program registrant) registers the created program source 28 (or a template program for each function) in the management server 10. The program source 28 is stored in a storage device (hard disk or the like) (not shown) of the management server 10.

  The template program is a program that declares only the interface (API) of the external function. Here, the hierarchical structure is checked after creating (coding) the program. However, in the case of new software development, since programs for each function are created in parallel, it is not possible to check without creating all of them. Therefore, by creating a template program first and making it possible to generate a hierarchy definition table, it is possible to detect an access violation even if the program is not completed.

However, in the following description, the case where the program source 28 is used is taken as an example, and the template program is not particularly mentioned. However, as described above, the template program may be registered. The target may be a template program.
(2) Program analysis processing An administrator (designer) who manages the entire system, for example, operates the operation terminal 1 to access the management server 10 via the network 2 and various requests described below. Is sent to the management server 10 to execute processing according to the request. In the following description of the processing of the management server 10, the operation of the operation terminal 1 by the administrator may not be described one by one. The manager is not limited to this example, and the administrator may directly operate the management server 10 to execute a desired process. In addition, the various processes executed by the management server 10 in response to the above request are basically performed under the management of the server main processing unit 11, and the server main processing unit 11 directly or indirectly calls a process according to the request. At the same time, the processing result is returned to the server main processing unit 11 and is returned from the server main processing unit 11 to the operation terminal 1. However, this may not be described one by one.

  For example, the server main processing unit 11 that has received the program analysis request as the request calls the program analysis processing (FIG. 18 and the like) via the definition generation task unit 14 and the like, and from the program source 28 registered in (1). The following extracted data is written in the corresponding fields of the hierarchy definition table (under creation) 21 and the access violation exception registration file (under creation) 26, respectively.

  Note that the hierarchy definition table is temporarily stored as the hierarchy definition table (during creation) 21 until all data has been registered (during creation), and all the data has been registered. When completed (when completed), it is stored as a hierarchy definition table (registration) 22.

  Further, for example, a hierarchy definition table (in other words, “hierarchy definition table template”) in a state where there is no data (an initial state; default) is stored in advance in the storage device of the management server 10, and the “( 2) At the beginning of the “program analysis process”, a copy of the “layer definition table template” may be created and stored in a predetermined storage area (such as a work area in a memory). This may be considered the initial state of the table (under construction)).

  The same applies to the access violation exception registration file (in preparation) 26. A copy of the "access violation exception registration file template" stored in advance is copied to the access violation exception registration file (in preparation) 26 in the initial state. Is created at the beginning of the “(2) Program analysis process”.

  Note that the present invention is not limited to these examples. For example, by storing a predetermined data item name in a predetermined field of the table, the initial state of the hierarchy definition table (under construction) 21 or an access violation exception registration file (created) Medium) 26 initial state generation processing or the like may be used.

  The process of writing the following data in the corresponding field is performed on the table (being created) 21 and the file (being created) 26 in the initial state. Furthermore, the layer number / function number input by “(3) Hierarchy registration & input check” described later is input to the table (under creation) 21 in which the following data is written by the “(2) Program analysis process”. Will be done. As described above, the data storage contents of the hierarchy definition table 21 (being created) differ depending on which processing stage is currently performed. The same applies to the access violation exception registration file (during creation) 26.

1) Hierarchy definition table (under construction) 21
-Extraction data: Extraction source-Function code: Program file name-Function name: Program header 2) Access violation exception registration file (under construction) 26
-Extraction data: Extraction source-Reference source function code: Program file name-Source name: Program file name-Reference destination function code: Extract function code from the referenced function name and variable name-Detection target name: Refer Function name and variable name • Detection type code: Judged by the function name and variable name being referenced. The detection type code extracted here is> 0 (positive value), or -5 or -6 (in other words, other than -1 to -4).
(3) Hierarchy registration & input check;
An administrator (designer or the like) that manages the entire system operates the operation terminal 1 to execute the following data registration and processing in cooperation with the management server 10.

1) Registration of the hierarchy number 32 or / and the function number 33 The management server 10 responds to a predetermined request from the operation terminal 1, for example, the hierarchy definition table (under construction) 21 (the above “(2) program analysis” The state after “processing” is read out from a predetermined storage area and displayed on the operation terminal 1 side, and a user (designer or the like) inputs arbitrary data. Thus, the user arbitrarily inputs the layer number 32 or / and the function number 33.

  If both the layer number 32 and the function number 33 are input, since the function number 33 includes the layer number 32, a contradiction may occur. Therefore, only one of them may be input at the time of input. Of course, both may be input. Further, in that case, an input check process (a process for checking whether or not the input hierarchy number 32 and the function number 33 match each other) may be performed as shown in FIG.

2) Write to the management server 10;
The management server 10 reflects the input contents of the layer number 32 / function number 33 on the operation terminal 1 side in the layer definition table (in preparation) 21 held and managed by itself (updates the table 21). . For example, the state is updated from the state shown in FIG. 12A to be described later to the state shown in FIG. 12B or FIG.

3) Check input;
The server main processing unit 11 calls the hierarchy registration check process (FIG. 19) via the definition generation task unit 14 and causes the process (for example, the process shown in FIG. 19) to be executed. By this process, it is determined whether or not there is a definition error (such as a matching error). When the user inputs only one of the hierarchy number 32 / function number 33, the other is automatically generated. Furthermore, automatic alignment of records may be performed. Details will be described later with reference to FIG.

  4) If there is a definition error, the processes 1) to 3) are repeated, and if there is no definition error, the hierarchy definition table (during creation) 21 is further updated (for example, the state shown in FIG. 12C described later) To update).

FIG. 12 shows a specific example of the setting procedure of “(3) Hierarchy registration & input check”. The following setting procedures (11) and (12) will be described. In the following description, it is assumed that the user inputs only one of the function number 33 and the layer number (layer) 32.
(11) A case where the user inputs a function number;
When the hierarchy definition table (under construction) 21 in the state shown in FIG. 12A is read and displayed, and the user manually inputs the function number 33 as shown in FIG. The hierarchy number included in the function number 33 is automatically reflected in the hierarchy number (layer) 32, and the records are arranged in the order of the function number. As a result, the state shown in FIG. That is, in this case, when the user inputs the function number 33, the hierarchy number (layer) 32 is automatically generated and registered, and the records are aligned based on the function number 33. As a result, the hierarchy definition table (during creation) 21 is updated to the state shown in FIG.

Since the function number 33 is in the form of “hierarchy number-sequential number in the hierarchy”, the number before “-(hyphen)” may be acquired and registered in the hierarchy number (layer) 32. . The ordering by function number is, for example, based on the above-mentioned “hierarchy number-serial number in the hierarchy”, in order from the lowest hierarchical number (here, “1” is the smallest), and further, the hierarchical number Are arranged in order from the one with the smallest serial number in the hierarchy (here, “1” is the smallest).
(12) A case where the user inputs a layer number (layer);
When the hierarchy definition table (in preparation) 21 in the state shown in FIG. 12A is read and displayed, and the user manually inputs the hierarchy number (layer) 32 as shown in FIG. 12D By processing as described below, the hierarchy definition table (during creation) 21 is updated to the state shown in FIG. 12C through the state shown in FIGS. 12E and 12F, for example.
When the user inputs the layer number (layer) 32, the position (order: serial number) in the layer of each function is undecided, so the serial number is determined and the records in the table 32 are arranged as follows. A function number 33 is automatically generated.

(1) The records are arranged in order from the one with the smallest layer (hierarchy number 32) (here, “1” is smallest).
(2) Records are arranged in alphabetical order of the first character of the function code 34 for each layer.

(3) For each record, the function number 33 is automatically generated based on the layer number (layer) 32 and the order in the layer.
If the user has not decided the position of each function in the layer at the time of designing, the one automatically arranged and generated in the above (1) to (3) is registered as it is (Case A).
・ When the user determines the position of each function in the layer at the time of design, if the automatically aligned one is different from the one determined by the user, the one determined by the user So that they are aligned with each other (input manually, etc.), and after being automatically aligned again, they are registered (case B). As a matter of course, in the case where what is automatically aligned as described above is the same as that determined by itself, as in case A, it is automatically aligned and generated as described above. Are registered as they are.

Hereinafter, the processes (1) to (3) described above will be further described with reference to a specific example shown in FIG.
When the user manually inputs the hierarchy number 32 as shown in FIG. 12D, for example, the above-described processing is started. That is, first, the records in the table 12 are arranged according to the above (1), and the records are arranged in order from the one having the smallest layer number (layer) 32 (here, “1” is smallest). Further, the order in the layers is determined and arranged. This arranges the order of records having the same layer number (layer) 32 in alphabetical order of the function code 34 according to (2) above, for example. By performing these processes, the hierarchy definition table (under construction) 21 changes from the state shown in FIG. 12D to the state shown in FIG. Function number 33 is unregistered).

  For example, for the record whose layer number (layer) 32 is “2”, since the function code 34 is “COM” and “SYS”, the record of “COM” is the first as shown in FIG. Become.

  Then, the function number 33 in the form of “hierarchy number−serial number in the hierarchy” can be automatically generated and registered based on the hierarchy number (layer) 32 and the order in the hierarchy (above (3)). As a result, the state shown in FIG. In the case A, the state shown in FIG. 12E is stored as an updated version of the hierarchy definition table 21 (being created) as it is.

  On the other hand, in the case of the above case B, if the developer or the like decides that the order of the hierarchy “1” should be prior to the RTC at the time of design, the state shown in FIG. Then the order is reversed. Therefore, in this case, when the user manually corrects the function number 33 as shown in FIG. 12 (f), the management server 10 performs the process of rearranging the records according to the function number 33. As a result, the state shown in FIG. 12C is obtained, and this is saved as an updated version of the hierarchy definition table 21 (being created).

  It is assumed that (11) function number input when the user or the like has previously determined a serial number in the layer, and (12) layer number (layer) input when the user or the like has not. However, the order may be changed even if it is not decided, so that the order can be changed manually.

  Although not shown in FIG. 12, after the state shown in FIG. 12C is obtained, the function number 33 may be further stored in the call destination 36 (in the order of arrangement in the drawing). As a result, the function numbers are stored in the call destination 36 in the order of the functions 1-1 to 3-2 as shown in FIG. 4, for example.

The processing and work of “(3) Hierarchy registration & input check” shown in FIG. 10 has been described above.
Next, the processing and work of “(4) Access violation extraction & normal deletion” shown in FIG. 10 will be described.
(4) Access Violation Extraction & Normal Delete An administrator (designer, etc.) who manages the entire system operates the operation terminal 1 and performs a hierarchy violation exception detection process via the definition generation task unit 14 (FIG. 20). ). In this process, referring to the updated hierarchy definition table (during creation) 21 in (3) above, the access (pair) that is an access violation among the records in the access violation exception registration file (during creation) 26 is recorded. The detected record is detected and the detection type code 45 is rewritten (1 to 4 of the detection type code 45 is changed to -1 to -4 if there is an access violation). Furthermore, normal records (not access violations) are deleted.

FIG. 13 shows a specific example of the setting procedure of the (4) “access violation extraction & normal deletion” process. This is, for example, the following (21) and (22).
It should be noted that the access violation exception registration file (during creation) 26 is stored in the state shown in FIG. 13A, for example, by the process (2) (the process shown in FIG. 18) at the start of this process. Through the processing, the state of FIG. 13C is stored as an updated version of the access violation exception registration file (under construction) 26 through the state of FIG. 13B.
(21) Extracting access violation Referring to the hierarchy definition table (under construction) 21, the access violation of each access (pair) recorded in each record registered in the access violation exception registration file (under creation) 26 The presence / absence is determined, and the record of access violation sets the detection type code 45 to a negative value (−1 to −4) (see S201 of FIG. 20 for the processing flow).
(22) Delete normal Delete all records whose detection type code 45 is normal (> 0) (see S202 of FIG. 20 for the processing flow).

Through the above processing, the updated access violation exception registration file (during creation) 26 is in a state where all the locations related to access to functions / variables that cause access violations in the program source 28 are extracted and registered. Then, according to (5) described later, the user (developer, etc.) makes an exception of any access violation (may be plural or all) from among the registered access violations. Can be specified.
(5) Access violation exception permission registration Administrators (such as designers) who manage the entire system perform the following instruction operations on the operation terminal 1 in order to register permission for access violation exceptions. The access violation exception registration file (during creation) 26 of the server 10 is updated. Note that a flowchart or the like is not particularly created for this processing.

  1) The access violation exception registration file (during creation) 26 is read out and displayed on the screen of the operation terminal 1. It should be noted that the contents of the file 26 can be arbitrarily edited (added, changed, deleted, etc.) on this screen. In addition, the access violation exception registration file (being created) 26 at this time is in a state after the above (4) “access violation extraction & normal deletion” processing (therefore, the detection type code 45 is positive). There should be no record with value (> 0)).

  2) The administrator registers whether or not to allow exceptional access permission (exception access permission flag 46) for the file 26 on the screen, and also allows the person who has made this permission registration to be identified. Enter the name (Availability Judge 47). In this example, when the access is permitted, the exception access permission flag 46 is set to “1”, but the present invention is not limited to this example.

  The availability determination person 47 may directly input the name as described above, or may automatically register the ID when logging in to the operation terminal 1. In addition to this example, a determination reason or the like may be input. The determination reason or the like may be directly input on the above screen, or selection items for the determination reason (such as “system error information collection”, “trace information for failure analysis”) may be prepared and selected in advance. .

3) The access violation exception registration file (being created) 26 after the editing operation is saved on the management server 10 side (the file 26 is updated).
As described above, among the access violations registered in the access violation exception registration file (during creation) 26, those that are handled as exceptions (not determined as violations) by the administrator's judgment are manually registered. Then, the semi-automatic creation of the hierarchy definition table is completed by performing the following process (6) shown in FIG. 10 using such an exception registered access violation exception registration file (being created) 26. (Stored as a hierarchy definition table (registration) 22). Thereafter, the scoring / evaluation process described above is performed using the saved hierarchy definition table (registration) 22.

Hereinafter, the “(6) Hierarchy violation permission registration” process shown in FIG. 10 will be described.
(6) Registration of Hierarchy Violation Allowance An administrator (designer) who manages the entire system operates the operation terminal 1 and performs a registration process of hierarchy violation allowance (FIG. 21) via the definition generation task unit 14. call. In this process, all records other than those that are exceptionally permitted to access (records with exception access permission flag 46 = '0') are deleted from the access violation exception registration file (during creation) 26, and this is regarded as an access violation. Saved as an exception registration file (registration) 27.

That is, the access violation exception registration file is substantially completed by the above processing, and is stored as the access violation exception registration file (registration) 27.
Then, using the access violation exception registration file (registration) 27, automatic setting of an unregistered portion in the hierarchy definition table (during creation) 21, that is, automatic setting of “existence of hierarchy violation and allowable information (allowable registration number)” is performed. By doing so, the hierarchy definition table is completed (stored as the hierarchy definition table (registration) 22).

  In the automatic setting, the “allowable registration number” can be obtained by referring to the access violation exception registration file (registration) 27. This will be described later with reference to FIG.

  As described above, in this method, semi-automatic creation of a hierarchy definition table can be realized, but it is also possible to avoid overlooking a newly generated access violation. This can be realized by using an access violation exception registration file. As described above, the contents of each access violation are registered in the access violation exception registration file. For example, even if the total number of access violations does not change by increasing the number of access violations by one, the number of access violations increases. It can be determined that there was a decrease.

  Regarding this feature, the program source 28 to be analyzed this time is, for example, an upgraded version, which is created based on a program source 28 (such as an old version) that has been created in the past, and It is assumed that an access violation exception registration file (referred to as the previous access violation exception registration file) has already been created for the past program source 28 (old version or the like) by the above-described processing or the like. Then, when an access violation exception registration file (this access violation exception registration file) is also created for the program source 28 to be analyzed this time, by comparing this with the previous file, an increase in access violations or It can be determined that there was a decrease.

FIG. 14 shows a flow of work / processing related to such access violation discrimination.
As described above, such processing provides an effect of not overlooking a newly generated access violation (maintaining maintainability). Alternatively, it is possible to obtain an effect that the user can confirm whether the addition / deletion of the function is correct.

Hereinafter, the processing procedures (31), (32), and (33) illustrated in FIG. 14 will be described.
(31) Table creation The hierarchy definition table 21 or 22 and the access violation exception registration file 26 or 27 are created along with the program evaluation process for the program source 28 to be analyzed this time. Note that the creation of these tables can be realized by the processes (2) to (6) described above, and therefore the description thereof is omitted here.
(32) Function code difference extraction The hierarchy definition table (being created) 21 created in the process (31) for the current processing target program (however, it may be the hierarchy definition table (registration) 22) and Then, a comparison process with the hierarchy definition table (registration) 22 created at the previous program evaluation is performed, and a difference (difference) between the function codes of the two is detected. For example, a comparison process program (hierarchy definition table comparison process (FIG. 22)) is called, and a table (hierarchy definition table (difference) 29 ″)) for storing the above-described difference detection result (addition / deletion of function code) is created. To do.

  The previous program evaluation means, for example, a program evaluation performed in the past for the previous version (old version) of the program to be evaluated this time. This process can be realized by saving the hierarchy definition table and the access violation exception registration file created at this time.

The current hierarchy definition table is compared with the previous hierarchy definition table, and if the function code is changed, only the difference is displayed on the operation terminal 1, for example. As a result, the system administrator or the like can confirm the content of whether the addition / deletion of the function is correct. If there is a mistake, for example, some measures such as correcting the contents of the program source 28 can be taken.
(33) Access violation difference extraction The access violation exception registration file (during creation) 26 created in the program evaluation of the program to be processed this time, and the access violation exception registration file (created in the previous program evaluation) A comparison process (access violation exception registration file comparison process (FIG. 23)) is started.

  If there is a different part as a result of the comparison, the part is extracted and displayed. At that time, a table (access violation exception registration file (difference) 29 ′) for storing the extracted “different parts” (differences) is created and displayed on the operation terminal 1 based on this table. Also good.

  By doing so, the system administrator or the like can individually recognize the increase / decrease in the access violation, and thus, it is not possible to overlook the newly generated access violation. In the prior application (Japanese Patent Application No. 2011-281484), for example, when the access violation increases by one and decreases by one, the total becomes plus zero, and it may not be possible to determine the new occurrence of the access violation. Note that a new occurrence of an access violation is determined by the user by referring to the notification content, for example, by displaying a notification to be described later, but is not limited to this example.

  Here, the previous file (being created) 26 and the current file (being created) 26 used for the comparison process are not limited as long as they are being created, and are in the state shown in FIG. Is desirable. Therefore, it is necessary to save the access violation exception registration file (being created) 26 in the state shown in FIG. 13C at the previous program evaluation. In addition, it is desirable to execute this processing when the access violation exception registration file (during creation) 26 is in the state shown in FIG. As a result, the administrator or the like can set the flag 46 shown in FIG. 13D while referring to the result of the comparison process (addition of an arbitrary access violation, etc.). Expect to be done.

Hereinafter, the various processes described above will be described in more detail with reference to the drawings (particularly, flowcharts) from FIG.
FIG. 15 is a flowchart of the server main processing unit 11.

The server main processing unit 11 calls a task corresponding to the following request in accordance with any of the following requests transmitted from the operation terminal 1 via the network 2, waits for the completion of execution, and operates the processing result when the execution is completed. The terminal 1 is notified. Note that these requests are generated and transmitted by the operation terminal 1 in accordance with, for example, an arbitrary operation by the administrator or the like, but are not limited to this example.
・ Scoring request: “Scoring task 12”
Definition request: “Definition access task 13”
Definition generation request: “Definition generation task 14”
That is, the server main processing unit 11 receives an arbitrary request while waiting for an arbitrary request from the operation terminal 1 (step S11). If the request is a scoring request (step S12, YES), the score is given. The activation task unit 12 is activated (step S15), the process completion of the scoring task unit 12 is awaited (step S16), and the process result is returned to the operation terminal 1 when the process is completed.

A process flowchart of the scoring task unit 12 is shown in FIG. 24 and will be described later.
If the received request is a request related to access (read / write) to a table / file or the like (collectively referred to as a definition setting request) (step S13, YES), the definition access task unit 13 (Step S17), waits for the processing of the definition access task unit 13 to be completed (step S18), and returns the processing result to the operation terminal 1 when the processing is completed.

  In addition, the received request is a request for some processing other than access (read / write) to the table / file etc. (particularly, processing related to automatic editing / checking of the table / file; collectively a definition generation request) (Step S14, YES), the definition generation task unit 14 is activated (Step S19), and the requested process is called and executed. Then, it waits for the processing of the definition generation task unit 14 to be completed (step S20), and returns the processing result to the operation terminal 1 when the processing is completed.

  Note that, for example, each request command includes some identification information indicating whether the request is a request classified into the above-described scoring request, definition setting request, or definition generation request. The unit 11 refers to the identification information to perform the determination processes in steps S12, S13, and S14. However, the present invention is not limited to this example.

FIG. 16 is a processing flowchart of the definition access task unit 13.
In this process, based on the received request (command), the definition content (for example, the type of read / write target data, file name, table name, etc.) is determined, and the table / file corresponding to this definition content is determined. Access (read / write) is performed.

That is, first, the definition contents are discriminated (step S31), thereby accessing a table / file corresponding to the definition contents.
For example, if the definition content is “layer definition table”, the layer definition table (21 or 22) is accessed (step S32). For example, if the definition content is “weight count” or “threshold threshold”, the operation information definition table 23 is accessed (step S33). Here, it is assumed that information (not specifically described) necessary for these determinations is stored in advance, but the present invention is not limited to this example.

  In addition to the above example, there are a case of accessing the “evaluation target product program” (step S34) and a case of accessing the access violation exception registration file (26or27) (step S35) depending on the definition contents. If the access destination is unknown, a request error is returned to the operation terminal 1 (step S36).

  If the request is a read request (step S37, YES), the data read from the corresponding access destination is returned to the operation terminal 1 (step S38). If the request is a write request (NO in step S37), the processing result (successful / unsuccessful writing) for the corresponding access destination is returned to the operation terminal 1 (step S39).

  For example, for the hierarchy definition table (being created) 21 and the access violation exception registration file (being created) 26, the administrator or the like has described any information (for example, the hierarchy number (layer) 32, the function number 33, the exception). When inputting and updating the access permission flag 46, the permission determination person 47, etc., the process of FIG. 16 is performed.

FIG. 17 is a process flowchart of the definition generation task unit 14.
This is processing when a request is made from the operation terminal 1 side to the management server 10 side in order to create a table and file for structure evaluation. In this embodiment, the processing is executed on the management server 10 side. Processing may be performed on the operation terminal 1 side.

In this process, the type of received request is determined (step S41), and a process (program) corresponding to the request is called. Examples of processing (program) to be called include the following. The determination method is an existing technique and is not particularly described. For example, a request (command) includes information (identification code or the like) necessary for determination. Of course, the present invention is not limited to this example.
Program analysis process (step S42; for example, a program for executing the process of FIG. 18)
Hierarchy registration check process (step S43; for example, a program for executing the process of FIG. 19)
Hierarchy violation exception detection process (step S44; for example, a program for executing the process of FIG. 20)
Hierarchy violation allowable registration process (step S45; for example, a program for executing the process of FIG. 21)
Hierarchy definition table comparison process (step S46; for example, a program for executing the process of FIG. 22)
Access violation exception registration file comparison process (step S47; for example, a program for executing the process of FIG. 23)
When the execution of any of the above processes is completed, the server main processing unit 11 is notified of the completion of the process (step S49).

If the request is undefined, a request error is returned to the operation terminal 1 (step S48).
Hereafter, each process of said step S42-S47 is demonstrated with reference to the flowchart figure of FIGS.

FIG. 18A is a flowchart of “program analysis processing”.
FIG. 18B is a detailed flowchart of the “detection type code creation process” in step S61.

  In the example shown in the drawing, a hierarchy definition table (under creation) 21 and an access violation exception registration file (being created) 26 are created from the program file name and program code in the following procedure (note that (under creation) 21, 26 means a state in the middle of creation (in other words, an incomplete state), and when completed, it is saved as (registration) 22 and 27. "Does not mean that the creation is complete (it is still in the process of being created).

First, a new default version of the hierarchy definition table 21 (during creation) and the access violation exception registration file (during creation) 26 is created (step S51).
For example, the hierarchy definition table 21 (being created) and the access violation exception registration file (being created) 26 templates (there are data items but no data) are stored in advance, and the above step S51. In the process, each table is copied and a table identification number (or name) based on the program file name to be analyzed is generated and assigned. As a result, a default version (initial state) of the hierarchy definition table 21 (being created) and the access violation exception registration file (being created) corresponding to the program source 28 to be analyzed is newly created.

  As described above, when the default versions of the table (under creation) 21 and the file (under creation) 26 corresponding to the program source 28 (program file group etc.) to be analyzed are generated, the following processing is repeated for each program file. Execute (loop processing between steps S52 and S52 ′).

  That is, first, regarding the program file to be analyzed, a function code is extracted from the file name and stored in the field of the function code 34 of the hierarchy definition table (under construction) 21 (step S53). In this example, it is naturally assumed that the file name is defined to include a function code.

  Further, the function name is extracted from the program header and stored in the function name 31 field of the hierarchy definition table (under construction) 21 (step S54). For example, this is extracted from a keyword indicating a function name in the program header. The keyword is “@brief” in the example shown in FIG. This function can be realized by predetermining “function name: xxxx” or the like as a rule and creating an extraction process according to this rule in advance by a developer or the like.

Then, the following analysis processing is performed for each line of all lines of the program text (loop processing between steps S55 and S55 ′).
That is, first, it is determined whether or not the variable / function at the reference destination (access destination) is a common variable / function within the function (local) or a global variable / function (step S56). This is determined to be YES in step S56 if any of the functions / variable determination methods shown in the description of the process in FIG.

  The reference destination (call destination) is a variable / function (local variable / local function) common within the function or a global variable / function (global variable / API function) (step S56, YES), and a file ( If it is a variable / function (unregistered (newly registered) variable / variable) to be registered for the first time in step 26 (YES in step S57), the following access violation exception registration file for access to the variable / function (Registering) Registration processing (steps S58 to S61) 26 is performed.

  That is, first, the program file name is stored in the source name 42, and the function code is extracted from the program file name and stored in the reference source function code 41 (step S58). That is, for example, the file name of the program file to be analyzed is stored in the source name 42 of the access violation exception registration file (during creation) 26. Further, the function code included in the file name is extracted (the one extracted in S53 may be used) and stored in the reference source function code 41 of the access violation exception registration file (under construction) 26.

  In this description, each program file constituting the program source 28 is created in units of functions. That is, one program file is created corresponding to one function. Therefore, even if there are various reference destinations (call destinations) for one program file (there can be various functions, functions, and variables), there is only one reference source (call source) function, and its function code is It can be understood by referring to the program file name. Of course, this is only an example, and the present invention is not limited to this example.

  Further, the function code of the reference destination is extracted from the variable name / function name of the reference destination variable / function obtained in step S56 and stored in the reference function code 43 of the file 26 (step S59). . The variable name / function name is stored in the detection target name 44 (step S60).

Further, a detection type code corresponding to the reference destination variable / function is generated and stored in the detection type code 45 of the file 26 (step S61).
Details of step S61 are shown in FIG.

Note that the program file name and the function name / variable name are given names in accordance with the following predetermined rules, and FIG. 18B shows a processing example in accordance with these example rules. However, the present invention is not limited to this example.
* Convention example of each function / variable The following specific example shows an example in which the function code is “SCI”.
(A) Determination of Function Code In this example, it is assumed that the first part of the program file name is a capital letter of the function code + “_” (underscore). Therefore, in this example, the part before “_” is recognized as a function code.

Example: If the program file name is SCI_Driver.c, the function code is “SCI”
(B) API function (global function)
The function name starts with an uppercase letter of the function code + "_" (underscore)
Example: SCI_Initial (void);
(C) Local function The function name starts with the first letter of the function code in uppercase and the rest in lowercase + "_" (underscore)
Example: Sci_FifoSet (void);
(D) Global variable “g _” + The first character of the function code is uppercase and the rest is lowercase. Example: g_SciSendState;
(E) Local variable “g” + The first letter of the function code is uppercase and the rest is lowercase
Example: gSciExpcntlUS;
In FIG. 18B, first, it is determined whether or not it is a function (step S71). This may be determined according to the rules of the programming language. For example, in the case of C language, if a function A is described, a parenthesis is always added after it, such as “A (...)”. To do. However, the present invention is not limited to this example. For example, when the API function (global function) or local function convention shown in (b) and (c) above is satisfied, the function may be determined.

  If it is a function (step S71, YES), and if the first part of the function name (the part before “_” (underscore)) is a function code and is all capital letters (step S72, YES), it is determined that it is an API function (step S73), and the detection type code (API function is '1' in the above example) corresponding to the determination result is stored in the field of the detection type code 45 of the file 26 (Step S82).

For example, it is assumed that all function codes are registered in advance, and by referring to this, it is possible to determine whether or not the part before “_” (underscore) is a function code.
If the function code is not all uppercase (step S72, NO) and only the first character is uppercase (step S74, YES), the function code is determined to be a local function (step S75). The detection type code corresponding to the result (in the above example, the local function is “2”) is stored in the field of the detection type code 45 of the file 26 (step S82).

  If neither of the above conditions is met (NO in both steps S72 and S74), it is determined that the function does not satisfy the rules (step S76), and the detection type code (in accordance with the determination result) In the above example, “−5” is stored in the field of the detection type code 45 of the file 26 (step S82).

  If it is not a function (step S71, NO), if it is “g_” (step S77, YES), it is determined that it is a global variable (step S78), and if it is “g” (step S77) (Step S79, YES) It is determined that the variable is a local variable (Step S80), and the detection type code corresponding to these determination results (in the above example, the global variable is “3” and the local variable is “4”) Store in the field of the detection type code 45 (step S82).

  If the head is neither 'g' nor 'g_' (both NO in steps S77 and S79), it is determined that the variable does not satisfy the rules (step S81), and detection according to the determination result The type code (in the above example, the variable that does not satisfy the convention is “−6”) is stored in the field of the detection type code 45 of the file 26 (step S82).

FIG. 19 is a flowchart of the hierarchy registration check process.
In this process, the hierarchy definition table (during creation) 21 requested (check instruction) from the operation terminal 1 is read out, and its function number / hierarchy number is checked / automatically generated as follows, and the hierarchy definition table (creation) Middle) 21 is updated. If there is an abnormality, the operation terminal 1 is notified.

In this example, it is assumed that the function number is composed of xxx-yyy (“xxx”: hierarchy number, “−”: delimiter, “yyy”: serial number in the hierarchy).
First, the hierarchy definition table 21 (being created) is read as described above (step S91), and the following processing is sequentially executed for all functions (all records) (loop processing between steps S92 and S92 ′). .

  First, it is determined whether or not the function number 33 has been registered in the processing target record (step S93). If the function number 33 has been registered (step S93, YES), it is further determined whether or not the layer number (layer) 32 has been registered (step S94).

  If both the function number 33 and the layer number (layer) 32 have been registered (YES in steps S93 and S94), it is determined whether or not the function number 33 and the layer number (layer) 32 are consistent. (Step S95) If not matched (Step S95, YES), a matching error is notified to the operation terminal 1 (Step S96). If they match (step S95, NO), they are left as they are (check OK). In the above example, the function number is “hierarchy number—sequential number in the hierarchy”. Therefore, the part of the layer number in the function number 33 (the part before the delimiter “−”) is the layer number (layer) 32. If they match, it is determined that they match.

Since the function number includes the hierarchy number, there is a contradiction in the following example.
Example of conflict: Function number 33 (hierarchy number-serial number in the hierarchy): hierarchy number 32
(2-2): 1 (not 2)
(2-1): 3 (not 2)
(1-1): 2 (not 1)
On the other hand, when only the function number is registered, that is, when the function number 33 is registered but the hierarchy number 32 is not registered (step S93 is YES and step S94 is NO), the function number 33 is changed to the hierarchy. A number is extracted and stored in the field of the hierarchy number 32 (step S97). As described above, since the function number is “hierarchy number—sequential number in the hierarchy”, the portion of the hierarchy number (the portion before − (hyphen)) may be extracted.

  If only the hierarchy number is registered, that is, if the hierarchy number 32 is registered but the function number 33 is not registered (step S93 is NO and step S98 is YES), the records are arranged in the hierarchy number order. At the same time (step S99), the function number is determined and stored in the function number 33 field (step S100). Since the function number is “hierarchy number-serial number in the hierarchy” as described above, it may be determined, for example, by “hierarchy number 32-natural number”. However, the present invention is not limited to this example. For example, the serial numbers in the hierarchy may be determined in alphabetical order of the first character of the function code 34.

  As in the above example, for example, first, the layers are arranged in the order of the layer numbers, and the function numbers “sequential numbers in the layers” are assigned in alphabetical order of the function codes for each layer. Then, by arranging in order of function number, the following example is obtained.

Example: Function code; Hierarchy number-Serial number in the hierarchy Before sorting SYS; 2-2
COM; 2-1
SCI; 1-1
After alignment SCI; 1-1
COM; 2-1
SYS; 2-2
If there is no input for both the function number 33 and the hierarchy number 32 (NO in steps S93 and S98), a non-input error is notified to the operation terminal 1 (step S101).

FIG. 20 is a flowchart of the hierarchy violation exception detection process.
The process of FIG. 20 is to update the access violation exception registration file (during creation) 26 being created with reference to the hierarchy definition table (during creation) 21.

  First, the hierarchy definition table (during creation) 21 and the access violation exception registration file (during creation) 26 are read (step S111). These are the states in the process of being created as described above, the hierarchy definition table (being created) 21 is the state after the processing of FIGS. 18 and 19, and the access violation exception registration file (being created) 26 is the state after the processing of FIG. It is in a state.

Then, the following processes are sequentially executed for each record in the access violation exception registration file (during creation) 26 (loop process between steps S112 and S112 ′).
With reference to the detection type code 45 of the record, the function type / variable type is recognized (step S113), and it is determined whether there is an access violation accordingly.

  The case where an access violation is determined by the determination process is as follows. By referring to the hierarchy definition table (under construction) 21, the hierarchy of each function of the reference source and the reference destination can be recognized.

(A) API function / global variable;
Based on the reference source function code 41, the reference destination function code 43, and the hierarchy definition table (during creation) 21, the reference source hierarchy and the reference destination hierarchy are recognized, and the same hierarchy as the reference source hierarchy / one hierarchy below Is normal, but when accessing other than the same hierarchy / one hierarchy below the reference source (the reference destination is higher than the reference source, or two or more levels below ( ), The access violation is determined.

(B) Local variable / local function;
When another function is accessing (when the reference source function code 41 and the reference destination function code 43 are not the same), it is determined as an access violation. This is because local variables / local functions can only be accessed within the same function.

  In both cases (a) and (b), if an access violation occurs, the corresponding detection type code 45 in the access exception permission registration file (in preparation) 26 is rewritten. That is, it is rewritten as follows.

1 (API function) ⇒ -1 (API function access violation)
2 (local function) ⇒ -2 (local function access violation)
3 (global variable) ⇒ -3 (global variable access violation)
4 (local variable) ⇒ -4 (local variable access violation)
The access violation exception registration file (during creation) 26 changes from the state shown in FIG. 13A to the state shown in FIG.

  The above-described processing is shown for each function type / variable type in steps S114 to S123 (also referred to collectively as processing of S201) shown below. explain.

  That is, first, when the detection type code 45 of the processing target record is “1” (API function), it is determined whether or not there is an access violation for this API function (step S114). This is because, as described above, based on the reference source function code 41, the reference destination function code 43, and the hierarchy definition table (under construction) 21 of this record, the reference source and the reference destination are in the same hierarchy or reference If the destination is one layer below the reference source, it is determined that there is no access violation (step S114, NO), and therefore it is determined in step S122 that there is no violation (step S122, NO).

  On the other hand, if the reference destination is a hierarchy higher than the reference source or the reference destination is a hierarchy that is two or more levels lower than the reference source, it is determined that there is an access violation (step S114, YES), The detection type code 45 of this record is rewritten to “−1” (steps S115 and S123). Of course, in this case, the determination in step S122 is YES.

  If the detection type code 45 of the processing target record is “2”, it is determined whether or not there is an access violation for this local function (step S116). As described above, based on the reference source function code 41 and the reference destination function code 43 of this record, if the reference source and the reference destination are the same function, it is determined that there is no access violation. Therefore, it is determined that there is no violation at step S122 (step S122, NO). On the other hand, when the reference source function code 41 is not the same as the reference destination function code 43 (when the local function is accessed from another function), it is determined that there is an access violation (step S116, YES), and this record The detection type code 45 is rewritten to “−2” (steps S117 and S123). Of course, in this case, the determination in step S122 is YES.

  If the detection type code 45 of the processing target record is “3”, it is determined whether there is an access violation for this global variable (step S118). This is because, as described above, based on the reference source function code 41, the reference destination function code 43, and the hierarchy definition table (under construction) 21 of this record, the reference source and the reference destination are in the same hierarchy or reference If the destination is one layer below the reference source, it is determined that there is no access violation (step S118, NO), and therefore, it is determined in step S122 that there is no violation (step S122, NO). On the other hand, when the reference destination is a hierarchy higher than the reference source, or when the reference destination is a hierarchy two or more levels lower than the reference source, it is determined that there is an access violation (step S118, YES), The detection type code 45 of this record is rewritten to “−3” (steps S119 and S123). Of course, in this case, the determination in step S122 is YES.

  If the detection type code 45 of the processing target record is “4”, it is determined whether or not there is an access violation for this local variable (step S120). As described above, based on the reference source function code 41 and the reference destination function code 43 of this record, when the reference source and the reference destination are the same function, it is determined that it is not a violation. (Step S120, NO), therefore, it is determined that there is no violation in Step S122 (Step S122, NO).

  On the other hand, when the reference source function code 41 is not the same function as the reference destination function code 43 (when the local variable is accessed from another function), it is determined that there is an access violation (step S120, YES). The detection type code 45 of this record is rewritten to “−4” (steps S121 and S123). Of course, in this case, the determination in step S122 is YES.

  If the record to be processed is not an access violation, the record (record with detection type code> 0) is deleted. That is, when the detection type code 45 of the processing target record is a positive value (> 0) (in other words, it is not impossible to determine or violates the rules, and a negative value ('-1' to '- (If any of 4 'has not been rewritten) (step S124, YES), this record is deleted from the file 26 (being created) (step S125). Note that these processes may be collectively referred to as the process of S202.

By the process of S202, the access violation exception registration file (during creation) 26 changes from the state of FIG. 13B to the state of FIG. 13C, for example.
When all the processes are completed (after exiting the loop process), the access violation exception registration file (under creation) 26 is saved in the state at that time (step S126). That is, for example, it is stored in the state of FIG. 13C (the file 26 is updated).

  Then, by performing the above-described setting process (not shown) after that, when “(24) Access permission setting” in “Access violation exception permission registration” in (4) above is performed, for example, FIG. The access violation exception registration file (being created) 26 in the state (c) is read and displayed, and for example, an arbitrary access permission setting operation is performed by the user.

  Although the flowchart of this setting process and the setting screen example are not particularly illustrated, the user can enter the exception access permission flag 46 and the column corresponding to the permission determination person 47 in the displayed access violation exception registration file (in preparation) 26. Arbitrary setting information can be input. For the exception access permission flag 46, “0” or “1” can be set. In addition, as already stated, the meaning of these numerical values is as follows.

0: Do not allow access violation 1: Allow access violation
Further, the user inputs an arbitrary name (basically, the user's own designation) or the like to the availability determination person 47.

When the user setting operation is completed, the access violation exception registration file (during creation) 26 is in the state shown in FIG. 13D, for example, and is saved in this state.
FIG. 21 is a flowchart of the “hierarchy violation registration process”.

  The process of FIG. 21 reads an access violation exception registration file (being created) 26 (for example, the state shown in FIG. 13D) in which permission of permission for access exception has been input by the user setting operation, and records in this file 26 In this process, an access violation exception registration file (registration) 27 is stored so that only records that are access violations but exceptionally allowed are left. Further, in the processing of FIG. 21, the hierarchy definition table is completed by automatically registering the unregistered portion in the hierarchy definition table (under creation) 21 based on the access violation exception registration file (registration) 27 (hierarchy definition table). (Registration) is stored as 22).

  In this description, regarding the access violation exception registration file, the state in the process of being created is distinguished as an access violation exception registration file (during creation) 26, and the completed state is distinguished as an access violation exception registration file (registration) 27. There is no particular need to make such a distinction. The same applies to the hierarchy definition table.

Hereinafter, the process of FIG. 21 will be described.
First, the access violation exception registration file (during creation) 26 (for example, the state shown in FIG. 13D) is read (step S131). Then, the processing of steps S133 to S135 is executed for each record of the file (during creation) 26 sequentially (the loop processing between steps S132 and S132 ′).

  That is, by referring to the exception access permission flag 46 of the processing target record, it is determined whether or not an access violation is permitted for the processing target record (a combination of the reference source and the reference destination) (step S133). As described above, when the exception access permission flag 46 = '1', access violation is permitted (step S133, YES), and the process of step S134 is executed. On the other hand, when the exception access permission flag 46 = '0', the access violation is not allowed (step S133, NO), so this process target record is deleted (step S135). Note that the processing in step S135 is not necessarily performed. Even if it is not deleted, for example, the determination in step S142 to be described later may be NO because there is no permissible registration.

  In the process of step S134, all unprocessed records are searched, and the same access form as the access form of the record to be processed (the access source function is the same and the access destination function and the detection type (function / variable type) ) Are the same)). That is, all unprocessed records whose reference source function code 41, reference destination function code 43, and detection type code 44 are the same as the processing target record are extracted. Further, the number of records with the exception access permission flag 46 = “1” among the extracted records is counted, and this count value + 1 is stored as “allowable number of access violation”. This is, for example, associated with the access form of the processing target record (the combination (pair) of the function of the access source, the function of the access destination and the detection type (function / variable type)), "".

  Further, the processing target record and the extracted record are all handled as processed (for example, a flag (not shown) indicating processing is recorded for each of these records). Therefore, it is assumed that these records are not the unprocessed records and are not the processing target records.

  Note that +1 of the “count value + 1” is for including the processing target record itself. As a result, with respect to the access mode of the processing target record, the number of records in which access violation is permitted (including the processing target record) is registered as “allowable number of access violation”.

  Here, the exception access permission flag 46 is arbitrarily determined and set by an administrator or the like as described above. As an example of one idea, as described above, a “program created in the past (legacy asset In the case of a program created based on (1), there may be a portion that is difficult to correct even if it is known that it is a violation. In the case where there are two difficult places, it is desirable that an abnormality is detected when there are three or more violation places (this has already been described). In this example, the “allowable number of access violations” should be ‘2’. Further, in this example, the automatic setting value of “History violation presence / absence and allowable information (allowable registration number)” in the hierarchy definition table (under construction) 21 to be described later should be “3”. In this case, according to the definition in the description of FIG. 4 described above, “when there are three or more violations, it is detected as an abnormality”.

  Of the extracted records, all the records with the exception access permission flag 46 = “0” are deleted from the file 26, and all the remaining records (flag is “1”) are treated as processed records. May be.

  When the loop processing is exited, the access violation exception registration file (being created) 26 at that time is stored as an access violation exception registration file (registration) 27 (step S136).

  That is, the access violation exception registration file (during creation) 26 is in the state shown in FIG. 13E, for example, that is, only the record whose exception access permission flag 46 is ‘1’ remains by the above processing. That is, only the access violation permitted file is left in the access violation exception registration file (during creation) 26. In step S136, the access violation exception registration file (being created) 26 in this state is stored as an access violation exception registration file (registration) 27. Furthermore, the registration information of “allowable number of access violations” corresponding to each access mode described above is also included and stored in the access violation exception registration file (registration) 27.

  After that, for example, by referring to the above “allowable number of access violations” or the like, an unregistered portion in the hierarchy definition table (during creation) 21, that is, “hierarchy violation allowable information (allowable registration number)” is automatically set. Thus, the hierarchy definition table is completed (stored as the hierarchy definition table (registration) 22).

For example, first, the hierarchy definition table 21 (under construction) is read (step S137). For example, the state shown in FIG. 12C (in the middle of creation) is read.
Then, for all combinations (pairs) of the functions of the caller and callee (however, for the callee, for each detection type), the processes of steps S140 to S144 are performed (steps S138 to S138 ′). Loop processing between steps S139 and S139 ′), “hierarchy violation existence and permissible information (allowable registration number)” are automatically registered for all of these combinations.

  In the processes of steps S140 to S144, first, it is determined whether or not the combination (pair) to be processed is an access violation (step S140). This is a determination process according to the detection type of the call destination. In other words, if the callee detection type is a local variable or local function using the method already described, it is not an access violation if the caller function and the callee function are the same. It determines (step S140, YES), and determines that it is an access violation otherwise (step S140, NO). Further, when the call destination detection type is a global variable or API function, if the callee function hierarchy is the same as or one level below the caller function hierarchy, it is not an access violation. It determines (step S140, YES), and determines that it is an access violation otherwise (step S140, NO).

  If it is determined that it is not an access violation (step S140, YES), a column of “Hierarchy violation presence / absence and allowable information (allowable registration number)” corresponding to the combination of processing targets in the hierarchy definition table (during creation) 21 Is set to “0” (step S141). For example, if an example is described using function numbers, if the caller is the function 1-1 and the callee is a local function of the function 1-1, the caller function is the same as the callee function. Therefore, it is determined that this pair is not an access violation, and for example, “0” is set as shown in FIG.

The “reference destination” is synonymous with the “call destination”, and the “reference source” is synonymous with the “call source”.
On the other hand, if it is determined that there is an access violation (step S140, NO), it is determined whether there is a registration of permission for the pair to be processed (step S142). This is determined, for example, with reference to the registration information of the “allowable number of access violations” included in the access violation exception registration file (registration) 27. As mentioned above, this registration information is registered with the “allowable number of access violations” registered for each pair where access violations are allowed. Is registered (step S142, YES). In this case, the “allowable number of access violations” corresponding to the pair to be processed is acquired, and the “allowable number of access violations” +1 is set as the processing target in the hierarchy definition table (during creation) 21. Is set in the column of “Hierarchy violation presence / absence and allowable information (allowable registration number)” corresponding to the pair (step S143).

  On the other hand, if it is determined that there is no registration of permission (NO in step S142), the presence / absence of hierarchy violation and allowable information (allowable registration count) corresponding to the pair to be processed in the hierarchy definition table (under construction) 21 "1" is set in the "" column (step S144).

  When the loop processing is exited, the hierarchy definition table (in preparation) 21 at that time is stored as a hierarchy definition table (registration) 22 (step S145). At this time, the state of the hierarchy definition table (under construction) 21 is “0”, “1”, or “2” or more in all the columns of “History violation existence / allowance information (allowable registration number)”. It should have been set. That is, the hierarchy definition table should be complete.

  Note that the processing in steps S131 to S136 may be collectively referred to as processing in S203. Similarly, the processes of steps S137 to S145 may be collectively referred to as the process of S204.

FIG. 22 is a flowchart of the “hierarchy definition table comparison process”.
At the time of hierarchy evaluation, a hierarchy definition table (registered) 22 (referred to as the previous hierarchy definition table) registered during the previous program evaluation process (an old version program, etc.) and a new evaluation target program were created. The hierarchy definition table (registration) 22 (referred to as the current hierarchy definition table) is read, and the difference information between them is detected and notified in the following procedure.

  In the process of FIG. 22, first, the previous hierarchy definition table and the current hierarchy definition table are read (step S151). Then, by comparing these two tables, a difference is obtained, and whether or not there is a change in the type of the function code (for example, if there is a function code that has increased or decreased this time, based on the previous time) (No) is determined (steps S152 and S153).

  If there is a change (increase or decrease) in the type of function code (YES in step S153), for example, the function code that has changed (the function code that was in the previous but not in this time (deleted), or the previous time All of the (additional function codes) that are not present but are included in this time are notified to the operation terminal 1 including the addition / deletion information (step S154). This is notified, for example, by creating a hierarchy definition table (difference) 29 ″ storing function codes that have changed and addition / deletion information, and transmitting them to the operation terminal 1.

On the other hand, when there is no change (addition or deletion) in the type of function code (step S153, NO), the operating terminal 1 is notified that it is normal (step S155).
FIG. 23 is a flowchart of the “access violation exception registration file comparison process”.

  In FIG. 23, at the time of hierarchical evaluation, an access violation exception registration file (during creation) 26 (referred to as a previous access violation exception registration file) registered at the time of the previous program evaluation process (an old version program, etc.) The newly created access violation exception registration file (currently being created) 26 (referred to as the current access violation exception registration file) is read for the program to be evaluated this time, and it is detected and notified by the following processing that there is a difference.

As already described, the access violation exception registration file (being created) 26 to be read is in the state of FIG.
First, the previous access violation exception registration file and the current access violation exception registration file are read (step S161). Then, the two are compared to obtain a difference (step S162), and it is determined whether there is a change (for example, whether there is a deleted record or an added record) (step S163).

  If there is a change (if there is a difference between them) (step S163, YES), and if there is data that was present in the previous access violation exception registration file but deleted in the current access violation exception registration file For example, this portion is notified to the operation terminal 1 or the like (step S164).

  Also, if there is data added in the access violation exception registration file (under construction) this time, this additional part (in order to prevent additional violations from being overlooked; The operation terminal 1 is notified (to make the user determine whether or not to modify the program) (step S165).

On the other hand, when there is no change between the previous time and the current time (step S163, NO), the operating terminal 1 is notified that it is normal (step S166).
FIG. 24 is a processing flowchart of the scoring task unit 12.

  Here, it is assumed that the scoring request includes information specifying the product to be scored, and the various information / programs related to the processing in FIG. 24 are the various information / programs related to the specified product. It shall be.

24A shows the main flow, FIG. 24B shows the detailed flow of the scoring process in step S171, and FIG. 24C shows the detailed flow of the process in step S183.
As shown in FIG. 24 (a), the scoring process is schematically executed (step S171), and when the process ends normally (step S172, YES), the calculation result is notified to the server main process (step S173). If it is not a normal end (step S172, NO), the server main process is notified of the error content (step S174).

Hereinafter, the scoring process in step S171 will be described with reference to FIGS.
(1) Confirmation of whether or not processing can be performed The scoring task unit 12 first determines whether there is information necessary for scoring (step S181). For example, the following two points are determined. If both points are OK, it is determined that there is information necessary for scoring. Definitions are set in the hierarchy definition table (registration) 22 and the operation information definition table 23. (However, the operation information definition table 23 is not necessarily required; it is not essential).
-The program source 28 has been registered.

If the scoring task unit 12 determines that there is no information required for scoring (step S181, NO), it returns an error content to the server main processing unit 11 as an error (step S189), and ends this processing. . On the other hand, if it is determined that there is information necessary for scoring (YES in step S181), the process proceeds to step S182 to perform scoring processing.
(2) Count and register the number of program steps for each function.

  First, the number of program steps of the program source 28 is counted (for example, counted for each function), and the result is registered in the access violation scoring file 25 (step S182). The access violation score file 25 needs to store the number of steps (LOC) for each function at least before executing the evaluation score calculation process.

  Here, the program source 28 includes a plurality of program source files. The file name of each program source file is given according to a predetermined rule predetermined by a developer or the like, for example. For example, by referring to the file name, it is possible to determine which function corresponds to the program source file.

  That is, in this example, the function code is registered in the “hierarchy definition table” or the like for the correspondence relationship between each program source file constituting the program source 28 and each function, assuming the following method a). However, the present invention is not limited to this example, and other methods (for example, the following methods b) and c) may be performed.

a) Add a function code to the file name. Further, information indicating a hierarchy may be added.
As an example, for example, a program naming convention such as “xxxx_yyyy_abcdef.c” (xxxx: hierarchy, yyyy: function code) is determined, and the file name of each program source file constituting the program source 28 is Give them according to the naming convention. Note that a program that violates the rules may be provided with a check function that makes an error.

  Thus, for example, for each program source file constituting the program source 28, the number of program steps of the file (number of lines, etc.) is counted, and the function code is obtained from the file name of the file, Based on this, the number of steps for each function (for each function code) can be registered in the access violation scoring file 25.

  When there are a plurality of program source files for one function, the program / step count process is performed for a plurality of program source files having the same function code included in the file name. Thus, these total values are registered in the access violation scoring file 25.

  Also, when referring to the hierarchy definition table (registration) 22 or when finding the corresponding counting column of the access violation counting file 24, the hierarchy and function code are acquired by referring to the file name.

b) Directory designation The directory structure is made the same as the software hierarchy, and each program source file is stored therein (for example, all program source files related to the function whose function code is SCI are stored in a directory called SCI.

c) Register in the definition file
The correspondence relationship between the hierarchy, the function, and the program source file name is registered in a definition file (a definition macro (not shown) or a definition table). That is, by referring to this definition file, it is possible to determine which program source file corresponds to which function in which hierarchy.
(3) Count access violations.

  For the program source 28 of the product to be evaluated, an access violation is determined with reference to the hierarchy definition table (registration) 22, and the number of access violations is counted on the access violation counting file 24 (step S183). This is intended for the above four evaluation items, but is not limited to this example.

As described above, the hierarchy definition table (registration) 22 includes, for example, “no violation” for each pair of the caller 36 (function unit) and the callee 35 (function type / variable type unit for each function). Or “violated” is registered (or an allowable number of violations is registered). On the other hand, the function code and function / variable type (type) related to the program source 28 can be identified by the above-described method, for example. As a result, the function of the caller, the function of the callee, and the function type / variable type with respect to the program source 28 are recognized, and the presence / absence of violation can be determined by referring to the hierarchy definition table (registration) 22. Details of the process in step S183 will be described later with reference to a detailed flow shown in FIG.
(4) Weight the violation count results.

Using the weighting coefficients for the four evaluation items included in the motion information definition table 23, the total number of the violations obtained in step S183 is corrected to obtain a weighted total result (step S184). That is, for example, the result obtained by multiplying the total value in the access violation count file 24 by the weight count value in the operation information definition table 23 is registered in a weighted total result file (not shown).
(5) The access violation is scored.

For example, the above-described evaluation score is calculated (step S185).
Since the evaluation score calculation method has already been described using an example, only a brief description will be given here.

  That is, the above “weighted count result” is divided by the number of program steps (KLOC) and further multiplied by a predetermined unit (for example, 1000) to obtain the “points per unit”, which is defined as motion information definition After adding the “footing threshold” in the table 23 as necessary, the “footing threshold” is converted to a score system with the “footing threshold” being a perfect score of 100, thereby obtaining the “point after footing”. 100— “Point after stepping” is set as the “evaluation point”.

As the “evaluation score”, an evaluation score for each function (to be a caller), an evaluation score for the entire program source 28, and the like are obtained.
(6) Calculate the deviation value. The calculated evaluation score is stored, and if the “evaluation score” is calculated and stored for other products in the past, the evaluation score is stored (registered). If the number of products that are set is equal to or greater than a predetermined value that is arbitrarily set in advance (5 or more in this example) (YES in step S186), a deviation value is calculated (step S187).

The deviation value calculation processing has already been described and will not be described here.
If the number of products for which the evaluation score has been calculated and registered is less than the predetermined value (less than 5) (NO in step S186), the process proceeds to step S188 as it is.
(7) Return the processing result to the server main processing.

The calculation result, that is, the evaluation score, the deviation value, and the like are returned to the server main processing unit 11 (step S188).
When a program developer or the like creates an arbitrary program, the management server 10 analyzes and scores the program structure, so that the program can be created according to the evaluation score, deviation value, and the like according to the software structure design. Or, at least, it can be confirmed that the level is not down compared to other past products. Since numerical evaluation and scoring are performed, an objective and easy-to-understand evaluation standard is shown, so that accurate evaluation and determination can be easily performed. For example, if it is determined that the level is down, the person in charge of development will review the program.

  Note that the software structure design is a software structure design in which there is a restriction on access between functions in software including a plurality of functions, as already described. In addition, restrictions on the hierarchical structure may be added. Regarding restrictions related to the hierarchical structure, for example, as described with reference to FIG. 2 etc., in the software structure in which a plurality of functions are hierarchized, it is illegal to call a higher-order function from at least a relatively lower-order function. There are restrictions such as. In addition to this, even when calling a lower-level function from a higher-level function, calling a function of a layer that is two or more levels lower may be a violation. .

  Further, the administrator can maintain the structure at the initial stage of development simply by confirming that the evaluation score is equal to or higher than the reference value (evaluation score of the past product (product before change, etc.)). Further, by calculating the deviation value, it is possible to improve compared with past products. Quality can be objectively evaluated by scoring.

If it says from another side, it can be said that the following effects are acquired by this system.
-The software structure can be confirmed without looking at the program itself (development efficiency).
-Since the software structure does not change, maintainability can be maintained (maintainability).

When the score does not decrease compared to the evaluation score of the past product, it can be determined that the software structure is not changed (maintained) (quality does not decrease).
It should be noted that the software structure design limitation described above does not mean that the software does not immediately operate normally even if it is not completely observed (even if there is a slight violation). For example, if you want to make sure that the above restrictions work properly (at least not worse than the past), but you want to make sure that the quality does not go down. Can be used effectively.

  Hereinafter, a detailed example of the process of step S183 will be described with reference to FIG. In this example, a case where functions and function types / variable types (four evaluation items, etc.) can be identified by names (program source file name, function name, variable name) is shown, but the present invention is not limited to this example. .

  Here, as an example, it is assumed that functions, program source file names, and function / variable names are determined according to the following rules. An example of a program based on this rule is shown in FIG.

Although an example of a function whose function code is “SCI” is shown here, of course, the present invention is not limited to this example.
* Function code identification The function code of the function to which it relates is included as part of the file name of each program source file. That is, for example, according to a predetermined rule, the head of each program source file name is “capital letter indicating function code +“ _ ”(underscore)”. In this case, it is further assumed that the function code is 3 characters.

Example: Program source file name = SCI_Driver.c
Therefore, in the above example, the function code (which may be regarded as a function name) is determined to be “SCI”. Note that one program source file does not necessarily correspond to one function. A plurality of program source files may correspond to one function. In other words, the function code may be a grouping of a plurality of program source files (assigned to a function composed of a plurality of program source files). In the above example, there may be a program source file whose first three characters are “SCI” in addition to “SCI_Driver.c”.
* Determination of API Function All functions that are API functions have the function name beginning with “capital letter of function code +“ _ ”(underscore).

Example: SCI_Initial (void);
FIG. 25 shows a program example using the above specific example.
* Distinguishing local functions All functions that are local functions have the function name beginning with "the first letter of the function code is uppercase and the rest is lowercase +" _ "(underscore)".

Example: Sci_FifoSet (void);
FIG. 25 shows a program example using the above specific example.
* Distinguishing global variables All variables that are global variables have “g_” + the first one of the function code in upper case letters and the rest in lower case letters.

Example: g_SciSendState;
FIG. 25 shows a program example using the above specific example.
* Distinguishing local variables All variables that are local variables have “g” + the first letter of the function code as upper case letters and the rest as lower case letters.

Example: gSciExpcntlUS;
FIG. 25 shows a program example using the above specific example.
In the above example, it is desirable to add “Do not use g at the beginning” as a rule relating to the function code.

  As described above, in this method, the name of the function / variable in the program source statement includes information indicating the function to which the function / variable belongs and information indicating the function type / variable type of the function / variable. ing. These pieces of information follow a predetermined rule as in the above example. Thus, in this method, by referring to the name of the function / variable, it is possible to determine the function to which the function / variable belongs, the function type / variable type of the function / variable, and the like.

  In this way, in this example, the function and function type / variable type can be distinguished by the name. Therefore, unlike those that can be distinguished only in the source such as static variables, for example, a global variable of a certain function and another variable It is possible to distinguish a global variable of a function, or a variable of a certain function and a variable of another function having the same variable name.

The detailed flowchart shown in FIG. 24C will be described below using the above example.
In FIG. 24B, all program source files constituting the program source 28 to be evaluated are sequentially analyzed (step S191), and the analysis processing of steps S192 to S196 is performed on the program source file to be analyzed. repeat. When the analysis process is completed for all program source files, the process of step S197 is performed, and this process ends.

Hereinafter, first, the processing of steps S192 to S196 will be described.
First, the function code (function name) is determined based on the file name of the program source file to be analyzed (step S192). In the above example, since the program source file name = SCI_Driver.c, it is determined that the function code (function name) is “SCI”. In the example illustrated in FIG. 4, the function number 33 of the function whose function code 34 is “SCI” is “function 1-1”. That is, this is the function number of the caller 36 in the hierarchy definition table (registration) 22.

  Then, with respect to the program source file to be analyzed, for example, the first line to the last line are sequentially referred to, and each time an arbitrary function finds a place where an arbitrary other function or variable is called, the call destination function Alternatively, based on the name of the variable, the function type / variable type and the function of the call destination are determined.

  That is, for example, if the first part of the name starts with g and the next of g is “_” (underscore), it is determined as a global variable, and the next of g is not “_”. In this case, it is determined as a local variable. Further, three characters following “_” or g are extracted, and all of them are capitalized and recognized as a function code of the function of the call destination.

  Also, for example, if the first part of the name starts with something other than g, “_” (underscore) is found, the character string before “_” is extracted, and when all the extracted characters are capital letters , It is determined to be an API function. If only the first character in the extracted character string is capitalized, it is determined to be a local function. In any case, the extracted character string in all capital letters is recognized as the function code of the call destination function.

  With the above processing, the function number of the caller 36, the function code 34 of the callee, and the type (any of the four evaluation items shown in the callee 35; function type / variable type) can be determined. Based on the above, it is possible to determine whether or not there is a violation by referring to the hierarchy definition table (registration) 22, and if it is a violation, it can be counted in the corresponding counting column of the access violation counting file 24 (steps S 193, S 194, S 195) S196). At this time, when the call destination is the own function, it may be determined that there is no violation without referring to the hierarchy definition table 15.

  Thus, for example, if the call destination is a global variable of another function, the presence / absence of violation is determined with reference to the hierarchy definition table (registration) 22, and if it is a violation, it is counted in the corresponding counting column of the access violation counting file 24. (Step S193).

  Similarly, if the call destination is a local variable of another function, the presence / absence of a violation is determined with reference to the hierarchy definition table (registration) 22, and if it is a violation, it is counted in the corresponding counting column of the access violation counting file 24 ( Step S194).

  If the call destination is an API function of another function, the presence / absence of violation is determined with reference to the hierarchy definition table (registration) 22, and if it is a violation, it is counted in the corresponding counting column of the access violation counting file 24 (step S195). .

  If the call destination is a local function of another function, the presence / absence of violation is determined with reference to the hierarchy definition table (registration) 22, and if it is a violation, it is counted in the corresponding counting column of the access violation counting file 24 (step S196). .

  When the above processing is executed for all the call processing of the program file to be analyzed, if there is an unanalyzed program file, the same processing is executed for the next analysis target, and processing has been completed for all the program files. The process exits the loop and proceeds to the process of step S197.

  In step S197, according to the setting of the hierarchy definition table (registration) 22, the contents of the counted access violation counting file 24 are corrected in some cases. As described above, when a value other than ‘0’ and ‘1’ (for example, ‘3’) is set, the above-described correction is performed by using this as an allowable number of violations.

In the above step S184, for example, the above-described weighting is performed using such a corrected total result.
15 to 24, the CPU (not shown) of the management server 10 reads out a predetermined application program stored in advance in a storage device (hard disk, memory, etc.) not shown. It is realized by executing.

  Note that the above-described processing example is an example, and the present invention is not limited to this example. In addition, it is not always necessary to execute all the processes in the above-described process example. For example, the semi-automatic generation of the hierarchy definition table is performed only in (2) and (3) shown in FIG. 10, for example, and the above-mentioned “non-existence of hierarchy violation and allowable information (allowable registration number)” is arbitrarily set manually by the user. You may do. In this example, the access violation exception registration file 26 (27) does not necessarily have to be generated (that is, in the process of (2) in FIG. 10, only the hierarchy definition table (under creation) 21 is generated). May be).

  As described above, according to the program structure evaluation system and the like of the present invention, whether or not a program has been created according to software structure design with restrictions on access between functions in software composed of a plurality of functions. By analyzing and scoring the program, it can be easily evaluated. Furthermore, the hierarchy definition table required for the analysis and scoring can be generated semi-automatically, and the labor for setting the hierarchy definition table can be reduced.

  Since a newly created product (program or the like) does not have a corresponding hierarchy definition table, the corresponding hierarchy definition table must be created in advance before the hierarchy evaluation. This may be input manually, but it takes a lot of time to create a new one when the scale is large.

In contrast, in this example, the hierarchy definition table can be semi-automatically created as described above.
In addition, as described above, the old software (legacy assets) may be modified to create new software, but the legacy assets violations should be corrected even if they are known to be violations. In many cases, it may be difficult to maintain the current status (no more violations). However, if a violation is deleted and added at the same time as creating new software, the additional violation may be overlooked. For example, if the number of violations increases by one and decreases by one, the total number of violations does not change, so there is a possibility that a new violation will be missed.

  On the other hand, in this method, exception information (program, function / variable name, violation contents, etc.) of the hierarchy violation is recorded, and the previous information (exception information etc. created in the previous version of the program) By comparing, it is determined whether there is a new violation, and if it is new, it is determined whether the existing violation should be permitted so as not to overlook the newly generated violation.

As described above, the present invention provides the following effects in addition to the effects described above.
(1) Semi-automatic generation of a hierarchy definition table can be realized. For example, the hierarchy definition table (registration) 22 is automatically created (development efficiency) simply by the user setting the hierarchy definition and whether or not the violation is permitted.
(2) It is no longer necessary to overlook new access violations. (Maintainability)
In other words, the various processing functions of the management server 10 described above can be said to have the following various processing function units (not shown).

That is, it can be said that the management server 10 includes various processing function units such as the following violation presence / absence information storage unit, violation determination unit, aggregation unit, evaluation score calculation unit, and violation presence / absence information generation unit.
Violation presence / absence information storage unit, for each function pair that is a combination of the function type / variable type of the function to be called and the function to be called, according to the restrictions on access between the functions of the software consisting of a plurality of functions, Violation presence / absence information storing the existence / non-existence of violations and / or the allowable number of violations is stored.

  The violation determining unit sequentially refers to the program source statements of the software to be evaluated, and each time a process for calling an arbitrary function / variable of another function from an arbitrary function is detected, the function of the called function / variable The type / variable type is discriminated, and the violation presence / absence information is further referenced to determine whether the call is a violation.

The counting unit counts the number of violations for each function or / and for the entire software to be evaluated based on the determination result by the violation determining unit.
The evaluation score calculation unit calculates the evaluation score for the entire evaluation target software and / or each function thereof based on the total number of violations by the totaling unit.

The violation presence / absence information generation unit generates the violation presence / absence information based on the software to be evaluated in advance and stores it in the violation presence / absence information storage unit.
For example, the violation presence / absence information generation unit
A program analysis unit that extracts data of predetermined data items related to each function from the evaluation target software and stores the data in the violation information in the initial state;
A hierarchy data setting unit that sets data of data items related to the hierarchy for the violation presence / absence information after processing by the program analysis unit may be included.

  Further, for example, the violation presence / absence information includes a function name or / and function code which is identification information of an arbitrary function, a layer number indicating a layer of the function, and / or a function number including the layer number. The predetermined data item relating to each function that has the data item and is extracted is the function name or / and the function code, and the arbitrary data item relating to the hierarchy to be set is the hierarchy number Or / and the function number may be used.

  Further, for example, when both the hierarchy number and the function number are set, the hierarchy data setting unit checks whether or not both match, and either the hierarchy number or the function number is checked. When is set, the other data may be generated based on the setting data.

  In addition, for example, the program analysis unit may further extract data indicating the function pair from the evaluation target software and store the function pair data in the access violation exception information in the initial state. Good.

For example, the violation presence / absence information generation unit
Referring to the access violation exception information, it is determined whether or not there is an access violation for each of the stored function pairs. The function pair that is determined not to be an access violation is deleted from the access violation exception information. You may further have an access violation discrimination | determination part which memorize | stores violation classification with respect to the function pair determined to exist.

For example, the violation presence / absence information generation unit
For each function pair of the access violation exception information after processing by the access violation determining unit, it may further include a violation permission setting unit for arbitrarily setting whether or not to allow the access violation.

In addition, for example, the violation existence information generation unit
Using the access violation exception information after setting by the violation allowance setting unit, the violation presence information after setting by the hierarchical data setting unit, whether there is a violation for each function pair in the violation presence information or / And a violation presence / absence information setting unit for automatically setting the allowable number of violations.

  Also, for example, the previous access violation exception that is the access violation exception information that has been generated for the software to be evaluated and the other software related to the software to be evaluated. It may further include a violation increase / decrease detection unit that compares information with each other and extracts differences when there is a difference.

  In addition, for example, the violation presence / absence information corresponding to the evaluation target software and the previous violation presence / absence information that has been generated corresponding to another software related to the evaluation target software When there is a difference in registered functions compared to each other, a function change detection unit that extracts a difference may be further included.

  Further, for example, when the evaluation score has been calculated for each of a plurality of other software, the evaluation score of the evaluation target software is based on the plurality of evaluation scores including the evaluation score of the evaluation target software. You may further have a deviation value calculation part which calculates a deviation value.

DESCRIPTION OF SYMBOLS 1 Operation terminal 2 Network 10 Management server 11 Server main process part 12 Pointing task part 13 Definition access task part 14 Definition production | generation task part 15 Deviation value count file 21 Hierarchy definition table (under construction)
22 Hierarchy definition table (registration)
23 Action information definition table 24 Access violation counting file 25 Access violation score file 26 Access violation exception registration file (under construction)
27 Access violation exception registration file (registration)
28 Program source 31 Function name 32 Layer number (layer)
33 Function number 34 Function code 35 Call destination 36 Call source 41 Reference source function code 42 Source name 43 Reference destination function code 44 Detection target name 45 Detection type code 46 Exception access permission flag 47 Accessibility determiner 51 Function name 52 Hierarchy number (layer )
53 Function number 54 Function code 55 Callee 56 Caller

Claims (20)

In a computer system for performing a predetermined evaluation for arbitrary software,
In accordance with restrictions on access between software functions consisting of multiple functions, for each function pair that is a combination of the function type / variable type of the function to be called and the function to be called, whether there is a violation, and / or A violation presence / absence information storage means for storing violation violation presence / absence information in which the allowable number of violations is stored;
Each time a process for calling an arbitrary function / variable of another function from an arbitrary function is detected by sequentially referring to the program source statements of the software to be evaluated, the function type / variable type of the called function / variable is changed. Discriminating and referring to the violation presence / absence information to determine whether the call is a violation or not,
Based on the determination result by the violation determination unit, a totaling unit that totals the number of violations for each function or / and the entire software to be evaluated;
An evaluation score calculating means for calculating an evaluation score for the whole evaluation target software and / or each function thereof based on the total number of violations by the counting means;
Violation presence / absence information generating means for generating the violation existence / non-existence information and storing it in the violation presence / absence information storage means based on the evaluation target software in advance,
A program structure evaluation system comprising: The violation presence / absence information generating means includes
Program analysis means for extracting data of predetermined data items relating to each function from the evaluation target software, and storing this in the violation information on the initial state;
Hierarchical data setting means for setting data of data items related to the hierarchy for the violation presence / absence information after the processing of the program analysis means,
The program structure evaluation system according to claim 1. The violation presence / absence information includes a function name or / and function code, which is identification information of an arbitrary function, and a data item of a layer number indicating the layer of the function or / and a function number including the layer number. And
The extracted predetermined data item relating to each function is the function name or / and the function code,
3. The program structure evaluation system according to claim 2, wherein the arbitrary data item related to the hierarchy to be set is the hierarchy number or / and the function number. Hierarchical data setting means
If both the hierarchy number and the function number are set, check whether they match,
4. The program structure evaluation system according to claim 3, wherein when one of the hierarchy number and the function number is set, the other data is generated based on the setting data.   3. The program analysis unit further extracts data indicating the function pair from the evaluation target software, and stores the function pair data in access violation exception information in an initial state. Program structure evaluation system. The violation presence / absence information generating means includes
Referring to the access violation exception information, it is determined whether or not there is an access violation for each stored function pair. The function pair that is determined not to be an access violation is deleted from the access violation exception information. 6. The program structure evaluation system according to claim 5, further comprising an access violation determining means for storing a violation type for a function pair determined to be present. The violation presence / absence information generating means includes
7. A violation permission setting unit for arbitrarily setting whether or not to allow the access violation for each function pair of the access violation exception information after the processing by the access violation determination unit. The program structure evaluation system described. The violation presence / absence information generating means includes
Using the access violation exception information after setting by the violation permission setting means, with respect to the violation presence information after setting by the hierarchical data setting means, presence / absence of violation for each function pair in the violation presence information or / 8. The program structure evaluation system according to claim 7, further comprising a violation presence / absence information setting means for automatically setting the allowable number of violations. The access violation exception information corresponding to the evaluation target software and the previous access violation exception information that is the access violation exception information that has been generated corresponding to another software related to the evaluation target software. compared to the further 5 Symbol mounting structure of a program evaluation system according to claim characterized in that it has a violation decrease detecting means for extracting a difference if there is a discrepancy.   The violation presence / absence information corresponding to the software to be evaluated is compared with the previous violation presence / absence information that has been generated corresponding to another software related to the evaluation target software. 10. The program structure evaluation system according to claim 1, further comprising function change detecting means for extracting the difference when the registered functions are different.   When the evaluation score is calculated for each of a plurality of other software, a deviation value is calculated for the evaluation score of the evaluation target software based on the plurality of evaluation scores including the evaluation score of the evaluation target software. The program structure evaluation system according to claim 1, further comprising a deviation value calculation unit that performs the calculation. A weight value storage means in which a predetermined weight value is registered in advance for each function type / variable type;
The counting means corrects the counting result for each function type / variable type by multiplying the corresponding weight value when counting the number of violations,
The program structure evaluation system according to any one of claims 1 to 10, wherein the evaluation score calculation means calculates the evaluation score based on the corrected aggregation result.   When calculating the evaluation score for each function, the evaluation score calculating means obtains the number of violations per unit step based on the total number of violations for each function type / variable type, The program structure evaluation system according to claim 1, wherein the evaluation score is obtained based on the number of violations per unit step number.   The evaluation score calculating means obtains the evaluation score using a value after a sufficient threshold is set using a threshold threshold set in advance for the number of violations per unit step number. The program structure evaluation system according to claim 12. Each of the functions is realized by one or more program source files,
Each function type is an API function or a local function.
15. The program structure evaluation system according to claim 1, wherein each of the variable types is a global variable or a local variable. The function / variable name in the program source statement includes information indicating a function to which the function / variable belongs and information indicating a function type / variable type of the function / variable. 15. Symbol mounting structure of a program evaluation system. The software composed of the plurality of functions has a software structure in which the plurality of functions are hierarchized.
The restriction on access between the functions related to the software is that it is a violation to call a higher-order function from a lower-order function at least relatively, and the local function of another function from any function 17. The system for evaluating a program structure according to claim 16, wherein the program structure is called a local variable. The evaluation target software is embedded software,
18. The program structure evaluation system according to claim 17, wherein in the layered software structure, an upper layer is an application, an intermediate layer is middleware, and a lower layer is a driver. In a computer system for performing a predetermined evaluation for arbitrary software,
A system in which a terminal and a server device are connected to a network,
The server device
In accordance with restrictions on access between software functions consisting of multiple functions, for each function pair that is a combination of the function type / variable type of the function to be called and the function to be called, whether there is a violation, and / or A violation presence / absence information storage means for storing violation violation presence / absence information in which the allowable number of violations is stored;
Each time a process for calling an arbitrary function / variable of another function from an arbitrary function is detected by sequentially referring to the program source statements of the software to be evaluated, the function type / variable type of the called function / variable is changed. Discriminating and referring to the violation presence / absence information to determine whether the call is a violation or not,
Based on the determination result by the violation determination unit, a totaling unit that totals the number of violations for each function or / and the entire software to be evaluated;
An evaluation score calculating means for calculating an evaluation score for the whole evaluation target software and / or each function thereof based on the total number of violations by the counting means;
Violation presence / absence information generating means for generating the violation existence / non-existence information and storing it in the violation presence / absence information storage means based on the evaluation target software in advance,
A program structure evaluation system comprising: Computer
In accordance with restrictions on access between software functions consisting of multiple functions, for each function pair that is a combination of the function type / variable type of the function to be called and the function to be called, whether there is a violation, and / or A violation presence / absence information storage means for storing violation violation presence / absence information in which the allowable number of violations is stored;
Each time a process for calling an arbitrary function / variable of another function from an arbitrary function is detected by sequentially referring to the program source statements of the software to be evaluated, the function type / variable type of the called function / variable is changed. Discriminating and referring to the violation presence / absence information to determine whether the call is a violation or not,
Based on the determination result by the violation determination unit, a totaling unit that totals the number of violations for each function or / and the entire software to be evaluated;
Based on the result of counting the number of violations by the counting means, the evaluation score calculating means for calculating the evaluation score for the entire evaluation target software or / and each function thereof, in advance, based on the evaluation target software, Violation presence / absence information generating means for generating violation presence / absence information and storing it in the violation presence / absence information storage means,
Program to function as.

Images