Detailed Overview of Software Smells

This document provides an overview of literature concerning software smells covering various dimensions of smells along with their corresponding references

Technical Debt Decision-Making Framework

Software development companies strive to produce high-quality software. In commercial software development environments, due to resource and time constraints, software is often developed hastily which gives rise to technical debt. Technical debt refers to the consequences of taking shortcuts when developing software. These consequences include making the system difficult to maintain and defect prone. Technical debt can have financial consequences and impede feature enhancements. Identifying technical debt and deciding which debt to address is challenging given resource constraints. Project managers must decide which debt has the highest priority and is most critical to the project. This decision-making process is not standardized and sometimes differs from project to project. My research goal is to develop a framework that project managers can use in their decision-making process to prioritize technical debt based on its potential impact. To achieve this goal, we survey software practitioners, conduct literature reviews, and mine software repositories for historical data to build a framework to model the technical debt decision-making process and inform practitioners of the most critical debt items

Technical Debt Decision-Making Framework

Software development companies strive to produce high-quality software. In commercial software development environments, due to resource and time constraints, software is often developed hastily which gives rise to technical debt. Technical debt refers to the consequences of taking shortcuts when developing software. These consequences include making the system difficult to maintain and defect prone. Technical debt can have financial consequences and impede feature enhancements. Identifying technical debt and deciding which debt to address is challenging given resource constraints. Project managers must decide which debt has the highest priority and is most critical to the project. This decision-making process is not standardized and sometimes differs from project to project. My research goal is to develop a framework that project managers can use in their decision-making process to prioritize technical debt based on its potential impact. To achieve this goal, we survey software practitioners, conduct literature reviews, and mine software repositories for historical data to build a framework to model the technical debt decision-making process and inform practitioners of the most critical debt items

Defining linguistic antipatterns towards the improvement of source code quality

Previous studies showed that linguistic aspect of source code is a valuable source of information that can help to improve program comprehension. The proposed research work focuses on supporting quality improvement of source code by identifying, specifying, and studying common negative practices (i.e., linguistic antipatterns) with respect to linguistic information. We expect the definition of linguistic antipatterns to increase the awareness of the existence of such bad practices and to discourage their use. We also propose to study the relation between negative practices in linguistic information (i.e., linguistic antipatterns) and negative practices in structural information (i.e., design antipatterns) with respect to comprehension effort and fault/change proneness. We discuss the proposed methodology and some preliminary results

Automatic Detection of GUI Design Smells: The Case of Blob Listener

International audienceGraphical User Interfaces (GUIs) intensively rely on event-driven programming: widgets send GUI events, which capture users' interactions, to dedicated objects called controllers. Controllers implement several GUI listeners that handle these events to produce GUI commands. In this work, we conducted an empirical study on 13 large Java Swing open-source software systems. We study to what extent the number of GUI commands that a GUI listener can produce has an impact on the change-and fault-proneness of the GUI listener code. We identify a new type of design smell, called Blob listener that characterizes GUI listeners that can produce more than two GUI commands. We show that 21 % of the analyzed GUI controllers are Blob listeners. We propose a systematic static code analysis procedure that searches for Blob listener that we implement in InspectorGuidget. We conducted experiments on six software systems for which we manually identified 37 instances of Blob listener. InspectorGuidget successfully detected 36 Blob listeners out of 37. The results exhibit a precision of 97.37 % and a recall of 97.59 %. Finally, we propose coding practices to avoid the use of Blob listeners

An exploratory study of the impact of software changeability

Antipatterns are poor design choices that make object-oriented systems hard to maintain by developers. In this study, we investigate if classes that participate in antipatterns are more change-prone than classes that do not. Specifically, we test the general hypothesis: classes belonging to antipatterns are not more likely than other classes to undergo changes, to be impacted when fixing issues posted in issue- tracking systems, and in particular to unhandled exceptions-related issues - a crucial problem for any software system. We detect 11 antipatterns in 13 releases of Eclipse and study the relations between classes involved in these antipatterns and classes change-, issue-, and unhandled exception-proneness. We show that, in almost all releases of Eclipse, classes with antipatterns are more change-, issue-, and unhandled-exception-prone than others. These results justify previous work on the specification and detection of antipatterns and could help focusing quality assurance and testing activities

Exploring the Relation Between Co-changes and Architectural Smells

The interplay between Maintainability and Reliability can be particularly complex and different kinds of trade-offs may arise when developers try to optimise for either one of these two qualities. To further understand how Maintainability and Reliability influence each other, we perform an empirical study using architectural smells and source code file co-changes as proxies for these two qualities, respectively. The study is designed using an exploratory multiple-case case study following well-know guidelines and using fourteen open source Java projects. Three different research questions are identified and investigated through statistical analysis. Co-changes are detected by using both a state-of-the-art algorithm and a novel approach. The three architectural smells selected are among the most important from the literature and are detected using open source tools. The results show that 50% of co-changes eventually end up taking part in an architectural smell. Moreover, statistical tests indicate that in 50% of the projects, files and packages taking part in smells are more likely to co-change than non-smelly files. Finally, co-changes were also found to appear before smells 90% of the times a smell and a co-change appear in the same file pair. Our findings show that Reliability is indirectly affected by low levels of Maintainability even at the architectural level. This is because low-quality components require more frequent changes by the developers, increasing chances to eventually introduce faults

Exploring and categorizing maintainability assurance research for service and microservice-based systems

Im Laufe des Softwarelebenszyklus eines Programms innerhalb einer sich ständig wechselnden Softwareumgebung ist es wahrscheinlich, dass dieses Programm regelmäßig gewartet werden muss. Wartungen kosten Geld und somit ist es wichtig, dass ebensolche Wartungen effizient und effektiv durchgeführt werden können. Im Laufe der Geschichte der Softwareentwicklung traten unter anderem zwei Architekturmuster hervor: Serviceorientierte Architektur und Microservices. Da diese Architekturmuster ein hohes Maß an Wartbarkeit versprechen, wurden viele Altsysteme hin zu diesen modernen Architekturen migriert. Es kann fatale Folgen für Unternehmen haben, wenn Änderungen an einem System nicht schnell, risikofrei und fehlerfrei umgesetzt werden können. Es wurden bereits viele Forschungsarbeiten bezogen auf die Wartbarkeit von serviceorientierter Architektur publiziert. Systeme basierend auf Microservices fanden jedoch, bezogen auf Wartbarkeitssicherung, nicht viel Beachtung. Sämtliche Forschungsarbeiten befinden sich verteilt auf viele Literaturdatenbanken, wodurch ein umfassender Überblick erschwert wird. Um einen solchen Überblick bereitzustellen, führten wir im Rahmen dieser Bachelorarbeit eine systematische Literaturstudie durch, die sich mit der Wartbarkeitssicherung von serviceorienter Architektur und Systemen basierend auf Microservices beschäftigt. Zur Durchführung dieser systematischen Literaturstudie entwickelten wir eine Reihe von relevanten Forschungsfragen sowie ein striktes Forschungsprotokoll. Aufbauend auf diesem Protokoll sammelten wir insgesamt 223 Forschungsarbeiten von verschiedenen Herausgebern. Diese Arbeiten wurden bezüglich ihres Inhalts zuerst in drei Gruppen von Kategorien unterteilt (architektonisch, thematisch und methodisch). Danach wurden die jeweils relevantesten Forschungsrichtungen aus jeder thematischen Kategorie herausgearbeitet und vorgestellt. Zum Abschluss wurden deutliche Unterschiede der in den Forschungsarbeiten präsentierten Inhalte in Bezug auf serviceorientierte Architektur und Microservice-basierte Systeme herausgearbeitet und dargestellt. Unsere Ergebnisse zeigten eine deutliche Unterrepräsentation von Forschungsarbeiten zur Wartbarkeitssicherung für Microservice-basierte Systeme. Während der Untersuchung der Kategorien konnten wir diverse Forschungsrichtungen innerhalb dieser feststellen. Ein Beispiel hierfür ist die Forschungsrichtung "change impact in business processes" in der Kategorie "Change Impact and Scenarios". Abschließend konnten wir einige Unterschiede bezogen auf die gesammelten Forschungsarbeiten zwischen Systemen basierend auf einer serviceorientierten Architektur und Systemen basierend auf Microservices feststellen. Ein solcher Unterschied kann zum Beispiel in der Kategorie "Antipatterns and Bad Smells" gefunden werden. Im Vergleich zu Forschungsarbeiten, welche sich auf serviceorientierte Architektur beziehen, beinhalten Forschungsarbeiten im Zusammenhang mit Systemen auf Basis von Microservices nur grundlegende Informationen zu Antipatterns, jedoch keine Herangehensweisen, um diese zu erkennen. Aufgrund unserer Ergebnisse schlagen wir einen stärkeren Fokus auf Forschung zur Wartbarkeitssicherung in Microservice-basierten Systemen vor. Mögliche zukünftige Forschungsarbeiten könnten überprüfen, ob Herangehensweisen zur Wartbarkeitssicherung von serviceorientierter Architektur auch bei Microservices anwendbar sind. Darüber hinaus schlagen wir die Durchführung von systematischen Literaturstudien vor, welche Themen wie "runtime adaptation", "testing" und "legacy migration" untersuchen, da diese Themen in unserer Literaturstudie ausgeschlossen wurden.It is very likely that software running in an everchanging environment needs to evolve at multiple points during its lifecycle. Because maintenance costs money, it is important for such tasks to be as effective and efficient as possible. During the history of software development service- and microservice-based architectures have emerged among other architectures. Since these architectures promise to provide a high maintainability, many legacy systems are or were migrated towards a service- or microservice-based architecture. In order to keep such systems running, maintenance is inevitable. While a lot of research has been published regarding maintainability assurance for service-based systems, microservice-based systems have not gotten a lot of attention. All published research is spread across several scientific databases which makes it difficult to get an extensive overview of existing work. In order to provide such overview of maintainability assurance regarding service- and microservice-based systems, we conducted a systematic literature review. To support our literature review, we developed a set of meaningful research questions and a rigid research protocol. Based on our protocol we collected a set of 223 different papers. These papers were first categorized into a threefold set of categories (architectural, thematical and methodical). After that, the most relevant research directions from each thematical category were extracted and presented. Lastly, we extracted and presented notable differences between approaches relating to service-oriented architecture or microservice-based systems. Our findings show a clear underrepresentation of maintainability assurance approaches suitable for microservice-based systems. We further discovered that regarding our formed categories, we could find several research directions such as change impact in business processes in "Change Impact and Scenarios". In the end, we could identify some differences between service- and microservice-based systems concerning approaches we retrieved in this thesis. A difference, for example was that in comparison with papers related to service-oriented architecture in "Antipatterns and Bad Smells", microservices related papers only contained basic information on antipatterns, but no approaches to detect them. Due to our findings we suggest a higher participation in research regarding maintainability assurance for microservice-based systems. Possible future work in this area could include further research on the applicability of service-oriented maintainability assurance approaches or techniques in microservice-based systems. Furthermore, future researchers could conduct follow-up literature reviews and investigate topics such as runtime adaptation, testing and legacy migration, since we excluded such topics from this thesis

Bad Droid! An in-depth empirical study on the occurrence and impact of Android specific code smells

Knowing the impact of bad programming practices or code smells has led researchers to conduct numerous studies in software maintenance. Most of the studies have defined code smells as bad practices that may affect the quality of the software. However, most of the existing research is heavily focused on detecting traditional code smells and less focused on mobile application specific Android code smells. Presently, there is a few papers that focus on android code smells - a catalog for Android code smells. This catalog defines 30 Android specific code smell that may impact maintainability of an app. In this research, we plan to introduce a detector tool called \textit{BadDroidDetector} for Android code smells that can detect 13 code smells from the catalog. We will also conduct an empirical study to know the distribution of 13 smell that we detect and know the severity of these smells