Exploring Maintainability Assurance Research for Service- and Microservice-Based Systems: Directions and Differences

To ensure sustainable software maintenance and evolution, a diverse set of activities and concepts like metrics, change impact analysis, or antipattern detection can be used. Special maintainability assurance techniques have been proposed for service- and microservice-based systems, but it is difficult to get a comprehensive overview of this publication landscape. We therefore conducted a systematic literature review (SLR) to collect and categorize maintainability assurance approaches for service-oriented architecture (SOA) and microservices. Our search strategy led to the selection of 223 primary studies from 2007 to 2018 which we categorized with a threefold taxonomy: a) architectural (SOA, microservices, both), b) methodical (method or contribution of the study), and c) thematic (maintainability assurance subfield). We discuss the distribution among these categories and present different research directions as well as exemplary studies per thematic category. The primary finding of our SLR is that, while very few approaches have been suggested for microservices so far (24 of 223, ?11%), we identified several thematic categories where existing SOA techniques could be adapted for the maintainability assurance of microservices

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

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

A Decade of Code Comment Quality Assessment: A Systematic Literature Review

Code comments are important artifacts in software systems and play a paramount role in many software engineering (SE) tasks related to maintenance and program comprehension. However, while it is widely accepted that high quality matters in code comments just as it matters in source code, assessing comment quality in practice is still an open problem. First and foremost, there is no unique definition of quality when it comes to evaluating code comments. The few existing studies on this topic rather focus on specific attributes of quality that can be easily quantified and measured. Existing techniques and corresponding tools may also focus on comments bound to a specific programming language, and may only deal with comments with specific scopes and clear goals (e.g., Javadoc comments at the method level, or in-body comments describing TODOs to be addressed). In this paper, we present a Systematic Literature Review (SLR) of the last decade of research in SE to answer the following research questions: (i) What types of comments do researchers focus on when assessing comment quality? (ii) What quality attributes (QAs) do they consider? (iii) Which tools and techniques do they use to assess comment quality?, and (iv) How do they evaluate their studies on comment quality assessment in general? Our evaluation, based on the analysis of 2353 papers and the actual review of 47 relevant ones, shows that (i) most studies and techniques focus on comments in Java code, thus may not be generalizable to other languages, and (ii) the analyzed studies focus on four main QAs of a total of 21 QAs identified in the literature, with a clear predominance of checking consistency between comments and the code. We observe that researchers rely on manual assessment and specific heuristics rather than the automated assessment of the comment quality attributes

Towards Improving the Code Lexicon and its Consistency

RÉSUMÉ La compréhension des programmes est une activité clé au cours du développement et de la maintenance des logiciels. Bien que ce soit une activité fréquente—même plus fré- quente que l’écriture de code—la compréhension des programmes est une activité difficile et la difficulté augmente avec la taille et la complexité des programmes. Le plus souvent, les mesures structurelles—telles que la taille et la complexité—sont utilisées pour identifier ces programmes complexes et sujets aux bogues. Cependant, nous savons que l’information linguistique contenue dans les identifiants et les commentaires—c’est-à-dire le lexique du code source—font partie des facteurs qui influent la complexité psychologique des programmes, c’est-à-dire les facteurs qui rendent les programmes difficiles à comprendre et à maintenir par des humains. Dans cette thèse, nous apportons la preuve que les mesures évaluant la qualité du lexique du code source sont un atout pour l’explication et la prédiction des bogues. En outre, la qualité des identifiants et des commentaires peut ne pas être suffisante pour révéler les bogues si on les considère en isolation—dans sa théorie sur la compréhension de programmes par exemple, Brooks avertit qu’il peut arriver que les commentaires et le code soient en contradiction. C’est pourquoi nous adressons le problème de la contradiction et, plus généralement, d’incompatibilité du lexique en définissant un catalogue d’Antipatrons Linguistiques (LAs), que nous définissons comme des mauvaises pratiques dans le choix des identifiants résultant en incohérences entre le nom, l’implémentation et la documentation d’une entité de programmation. Nous évaluons empiriquement les LAs par des développeurs de code propriétaire et libre et montrons que la majorité des développeurs les perçoivent comme mauvaises pratiques et par conséquent elles doivent être évitées. Nous distillons aussi un sous-ensemble de LAs canoniques que les développeurs perçoivent particulièrement inacceptables ou pour lesquelles ils ont entrepris des actions. En effet, nous avons découvert que 10% des exemples contenant les LAs ont été supprimés par les développeurs après que nous les leur ayons présentés. Les explications des développeurs et la forte proportion de LAs qui n’ont pas encore été résolus suggèrent qu’il peut y avoir d’autres facteurs qui influent sur la décision d’éliminer les LAs, qui est d’ailleurs souvent fait par le moyen de renommage. Ainsi, nous menons une enquête auprès des développeurs et montrons que plusieurs facteurs peuvent empêcher les développeurs de renommer. Ces résultats suggèrent qu’il serait plus avantageux de souligner les LAs et autres mauvaises pratiques lexicales quand les développeurs écrivent du code source—par exemple en utilisant notre plugin LAPD Checkstyle détectant des LAs—de sorte que l’amélioration puisse se faire sur la volée et sans impacter le reste du code.----------ABSTRACT Program comprehension is a key activity during software development and maintenance. Although frequently performed—even more often than actually writing code—program comprehension is a challenging activity. The difficulty to understand a program increases with its size and complexity and as a result the comprehension of complex programs, in the best- case scenario, more time consuming when compared to simple ones but it can also lead to introducing faults in the program. Hence, structural properties such as size and complexity are often used to identify complex and fault prone programs. However, from early theories studying developers’ behavior while understanding a program, we know that the textual in- formation contained in identifiers and comments—i.e., the source code lexicon—is part of the factors that affect the psychological complexity of a program, i.e., factors that make a program difficult to understand and maintain by humans. In this dissertation we provide evidence that metrics evaluating the quality of source code lexicon are an asset for software fault explanation and prediction. Moreover, the quality of identifiers and comments considered in isolation may not be sufficient to reveal flaws—in his theory about the program understanding process for example, Brooks warns that it may happen that comments and code are contradictory. Consequently, we address the problem of contradictory, and more generally of inconsistent, lexicon by defining a catalog of Linguistic Antipatterns (LAs), i.e., poor practices in the choice of identifiers resulting in inconsistencies among the name, implementation, and documentation of a programming entity. Then, we empirically evaluate the relevance of LAs—i.e., how important they are—to industrial and open-source developers. Overall, results indicate that the majority of the developers perceives LAs as poor practices and therefore must be avoided. We also distill a subset of canonical LAs that developers found particularly unacceptable or for which they undertook an action. In fact, we discovered that 10% of the examples containing LAs were removed by developers after we pointed them out. Developers’ explanations and the large proportion of yet unresolved LAs suggest that there may be other factors that impact the decision of removing LAs, which is often done through renaming. We conduct a survey with developers and show that renaming is not a straightforward activity and that there are several factors preventing developers from renaming. These results suggest that it would be more beneficial to highlight LAs and other lexicon bad smells as developers write source code—e.g., using our LAPD Checkstyle plugin detecting LAs—so that the improvement can be done on-the-fly without impacting other program entities

Resource Allocation Modeling Framework to Refactor Software Design Smells

The domain to study design flaws in the software environment has created enough opportunity for the researchers. These design flaws i.e., code smells, were seen hindering the quality aspects of the software in many ways. Once detected, the segment of the software which was found to be infected with such a flaw has to be passed through some refactoring steps in order to remove it. To know about their working phenomenon in a better way, authors have innovatively talked about the smell detection mechanism using the NHPP modeling framework. Further the authors have also chosen to investigate about the amount of resources/efforts which should be allotted to various code smell categories. The authors have developed an optimization problem for the said purpose which is being validated on the real-life smell data set belonging to an open-source software system. The obtained results are in acceptable range and are justifying the applicability of the model

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