JP5487078B2 - Software asset management method and apparatus - Google Patents

Description

  It relates to componentization of existing software in large-scale systems.

  Large-scale systems such as railway operation management systems, once constructed, are used for a long period of more than 10 years. Such a system needs to be modified and modified in accordance with the situation even after the system is constructed, and the functions must be expanded sequentially.

  For example, railway operation management systems built during the development of computer control have always been forced to respond to new needs such as high-density transportation and electronic passenger guidance. In addition, operation modes that were not previously envisaged, such as direct operation from other areas, were born, and the operation management system has been forced to respond to new operation modes.

  When modifying the source code once it has been modified, the test must be performed again for the extent of the impact of the modification. However, inadvertent modification will increase the range of impact and increase the number of test steps. Such an increase in man-hours is particularly noticeable in large-scale systems. For this reason, a method is generally used in which the existing source code is not touched as much as possible, and the range of influence is limited by adding a new source code in the immediate vicinity or at the end of the repair location.

  For example, in most cases, system modifications are performed only for processing related to specific data, and the structure of the source code is designed with such modifications in mind. That is, even if the process is similar, a separate function and source code are prepared for each data to be processed. With such a design, it is possible to reduce the possibility that unexpected effects will occur due to the impact of the modification on other data. Even if the refurbishment part was originally a place where the change was not expected, and it was regarded as a common process for all the data, copy and paste the relevant source code to the last or last to rewrite other data. Can be minimized.

  However, if such modifications are repeated, the source code scale increases, unnecessary source code accumulates, the source code structure changes, and the like, resulting in a significant decrease in readability. In addition, a large number of source codes that appear to be the same processing at first glance but are partially different from each other are generated, and there is a risk that the user may not be aware of the difference and make an incorrect modification. As a result, the maintainability deteriorated, and it was impossible for anyone other than the workers who had been involved in the repair for a long time. Furthermore, due to the retirement of baby boomers, the number of experts has decreased significantly, and the maintenance man-hours are increasing at an accelerated pace.

  In addition to the actualization of such problems, the number of times new functions are added has decreased in mature systems such as railway operation management systems, and the program structure with higher maintainability is stronger than the program structure suitable for refurbishment. It has been demanded.

  Software product line development has been proposed as an effective technique for producing highly maintainable programs. In software product series development, commonality and dissimilarity between products are defined for a plurality of software product groups, and software is divided into common parts and non-common parts for manufacturing. By making parts according to the commonality between products, it is possible to easily know the scope of impact at the time of repair, and to improve maintainability and reusability.

  Even in a large-scale system such as a railway operation management system, the conventional source code created for each data to be processed can be regarded as a software product group. Therefore, if the source code is classified into common processing that does not depend on the data to be processed and processing that is specific to the data to be processed, and each source code is made into parts, the concept of software product line development is like a railway operation management system. It can be applied to large-scale systems. At this time, a technique for extracting common processing and unique processing from existing source code is required.

  As a technique for analyzing a common process for an existing source code, there is a technique for detecting a matching portion of a source code as a duplicate code. Duplicate codes are discriminated in units such as words and lines by syntax analysis. Furthermore, as a technique for detecting similar but not perfect match, a technique for grouping surrounding duplicate codes based on the position on the source code is disclosed (Patent Document 1).

Japanese Patent No. 3,868,859

  Patent Document 1 relates to an apparatus for detecting a similar partial character string that is a similar portion in a target character string. By detecting a similar partial character string in the source code, common processing included in the existing source code can be extracted. However, since the extracted common process is fragmented and does not necessarily match the process delimiter, it is necessary to search for a process delimiter included in the nearby source code for componentization. However, since a similar part includes a large amount of noise such as a variable declaration part and an accidental coincidence part, a large amount of calculation resources are required to make a determination on all of them. This problem is particularly noticeable in large-scale systems. Also, since the similar partial character string needs to be searched over the entire source code, it is necessary to perform recalculation every time tuning is performed such as changing the detection condition. In addition, a method for filtering out accidental matches must be implemented.

  Therefore, a method and apparatus for organizing software assets that can be executed with fewer computational resources is provided.

  An apparatus for extracting source blocks that can be managed as software components from software source code includes a source code dividing unit, a source block classifying unit, a grouping marker extracting unit, and a source block grouping unit. .

  The source code dividing unit divides the source code into a plurality of source blocks based on a predetermined source code dividing condition, extracts variables used in the source block for each of the plurality of source blocks, and Determine the relationship.

  The source block classification unit determines, for each of the specified one or more variables, one or more source blocks having a predetermined correspondence relationship with the variable.

  The grouping marker extraction unit extracts markers for collecting a plurality of source blocks into one or more groups based on the determination result.

  The source block grouping unit is a source that can organize two or more source blocks of a plurality of source blocks as one software component based on a predetermined grouping condition using the markers extracted by the grouping marker extraction unit. Group as a block group.

  Software assets can be organized with less computational resources, and tuning is easier.

It is an example of an input screen which a software asset rearrangement apparatus provides. It is an example of an output screen which a software asset rearrangement apparatus provides. It is a hardware structural example of a software asset rearrangement apparatus. It is a software structural example of a software asset rearrangement apparatus. It is a figure which shows the concept of an example of the whole process of a software asset rearrangement apparatus. It is a flow which shows an example of the whole process of a software asset rearrangement apparatus. It is a flow which shows an example of the division | segmentation process of a source code. It is a flow which shows an example of the process which matches a variable and a source block. It is a flow which shows an example of the process which calculates | requires the dependence relationship between source blocks. It is a flow which shows an example of a process of a source block classification | category part. It is a flow which shows an example of a process of a source block classification | category part. It is a flow which shows an example of the detailed process of a software asset rearrangement apparatus. It is a flow which shows an example of the detailed process of a software asset rearrangement apparatus. It is a figure which shows an example of a source code division | segmentation condition list | wrist. It is a figure which shows an example of a control syntax information table. It is a figure which shows an example of a source code division | segmentation result table. It is a figure which shows an example of a variable information table. It is a figure which shows an example of a source block dependence function table. It is a figure which shows an example of a process target data candidate table. It is a figure which shows an example of a process target data table. It is a figure which shows an example of a source block classification | category table. It is a figure which shows an example of a common source block list. It is a figure which shows an example of a source block grouping table.

  Hereinafter, an embodiment of the present invention will be described in detail with reference to FIGS.

  FIG. 1 is a configuration example of an input screen provided by the software asset rearranging apparatus 100 used when a developer converts an existing software asset into a part. The input screen of the software asset rearranging apparatus 100 includes a source file selection window 110, a condition setting window 120, a source code preview window 130, a division execution button 140, a processing target variable selection window 150, a component determination condition setting window 160, and a grouping execution button. 170.

  The source file selection window 110 includes a file display window 111, a source file addition button 112, a source file removal button 113, and a source file determination window 114. The file display window 111 displays a directory structure in the file system. In FIG. 1, directories DirectoryA and DirectoryB are displayed under the directory root. Further, under the directory A, the directories A1 and A2 are stored. Under the directory A1, the source file hoge. c, fuga. c is displayed. The developer selects a source file for which software asset rearranging is to be performed in the software asset rearranging apparatus 100 from the file display window 111 and then registers the source file in the source file determination window 114 by pressing a source file addition button 112. be able to. Further, when it is desired to remove a source file registered in the source file determination window 114, the source file can be removed by pressing the source file removal button 113 after selecting the source file to be removed in the source file determination window 114. When a source file is added or removed, the contents of the source code selected by the source code preview window 130 can be confirmed. In the source file determination window 114, a source file to be analyzed by the software asset rearranging apparatus 100 is selected from the registered source files using a check box. In FIG. 1, as a source file to be analyzed for software asset componentization, hoge. c, fuga. c, head. h is selected.

  In the condition setting window 120, a condition used for the analysis of the software asset rearranging apparatus 100 can be selected. The condition used for the analysis is, for example, a programming language used for describing the source code to be analyzed. The conditions used for analysis can be changed by pressing the change button 121.

  When the division execution button 140 is pressed after the input of the source file selection window 110 and the condition setting window 120 is completed, the software asset rearranging apparatus 100 starts the source code division process.

  After the source code division processing is completed, candidates for processing target data (hereinafter also referred to as processing target variables) are displayed in the processing target variable selection window 150 by the software asset rearranging apparatus 100. The processing target variable selection window 150 includes a processing target data candidate display window 151, a processing target data addition button 152, a processing target data removal button 153, and a processing target data determination window 154. In FIG. 1, structures StructA and StructB are displayed under the root. In addition, StructA1 and StructA2 are displayed under StructA, and data dataA and dataB are displayed under StructA1. The developer selects processing target data to be used for classifying source code in the software asset rearranging apparatus 100 from the processing target data candidate display window 151, and then presses a processing target data addition button 152 to select a processing target data determination window. The processing target data can be registered in 154. In addition, when it is desired to remove the processing target data registered in the processing target data determination window 154, after selecting the processing target data to be deleted in the processing target data determination window 154, the processing target data determination window 154 is deleted by pressing the processing target data removal button 153. can do. In the processing target data determination window 154, processing target data to be used for classifying the source code in the software asset rearranging apparatus 100 is selected from the registered processing target data using check boxes. In FIG. 1, dataA and dataB are selected.

  Here, the processing target data means that the generation of the data is the purpose of execution of the target program. In the source code, the return value of the program, variables stored in the table, After rewriting, it can be determined in the form of variables used as input in other programs. Further, it can be determined from the specification as data that is clearly shown as the output of the program. As an example, a case of a program for generating information for passenger guidance from an information table for operation control in a railway operation management system will be described. In the program, the target output is information for passenger guidance, and the processing target data is, for example, a train destination or a stop station.

  After the input of the processing target variable selection window 150 is completed, for example, the lower limit of the source code match rate is input as a condition for determining two components as the same component from the componentization determination condition setting window 160. Thereafter, when the grouping execution button 170 is pressed, the software asset rearranging apparatus 100 starts grouping processing of source code groups that can be converted into parts as software assets.

  FIG. 2 is a configuration example of an output screen provided by the software asset rearranging apparatus 100. The output screen of the software asset rearranging apparatus 100 includes a source block grouping result display window 210, a source block classification result display window 220, a source code comparison result display window 230, a metrics display window 240, and a redisplay button 250.

  The source block grouping result display window 210 includes a group display window 211 and a source block display window 212 in the group. The group display window 211 displays a list of grouped source blocks grouped as one software component. In FIG. 2, Group1, Group2, Group3, and Group4 are displayed as groups. In addition, Group 1 is in a selected state. In the source block display window 212 in the group, source block groups belonging to the group selected in the group display window 211 are displayed. In FIG. 2, Block2, Block5, Block9, and Block15 belonging to Group1 are displayed. In the source block display window 212 in the group, the source block displayed in the source code comparison result display window 230 in the selected group can be selected by a check box. In FIG. 2, Block 2, Block 5, and Block 9 are selected. From the display results of the source block grouping result display window 210 and the source code comparison result display window 230, the developer can know what source code group is capitalized as one software component. Developers can also manually modify the componentization results.

  The source block classification result display window 220 includes a source block name display column 221, a processing target data display column 222, and a source block / processing target data correspondence display column 223. In FIG. 2, a black-colored cell in the correspondence display column 223 between the source block and the processing target data indicates that the source block name displayed to the left of the cell in the source block name display column 221 In the target data display field 222, it is shown that it is associated with the processing target data displayed on the cell. From the result of the source block classification result display window 220, the developer can confirm which processing target data can be affected by the source block handled at the time of componentization of the source code.

  The source code comparison result display window 230 displays the source code matching part and the difference part of the source block selected in the source block display window 212 in the group. In FIG. 2, the black painted portion represents a matching portion, and the non-black painted portion represents a different portion. From the result of the source code comparison result display window 230, the developer inserts each line when removing the duplicate source code or integrating the source code group in the source block in the source code componentization work. The place to do can be determined.

  The metrics display window 240 displays the effect of organizing software assets. The effects of organizing software assets include, for example, the number of source code lines and the source code reduction rate that can be reduced by componentization. Information such as the total number of source blocks, the number of parts after conversion into parts, and the total number of source code lines are also displayed. In FIG. 2, 64% is displayed as the source code reduction rate, which is obtained by dividing the number of source code lines 18 and 552 that can be reduced by componentization by the total number of source code lines 28 and 988. Is. From the result of the metrics display window 240, the developer can quantitatively evaluate the work scale of componentization work and the source code reduction effect associated with componentization.

  The re-display button 250 is pressed when the group or source block selected in the source block grouping result display window 210 is changed, so that a source block classification result display window 220, a source code comparison result display window 230, and a metrics display are displayed. This is a button for updating the window 240.

  FIG. 3 is a hardware configuration example of the software asset rearranging apparatus 100. The hardware of the software asset management device 100 includes a central processing unit 310, a main storage device 320, an internal bus 330, a bus interface 340, an external bus 350, an input / output device 360, an input / output device interface 361, a mass storage device 370, and a large capacity. A capacity storage device interface 371, a communication device 380, and a communication device interface 381 are included.

  The central processing unit 310 is a processor for performing operations such as program execution. The main storage device 320 is a device for temporarily storing data such as programs and calculation results during program execution. The central processing unit 310 and the main storage device 320 are connected by an internal bus 330, and the internal bus 330 is connected to an external bus 350 via a bus interface 340.

  The input / output device interface 361 is connected to the input / output device 360. The input / output device 360 is an interface device with a developer such as a display, a keyboard, and a mouse. The input screen and output screen shown in FIGS. 1 and 2 are provided from the input / output interface 361. The mass storage device interface 371 is connected to the mass storage device 370. The mass storage device 370 is a device for permanently storing basic programs and processing results. The communication device interface 381 is connected to the communication device 380. The communication device 380 is a device for connecting to an external server device or the like, and can provide a source code to be processed and a processing result to the external server device through a network. By using the communication device 380, for example, the function of the software asset rearranging device 100 can be provided as a service to a computer connected earlier through the network.

  FIG. 4 is a software configuration example of the software asset rearranging apparatus 100. The software of the software asset rearranging apparatus 100 includes a source code division unit 411, a source block classification unit 412, a grouping marker extraction unit 413, a source block grouping unit 414, a controller unit 421, a screen management unit 431, an input interface 441, and an output. Interface 451, source code division condition list 461, inline expansion source file 462, control syntax information table 463, source code division result table 464, variable information table 465, source block dependency table 466, processing target data candidate table 467, and processing target A data table 471, a source block classification table 472, a common source block list 481, and a source block grouping table 491 are included.

  A program for realizing the source code dividing unit 411, the source block classifying unit 412, the grouping marker extracting unit 413, the source block grouping unit 414, the controller unit 421, the screen management unit 431, the input interface 441, and the output interface 451 is executed at the time of execution. The data is expanded from the mass storage device 370 to the main storage device 320, and the central processing unit 310 performs an operation. Also, a source code division condition list 461, an inline expansion source file 462, a control syntax information table 463, a source code division result table 464, a variable information table 465, a source block dependency table 466, processing target data generated by executing the program The candidate table 467, the processing target data table 471, the source block classification table 472, the common source block list 481, and the source block grouping table 491 are expanded into the main storage device 320. The developer can control the execution of the program by giving an instruction to the input interface 441 via the input / output device 360 such as a keyboard, a mouse, and a display. In addition, data can be input and output by using a detachable and portable storage medium as the input / output device 360. Input / output can also be performed with other devices via the communication device 380. A program that realizes each functional unit and a source file that can be selected in the source file determination window 114 may be stored in the mass storage device 370 in advance, or may be stored in a mass storage device from another device via an available medium. It may be installed in 370 or the main storage device 320. The medium refers to, for example, a removable storage medium as the input / output device 360, or a communication medium such as a network, a carrier wave propagating through the network, or a digital signal as the communication device 380.

  The source code dividing unit 411 is a part that expands an existing source code inline and divides the source code by a control syntax. At that time, the dependency relationship between the source blocks is derived and the data used in the source code is also extracted. First, the source code division unit 411 reads the analysis conditions input to the condition setting window 120 and stores them in the source code division condition list 461.

  A detailed example of the source code division condition list 461 is shown in FIG. The source code division condition list 461 stores source code language settings and source code division conditions. The source code language setting stores a language describing the source code, such as C language or JAVA (registered trademark). This is used when performing syntax analysis such as searching for conditional branches and determining the execution order. The source code division condition stores a condition used when the input source code is divided into source blocks.

  Next, the source code dividing unit 411 reads the source code from the source file designated by the source file name selected in the source file determination window 114, and stores the source code inline expanded into the inline expanded source file 462. To do. Then, the source code dividing unit 411 performs syntax analysis processing on the inline expansion source file 462 and stores details of the extracted control syntax in the control syntax information table 463. Here, the control syntax is, for example, an if statement representing a conditional branch or a for statement representing an iterative process in C language. The control syntax information table 463 is used for source code division.

  A detailed example of the control syntax information table 463 is shown in FIG. The control syntax information table 463 stores a control syntax ID, a start position, an end position, a control syntax type, an execution condition, and a parent hierarchy control syntax ID for each control syntax that appears in the source file. The control syntax ID stores a key for uniquely identifying the target control syntax. The assignment of the control syntax ID may be arbitrary as long as there is no duplication. In the start position, the line number of the first line in the source code range controlled by the control syntax (hereinafter referred to as control range) is stored. The end position stores the line number of the last line in the control range. The line numbers in the inline expanded source file 462 are used. The control syntax stores the type of control syntax. The execution condition stores a condition to be satisfied when the control syntax is executed. If the control syntax A is included in the control range of another control syntax B, the parent hierarchical control syntax ID defines B as the parent hierarchical control syntax of A, and the parent hierarchical control syntax of the target control syntax Control syntax ID is stored. Here, when the control syntax A is included in a plurality of control syntaxes B and C, that is, when the control syntax B is further included in the control syntax C, the control syntax immediately above A, that is, control. Syntax B is a parent hierarchy control syntax.

  After the creation of the control syntax information table 463 is completed, the source code division unit 411 refers to the source code division condition in the source code division condition list 461 and searches the control syntax information table 463 for a control syntax corresponding to the condition. Divide the source code into multiple source blocks. The creation result is stored in the source code division result table 464. The source code division result table 464 is a main product in the source code division unit 411.

  Details of the source code division result table 464 are shown in FIG. The source code division result table 464 stores a source block ID, a start position, an end position, an execution condition, and a parent hierarchy source block ID. The source block ID stores a key for uniquely identifying the target source block. The assignment of the source block ID may be arbitrary as long as there is no duplication. The starting position stores the line number of the starting line of the source block. At the end position, the line number of the end line of the source block is stored. The line numbers in the inline expanded source file 462 are used. The execution condition stores a condition to be satisfied when the source block is executed. When a value is stored in the parent hierarchy control syntax ID of the control syntax information table 463 for the control syntax corresponding to the source block, the parent hierarchy source block ID corresponds to the control syntax represented by the parent hierarchy control syntax ID. The source block ID of the source block is stored.

  FIG. 5 conceptually shows how the source code division result table 464 is generated from the inline expansion source file 462. In FIG. 5, the source code dividing unit 411 causes the first line of the inline expanded source file 462 to be the source block 1, the second to fifth lines to the source block 2, the sixth to ninth lines to the source block 3, The 13th line is divided into source blocks 4 and the 14th line is divided into source blocks 5.

  After the creation of the source code division result table 464 is completed, the source code division unit 411 derives the processing target data extraction and the relationship between the source blocks. First, the source code dividing unit 411 extracts variables appearing in the inline expansion source file 462 from the inline expansion source file 462 and stores them in the variable information table 465. The variable information table 465 is used to determine the dependency relationship between source blocks.

  A detailed example of the variable information table 465 is shown in FIG. The variable information table 465 stores a variable ID, a variable name, a scope, a variable type, an appearance position, a corresponding divided source code ID (hereinafter, the divided source code is also referred to as a source block), and a usage type flag. The variable ID stores a key for uniquely identifying the target variable. The assignment of the variable ID may be arbitrary as long as there is no duplication. The variable name stores the name of the variable used in the inline expansion source file 462. The scope stores the line numbers of the start line and the end line in the inline expanded source file 462 for the range in which the variable can be read and written on the source code. Here, in the variable information table 465, the same variable name is treated as a separate variable if the scope is different. The variable type stores the type of the target variable. Here, the variable type is, for example, int or float in the C language. In this embodiment, the appearance position, the corresponding source block ID, and the usage type flag are provided separately for each variable in order to avoid complicated description. A line where a variable appears on the inline expanded source file 462 is stored at the appearance position. The corresponding source block ID stores the source block ID of the source block that includes the variable appearance line in the range. The usage type flag stores “write” when a value is written to the variable in the corresponding row, and “read” when the value of the variable is read. Here, when writing is not performed in the row, it is determined that reading is performed.

  After the creation of the variable information table 465 is completed, the source code dividing unit 411 determines the data read / write relationship between the source blocks from the corresponding divided source block ID and the usage type flag in the variable information table 465, and the result depends on the source block. Stored in the relationship table 466. The source block dependency relationship table 466 is used when associating a source block with data to be processed.

  A detailed example of the source block dependency relationship table 466 is shown in FIG. The source block dependency relationship table 466 stores a variable ID, a read divided source code ID, a write divided source code ID, and an execution condition dependent flag. The variable ID is a variable ID used in the variable information table 465, and stores variable IDs of variables that are read or written by the two source blocks. The read source block ID stores the source block ID from which the variable is read. The write source block ID stores the source block ID in which the variable is written. When determining the data read / write relationship between the source blocks, after writing is performed in the source block represented by the write source block ID, and before reading is performed in the source block represented by the read source block ID. In addition, those overwritten in other source blocks are excluded. In the execution condition dependency flag, “TRUE” is stored when the location where the variable is read is the execution condition portion of the source block indicated by the read source block ID, and “FALSE” is stored otherwise. ing. The execution condition dependency flag is used to correctly associate the processing target data with the source block when a value is stored in the parent hierarchy source block ID of the source code division result table 464.

  After the creation of the source block dependency relationship table 466 is completed, the source code dividing unit 411 extracts candidates for processing target data from variables appearing in the source code. The result is stored in the processing target data candidate table 467.

  A detailed example of the processing target data candidate table 467 is shown in FIG. The processing target data candidate table 467 stores a variable ID, the number of bits, and a variable ID immediately below the structure. The variable ID is the same as the variable ID in the variable information table 465, and is used for reference to the variable information table 465. The number of bits stores the data size of the variable expressed in bits. If the variable is a structure, the variable ID immediately below the structure stores the variable ID of the variable that exists immediately below the structure. Here, when the structure A has the structure B as an element, the structure B is included in the structure A, and when there is another structure B in the structure A, Of the variables included in the structure A, variables excluding the variables included in the structure B are defined as variables immediately below the structure. The order of display in the processing target data candidate display window 151 is stored in the priority order. After the creation of the processing target data candidate table 467 is completed, the source code dividing unit 411 outputs the result to the processing target data candidate display window 151 and waits for a user response.

  The source block classification unit 412 is a part that classifies the source blocks according to the processing target data input by the user. First, processing target data designated by the user is read from the processing target data determination window 154 and stored in the processing target data table 471.

  A detailed example of the processing target data table 471 is shown in FIG. The processing target data table 471 stores processing target data IDs and variable IDs. The processing target data ID stores a key for uniquely identifying the target variable. The assignment of the processing target data ID may be arbitrary as long as there is no duplication. The variable ID stores a variable ID assigned to the variable in the variable information table 465.

  After the creation of the processing target data table 471 is completed, the source block classification unit 412 derives the correspondence between the processing target data and the source block. Here, the fact that the processing target data and the source block have a correspondence relationship means that there is a case where the value of the processing target data changes due to the removal of the source block. The source code division result table 464, the source block dependency relationship table 466, and the processing target data table 471 are used for determining the correspondence between the processing target data and the source block. The result is stored in the source block classification table 472. The source block classification table 472 is a main product of the source block classification unit 412.

  A detailed example of the source block classification table 472 is shown in FIG. The source block classification table 472 is prepared for each processing target data, and stores a source block ID, a relation processing flag, and a condition processing flag for each processing target data. The source block ID stores the source block ID of the source block having a correspondence relationship with the processing target data. The relation processing flag indicates “unprocessed” when the relation processing has not yet been performed on the source block, “in process” while the relation processing is being performed, and “after processing” “Processed” is stored. Here, the relationship processing is processing for searching for source blocks having a dependency relationship from the source block dependency relationship table 466 in a chained manner. The condition processing flag indicates “Unprocessed” if the condition processing has not yet been performed on the source block, “Processing” while the condition processing is being performed, and “After processing is completed” “Processed” is stored. Here, the conditional processing is processing for searching for another source block for rewriting a variable when the execution condition of a certain source block includes a variable. In the condition processing, a value is stored in the parent hierarchy source block ID of the row corresponding to the source block in the source code division result table 464, and the parent hierarchy source block ID is included in the read source block ID in the source block dependency relation table 466. This is performed when the source block corresponding to is stored and the execution condition flag of the row is “TRUE”.

  The concept of processing of the source block classification unit 412 will be described with reference to FIG. In FIG. 5, the source block classification unit 412 causes the source blocks 1, 2, and 5 to be processed data dataA, the source blocks 1, 3, and 5 are processed data dataB, and the source blocks 1, 4, and 5 are processed data dataC. Is determined to have a corresponding relationship. After the creation of the source block classification table 472 is completed, the grouping marker extraction unit 413 is executed.

  The grouping marker extraction unit 413 is a part that extracts a marker used when grouping source block groups that can be capitalized as one software component based on the correspondence relationship between processing target data and source blocks. In this embodiment, a source block (hereinafter referred to as a common source block) having a correspondence relationship with all processing target data is used as a marker. The source block classification table 472 is used to determine the common source block, and the result is stored in the common source block list 481. The common source block list 481 is a main product of the grouping marker extraction unit 413.

  A detailed example of the common source block list 481 is shown in FIG. The common source block list 481 stores source block IDs of source blocks determined as common source blocks. The processing concept of the grouping marker extraction unit 413 will be described with reference to FIG. In FIG. 5, source blocks 1 and 5 having a correspondence relationship with all the processing target data (data A, data B, and data C) are determined to be common source blocks. After the creation of the common source block list 481 is completed, the source block grouping unit 414 is executed.

  The source block grouping unit 414 is a part that groups source blocks that can be capitalized as one software component using the markers extracted by the grouping marker extraction unit 413. In addition, the total number of groups and the number of matched lines of source code of the source block group included in the group are calculated, and indicators such as the number of parts and the effect of reducing the amount of source code by componentization are presented to the user. For group discrimination, a combination of two common source blocks stored in the common source block list 481 is used. For a combination of two common source blocks, a program execution path connecting them is discriminated that does not include another common source block, and a group of source blocks existing on the execution path is defined as one group. The result is stored in the source block grouping table 491. The source block grouping table 491 is a main product of the source block grouping unit 414.

  Details of the source block grouping table 491 are shown in FIG. The source block grouping table 491 stores a group ID, a common source block ID (front), a common source block ID (back), and an intra-group source block ID. The group ID stores a key for uniquely identifying the target group. Group ID assignment may be arbitrary as long as there is no duplication. The common source block ID (previous) stores the common source block ID of the two common source blocks that are grouping markers that have the previous execution order on the program. The common source block ID (after) stores the common source block ID of the later execution order on the program among the two common source blocks that are markers for grouping. The intra-group source block ID stores the source block ID of the source block belonging to the target group.

  After the creation of the source block grouping table 491 is completed, the source block grouping unit 414 performs an analysis process on the grouping result and outputs the result to the metrics display window 240. In the analysis process, for example, the total number of source blocks, the number of groups, the total number of source code lines, the number of source code lines that can be reduced by componentization, and the number of source code lines that can be reduced by componentization are divided by the total number of source code lines. Calculate the source code reduction rate etc. After the analysis process is completed, the source block grouping unit 414 passes the result to the screen management unit 431 and waits for a user response. A processing conceptual diagram of the source block grouping unit 414 will be described with reference to FIG. In FIG. 5, the source blocks 2, 3, and 4 that are source blocks on the program execution path connecting the source blocks 1 and 5 that are common source blocks are determined as one group.

  The controller unit 421 is a part that receives user input information from the screen management unit 431 and controls the source code dividing unit 411, the source block classifying unit 412, the grouping marker extracting unit 413, and the source block grouping unit 414. The screen management unit 431 receives user input information from the input interface 441 and passes it to the controller unit 421. In addition, the processing results of the source code dividing unit 411, the source block classifying unit 412, the grouping marker extracting unit 413, and the source block grouping unit 414 are received, and the screen output is transferred to the output interface 451. The input interface 441 receives input from the user and passes it to the screen management unit 431. The output interface 451 outputs the screen output received from the screen management unit to a user interface such as a display.

  FIG. 6 shows a process flow of the software asset rearranging apparatus 100. The process 600 is started by pressing the division execution button 140 as a trigger, and the processes 700, 800, 900, and 1000 are executed.

  The process 700 is a process of dividing the source code by inline expansion of the target source code and then analyzing the control syntax by syntax analysis, and is executed by the source code dividing unit 411. A detailed flow of the process 700 is shown in FIG. The deliverables in 700 are a source code division condition list 461, an inline expansion source file 462, a control syntax information table 463, and a source code division result table 464, and particularly main deliverables are a source code division result table 464. The process 700 includes input processes 711 and 712, syntax analysis processes 721, 722, 723, 724, 725, and 726, and source code division processes 731, 732, 733, and 734.

  In 711, the analysis condition input to the condition setting window 120 is read. Here, the analysis condition is, for example, a description language of a source code to be analyzed or a source code division condition. The source code division condition is given as a control syntax used as a division at the time of division, for example.

  In 712, the analysis conditions read in 711 are stored in the source code division condition list 461.

  In 721, the source file set in the source file determination window 114 by the user is read. The source file to be read is a source file having a check mark in the check box in the source file determination window 114 of FIG.

  In 722, the read source file is expanded inline and stored in the inline expanded source file 462.

  In 723, the control syntax appearing in the inline expanded source file 462 is detected by using the information stored in the description language in the source code division condition list 461 for the inline expanded source file 462. For example, if the description language is C language, an if sentence, a for sentence, a while sentence, a switch sentence, etc. are detected. A control syntax ID is assigned to the detected control syntax. The assignment of the control syntax ID may be arbitrary as long as there is no duplication.

  In 724, the position, control range, and execution condition in the inline expansion source file 462 are determined for each control syntax detected in 723. Here, the position is an appearance line in the inline expansion source file 462 of the control syntax. The control range is, for example, a range surrounded by “{” and “}” after the control syntax in C language. The execution condition is a condition necessary for the source code within the control range to be executed in the program. For example, in the C if statement, the condition is that the value of the expression surrounded by "(" and ")" immediately after is 1.

  At 725, the hierarchical relationship between the control syntaxes is determined. Here, the hierarchical relationship means that when another control syntax B appears inside the control syntax A, that is, when A⊃B, B has A as a parent hierarchy.

  In 726, the results determined in 724 and 725 are stored in the control syntax information table 463.

  In 731, a control syntax that matches the division condition in the source code division condition list 461 is detected from the control syntaxes stored in the control syntax information table 463.

  At 732, the source block is determined from the control syntax detected at 731. The control range of the detected control syntax is set as one source block. When another control syntax B appears inside the control syntax A, that is, A⊃B, B and A minus B, that is, B and A∩¬B are set as source blocks. Source code that does not belong to any source block, for example, source code written directly under the main function, is considered to exist inside a conditional statement that always has an execution condition that is true, and another source block that appears before and after Use a source block as a delimiter.

  At 733, a source block ID is assigned to the source block detected at 732 as an identification ID. The assignment of the source block ID may be arbitrary as long as there is no duplication.

  In step 734, the source block ID, the position, range, and execution condition of the source block are stored in the source code division result table 464.

  Returning to FIG. 6, after the process 700 is completed, the process 800 is executed by the source code dividing unit 411. A process 800 is a process for extracting variables from the inline expansion source file 462 and associating each variable with a source block.

  A detailed flow of the process 800 is shown in FIG. The result of the process 800 is a variable information table 465. The process 800 includes data reading processes 811, 812, and 813, variable extraction processes 821 and 822, and variable and source block association processes 831, 832, 833, 834, and 835. In process 800, a variable appearing in the source code is detected, and it is determined whether reading or writing is performed at each location. Here, the variable includes a structure.

  In 811, information stored in the description language of the source code division condition list 461 is read.

  In 812, the source code expanded inline from the inline expanded source file 462 is read.

  In 813, the information of the source code division result table 464 is read.

  In 821, all variables appearing in the inline expanded source file 462 are detected. At this time, the scope of the variable is simultaneously determined by referring to the variable definition. The scope of a variable is a range where the variable can be read and written on the source code. A variable ID is assigned to the detected variable. The assignment of the variable ID may be arbitrary as long as there is no duplication.

  In 822, the variable ID, variable name, scope, variable type, and appearance position of the variable detected in 821 are stored in the variable information table 465.

  Reference numeral 831 denotes an iterative process, which indicates that 832, 833, 834, 835, and 836 are executed for all occurrence locations of each variable stored in the variable information table 465.

  In 832, it is determined whether data is being written at the target appearance location. If the data has been written, the usage type flag at that location is set to “write” in 833. If writing has not been performed, it is determined that reading has been performed, and the use type flag at the relevant location is set to “read” in 836.

  In 834, by referring to the start and end lines of the source code division result table 464, a source block that includes the appearance location is searched, and a source block ID is obtained. In 835, the appearance location, the corresponding source block ID, and the usage type flag are stored in the variable information table 465.

  Returning to FIG. 6, after the process 800 is completed, the process 900 is executed. A process 900 is executed by the source code dividing unit 411 and is a process for obtaining a dependency relationship between source blocks based on reading and writing of variables in each source block.

  A detailed flow of the process 900 is shown in FIG. A product of the process 900 is a process target data candidate table 467. The process 900 includes 911, 912, 913, 914, 915, 916, and 917.

  Reference numeral 911 denotes an iterative process, which indicates that 912, 913, 914, 915, 916, 917, and 918 are executed for each source block stored in the source code division result table 464. 912 is also an iterative process, and 913, 914, 915, 916, 917, and 918 are executed for variables that appear in the source block and that have an appearance position whose usage type flag is “read”. Is shown.

  In step 913, a part corresponding to the variable currently processed in the iteration process 912 in the variable information table 465 is referred to, and all source blocks whose usage type flag is “write” are detected.

  In 914, among the source blocks detected in 913, those having a dependency relationship with the source block currently being processed in the iterative process 911 are extracted. The dependency is determined by considering the execution path of the program connecting the processing target source block of the iterative process 911 and the source block detected in 913. In other words, one is selected from the source blocks detected in 913, and the other detected in 913 is between the source block currently processed in the iterative process 911 and the selected one source block. When there is an execution path that does not include the source block, there is a dependency between these two source blocks.

  In 915, for the two source blocks determined to have a dependency in 914, the read divided source code ID and the write divided source code ID are stored in the source block dependency relationship table 465, and the variable currently being processed in the iterative process 912 is stored. To do.

  In 916, it is determined whether or not the variable currently processed in the iteration 912 appears within the execution condition of the source block currently processed in the iteration 911. If it appears in the execution condition of the source block, the execution condition dependency flag of the item in the source block dependency relationship table 465 is set to “TRUE” in 917. Otherwise, the execution condition dependency flag is set to “FALSE” in 918. The execution condition dependence flag is used in the subsequent processing in order to correctly associate the processing target data with the source block when a value is stored in the parent hierarchy source block ID of the source code division result table 464.

  Returning to FIG. 6, after the process 900 is completed, the process 1000 is executed. The process 1000 is a process executed by the source code dividing unit 411 to calculate candidate data to be processed to be presented to the user.

  A detailed flow of the process 1000 is shown in FIG. A deliverable of the process 1000 is a process target data candidate table 467. 1000 includes 1011, 1012, 1013, 1014, and 1015.

  In 1011, variable information is read from the variable information table 465.

  In 1012, the variables including the entire program in the scope are extracted from the variables read in 1011. This includes global variables that appear in the source code. Similar to the variable information table 465, the structure is handled as one variable.

  In 1013, the variable extracted in 1012 is analyzed for the hierarchical structure and the relationship of reference / reference between variables. Here, when the variable is a structure, if the structure A has the structure B as an element, the structure B is included in the structure A. In addition, when there is another structure B inside the structure A, the variables included in the structure A excluding the variables included in the structure B are directly below the structure. Variable. When the variables C and D are immediately below the structure A, it is assumed that C and D are in a parallel relationship.

  In 1014, the data size of the variable extracted in 1012 is calculated by the number of bits.

  In 1015, the priority order of the variables extracted in 1012 is calculated. The calculation of the priority order is determined, for example, by counting the number of variables in parallel relation and assigning the priority order in ascending order from the largest number. At this time, if the number of variables in parallel relation is the same, the priority order is also the same. Here, the priority is an index representing the high possibility that the user will be selected as the processing target data among the processing target data candidates. In addition to the method of this embodiment, the appearance of variables in the program The number of times, the size of the structure, and the writing traced from the end of the program may be used for calculation.

  In 1016, the variable ID, the number of bits, the variable ID immediately below the structure, and the priority order are stored in the processing target data candidate table 467 based on the results of 1012, 1013, 1014, and 1015.

  After the end of 1016, the process is paused and the user input is waited for. At this time, the screen management unit 431 displays processing target variable candidates in the processing target variable candidate display window 151 via the output interface 451 based on the contents of the processing target data candidate table 467. At this time, candidates for processing target variables are displayed according to the priority order of the processing target data candidate table 467.

  Returning to FIG. 6, after the user selects the processing target variable, the processing 1100, 1200, 1300 is executed with the pressing of the grouping execution button 170 as a trigger. Processes 1100 and 1200 are executed by the source block classifying unit 412 to determine the relationship between the processing target variable selected by the user and the source block using the source block dependency table 466.

  The detailed flow of processes 1100 and 1200 is shown in FIGS. The deliverables 1100 and 1200 are a source block classification table 472. Processes 1100 and 1200 are processes for directly determining the source block for rewriting the processing target data 1111, 1112, and 1113, and are processes for determining the source block that can affect the rewriting of the processing target data from the dependency relationship between the source blocks. 1131, 1211, 1133, 1134, 1135, 1136, 1121, 1211, 1212, 1213, 1214, 1215 is a process for detecting a source block that affects the execution of the parent layer source block when the parent layer source block exists , 1216, 1217. In 1111, the processing target variable selected by the user in the processing target data determination window 154 is read and stored in the processing target variable table 471.

  In step 1112, the source block dependency relationship table 466 is referenced to search for a source block in which the usage type flag of the processing target variable read in 1111 is “write”.

  In 1113, the processing target variable is added to the processing target data item of the source block classification table 472 for the source block searched in 1112, and the related processing flag is set to “processing”. Here, in the relation processing flag, “unprocessed” is indicated if the relation processing has not yet been performed on the source block, and “processing in progress” is completed while the relation processing is being performed. “Processed” is stored afterwards. The relationship processing is processing for searching for source blocks having dependency relationships from the source block dependency relationship table 466 in a chain manner, and indicates 1311, 1132, 1133, 1134, 1135, 1136.

  1121 is an infinite loop and is repeated until the condition of 1217 is satisfied. 1131 is also an infinite loop, and is repeated until the condition of 1136 is satisfied.

  In 1132, a source block whose relation processing flag is “processing” is searched from the source block classification table 472.

  In 1133, a line having the source block ID retrieved in 1132 in the source block term is retrieved from the source block dependency relationship table 466, and the source block ID in the write source block term of the row is retrieved.

  In 1134, the source block ID extracted in 1133 is added to the source block classification table 472, and the relation processing flag is set to “processing”.

  In 1135, the relation processing flag of the source block searched in 1132 is set to “processed”.

  In 1136, it is determined in 1132 whether one or more source blocks whose relation processing flag is “processing” are detected. If one or more are detected, 1132, 1133, 1134, 1135 are executed again. If none is detected, the process proceeds to process 1200.

  In step 1211, the source block classification table 472 is searched for a source block whose relation processing flag is “processed” and whose condition processing flag is “unprocessed”. Here, in the condition processing flag, the condition processing is “unprocessed” when the condition processing has not yet been performed on the source block, and “processing in progress” is completed while the condition processing is being performed. “Processed” is stored afterwards. In the condition processing, a value is stored in the parent hierarchy source block ID of the row corresponding to the source block of the source code division result table 464, and the parent hierarchy source block is included in the read source block ID of the source block dependency table 466. This process is performed when the source block corresponding to the ID is stored and the execution condition flag of the row is “TRUE”, and indicates 1121, 1211, 1212, 1213, 1214, 1215, 1216, 1217 .

  In 1212, the source block searched in the source code division result table 464 to 1211 is searched.

In 1213, the parent hierarchy source block is determined for the source block searched in 1212. Thereafter, for the determined parent hierarchy source block, the process of determining the parent hierarchy source block is repeated until there is no parent hierarchy source block. Finally, the source block ID of each parent hierarchy source block is extracted.
In 1214, the source block dependency relationship table 466 is referred to, and the row having the source block searched in 1213 as the read source block and the execution condition dependency flag being “TRUE” is searched. That is, the source block that can affect the execution condition of the source block searched in 1213 is searched.

  In 1215, the source block ID stored in the write source block item of the row searched in 1214 is added to the source block classification table 472, and the relation processing flag is set to “processing”.

  In 1216, the condition processing flag of the source block searched in 1211 is set to “processed”.

  In 1217, it is determined whether or not one or more source blocks are detected in 1211. If one or more are detected, the process 1131 is executed again. If none is detected, 1200 is terminated.

  Returning to FIG. 6, after the process 1200 is completed, the process 1300 is executed. The process 1300 is executed by the grouping marker extraction unit 413 and the source block grouping unit 414, extracts a common source block as a grouping marker, and generates a source block group that can be capitalized as a software component from the position of the common source block. This is a grouping process.

  A detailed flow of the process 1300 is shown in FIG. The deliverables of the process 1300 are a common source block list 481 and a source block grouping table 491. The process 1300 is a process for discriminating common source code 1311, 1312, a process for grouping source blocks using a common source block, 1321, 1322, 1323, 1324, 1325; It consists of 1331, 1332, and 1333 to output.

  In step 1311, the source block classification table 472 is searched for a source block having a correspondence relationship with all the processing target variables.

  In 1312, the source block searched in 1311 is added to the common source block list 481.

  In 1321, the common source block list 481 is searched for a combination in which there is an execution path of a program connecting two common source blocks that does not pass through another common source block.

  At 1322, the common source block set searched at 1321 is added to the source block grouping table 491.

  In 1323, all the source blocks existing on the program execution path connecting the two common source blocks searched in 1322 are extracted. These source block groups are candidates for capitalization as one software component.

  In 1324, the source code comparison between the source blocks extracted in 1323 is performed, and if the matching rate exceeds the threshold set from the componentization determination condition setting window 160, it is determined as the same group. The match rate is calculated by dividing the source block into a sequence of tokens (lexeme), finding the number of tokens matched by the two source blocks, and dividing by the smaller of the total number of tokens of the two source blocks. calculate. Here, the number of matched tokens is obtained by three procedures. As a procedure 1, a partial token sequence is created by removing tokens at arbitrary positions from the token sequence generated from each source block. For example, the partial token sequences of the token sequence [a, b, c] are [], [a], [b], [c], [a, b], [a, c], [b, c], [ There are 8 a, b, c]. As a procedure 2, one partial token string is selected from each of the two source blocks, and the number of tokens that match at the same position is counted. As procedure 3, procedure 2 is repeated for a set of all partial token strings, and the maximum value is set as the number of matched tokens.

  In 1325, the source block group determined to be the same group in 1324 is stored in the source block grouping table 491.

  In 1331, the source code comparison between the source blocks belonging to each group is performed from the source block grouping table 491, and the matching part and the difference part of the source code are determined.

  In 1332, for example, an index such as a source code reduction rate is calculated as statistical information. The source code reduction rate can be calculated by determining the duplicate source code from the matching portion of the source code and dividing the total number of lines of the duplicate source code by the total number of lines of the source code.

  In 1333, the source block groups determined to be the same group from the source block grouping table 491 are integrated and output to a file.

  After 1333 is completed, the source block classification table 472, the common source block list 481, and the source block grouping table 491 are transferred to the screen management unit 431, and the process ends.

  According to the embodiment as described above, it is possible to extract a source code group having high similarity from existing software assets and convert it into parts. Further, the user can correct the componentization result based on the information presented to the GUI.

  Furthermore, according to the present embodiment, the source code is divided in advance according to the processing delimiter, and the componentization determination is performed between the source blocks generated by the division, so that noise such as fine matching code fragments does not occur, and the calculation resource Can be saved. In addition, source code splitting and source block association do not need to be re-executed even if the data to be processed or the conditions for componentization determination are changed, so the cost of recalculation by tuning the conditions can be greatly reduced. . Furthermore, since the source code is divided by the control syntax and the componentization determination is performed between the source blocks whose processing execution order is close, the componentization is possible without breaking the semantic unity of the program. In addition, since a process unique to the data to be processed can be detected, it can be used for purposes such as relevance analysis of data and processes and functions, and estimation of an influence range when processing data is added by refurbishing.

  In the railway operation management system, even if you take a passenger information system as a subsystem, there are various data such as train destinations, stop stations, and the number of both. In addition, trains are operated in units of thousands of trains a day in the Tokyo area, and the amount of data is enormous as well as the type of data. In such a system, it takes a lot of labor to convert the source code created for each data to be processed into parts, but according to the present invention, componentization can be realized with almost no disruption to the program execution order, Moreover, since no additional man-hours such as noise determination are generated, the work can be performed very efficiently.

100: Software asset rearranging device 411: Source code dividing unit 412: Source block classifying unit 413: Marker extracting unit for grouping 414: Source block grouping unit 431: Inter-screen intermediary unit

Claims (14)

An apparatus for extracting source blocks that can be managed as software components from software source code,
The source code is divided into a plurality of source blocks based on a predetermined source code dividing condition, a variable used in the source block is extracted for each of the plurality of source blocks, and a relationship between the plurality of source blocks is determined. A source code dividing unit to be determined;
For each of one or more specified variables, a source block classifying unit that determines one or more source blocks having a predetermined correspondence with the variable;
Based on the determination result of the source block classification unit, a marker extracting unit for grouping that extracts markers for collecting the plurality of source blocks into one or more groups;
Based on a predetermined grouping condition using the markers extracted by the grouping marker extraction unit, grouping two or more source blocks of the plurality of source blocks as a group of source blocks that can be organized as one software component software assets organizer that includes a source block grouping part for. A software asset organizer according to claim 1,
The software asset rearranging apparatus, wherein the source code division condition is set according to a language of the source code. The software asset rearranging device according to claim 1,
The source code dividing unit determines whether or not variables are read and written for each of the plurality of source blocks, and determines a relationship between the plurality of source blocks based on a determination result. Software asset management device. The software asset rearranging device according to claim 1,
The source block classification unit determines that the source block and the variable have the predetermined correspondence when the value of the variable can be changed by removing the source block. apparatus. The software asset rearranging device according to claim 1,
The grouping marker extracting unit extracts a source block having the predetermined correspondence with all of the one or more variables as the marker. The software asset rearranging device according to claim 1,
The source block grouping unit further calculates the total number of generated source block groups and the number of matching lines of source code of two or more source blocks included in the source block group, An apparatus for organizing software assets, characterized in that an index indicating the effect of grouping is presented to a user based on the number of matching lines of source code. 6. The software asset rearranging apparatus according to claim 5, wherein the source block grouping unit includes a plurality of source blocks existing on the program execution path not including another marker in a program execution path connecting two markers. A software asset organizing apparatus, characterized by grouping as a source block group. A software asset management method for extracting source blocks that can be managed as software components from software source code,
Dividing the source code into a plurality of source blocks based on a predetermined source code dividing condition;
For each of the plurality of source blocks, extract variables used in the source block,
Determine the relationship between the source blocks,
For each of one or more designated variables, determining one or more source blocks having a predetermined correspondence with the variable, and grouping the plurality of source blocks into one or more groups based on the determination result Extract the marker
Software asset organization, wherein two or more source blocks of the plurality of source blocks are grouped as a group of source blocks that can be organized as one software component based on a predetermined grouping condition using the marker Method. A software asset organizing method of claim 8,
The method of organizing software assets, wherein the source code division condition is set according to a language of the source code. A software asset rearranging method according to claim 8,
When determining the relationship between the source blocks, for each of the plurality of source blocks, it is determined whether or not variables are read and written, and the relationship between the plurality of source blocks is determined based on the determination result. Software asset management method characterized by the above. A software asset rearranging method according to claim 8,
A software asset rearranging method, wherein when the value of the variable can be changed by removing the source block, it is determined that the source block and the variable have the predetermined correspondence. A software asset rearranging method according to claim 8,
A software asset rearranging method, wherein a source block having the predetermined correspondence with all of the one or more variables is extracted as the marker. A software asset rearranging method according to claim 8,
Further, the total number of source block groups created and the number of matching lines of source code of two or more source blocks included in the source block group are calculated, and the total number of source block groups and the number of matching lines of the source code are calculated. A software asset rearranging method characterized in that an index indicating the effect of grouping is presented to a user based on the above. A software asset rearranging method according to claim 12,
A software asset rearranging method, characterized in that, in a program execution path connecting two markers, a plurality of source blocks existing on the program execution path not including another marker are grouped as a group of source blocks.

Images