Automatic software traceable generation method for code change submission record to transaction report based on multi-dimensional feature analysis

Abstract

The invention discloses an automatic software traceable generation method for a code change submission record to a transaction report based on multi-dimensional feature analysis. The method comprises the steps that 1, the code change submission record and transaction report data are extracted; 2, using the extracted transaction report and code change submission record data to construct sample data; step 3, cleaning the data and performing multi-dimensional feature extraction and analysis; and step 4, dividing the sample data set into a training set and a test set to train the classification model and evaluate the performance of the model. The traceable clue classification model is trained by analyzing and utilizing the multi-dimensional features between the code change submission record and the transaction report, so that the accuracy and recall rate of the candidate tracking list are improved.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and more specifically to an automated method for generating traceable software by recording code change commits to transaction reports based on multi-dimensional feature analysis. Background Technology

[0002] During the software lifecycle, various types of software artifacts are generated, such as requirements documents, UML models, code, and test cases. These artifacts often have underlying relationships, which can be traced back to specific artifacts. For example, a requirement might be implemented by one or more code files, which in turn might be tested by one or more test cases. Creating explicit relationships between these artifacts helps users quickly and accurately understand the software. Furthermore, existing research has shown that maintaining accurate and complete traceable threads can effectively improve the efficiency and accuracy of software maintenance activities.

[0003] Currently, code version control tools (such as Git) and transaction management tools (such as JIRA) are widely used in software production activities to assist in software development, maintenance, and project management. Specifically, users can submit different types of transaction reports, or issues, on JIRA, such as tasks, requirements, defects, and improvements. Furthermore, each transaction corresponds to a unique and fixed number. Submitted transactions are assigned to designated developers for development or maintenance by administrators. Code changes resulting from these activities are then submitted to Git by the developers. When submitting, users must fill in information summarizing the purpose of the submission and the corresponding transaction number. After submission, a commit record is generated. Finally, the submitted changed code is merged into the main project for version control after code review. However, in daily practice, developers are often not very proactive in filling in change information when submitting code change records, and omitting the corresponding transaction number in the commit information is very common. Existing research indicates that in multiple software projects surveyed in this work, only 60% of code change commit records explicitly included the corresponding transaction number. The lack of a traceable link between code change commit records and transactions not only hinders developers from understanding the purpose of code changes, but also makes it difficult to check or understand whether the corresponding transactions have been completed completely and correctly.

[0004] To address the aforementioned problems, this invention proposes an automated method for generating traceable software from code change commit records to transaction reports based on multi-dimensional feature analysis. This method performs multi-dimensional feature analysis on code change commit records and transaction report artifacts, constructs feature vectors based on these vectors, and trains a classifier for traceable clues using a classification model. Compared to open-source traceable clue generation methods, the traceable clue list generated by this invention shows significant improvements in both accuracy and recall. Summary of the Invention

[0005] The purpose of this invention is to provide an automated software traceability generation method based on multi-dimensional feature analysis of code change commit records to transaction reports, so as to improve the accuracy of automatically generating traceable clues between commit records and transaction reports.

[0006] To achieve the above objectives, this invention discloses an automated method for generating software traceable records of code change commits to transaction reports based on multi-dimensional feature analysis. The specific steps are as follows:

[0007] S100: Extract code change commit data and transaction report data from the code version control tool and transaction report management tool, respectively.

[0008] S200: Construct sample data using extracted transaction reports and code change commit records;

[0009] S300: Perform multi-dimensional feature analysis on the sample data and construct feature vectors;

[0010] S400: Train a traceable cue classifier using a classification model and evaluate its performance;

[0011] S100 includes the following steps:

[0012] S101: Extract code change commit record data corresponding to the project from the code version control tool;

[0013] S102: Extract the corresponding transaction report data from the transaction report management tool.

[0014] S200 includes the following steps:

[0015] S201: Retain report data for completed and resolved transactions;

[0016] S202: Use regular expressions to identify whether each commit record contains a transaction report number. If it does, create a tracing clue for that commit record and transaction report, and save it as the correct sample data that has been marked.

[0017] S203: Construct error sample data based on the creation and resolution times of transaction reports and the commit times of code change commit records. First, calculate the median time interval (med) between the committed_date of code changes and the resolved_date of the tracked transaction reports, based on all marked correct sample data. Then, sample data marked as errors must simultaneously meet the following two conditions:

[0018]

[0019] isFalseTrace is used to determine whether a given issue report (issuei) and code change commit record (commitj) are error samples; created_date indicates the time the issue report was created.

[0020] S300 includes the following steps:

[0021] S301: Analyze the version information characteristics corresponding to code change commit records and transaction reports. The version information in a commit record is the version of the changed code released for that commit, while the version information in a transaction report is the version corresponding to the completion of that transaction. Version numbers typically include four parts: major version number (main), minor version number (minor), patch version number (patch), and a suffix. Compare each of the four parts of the version information in both records one by one; if they match, mark them as "1"; otherwise, mark them as "0".

[0022] S302: Analyze the stakeholder characteristics involved in code change commit records and transaction reports. Stakeholders for commit records include the author and committer, while stakeholders for transaction reports include the reporter and assignee. Compare the usernames of the author and committer with those of the reporter and assignee one by one. If they match, mark "1"; otherwise, calculate the similarity between the two usernames using the Levenshtein Distance formula, with a value ranging from 0 to 1.

[0023] S303: Analyze the text similarity features between code change commit messages and transaction reports. The transaction report text consists of a summary and a description, while the commit message consists of the target message and the changed code text. First, calculate the text similarity between the overall transaction report text (i.e., the summary and description) and the target message and changed code, respectively. Then, calculate the text similarity between the summary and description sections and the target message and changed code, respectively. The text similarity value ranges from 0 to 1.

[0024] S304: Analyze the correlation characteristics between different transaction reports. If the current transaction report is related to one or more other transaction reports, calculate the overlap rate of the code files involved in the code change commit records corresponding to this transaction report and other transaction reports, and take the mean, minimum and maximum values.

[0025] S305: Analyze the defect-fixing tendency characteristics in code change commit messages. Based on the purpose of the code change commit, they are divided into defect-fixing and non-defect-fixing code changes. Defect-fixing code change commit messages typically contain words such as "fix," "failure," "bug," and "error," while non-defect-fixing code change commit messages typically contain words such as "add," "improve," "update," "support," and "implement." Each of these words is matched one by one; when a word matches in the commit message, it is marked as "1," otherwise marked as "0."

[0026] S306: Based on the above feature analysis results, construct a feature vector for each transaction report and code change commit record with a tracking relationship.

[0027] S400 includes the following steps:

[0028] S401: Using all the feature vectors created in step S300, a classification model is used to train a candidate traceable cue classifier;

[0029] S402: Evaluate the performance of candidate traceable clue classifiers.

[0030] Compared to existing technologies, the advantages of this invention are as follows: It fully analyzes and utilizes the multi-dimensional features between transaction reports and code change commit records, specifically including five dimensions: version information features, stakeholder features, text similarity features, correlation features between transaction reports, and defect repair tendency features. Compared to existing methods, this invention considers more comprehensive feature information and performs more complete feature analysis. The traceable clue classifier obtained by constructing feature vectors based on the above features can significantly improve accuracy and recall. Attached Figure Description

[0031] Figure 1 This is a flowchart of an automated software traceability generation method for recording code change commits to transaction reports based on multi-dimensional feature analysis. Detailed Implementation

[0032] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0033] This embodiment applies the technical solution provided by the present invention—an automated software traceability generation method based on multi-dimensional feature analysis for code change commit records to transaction reports—to a specific case to explain how the method is executed. Taking the Maven system shown in Table 1 as an example, this system is an open-source project management tool written in Java, used for building and dependency management of Java projects. The Maven system uses the JIRA platform for transaction report management and GitHub for code version control. When building this system, please refer to... Figure 1 This invention provides a technical solution: an automated software traceable generation method for code change commit records to transaction reports based on multi-dimensional feature analysis, specifically including the following steps:

[0034] Table 1 Maven System Dataset

[0035]

[0036] S100: Extract code change commit record data and transaction report data from the code version control tool and transaction report management tool, respectively;

[0037] Furthermore, S100 includes the following steps:

[0038] S101: Extract code change commit records for the Maven project from the code version control tool GitHub. The specific field information is shown in Table 2.

[0039] Table 2 shows the field information included in the transaction report data extracted from the transaction report management tool.

[0040]

[0041] S102: Extract transaction report data for Maven projects from the transaction report management tool JIRA. The specific field information is shown in Table 3.

[0042] Table 3 contains the field information of the code change commit records extracted from the code version control tool.

[0043] Field Name describe issue_id Transaction report number, unique value summary Summary Information description Description information status Current status resolution Solution create_date Creation Date resolved_date Resolution Date update_date Update date reporter Reporter assignee person in charge fix_versions There may be multiple version numbers during the repair process.

[0044] S200: Construct sample data using extracted transaction reports and code change commit records.

[0045] Furthermore, S200 includes the following steps:

[0046] S201: Examine the status and resolution fields of each transaction report and retain only the transaction report data with the status field valued as "Resolved" or "Closed" and the resolution field valued as "Fixed" or "Done".

[0047] S202: Use regular expressions to identify whether the commit_message field of each code commit record contains a transaction report number. If it does, save a trace data for that commit record and transaction report. Table 4 shows a code change commit record in the Maven system. Using the regular expression "(\[)?[AZ]{2,}\-[0-9]{1,}(\])?", the transaction report number "MNG-6754" can be extracted from the commit_message field. The relevant information for transaction report MNG-6754 is shown in Table 5. Create a trace from transaction report MNG-6754 to commit record 72688805c4 and save it to the database as a marked correct sample data.

[0048] Table 4 Code Change Submission Record 72688805c4

[0049]

[0050]

[0051] S203: Construct error sample data based on the creation and resolution times of transaction reports and the commit times of code change commit records. First, calculate the median time interval (med) between the committed_date of code changes and the resolved_date of the tracked transaction reports, based on all marked correct sample data. Then, sample data marked as errors must simultaneously meet the following two conditions:

[0052]

[0053] isFalseTrace is used to determine whether a given issue report (issuei) and code change commit record (commitj) are error samples; created_date indicates the time the issue report was created.

[0054] S300: Perform multi-dimensional feature analysis on the sample data and construct feature vectors;

[0055] Furthermore, the S300 includes the following steps:

[0056] S301: Analyze the version information characteristics corresponding to the code change commit records and transaction reports. The version information for commit record 72688805c4 is 4.0.0-alpha-2, while the version information for transaction report MNG-6754 exists in multiple forms: 3.8.2, 4.0.0-alpha-2, and 4.0.0. The major version number of version 4.0.0-alpha-2 is "4", the minor version number is "0", the revision number is "0", and the suffix is ​​"alpha-2". Since both the commit record and the transaction report contain version 4.0.0-alpha-2, the comparison result of the four parts of their version information is "1,1,1,1".

[0057] Table 5 Transaction Report MNG-6754

[0058]

[0059] S302: Analyze the stakeholder characteristics involved in code change commit records and transaction reports. The code writer and committer of commit record 72688805c4 are both "Michael Osipov," while the reporter and person in charge of transaction report MNG-6754 are both "Michael Angstadt." The usernames of the code writer and committer are compared one by one with the usernames of the reporter and person in charge; similarities are marked as "1." The similarity between "Michael Angstadt" and "Michael Osipov" is calculated using the Levenshtein distance formula, which yields a similarity of 0.5625. The final comparison result is "0.5625,1,0.5625,1".

[0060] S303: Analyze the text similarity features between code change commit records and transaction reports. The transaction report text includes a summary and a description, while the commit record includes the commit message and the changed code text. First, calculate the text similarity between the overall transaction report text (i.e., the summary and description) and the commit message and changed code, respectively. Then, calculate the text similarity between the summary and description sections and the commit message and changed code, respectively. The text similarity feature analysis results are "0.0675, 0, 0.0156, 0.0425, 0.0235, 0.0032".

[0061] S304: Analyze the correlation characteristics between different transaction reports. If a transaction report is related to one or more other transaction reports, calculate the overlap rate of the code files involved in the code change commit records corresponding to that transaction report and the other transaction reports, and take the mean, minimum, and maximum values. MNG-6754 and MRESOLVER-144 are related, but the latter has no corresponding code change commit record. Therefore, the result of the correlation characteristic analysis between the two is "0,0,0".

[0062] S305: Analyze the defect fix tendency characteristics in the code change commit information. The purpose information of commit 72688805c4 only contains "update", therefore the value for "update" is "1". The remaining defect fix tendency terms "fix", "failure", "bug", and "error" and the non-defect fix tendency terms "add", "improve", "support", and "implement" all have values ​​of "0". The final defect fix tendency characteristic analysis result is "0,0,0,0,0,0,0,1,0,0".

[0063] S306: Construct a feature vector based on the feature analysis results of steps S301, S302, S303, S304 and S305. The description of each field in the feature vector is shown in Table 6.

[0064] Table 6 lists each feature involved in the multidimensional features and its description.

[0065]

[0066] The feature vectors for tracking the transaction report MNG-6754 and commit record 72688805c4 are constructed as follows: t1:0.0675,t2:0,t3:0.0156,t4:0.0425,t5:0.0235,t6:0.0032,s1:0.5625,s2:1,s3:0.5625,s4:1,v1:1,v2:1,v3:1,v4:1,b1:0,b2:0,b3:0,b4:0,nb1:0,nb2:0,nb3:1,nb4:0,nb5:0,l1:0,l2:0,l3:0.

[0067] S400: Train a traceable cue classifier using a classification model and evaluate its performance;

[0068] Furthermore, the S400 includes the following steps:

[0069] S401: Using all the feature vectors created in step S300, perform five-fold cross-training using decision tree and random forest classification models to obtain candidate traceable cue classifiers;

[0070] S402: When evaluating the performance of the candidate traceable clue classifiers, accuracy (P), recall (R), F1 score, and F2 score are used. To ensure the reliability of the evaluation results, step S401 is repeated ten times, and the average performance of the ten classifiers is taken. Table 7 shows the comparison results of the proposed method REUNION and the baseline method SPLINT on the Maven dataset. The comparison results show that the present invention can be combined with existing traceable clue methods and significantly improve their performance.

[0071] Table 7 Comparison of results from this method and other traceable generation methods on the Maven system.

[0072]

[0073] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to separate one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "order," "inclusion," or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0074] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An automated software traceability generation method for generating code change commit records to transaction reports based on multi-dimensional feature analysis, characterized in that, The method includes the following steps: S100: Extract code change commit record data and transaction report data from the code version control tool and transaction report management tool, respectively; S200: Construct sample data using extracted transaction reports and code change commit records; S300: Perform multi-dimensional feature analysis on the sample data and construct feature vectors; S400: Train a traceable cue classifier using a classification model and evaluate its performance.

2. The automated software traceable generation method for code change commit records based on multi-dimensional feature analysis as described in claim 1, characterized in that, Step S100 includes the following steps: S101: Extract code change commit history data corresponding to the project from the code version control tool. S102: Extract the corresponding transaction report data from the transaction report management tool.

3. The automated software traceable generation method for code change commit records based on multi-dimensional feature analysis as described in claim 1, characterized in that, S200 includes the following steps: S201: Retain report data for completed and resolved transactions. S202: Use regular expressions to identify whether each commit record contains a transaction report number. If it does, create a tracing clue between the commit record and the transaction report, and save it as a marked correct sample data. S203: Construct error sample data based on the creation and resolution times of transaction reports and the commit times of code change commit records. First, calculate the median time interval med between the committed_date of code changes and the resolved_date of the tracked transaction reports based on all marked correct sample data. Then, sample data marked as errors must simultaneously meet the following two conditions: Among them, isFalseTrace is used to determine whether a given issue report (issuei) and code change commit record (commitj) are error samples; created_date represents the time when the issue report was created.

4. The automated software traceable generation method for code change commit records based on multi-dimensional feature analysis as described in claim 1, characterized in that, S300 includes the following steps: S301: Analyze the version information characteristics corresponding to code change commit records and transaction reports. The version information of the commit record is the version of the changed code released for that commit record, and the version information of the transaction report is the version corresponding to the completion of the transaction. The version number usually includes four parts: major version number (main), minor version number (minor), patch version number (patch), and suffix. Compare the four parts of the version information of the two one by one. If they are the same, mark them as "1"; otherwise, mark them as "0". S302: Analyze the stakeholder characteristics involved in code change commit records and transaction reports. Stakeholders for commit records include the author and committer, while stakeholders for transaction reports include the reporter and assignee. Compare the usernames of the author and committer with those of the reporter and assignee one by one. If they match, mark "1". If they differ, calculate the similarity between the two usernames using the Levenshtein Distance formula, with a value ranging from 0 to 1. S303: Analyze the text similarity features between code change commit records and transaction reports. The transaction report text consists of a summary and a description, while the commit record consists of a commit message and the changed code text. First, calculate the text similarity between the overall transaction report text (i.e., the summary and description) and the commit message and changed code, respectively. Then, calculate the text similarity between the summary and description sections and the commit message and changed code, respectively. The text similarity value ranges from 0 to 1. S304: Analyze the correlation characteristics between different transaction reports. If the current transaction report is related to one or more other transaction reports, calculate the overlap rate of the code files involved in the code change commit records corresponding to this transaction report and other transaction reports, and take the mean, minimum, and maximum values. S305: Analyze the defect-fixing tendency characteristics in code change commit information. Based on the purpose of the code change commit, categorize them into defect-fixing and non-defect-fixing code changes. Defect-fixing code change commit information typically contains the words "fix," "failure," "bug," and "error." Non-defect-fixing code change commit information typically contains the words "add," "improve," "update," "support," and "implement." Match each of these words one by one. When a word matches in the commit information, it is marked as "1"; otherwise, it is marked as "0." S306: Based on the above feature analysis results, construct a feature vector for each transaction report and code change commit record with a tracking relationship.

5. The automated software traceable generation method for generating code change commit records to transaction reports based on multi-dimensional feature analysis as described in claim 1, characterized in that, The S400 includes the following steps: S401: Using all the feature vectors created in step S300, a classification model is used to train a candidate traceable cue classifier; S402: Evaluate the performance of candidate traceable clue classifiers.

Images