Search

Widgets are part of many web applications and implement distinct interaction mechanisms, in reusable user interface components. However, implementing accessible widgets is a challenge, associated to different factors highlighted in the state-of-the-art, such as: lack of developers knowledge of accessibility guidelines, organization support and tools that support accessible development. This paper reports an investigation on JavaScript source-code complexity impacts of implementing accessibility requirements in widgets. We investigated Dialog, Drop-down menu and Tab widgets of 27 open-source JavaScript libraries. The results showed that widget software artifacts reported an increased average of source-code complexity when implementing accessibility requirements. Results also showed that using DOM-oriented JavaScript libraries (eg. jQuery) significantly increased source-code complexity of widgets. Nevertheless, when using Declarative Component-based JavaScript libraries, no significant difference in source-code complexity was observed. These results suggest that using Declarative Component-based widget libraries might reduce maintainability costs of JavaScript front-end projects.

A new metric was introduced to calculate the distance between actively modified files in a source code repository and the files, which are rarely modified and may be considered abandoned or even dead. It was empirically demonstrated that larger repositories have larger values of the introduced metric. The metric may be used for earlier detection of code maintenance anomalies and helping software developers make the decision of splitting the repository into smaller ones in order to prevent maintainability issues.

Mobile devices have become popular, and their use for daily activities has spread around the world. A wide variety of mobile applications aims to meet the daily needs of diverse people, such as transportation and commerce. Meanwhile, mobile accessibility is a worldwide concern. Accessibility is a requirement for any user to interact with software. For example, about 25% of the Brazilian population declares themselves as having some disability. Although traditional mobile software development approaches indicate that native development achieves higher computing performances, this implies high-priced development, difficult maintainability, and low accessibility for the interface components. Many mobile applications still lack accessibility, and people with disabilities may find barriers when interacting with them. We understand that Model-Driven Development (MDD) and cross-platform mobile development, together, may help to solve this gap and facilitate the development of more accessible mobile applications. Our goal is to create an MDD solution that generates accessible mobile applications. We place our focus on blind and low vision users to direct the development of our solution. In this work, we investigate MDD approaches for mobile development and appoint recommendations for accessibility in the user interface components. To achieve this goal, we developed AccessMDD, an approach to stimulate developers´ awareness of accessibility recommendations. This approach supports the inclusion of accessibility requirements and generates accessible user interfaces for mobile apps.

The current trend of transforming static embedded systems into open platforms (in which several software providers are able to directly load their software) drives the need to design and implement modular embedded software. Additionally, a myriad of embedded devices are expected to operate and provide services for years, or even decades, while remaining correct and secure at all times. Therefore, one of the emerging challenges for highly adaptive embedded computing platforms is to offer dynamic software composition at runtime and internal device housekeeping, which in conjunction improve device maintainability. We propose a hardware/software co-designed technique to improve both security and maintainability in modular embedded systems.

Context: Technical debt (TD) can compromise the quality of software systems in the long term. However, depending on the needs and properties of the specific product, different quality characteristics may be considered in the assessment with different levels of relevance. In this way, quality characteristics can guide teams in managing the TD, from identifying to paying for the TD items relevant to each situation. Although a set of TD item indicators has been identified in the literature, there is no clear guidance on how these indicators can be efficiently used to identify TD items. Aims: To investigate, from the point of view of software professionals using the SO platform, the relationship between the TD item indicators and the quality characteristics of the system, in order to guide the use of indicators for greater efficiency and effectiveness in identifying and managing DT items from a quality perspective. Method: We extracted empirical evidence using data mining from discussions related to TD on the SO. From the execution of an analysis process, the quality characteristics related to the occurrence of DT items identified in the discussions, the respective indicators and types of debt were identified. Results: The main results reveal that maintainability is the characteristic most related to TD through its sub-characteristics: modifiability, testability and modularity. Code debt items can be related to all quality characteristics, while Infrastructure debt can resonate up to 6 characteristics. All quality characteristics have at least one associated indicator, with an emphasis on Maintainability with 13 high-level and 28 low-level indicators. The indicator related to version problems is the one with the highest number of quality features. Conclusion: The relationship between indicators, TD types and quality characteristics was organized in a conceptual diagram in order to assist software teams in identifying which TD items are related to the quality characteristics that are critical to the project context, contributing to decision making regarding the best strategy for debt management.

Test smells are poor design and implementation choices that can affect the test code’s understanding and maintainability. Recent studies show the industry is not aware of the test smells concept, while software engineers commonly encounter obstacles to maintain test code. This study investigated test creation and maintenance strategies through developers’ perception of eight test smells types. We surveyed 87 software testers and interviewed eight to understand their view on test smells in practice. Our results show that most participants use manual strategies for creating and maintaining test cases. Based on data captured from software testers’ perspectives, this study contributes with possible directions and treatments to analyze test smells, seeking to understand how the test affects and potential solutions for test smells.

GoF Design Patterns (DPs) are optimal solutions for several recurring problems in software development. As maintenance accounts for a massive amount of development costs, understanding the impact of DPs on maintainability is key to decide whether their benefits outweigh their costs. To test the hypothesis that the Strategy DP impacts maintainability, we carried out a quasi-experiment with 19 final-year undergraduate students. Participants performed enhancement tasks in two identical versions of Java classes that differed only in that a version implemented the Strategy DP whereas another version did not. As recommended in the literature, we used effectiveness as a representative proxy of maintainability and correctness as a measure of effectiveness. We found a statistically significant correctness change between treatments. Moreover, the effect size shows that a participant is 47.7 percentage points more likely to succeed when the Strategy DP is not used. Conversely, a participant is 5.5 times more likely to fail when the DP is introduced. Unlike most related studies, our findings suggest that the Strategy DP may reduce software maintainability although these findings need to be confirmed by independent and extended replications.

Software Product Lines (SPL) are generally specified using a Feature Model (FM), an artifact designed in the early stages of the SPL development life cycle. This artifact can quickly become too complex, which makes it challenging to maintain an SPL. Therefore, it is essential to evaluate the artifact's maintainability continuously. The literature brings some approaches that evaluate FM maintainability through the aggregation of maintainability measures. Machine Learning (ML) models can be used to create these approaches. They can aggregate the values of independent variables into a single target data, also called a dependent variable. Besides, when using white-box ML models, it is possible to interpret and explain the ML model results. This work proposes white-box ML models intending to classify the FM maintainability based on 15 measures. To build the models, we performed the following steps: (i) we compared two approaches to evaluate the FM maintainability through a human-based oracle of FM maintainability classifications; (ii) we used the best approach to pre-classify the ML training dataset; (iii) we generated three ML models and compared them against classification accuracy, precision, recall, F1 and AUC-ROC; and, (iv) we used the best model to create a mechanism capable of providing improvement indicators to domain engineers. The best model used the decision tree algorithm that obtained accuracy, precision, and recall of 0.81, F1-Score of 0.79, and AUC-ROC of 0.91. Using this model, we could reduce the number of measures needed to evaluate the FM maintainability from 15 to 9 measures.

We propose Switch(De)Composer, a solution for enabling network developers to leverage the One Big Switch abstraction to write modular switch code that can be deployed across a programmable forwarding plane while promoting reusability, maintainability, and efficient resource usage in switches.

Machine learning has been increasingly used to solve various software engineering tasks. One example of their usage is in regression testing, where a classifier is built using historical code commits to predict which test cases require execution. In this paper, we address the problem of how to link specific code commits to test types to improve the predictive performance of learning models in improving regression testing. We design a dependency taxonomy of the content of committed code and the type of a test case. The taxonomy focuses on two types of code commits: changing memory management and algorithm complexity. We reviewed the literature, surveyed experienced testers from three Swedish-based software companies, and conducted a workshop to develop the taxonomy. The derived taxonomy shows that memory management code should be tested with tests related to performance, load, soak, stress, volume, and capacity; the complexity changes should be tested with the same dedicated tests and maintainability tests. We conclude that this taxonomy can improve the effectiveness of building learning models for regression testing.

The presence of source code that is no longer needed is a handicap to project maintainability. The larger and longer-lived the project, the higher the chances of accumulating dead code in its different forms. Manually detecting unused code is time-consuming, tedious, error-prone, and requires a great level of deep knowledge about the codebase. In this paper, we examine the kinds of dead code (specifically, oxbow code) that can appear in Erlang projects, and formulate rules to identify them with high accuracy. We also present an open-source static analyzer that implements these rules, allowing for the automatic detection and confident removal of oxbow code in Erlang codebases, actively contributing to increasing their quality and maintainability., 13 pages, 1 figure, 2 tables

Unit testing focuses on verifying the functions of individual units of a software system. It is challenging due to the high inter-dependencies among software units. Developers address this by mocking-replacing the dependency by a "faked" object. Despite the existence of powerful, dedicated mocking frameworks, developers often turn to a "hand-rolled" approach-inheritance. That is, they create a subclass of the dependent class and mock its behavior through method overriding. However, this requires tedious implementation and compromises the design quality of unit tests. This work contributes a fully automated refactoring framework to identify and replace the usage of inheritance by using Mockito-a well received mocking framework. Our approach is built upon the empirical experience from five open source projects that use inheritance for mocking. We evaluate our approach on four other projects. Results show that our framework is efficient, generally applicable to new datasets, mostly preserves test case behaviors in detecting defects (in the form of mutants), and decouples test code from production code. The qualitative evaluation by experienced developers suggests that the auto-refactoring solutions generated by our framework improve the quality of the unit test cases in various aspects, such as making test conditions more explicit, as well as improved cohesion, readability, understandability, and maintainability with test cases.

This paper shares our experience in supporting and running the Open vSwitch (OVS) software switch, as part of the NSX product for enterprise data center virtualization used by thousands of VMware customers. Starting in 2009, the OVS design split its code between tightly coupled kernel and userspace components. This split was necessary at the time for performance, but it caused maintainability problems that persist today. In addition, in-kernel packet processing is now much slower than newer options. To solve the problems caused by the user/kernel split, OVS must adopt a new architecture. We describe two possibilities that we explored, but did not adopt, one because it gives up compatibility with drivers and tools that are important to virtual data center operators, the other because it performs poorly. Instead, we endorse a third approach, based on a new Linux socket type called AF\_XDP, which solves the maintainability problem in a compatible, performant way. The new code is already merged into the mainstream OVS repository. We include a thorough performance evaluation and a collection of lessons learned.

Java code can be annotated with formal specifications using the Java Modelling Language (JML). Previous work has provided IDE plugins intended to help write JML, but mostly for the Eclipse IDE. We introduce IntelliJML, a JML plugin for IntelliJ IDEA, with a focus on ease of use and maintainability. Features such as syntax, semantic, and type checking, as well as syntax highlighting and code completion are integrated into the plugin. The plugin can also be extended in the future to add more features. The source code for the plugin can be found at https://gitlab.utwente.nl/fmt/intellijml.

One of the greatest challenges in software quality control is the efficient and effective measurement of maintainability. Thorough expert assessments are precise yet slow and expensive, whereas automated static analysis yields imprecise yet rapid feedback. Several machine learning approaches aim to integrate the advantages of both concepts. However, most prior studies did not adhere to expert judgment and predicted the number of changed lines as a proxy for maintainability, or were biased towards a small group of experts. In contrast, the present study builds on a manually labeled and validated dataset. Prediction is done using static code metrics where we found simple structural metrics such as the size of a class and its methods to yield the highest predictive power towards maintainability. Using just a small set of these metrics, our models can distinguish easy from hard to maintain code with an F-score of 91.3% and AUC of 82.3%. In addition, we perform a more detailed ordinal classification and compare the quality of the classification with the performance of experts. Here, we use the deviations between the individual expert’s ratings and the eventually determined consensus of all experts. In sum, our models achieve the same level of performance as an average human expert. In fact, the obtained accuracy and mean squared error outperform human performance. We hence argue that our models provide an automated and trustworthy prediction of software maintainability.

When students first learn to program, they often focus on functionality: does a program work? In an era where software volume and complexity increase exponentially, it is equally important that they learn to write code with style. Quality code starts with the building blocks for any program, its functions. A carefully chosen name is vital for program maintainability and manageability. The identifier is the most portable and concise way to summarize what the function does. What makes for the right choice? And can we automatically assess the quality of function names? Using natural language processing, we were able to create a probabilistic model to evaluate their clarity. Using functionality encodings, we attempt to learn the relationship between functions in different programs to improve their names. We analyzed a total of 3,900 programs tackling three novice programming tasks submitted by 1,300 students in CS1.

Kernel-bypass networking, which allows applications to circumvent the kernel and interface directly with NIC hardware, is one of the main tools for improving application network performance. However, allowing applications to circumvent the kernel makes it impossible to use tools (e.g., tcpdump) or impose policies (e.g., QoS and filters) that need to interpose on traffic sent by different applications running on a host. This makes maintainability and manageability a challenge for kernel-bypass applications. In response, we propose Kernel On-Path Interposition (KOPI), in which traditional kernel data-plane functionality is retained but implemented in a fully programmable SmartNIC. We hypothesize that KOPI can support the same tools and policies as the kernel stack while retaining the performance benefits of kernel bypass.

Discrete models such as cellular automata may be ported from one platform or language onto another to improve performances, for instance by rewriting legacy Matlab code into C++ or adding optimizations into a Python implementation. Although such transformations can offer benefits such as scalability or maintainability, they also have the risk of introducing bugs. While standard verification techniques can always be applied, this situation presents a unique opportunity since the two implementations can be directly compared based on their simulation runs. Although comparing average results across runs of a same configuration is a common practice, our paper shows that many bugs would not be detected at this aggregate level. We thus propose comparing implementations of cellular automata by analyzing their outputs as images. In this paper, we examine the detection of several implementation errors using five different techniques (supervised/unsupervised image processing, decision trees, random forests, or deep learning) across three different cellular automata models (forest fire, tumor, HIV). We show that in some models, random forests can detect 4 out of 5 erroneous runs, although the accuracy depends both on the model and on the nature of the errors.

Proprietary formats, missing analysis tools, the lack of continuous toolchains and their complexity itself impair the maintainability of industrial variability models, making them prone to defects. Also, automated analysis of variability models is still not common in industry. To gain detailed information about the defects in a proprietary variability model, it can be converted into a standardized feature model to apply automated analyses that expose present defects. In this paper, however, we exclusively handle and evaluate defects of type dead feature. Resolving those defects can be challenging, as their cause can be complex, especially for large feature models. To mitigate this, an explanation can be generated which identifies feature model parts that are involved in a specific defect. Although those explanations provide valuable information, handling a high number of defects at the same time remains a tedious task, as there is no prioritization that states which defect is to be handled first to achieve the best progress. In this paper, we propose a concept to automatically derive that prioritization by deriving a hyper explanation that aggregates the information provided by the explanations of all individual defects. Hyper explanations allow to derive a prioritization not only for defects but also for defect-creating constraints. We apply our concept to industrial variability models and discussed the results with domain experts, which leads to an unexpected conclusion: The models contain intentionally created dead features. We further evaluate the usage of intentionally dead features in industry and discuss how to handle them together with actual defects.

Maintainability is an important quality attribute of code, and so should be a key learning outcome for software engineering programmes. This raises the question of how to assess this learning outcome. In this practical report we describe how we exploited the code review mechanism provided by GitHub, the “pull request”, to assess students’ understanding of maintainability. It requires a slightly non-standard workflow by the students and a reporting tool to assemble the code review comments in a form suitable for assessment. We give the details of what we learned to make it work that should allow others to conduct similar kinds of assessment.

A GitHub profile is becoming an essential part of a developer's resume enabling HR departments to extract someone's expertise, through automated analysis of his/her contribution to open-source projects. At the same time, having clear insights on the technologies used in a project can be very beneficial for resource allocation and project maintainability planning. In the literature, one can identify various approaches for identifying expertise on programming languages, based on the projects that developer contributed to. In this paper, we move one step further and introduce an approach (accompanied by a tool) to identify low-level expertise on particular software frameworks and technologies apart, relying solely on GitHub data, using the GitHub API and Natural Language Processing (NLP)---using the Microsoft Language Understanding Intelligent Service (LUIS). In particular, we developed an NLP model in LUIS for named-entity recognition for three (3) .NET technologies and two (2) front-end frameworks. Our analysis is based upon specific commit contents, in terms of the exact code chunks, which the committer added or changed. We evaluate the precision, recall and f-measure for the derived technologies/frameworks, by conducting a batch test in LUIS and report the results. The proposed approach is demonstrated through a fully functional web application named RepoSkillMiner. Tool Links: Video, Code Repo, Application, Validation Dataset

Dependencies among software entities are the basis for many software analytic research and architecture analysis tools. Dynamically typed languages, such as Python, JavaScript and Ruby, tolerate the lack of explicit type references, making certain syntactic dependencies indiscernible in source code. We call these possible dependencies, in contrast with the explicit dependencies that are directly referenced in source code. Type inference techniques have been widely studied and applied, but existing architecture analytic research and tools have not taken possible dependencies into consideration. The fundamental question is, to what extent will these missing possible dependencies impact the architecture analysis? To answer this question, we conducted an empirical study with 105 Python projects, using type inference techniques to manifest possible dependencies. Our study revealed that the architectural impact of possible dependencies is substantial---higher than that of explicit dependencies: (1) file-level possible dependencies account for at least 27.93% of all file-level dependencies, and create different dependency structures than that of explicit dependencies only, with an average difference of 30.71%; (2) adding possible dependencies significantly improves the precision (0.52%~14.18%), recall(31.73%~39.12%), and F1 scores (22.13%~32.09%) of capturing co-change relations; (3) on average, a file involved in possible dependencies influences 28% more files and 42% more dependencies within architectural sub-spaces than a file involved in just explicit dependencies; (4) on average, a file involved in possible dependencies consumes 32% more maintenance effort. Consequently, maintainability scores reported by existing tools make a system written in these dynamic languages appear to be better modularized than it actually is. This evidence strongly suggests that possible dependencies have a more significant impact than explicit dependencies on architecture quality, that architecture analysis and tools should assess and even emphasize the architectural impact of possible dependencies due to dynamic typing.

The Internet of Things (IoT) is an increasingly evident reality in everyday life. IoT makes possible to interconnect physical objects through a heterogeneous computer network, creating new ways to manage infrastructures. In the IoT systems, smartphones have a fundamental role due to their computational capacity and resources. Nowadays, the major mobile devices have several types of sensors that can be used to monitor and collect data from the physical world, such as GPS, accelerometer, barometer, among others. Thus, IoT developers have used different cross-platform frameworks to improve their productivity and to make the software maintainability easily and fast. In this context, the goal of this work is to understand the performance impacts of some cross-platform frameworks for IoT application development. To do this, we built three versions of the same Android application of an IoT system using (1) Ionic, (2) React Native, and (3) Java, which uses some smartphone's sensors commonly used in IoT applications, such as GPS, WiFi, and BLE. For each resource and performance evaluation metric for each version of our application, we created a specific test-case to measure and to compare the analyzed cross-platform framework. Our results showed slight differences between the three versions of our IoT application in some analyzed metrics.

Simulation is a key tool for researching complex system behaviour. Agent-based simulation has been applied across domains, such as biology, health, economics and urban sciences. However, engineering robust, efficient, maintainable, and reliable agent-based simulations is challenging. We present a vision for engineering agent simulations comprising a family of domain-specific modelling languages (DSMLs) that integrates core software engineering, validation and simulation experimentation. We relate the vision to examples of principled simulation, to show how the DSMLs would improve robustness, efficiency, and maintainability of simulations. Focusing on how to demonstrate the fitness for purpose of a simulator, the envisaged approach supports bi-directional transparency and traceability between the original domain understanding to the implementation, interpretation of results and evaluation of hypotheses.

Developers frequently change the type of a program element and update all its references for performance, security, concurrency,library migration, or better maintainability. Despite type changes being a common program transformation, it is the least automated and the least studied. With this knowledge gap, researchers miss opportunities to improve the state of the art in automation for software evolution, tool builders do not invest resources where automation is most needed, language and library designers can-not make informed decisions when introducing new types, and developers fail to use common practices when changing types. To fill this gap, we present the first large-scale and most fine-grained empirical study on type changes in Java. We develop state-of-the-art tools to statically mine 297,543 type changes and their subsequent code adaptations from a diverse corpus of 129 Java projects containing 416,652 commits. With this rich data set we answer research questions about the practice of type changes. Among others, we found that type changes are actually more common than renaming,but the current research and tools for type changes are inadequate.Based on our extensive and reliable data, we present actionable,empirically-justified implications.

This paper presents the design, implementation, and usage details of ARCADE, an extensible workbench for supporting the recovery of software systems' architectures, and for evaluating architectural change and decay. ARCADE has been developed and maintained over the past decade, and has been deployed in a number of research labs as well as within three large companies. ARCADE's implementation is available at https://bitbucket.org/joshuaga/arcade and the video depicting its use at https://tinyurl.com/arcade-tool-demo.

The test code, just like production source code, is subject to bad design and programming practices, also known as smells. The presence of test smells in a software project may affect the quality, maintainability, and extendability of test suites making them less effective in finding potential faults and quality issues in the project's production code. In this paper, we introduce tsDetect, an automated test smell detection tool for Java software systems that uses a set of detection rules to locate existing test smells in test code. We evaluate the effectiveness of tsDetect on a benchmark of 65 unit test files containing instances of 19 test smell types. Results show that tsDetect achieves a high detection accuracy with an average precision score of 96% and an average recall score of 97%. tsDetect is publicly available, with a demo video, at: https://testsmells.github.io/

Over the last decade, Android has become the largest mobile platform, providing a huge and ever increasing amount of apps in the Google Play store. Since 2017, a growing number of Android apps have been written using the Kotlin programming language. Maintainability is an important attribute of software quality. It determines how well maintenance and code modification can be done. This is particularly important for Android apps that are frequently updated to meet changing user requirements.Several metrics can provide information about the maintainability of a system. They can be calculated with different analysis tools. This paper analyzes the maintainability of Kotlin applications. In particular, we investigate which metrics are relevant for the maintainability of Kotlin applications and to what extent analysis tools support the calculation of these metrics. Our results show that these tools are very limited with respect to the supported programming languages. Especially for Android applications written in Kotlin, the majority of maintainability metrics cannot be calculated with current tools.

In a microservice architecture, solutions are created by teams focused on specific domains and needs. They independently develop and deploy distributed services in the network. One characteristic of microservices is decentralized data management. Each microservice may use different data management technology which best fit its needs. Hence, it is an issue to integrate data of heterogenous microservices to come up with consolidate data views. Flexible and efficient solutions in this scenario are needed. This work is based on the use of a canonical data model as the mechanism for data integration in microservices. The canonical data model is the reference for query specifications and data integration. This work proposes and implements a microservice architecture based on this strategy and it is composed by nodes that intercommunicate through several mechanisms (e.g., SPARQL, GraphQL and JDBC queries, calls to REST services and proprietary APIs). The solution was analyzed in a proof of concept in a fictitious scenario but using real services available at DBPedia and Twitter. The evaluation goal was to qualitatively analyze the use of the architecture in the design, development and execution of microservices in order to identify the characteristics one should consider when using the canonical data model strategy. The evaluation employed the criteria of ISO/IEC 25010 model that most relate to the SOA challenges, which were: usability; performance; compatibility; and, maintainability. The identified advantages and disadvantages of using the architecture (i.e., the strategy) can be used by architects and developers to make their development decisions.

Developers often use the C preprocessor to handle variability and portability. However, many researchers and practitioners criticize the use of preprocessor directives because of their negative effect on code understanding, maintainability, and error proneness. This negative effect may lead to configuration-related code weaknesses, which appear only when we enable or disable certain configuration options. A weakness is a type of mistake in software that, in proper conditions, could contribute to the introduction of vulnerabilities within that software. Configuration-related code weaknesses may be harder to detect and fix than weaknesses that appear in all configurations, because variability increases complexity. To address this problem, we propose a sampling-based white-box technique to detect configuration-related weaknesses in configurable systems. To evaluate our technique, we performed an empirical study with 24 popular highly configurable systems that make heavy use of the C preprocessor, such as Apache Httpd and Libssh. Using our technique, we detected 57 configuration-related weaknesses in 16 systems. In total, we found occurrences of the following five kinds of weaknesses: 30 memory leaks, 10 uninitialized variables, 9 null pointer dereferences, 6 resource leaks, and 2 buffer overflows. The corpus of these weaknesses is a valuable source to better support further research on configuration-related code weaknesses.

Refactoring aims to remove bad smells and increase software maintainability by improving the software structure without changing its behavior. However, some studies show that refactoring tools may introduce new bad smells into the source code, but to the best of our knowledge, we have not been able to find a complete catalog that states the bad smells introduced from refactoring. To bridge this gap, this paper goal is to evaluate the impacts of refactoring on the detection of bad smells in open-source Java systems. Hence, we want to know if and when the automated refactoring removes or introduces bad smells.

Test smells are fragments of code that can affect the comprehensibility and the maintainability of the test code. Preventing, detecting, and correcting test smells are tasks that may require a lot of effort, and might not scale to large-sized projects when carried out manually. Currently, there are many tools available to support test smells detection. However, they usually do not provide neither a user-friendly interface nor automated support for refactoring the test code to remove test smells. In this work, we propose RAIDE, an open-source and IDE-integrated tool. RAIDE assists testers with an environment for automated detection of lines of code affected by test smells, as well as a semi-automated refactoring for Java projects using the JUnit framework.

Developers need to consistently improve the internal structural quality of a program to address its maintainability and possibly other non-functional concerns. Refactoring is the main practice to improve code quality. Typical refactoring factors, such as their complexity and explicitness (i.e., their self-affirmation), may influence its effectiveness in improving key internal code attributes, such as enhancing cohesion or reducing its coupling, complexity and size. However, we still lack an understanding of whether such concerns and factors play a role on improving the code structural quality. Thus, this paper investigates the relationship between complexity, explicitness and effectiveness of refactorings and non-functional concerns in four projects. We study four non-functional concerns, namely maintainability, security, performance, and robustness. Our findings reveal that complex refactorings indeed have an impactful effect on the code structure, either improving or reducing the code structural quality. We also found that both self-affirmed refactorings and non-functional concerns are usually accompanied by complex refactorings, but tend to have a negative effect on code structural quality. Our findings can: (i) help researchers to improve the design of empirical studies and refactoring-related tools, and (ii) warn practitioners on which circumstances their refactorings may cause a negative impact on code quality.

Previous studies demonstrated how code smells (i.e., symptoms of the presence of system degradation) impact the software maintainability. However, few studies have investigated which code smell types tend to co-occur in the source code. Moreover, it is not clear to what extent the removal of code smell co-occurrences -through refactoring operations - has a positive impact on quality attributes such as cohesion, coupling, inheritance, complexity, and size. We aim at addressing these gaps through an empirical study. By investigating the impact of the smells co-occurrences in 11 releases of 3 closed-source systems, we observe (i) which code smells tend to co-occur together, (ii) the impact of the removal of code smell co-occurrences on quality internal attributes before and after refactoring, and (iii) which are the most difficult co-occurrences to refactoring from the developers' perspective. Our results show that 2 types of code smell co-occurrences generally tend to co-occur. Moreover, we observed that the removal of code smells co-occurrences lead to a significant reduction in the complexity of the systems studied was obtained. Conversely, cohesion and coupling tend to get worse. We also found that two code smells cooccurrences (God Class-Long Method and Disperse Coupling-Long Method) as the most difficult to refactor indicating that attention is needed not to insert these anomalies in the source code. Based on our findings, we argue that further research is needed on the impact of code smells co-occurrences on internal quality attributes.

The Multi-objective Optimization Approach for Product Line Architecture Design (MOA4PLA) is the seminal approach that successfully optimizes Product Line Architecture (PLA) design using search algorithms. The tool named OPLA-Tool was developed in order to automate the use of MOA4PLA. Over time, the customization of the tool to suit the needs of new research and application scenarios led to several problems. The main problems identified in the original version of OPLA-Tool are environment configuration, maintainability and usability problems, and PLA design modeling and visualization. Such problems motivated the development of a new version of this tool: OPLA-Tool v2.0, presented in this work. In this version, those problems were solved by the source code refactoring, migration to a web-based graphical user interface (GUI) and inclusion of a new support tool for PLA modeling and visualization. Furthermore, OPLA-Tool v2.0 has new functionalities, such as new objective functions, new search operators, intelligent interaction with users during the optimization process, multi-user authentication and simultaneous execution of several experiments to PLA optimization. Such a new version of OPLA-Tool is an important achievement to PLA design optimization as it provides an easier and more complete way to automate this task.

Traditional parametric methods for assessing maintainability most often only consider the time to repair (TTR) as a single explanatory variable. However, maintainability design characteristics may have a significant influence on maintainability performance. A better model is needed to quantify the effect of maintainability design characteristics on TTR. This paper aims to develop a multiple linear regression model for maintainability analysis considering maintainability design attributes. A case study concerning the transmission box is used to demonstrate how the model can be applied in a real case. The result shows that the regression model provides a good fit concerning model assumptions and accounts for 97.03% of the variance in maintenance time, and the design attribute accessibility and disassembly/assembly have an about three times greater impact on the TTR than simplicity. By using the linear regression model, the MTTR estimation can be obtained for components with few samples, which are not possible in a frequentist analysis.

SBCARS 2020 - Maintenance in the context of SPLs is a topic of interest, and that still needs further investigation. There are several ways to evaluate the maintainability of a feature model (FM), one of which is a manual or automated analysis of quality measures. However, the use of measures does not allow to evaluate the FM quality as a whole, as each measure considers a specific characteristic of FM. In general, the measures have wide ranges of values and do not have a clear definition of what is appropriate and inappropriate. In this context, the goal of this work is to investigate the use of machine learning techniques to classify the feature model maintainability. The research questions investigated in the study were: (i) how could machine learning techniques aid to classify FMs maintainability; and, (ii) which FM classification model has the best accuracy and precision. In this work, we proposed an approach for FM maintainability classification using machine learning technics. For that, we used a dataset of 15 FM maintainability measures calculated for 326 FMs, and we used machine learning algorithms to clustering. After this, we used thresholds to evaluate the general maintainability of each cluster. With this, we built 5 maintainability classification models that have been evaluated with the accuracy and precision metrics.

Test code maintainability is a common concern in software testing. In order to achieve good maintainability, test methods should be clearly structured, well named, small in size, and, mainly, test code duplication should be avoided. Several strategies exist to avoid test code duplication, such as implicit setup and delegated setup. However, prior to applying these strategies, first it is necessary to identify the duplicate code, which can be a time-consuming task. To address this problem, we automate the identification of duplicate test code through the application of code similarity metrics. We propose a novel similarity metric, called Longest Common Contiguous Start Sub-Sequence (LCCSS), to identify refactoring candidates. LCCSS is a metric used to measure similarity between pairs of tests. The most similar pairs are reported as strong candidates to be refactored through the implicit setup strategy. We also develop a framework, called Roza, that can use different similarity metrics to identify test code duplication. An experiment shows that LCCSS and Simian, a clone detection tool, have both identified pairs of tests to be refactored through the implicit setup strategy with maximum precision in all the eleven standard recall levels. But, unlike Simian, LCCSS does not need to be calibrated for each project.

One of the key enablers of further growth of multi-level modeling will be the development of objective ways to allow multi-level modeling approaches to be compared to one another and to two-level modeling approaches. While significant strides have been made regarding qualitative comparisons, there is currently no adequate way to quantitatively assess to what extent a multi-level model may be preferable over another model with respect to high-level qualities such as understandability, maintainability, and control capacity. In this paper, we propose deep metrics, as an approach to quantitatively measure high-level model concerns of multi-level models that are of interest to certain stakeholders. Beyond the stated goals, we see deep metrics as furthermore supporting the comparison of modeling styles and aiding modelers in making individual design decisions. We discuss what makes a metric "depth-aware" so that it can appropriately capture multi-level model properties, and present two concrete proposals for metrics that measure high-level multi-level model qualities.

Eventual consistency between design and implementation is imperative for the quality and maintainability of software systems. Towards achieving this consistency, engineers can analyze the gaps between models and corresponding code to gain insights into differences between design and implementation. Due to the different levels of abstraction of the involved artifacts, this analysis is a complex task to automate. We study an industrial MBSE setting where we aim to provide model-code gap analysis between SysML system models and corresponding C/C++ code through structural consistency checks. To this end, we propose an extension of the OpenMBEE platform, to include code as one of the synchronized development artifacts in addition to models and documentation. In this paper, we outline our initial research idea to include code as a view in this platform and we propose to explicitly link the code to generated documentation, and thereby to the model.

They are many risk factors decreasing overall human physical and cognitive performance and increasing incidence of chronic diseases. It is very beneficial for any society to map, discuss and cope with these factors. This can be supported and evaluated by designing, developing, testing and using suitable self-management health systems. One of these systems is the BodyInNumbers exercise and wellness health strategy framework that allows experimenters to collect various heterogeneous health related data in a highly organized and efficient way. Thanks to its success and daily use, new requirements related to better security, scalability and maintainability of its architecture have emerged. The aim of this work is to present advances and changes in the architecture of the BodyInNumbers health strategy framework mainly focusing on new definition of user roles, optimization of the system deployment, and orchestration of the system components. As a proof of concept, a Kubernetes cluster prototype has been used to demonstrate the improved architectural solution.

In the last decade, the rise of hosted Software-as-a-Service (SaaS) application programming interfaces (APIs) across both academia and industry has exploded, and simultaneously, microservice architectures have replaced monolithic application platforms for the flexibility and maintainability they offer. These SaaS APIs rely on small, independent and reusable microservices that can be assembled relatively easily into more complex applications. As a result, developers can focus on their own unique functionality and surround it with fully functional, distributed processes developed by other specialists, which they access through APIs. The Tapis framework, a NSF funded project, provides SaaS APIs to allow researchers to achieve faster scientific results, by eliminating the need to set up a complex infrastructure stack. In this paper, we describe the best practices followed to create Tapis APIs using Python and the Stream API as an example implementation illustrating authorization and authentication with the Tapis Security Kernel, Tenants and Tokens APIs, leveraging OpenAPI v3 specification for the API definitions and docker containerization. Finally, we discuss our deployment strategy with Kubernetes, which is an emerging orchestration technology and the early adopter use cases of the Streams API service.

In object-oriented software development, several design patterns are used to design software to solve different problems. The Model-View-ViewModel or MVVM pattern is a design pattern that can be used to design structure of software which comprises three components. The Model component holds application data. The View component displays visual elements and controls on the screen. The ViewModel component is the intermediary between the Model and View and transforms model information for display on a view. The advantages of this pattern are that there is a clear separation between domain logic in the Model and the display on the View, and tests and maintenance of different components are facilitated. However, there are several developers in a software development team, and not all developers use the MVVM pattern. This makes the code not compliant with the pattern and affects code maintenance. To help developers to revise the code to comply with the MVVM pattern, this paper has studied the MVVM design pattern, summarized principles of the pattern, and proposed the criteria to detect pattern violation in Objective-C code. An automated tool has been developed to detect MVVM violation and report violation locations in the code so that developers can revise the code to follow the pattern. An experiment shows that the tool performs satisfactorily in pattern violation detection, compared with manual detection, with the precision of 0.81, recall of 0.77, and F1 of 0.79.

Test smells represent sub-optimal design or implementation solutions applied when developing test cases. Previous research has shown that these smells may decrease both maintainability and effectiveness of tests and, as such, researchers have been devising methods to automatically detect them. Nevertheless, there is still a lack of tools that developers can use within their integrated development environment to identify test smells and refactor them. In this paper, we present DARTS (Detection And Refactoring of Test Smells), an Intellij plug-in which (1) implements a state-of-the-art detection mechanism to detect instances of three test smell types, i.e., General Fixture, Eager Test, and Lack of Cohesion of Test Methods, at commit-level and (2) enables their automated refactoring through the integrated APIs provided by Intellij.

High-performance computing (HPC) systems keep increasing in size and bandwidth, thus requiring larger and higher-bandwidth interconnection networks. The race to exascale just exacerbated this trend. The resulting longer average distance and more links between modules makes the use of optical fiber mandatory. However, the system meets the challenge of cable packaging complexity, cable tolerance, and cable maintainability. Splitter cable, like multi-core fiber (MCF), is a new and cost-effective approach that has the potential to replace a bundle of fibers between any pairs of modules with a single cable, thus lowering the packaging complexity and enhancing the maintainability. To the best of our knowledge, we are the first to formally study the problem of building a cost-effective HPC network topology using multicore fiber. In this paper, a new diameter-3 topology is proposed, namely Bundlefly. It achieves a flexible tradeoff between intra-module radixes and inter-module radixes of routers with merely moderate radix to build a diameter-3 exascale interconnection network. It is suitable for the use of multi-core fiber for the requirement of inter-module bandwidth and cable packaging complexity. We analyze the properties of Bundlefly and present effective routing algorithms. We simulate and analyze the performance of Bundlefly against state-of-the-art topologies. The results show that Bundlefly with flexible configurations can achieve better performance than most existing topologies.

The growth of the video game market, the large proportion of games targeting mobile devices or streaming services, and the increasing complexity of video games trigger the availability of video game-specific tools to assess performance and maintainability problems. This paper proposes UnityLinter, a static analysis tool that supports Unity video game developers to detect seven types of bad smells we have identified as relevant in video game development. Such smell types pertain to performance, maintainability and incorrect behavior problems. After having defined the smells by analyzing the existing literature and discussion forums, we have assessed their relevance with a survey involving 68 participants. Then, we have analyzed the occurrence of the studied smells in 100 open-source Unity projects, and also assessed UnityLinter's accuracy. Results of our empirical investigation indicate that developers well-received performance- and behavior-related issues, while some maintainability issues are more controversial. UnityLinter is, in general, accurate enough in detecting smells (86%-100% precision and 50%-100% recall), and our study shows that the studied smell types occur in 39%-97% of the analyzed projects.

Technical debt is a metaphor that measures the additional effort needed to continue to add more features in a software due to its inherent decrease in code quality. Most software systems suffer from technical debt at some point so that dedicated tools and metrics have been developed to monitor such debt. Alongside tools, appropriate engineering practices must be put in place by the development team to keep that debt at an acceptable level. In this empirical study, we observed and surveyed Scrum development teams composed of experienced students in order to understand their quality-related processes on a year-long academic project. We found that (1) students do use static analysis tools of many forms, but their actual usage is limited due to time pressure; (2) retrospective and non-constraining feedback on code quality has little to no effect, even when given regularly during the course of the project; and (3) junior developers value composite quality indicators (e.g., maintainability, reliability in SonarQube), even if they do not fully understand their meaning. From our findings, we propose a series of recommendations, both technical and methodological, on how to train junior developers to understand and manage technical debt.

Preventing and reducing risk of hazards in a natural disaster like Earthquake is unavoidable hence, there are government agencies that specialized in reducing risks while conducting the search and rescue operations. The SnakeBotSaver is designed to assist with the penetration of the specific area before the deployment of the search and rescue team. The project can use as rescue equipment and response to the team if ever there is a possible sign of human life through catching the actual footage of the camera and the output in thermal sensor attached to the head of the snake. The whole system is programmed and maintained by the operating system and language of the Raspberry Pi. This study aims to provide the best assistance for the search and rescue team of the City Disaster Risk Reduction Management Office (CDRRMO) to minimize the manpower in penetrating the specific location that is affected by the aftermath of an earthquake. This study also aims to provide a snake robot for search and rescue of CDRRMO by planning, developing, implementing, and evaluating the system in terms of its functionality, reliability, efficiency, usability and maintainability. In concluding this study, the researchers attained a mean of 4.09 interpreted as acceptable based on Likert's Scale as a statistical tool used.

Recent1 years have seen a surge of research into new ways of analyzing software quality. Specifically, a set of studies has been devoted to the impact the architectural relations among files have on system maintainability and file bug-proneness. The literature has proposed a set of rules for determining recurring architectural design flaws that occur in most complex systems, are associated with bugs, and thus incur high maintenance costs. In the present paper we advocate for using machine learning as the means of refining the approach and revealing new patterns of architectural integrity violations. Having trained a machine learning model on the combination of structural and historical information acquired from the Tiki open source project, we have been able to replicate three of the six known types of architectural violations and discover one new type, the Reverse Unstable Interface pattern. The implication of our study is that machine learning can provide valuable insights into the problem and discover novel patterns which would help software analysts to pinpoint specific architectural problems that may be the root causes of elevated bug- and change-proneness.

In the safety-critical domain (e.g. transportation, nuclear, aerospace and automotive), large-scale embedded systems implemented using Programmable Logic Controllers (PLCs) are widely used to provide supervisory control. Software complexity metrics, such as code size and cyclomatic complexity, have been used in the software engineering community for predicting quality metrics such as maintainability, bug proneness and robustness. However, since there is no available approach and tool support for measuring software complexity of PLC programs, we developed a tool called TIQVA in an effort to measure complexity for this type of software. We show how to measure different software complexity metrics such as lines of code, cyclomatic complexity, and information flow for a popular PLC programming language named Function Block Diagram (FBD). We evaluate the tool using data provided by Bombardier Transportation from a Train Control Management System (TCMS). In addition, we report some empirical and industrial evidence showing how TIQVA can be used to provide some experimental evidence to support the use of these metrics to estimate testing effort for an industrial control software. The results from this evaluation indicate that other specific dimensions of PLC programs (e.g., function block relationships, block coupling and timing) could be used to improve the measurement of complexity for industrial embedded software.