Source Code Elements Research Articles

Two-Level Information-Retrieval-Based Model for Bug Localization Based on Bug Reports

Software bugs are a noteworthy concern for developers and maintainers. When a failure is detected late, it costs more to be fixed. To repair the bug that caused the software failure, the location of the bug must first be known. The process of finding the defective source code elements that led to the failure of the software is called bug localization. Effective approaches for automatically locating bugs using bug reports are highly desirable, as they would reduce bug-fixing time, consequently lowering software maintenance costs. With the increasing size and complexity of software projects, manual bug localization methods have become complex, challenging, and time-consuming tasks, which motivates research on automated bug localization techniques. This paper introduces a novel bug localization model, which works on two levels. The first level localizes the buggy classes using an information retrieval approach and it has two additional sub-phases, namely the class-level feature scoring phase and the class-level final score and ranking phase, which ranks the top buggy classes. The second level localizes the buggy methods inside these classes using an information retrieval approach and it has two sub-phases, which are the method-level feature scoring phase and the method-level final score and ranking phase, which ranks the top buggy methods inside the localized classes. A model is evaluated using an AspectJ dataset, and it can correctly localize and rank more than 350 classes and more than 136 methods. The evaluation results show that the proposed model outperforms several state-of-the-art approaches in terms of the mean reciprocal rank (MRR) metrics and the mean average precision (MAP) in class-level bug localization.

Improving the efficiency of symbolic execution by clustering the input data based on the complexity of test generation

The object of research is means to increase computational effectiveness for automatic unit test generation process. It provides arguments for developing new method to achieve wider use of symbolic execution in commercial software development. The main task of the research is to create adaptive code clustering method that considers test generation complexity for structural source code elements and available computational resources that will increase effectiveness of computations. It is achieved by estimating test generation complexity and balancing the it for produced clusters during clusterization. As a result, proposed clustering method is adaptive to hardware and source code variability. It is shown that developed approach provides up to 30 % increase in computation effectiveness compared to clustering based on code structural properties alone for selected samples and up to 250 % in separate cases. This is caused by balanced estimated test generation complexity within generated clusters. It limits path explosion to expected levels that match computational resources for every cluster. Estimate of test generation complexity makes it possible to stop the computation when the spent time exceeds the corresponding complexity limit. Consequently, it makes it possible to prevent performing unnecessary computations. Proposed method makes it possible to use symbolic execution in commercial software development due to higher adaptability for source code and hardware variations. It will allow to reduce expenses on early-stage software testing and provide means for determining feasibility of symbolic execution for commercial projects

ОПИС ЗНАНЬ ПРО ВИХІДНИЙ КОД З ВИКОРИСТАННЯМ ОНТОЛОГІЇ

This research focuses on the use of ontologies as formal knowledge bases for representing source code in automated systems.By creating an ontology that represents the concepts, relationships, and properties of source code elements, it becomes possible to capture and organize knowledge about the codebase. This enables various functional abilities such as automated code analysis and reasoning about code structure and behavior. The aim of this research is to verify the ability to use ontology as a formal knowledge base about source code in automated systems. A review of the recent articles showed that existing tools to work with ontologies does not provide direct functionality to convert the code into a knowledge, so the idea proposed in the article has novelty. The research explores the use of the Web Ontology Language (OWL) as the primary ontology representation language due to its expressiveness, reasoning capabilities, and compatibility with semantic web standards. The research proposes the creation of ontology representations for various code entities, with classes representing main entity types and individuals representing specific instances within the codebase. To validate the concept and demonstrate the expected results, a proof-of-concept system is built, consisting of a parsing client, a RESTful API for communication, and an ontology manager. The system utilizes libraries such as SwiftSyntax for parsing Swift code, Alamofire for HTTP communication, and OWL manipulation libraries (such as OWL-API and ONT-API) for working with ontologies. The system aims to extract knowledge from the source code, convert it into ontology entities and axioms, and reason over the ontology using a reasoner (such as HermiT). The research concludes that ontologies can effectively store knowledge about source code and enable various further manipulations on that knowledge. However, further investigation is needed to determine the optimal set of properties and entities that should be supported by the code ontology extraction system to infer more knowledge about the source code.

FineCodeAnalyzer: Multi-Perspective Source Code Analysis Support for Software Developer Through Fine-Granular Level Interactive Code Visualization

Source code analysis is one of the important activities during the software maintenance phase that focuses on performing the tasks including bug localization, feature location, bug/feature assignment, and so on. However, handling the aforementioned tasks on a manual basis (i.e. finding the location of buggy code from a large application) is an expensive, time-consuming, tedious, and challenging task. Thus, the developers seek automated support in performing the software maintenance tasks through automated tools and techniques. However, the majority of the reported techniques are limited to textual analysis where the real developers’ concerns are not properly considered. Moreover, existing solutions seem less useful for the developers. This work proposes a tool (called as FineCodeAnalyzer) that supports an interactive source code analysis grounded on structural and historical relations at fine granular-level between the source code elements. To evaluate the performance of FineCodeAnalyzer, we consider 74 developers that assess three main facets: (i) usefulness, (ii) cognitive-load, and (iii) time efficiency. For usefulness concern, the results show that FineCodeAnalyzer outperforms the developers’ self-adopted strategies in locating the code elements in terms of Precision, Recall, and F1-Measure of accurately locating the code elements. Specifically, FineCodeAnalyzer outperforms the developers’ strategies up to 47%, 76%, and 61% in terms of Precision, Recall, and F1-measure, respectively. Additionally, FineCodeAnalyzer takes 5% less time than developers’ strategies in terms of minutes of time. For cognitive-load, the developers found FineCodeAnalyzer to be 72% less complicated than manual strategies, in terms of the NASA Tool Load Index metric. Finally, the results indicate that FineCodeAnalyzer allows effectively locating the code elements than the developer’s adopted strategies.

"@alex, this fixes #9": Analysis of Referencing Patterns in Pull Request Discussions

Pull Requests (PRs) are a frequently used method for proposing changes to source code repositories. When discussing proposed changes in a PR discussion, stakeholders often reference a wide variety of information objects for establishing shared awareness and common ground. Previous work has not considered how the referential behavior impacts collaborative software development via PRs. This knowledge gap is the major barrier in evaluating the current support for referencing in PRs and improving them. We conducted an explorative analysis of \textasciitilde7K references, collected from 450 public PRs on GitHub, and constructed taxonomies of referent types and expressions. Using our annotated dataset, we identified several patterns in the use of references. Referencing source code elements was prevalent but the authoring interface lacks support for it. Three classes of contextual factors influence referencing behaviors: referent type, discussion thread, and project attributes. Referencing patterns may indicate PR outcomes (e.g., merged PRs frequently reference issues, users, and tests). We conclude with design implications to support more effective referencing in PR discussion interfaces.

Usage of Artificial Intelligence to Improve Secure Software Development

C# is an object-oriented software language that was developed by Microsoft and runs on the .NET framework. It has the ninth in Github, and it would cause a great impact in .NET. Main method for the situation is mainly using the machine learning techniques to analyze the source code and determine the security level of a source code. Our focus point is the source code files that written in C#. By evaluating the source code elements of software, the framework could proclaim that either a software product is secure or not, thus developer can make necessary arrangement in his or her code. It is important, because securing the code during the creation of the software is easy as compared with the end of the software creation. As part of a limited literature review study, we have analyzed 3 main articles in detail. An assessment of the review is conducted according to artificial neural network logic to help improve the Security of C# software development.

Software evolution: the lifetime of fine-grained elements.

A model regarding the lifetime of individual source code lines or tokens can estimate maintenance effort, guide preventive maintenance, and, more broadly, identify factors that can improve the efficiency of software development. We present methods and tools that allow tracking of each line’s or token’s birth and death. Through them, we analyze 3.3 billion source code element lifetime events in 89 revision control repositories. Statistical analysis shows that code lines are durable, with a median lifespan of about 2.4 years, and that young lines are more likely to be modified or deleted, following a Weibull distribution with the associated hazard rate decreasing over time. This behavior appears to be independent from specific characteristics of lines or tokens, as we could not determine factors that influence significantly their longevity across projects. The programing language, and developer tenure and experience were not found to be significantly correlated with line or token longevity, while project size and project age showed only a slight correlation.

Name-based Approach to Identify Suspicious Return Statements

Identifier names account for 70 percent of source code in characters. Meaningful identifier names convey valuable natural language information of the corresponding software entities, and thus they can be exploited to analyse the program and comprehend the semantics of it. However, existing bug detection approaches often ignore such natural language information and semantics encoded in identifier names. To this end, we propose a name-based approach to identify suspicious return statements. The recent study suggests that source code elements are often lexically similar to their corresponding semantic related elements. Based on this assumption, we design a sequence of heuristic rules to determine whether the return statement of a given method matches the signature of it. Evaluations on 100 open-source Java projects suggest that the proposed approach detects 16 out of 60 real return bugs. The precision and recall of the proposed approach are 31% and 27%, respectively.

Enhanced Bug Prediction in JavaScript Programs with Hybrid Call-Graph Based Invocation Metrics

Bug prediction aims at finding source code elements in a software system that are likely to contain defects. Being aware of the most error-prone parts of the program, one can efficiently allocate the limited amount of testing and code review resources. Therefore, bug prediction can support software maintenance and evolution to a great extent. In this paper, we propose a function level JavaScript bug prediction model based on static source code metrics with the addition of a hybrid (static and dynamic) code analysis based metric of the number of incoming and outgoing function calls (HNII and HNOI). Our motivation for this is that JavaScript is a highly dynamic scripting language for which static code analysis might be very imprecise; therefore, using a purely static source code features for bug prediction might not be enough. Based on a study where we extracted 824 buggy and 1943 non-buggy functions from the publicly available BugsJS dataset for the ESLint JavaScript project, we can confirm the positive impact of hybrid code metrics on the prediction performance of the ML models. Depending on the ML algorithm, applied hyper-parameters, and target measures we consider, hybrid invocation metrics bring a 2–10% increase in model performances (i.e., precision, recall, F-measure). Interestingly, replacing static NOI and NII metrics with their hybrid counterparts HNOI and HNII in itself improves model performances; however, using them all together yields the best results.

An automatically created novel bug dataset and its validation in bug prediction

Bugs are inescapable during software development due to frequent code changes, tight deadlines, etc.; therefore, it is important to have tools to find these errors. One way of performing bug identification is to analyze the characteristics of buggy source code elements from the past and predict the present ones based on the same characteristics, using e.g. machine learning models. To support model building tasks, code elements and their characteristics are collected in so-called bug datasets which serve as the input for learning.We present the BugHunter Dataset: a novel kind of automatically constructed and freely available bug dataset containing code elements (files, classes, methods) with a wide set of code metrics and bug information. Other available bug datasets follow the traditional approach of gathering the characteristics of all source code elements (buggy and non-buggy) at only one or more pre-selected release versions of the code. Our approach, on the other hand, captures the buggy and the fixed states of the same source code elements from the narrowest timeframe we can identify for a bug’s presence, regardless of release versions. To show the usefulness of the new dataset, we built and evaluated bug prediction models and achieved F-measure values over 0.74.

Code smell detection using multi-label classification approach

Code smells are characteristics of the software that indicates a code or design problem which can make software hard to understand, evolve, and maintain. There are several code smell detection tools proposed in the literature, but they produce different results. This is because smells are informally defined or subjective in nature. Machine learning techniques help in addressing the issues of subjectivity, which can learn and distinguish the characteristics of smelly and non-smelly source code elements (classes or methods). However, the existing machine learning techniques can only detect a single type of smell in the code element that does not correspond to a real-world scenario as a single element can have multiple design problems (smells). Further, the mechanisms proposed in the literature could not detect code smells by considering the correlation (co-occurrence) among them. To address these shortcomings, we propose and investigate the use of multi-label classification (MLC) methods to detect whether the given code element is affected by multiple smells or not. In this proposal, two code smell datasets available in the literature are converted into a multi-label dataset (MLD). In the MLD, we found that there is a positive correlation between the two smells (long method and feature envy). In the classification phase, the two methods of MLC considered the correlation among the smells and enhanced the performance (on average more than 95% accuracy) for the 10-fold cross-validation with the ten iterations. The findings reported help the researchers and developers in prioritizing the critical code elements for refactoring based on the number of code smells detected.

Associating Natural Language Comment and Source Code Entities

Comments are an integral part of software development; they are natural language descriptions associated with source code elements. Understanding explicit associations can be useful in improving code comprehensibility and maintaining the consistency between code and comments. As an initial step towards this larger goal, we address the task of associating entities in Javadoc comments with elements in Java source code. We propose an approach for automatically extracting supervised data using revision histories of open source projects and present a manually annotated evaluation dataset for this task. We develop a binary classifier and a sequence labeling model by crafting a rich feature set which encompasses various aspects of code, comments, and the relationships between them. Experiments show that our systems outperform several baselines learning from the proposed supervision.

Validation of Authentication Measures Implementation in Iot Mobile Applications

Smartphones are an integral cog of the IoT environment and a fundamental bloc of any related security solution, given that IoT mobile applications allow users not only to get information, but also to influence the environment. This paper presents a methodological instrument that can contribute to implementing and evaluating security measures in mobile applications by means of an automated analysis tool. A clear process for linking policy and high-level security guidelines and measures to concrete source code elements is depicted, as well as an automated way of testing a set of mobile applications against them. In addition, the obtained results highlight the current state of authentication measures’ implementation in IoT mobile applications; at the same time, it is important to note that the proposed approach is generic enough to accommodate other security principles as well.

Change impact analysis for maintenance and evolution of variable software systems

Understanding variability is essential to allow the configuration of software systems to diverse requirements. Variability-aware program analysis techniques have been proposed for analyzing the space of program variants. Such techniques are highly beneficial, e.g., to determine the potential impact of changes during maintenance. This article presents an interprocedural and configuration-aware change impact analysis (CIA) approach for determining the possibly impacted source code elements when changing the source code of a product family. The approach also supports engineers, who are adapting the code of specific product variants after an initial pre-configuration. The approach can be adapted to work with different variability mechanisms, it is more precise than existing CIA approaches, and it can be implemented using standard control flow and data flow analysis. We report evaluation results on the benefit and performance of the approach using industrial product lines.

Empirical evaluation of software maintainability based on a manually validated refactoring dataset

ContextRefactoring is a technique for improving the internal structure of software systems. It has a solid theoretical background while being used in development practice also. However, we lack empirical research results on the real effect of code refactoring and its application. ObjectiveThis paper presents a manually validated subset of a previously published dataset containing the refactorings extracted by the RefFinder tool, code metrics, and maintainability of 7 open-source systems. We found that RefFinder had around 27% overall average precision on the subject systems, thus our manually validated subset has substantial added value. Using the dataset, we studied several aspects of the refactored and non-refactored source code elements (classes and methods), like the differences in their maintainability and source code metrics. MethodWe divided the source code elements into a group containing the refactored elements and a group with non-refactored elements. We analyzed the elements’ characteristics in these groups using correlation analysis, Mann–Whitney U test and effect size measures. ResultsSource code elements subjected to refactorings had significantly lower maintainability than elements not affected by refactorings. Moreover, refactored elements had significantly higher size related metrics, complexity, and coupling. Also these metrics changed more significantly in the refactored elements. The results are mostly in line with our previous findings on the not validated dataset, with the difference that clone metrics had no strong connection with refactoring. ConclusionsCompared to the preliminary analysis using a not validated dataset, the manually validated dataset led to more significant results, which suggests that developers find targets for refactorings based on some internal quality properties of the source code, like their size, complexity or coupling, but not clone related metrics as reported in our previous studies. They do not just use these properties for identifying targets, but also control them with refactorings.

Automatic Calculation of Process Metrics and their Bug Prediction Capabilities

Identifying fault-prone code parts is useful for the developers to help reduce the time required for locating bugs. It is usually done by characterizing the already known bugs with certain kinds of metrics and building a predictive model from the data. For the characterization of bugs, software product and process metrics are the most popular ones. The calculation of product metrics is supported by many free and commercial software products. However, tools that are capable of computing process metrics are quite rare. In this study, we present a method of computing software process metrics in a graph database. We describe the schema of the database created and we present a way to readily get the process metrics from it. With this technique, process metrics can be calculated at the file, class and method levels. We used GitHub as the source of the change history and we selected 5 open-source Java projects for processing. To retrieve positional information about the classes and methods, we used SourceMeter, a static source code analyzer tool. We used Neo4j as the graph database engine, and its query language - cypher - to get the process metrics. We published the tools we created as open-source projects on GitHub. To demonstrate the utility of our tools, we selected 25 release versions of the 5 Java projects and calculated the process metrics for all of the source code elements (files, classes and methods) in these versions. Using our previous published bug database, we built bug databases for the selected projects that contain the computed process metrics and the corresponding bug numbers for files and classes. (We published these databases as an online appendix.) Then we applied 13 machine learning algorithms on the database we created to find out if it is feasible for bug prediction purposes. We achieved F-measure values on average of around 0.7 at the class level, and slightly better values of between 0.7 and 0.75 at the file level. The best performing algorithm was the RandomForest method for both cases.

Automating the Refactoring Process

To decrease software maintenance cost, software development companies use static source code analysis techniques. Static analysis tools are capable of finding potential bugs, anti-patterns, coding rule violations, and they can also enforce coding style standards. Although there are several available static analyzers to choose from, they only support issue detection. The elimination of the issues is still performed manually by developers. Here, we propose a process that supports the automatic elimination of coding issues in Java. We introduce a tool that uses a third-party static analyzer as input and enables developers to automatically fix the detected issues for them. Our tool uses a special technique, called reverse AST-search, to locate source code elements in a syntax tree, just based on location information. Our tool was evaluated and tested in a two-year project with six software development companies where thousands of code smells were identified and fixed in five systems that have altogether over five million lines of code.

The effect of automatic concern mapping strategies on conceptual cohesion measurement

Context: Cohesion has been recognized as an important quality attribute of software design across decades. It can be defined as the degree to which a module is focused on a single concern of software. A concern is any concept, feature, requirement or property of the problem or solution domain. Conceptual cohesion is an alternative way of cohesion measurement based on what concerns each module addresses. Therefore, adopting a strategy to map concerns to source code elements is challenging but necessary.Objective: We aim at providing empirical evidence about whether automatic concern mapping strategies are already ready to be used effectively for conceptual cohesion measurement.Method: We carried out an empirical study to assess the ability of conceptual cohesion measurement using different automatic concern mapping strategies in selecting the least cohesive modules.Results: Conceptual cohesion measurements over the two analyzed mapping strategies performed weakly in the ability of selecting the least cohesive modules. We then provide a discussion to explain the reasons.Conclusion: Concern mapping strategies should be carefully chosen for conceptual cohesion measurement, specially if automatic mapping is under consideration. Manual mapping is still the most reliable way for computing conceptual cohesion. We pointed out limitations in automatic mapping strategies that go beyond conceptual cohesion measurement purposes and which should be considered in future research or applications in industry.

Eye gaze and interaction contexts for change tasks – Observations and potential

Study findings based on eye-tracking and user interaction monitoring.Insights into the detailed navigation behavior of 22 developers.An approach to automatically capture the source code elements a developer looks at.A discussion on the value the data and the findings offer for developer support. The more we know about software developers detailed navigation behavior for change tasks, the better we are able to provide effective tool support. Currently, most empirical studies on developers performing change tasks are, however, limited to very small code snippets or limited by the granularity and detail of the data collected on developers navigation behavior. In our research, we extend this work by combining user interaction monitoring to gather interaction context the code elements a developer selects and edits with eye-tracking to gather more detailed and fine-granular gaze context-code elements a developer looked at. In a study with 12 professional and 10 student developers we gathered interaction and gaze contexts from participants working on three change tasks of an open source system. Based on an analysis of the data we found, amongst other results, that gaze context captures different aspects than interaction context and that developers only read small portions of code elements. We further explore the potential of the more detailed and fine-granular data by examining the use of the captured change task context to predict perceived task difficulty and to provide better and more fine-grained navigation recommendations. We discuss our findings and their implications for better tool support.

A combined approach for concern identification in KDM models

Abstract Background Systems are considered legacy when their maintenance costs raise to unmanageable levels, but they still deliver valuable benefits for companies. One intrinsic problem of this kind of system is the presence of crosscutting concerns in their architecture, hindering its comprehension and evolution. Architecture-driven modernization (ADM) is the new generation of reengineering in which models are used as main artifacts during the whole process. Using ADM, it is possible to modernize legacy systems by remodularizing their concerns in a more modular shape. In this sense, the first step is the identification of source code elements that contribute to the implementation of those concerns, a process known as concern mining. Although there exist a number of concern mining approaches in the literature, none of them are devoted to ADM, leading individual groups to create their own ad hoc proprietary solutions. In this paper, we propose an approach called crosscutting-concern knowledge discovery meta-model (CCKDM) whose goal is to mine crosscutting concerns in ADM context. Our approach employs a combination of a concern library and a K-means clustering algorithm. Methods We have conducted an experimental study composed of two analyses. The first one aimed to identify the most suitable levenshtein values to apply the clustering algorithm. The second one aimed to check the recall and precision of our approach when compared to oracles and also to two other existing mining techniques (XScan and Timna) found in literature. Results The main result of this work is a combined mining approach for KDM that enables a concern-oriented modernization to be performed. As a secondary and more general result, this work shows that it is possible to adapt existing concern mining code-level approaches for being used in ADM processes and maintain the same level of precision and recall. Conclusions By using the approach herein presented, it was possible to conclude the following: (i) it is possible to automate the identification of crosscutting concerns in KDM models and (ii) the results are similar or equal to other approaches.