Continuous and automated evolution of architecture-to-implementation traceability links

Information retrieval (IR) approaches have proven useful in recovering traceability links between free-text documentation and source code. IR-based traceability recovery approaches produce ranked lists of traceability links between pieces of documentation and source code. These traceability links are then pruned using various strategies and, finally, validated by human experts. In this paper we propose two contributions to improve the precision and recall of traceability links and, thus, reduces the required human experts' manual validation effort. First, we propose a novel approach, Trust race, inspired by Web trust models to improve the precision and recall of traceability links: Trust race uses intractability recovery approach to obtain a set of traceability links, which rankings are then re-evaluated using a set of other traceability recovery approaches. Second, we propose a novel traceability recovery approach, His trace, to identify traceability links between requirements and source code through CVS/SVN change logs using a Vector Space Model (VSM). We combine a traditional recovery traceability approach with His trace to build Trust race in which we use Histraceas one expert adding knowledge to the traceability links extracttedfrom CVS/SVN change logs. We apply Trustrace on two case studies to compare its traceability links with those recovered using only the VSM-based approach, in terms of precision and recall. We show that Trustrace improves with statistical significance the precision of the traceability links while also improving recall but without statistical significance.

Trace links between requirements and code are beneficial for many software engineering tasks such as maintenance, program comprehension, and re-engineering. If trace links are created and used continuously during a project, they need to have high precision and recall to be useful. However, manual trace link creation is cumbersome and existing automatic trace link creation methods are typically only applied retrospectively and to structured requirements. Therefore, they focus on recall and accept manual effort to cope with low precision. Such manual effort is not acceptable continuously. Furthermore, the maintenance of existing links along with changing artefacts in a project is neglected in most automatic trace link creation approaches. Therefore, we developed and evaluated an interaction log-based trace link creation approach IL to continuously provide correct trace links during a project. IL links unstructured requirements specified in an issue tracker and source code managed in a version control system. In the latest version, ILCom, our approach uses the interactions of developers with files in an integrated development environment and issue identifiers provided in commit messages to create trace links continuously after each commit. In this paper, we present ILCom, its most recent evaluation study, and a systematic literature review (SLR) about trace link maintenance (TM). We also present a TM process for ILCom based on two approaches from our SLR. In the evaluation study, we show that precision of ILCom created links is above 90% and recall almost at 80%. In the SLR, we discuss 16 approaches. Our approach is the first trace link creation approach with very good precision and recall and integrated trace maintenance.

Recovering traceability links between source code and software document can be very helpful for Software Maintenance and Software Reuse. Existing work has already achieved good results in extracting code elements (classes, methods, etc.) from software documents. However, it will lead to a lot of noise links if we link a document to all the code elements existing in it. In this paper, we propose an approach to identify the contextual code elements and the salient code elements in a software document, then we can weight the traceability links between source code and software document so that those noise traceability links can be filtered effectively. We measure the saliency of each code element in a document with four kinds of document-related features and three kinds of code-related features, and we adopt TransR-based code embedding technology to evaluate the distance between code elements. In the experiments, we get a precision of 70.7% in recognizing salient code elements of StackOverflow answer documents, which is more than 12% improvement compared with Rigby's work. At the same time, we can filter about 56.5%~69.3% noise traceability links compared with the RecoDoc approach. It will improve the quality of traceability links between source code and related software documents.

Traceability is defined by Center of Excellence for Software Traceability as the ability to interrelate any uniquely identifiable software engineering artifact to any other, maintain required links over time, and use resulting network to answer questions of both software product and its development process. It is an essential element in software development process, especially for Safety-Critical systems where trace links are used to demonstrate that all hazards and faults are mitigated in delivered system. Maintaining trace links as a software system evolves over time is difficult, error-prone and costly. As a result, trace links tend to become outdated and safety-cases, which rely on trace links and associated data to compose arguments and evidence for system safety are invalidated. In practice, software developers must therefore painstakingly update trace links in order to re-validate safety-cases whenever they seek re-certification of their product. While a significant body of work exists in area of trace link creation, very limited research has focused on problem of link evolution. The goal of this dissertation is therefore to deliver an accurate, scalable, and practical approach for supporting trace link evolution across a diverse set of software artifacts including requirements, source code and safety cases.

To quickly locate the source code that maps to a specific change described in change history, establishing traceability links between release notes and source code is a necessary task. Current works on the traceability link recovery can be used to find out source code changes which are of higher textual similarities with the release note. However, these approaches rely on consistency of the text used in artifacts at various abstraction levels, and the completeness of text descriptions. In this paper, we propose to leverage source code change information for improving the accuracy of release note to source code traceability recovery tasks. In order to reduce the complexity of link recovery, our approach first performs change impact analysis to cluster the source code changes for the same purpose as a virtual class. After that, our approach employs a natural language generation algorithm to generate readable summary sentence for each virtual class. The traceability links are built between release notes and clusters of program entities by computing the linguistic similarity of sentences. We conduct case studies on 26 releases of 3 popular softwares to evaluate the approach, and the results indicate that our proposed method can improve the accuracy of traceability link recovery compared to other IR-based techniques.

The traceability links among software artifacts plays a very important role for the maintenance of consistency in the evolution of software product lines. This paper introduces an improved approach to the recovery of traceability information between requirement documents and source codes based on Latent Semantic Indexing (LSI) and the special features of object-oriented source codes. In order to obtain accurate traceability links, it employs the hierarchical information caused by the inheritance relationship among classes and recovers the traceability links using class clusters. Moreover, it assigns different weights for the terms in source codes according to their degrees of correlation to the documents. The case demonstrates the improved approach, and the experimental results show that it can increase the extraction precision by 3%~6%, compared with that based on the traditional LSI.

Maintaining traceability links of software systems is a crucial task for software management and development. Unfortunately, dealing with traceability links are typically taken as afterthought due to time pressure. Some studies attempt to use information retrieval-based methods to automate this task, but they only concentrate on calculating the textual similarity between various software artifacts and do not take into account the properties of such artifacts. In this paper, we propose a novel traceability link recovery approach, which comprehensively measures the similarity between use cases and source code by exploring their particular properties. To this end, we leverage and combine machine learning and logical reasoning techniques. On the one hand, our method extracts features by considering the semantics of the use cases and source code, and uses a classification algorithm to train the classifier. On the other hand, we utilize the relationships between artifacts and define a series of rules to recover traceability links. In particular, we not only leverage source code’s structural information, but also take into account the interrelationships between use cases. We have conducted a series of experiments on multiple datasets to evaluate our approach against existing approaches, the results of which show that our approach is substantially better than other methods.

Context: A large number of source code metrics are reported in the literature. It is necessary to systematically collect, describe and classify source code metrics to support research and practice. Objective: We aim to utilize existing secondary studies to develop a catalog of source code metrics together with their descriptions. The catalog will also provide information about which units of code (e.g., operators, operands, lines of code, variables, parameters, code blocks, or functions) are used to measure the internal quality attributes and the scope on which they are collected. Method: We conducted a tertiary study to identify secondary studies reporting source code metrics. We have classified the source code metrics according to the measured internal quality attributes, the units of code used in the measures, and the scope at which the source code metrics are collected. Results: From 711 secondary studies, we identified 52 relevant secondary studies. We reported 423 source code metrics together with their descriptions and the internal quality attributes they measure. Source code metrics predominantly incorporate function as a unit of code to measure internal quality attributes. In contrast, several source code metrics use more than one unit of code when measuring internal quality attributes. Nearly 51% of the source code metrics are collected at the class scope, while almost 12% and 15% of source code metrics are collected at module and application levels, respectively. Conclusions: Researchers and practitioners can use the extensive catalog to assess which source code metrics meet their individual needs based on the description and classification scheme presented.

A feature of the interpretive BASIC languages supplied on most microcomputers is that codes from several "BASICS" may be combined in the same program. When the executed code is correct and the code foreign to the interpreter being used is bypassed, problems do not occur. Thus, BASIC programs can be prepared which run on several different .machines. A front-end menu query is utilized to identify the brand of microcomputer on which the program is running. The source code (see Appendix) displays a hybrid BASIC program that has been used to transfer both text and BASIC programs among ffiM-PC, Radio Shack TRS80 Model ill, and Apple lIe microcomputers. Lines 240360 are consistent with the syntax rules for all three computers and present the menu through which the computer brand is identified. The user answers a query about whether to send or receive a file, and names the file to be accessed for transmission or the file to be received and stored. Lines 70-200 handle communications to and from the TRS-80 microcomputer, lines 370-610 control communications to and from the ffiM-PC, and lines 620-820 govern communications to and from the Apple lIe. If a machine other than one of the three listed is used, it may trap certain types of errors; that is, lines of code which will not run under the machine's interpreter may not be enterable from the keyboard. Should this situation arise, the user simply bypasses that line and continues to enter the remaining lines of program code. This is not a problem when the program executes because the unenterable lines would not have been executed on the machine. Communications from the sending to the receiving microcomputers are handled using standard asynchronous (RS-232)procedures. Our approach is to fit the microcomputers' serial communications ports with the appropriate vendor's RS-232 cables and then connect these cables using a modem eliminator. If the necessary cables are not readily available from the computer manufacturers, then substitutes as well as a modem eliminator may be purchased from a retail computer store or outlet. The demonstration program shown in the Appendix utilizes timing delays, set within the program, to mediate

In Engineering and Scientific computing, a significant number of software systems that are being commonly used by the Engineering community are developed and deployed as Open Source Systems (OSS). This collaborative development model has been widely accepted in both academia and industry. As these systems are typically developed by developers who are experts in their fields (e.g., Engineering), some of those programmers may be lacking an essential skillset today's software quality and engineering concepts (e.g., source code maintainability and analyzability, source code vulnerability, parallelization, etc.). An empirical study is presented that examines some of the source code quality aspects and programming practices (e.g., jumps statements, usage of recursion) from software engineering perspective in ten open source Engineering software systems. The studied systems are written in the C/C++ programming languages and comprised of over ten million lines of code, and present numerous tasks of the engineering community, including computer-aided design, computational fluid dynamics, and finite element analysis. Static analysis methods are applied to each system to determine the number of jump statements (Goto and Break statements) and functions that are recursively invoked. Functions that contain direct or indirect recursive calls are determined and counted. The results show that number of the used jump statements and functions that have recursive calls are significant and thus pose more of a roadblock to effectively and automatically maintain, comprehend, analyze, and re-engineer systems. Lastly, this leads to inefficiencies in a software engineer's ability to accomplish these common tasks. The study showed that issues in source code stemming from the lack of coding standards have increased over time and are prevalent.

Normally, software documentations are produced, informally. They are written in the unnatural and non-structural form of the language, such as user manuals, user requirements, design documentation, tutorials, support documentation, and so on. Recent studies show that 61% of software projects are subject to failure or challenges due to an increase in the costs and production time. Various factors may lead to this issue, and one of the major contributing factors is the lack of links between the software's source code and its related documents. The significance of software development and the possibility of making prospective changes by the development team necessitate an understanding of the links between various sections of codes and documentations. Therefore, it is crucial to design a system to link the software codes to their corresponding textual documentation. This article proposes a model for recovering the latent, but traceable links between software source codes and existing documents based on word extraction and function name separation. The contributions in this article include: (1) a model based on word extraction from document and source codes; (2) the proposal of an algorithm for splitting compound words and words that are connected to one another and completing abbreviations used in the names of functions, variables, and output commands; and (3) a new algorithm that is proposed for retrieving traceable latent links between the source code and documents. Two data sets are used in this research and the achieved results will be reported in terms of recall, precision, and F-measure. The experimental results are promising and indicate that the proposed approach significantly outperforms its counterparts.

The problem of consistency between software requirements and their implementation in source code becomes critically important as the scale and complexity of modern software systems increase, since the absence of reliable traceability links often leads to incomplete requirement implementation, complicates code maintenance, and hinders the verification of system correctness. Manual generation of traceability matrices is a labour-intensive and error-prone process, especially in large projects. The use of large language models opens up new opportunities for automating this process, as such models are capable of reflecting deep semantic relationships between text requirements and software code fragments. The article proposes a method for identifying traceability links between requirements and software code using transformer models of large language systems. The proposed approach is based on converting text artefacts into vector representations using CodeBERT, SBERT, and TF-IDF models, followed by calculating semantic similarity to automatically identify potential connections. The method covers such stages as data preparation, embedding generation, search for relevant fragments, and evaluation of the results obtained. The experiments were conducted on the MSR-2021 dataset, which contains real traceability links for several projects. The obtained results demonstrated the advantage of CodeBERT over traditional approaches (TF-IDF, SBERT): the method achieves accuracy of up to 0.85 and an F1-score of up to 0.50, depending on the search depth, which represents strong performance for automated information retrieval and ranking tasks. The study additionally confirmed the importance of considering the structural context of the code and showed the influence of the Top-K parameter on the balance between recall and precision. The results indicate that integrating LLM-based models significantly improves the level of automation, consistency, and quality of requirements traceability in modern software development environments.

Context and motivation: Traceability is used to follow and understand the relationships between various software engineering artifacts such as requirements and source code. Comprehensive traceability of software engineering artifacts is important to ensure that a software can be further developed or maintained. Traceability links are often created manually by using commit ids or retrospectively by using information retrieval (IR). Question/Problem: However, creating traceability links manually is costly and it is error-prone in retrospect. As part of our ongoing research on feature management where traceability is also of interest, we use a lightweight tagging approach to relate artifacts. We want to investigate how such a tag-based approach compares to approaches using commit ids, interaction logs (IL), and IR for creating traceability links. Principal ideas/results: We conducted a case study in which students applied the tag-based, the IL-based, and the commit-based approach. We transformed the tags to traceability links and compared them with the commit-based and IL-based approach as well as with IR-based approaches, using a gold standard. We applied different improvements. Contribution: This is the first study comparing four completely different traceability approaches in one project. The combination of IL and commit ids shows the best precision and recall but is intrusive. The other approaches differ less in precision and recall and both need improvement for practical application. We discuss the benefits and drawbacks of the different approaches and state implications for research and practice.

Information retrieval (IR) is widely used in automatically requirements traceability recovery. Corresponding approaches are built based on textual similarity, that is, the higher the similarity, the higher possibility of artifacts related. A common work of many IR-based techniques is to remove false positive links in the candidate links to achieve higher accuracy. In fact, traceability links can be recovered by different kinds of information, not only the textual information. In our study, we propose to recover more traceability links by exploring both textual features and structural information. Specifically, we use combined IR techniques to process the textual information of the software artifacts, and extract the structural information from the source code, establishing corresponding code relationship graphs. We then incorporate such structural information into the traceability recovery analysis by using graph embedding. The results show that combined IR techniques and using graph embedding technology to process structural information can improve the recovery traceability.

When a system evolves, while the source code is changed, documentation and traceability links are barely ever updated: maintaining traceability information between software artifacts is a costly and tedious activity, which is frequently sacrificed during development and maintenance due to market pressure. The paper presents a new method to recovery traceability links between high level and low level artifacts. The method is based on the partial knowledge of a subset of tracability links. It can be fully automated and the human intervention is only required to confirm or confute recovered traceability links. The method has been applied to software written in Java, to trace classes onto functional requirements. Experimental results demonstrate the superiority of the novel method over previously published results on the same system.