Search

Code comprehension is crucial in software maintenance activities, though it can be hindered by misunderstandings and confusion patterns, namely, atoms of confusion. They are small pieces of code using specific programming language constructs, such as Conditional Operators and Comma Operators. A previous study showed that these atoms of confusion impact developers’ performance, i.e., time and accuracy, and increase code misunderstandings. However, empirical knowledge of the impact of such atoms on code comprehension is still scarce, especially when it comes to analyzing that impact on developers’ visual attention. The present study evaluates whether developers misunderstand the code in the presence of atoms of confusion with an eye tracker. For this purpose, we measure the tasks’ completion time, the accuracy of the answers, and analyze the distribution of visual attention. We conducted a controlled experiment with 30 students and software practitioners. We ask the subjects to specify the output of three tasks with atoms and three without atoms randomly assigned using a Latin Square design. We use an eye-tracking camera to detect the visual attention of the participants while solving the tasks. From an aggregated perspective, we observed an increase of 43.02% in time and 36.8% in gaze transitions in code snippets with atoms. For accuracy, no statistically significant difference was observed. We also confirm that the regions that receive most of the eye attention were theregions with atoms. Our findings reinforce that atoms hinder developers’ performance and comprehension. So, developers should avoid writing code with them.

Responding to change over following a plan is one of the Agile Manifesto’s values. According to its original perspective, development teams should embrace changes due to a better understanding of the business domain or about the users’ needs. This kind of change is well understood and explored by practitioners and researchers. However, the issue of how development teams embrace changes due to unexpected, severe, and atypical external events (like the ones we are facing during COVID-19) have not been fully discussed. In this paper, we present our experience in managing the expectations and changing the development methods to mitigate the risks of carrying out a research and development project (named Virtual Social Office-VSO) during a pandemic time. To this end, we report on an observational study that explains the main differences between the procedures we expected to follow before the pandemic and the procedures we are following. We also present the percep- tions of both stakeholder and development teams about the impact of COVID-19 on VSO development. Although the development team quickly adapted itself to work from home, we observed some impact on the development plans. In particular, trying to reconcile the trade-offs between completeness and the tight schedule for the first release was a challenge, since we depended on different partners to collect the information that we need to make available in a mobile application (app) that corresponds to one of the VSO project outcomes. According to one stakeholder, the initial effort to design and prototype the VSO app (using the Design Thinking approach) before the start of the pandemic, has been considered essential to mitigate part of the threats that arose due to the COVID-19. We discuss part of these threats in this paper and the actions we have been taking to mitigate them. In addition, according to members of the development team, working remotely presents both challenges (e.g., adapt to a new routine, prepare a comfortable place, isolation feelings), and benefits (e.g., working hours flexibility, less distraction from co-workers)., {"references":["Titan M Alon, Matthias Doepke, Jane Olmstead-Rumsey, and Michele Tertilt. 2020. The impact of COVID-19 on gender equality. Technical Report. National Bureau of Economic Research.","Roy M Anderson, Hans Heesterbeek, Don Klinkenberg, and T Déirdre Hollingsworth. 2020. How will country-based mitigation measures influence the course of the COVID-19 epidemic? The Lancet 395, 10228 (2020), 931–934.","Lingfeng Bao, Tao Li, Xin Xia, Kaiyu Zhu, Hui Li, and Xiaohu Yang. 2020. How does Working from Home Affect Developer Productivity? - A Case Study of Baidu During COVID-19 Pandemic. CoRR abs/2005.13167 (2020), 1–11.","Louis-Philippe Béland, Abel Brodeur, and Taylor Wright. 2020. The short-term economic consequences of Covid-19: exposure to disease, remote work and government response. University of Ottawa - Department of Economics; IZA Institute of Labor Economics 13159 (2020), 1–92.","Angel Belzunegui-Eraso and Amaya Erro-Garcés. 2020. Teleworking in the Context of the Covid-19 Crisis. Sustainability 12, 9 (2020), 3662.","Kelly D Blake, Robert J Blendon, and Kasisomayajula Viswanath. 2010. Employ- ment and compliance with pandemic influenza mitigation recommendations. Emerging infectious diseases 16, 2 (2010), 212.","M Bruce and PA Pereira. 2019. Microservices in Action. Manning Publications Co., 978-1617294457.","Scott Chacon and Ben Straub. 2014. Pro Git (2nd ed.). Apress, USA.","Bonnie Eisenman. 2016. Learning React Native: Building Native Mobile Apps with JavaScript (1st ed.). O'Reilly Media, Inc., B076PWRYSS.","Paul Ralph et al. 2020. Pandemic Programming: How COVID-19 affects software developers and how their organizations can help. CoRR abs/2005.01127 (2020), 1–32.","Robert Feldt and Thomas Zimmermann. 2020. ESE Special Issue on COVID-19 and Software Engineering.","LucianoA.Garcia,EdsonOliveiraJr,GislaineC.L.Leal,andMarceloMorandini. 2020. On the Adaptations of the Scrum Framework Software Development Events: Literature and Practitioners Analysis using Feature Models. In Proceedings of the 22nd International Conference on Enterprise Information Systems, ICEIS 2020, Prague, Czech Republic, May 5-7, 2020, Volume 2. SCITEPRESS, 978-989-758-423-7, 416–423. https://doi.org/10.5220/0009578904160423","JenniferHehn,DanielMéndez,FalkUebernickel,WalterBrenner,andManfred Broy. 2020. On Integrating Design Thinking for Human-Centered Requirements Engineering. IEEE Softw. 37, 2 (2020), 25–31.","Hadi Hemmati, Sarah Nadi, Olga Baysal, Oleksii Kononenko, Wei Wang, Reid Holmes, and Michael W. Godfrey. 2013. The MSR cookbook: mining a decade of research. In Proceedings of the 10th Working Conference on Mining Software Repositories, MSR '13, San Francisco, CA, USA, May 18-19, 2013, Thomas Zimmer- mann, Massimiliano Di Penta, and Sunghun Kim (Eds.). IEEE Computer Society, https://doi.org/10.1109/MSR.2013.6624048,343–352. https://doi.org/10.1109/MSR. 2013.6624048","Siw Elisabeth Hove and Bente Anda. 2005. Experiences from Conducting Semi- structured Interviews in Empirical Software Engineering Research. In IEEE MET- RICS. IEEE Computer Society, 10.1109/METRICS.2005.24, 23.","James Lewis and Martin Fowler. 2014. Microservices. https://martinfowler.com/ articles/microservices.html","Ting-Peng Liang, Yu-Wen Wang, and Ping-Ju Wu. 2013. A System for Service Blueprint Design. In ICSSI. IEEE Computer Society, 10.1109/ICSSI.2013.52, 252– 253.","Verne W Loose, Vanessa N Vargas, Drake E Warren, Shirley J Starks, Theresa J Brown, and Braeton J Smith. 2010. Economic and policy implications of pandemic influenza. Report SAND2010-1910, Sandia National Laboratories, Albuquerque, New Mexico March 1910 (2010), 1–22.","Terri Rebmann. 2009. Infectious disease disasters: bioterrorism, emerging in- fections, and pandemics. APIC text of infection control and epidemiology. 3rd ed. Washington, DC: Association for Professionals in Infection Control and Epidemiology, Inc 1 (2009), 1–22.","Ken Schwaber. 2004. Agile Project Management with Scrum. Microsoft Press, USA.","Daniel Spurk and Caroline Straub. 2020. Flexible employment relationships and careers in times of the COVID-19 pandemic.","Craig Walls. 2016. Spring Boot in Action (1st ed.). Manning Publications Co., USA."]}

Due to the popularization of Android and the full range of applications (apps) targeting this platform, many security issues have emerged, attracting researchers and practitioners’ attention. As such, many techniques for addressing security Android issues have emerged, including approaches for mining sandboxes using dynamic analysis tools (i.e., automated testing tools). Undoubtedly, the resulting sandboxes’ efficiency depends on the test case generation tools used in the mining procedures. Previous research studies have compared Android test case generation tools for this specific goal. However, it is difficult to increment the research in this field because reproducing these previous empirical studies is a challenging and time-consuming task. This difficulty occurs because it is necessary to integrate test generation tools that often require different and conflicting versions of the Android platform, programming languages (e.g., Python 2 and Python 3), and software libraries. To mitigate this issue, in this paper we present DroidXP, a software infrastructure that allows researchers (and tools developers) to integrate and compare test case generation tools for mining sandboxes. We evaluated DroidXP through a reproduction study of previous research work, though considering additional test case generation tools. Our experiment suggests that DroidXP simplifies the comparison of existing tools for mining sandboxes, and revealed that Sapienz outperforms the other test case generation tools—regardless of the Monkey tool had presented the highest code coverage in our study.

Maintaining complex software systems is a timeconsuming and challenging task. Practitioners must have a general understanding of the system’s decomposition and how the system’s developers have implemented the software features (probably cutting across different modules). Re-engineering practices are imperative to tackle these challenges. Previous research has shown the benefits of using software module clustering (SMC) to aid developers during re-engineering tasks (e.g., revealing the architecture of the systems, identifying how the concerns are spread among the modules of the systems, recommending refactorings, and so on). Nonetheless, although the literature on software module clustering has substantially evolved in the last 20 years, there are just a few tools publicly available. Still, these available tools do not scale to large scenarios, in particular, when optimizing multi-objectives. In this paper we present the Draco Clustering Tool (DCT), a new software module clustering tool. DCT design decisions make multi-objective software clusterization feasible, even for software systems comprising up to 1,000 modules. We report an empirical study that compares DCT with other available multi-objective tool (HD-NSGA-II), and both DCT and HD-NSGA-II with mono-objective tools (BUNCH and HD-LNS). We evidence that DCT solves the scalability issue when clustering medium size projects in a multi-objective mode. In a more extreme case, DCT was able to cluster Druid (an analytics data store) 221 times faster than HD-NSGA-II.

Context: In a seminal work, Ball et al. [1] investigate if the information available in version control systems could be used to predict defect density, arguing that practitioners and researchers could better understand errors "if [our] version control system could talk". In the meanwhile, several research works have reported that conflict merge resolution is a time consuming and error-prone task, while other contributions diverge about the correlation between co-change dependencies and defect density. Problem: The correlation between conflicting merge scenarios and bugs has not been addressed before, whilst the correlation between co-change dependencies and bug density has been only investigated using a small number of case studies—which can compromise the generalization of the results. Goal: To address this gap in the literature, this paper presents the results of a comprehensive study whose goal is to understand whether or not (a) conflicting merge scenarios and (b) co-change dependencies are good predictors for bug density. Method: We first build a curated dataset comprising the source code history of 29 popular Java Apache projects and leverage the SZZ algorithm to collect the sets of bug-fixing and bug-introducing commits. We then combine the SZZ results with the set of past conflicting merge scenarios and co-change dependencies of the projects. Finally, we use exploratory data analysis and machine learning models to understand the strength of the correlation between conflict resolution and co-change dependencies with defect density. Findings: (a) conflicting merge scenarios are not more prone to introduce bugs than regular commits, (b) there is a negligible to a small correlation between co-change dependencies and defect density—contradicting previous studies in the literature.

The effect of gender diversity in open source communities has gained increasing attention from practitioners and researchers. For instance, organizations such as the Python Software Foundation and the OpenStack Foundation started actions to increase gender diversity and promote women to top positions in the communities. Although the general underrepresentation of women (a.k.a. horizontal segregation) in open source communities has been explored in a number of research studies, little is known about the vertical segregation in open source communities -- which occurs when there are fewer women in high-level positions. To address this research gap, in this paper we present the results of a mixed-methods study on gender diversity and work practices of core developers contributing to open-source communities. In the first study, we used mining-software repositories procedures to identify the core developers of 711 open source projects, in order to understand how common are women core developers in open source communities and characterize their work practices. In the second study, we surveyed the women core developers we identified in the first study to collect their perceptions of gender diversity and gender bias they might have observed while contributing to open source systems. Our findings show that open source communities present both horizontal and vertical segregation (only 2.3% of the core developers are women). Nevertheless, differently from previous studies, most of the women core developers (65.7%) report never having experienced gender discrimination when contributing to an open source project. Finally, we did not note substantial differences between the work practices among women and men core developers. We reflect on these findings and present some ideas that might increase the participation of women in open source communities., Preprint of our paper published at ESEM 2020

Static analysis tools are frequently used to detect common programming mistakes or bad practices. Yet, the existing literature reports that these tools are still underused in the industry, which is partly due to (1) the frequent high number of false positives generated, (2) the lack of automated repairing solutions, and (3) the possible mismatches between tools and workflows of development teams. In this study we explored the question: “How could a bot-based approach allow seamless integration of static analysis tools into developers' workflows?” To this end we introduce C-3PR, an event-based bot infrastructure that automatically proposes fixes to static analysis violations through pull requests (PRs). We have been using C-3PR in an industrial setting for a period of eight months. To evaluate C-3PR usefulness, we monitored its operation in response to 2179 commits to the code base of the tracked projects. The bot autonomously executed 201346 analyses, yielding 610 pull requests. Among them, 346 (57%) were merged into the projects' code bases. We observed that, on average, these PRs are evaluated faster than general-purpose PRs (2.58 and 5.78 business days, respectively). Accepted transformations take even shorter time (1.56 days). Among the reasons for rejection, bugs in C-3PR and in the tools it uses are the most common ones. PRs that require the resolution of a merge conflict are almost always rejected as well. We also conducted a focus group to assess how C-3PR affected the development workflow. We observed that developers perceived C-3PR as efficient, reliable, and useful. For instance, the participants mentioned that, given the chance, they would keep using C-3PR. Our findings bring new evidence that a bot-based infrastructure could mitigate some challenges that hinder the wide adoption of static analysis tools.

Background: The Java programming language version eighth introduced a number of features that encourage the functional style of programming, including the support for lambda expressions and the Stream API. Currently, there is a common wisdom that refactoring a legacy code to introduce lambda expressions, besides other potential benefits, simplifies the code and improves program comprehension. Aims: The purpose of this paper is to investigate this belief, conducting an in depth study to evaluate the effect of introducing lambda expressions on program comprehension. Method: We conduct this research using a mixed-method study. First, we quantitatively analyze 66 pairs of real code snippets, where each pair corresponds to the body of a method before and after the introduction of lambda expressions. We computed two metrics related to source code complexity (number of lines of code and cyclomatic complexity) and two metrics that estimate the readability of the source code. Second, we conduct a survey with practitioners to collect their perceptions about the benefits on program comprehension, with the introduction of lambda expressions. The practitioners evaluate a number between three and six pairs of code snippets, to answer questions about possible improvements. Results: We found contradictory results in our research. Based on the quantitative assessment, we could not find evidences that the introduction of lambda expressions improves software readability--one of the components of program comprehension. Differently, our findings of the qualitative assessment suggest that the introduction of lambda expression improves program comprehension. Implications: We argue in this paper that one can improve program comprehension when she applies particular transformations to introduce lambda expressions (e.g., replacing anonymous inner classes by lambda expressions). In addition, the opinion of the participants shine the opportunities in which a transformation for introducing lambda might be advantageous. This might support the implementation of effective tools for automatic program transformations. Finally, our results suggest that state-of-the-art models for estimating program readability are not helpful to capture the benefits of a program transformation to introduce lambda expressions.

Static code analysis tools such as FindBugs and SonarQube are widely used on open-source and industrial projects to detect a variety of issues that may negatively affect the quality of software. Despite these tools' popularity and high level of automation, several empirical studies report that developers normally fix only a small fraction (typically, less than 10% [1]) of the reported issues—so-called "warnings". If these analysis tools could also automatically provide suggestions on how to fix the issues that trigger some of the warnings, their feedback would become more actionable and more directly useful to developers. In this work, we investigate whether it is feasible to automatically generate fix suggestions for common warnings issued by static code analysis tools, and to what extent developers are willing to accept such suggestions into the codebases they're maintaining. To this end, we implemented a Java program transformation technique that fixes 11 distinct rules checked by two well-known static code analysis tools (SonarQube and SpotBugs). Fix suggestions are generated automatically based on templates, which are instantiated in a way that removes the source of the warnings; templates for some rules are even capable of producing multi-line patches. We submitted 38 pull requests, including 920 fixes generated automatically by our technique for various open-source Java projects, including the Eclipse IDE and both SonarQube and SpotBugs tools. At the time of writing, project maintainers accepted 84% of our fix suggestions (95% of them without any modifications). These results indicate that our approach to generating fix suggestions is feasible, and can help increase the applicability of static code analysis tools.

Background: Object-Relational Mapping (ORM) frameworks are regarded as key tools in the software engineer arsenal. However, developers often face ORM problems, and the solution to these problems are not always clear. To mitigate these problems, we created a framework that detects and reports a family of ORM problems. Aims: The aim of this work is to assess how practitioners perceive our framework, the problems, they face, and the eventual points for improvements. Method: We first report an observational study in which we curated 12 ORM-related problems, which are implemented in our framework. We then conducted a developer experience (DX) study with 13 developers (10 well-experienced and 3 students) to assess their experience with our framework to implement six ORM-related tasks. Results: All participants agreed that our framework helped them to finish the programming tasks. The participants perceived that our framework eases the ORM modeling, has precise error messages, and employs ORM best practices. As a shortcoming, however, one participant mentioned that some custom annotations are not very intuitive. Conclusions: Our findings indicate that developers are willing to use frameworks that catch ORM problems, which create opportunities for new research and tools.

The use of automatic static analysis tools (ASATs) has gained increasing attention in the last few years. Even though available research have already explored ASATs issues and how they are fixed, these studies rely on revisions of the software, instead of mining real usage of these tools and real issue reports. In this paper we contribute with a comprehensive, multi-method study about the usage of SonarQube (a popular static analysis tool), mining 421,976 issues from 246 projects in four different instance of SonarQube: two hosted in open-source communities (Eclipse and Apache) and two hosted in Brazilian government institutions (Brazilian Court of Account (TCU) and Brazilian Federal Police (PF)). We first surveyed team leaders of the analyzed projects and found that they mostly consider ASATs warning messages as relevant for overall software improvement. Second, we found that both Eclipse and TCU employ highly customized instance of SonarQube, with more than one thousand distinct checkers-though just a subset of these checkers actually led to issues' reports. Surprisingly, we found a low resolution rate per project in all organizations-on average, 13% of the issues have been solved in the systems. We conjecture that just a subset of the checkers reveal real design and coding flaws, and this might artificially increase the technical debt of the systems. Nevertheless, considering all systems, there is a central tendency (median) of fixing issues after 18.99 days they had been reported, faster than the period for fixing bugs as reported in previous studies.

Static code analysis tools such as FindBugs and SonarQube are widely used on open-source and industrial projects to detect a variety of issues that may negatively affect the quality of software. Despite these tools’ popularity and high level of automation, several empirical studies report that developers normally fix only a small fraction (typically, less than 10% (Marcilio et al., 2019) of the reported issues—so-called “warnings”. If these analysis tools could also automatically provide suggestions on how to fix the issues that trigger some of the warnings, their feedback would become more actionable and more directly useful to developers. In this work, we investigate whether it is feasible to automatically generate fix suggestions for common warnings issued by static code analysis tools, and to what extent developers are willing to accept such suggestions into the codebases they are maintaining. To this end, we implemented SpongeBugs, a Java program transformation technique that fixes 11 distinct rules checked by two well-known static code analysis tools (SonarQube and SpotBugs). Fix suggestions are generated automatically based on templates, which are instantiated in a way that removes the source of the warnings; templates for some rules are even capable of producing multi-line patches. Based on the suggestions provided by SpongeBugs, we submitted 38 pull requests, including 946 fixes generated automatically by our technique for various open-source Java projects, including Eclipse UI – a core component of the Eclipse IDE – and both SonarQube and SpotBugs. Project maintainers accepted 87% of our fix suggestions (97% of them without any modifications). We further evaluated the applicability of our technique on software written by students and on a curated collection of bugs. All results indicate that our approach to generating fix suggestions is feasible, flexible, and can help increase the applicability of static code analysis tools.

Background. DevOps is a set of practices and cultural values that aims to reduce the barriers between development and operations teams. Due to its increasing interest and imprecise definitions, existing research works have tried to characterize DevOps---mainly using a set of concepts and related practices. Aims. Nevertheless, little is known about thepractitioners practitioners' understanding about successful paths for DevOps adoption. The lack of such understanding might hinder institutions to adopt DevOps practices. Therefore, our goal here is to present a theory about DevOps adoption, highlighting the main related concepts that contribute to its adoption in industry. Method. Our work builds upon Classic Grounded Theory. We interviewed practitioners that contributed to DevOps adoption in 15 companies from different domains and across 5 countries. We empirically evaluate our model through a case study, whose goal is to increase the maturity level of DevOps adoption at the Brazilian Federal Court of Accounts, a Brazilian Government institution.Results. This paper presents a model to improve both the understanding and guidance of DevOps adoption. The model increments the existing view of DevOps by explaining the role and motivation of each category (and their relationships) in the DevOps adoption process. We organize this model in terms of DevOps enabler categories and DevOps outcome categories. We provide evidence that collaboration is the core DevOps concern, contrasting with an existing wisdom that implanting specific tools to automate building, deployment, and infrastructure provisioning and management is enough to achieve DevOps. Conclusions. Altogether, our results contribute to (a) generating an adequate understanding of DevOps, from the perspective of practitioners; and (b) assisting other institutions in the migration path towards DevOps adoption., 11 pages

Collaborative development approaches (e.g., pair programming, coding dojo, and hackathons) have gained increasing attention in recent years, mostly because they help to share knowledge during software development activities and might shorten development cycles and increase the quality of software products. Collaborative development approaches bring also the potential benefit to contribute to learning activities. For instance, novices might participate on collaborative development sessions in order to learn new development practices, tools, and techniques used in a software development project. Besides these potential benefits, little is known about the perception of students engaged in collaborative development efforts. Therefore, in this paper we investigate whether or not the engagement of students in collaborative development efforts contributes to the learning process of software development practices and techniques, as well as the perceived benefits and challenges related to collaborative software development activities. To this end, we first performed several of coding dojo sessions during a period of 18 months. These development sessions have been conducted within the context of a real software modernization effort, which aims to modernize two enterprise systems of the Brazilian Army. After that, we carried out a qualitative study where the participants (students, software developers, and software architects) answered a survey, in order to understand the learning benefits of using coding dojo in software development activities. The results so far are encouraging. Coding Dojos allowed professors and software architects to seamless share their experience in software development with the students. According to the answers, the methodology created a better environment for the team, allowing better discussions and ideas to be shared and implemented. This has helped the team members to solve problems easier than by themselves, bringing additional benefits, such as steep the learning curve in programming languages, usage of development tools, understanding the requirements, and code refactoring.

Although monolithic applications are still the modus operandi of many software systems, the microservices architecture, which favors small and independent applications, is gaining increasing popularity. This is part due to its claimed benefits, which includes better scalability, productivity, and maintainability. However, little is known about how developers and architects perceive the benefits of migrating from monolithic applications to microservices, and what are the challenges towards achieving them. In this paper we discuss the motivation, benefits, and challenges related to the migration from monolithic enterprise architectures to a microservices based architecture. We report several lessons learned that arose from a two years process faced by three Brazilian Government Institutions. We also cross-validate these findings with a survey conducted with 13 practitioners in the studied companies. The results of our investigation highlight some evidence that the adoption of microservices brought several benefits for these institutions, such as (a) reducing development time and risks related to deployment activities and (b) increasing the opportunities to experiment with different technologies and development models (such as hackathons). However, our observations reveal that the adoption of microservices is still a challenging task, mainly because it not only demands the understanding of new techniques and tools, but it also increases the need to automate tasks related to software deployment and software monitoring. This study is particularly relevant for institutions interested in adopting a software architecture based on microservices, and we are currently sharing our experiences with other institutions.

Software systems change frequently over time, either due to new business requirements or technology pressures. Programming languages evolve in a similar constant fashion, though when a language release introduces new programming constructs, older constructs and idioms might become obsolete. The coexistence between newer and older constructs leads to several problems, such as increased maintenance efforts and steeper learning curve for developers. In this paper we present a RASCAL Java transformation library that evolves legacy systems to use more recent programming language constructs (such as multi-catch and lambda expressions). In order to understand how relevant automatic software rejuvenation is, we submitted 2462 transformations to 40 open source projects via the GitHub pull request mechanism. Initial results show that simple transformations, for instance the introduction of the diamond operator, are more likely to be accepted than transformations that change the code substantially, such as refactoring enhanced for loops to the newer functional style.

Service-oriented computing has emerged as an effective approach for integrating business (and systems) that might spread throughout different organizations. A service is a unit of logic modularization that hides implementation details using well-defined contracts. However, existing languages for contract specification in this domain present several limitations. For instance, both WSDL and Swagger use language-independent data formats (XML and JSON) that are not suitable for specifying contracts and often lead to heavyweight specifications. Interface description languages, such as CORBA IDL and Apache Thrift, solve this issue by providing specific languages for contract specifications. Nevertheless, these languages do not target to the REST architectural style and lack support for language extensibility. In this paper we present the design and implementation of NeoIDL, an extensible domain specific language and program generator for writing REST based contracts that are further translated into service’s implementations. In addition, we also present a systematic evaluation of our approach from different perspectives, which involved the implementation of different services using NeoIDL from the domain of Command & Control. In particular, we found initial evidences that shows that NeoIDL can contribute: (i) to bring return on investment with respect to the design and development of NeoIDL, after the implementation of 4 to 7 services; and (ii) to reduce significantly the number of lines of specification when compared to an existing service specification language such as Swagger.

Modularity benefits, including the independent maintenance and comprehension of individual modules, have been widely advocated. However, empirical assessments to investigate those benefits have mostly focused on source code, and thus, the relevance of modularity to earlier artifacts is still not so clear (such as requirements and design models). In this paper, we use a multimethod technique, including designed experiments, to empirically evaluate the benefits of modularity in the context of two approaches for specifying product line use case scenarios: PLUSS and MSVCM. The first uses an annotative approach for specifying variability, whereas the second relies on aspect-oriented constructs for separating common and variant scenario specifications. After evaluating these approaches through the specifications of several systems, we find out that MSVCM reduces feature scattering and improves scenario cohesion. These results suggest that evolving a product line specification using MSVCM requires only localized changes. On the other hand, the results of six experiments reveal that MSVCM requires more time to derive the product line specifications and, contrasting with the modularity results, reduces the time to evolve a product line specification only when the subjects have been well trained and are used to the task of evolving product line specifications.

The C preprocessor is a simple, effective, and language-independent tool. Developers use the preprocessor in practice to deal with portability and variability issues. Despite the widespread usage, the C preprocessor suffers from severe criticism, such as negative effects on code understandability and maintainability. In particular, these problems may get worse when using undisciplined annotations, i.e., when a preprocessor directive encompasses only parts of C syntactical units. Nevertheless, despite the criticism and guidelines found in systems like Linux to avoid undisciplined annotations, the results of a previous controlled experiment indicated that the discipline of annotations has no influence on program comprehension and maintenance. To better understand whether developers care about the discipline of preprocessor-based annotations and whether they can really influence on maintenance tasks, in this paper we conduct a mixed-method research involving two studies. In the first one, we identify undisciplined annotations in 110 open-source C/C++ systems of different domains, sizes, and popularity GitHub metrics. We then refactor the identified undisciplined annotations to make them disciplined. Right away, we submit pull requests with our code changes. Our results show that almost two thirds of our pull requests have been accepted and are now merged. In the second study, we conduct a controlled experiment. We have several differences with respect to the aforementioned one, such as blocking of cofounding effects and more replicas. We have evidences that maintaining undisciplined annotations is more time consuming and error prone, representing a different result when compared to the previous experiment. Overall, we conclude that undisciplined annotations should not be neglected.

DevOps is a set of practices and cultural values that aims to reduce the barriers between development and operations teams. Due to its increasing interest and imprecise definitions, existing research works have tried to characterize DevOps. Nevertheless, little is known about the practitioners’ understandingabout successful paths for DevOps adoption. Therefore, our goal is to detail real scenarios of DevOps adoption, presenting a theory, a model, and a case study. We used classic Grounded Theory to build a theory about 15 scenarios of successful DevOps adoption in companies from different domains and countries. We proposed a model (i.e., a workflow for DevOps adoption) and evaluated it through a case study at a Brazilian Government institution. We used a focus group to collect the company perceptions about DevOps adoption. This paper increments the existing view of DevOps by detailing real scenarios and explaining the role of each category during DevOps adoption. We provide evidence that collaboration is the core DevOps concern, contrasting with an existing wisdom that automation and tooling can be enough to achieve DevOps. Altogether, our results contribute to: generating an adequate understanding of DevOps, from the practitioners’ perspective; and assisting other institutions in the path towards DevOps adoption.

This paper presents an empirical study whose goal was to investigate the exception handling strategies adopted by Java libraries and their potential impact on the client applications. In this study, exception flow analysis was used in combination with manual inspections in order: (i) to characterize the exception handling strategies of existing Java libraries from the perspective of their users; and (ii) to identify exception handling anti-patterns. We extended an existing static analysis tool to reason about exception flows and handler actions of 656 Java libraries selected from 145 categories in the Maven Central Repository. The study findings suggest a current trend of a high number of undocumented API runtime exceptions (i.e., @throws in Javadoc) and Unintended Handler problem. Moreover, we could also identify a considerable number of occurrences of exception handling anti-patterns (e.g. Catch and Ignore). Finally, we have also analyzed 647 bug issues of the 7 most popular libraries and identified that 20.71% of the reports are defects related to the problems of the exception strategies and anti-patterns identified in our study. The results of this study point to the need of tools to better understand and document the exception handling behavior of libraries.

Modernizing a legacy system is a costly process that requires deep understanding of the system architecture and its components. Without an understanding of the software architecture that will be rewritten, the entire process of reengineering can fail. For this reason, semi-automatic and automatic techniques for architecture recovery have been active focuses of research. However, there are still important improvements that need to be addressed on this field of research w.r.t. achieving a more accurate architecture recovery process. In this work, we propose to explore if an approach where visualization and clustering applied together can provide a higher accuracy on the software architecture recovery process. An experimental study was conducted in a industrial environment to empirically evaluate our investigation in four commercial systems. Our results indicated a statistically significant increase in the accuracy of the recovered architectures in all cases.

Product flexibility is one of the expected benefits of a modular design, and thus "it should be possible to make drastic changes to a module without changing others." Accordingly, the data available on version control systems might help software architects to reason about some quality attributes of the modular decomposition of a system. In this paper we investigate the impact of co-change dependencies into system stability, that is, the potential ripple effect that might occur during maintenance tasks. Here we use (a) Design Structure Matrices (DSMs) for visualizing dependencies motivated by assets’ co-change and (b) two metrics for estimating system stability: Propagation Cost of Changes and Clustered Cost of a Decomposition. We conducted a comprehensive study about co-change dependencies and their effects on system stability, considering the change history of six open-source Java systems: Derby, Eclipse UI, Eclipse JDT, Hadoop, Geronimo, and Lucene; and one relevant financial systems of the Brazilian Government (SIOP). We evaluated two distinct situations: first considering only the static dependencies of each system and then considering both static and co-change dependencies of each system. There is a significant impact of the co-change dependencies on the stability measurements for Derby, Hadoop, Lucene, and SIOP. This result suggests that the modular decomposition of these systems does not resemble their change history. Accordingly, our findings provide empirical evidence that the common approach for reasoning about the modular decomposition, which often uses only static dependencies, hides important details about the costs of maintenance tasks.

International audience; Software product lines (SPL) provide support for productivity gains through systematic reuse. Among the various quality attributes supporting these goals, modularity, stability and expressiveness of feature specifications, their composition and configuration knowledge emerge as strategic values in modern software development paradigms. This paper presents a metric-based evaluation aiming at assessing how well the chosen qualities are supported by scenario-based SPL requirements approaches. The selected approaches for this study span from type of notation (textual or graphical based), style to support variability (annotation or composition based), and specification expressiveness. They are compared using the metrics developed in a set of releases from an exemplar case study. Our major findings indicate that composition-based approaches have greater potential to support modularity and stability, and that quantification mechanisms simplify and increase expressiveness of configuration knowledge and composition specifications.