JP2010061301A - Clone code detection device, clone code detection method, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To prevent the excessive detection of a clone code by matching the longest length of a clone code to be detected. <P>SOLUTION: A detection table creation part 102 registers the section information of each prescribed unit data in a clone detection target file in a first detection table, and registers the section information of each prescribed unit data in a comparison target file with the clone code detection target file in a detection table. When the section information between prescribed unit data in the detection table satisfies prescribed conditions, a clone simple connection part 103 combines the pieces of pertinent section information in the detection table for every file. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a technique applied to a process for detecting a clone code between files.

  In recent years, a large amount of source code has been described by a large number of people in the development of computer systems. In computer system development projects, projects are also evaluated. In such a development situation, the source code created by one member may be copied (clone) by another member and used.

  Depending on the possibility and method of automatically generated code of the framework, there are cases where over-detection may occur, so it is not possible to evaluate whether it is simply a large number of clones, but the clone code is often corrected when there are defects or function changes To increase costs, having a large number of clones is not desirable, and detecting clones is an important indicator in evaluating a project.

  The clone code can be generated as follows. First, there is a case where a clone code is generated when an operator copies and pastes the source code of himself or another person. Secondly, there is a case where similar code is automatically generated by an application framework or the like.

Japanese Patent Laid-Open No. 2003-29978

  However, there is a conventional method for detecting a clone code, but the calculation amount of the detection process is large, and it takes a lot of time to detect the clone code, which is not practical. For example, Patent Document 1 discloses a technique for efficiently detecting a clone code.

  Patent Document 1 discloses an isomorphic pattern detection system that detects isomorphic patterns from text. In the isomorphic pattern detection system disclosed in Patent Document 1, the isomorphism of the target text is detected by lexical analysis, rule transformation, parameter conversion, isomorphism detection, and isomorphism output. However, although the isomorphic pattern detection system disclosed in Patent Document 1 has a high calculation amount of O (N) to O (NlogN), the extracted clone code is not the longest match, so that overdetection increases. There was a problem.

  Therefore, an object of the present invention is to achieve the longest match of the clone codes to be detected and to prevent overdetection of the clone codes.

The clone code detection apparatus of the present invention registers the section information for each predetermined unit of data in the clone code detection target file in the first detection table, and in the file to be compared with the clone code detection target file. First detection table generating means for registering section information for each predetermined unit of data in the first detection table, and section information between the predetermined unit of data in the first detection table is a predetermined condition. When satisfying, the first combining means for combining the corresponding section information in the first detection table for each file, and the clone code that extracts the section information in the first detection table and registers it in the clone code table And a table generation means.
The clone code detection method of the present invention is a clone code detection method by a clone code detection device, and registers the section information for each predetermined unit of data in a clone code detection target file in the detection table, and the clone code detection target A detection table generating step for registering, in the detection table, section information for each data of the predetermined unit in the file to be compared with the file, and section information between the data of the predetermined unit in the detection table is predetermined. If the condition is satisfied, the method includes a combining step of combining corresponding section information in the detection table for each file, and a clone code table generating step of extracting the section information in the detection table and registering the information in the clone code table. Features.
The program of the present invention registers the section information for each predetermined unit of data in the clone code detection target file in the detection table, and the predetermined unit of data in the file to be compared with the clone code detection target file A detection table generating step for registering each section information in the detection table, and when section information between the predetermined unit data in the detection table satisfies a predetermined condition, the corresponding section information in the detection table is stored for each file. And a clone code table generation step of extracting section information in the detection table and registering it in the clone code table.

  In the present invention, section information between a clone code detection target file and a file to be compared with the file is combined for each file, and the combined section information is registered in the clone code table. . Therefore, according to the present invention, it is possible to achieve the longest match between the clone codes to be detected, and it is possible to prevent over-detection of the clone codes.

  DESCRIPTION OF EXEMPLARY EMBODIMENTS Hereinafter, preferred embodiments to which the invention is applied will be described in detail with reference to the accompanying drawings.

  FIG. 1 is a block diagram showing a functional configuration of a clone code detection apparatus according to an embodiment of the present invention. As shown in FIG. 1, the clone code detection apparatus 100 according to the present embodiment includes a base table creation unit 101, a detection table creation unit 102, a simple clone join unit 103, a clone join unit 104, and an included clone deletion unit 105. The

  The base table creation unit 101 converts the source code of the latest file at the time of the last clone code detection into a token string, and converts the token strings converted into n-grams and the interval information of those token strings into the base table. sign up.

  The detection table creation unit 102 converts the source code of the file that is the detection target of the clone code into a token string, and registers the token strings converted into n-grams and the section information of those token strings in the detection table. Then, the detection table creation unit 102 registers the section information registered in the base table in the detection table by a method described later.

  The clone simple combining unit 103 compares the corresponding section information between the records in the detection table, and combines the section information if the compared section information has the same offset between the files.

  The clone combining unit 104 acquires section information for each file from the detection table generated by the clone simple combining unit 103. Then, the clone combining unit 104 overlaps the end of the section information of the preceding token string and the start of the section information of the subsequent token string, or the end information of the section information of the preceding token string and the section information of the subsequent token string Is connected to the new detection table, the section information obtained by combining the section information is registered in the new detection table.

  The inclusion clone deletion unit 105 compares the detection table with the new detection table, and when the section information of the detection table is completely included in the section information of the new detection table, that is, the detection table is overdetected. If there is existing section information, the record in which the over-detected section information is registered in the detection table is deleted.

  FIG. 2 is a diagram illustrating a hardware configuration of the clone code detection apparatus 100 according to the present embodiment.

  The CPU 201 comprehensively controls each device and controller connected to the system bus. The ROM 203 or the HD (hard disk) 207 stores a basic input / output system (BIOS) that is a control program for the CPU 201, an operating system program, and the processes shown in FIGS. Programs are stored.

  In the example of FIG. 2, the HD 207 is configured to be arranged inside the clone code detection device 100. However, as another embodiment, a configuration corresponding to the HD 207 is arranged outside the clone code detection device 100. Also good. In addition, for example, the program for performing the processing illustrated in FIGS. 3-1 to 3-3 according to the present embodiment is recorded on a computer-readable recording medium such as a flexible disk (FD) or a CD-ROM. It is good also as a structure supplied from a recording medium, and good also as a structure supplied via communication media, such as the internet.

  The RAM 202 functions as a main memory, work area, and the like for the CPU 201. The CPU 201 implements various operations by loading a program necessary for execution of processing into the RAM 202 and executing the program.

  The HD 207 and the FD 206 function as an external memory. The CPU 201 implements various operations by loading a program necessary for execution of processing into the RAM 202 and executing the program.

  The disk controller 205 controls access to external memories such as the HD 207 and the FD 206. The communication I / F controller 204 is connected to the Internet or a LAN, and controls communication with the outside by, for example, TCP / IP.

  The display controller 208 controls image display on the display 209.

  The KB controller 210 receives an operation input from the KB (keyboard) 211 and transmits it to the CPU 201. Although not shown, in addition to the KB 211, a pointing device such as a mouse can also be applied to the clone code detection apparatus 100 according to the present embodiment as a user operation means.

  The base table creation unit 101, the detection table creation unit 102, the clone simple combination unit 103, the clone combination unit 104, and the included clone deletion unit 105 shown in FIG. 1 are stored in, for example, the HD 207 and loaded into the RAM 202 as necessary. The configuration is realized by a program and a CPU 201 that executes the program.

FIGS. 3A to 3C are flowcharts illustrating the operation flow of the clone code detection apparatus 100 according to the present embodiment. The operation flow of the clone code detection apparatus 100 will be described below with reference to the flowcharts shown in FIGS. 3-1 to 3-3. Before the description, the storage status of files in the repository will be described with reference to FIG. An example will be described. The repository stores files that are targets for detection of clone codes by the clone code detection apparatus 100. The repository may be configured in a partial recording area of a recording medium such as an HDD in the clone code detection apparatus 100, or may be configured in a DB server connected to the clone code detection apparatus 100 via a communication line. Good. Note that the file storage configuration in the repository illustrated in FIG. 4 is merely an example, and the clone code detection apparatus 100 is not limited to the file illustrated in FIG. Therefore, in the following description, the operation of the clone code detection apparatus 100 will be described using the files other than those shown in FIG.
It shall be.

  FIG. 4 is a diagram showing the update status of each version together with the storage status of each version of each file in the repository. In FIG. 4, the passage of time is shown from the top to the bottom of the drawing. In FIG. 4, file 1 (F1) is registered in the repository with version 1 (V1), and there is no subsequent update. File 2 (F2) is registered in the repository with version 1 (V1), and then updated and registered twice with version 2 (V2) and version 3 (V3). That is, as for the file 2, files of versions 1 to 3 are registered. The file 3 (F3) is registered in the repository with version 1, and then updated and registered with version 2, version 3, and version 4. That is, for the file 3, the files of versions 1 to 4 are registered. A broken line 401 represents the time when the clone code detection process was last performed, and a broken line 402 represents the current time. In other words, FIG. 4 shows that the latest file registered in the repository when clone code is detected last is version 1 for file 1, version 2 for file 2, and version 2 for file 3. Yes. FIG. 4 also shows that file 2 has been updated once from version 2 to version 3 and file 3 has been updated twice from version 2 to version 4 since the last clone code was detected. ing.

  Next, the operation of the clone code detection apparatus 100 will be described. 3A, the base table creation unit 101 reads the latest file from the repository at the time when the clone code was last detected (step S301). That is, the base table creation unit 101 reads version 1 of file 1, version 2 of file 2, and version 2 of file 3.

  Subsequently, the base table creation unit 101 parses the source code described in each file fetched from the repository, and converts the source code into a token string such as V if void (step S302). The conversion rule here uses ad hoc.

  FIG. 5 is a diagram illustrating a conversion example from a source code to a token string and a configuration example of a base table. As shown in 501 and 502 of FIG. 5, void (source code) is V (token), method1 (source code) is $ (token), int (source code) is I (token), arg (source) Code () is converted to% (token), long (source code) is converted to L (token), I (source code) is converted to% (token), and 10L (source code) is converted to & (token).

  Subsequently, the base table creation unit 101 converts the token string into an n-gram (n = 1, 2, 3,..., N = 10 in FIG. 5), and converts the token string into the n-gram and the file And the token sequence section information in step S303. As indicated by reference numeral 503 in FIG. 5, in the base table, the token string v $ (I%) [L% = is changed from the second column (2, 1) of the second row of the file 1 to the fourth column of the third row ( 3, 4) ((2,1)-(3,4)), token sequence v $ (I%) [L% = is the first column of the 10th row of the file 2 to the ninth column of the 10th row. ((10,1)-(10,9)), token sequence v $ (I%) [L% = is from the first column of the first row to the ninth column of the first row ((1 , 1)-(1, 9)) is registered as section information.

  Also, the token string $ (I%) [L% = & is from the second column of the second row to the fifth column of the third row ((2, 2)-(3, 5)), Section information indicates that $ (I%) [L% = & exists from the second column of the first row to the tenth column of the first row ((1,2)-(1,10)). It is registered.

  Further, the token string (I%) [L% = &; exists from the third column of the first row of the file 3 to the eleventh column of the first row ((1,3)-(1,11)). Is registered as section information. Further, the token string = $ (%,%,%); exists from the first column of the 12th row to the 12th column of the 12th row ((12,1)-(12,12)). Is registered as section information.

  FIG. 6 is a diagram for explaining detection table creation processing by the detection table creation unit 102. FIG. 6 shows a configuration example of a detection table created when version 3 of the file 3 is a clone code detection target.

  Subsequently, the detection table creation unit 102 determines whether or not an old version of the file 3 to be detected exists in the base table (step S304). When the old version of the file 3 exists, the detection table creation unit 102 deletes the section information of the old version of the detection target file 3 from the base table as indicated by 601 in FIG. 6 (step S305). If this is a file of the same type with a different version, it is not appropriate to detect the common part as a clone code because the new version file is partially updated from the old version file and there are many common parts. Because. On the other hand, if the old version of the file 3 does not exist, the process proceeds to step S306 without executing step S305.

  Subsequently, the detection table creation unit 102 reads version 3 of the file 3 from the repository (step S306). Then, the detection table creation unit 102 parses the source code described in the version 3 of the file 3 and converts it into a token string (step S307).

  Subsequently, the detection table creation unit 102 converts the token string into an n-gram, and registers the token string converted into an n-gram and section information in the file of the corresponding token string in the detection table (step S308). As indicated by 602 in FIG. 6, the clone column v $ (I%) [L% = is from the fifth column of the second row of the version v3 of the file F3 to the thirteenth row of the second row ((2, 5) -(2,13)), clone string $ (I%) [L% = & is the second line of file F3 version v3 from the 6th line to the 14th line ((2,6)- (2,14)), the clone column (I%) [L% = &; is from the seventh row of the second row to the fifteenth column of the second row of version v3 of the file F3 ((2,7)-( 2, 15)) Existence is registered as section information.

  Subsequently, when the section information is registered in the base table in the same token string as the token string in which the section information is registered in the detection table, the detection table creation unit 102 displays the section information of the corresponding token string in the base table. Register in the detection table (step S309).

  As indicated by reference numeral 603 in FIG. 6, in the detection table, three token sequences v $ (I%) [L% =, $ (I%) [L% = &, (I%) [L% = &; Section information is registered, but in the base table, section information of two token sequences v $ (I%) [L% =, $ (I%) [L% = & is registered. ing. Therefore, the detection table creation unit 102 registers the section information of the two token strings v $ (I%) [L% =, $ (I%) [L% = &] in the base table in the detection table.

  Subsequently, in FIG. 3B, the detection table creation unit 102 determines whether or not there is a token string record in which only one section information is registered between files (step S310). When only one section information is registered between files, the detection table creation unit 102 deletes the corresponding record (step S311). This is because it is clear that a token string in which only one piece of section information is registered between files is not a clone code at that time. In the example of FIG. 6, only the section information of the file 3 is registered in the record of the token string (I%) [L% = &;. Therefore, the record of the token string (I%) [L% = &; is deleted. As described above, the detection table indicated by reference numeral 603 in FIG. 6 is created. On the other hand, if there is no token sequence record in which only one section information is registered between files, the process proceeds to step S312 without executing step S311.

  Subsequently, the clone simple combining unit 103 classifies each record of the detection table according to the number of section information (step S312). In the example of FIG. 7, the classification of the record of token sequence V $ (I%) [L% = and the record of token sequence (I%) [L% = &; The token sequence $ (I%) [L% = & record and the token sequence I%) [L% = &;% record in which three pieces of section information are registered are classified.

  Subsequently, the clone simple combining unit 103 performs a clone simple combining process (step S313). That is, the simple clone combining unit 103 compares corresponding section information between records for each classification, and combines the section information if the compared section information has the same offset between files.

  FIG. 7 is a diagram for explaining the process of simple clone combining by the clone simple combining unit 103. Here, as shown by reference numeral 701 in FIG. 7, an example is shown in which section information is registered for four token strings in the detection table. That is, in the detection table, the section information of the token string V $ (I%) [L% = is registered in the four files 4 to 7, and the token string (I%) [L% = & is stored in the four files 4 to 7. ; Section information is registered. In addition, the section information of token sequence $ (I%) [L% = & is registered in the three files 4 to 6, and the token sequence I%) [L% = &;% section information is stored in the three files 4 to 6. Is registered.

  In the example of FIG. 7, as the section information of the token string V $ (I%) [L% =, (2, 1)-(3, 3), ( 3,2)-(4,4), (4,5)-(5,7), (6,2)-(7,4) are registered, and a token string (I%) [L% = &; (2, 2)-(3,4), (3, 3)-(4, 5), (4, 6)-(5, 8), (6, 3)-(7, 5) is registered. All section information to be compared has the same offset (one coordinate in the horizontal axis direction). Therefore, in this case, the section information is combined. In other words, the detection table creation unit 102 generates section information in which the beginning token end of the preceding token string to the end of the latter token string of the compared token strings are combined. At this time, the clone simple combining unit 103 updates the token string of one record among the records divided for each classification to the combined token string, and converts each section information of the record to the combined section information. Update. Then, the clone simple combination unit 103 deletes all other records belonging to the classification. As described above, after the clone simple combining process, a detection table indicated by 702 in FIG. 7 is generated.

  When the section information is combined for each file, the token string corresponding to the combined section information can be regarded as the same token string across a plurality of files. Therefore, in the above-described clone simple combination process, the same number of section information of a certain token string is registered across a plurality of files between records, and the section information of each token string is recorded between records of the same classification. This is performed when a plurality of files are registered with the same offset.

  Subsequently, the clone combining unit 104 performs a clone combining process (step S314). That is, the clone combining unit 104 acquires section information for each file from the detection table generated by the clone simple combining unit 103. Then, the clone combining unit 104 overlaps the end of the section information of the preceding token string and the start of the section information of the subsequent token string, or the end information of the section information of the preceding token string and the section information of the subsequent token string Is connected to the new detection table, the section information obtained by combining the section information is registered in the new detection table. As a result, a new detection table is created in which section information corresponding to a series of token strings obtained by combining token strings converted into n-grams is created.

  FIG. 8 is a diagram for explaining clone joining processing by the clone joining unit 104. Reference numeral 801 in FIG. 8 is a detection table, and reference numeral 802 in FIG. 8 is a new detection table generated by performing clone combination processing on the detection table. In the detection table, the section information of the file 9 of the token sequence $ (); (L% = N; is (10, 3)-(11, 5), and the token sequence $ (); [L% = $ ( The section information of the file 9 is (9,5)-(10,7) Therefore, the end of the section information ((9,5)-(10,7)) of the preceding token string and the token information of the latter stage Section information ((10,3)-(11,5)) overlaps with the beginning of the section information, and section information (9,5)-(11,5) obtained by combining these section information is calculated.

  Further, since the section information of the file 9 of the token sequence $ (%,%,%,%) is (11, 5)-(12, 7), the file of the token sequence $ (); (L% = N; 9 is connected to the end of the section information ((10, 3)-(11, 5)), so section information (10, 3)-(12, 7) is calculated by combining the section information. The section information is similarly combined for the other files 10 to 12. Since section information is registered only in the token string $ (); [L% = N; Are not combined.

  Subsequently, the clone combining unit 104 determines whether there is section information combined by the clone combining process (step S315). If there is section information combined by the clone combining process, the clone combining unit 104 registers the combined section information in association with the combined token string in the new detection table (step S316). On the other hand, when there is no section information joined by the clone joining process, the process proceeds to step S317 in FIG. 3-3 without executing step S316.

  Subsequently, the clone combining unit 104 determines whether there is a record that has only one piece of section information registered between files in the new detection table (step S317). If there is a record that has only one section information registered between files in the new detection table, the clone combining unit 104 deletes the corresponding record (step S318). This is because a token string in which only one section information is registered between files is not a clone. In the example of FIG. 8, the record of token string $ (); [L% = $ (); [L% = $ (will be deleted. If there is no record that can only be registered, the process proceeds to step S319 without executing step S318, and the process in steps S314 to S318 described above is performed to detect the new table 802 in FIG. A detection table is generated.

  9 and 10 are diagrams for explaining the operation of the inclusion clone deletion unit 105. FIG. The included clone deletion unit 105 separates the files registered in the detection table into groups, and separates the files registered in the new detection table into groups (step S319). In this grouping, files in which section information is registered with the same token string are grouped into the same group. Grouping in this way can reduce the amount of processing by performing overdetection processing for each group having a higher possibility of clones than performing clone overdetection processing described later for each file. Because. 901 in FIG. 9 indicates the status of grouping in the detection table, and 902 in FIG. 9 indicates the status of grouping in the new detection table. Both the detection table and the new detection table are divided into group A of file 9 and file 10 and group B of file 11 and file 12.

  Subsequently, the inclusion clone deletion unit 105 compares the section information for each group between the detection table and the new detection table, and whether or not the section information of the combined table is completely included in the section information of the new combined table. Is determined (step S320). That is, in step S320, it is determined whether or not there is section information that is over-detected in the detection table. For example, when the token string ABABA is registered in the new detection table and the token string BAB is registered in the detection table with section information included in the section information of the token string ABABA, only the longest token string ABABA is stored. The token string BAB included in the token string need not be detected. In such a case, detecting the token string BAB is overdetection, and in step S320, this overdetection is determined.

  If the section information of the combined table is completely included in the section information of the new combined table, the included clone deletion unit 105 deletes the corresponding record from the combined table (step S321). That is, the included clone deletion unit 105 deletes a record in which overdetected section information is registered in the combined table.

  As indicated by 1001 in FIG. 10, the section information of the file 9 of the token sequence $ (%,%,%,%) of the join table is (11,5)-(12,7), and the token sequence $ of the join table is also the same. The section information of the file 10 of (%,%,%,%) is (12, 5)-(13, 7). Further, as indicated by 1002 in FIG. 10, the section information of the file 9 in the token string $ (); [L% = N; $ (%,%,%,%) of the new join table is (10, 3) − (12, 7), similarly, the section information of the file 10 in the token sequence $ (); [L% = N; $ (%,%,%,%) of the new join table is (11, 3)-(13, 7 ). In this way, the interval information of token $ (%,%,%,%) in the join table is the interval of token $ (); [L% = N; $ (%,%,%,%) in the new join table Since it is completely included in the information, the record of token $ (%,%,%,%) in the join table is deleted. On the other hand, when the section information of the join table is not completely included in the section information of the new join table, the process proceeds to step S322 without executing step S321.

  Subsequently, the included clone deletion unit 105 extracts all the records in the detection table and generates a clone table (step S322). Therefore, as indicated by 1001 in FIG. 10, the clone table is composed of records of token sequence $ (); [L% = N; and records of token sequence $ (); [L% = $ ( It will be.

  Subsequently, the included clone deletion unit 105 determines whether or not a new detection table has been generated (step S323). In the example of FIG. 10, since a new detection table is generated, the process proceeds to step S324 in FIG. The clone simple combining unit 103 replaces the new detection table with the detection table (step S324). On the other hand, if a new detection table has not been generated, the process ends.

  The inclusion clone deletion unit 105 executes the clone simple combination process of step S313 on the detection table replaced from the new detection table by the inclusion clone deletion unit 105. That is, the detection table replaced from the new detection table 1101 in FIG. 11 is the section information of token strings $ (); [L% = $ (); [L% = N; (9,5)-(11,5), (10,5)-(12,5) are registered as token strings $ (); [L% = N; $ (%,%,%,%) (10,3)-(12,7), (11,3)-(13,7) are registered as the section information. Therefore, all the section information to be compared has the same offset (one coordinate in the vertical axis direction and two coordinates in the horizontal axis direction), and the section information is combined. As shown in 1102 of FIG. 11, the detection table after the combination of the section information is the token string $ (); [L% = $ (); [L% = N; $ (%,%,% ,%) Records the section information (9, 5)-(12, 7) for the file 9 and the section information (10, 5)-(13, 7) for the file 10. .

  Subsequently, the clone combining unit 104 executes the clone combining process in step S314 on the detection table illustrated in FIG. 11 in 1102. In the detection table illustrated in FIG. The beginning of the section information of the token sequence of the previous token string does not overlap, and the end of the section information of the preceding token string is not connected to the beginning of the section information of the subsequent token string. Therefore, in this clone combining process, the section information is not combined and the record is not registered in the new detection table. When the new detection table is not generated in this way, the process skips steps S316, S318, and S321, and proceeds to step S322.

  In step S322, the included clone deletion unit 105 extracts all the records in the detection table and adds them to the clone table. That is, all the records in the detection table indicated by 1102 in FIG. 11 are extracted and added to the clone table indicated by 1001 in FIG. As a result, the clone table shown in FIG. 12 is generated. In the clone table shown in FIG. 12, the final clone code detection result is registered. That is, token sequence $ (); [L% = N ;, $ (); [L% = $ (, $ (); [L% = $ (); [L% = N; $ (%,%, %,%) Clone code exists between files 9 and 10, and token string $ (); [L% = N; $ (); [L% = $ (clone code between files 11 and 12 The section information registered in the clone table is the longest matching section information by the section information combining process by the clone simple combining unit 103 and the clone combining unit 104.

  Subsequently, the included clone deletion unit 105 determines whether or not a new detection table has been generated (step S323). Since the new detection table has not been generated this time, the process ends.

  In the embodiment described above, the section information between the clone code detection target file and the file to be compared with the file (in this embodiment, the file at the time of the last clone code detection) is stored for each file. And the combined section information is registered in the clone table. Therefore, it is possible to achieve the longest match between the clone codes to be detected, and it is possible to prevent over-detection of the clone codes.

  In the example shown in FIG. 5, n-gram conversion is performed at n = 10. However, in actual processing, it is preferable to perform n-gram conversion at around n = 56 from the viewpoint of calculation efficiency. .

It is a block diagram which shows the functional structure of the clone code detection apparatus which concerns on embodiment of this invention. It is a figure which shows the hardware constitutions of the clone code detection apparatus which concerns on embodiment of this invention. It is a flowchart which shows the flow of operation | movement of the clone code detection apparatus which concerns on embodiment of this invention. It is a flowchart which shows the flow of operation | movement of the clone code detection apparatus which concerns on embodiment of this invention. It is a flowchart which shows the flow of operation | movement of the clone code detection apparatus which concerns on embodiment of this invention. It is a figure which shows the update condition of a version with the storage condition of each version of each file in a repository. It is a figure which shows the example of a conversion from a source code to a token sequence, and the structural example of a base table. It is a figure for demonstrating the creation process of the detection table by a detection table preparation part. It is a figure for demonstrating a clone simple joining process. It is a figure for demonstrating a clone joint process. It is a figure for demonstrating operation | movement of an inclusion clone deletion part. It is a figure for demonstrating operation | movement of an inclusion clone deletion part. It is a figure for demonstrating a clone simple joining process. It is a figure which shows the structural example of a clone table.

Explanation of symbols

DESCRIPTION OF SYMBOLS 100 Clone detection apparatus 101 Detection table preparation part 102 Clone simple coupling | bond part 103 Clone coupling | bond part 104 Inclusion clone deletion part

Claims (6)

Section information for each predetermined unit of data in the clone code detection target file is registered in the first detection table, and the section for each predetermined unit of data in the file to be compared with the clone code detection target file First detection table generating means for registering information in the first detection table;
A first combining unit that combines corresponding section information in the first detection table for each file when section information between the predetermined units of data in the first detection table satisfies a predetermined condition;
A clone code detection device, comprising: clone code table generation means for extracting section information in the first detection table and registering it in the clone code table.   When the section information between the data of the predetermined unit has the same offset across files registered in the first detection table, the first combining unit is configured to perform the predetermined in the first detection table. The clone code detection apparatus according to claim 1, wherein section information between data of the unit is combined. When the section information between the data of the predetermined unit in the first detection table after the combining process by the first combining means overlaps or is connected, the section information obtained by combining the corresponding section information is A second combined table generating means for registering in the two detection tables;
The first combining means replaces the second detection table with the first detection table and replaces the second detection table with the predetermined unit in the first detection table generated by replacing the second detection table with the first detection table. 3. The clone code detection apparatus according to claim 2, wherein, when section information between data satisfies the predetermined condition, corresponding section information in the first detection table is combined. When the section information of the first combined table is included in the section information of the second combined table, further includes a deleting unit that deletes the corresponding section information in the first combined table,
The said clone code table production | generation means extracts the section information in the said 1st table after the section information was deleted by the said deletion means, and registers it in the said clone code table, The said code | cord | chord code | symbol table is characterized by the above-mentioned. Clone code detector. A clone code detection method using a clone code detection apparatus,
The section information for each data of a predetermined unit in the clone code detection target file is registered in the detection table, and the section information for each predetermined unit of data in the file to be compared with the clone code detection target file is A detection table generation step to be registered in the detection table;
When section information between the predetermined units of data in the detection table satisfies a predetermined condition, a combining step of combining corresponding section information in the detection table for each file;
A clone code table generating step of extracting section information in the detection table and registering it in the clone code table. The section information for each data of a predetermined unit in the clone code detection target file is registered in the detection table, and the section information for each predetermined unit of data in the file to be compared with the clone code detection target file is A detection table generation step to be registered in the detection table;
When section information between the predetermined units of data in the detection table satisfies a predetermined condition, a combining step of combining corresponding section information in the detection table for each file;
A program for causing a computer to execute a clone code table generation step of extracting section information in the detection table and registering it in the clone code table.

Images