Byron J. Williams

Characterizing software architecture changes: A systematic review

With todays ever increasing demands on software, software developers must produce software that can be changed without the risk of degrading the software architecture. One way to address software changes is to characterize their causes and effects. A software change characterization mechanism allows developers to characterize the effects of a change using different criteria, e.g. the cause of the change, the type of change that needs to be made, and the part of the system where the change must take place. This information then can be used to illustrate the potential impact of the change. This paper presents a systematic literature review of software architecture change characteristics. The results of this systematic review were used to create the Software Architecture Change Characterization Scheme (SACCS). This report addresses key areas involved in making changes to software architecture. SACCSs purpose is to identify the characteristics of a software change that will have an impact on the high-level software architecture.

Characterizing Software Architecture Changes: An Initial Study

The goal of this paper is to improve the prediction performance of fault-prone module prediction models (fault-proneness models) by employing over/under sampling methods, which are preprocessing procedures for a fit dataset. The sampling methods are expected to improve prediction performance when the fit dataset is unbalanced, i.e. there exists a large difference between the number of fault-prone modules and not-fault-prone modules. So far, there has been no research reporting the effects of applying sampling methods to fault-proneness models. In this paper, we experimentally evaluated the effects of four sampling methods (random over sampling, synthetic minority over sampling, random under sampling and one-sided selection) applied to four fault-proneness models (linear discriminant analysis, logistic regression analysis, neural network and classification tree) by using two module sets of industry legacy software. All four sampling methods improved the prediction performance of the linear and logistic models, while neural network and classification tree models did not benefit from the sampling methods. The improvements of Fl-values in linear and logistic models were 0.078 at minimum, 0.224 at maximum and 0.121 at the mean.With todays ever increasing demands on software, developers must produce software that can be changed without the risk of degrading the software architecture. Degraded software architecture is problematic because it makes the system more prone to defects and increases the cost of making future changes. The effects of making changes to software can be difficult to measure. One way to address software changes is to characterize their causes and effects. This paper introduces an initial architecture change characterization scheme created to assist developers in measuring the impact of a change on the architecture of the system. It also presents an initial study conducted to gain insight into the validity of the scheme. The results of this study indicated a favorable view of the viability of the scheme by the subjects, and the scheme increased the ability of novice developers to assess and adequately estimate change effort.

Managing technical debt: an industrial case study

Technical debt is the consequence of trade-offs made during software development to ensure speedy releases. The research community lacks rigorously evaluated guidelines to help practitioners characterize, manage and prioritize debt. This paper describes a study conducted with an industrial partner during their implementation of Agile development practices for a large software development division within the company. The report contains our initial findings based on ethnographic observations and semi-structured interviews. The goal is to identify the best practices regarding managing technical debt so that the researchers and the practitioners can further evaluate these practices to extend their knowledge of the technical debt metaphor. We determined that the developers considered their own taxonomy of technical debt based on the type of work they were assigned and their personal understanding of the term. Despite managements high-level categories, the developers mostly considered design debt, testing debt and defect debt. In addition to developers having their own taxonomy, assigning dedicated teams for technical debt reduction and allowing other teams about 20% of time per sprint for debt reduction are good initiatives towards lowering technical debt. While technical debt has become a well-regarded concept in the Agile community, further empirical evaluation is needed to assess how to properly apply the concept for various development organizations.

Exception Handling Defects: An Empirical Study

Exception handling mechanisms are a feature common in many programming languages. Improper handling of exceptions can cause failures in software systems. This is especially critical for high-assurance systems where software failures may have severe consequences. Understanding the impact of misusing exception handling is important for better utilization of these constructs. This paper presents an exploratory study to determine whether using exception handling is relatively risky by analyzing the defect densities of exception handling code and the overall source code. Also, statistics representing the prevalence of exception handling code are proposed. The study was conducted with six major Eclipse releases. Essential data was collected using custom scripts to extract exception handling information from the source code and exception handling defects information from bug reports. We found that the density of defects that are closely related to exception handling constructs is relatively high compared to the overall defect density. This implies a relationship between the use of exception handling constructs and the risk of defects. Further studies should be conducted to better determine proper ways to implement exception handling and the root causes of exception defects in the software systems.

The Correspondence Between Software Quality Models and Technical Debt Estimation Approaches

Technical debt has recently become a major concern in the software industry. While it has been shown that technical debt has an adverse effect on the quality of a software system, there has been little work to explore this relationship. Further, with the growing number of approaches to estimate the technical debt principal of a software system, there is a dearth of work to empirically validate the relationship between technical debt scores produced by practical tools against established theoretical quality models. We conducted a case study across 10 releases of 10 open source systems in order to evaluate three proposed methods of technical debt principal estimation. The evaluation compares each technique against an external quality model. We found that only one estimation technique had a strong correlation to the quality attributes reusability and understand ability. In a multiple linear regression analysis we also found that a different estimation technique had a significant relationship to the quality attributes effectiveness and functionality. These results indicate that it is important that industry practitioners, ensure that the technical debt estimate they employ accurately depicts the effects of technical debt as viewed from their quality model.

A Preliminary Study Examining Relationships Between Nano-Patterns and Software Security Vulnerabilities

Software security plays a significant role in ensuring software quality. The goal of this study is to conduct a preliminary analysis to find hidden relationships between source code patterns and security defects. We describe a study in which we focus on evaluating software security using nano-patterns to reduce security risks during the development lifecycle. Nano-patterns are simple properties of Java methods. In our research, we investigate the correlation between software vulnerabilities and nano-patterns using data mining techniques. Identifying these relationships can assist developers to quickly assess the likelihood that they are writing vulnerable code and recommend tests to uncover the vulnerability. The goal of this research is to reduce the amount of vulnerable code developers write. We successfully apply data mining techniques to identify vulnerable code characteristics and apply hypothesis testing to validate the findings. This preliminary study shows that certain nano-patterns localReader, jdkClient, tailCaller are significantly present in vulnerable methods. These findings can be used to recommend security test patterns to improve vulnerability testing and reduce the number of vulnerabilities in released code.

Correlation Analysis among Java Nano-Patterns and Software Vulnerabilities

Ensuring software security is essential for developing a reliable software. A software can suffer from security problems due to the weakness in code constructs during software development. Our goal is to relate software security with different code constructs so that developers can be aware very early of their coding weaknesses that might be related to a software vulnerability. In this study, we chose Java nano-patterns as code constructs that are method-level patterns defined on the attributes of Java methods. This study aims to find out the correlation between software vulnerability and method-level structural code constructs known as nano-patterns. We found the vulnerable methods from 39 versions of three major releases of Apache Tomcat for our first case study. We extracted nano-patterns from the affected methods of these releases. We also extracted nano-patterns from the non-vulnerable methods of Apache Tomcat, and for this, we selected the last version of three major releases (6.0.45 for release 6, 7.0.69 for release 7 and 8.0.33 for release 8) as the non-vulnerable versions. Then, we compared the nano-pattern distributions in vulnerable versus non-vulnerable methods. In our second case study, we extracted nano-patterns from the affected methods of three vulnerable J2EE web applications: Blueblog 1.0, Personalblog 1.2.6 and Roller 0.9.9, all of which were deliberately made vulnerable for testing purpose. We found that some nano-patterns such as objCreator, staticFieldReader, typeManipulator, looper, exceptions, localWriter, arrReader are more prevalent in affected methods whereas some such as straightLine are more vivid in non-affected methods. We conclude that nano-patterns can be used as the indicator of vulnerability-proneness of code.

Examination of the software architecture change characterization scheme using three empirical studies

Software maintenance is one of the most crucial aspects of software development. Software engineering researchers must develop practical solutions to handle the challenges presented in maintaining mature software systems. Research that addresses practical means of mitigating the risks involved when changing software, reducing the complexity of mature software systems, and eliminating the introduction of preventable bugs is paramount to today’s software engineering discipline. The Software Architecture Change Characterization Scheme (SACCS) provides software maintainers with a systematic approach to analyzing and characterizing the impact of a change prior to its implementation. SACCS was designed to help novice developers understand change requests, facilitate discussion among developers, and provide a higher-quality change compared with an ad hoc approach. In addition, this paper describes three controlled experiments designed to assess the viability of using SACCS and its ability to fulfill its goals. The successive studies build upon each other to enable progressive insights into the viability of the scheme. The results indicate that SACCS: 1) provides insight into the difficulty of a change request by assisting novice developers to consider various aspects of the request’s potential to impact the system, 2) helps to facilitate discussion among developers by providing a common tool for change assessment, and 3) is a useful tool for supporting change implementation. The three experiments provide insight into the usefulness of SACCS, motivate additional research questions, and serve as a baseline for moving forward with research and further development of the approach.

Empirical evidence of code decay: A systematic mapping study

Code decay is a gradual process that negatively impacts the quality of a software system. Developers need trusted measurement techniques to evaluate whether their systems have decayed. The research aims to find what is currently known about code decay detection techniques and metrics used to evaluate decay. We performed a systematic mapping study to determine which techniques and metrics have been empirically evaluated. A review protocol was developed and followed to identify 30 primary studies with empirical evidence of code decay. We categorized detection techniques into two broad groups: human-based and metric-based approaches. We describe the attributes of each approach and distinguish features of several subcategories of both high-level groups. A tabular overview of code decay metrics is also presented. We exclude studies that do not use time (i.e., do not use evaluation of multiple software versions) as a factor when evaluating code decay. This limitation serves to focus the review. We found that coupling metrics are the most widely used at identifying code decay. Researchers use various terms to define code decay, and we recommend additional research to operationalize the terms to provide more consistent analysis.

High false positive detection of security vulnerabilities: a case study

Static code analysis is an emerging technique for secure software development that analyzes large software code bases without execution to reveal potential vulnerabilities present in the code. These vulnerabilities include but are not limited to SQL injections, buffer overflows, cross site scripting, improper security settings, and information leakage. Software developers can spend many man-hours to track and fix the flagged vulnerabilities. Surveys show that a high percentage of discovered vulnerabilities are actually false positives. This paper presents a case study that found that context information regarding libraries could account for many of the false positives. We suggest future research incorporate context information into static analysis tools for security.