Chapter 8 - Applications

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.

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.

ABSTRACTAn internal audit engagement at a large bank revealed that legacy software code can represent significant risk to an organization. In this engagement, several instances of malicious COBOL source code were discovered through manual inspection and identification. The internal auditors were concerned that more instances of faulty code could be in the production environment, and that manually inspecting over 100 million lines of source code would be infeasible. Under their auspices, I developed the Retrospective Static Source Code Analysis Framework for automatically identifying source code files likely to contain source code faults. We implemented this audit analytic framework in a tool called COBOL Analyzer. Using the tool, the auditors discovered thousands of potential source code files with faults and, using a ranking method, audited the most suspicious ones. The tool was deemed a success and it is undergoing further development by the internal audit team.

The performance of a programmer can be defined as skills in solving problems or challenges. A programmer produces source codes. There are types of source code: physical line of code (PLOC) is the source code without comments and whitespace whereas the logical line of code (LLOC) is the source code in the form of statements. In the previous work, an attempt to measure programmer performance was proposed and implemented in a tool called Prometer. The tool uses LOC as the sole metric. In this work, we added PLOC and LLOC to give a more complete measurement result. We collected historical data from GitHub repositories. We cloned and parsed the repositories to find authors and the contributed codes. We count the number of PLOC and LLOC besides LOC. Lastly, we generated the performance score based on their influence score. The programmer performance is obtained from the sum of scores on each metric.

Chapter 12 - Source Code Format

K-scope is a source code analysis tool with a graphical user interface for the performance tuning of Fortran programs. With K-scope, developers are able to visually understand the structures of their Fortran programs and estimate their performance. However, the original version of K-scope has two problems. First, it lacks the ability to integrate the results of source code analysis with performance profiling data. Second, it requires developers to install XcalableMP because K-scope utilizes the front-end of the XcalableMP compiler. However it is difficult to set up the XcalableMP environment because this requires installing and configuring several libraries and applications. A binary package of XcalableMP is only available for major Linux distributions, and developers thus have a hard time installing XcalableMP on other environments, e.g., Windows. In order to address these two problems, we extend K-scope with two mechanisms. The first visualizes performance profiling data and the second offloads the parsing of Fortran programs to a remote server. More specifically, the visualization mechanism enables users to readily identify performance bottlenecks in their programs by mapping performance profiling data to each line of the source code. With the offloading mechanism, developers no longer need to install XcalableMP. Instead, they can connect K-scope to a remote server on which XcalableMP is installed, and which generates the intermediate code used for analysis. For this purpose, we develop a tool named SSHconnect. To verify the effectiveness of our extended K-scope, we analyze the Nonhydrostatic Icosahedral Atmospheric Model (NICAM) code, an application for global climate simulation that consists of about 300,000 lines of Fortran code. We found that K-scope successfully identified performance bottlenecks in the NICAM code and translated the source code for several applications using its remote parsing mechanism.

Secure cloud model for intellectual privacy protection of arithmetic expressions in source codes using data obfuscation techniques

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

A traditional obstacle in the use of multiple representations is the need to maintain traceability among the representations in the face of evolution. The introduction of software architecture, and architecture-based development, has brought this need to architectural descriptions and corresponding source code. Specifically, the task is to relate versions of architectural elements to versions of source code configuration items, and to update those relations as new versions of the architecture and source code are produced. We present ArchTrace, a new approach that we developed to address this problem. ArchTrace distinguishes itself by continuously updating traceability relations from architectural elements to code elements through a policy-based extensible infrastructure that allows a group of developers to choose a set of traceability management policies that best match their situational needs and/or working styles. We introduce the high-level approach of ArchTrace, discuss its extensible infrastructure, and present our current set of ten pluggable traceability management policies. We conclude with a retrospective analysis of data collected from a twenty month period of development and maintenance of Odyssey, a component-based software development environment comprised of over 50,000 lines of code. This analysis shows that our approach is promising: with respect to the ideal set of traceability links, the policies applied resulted in a precision of 95% and recall of 89%.

Static and dynamic program analysis techniques are important research areas in software security. Static analysis helps us locate vulnerabilities in a software by looking at the source code. Dynamic analysis helps us reason about the behavior of the software from information gathered at run-time. In this thesis, we are focusing on data flow analysis and heap analysis which are key static and dynamic program analysis techniques respectively.
\n
\nIn the first part of this thesis, we aim at detecting vulnerabilities in Android applications which have capability leaks. The security of the Android platform relies mainly on sandboxing applications and restricting their capabilities such that no application, by default, can perform any operations that would adversely impact other applications, the operating system, or the user. However, a recent research reported that a genuine but vulnerable application may leak its capabilities. When being leveraged, other applications can gain extra capabilities which they are not granted originally. We present DroidChecker, an Android application analyzing tool which searches for the aforementioned vulnerability in Android applications. DroidChecker uses interprocedural control flow graph searching and static taint checking to detect exploitable data paths in an Android application. We analyzed more than 1100 Android applications using DroidChecker and found 6 previously unknown vulnerable applications including the renowned Adobe Photoshop Express application. We also developed a malicious application that exploits the previously unknown vulnerability found in the Adobe Photoshop Express application. We showed that the malicious application, which is not granted any permissions, can access contacts on the phone with just a few lines of code.
\n
\nIn the second part of this thesis, we explore the use of heap analysis to extract software birthmarks. There are techniques like code obfuscation and watermarking which can make the source code of a program difficult to understand by humans and prove the ownership of the program. However, code obfuscation cannot avoid the source code being copied and a watermark can be defaced. A birthmark is a group of unique characteristics a program possesses that can be used to identify the program. We propose two novel dynamic birthmark systems based on the run-time heap. A dynamic birthmark is one that is extracted when the program is executing. Since it is based on the run-time behavior of the program, semantics-preserving transformations of the code like obfuscation cannot defeat dynamic birthmarks. In this regard, dynamic birthmarks are more robust compared with static birthmarks.
\n
\nTo the best of our knowledge, these are the first birthmark systems using heap analysis as the underlying technique. The basic idea is to take snapshots of the heap while the program is running. From the snapshots, heap graphs are constructed to model the referencing structure between objects. After going through some filtering and referencing processes, they become the birthmarks. The two birthmark systems have been devised to extract birthmarks for Java programs and JavaScript programs respectively. While the underlying ideas of the two birthmark systems are similar, the differences in nature of the two programming languages led to different implementation designs.

Code clones represent a stumbling blocking the way of having a more readable, maintainable and less complicated source codes, free of bugs and errors. Many studies had been proposed for detecting and omitting the four types of cloned codes based on pattern matching, syntax parsing, tree parsing and refactoring which is the most commonly used technique to remove the code clones from software, while maintaining its original behavior. In this paper, we propose an automated refactoring technique and its correspondence algorithm to omit code clones of type 1 and type 2. The proposed technique performance was tested and evaluated using four open source Java projects JFreeChart, JRuby, JCommon and Apache ant. The performance of the source codes was indicated based on number of metrics as the lines of code, number of blank lines, method’s count and cyclomatic complexity before and after applying the proposed technique. The experimentation results indicated that the proposed technique had showed superiority over the state-of-the-art through omitting the cloned codes with the possibility of maintaining the stability and correctness of behavior of the source codes under consideration.

Observation-based slicing and its generalization observational slicing are recently-introduced, language-independent dynamic slicing techniques. They both construct slices based on the dependencies observed during program execution, rather than static or dynamic dependence analysis. The original implementation of the observation-based slicing algorithm used lines of source code as its program representation. A recent variation, developed to slice modelling languages (such as Simulink), used an XML representation of an executable model. We ported the XML slicer to source code by constructing a tree representation of traditional source code through the use of srcML. This work compares the tree- and line-based slicers using four experiments involving twenty different programs, ranging from classic benchmarks to million-line production systems. The resulting slices are essentially the same size for the majority of the programs and are often identical. However, structural constraints imposed by the tree representation sometimes force the slicer to retain enclosing control structures. It can also “bog down” trying to delete single-token subtrees. This occasionally makes the tree-based slices larger and the tree-based slicer slower than a parallelised version of the line-based slicer. In addition, a Java versus C comparison finds that the two languages lead to similar slices, but Java code takes noticeably longer to slice. The initial experiments suggest two improvements to the tree-based slicer: the addition of a size threshold, for ignoring small subtrees, and subtree replacement. The former enables the slicer to run 3.4 times faster while producing slices that are only about 9% larger. At the same time the subtree replacement reduces size by about 8–12% and allows the tree-based slicer to produce more natural slices.

As technology continues to advance, it becomes increasingly integrated into daily life facilitating complex tasks across a range of environments. While some applications such as smartphones and smartwatches are less critical, others like healthcare devices and autonomous vehicles demand bug-free performance to prevent financial loss or harm. Traditionally, simulation-based testing and formal verification played a major role in ensuring a bug-free device. However, the simulation of bigger systems is limited to a definite number of scenarios on the Design under Verification (DUV). Hence, it is unable to explore all possible inputs that can occur. Formal verification, on the other hand, offers a higher level of assurance through mathematical proofs but is both time-consuming and suffers from scalability issues, especially as designs grow in complexity. Recently, Large Language Models (LLMs) have shown promise in tasks previously limited to human expertise. Their natural language processing capabilities can assist in handling extensive specifications and source code, particularly in debugging hardware descriptions and analyzing security and functionality. The utilization of Retrieval Augmented Generation (RAG) has further enhanced LLMs by incorporating large specification or source code bases, thereby improving their bug-identification and correction capabilities. While recent advancements in LLMs, particularly with RAG, have yielded promising results in bug identification and correction for a small class of hardware bugs, significant gaps remain in their full potential for systematically addressing a wide range of hardware bugs. For instance, existing LLM methodologies struggle to detect bugs involving incorrect constant values, i.e., the use of wrong constants in source code. This limitation underscores the need for further exploration in utilizing LLMs to fully optimize the verification process. To bridge this gap, we propose a 3-phased 4-stage LLM-assisted systematic bug closure methodology that focuses on functional bugs in Verilog HDL rather than structural or syntactic issues. Our approach extracts functional properties of the DUV and systematically breaks down complex expressions into smaller sub-expressions to facilitate bug detection and correction. By employing RAG, the LLM is guided using the functional specifications and source code to identify and correct bugs. If the initial guidance through RAG is insufficient, our methodology initiates an iterative bug closure process. This includes incorporating more extensive information from the specifications, fetching additional lines of code for bug localization, and breaking down complex Verilog HDL expressions. In our comprehensive evaluation, we assess the LLM’s capabilities using 9 different categories of bugs. As benchmarks, we use 5 OpenTitan Intellectual Property (IP) cores to demonstrate the scalability and effectiveness of our bug closure methodology where ≈ 60% of the bugs were corrected. Specifically, we evaluate OpenAI’s GPT-4 in its ability to identify and correct functional bugs in Verilog HDL code.

Software Defect Prediction (SDP) plays an active area in many research domain of Software Quality of Assurance (SQA). Many existing research studies are based on software traditional metric sets and defect prediction models are built in machine language to detect the bug for limited source code line. Inspired by the above existing system. In this paper, defect prediction is focused on predicting defects in source code. The objective of this thesis is to improve the software quality for accurate defect prediction is source code for file level. So, that it helps the developer to find the bug and fix the issue, to make better use of a resource which reduces the test effort, minimize the cost and improve the quality of software. A new approach is introduced to improve the prediction performance of Bidirectional RNNLM in Deep Neural Network. To build the defect prediction model a defect learner framework is proposed and first it need to build a Neural Language Model. Using this Language Model it helps to learn to deep semantic features in source code and it train & test the model. Based on language model it combined with software traditional metric sets to measure the code and find the defect. The probability of language model and metric set Cross-Entropy with Abstract Syntax Tree (CE-AST) metric is used to evaluate the defect proneness and set as a metric label. For classification the metric label K-NN classifier is used. BPTT algorithm for learning RNN will provide additional improvement, it improves the predictions performance to find the dynamic error.

While the creation of new branches and forks is easy and fast with modern version-control systems, merging is often time-consuming. Especially when dealing with many branches or forks, a prediction of merge costs based on lightweight indicators would be desirable to help developers recognize problematic merging scenarios before potential conflicts become too severe in the evolution of a complex software project. We analyze the predictive power of several indicators, such as the number, size or scattering degree of commits in each branch, derived either from the version-control system or directly from the source code. Based on a survey of 41 developers, we inferred 7 potential indicators to predict the number of merge conflicts. We tested corresponding hypotheses by studying 163 open-source projects, including 21,488 merge scenarios and comprising 49,449,773 lines of code. A notable (negative) result is that none of the 7 indicators suggested by the participants of the developer survey has a predictive power concerning the frequency of merge conflicts. We discuss this and other findings as well as perspectives thereof.