WO2015145539A1

WO2015145539A1 - Device for creating abstract diagram of program and program for creating abstract diagram of program

Info

Publication number: WO2015145539A1
Application number: PCT/JP2014/058068
Authority: WO
Inventors: 大輔福井; 玄太是木
Original assignee: 株式会社日立製作所
Priority date: 2014-03-24
Filing date: 2014-03-24
Publication date: 2015-10-01
Also published as: JPWO2015145539A1; JP6087473B2

Abstract

　The present invention provides a device for creating an abstract diagram of a program, the device creating a program diagram that is simplified in order to facilitate the understanding of the outline of a complicated program, without requiring manual settings by a user or a developer. In this device, a group of other modules that reference the same external data (e.g., global variables and file data) as that referenced by a module is abstracted as one module. When no external data exists that is referenced by a module, a group of other modules called from among modules is abstracted as one module. Module abstraction is performed by calculating the degree of a lack of cohesiveness in the abstracted module and repeating the abstraction process until this value exceeds a threshold value, and an abstract diagram of the program to be evaluated is outputted.

Description

Program abstract diagram creation device and program abstract diagram creation program

The present invention relates to a technique for visualizing the structure and behavior of a program.

There are methods of using program diagrams such as flowcharts and sequence diagrams to understand the structure and behavior of programs. The program diagram can be generated from the source code of the program using a commercially available visualization tool. However, when a program diagram is generated for a complex program, the program diagram is also complicated and is not suitable for the purpose of understanding the outline of the entire program.

In order to solve this problem, for example, Patent Document 1 proposes a method in which a developer visualizes only a specific module by manually setting a module to be visualized in advance. In this way, by showing only the necessary modules in the program diagram, it becomes possible to facilitate understanding of the outline of the entire program.

JP-A-5-257666

However, in the method described in Patent Document 1, it is difficult for a developer to manually set a module to be visualized in advance, so that it is difficult to apply to a complicated program.
For example, when a simplified flowchart of a complex program is created, some important module groups must be manually extracted from the complex group of modules. Furthermore, to create a flowchart, it is necessary to be able to illustrate the relationship between modules, but it takes a lot of time to manually extract this relationship.

Therefore, an object of the present invention is to provide a program abstract diagram creation device that can easily create a simplified program diagram without requiring manual settings by a user or a developer and can illustrate the relationship between modules. And providing a program abstract diagram creation program.

In order to solve the above-described problems, in the present invention, a program abstract diagram creation device that displays an abstract diagram of an evaluation target program in accordance with a specified input of abstraction is provided with at least a module configuration and reference data from the source code of the evaluation target program. An abstract diagram creation processing unit that creates source code analysis data having call module data and module-specific importance data having at least importance data for each module for each evaluation viewpoint, or reads already created data Accepting the user-specified abstraction level, the threshold level of the importance of the module to be visualized corresponding to the abstraction level, the abstraction level determination unit that sets the threshold value of LCOM, and the module level An abstraction target module that selects a module whose importance is equal to or higher than the threshold as an abstraction target module A determination module, an external data access determination module that determines whether or not the abstraction target module refers to external data, and the abstraction target module that references the external data And a first abstraction processing unit that abstracts the other non-abstraction modules referring to the external data together as one new abstraction module, and the abstraction target module refers to the external data A second abstraction processing unit that abstracts the abstraction target module and other non-abstraction modules called by the abstraction target module as one new abstraction module. The abstract diagram creation processing unit calculates a degree of lack of cohesion (LCOM) of the new abstraction module, and the degree of lack of cohesion is the threshold value. If the threshold value is not exceeded, the abstract module is registered, and a flag is set with the non-abstract modules collected in the registered new abstract module as an abstracted module Then, the registered new abstraction module is set as the next abstraction target module, the process proceeds to the external data access determination unit, and if the degree of cohesiveness exceeds the threshold, the abstraction module When the abstraction target module determination unit determines that there is no non-abstraction module to be selected as the abstraction target module, the module abstraction processing is performed. The abstract diagram creation processing unit refers to the abstracted flag and calls only the non-abstracted module as a node. And configured to output the abstract view of the full format.

According to the present invention, it is possible to construct and display a simplified program diagram without manually setting a module group in the source code of the evaluation target program in advance by a developer or a user. Effects other than those described above will be clarified in the description of the embodiments.

It is an example of the hardware block diagram of the information processing apparatus with which the program abstract drawing production apparatus of this invention is mounted. It is a figure which shows the example of the program abstract drawing preparation program of this invention, the software structure of a database program, and a data table structure. It is a figure which shows the example of the database table which memorize | stores the source code analysis data. It is a figure which shows the example of the database table which memorize | stores the importance data 211 by module. It is the flowchart which showed the program abstract drawing creation processing. It is the flowchart which showed the abstraction module registration process. It is a figure which shows the example of the database table which memorize | stores the abstraction module registration data. It is the figure explaining the characteristic which the calculation formula of the software metrics LCOM showing the degree of lack of cohesiveness, and the value of LCOM show. It is the schematic which illustrated in an easy-to-understand manner the abstraction process from step S604 to step S611 of abstraction module registration processing. It is an example of a screen of the program abstract diagram creation apparatus to which the present invention is applied.

Hereinafter, an embodiment of a program abstract diagram creation apparatus, a program abstract diagram creation method, and a program abstract diagram creation program according to the present invention will be described in detail with reference to the drawings.

In this embodiment, an example of a module abstract diagram creation method for source code written in C language will be described.

FIG. 1 is an example of the hardware configuration of the present invention. As hardware of the program abstract diagram creation device (information processing device) 100, a central processing unit 101, an input device 102 such as a keyboard and a mouse, a secondary storage device 103 such as a hard disk, a main storage device 104 such as DRAM, a display, etc. A display device 105 and a communication device 107 are included. Each component device is connected by a bus 106, and data can be transmitted and received between the component devices. Further, the program abstract diagram creation apparatus (information processing apparatus) 100 can be connected to another information processing apparatus 110 having the same hardware configuration via a communication network 120 such as the Internet. The above is an example of the hardware configuration, and the present invention is not limited to this.

FIG. 2 shows an example of the software configuration of the present invention. The program abstract diagram creation program 200 is a program for creating a program abstract diagram according to the present invention, which is stored in the secondary storage device 103 of the program abstract diagram creation device 100, loaded into the main storage device 104, and central processing. When executed by the apparatus 101, the abstract diagram creation processing unit 201, the abstraction level determination unit 202, the abstraction target module determination unit 203, the external data access determination unit 204, the data access abstraction processing unit 205, and the control flow abstraction processing unit 206 Each function unit includes an abstracted data processing unit 207 and an LCOM threshold determination unit 208. Details of the processing contents of the program abstract diagram creation program 200 will be described with reference to FIG.

The database program 209 is a general database program that can store arbitrary data. In this embodiment, the database program 209 stores source code analysis data 210, module importance data 211, and abstract module registration data 212. The source code analysis data 210 will be described in detail with reference to FIG. The module-specific importance data 211 will be described in detail with reference to FIG. The use of the database program 209 is not essential, and instead, the source code analysis data 210, the module importance data 211, and the abstract module registration data 212 may be stored as file data in the secondary storage device 103.

The program abstract diagram creation program 200 and the database program 209 are programs stored in the secondary storage device 103 of the information processing device, and are read into the main storage device 104 by the central processing unit 101 and executed. An OS (Operating System) is involved in the execution of these programs, but since this is a known technique, description and description are omitted. In addition, these programs may be executed on the same

information processing apparatus

100 or 110, or may be separately executed on different

information processing apparatuses

100 and 110 via the network 120.

FIG. 3 is an example of a database table representing the source code analysis data 210. The result of analyzing the source code using a commercially available source code analysis tool or the like is stored here. Since there are various commercially available analysis tools and means for storing analysis results in the database, description thereof is omitted here.

The module column 301 of the source code analysis data table 210 in FIG. 3 is a column for storing the identifier of the module. In the present embodiment, the module identifier is assumed to be a combination of a function name and a file name, but is not limited to this, and can be arbitrarily determined by the developer. For example, it is possible to define a single library as a module instead of a function unit. The module identifier may be data that can uniquely identify the module.

The reference data column 302 is a column for storing an identifier of external data referred to by the module. External data refers to, for example, C language global variables, files, communication sockets, databases, and the like. However, the definition of the external data is not limited to this, and any data that the module uses for processing may be used. For example, it is possible to define a Web service that returns certain character string data as external data. The identifier of the external data only needs to be able to uniquely identify the data such as a global variable name. When one module refers to a plurality of external data, a method of storing the identifier of the external data group in another table and storing the reference of the table in the column 302 is generally used.

The calling module column 303 is a column for storing an identifier of another module called by the module. In this embodiment, this call relationship indicates a function call. That is, the identifier of the module called by the module is stored in the column 303. However, the definition of the call relationship is not limited to this, and may include a reference relationship. When one module calls a plurality of modules, a method is generally used in which the identifier of the callee module group is stored in another table and the reference of the table is stored in the column 303.

FIG. 4 is an example of a database table representing module-specific importance data 211. The importance by module is a numerical value representing the value and importance of the module from a certain point of view. Although this calculation method varies depending on the viewpoint, a technique for visualizing a module based on software metrics (hereinafter referred to as metrics) such as module complexity, aggregation degree, and number of code lines has been proposed.

Using these commonly known metrics, for example, from the viewpoint of understanding the structure of the source code, the following method of calculating the importance in consideration of the test execution results can be considered.
First, based on the metrics shown in Table 1, the importance M of the module is calculated by the mathematical formula shown in Equation 1. The importance level M is calculated using general metrics of the source code.

Next, the importance T of the module is calculated according to Equation 2. The importance T is an importance calculated using the value of the importance M and the unit test code metrics.

Also, from the viewpoint of source code complexity, the value of cyclic complexity, which is a general software metric, can be used as importance. It is also possible to arbitrarily determine the importance of a module according to the subjectivity of the developer. In the present invention, a module to be abstracted is determined using the importance value calculated in this way. This is an easy-to-understand expression process for determining a module to be abstracted, and is limited to this method. It is not a thing. For example, it may be possible to abstract a module extracted at random without using an index of importance.

The evaluation viewpoint column 401 of the module importance level data table 211 in FIG. 4 is a column for storing the importance level calculation viewpoint of the module. For example, when it is desired to abstract a module that is important for understanding the structure of the source code, a method of determining a module having a high importance whose column 401 value is “structure understanding” as an abstraction target can be considered. By calculating and storing the importance for each type of viewpoint in this way, it is possible to determine the module to be abstracted from various viewpoints.
The module column 402 is a column for storing a module identifier. The module identifier is as described in the description of the column 301.
The importance column 403 is a column for storing the importance of the module described above. Although it is assumed that modules with high or low importance are determined as abstraction targets, the present invention is not limited to this method.

FIG. 5 shows a flowchart of the evaluation target program abstract diagram creation processing when the user creates an abstract diagram of the evaluation target program and performs analysis in the program abstract diagram creation device of this embodiment.
In step S501, the abstract diagram creation processing unit 201 receives a general program call operation such as a user GUI operation or an API call from another module, and starts processing. Enter the source code of the specified program to be evaluated and, if necessary, the test code.

In step S502, the abstract diagram creation processing unit 201 analyzes the source code of the evaluation target program using a known source code analysis tool or the like, creates a source code analysis data table 210, creates a database, and main memory Store in device 104. If the source code analysis data table 210 is already registered in the database, it is read out to the main storage device 104.

In step S503, the abstract diagram creation processing unit 201 calculates the module-specific importance data 211 for each evaluation viewpoint and stores it in the database. The viewpoint specified by the user is used as the evaluation viewpoint, and the importance is calculated for all modules stored in the source code analysis data table 210 and stored in the database and the main storage device 104. If the module-specific importance data 211 is already registered in the database, it is read out to the main storage device 104.

The abstract diagram creation processing unit 201 creates the source code analysis data 210 and the module-specific importance data 211 or obtains it from the database program 209 and stores it in the main storage device 104 in steps S502 and S503. This is not necessary when data is already stored in the main storage device 104. In addition, there is a method of storing these data in the main storage device 104 at the time of starting the processing, and a method of reading from the database program 209 as necessary. Hereinafter, when the source code analysis data 210 or the module-specific importance data 211 is simply described, it indicates data stored in the main storage device 104.

In step S504, the abstraction level determination unit 202 receives an instruction to specify the abstraction level or end the program abstract drawing creation process by a user GUI operation or the like. The degree of abstraction is the degree of abstraction of the program abstract diagram expressed as a numerical value. The higher the degree of abstraction, the higher the degree of abstraction of the module that is visualized. Therefore, the higher the degree of abstraction, the more visible the module. The threshold of importance and the threshold of LCOM described later are set high.

The value of the abstraction level is determined by, for example, a user GUI operation using a slide bar described in FIG. 10, but the determination method is not limited. The developer can freely determine the correspondence between the abstraction level and the module importance level threshold or LCOM threshold. In the present embodiment, it is assumed that these correspondences are hard-coded in advance in the program logic of the abstraction level determination unit 202. However, for example, it is assumed that the correspondences can be changed later using a setting file or the like. it can.

In step S505, the abstract diagram creation processing unit 201 proceeds to step S506 when the user designates a new level of abstraction, and terminates the process when the user designates the end of the program abstract diagram creation processing.

In step S506, abstract module registration processing for abstracting the module of the evaluation target program according to the abstract level is executed. FIG. 6 shows a flowchart of abstraction module registration processing.
In step S601, the abstracted flags corresponding to all the modules registered in the source code analysis data 210 of the evaluation target program are initialized.

In step S602, the abstraction target module determination unit 203 determines whether there is a module that has not been abstracted yet. When the process proceeds from step S601, all modules are not abstracted. When the process proceeds from step S608 described later, it is determined whether there is a module that has not been abstracted yet. Whether or not a module has already been abstracted is determined by a truth value set in the abstracted flag for each module. This true / false value is stored in the abstracted flag on the main storage device 104 by the abstracted data processing unit 207 in step S610 described later.
The abstraction target module determination unit 203 determines the presence of a non-abstracted module by reading the true / false value of the abstracted flag stored in the main storage device 104. If there is a module that has not been abstracted yet, the process proceeds to step S603, and if not, the process proceeds to END.

In step S603, the abstraction target module determination unit 203 selects a module to be abstracted from the module group determined not to be abstracted yet in step S602. There are various selection methods, but in this embodiment, the determination is made using the importance of the module. Based on the importance value stored in the column 403 of the module importance data table 211 and the importance threshold determined in step S504, only modules whose importance in the evaluation viewpoint designated by the user is equal to or higher than the threshold are selected. Select as a module to be abstracted.
If there is no abstraction target module, that is, if the importance of all the non-abstraction modules is less than the threshold, it is determined that there are no remaining modules to be abstracted, and the process proceeds to END. However, this processing is only an example, and for example, it may be possible to select the module having the highest importance as the abstraction target module from the remaining non-abstraction modules. When the abstraction target module exists, the process proceeds to step S604.

In step S604, the external data access determination unit 204 determines whether the module selected as the abstraction target in step S603 or the module group abstracted in steps S605 and S606 described later refers to external data. judge. Whether the module refers to external data can be determined by reading the value of the external data identifier stored in the column 302 of the source code analysis data table 210. If the module refers to external data, the process proceeds to step S605. If not, the process proceeds to step S606.

In step S605, the data access abstraction processing unit 205 performs abstraction from the viewpoint of data access.
The abstraction from the viewpoint of data access is the abstraction by combining the abstraction target module determined to refer to the external data in step S604 and the other module group referring to the same external data. Represents the processing to be performed. In this process, the value of the external data identifier stored in the column 302 of the source code analysis data 210 is read, and another module storing the same identifier as that identifier in the column 302 is determined by the value of the module identifier in the column 301. Can be executed. A specific example of this abstraction processing will be described with reference to FIG.
When there are multiple other modules that refer to the same external data as the abstraction target module, it is assumed that all of them are abstracted together. For example, only the module with the highest importance value is abstracted. It is possible to make it. In this method, the module can be abstracted with a finer granularity, but the processing speed decreases.

In step S606, the control flow abstraction processing unit 206 performs abstraction from the viewpoint of control flow.
The abstraction from the viewpoint of the control flow represents a process of abstracting another module group called from among the abstraction target modules into the abstraction target module. The calling relationship between modules can be determined by reading the value of the calling module identifier stored in the column 303 of the source code analysis data table 210. A specific example of this abstraction processing will be described with reference to FIG.
When there are multiple other modules called from the abstraction target modules, it is assumed that all of them are abstracted together. For example, it is also possible to abstract only the module with the highest importance value. It is done. In this method, the module can be abstracted with a finer granularity, but the processing speed decreases.

In step S607, the LCOM threshold value determination unit 208 calculates the LCOM value of the new abstract module that is abstracted and collected in step S605 or step S606.
LCOM is an abbreviation for “Lack of Cohesion in Methods” and is a numerical value indicating the degree of lack of cohesion. The degree of cohesion is an index representing the strength of the relationship between the functional elements and information elements in the module, and LCOM is one of the software metrics that has been conventionally known. Details of LCOM will be described with reference to FIG.

In step S608, the LCOM threshold value determination unit 208 determines that the abstraction is not appropriate when the LCOM value of the new abstract module exceeds the threshold value, and returns to step S602 without registering the abstract module. The other non-abstraction module is determined and the next abstraction target module is selected. If not, it is determined that the abstraction is appropriate, and the process proceeds to step S609.

In step S609, the abstract diagram creation processing unit 201 registers the new abstract module summarized and summarized in the abstract module registration data table 212 shown in FIG. In the abstract module column 701, “module 801” with a new name is registered by the system, and in the included module (module included in the abstract module) column 702, the abstracted module is imported. The identifier “Module A, Module B” is stored, and the identifier “Data A” of the data captured by abstraction is stored in the column 703 of the included data (data included in the abstraction module), and the column of the reference data 704 stores data referenced by Module A and Module B outside the module 801, and the column 705 of the calling module stores Module A and Module B calling a module outside the module 801. For example, the module identifier is stored.

In step S610, the abstracted data processing unit 207, for example, marks the abstracted flag “Module A, Module B” as abstracted (a true / false value indicating that it has already been abstracted), and newly An abstracted flag of “module 801” is additionally installed, and its value (true / false value) is set to an initial value (unfinished). Although the abstracted flag can be stored in a database or a file, it is assumed that the abstracted flag is stored in the main storage device 104 in this embodiment.
In step S611, the new abstract module summarized and summarized is set as the next abstraction target module, and the process proceeds to step S604.

In step S507 of FIG. 5, the abstract diagram creation processing unit 201 displays the abstract diagram of the evaluation target program on the display device 105, for example, in a call graph format as shown in FIG.
The call graph is a directed graph representing a calling relationship between program modules (subroutines). In the present embodiment, a call graph node is selected by selecting only a module whose abstracted flag value (true / false value) is an initial value (uncompleted) from the source code analysis data 210 and the abstract module registration data 212. Is displayed, the edge of the call graph is displayed from the data in the column of the calling module, and an abstract diagram of the evaluation target program is displayed.
After the abstract diagram is displayed, the process proceeds to step S504, and the abstraction level determination unit 202 waits for an instruction to specify the abstraction level or to terminate the program abstraction diagram creation process by a user GUI operation or the like.

FIG. 8 is a diagram for explaining the calculation formula of LCOM and the characteristics indicated by the value of LCOM.
Equation 3 in FIG. 8 is an LCOM calculation formula. The calculation formula of LCOM is widely known, and there are some variations. In this embodiment, the calculation formula of Formula 3 is illustrated, but the present invention is not limited to this. Since LCOM is a software metric for object-oriented languages, FIG. 8 illustrates a Java language program. The value of LCOM ranges from 0 to 1. The closer the value is to 0, the better the design, and the closer the value is to 1, the worse the design.

FIG. 8 (a) shows a Java class that is well designed. In the class 811, one variable fieldA is defined, and two methods respectively access fieldA. For this reason, the class 811 cannot be divided into a plurality of parts and is designed well.
FIG. 8B shows a Java class that is considered badly designed. In class 812, two variables fieldA and fieldB are defined. Only method methodA is accessed for fieldA, and only method methodB is accessed for fieldB. Since this class 812 can be divided into two, it is considered a bad design.

As described above, LCOM is a metric that can be used to determine whether the design is good or bad, depending on the relationship between variables and methods. As described in FIG. 6, the abstraction from the viewpoint of data access and the abstraction from the viewpoint of control flow are performed, and the abstraction is advanced step by step while judging the value of LCOM. It is possible to proceed with abstraction while maintaining as high a state as possible. By assuming a group of modules that are abstracted and grouped together as one object (abstract module), the value of LCOM, which is a metric for object-oriented languages, is calculated.

FIG. 9 is a schematic diagram illustrating the abstraction process from step S604 to step S611 in FIG. 6 in an easy-to-understand manner. Data A 901 and Data B 906 in the figure represent general external data such as program global variables, files, and databases. These correspond to the external data indicated by the identifier stored in the column 302 of the source code analysis data 210. Module A 902, Module B 903, Module C 904, and Module D 905 represent modules. These correspond to the modules indicated by the identifiers stored in the column 301 and the column 303 of the source code analysis data 210 and the column 402 of the module-specific importance data 211. A double line 907 represents a reference relationship from the module to the external data. An arrow 908 represents a calling relationship from module to module.

Reference numerals

801, 802, and 803 denote new modules (abstraction modules) obtained by abstracting together the module group included in each dotted line.

Here, the abstraction process from step S604 to step S611 will be briefly described with reference to FIG. First, it is assumed that the threshold of LCOM is determined to be 0.4 in step S504, and the module to be abstracted is determined to be ModuleA 902 in step S603. In step S604, it is determined whether Module A 902 is accessing external data. Since Module A 902 refers to Data A 901, the process proceeds to step S605.
In step S605, abstraction by data access is performed. Here, ModuleA 902 and Module B 903 referencing DataA 901 are abstracted as one module 801.
In step S607, the LCOM value of the new abstracted module 801 is calculated. Here, since Module A 902 and Module B 903 constituting module 801 refer to the same external data DataA 901, the value of LCOM is 0.

Next, in step S608, since the LCOM value of the module 801 is smaller than the threshold value, the process proceeds to step S609, and the data of the module 801 is registered in the abstract module registration data table 212 shown in FIG.
Next, in step S610, the Moodle A 902 and the Module B 903 are set as abstracted. In addition, an abstracted flag of the module 801 is additionally installed with an initial value.
Next, in step S611, the module 801 is set as the next abstraction target module, and the process returns to step S604.

Next, in step S604, it is determined whether the module 801 is accessing external data. Since the module 801 does not access external data, the process proceeds to step S606.
Next, abstraction by the control flow is performed in step S606. Here, since the module 801 is calling ModuleC904, the module 801 and ModuleC904 are abstracted as one module 802.
Next, in step S607, the LCOM value of the new abstracted module 802 is calculated. Here, ModuleA 902 and Module B 903 constituting module 802 refer to the same external data DataA 901, but since Module C 904 does not refer to DataA 901, the LCOM value of module 802 increases to 0.3 (this value is accurately calculated). It is an example to make the explanation easy to understand).

Next, in step S608, since the LCOM value of the module 802 is smaller than the threshold value, the process proceeds to step S609, and the data of the module 802 is registered in the abstract module registration data table 212 shown in FIG.
Next, in step S610, Module C904 is newly set as abstracted. In addition, an abstracted flag of the module 802 is additionally installed with an initial value.
Next, in step S611, the module 802 is set as the next abstraction target module, and the process returns to step S604.

Similarly, by repeating step S604 to step S608, a new abstract module 803 is abstracted by combining the module 802, DataB 906, and Module D 905 into one. Here, the LCOM value of the module 803 is 0.5, which exceeds the threshold value. Therefore, in step S608, the module 803 is not registered and the process proceeds to step S602.
Therefore, in this embodiment, by abstracting the module ModuleA 902 up to the abstract module 802 is generated. It is possible to automate the creation of an abstract diagram by repeating the above processing until there are no abstraction target modules.

FIG. 10 is a screen example of a program abstract diagram creation apparatus to which the present invention is applied. As shown in the figure, the user can determine the module abstraction level by moving the slider for setting the module abstraction level to the left or right by dragging the mouse (step S504). Accordingly, the threshold of importance of the module to be abstracted and the threshold of LCOM are determined, and an abstract diagram of the program as shown in FIG. 10 can be generated by performing processing according to the method of the present invention.
The abstract diagram of the program to be evaluated is generated by the abstract diagram creation processing unit 201 from the source code analysis data 210 and the abstract module registration data 212. The abstract flag value (true / false value) is the initial value (unfinished). ) Module is selected to display the call graph node, and the call graph edge is displayed from the call module column data.
According to the present invention, an abstract diagram of a program can be generated without requiring manual settings by a user or a developer.

In addition, this invention is not limited to an above-described Example, Various modifications are included. For example, the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described.
Each of the above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit. Information such as programs, tables, and files that realize each function can be stored in a recording device such as a memory, a hard disk, or an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.
Also, the lines and dotted lines in the figure indicate what is considered necessary for the explanation, and not all lines and dotted lines are necessarily shown.

100 Program abstract diagram creation device (information processing device)
101 Central processing unit 102 Input device 103 Secondary storage device 104 Main storage device 105 Display device 106 Bus 107 Communication device 110 Another information processing device 120 Communication network 200 Program abstract diagram creation program 201 Abstract diagram creation processing unit 202 Abstraction level determination unit 203 Abstraction target module determination unit 204 External data access determination unit 205 Data access abstraction processing unit 206 Control flow abstraction processing unit 207 Abstracted data processing unit 208 LCOM threshold determination unit 209 Database program 210 Source code analysis data 211 By module Importance data 212 Abstract

module registration data

801, 802, 803 A new module (abstract module) that is an abstraction of a group of modules
901 DataA
902 ModuleA
903 ModuleB
904 ModuleC
905 ModuleD
906 DataB
907 Double line indicating reference relationship from module to external data 908 Arrow indicating call relationship from module to module

Claims

A program abstract diagram creation device that displays an abstract diagram of a program to be evaluated in response to a specified input of abstraction level,
Source code analysis data having at least module configuration, reference data, and calling module data, and at least module-specific importance data having importance data for each module for each evaluation viewpoint are created from the source code of the evaluation target program. Or an abstract diagram creation processing unit that reads the already created data,
Accepting the user-specified abstraction level, the threshold level of importance of the module to be visualized corresponding to the abstraction level, and the abstraction level determination unit for setting the LCOM threshold value,
An abstraction target module determination unit that selects, as an abstraction target module, a module whose module importance is equal to or higher than the threshold value from modules that have not yet been abstracted;
An external data access determination unit that determines whether the abstraction target module refers to external data;
When the abstraction target module refers to external data, the abstraction target module and the other non-abstraction modules referring to the external data are combined into one new abstraction module for abstraction. A first abstraction processing unit,
When the abstraction target module does not refer to external data, the abstraction target module and other non-abstraction modules called by the abstraction target module are collectively abstracted as one new abstraction module. Two abstraction processing units,
When the abstract diagram creation processing unit calculates the degree of lack of cohesiveness (LCOM) of the new abstraction module, determines whether the degree of lack of cohesiveness exceeds the threshold, and does not exceed the threshold , Registering the abstraction module, setting a flag as the abstracted module for the non-abstracted modules collected in the registered new abstraction module, and setting the registered new abstraction module as the next abstraction The module is set to be an abstraction target module, and the process proceeds to the external data access determination unit. If the degree of cohesiveness exceeds the threshold value, the abstraction module is not registered and the process proceeds to the abstraction target module determination part And
When the abstraction target module determination unit determines that there is no non-abstraction module to be selected as the abstraction target module, the module abstraction processing is terminated.
A program abstract diagram creation device, wherein the abstract diagram creation processing unit refers to an abstracted flag and outputs a call graph format abstract diagram having only non-abstracted modules as nodes.
The program abstract diagram creation device according to claim 1,
When the abstraction target module determination unit selects an abstraction target module from the non-abstraction modules, the importance level of the non-abstraction module is determined, and the non-abstraction module having the highest importance level is determined. Is selected as the abstraction target module.
The program abstract diagram creation device according to claim 1,
When the abstract diagram creation processing unit registers the abstract module, it has at least data items of an abstract module identifier, an included module identifier, an included data identifier, a reference data identifier, and a calling module identifier. An apparatus for creating a program abstract diagram, characterized in that an abstracted flag of a newly registered abstract module registered in a data table is additionally installed with a non-abstracted initial value.
In the program abstract drawing creation apparatus according to any one of claims 1 to 3,
2. The program abstract diagram creation apparatus according to claim 1, wherein the external data is global variables, file data, data stored in a database, input data from a communication socket, and a return value from a function.
In the program abstract drawing creation apparatus according to any one of claims 1 to 3,
The first abstraction processing unit sets the abstraction target module and a plurality of other non-abstraction modules referring to the external data referred to by the abstraction target module as one module. In the case of abstraction, the importance of the other plurality of non-abstraction modules is determined, and the abstraction target module and the non-abstraction module having the highest importance are abstracted as one module. A program abstract diagram creation device characterized by the above.
In the program abstract drawing creation apparatus according to any one of claims 1 to 3,
When the second abstraction processing unit abstracts the abstraction target module and the plurality of other non-abstraction modules called by the abstraction target module as one module, the other plural An apparatus for creating a program abstract diagram, characterized by determining the importance of a non-abstraction module and abstracting the abstraction target module and the non-abstraction module having the highest importance as one module.
A program abstract diagram creation program for displaying an abstract diagram of a program to be evaluated according to a specified input of an abstraction level using a computer,
As a processing step by the computer,
Source code analysis data having at least module configuration, reference data, and calling module data, and at least module-specific importance data having importance data for each module for each evaluation viewpoint are created from the source code of the evaluation target program. Or processing steps to load already created data,
An abstraction level determining step for accepting a user-specified abstraction level and setting a threshold level of importance of a module to be visualized corresponding to the abstraction level and a threshold value of LCOM;
An abstraction target module determination step of selecting, as an abstraction target module, a module whose module importance is equal to or higher than the threshold value from among modules not yet abstracted;
An external data access determination step of determining whether the abstraction target module refers to external data;
When the abstraction target module refers to external data, the abstraction target module and the other non-abstraction modules referring to the external data are combined into one new abstraction module for abstraction. A first abstraction processing step,
When the abstraction target module does not refer to external data, the abstraction target module and other non-abstraction modules called by the abstraction target module are collectively abstracted as one new abstraction module. Two abstraction processing steps;
Calculate the degree of lack of cohesiveness (LCOM) of the new abstraction module, determine whether the degree of lack of cohesiveness exceeds the threshold, and register the abstraction module if the threshold is not exceeded A flag is set as the abstracted module for the non-abstracted modules collected in the registered new abstraction module, and the registered new abstraction module is set as a next abstraction target module, When the process proceeds to the external data access determination unit and the degree of lack of cohesion exceeds the threshold value, the processing step of transferring to the abstraction target module determination unit without registering the abstraction module;
If it is determined in the abstraction target module determination step that there is no non-abstraction module to be selected as the abstraction target module, the module abstraction process is terminated, and the abstracted flag is referred to And a step of outputting an abstract diagram in a call graph format having only the abstraction module as a node.
In the abstraction target module determination step, when an abstraction target module is selected from the non-abstraction modules, the importance of the non-abstraction module is determined, and the non-abstraction module having the highest importance is determined. 8. The program abstract diagram creation program according to claim 7, wherein: is selected as the abstraction target module.
The program abstract diagram creation program according to claim 7,
When registering the abstraction module, register it in a data table having at least data items of an abstraction module identifier, an inclusion module identifier, an inclusion data identifier, a reference data identifier, and a calling module identifier, and newly A program abstract diagram creation program characterized by additionally installing an abstracted flag of the registered abstract module with an initial value of non-abstraction.
In the program abstract diagram creation program according to any one of claims 7 to 9,
A program abstract diagram creation program characterized in that the external data is global variables, file data, data stored in a database, input data from a communication socket, and a return value from a function.
In the program abstract diagram creation program according to any one of claims 7 to 9,
In the first abstraction processing step, the abstraction target module and a plurality of other non-abstraction modules referring to the external data referred to by the abstraction target module as one module In the case of abstraction, the importance of the other plurality of non-abstraction modules is determined, and the abstraction target module and the non-abstraction module having the highest importance are abstracted as one module. A program abstract diagram creation program characterized by
In the program abstract diagram creation program according to any one of claims 7 to 9,
In the second abstraction processing step, when the abstraction target module and the plurality of other non-abstraction modules called by the abstraction target module are abstracted as one module, the other plural A program abstract diagram creation program characterized by determining the importance of a non-abstraction module and abstracting the abstraction target module and the non-abstraction module having the highest importance as one module.