Abstract The reengineering of systems into a microservice-based architecture can be seen as an implementation of a service-oriented architecture (SOA). However, the deployment of SOA into an enterprise is a challenging task, as it may involve the modernization of mission-critical systems with high technical debt and high maintenance costs. To this end, a process is required to provide an appropriate set of steps and techniques that minimize risks and at the same time ensure the quality of the systems during the migration process. Thus, this work presents the Service-oriented Process for Reengineering and DevOps—SPReaD, an instantiation of the mainstream SOA methodology focusing on the reengineering of legacy systems integrating DevOps aspects for developing microservices systems. This process has been defined during a real software reengineering project of legacy systems from a Brazilian State Department of Taxation. The results obtained include a substantial improvement in the quality of the main taxation system used by the state, including not only code-related metrics but also performance improvements of the services offered, and a change in the methodology adopted by the software development team.

The information available in crash reports has been used to understand the root cause of bugs and improve the overall quality of systems. Nonetheless, crash reports often lead to a huge amount of information, being necessary to consolidate the crash report data into groups, according to a set of well-defined criteria. Recent research work have proposed different criteria and techniques to group crash report data, making more effective the process of finding the root causes of a bug and showing the performance of the approaches in the context of open source applications (such as IDEs and web browsers). In spite of that, it is still not clear how these approaches perform in other application domains, such as enterprise systems. In this paper, we present an industrial study in this field. We tailor existing approaches to find and group correlated crash reports, and identify buggy files in the domain of web-based systems. We then evaluate the performance of the resulting criteria and technique in industrial settings - identifying and ranking the classes that are more likely to contribute to a crash and thus might need a fix. We also check if the methods changed by the developers to fix a bug are present in the stack traces of the crash report groups used to identify the buggy classes. Our study provides new pieces of evidence of the potential use of crash report groups to indicate buggy classes and methods using stack traces information. For instance, we successfully identify buggy classes with recall varying from 61.4% to 77.3%, considering the top 1, top 3, top 5, and top 10 suspicious buggy files identified and ranked by our approach. We also found that 80% of changed methods from the closed bug fix issues appeared in related stack traces of the crash report groups. Finally, the approach also received positive response from the project leaders of the evaluated projects to help their bug resolution processes.

This paper presents an extended abstract incorporated as a journal-first paper into the ICSE'18 program.

Empirical evidence suggests exception handling is not reliably implemented. Most faults in exception handling are related to global exceptions violating the intended exception handling design. However, repairing these violations is a cumbersome and error-prone task. It requires knowing the intended design and understanding how the source code violates it. It also requires changing the source code to make it compliant with the intended design. But changing the exception handling code is a difficult task, since changes in exception handling requires changing different parts of a program. Currently, there is still no solution to assist the repair of this type of violations. To bridge this gap, we present RAVEN, a heuristic strategy aware of the global context of exceptions that produces recommendations of how violations in exception handling may be repaired. This strategy takes advantage of explicit specifications of the intended design, although their availability is not mandatory. Our results revealed RAVEN provides recommendations able to repair violations in 69 percent of the cases when policy specifications are not available and in 97 percent of the cases when specifications are available. Thus, development teams may benefit from RAVEN, even when exception handling design decisions are not documented in their projects.

Current software projects deal with exceptions in implementation and maintenance phases without a clear definition of exception handling policies. We call an exception handling policy the set of design decisions that govern the use of exceptions in a software project. Without an explicit exception handling policy, developers can remain unaware of the originally intended use of exceptions. In this paper, we present Exception Handling Policies Language (EPL), a domain-specific language to specify and verify exception handling policies. The evaluation of EPL was based on a user-centric observational study and case studies. The user-centric study was performed to observe how potential users of the language actually use it. With this study, we could better understand the trade-offs related to different language design decisions based on concrete and well-documented observations and experiences reported by participants. We identified some language characteristics that hindered its use and that motivated new language constructs. In addition, we performed case studies with one open-source project and two industry-strength systems to investigate how specifying and verifying exception handling policies may assist in detecting exception handling problems. The results show that violations of exception handling policies help to indicate potential faults in the exception handling code.

Exception handling mechanisms have been introduced into programming languages in an effort to help deal with runtime irregularities. These mechanisms aim to improve code reliability by providing constructs for sectioning code into exception scopes (e.g. Java try blocks) and exception handlers (e.g. Java catch blocks). Whilst exception handling mechanisms have been the focus of much research over the past years, empirical studies have only focused on characterising exception handling code of Java and C# programs. There exists little empirical evidence on how exception handling mechanisms are used to develop software with other programming languages. Moreover, to date there exists no empirical study which has examined the structure of exception scopes across software projects. We address these shortcomings by examining the commonalities and differences of both exception scopes and handlers implemented with a wider range of languages. To this end, we analysed 50 software projects, containing code developed in C++, JavaScript, PHP, Java and C#. More than 9 million lines of code and over 20,000 exceptional code blocks were analysed. Our findings revealed significant differences in the frequency, structure and length of exception scopes and exception handlers across languages. This finding suggests that certain exception handling mechanisms are less explored by programmers using certain programming languages. However, regardless of language, exception handlers remained simplistic and in general only ever one handler was associated with each scope. Finally, our analysis confirms the existing belief that developers often pay little attention to developing exception scoping and handling behaviour.

Mainstream programming languages provide built-in exception handling mechanisms to support robust and maintainable implementation of exception handling in software systems. Most of these modern languages, such as C#, Ruby, Python and many others, are often claimed to have more appropriated exception handling mechanisms. They reduce programming constraints on exception handling to favor agile changes in the source code. These languages provide what we call maintenance-driven exception handling mechanisms. It is expected that the adoption of these mechanisms improve software maintainability without hindering software robustness. However, there is still little empirical knowledge about the impact that adopting these mechanisms have on software robustness. This paper addressed this gap by conducting an empirical study aimed at understanding the relationship between changes in C# programs and their robustness. In particular, we evaluated how changes in the normal and exceptional code were related to exception handling faults. We applied a change impact analysis and a control flow analysis in 119 versions of 16 C# programs. The results showed that: (i) most of the problems hindering software robustness in those programs are caused by changes in the normal code, (ii) many potential faults were introduced even when improving exception handling in C# code, and (iii) faults are often facilitated by the maintenance-driven flexibility of the exception handling mechanism. Moreover, we present a series of change scenarios that decrease the program robustness.

Exception handling mechanisms (EHM) were conceived as a means to improve maintainability and reliability of programs that have to deal with exceptional situations. Amongst the different implementations of built-in EHM, we classify them in two main categories: reliability-driven and maintenance-driven. Some programming languages, such as Java, provide built-in exception handling mechanisms that promote reliability-driven EHMs. Maintenance-driven EHMs, on the other hand, promote software maintainability by not forcing developers to specify exception handling constraints. Most of modern languages, such as C#, Ruby, Python and many others support this approach. Developers usually have to choose between maintainability-driven and reliability-driven approaches to structure exception handling in their applications. However, there is still little empirical knowledge about the impact that adopting these mechanisms have on software robustness and maintenance. This paper addressed this gap by conducting an empirical study aimed at understanding the relationship between changes in Java and C# programs and their robustness. In particular, we evaluated how changes in the normal and exceptional code were related to exception handling faults. We applied a change impact analysis and a control flow analysis in 116 versions of 16 C# programs and 112 versions of 16 Java programs.