Abstract “In Silico” research drives the world around us, as illustrated by the way our society handles climate change, controls the COVID-19 pandemic and governs economic growth. Unfortunately, the code embedded in the underlying data processing is mostly written by scientists lacking formal training in software engineering. The resulting code is vulnerable, suffering from what is known as threats to instrument validity. This position paper aims to understand and remedy threats to instrument validity in current “in silico” research. To achieve this goal, we specify a research agenda listing how recent software engineering achievements may improve “in silico” research (SE4Silico) and, conversely, how software engineering may strengthen its applicability (Silico4SE).

Abstract Mutation testing is the state‐of‐the‐art technique for assessing the fault detection capacity of a test suite. Unfortunately, a full mutation analysis is often prohibitively expensive. The CppCheck project for instance, demands a build time of 5.8 min and a test execution time of 17 s on our desktop computer. An unoptimised mutation analysis, for 55,000 generated mutants took 11.8 days in total, of which 4.3 days is spent on (re)compiling the project. In this paper, we present a feasibility study, investigating how a number of optimisation strategies can be implemented based on the Clang front‐end. These optimisation strategies allow to eliminate the compilation and execution overhead in order to support efficient mutation testing for the C language family. We provide a proof‐of‐concept tool that achieves a speedup of between 2 and 30 . We make a detailed analysis of the speedup induced by the optimisations, elaborate on the lessons learned and point out avenues for further improvements.

Several experience reports illustrate that mutation testing is capable of supporting a “shift-left” testing strategy for software systems coded in textual programming languages like C++. For graphical modelling languages like Simulink, such experience reports are missing, primarily because of a lack of adequate tool support. In this paper, we present a proof-of-concept (named MUT4S LX) for automatic mutant generation and test execution of Simulink models. MUT14SLX features 15 mutation operators which are modelled after realistic faults (mined from an industrial bug database) and are fast to inject (because we only replace parameter values within blocks). An experimental evaluation on a sample project (a Helicopter Control System) demonstrates that MUT4SLX is capable of injecting 70 mutants in less than a second, resulting in a total analysis time of 8.14 hours.

Recent research has shown that clones occur far more often in test code than in production code. This is explained by the typical template of unit test code (the setup-stimulate-verify-teardown cycle), a template which lends itself well to parameterisation of proven solutions. However, little is known on how these clones evolve over time. In this paper, we compare the evolution of clones in test code with those in production code. Based on a quantitative and qualitative study of eight representative open-source systems, we conclude that clones in test code are inherently different than clones in production code throughout development. As a consequence, consistent maintenance and tracking of test clones becomes more important, hence the need for special purpose clone tracking and management tools.

Software testing enables development teams to maintain the quality of a software system while it evolves. The database manipulation code requires special attention in this context. However, it is often neglected and suffers from software maintenance problems. In this paper, we study the current state-of-the-practice in testing database manipulation code. We first analysed the tests of 72 open-source projects to gain insight into the coverage of database access code. The database was poorly tested: 46% of the projects did not cover with tests half of their database access methods, and 33% did not cover the database code at all. This poor coverage motivated us to study developers’ challenges and best practices. (i) First, we analysed 532 questions on Stack Exchange sites and deduced a taxonomy of issues. Developers mostly looked for general best practices to test database access code. Their technical questions were related to database management, mocking, parallelisation, or framework/tool usage. (ii) Next, we examined the answers to these questions. We manually labelled 598 answers to 255 questions. We distinguished 363 solutions and organised them in a taxonomy of best practices. Most of the suggestions considered the testing environment and recommended various tools or configurations. The second largest category was database management, where many addressed database initialisation and clean-up between tests. Other categories pertained to code structure or design, concepts, performance, processes, test characteristics, test code, and mocking. We illustrate the two taxonomies through intriguing examples.

Modern software systems increasingly depend on packages released on code sharing platforms such as GitHub, Bitbucket, and GitLab. To minimize the risk of lurking defects in such packages, strong test suites covering the normal as well as the exceptional paths are needed. In this paper we explore the potential of using tests from dependent projects to increase the code coverage of base packages. We extracted 4 popular Python packages from GitHub together with 14 dependent projects and analyzed the code coverage of the available tests. We observed that adopting the tests of the dependent projects in the test suite of the base library, would increase the line coverage in 9 out of 14 (64%) of the cases and the mutation coverage in all of them (100%). Our results suggest that a tool which would generate tests for the base package based on the tests in the dependent projects, would help to strengthen the test suite.

Previous research has demonstrated that the test coverage of libraries can be expanded by using existing test inputs from their dependent projects. In this paper, we propose an algorithm for test transplantation based on test slicing. The algorithm extracts test inputs, isolates them by creating mocks, and then transplants the test code onto the test suite of the libraries. To achieve test slicing, we dynamically execute the tests in the dependent project and create its graph of histories. Then, we traverse back from the interesting object state and collect the corresponding edges. Finally, we reverse the collected edges and create a sequence of method calls to reconstruct the same object state. We have implemented a proof-of-concept in Pharo-Smalltalk, in this paper we discuss the lessons learned so far.

Re-using whole repositories as a starting point for new projects is often done by maintaining a variant fork parallel to the original. However, the common artifacts between both are not always kept up to date. As a result, patches are not optimally integrated across the two repositories, which may lead to sub-optimal maintenance between the variant and the original project. A bug existing in both repositories can be patched in one but not the other (we see this as a missed opportunity) or it can be manually patched in both probably by different developers (we see this as effort duplication). In this paper we present a tool (named PaReCo) which relies on clone detection to mine cases of missed opportunity and effort duplication from a pool of patches. We analyzed 364 (source to target) variant pairs with 8,323 patches resulting in a curated dataset containing 1,116 cases of effort duplication and 1,008 cases of missed opportunities. We achieve a precision of 91%, recall of 80%, accuracy of 88%, and F1-score of 85%. Furthermore, we investigated the time interval between patches and found out that, on average, missed patches in the target variants have been introduced in the source variants 52 weeks earlier. Consequently, PaReCo can be used to manage variability in “time” by automatically identifying interesting patches in later project releases to be backported to supported earlier releases.

Social coding platforms centred around git provide explicit facilities to share code between projects: forks, pull requests, cherry-picking to name but a few. Variant forks are an interesting phenomenon in that respect, as they permit for different projects to peacefully co-exist, yet explicitly acknowledge the common ancestry. Several researchers analysed forking practices on open source platforms and observed that variant forks get created frequently. However, little is known on the motivations for launching such a variant fork. Is it mainly technical (e.g., diverging features), governance (e.g., diverging interests), legal (e.g., diverging licences), or do other factors come into play? We report the results of an exploratory qualitative analysis on the motivations behind creating and maintaining variant forks. We surveyed 105 maintainers of different active open source variant projects hosted on GitHub. Our study extends previous findings, identifying a number of fine-grained common motivations for launching a variant fork and listing concrete impediments for maintaining the co-existing projects.

Software test amplification is the act of strength-ening manually written test-cases to exercise the boundary conditions of the system under test. It has been demonstrated by the research community to work for the programming language Java, relying on the static type system to safely transform the code under test. In dynamically typed languages, such type decla-rations are not available, and as a consequence test amplification has yet to find its way to programming languages like Smalltalk, Python, Ruby and Javascript. The AnSyMo research group has created two proof of concept tools for languages without a static type system: AmPyfier (for Python) and Small-Amp (for Pharo-Smalltalk). In this tool demonstration paper we explain how we relied on profiling libraries present in the respective eco-systems to infer the necessary type information for enabling full-blown test amplification.

Abstract Some test amplification tools extend a manually created test suite with additional test cases to increase the code coverage. The technique is effective, in the sense that it suggests strong and understandable test cases, generally adopted by software engineers. Unfortunately, the current state-of-the-art for test amplification heavily relies on program analysis techniques which benefit a lot from explicit type declarations present in statically typed languages. In dynamically typed languages, such type declarations are not available and as a consequence test amplification has yet to find its way to programming languages like Smalltalk, Python, Ruby and Javascript. We propose to exploit profiling information —readily obtainable by executing the associated test suite— to infer the necessary type information creating special test inputs with corresponding assertions. We evaluated this approach on 52 selected test classes from 13 mature projects in the Pharo ecosystem containing approximately 400 test methods. We show the improvement in killing new mutants and mutation coverage at least in 28 out of 52 test classes (≈ 53%). Moreover, these generated tests are understandable by humans: 8 out of 11 pull-requests submitted were merged into the main code base (≈ 72%). These results are comparable to the state-of-the-art, hence we conclude that test amplification is feasible for dynamically typed languages.

Abstract Test amplification aims to automatically improve a test suite. One technique generates new test methods through transformations of the original tests. These test amplification tools heavily rely on analysis techniques that benefit a lot from type declarations present in the source code of projects written in statically typed languages. In dynamically typed languages, such type declarations are not available, and therefore, research regarding test amplification for those languages is sparse. Recent work has brought test amplification to the dynamically typed language Pharo Smalltalk by introducing the concept of dynamic type profiling. The technique is dependent on Pharo‐specific frameworks and has not yet been generalized to other languages. Another significant downside in test amplification tools based on the mutation score of a test suite is their high time cost. In this paper, we present AmPyfier, a tool that brings test amplification and type profiling to the dynamically typed language Python. AmPyfier introduces multi‐metric selection in order to increase the time efficiency of test amplification. We evaluated AmPyfier on 11 open‐source projects and found that AmPyfier could strengthen 37 out of 54 test classes. Multi‐metric selection decreased the time cost ranging from 17% to 98% as opposed to selection based on the full mutation score.

Digital twins (DTs) are prevalent throughout industrial domains as evidenced by the rapid pace of experience reports in the literature.However, there remains disagreement about the precise definition of a DT and the essential characteristics in the DT paradigm, such as the scope of the system-under-study and the time-scale of its communication with the DT.These experience reports could therefore be hampering further classification and research insights by not reporting all of these relevant details about the DT solutions.We address these concerns by providing a conceptual structure for DTs as a common understanding and checklist for researchers and practitioners to precisely describe the characteristics and capabilities of their DT solutions.We express five experience reports using our structure to demonstrate its applicability and role as a guideline to improve the reporting of characteristics and increase the clarity of future experience reports.

The software industry has seen an increasing interest in test automation. In this paper, we present a test automation maturity survey serving as a self-assessment for practitioners. Based on responses of 151 practitioners coming from above 101 organizations in 25 countries, we make observations regarding the state of the practice of test automation maturity: a) The level of test automation maturity in different organizations is differentiated by the practices they adopt; b) Practitioner reported the quite diverse situation with respect to different practices, e.g., 85\% practitioners agreed that their test teams have enough test automation expertise and skills, while 47\% of practitioners admitted that there is lack of guidelines on designing and executing automated tests; c) Some practices are strongly correlated and/or closely clustered; d) The percentage of automated test cases and the use of Agile and/or DevOps development models are good indicators for a higher test automation maturity level; (e) The roles of practitioners may affect response variation, e.g., QA engineers give the most optimistic answers, consultants give the most pessimistic answers. Our results give an insight into present test automation processes and practices and indicate chances for further improvement in the present industry.

Duplicated test code (a.k.a. test code clones) has a negative impact on test comprehension and maintenance. Moreover, the typical structure of unit test code induces structural similarity, increasing the amount of duplication. Yet, most research on software clones and clone detection tools is focused on production code, often ignoring test code. In this paper we fill this gap by comparing four different clone detection tools (NiCad, CPD, iClones, TCORE) against the test code of three open-source projects. Our analysis confirms the prevalence of test code clones, as we observed between 23% and 29% test code duplication. We also show that most of the tools suffer from false negatives (NiCad = 83%, CPD = 84%, iClones = 21%, TCORE = 65%), which leaves ample room for improvement. These results indicate that further research on test clone detection is warranted.

Background: Mutation testing is the state-of-the-art technique for assessing the fault detection capacity of a test suite. Unfortunately, it is seldom applied in practice because it is computationally expensive. We witnessed 48 hours of mutation testing time on a test suite comprising 272 unit tests and 5,258 lines of test code for testing a project with 48,873 lines of production code. Aims: Therefore, researchers are currently investigating cloud solutions, hoping to achieve sufficient speed-up to allow for a complete mutation test run during the nightly build. Method: In this paper we evaluate mutation testing in the cloud against two industrial projects. Results: With our proof-of-concept, we achieved a speed-up between 12x and 12.7x on a cloud infrastructure with 16 nodes. This allowed to reduce the aforementioned 48 hours of mutation testing time to 3.7 hours. Conclusions: We make a detailed analysis of the delays induced by the distributed architecture, point out avenues for further optimisation and elaborate on the lessons learned for the mutation testing community. Most importantly, we learned that for optimal deployment in a cloud infrastructure, tasks should remain completely independent. Mutant optimisation techniques that violate this principle will benefit less from deploying in the cloud.

Already from the early days of testing, practitioners distinguish between unit tests and integration tests as a strategy to locate defects. Unfortunately, the mining software engineering community rarely distinguishes between these two strategies, mainly because it is not straightforward to separate them in the code repositories under study. In this paper we exploited the TravisTorrent dataset provided for the MSR 2017 mining challenge, separated unit tests from integration tests, and correlated these against the workflow as recorded in the corresponding issue reports. Further analysis confirmed that it is worthwhile to treat unit tests and integration tests differently: we discovered that unit tests cause more breaking builds, that fixing the defects exposed by unit tests takes longer and implies more coordination between team members.

Code clones commonly occur during software evolution. They impact the effort of software development and maintenance, and therefore they need to be monitored. We present a large-scale empirical study (237 open-source Java projects maintained by 500 individuals) that investigates how the number of clones changes throughout software evolution, as well as the tendency of individual developers to introduce clones. Our results will set a point-of-reference against which development teams can compare and, if needed, adjust.

Mutation testing is a standard technique to evaluate the quality of a test suite. Due to its computationally intensive nature, many approaches have been proposed to make this technique feasible in real case scenarios. Among these approaches, uniform random mutant selection has been demonstrated to be simple and promising. However, works on this area analyze mutant samples at project level mainly on projects with adequate test suites. In this paper, we fill this lack of empirical validation by analyzing random mutant selection at class level on projects with non-adequate test suites. First, we show that uniform random mutant selection underachieves the expected results. Then, we propose a new approach named weighted random mutant selection which generates more representative mutant samples. Finally, we show that representative mutant samples are larger for projects with high test adequacy.

Continuous integration is a best practice adopted in modern software development teams to identify potential faults immediately upon project build. Once a fault is detected it must be repaired immediately, hence continuous integration provides an ideal testbed for experimenting with the state of the art in fault localisation. In this paper we propose a variant of what is known as spectrum based fault localisation, which leverages patterns of method calls by means of frequent itemset mining. We compare our variant (we refer to it as patterned spectrum analysis) against the state of the art and demonstrate on 351 real bugs drawn from five representative open source java projects that patterned spectrum analysis is more effective in localising the fault. Based on anecdotal evidence from this comparison, we suggest avenues for further improvements. Keywords: Automated developer tests; Continuous Integration; Spectrum based fault localisation; Statistical debugging

The test suite is essential for fault detection during software development. First-order mutation coverage is an accurate metric to quantify the quality of the test suite. However, it is computationally expensive. Hence, the adoption of this metric is limited. In this study, we address this issue by proposing a realistic model able to estimate first-order mutation coverage using only higher-order mutation coverage. Our study shows how the estimation evolves along with the order of mutation. We validate the model with an empirical study based on 17 open-source projects.

Today, it is widely accepted that if refactoring is applied in practice, it is mainly interweaved with normal software development - so called "floss refactoring". Unfortunately, the current state-of-the-art is poorly equipped to mine floss refactoring from version histories, mainly because they infer refactorings by comparing two snapshots of a system and making educated guesses about the precise edit operations applied in between. In this paper we propose a solution that reconstructs refactorings not on snapshots of a system but using the actual changes as they are performed in an integrated development environment. We compare our solution against RefFinder and demonstrate that on a small yet representative program (the well-known "Video Rental system") our approach is more accurate in identifying occurrences of the "Move Method" and "Rename Method" refactorings.

On the occasion of the 10th anniversary of the MSR conference, it is a worthwhile exercise to meditate on the past, present and future of our research discipline. Indeed, since the MSR community has experienced a big influx of researchers bringing in new ideas, state-of-the art technology and contemporary research methods it is unclear what the future might bring. In this paper, we report on a text mining exercise applied on the complete corpus of MSR papers to reflect on where we come from; where we are now; and where we should be going. We address issues like the trendy (and outdated) research topics; the frequently (and less frequently) cited cases; the popular (and emerging) mining infrastructure; and finally the proclaimed actionable information which we are deemed to uncover.

The analysis of bug reports is an important subfield within the mining software repositories community. It explores the rich data available in defect tracking systems to uncover interesting and actionable information about the bug triaging process. While bug data is readily accessible from systems like Bugzilla and JIRA, a common database schema and a curated dataset could significantly enhance future research because it allows for easier replication. Consequently, in this paper we propose the Eclipse and Mozilla Defect Tracking Dataset, a representative database of bug data, filtered to contain only genuine defects (i.e., no feature requests) and designed to cover the whole bug-triage life cycle (i.e., store all intermediate actions). We have used this dataset ourselves for predicting bug severity, for studying bug-fixing time and for identifying erroneously assigned components. Sharing these data with the rest of the community will allow for reproducibility, validation and comparison of the results obtained in bug-report analyses and experiments.

This paper presents an empirical study comparing two alternatives for generating code from aspect-oriented models. In an aspect "disrupting" process, an object oriented implementation in Java is automatically generated from domain specific models, comprising a mix of UML (for core functionality) and DSLs (for qualities like security and perfor mance). In an aspect "preserving" process, an aspect oriented implementation in AspectJ is automatically generated from the same models. In both alternatives, a number of subjects are asked to perform several maintenance tasks requiring the addition and improvement of functionality. The results show that, in most of the cases, the AO alternative provides for shorter maintenance cycles.

Computer Science as a research discipline has always struggled with its identity. On the one hand, it is a field deeply rooted in mathematics which resulted in strong theories.1For example, there is computational complexity theory (turing machines, the halting problem), database theory (the relational model, expresive power of query languages), formal language theory (the chomsky hierarchy, well-formedness, formal semantics). On the other hand, it is a field deeply rooted in engineering which resulted in machines that have completely warped our society: the von Neumann architecture (the basis for digital computers), parallel processors (the new generation of multi-core machines), distributed computers (a prerequisite for the success of the internet and recent phenomena like grid computing). Consequently, computer science has inherited its research methods from the same disciplines: on the one hand, the mathematical approach with axioms, postulates and proofs; on the other hand the engineering approach with quantification, measurements and comparison.

Identifying refactorings in software archives has been an active research topic in the last decade, mainly because it is a prerequisite for various software evolution analyses (e.g., error detection, capturing intent of change, capturing and replaying changes, and relating refactorings and software metrics). Many of these techniques rely on similarity measures to identify structurally equivalent code, however, up until now the effect of this similarity measure on the performance of the refactoring identification algorithm is largely unexplored. In this paper we replicate a well-known experiment from Weißgerber and Diehl, plugging in three different similarity measures (text-based, AST-based, token-based). We look at the overlap of the results obtained by the different metrics, and we compare the results using recall and the computation time. We conclude that the different result sets have a large overlap and that the three metrics perform with a comparable quality.

Many software production processes advocate rigorous development testing alongside functional code writing, which implies that both test code and production code should co-evolve. To gain insight in the nature of this co-evolution, this paper proposes three views (realized by a tool called TeMo) that combine information from a software project’s versioning system, the size of the various artifacts and the test coverage reports. We validate these views against two open source and one industrial software project and evaluate our results both with the help of log messages, code inspections and the original developers of the software system. With these views we could recognize different co-evolution scenarios (i.e., synchronous and phased) and make relevant observations for both developers as well as test engineers.

The severity of a reported bug is a critical factor in deciding how soon it needs to be fixed. Unfortunately, while clear guidelines exist on how to assign the severity of a bug, it remains an inherent manual process left to the person reporting the bug. In this paper we investigate whether we can accurately predict the severity of a reported bug by analyzing its textual description using text mining algorithms. Based on three cases drawn from the open-source community (Mozilla, Eclipse and GNOME), we conclude that given a training set of sufficient size (approximately 500 reports per severity), it is possible to predict the severity with a reasonable accuracy (both precision and recall vary between 0.65-0.75 with Mozilla and Eclipse; 0.70-0.85 in the case of GNOME).

Over the last decade, numerous techniques have been proposed in the literature to reverse engineer large legacy systems, several of them even claiming success on industrial scale. Consequently, when faced with a reverse engineering request from a large banking company, we decided to reuse an existing technique (namely, feature location using formal concept analysis on execution profiles) and see whether we could replicate their results. This paper reports our experience with such a replication experiment: we list those things that worked well (and fortunately, there were quite a few) and those things that did not work so well (and try to identify root causes and solutions for the problems we encountered).

Engineering software systems is a multidisciplinary activity, whereby a number of artifacts must be created - and maintained - synchronously. In this paper we investigate whether production code and the accompanying tests co- evolve by exploring a project's versioning system, code coverage reports and size-metrics. Our main aim for studying this co-evolution is to create awareness with developers and managers alike about the testing process that is followed. We explore the possibilities of our technique through two open source case studies and observe a number of different co-evolution scenarios. We evaluate our results both with the help of log-messages and the original developers of the software system.

Abstract Software engineers new to a project are often stuck sorting through hundreds of classes in order to find those few classes that offer a significant insight into the inner workings of the software project. To help stimulate this process, we propose a technique that can identify the most important classes in a system or the key classes of that system. Software engineers can use these classes to focus their understanding efforts when starting to work on a new software project. Those key classes are typically characterized with having a lot of ‘control’ within the application. In order to find these controlling classes, we present a detection approach that is based on dynamic coupling and webmining. We demonstrate the potential of our technique using two open‐source software systems that have a rich documentation set. During the case studies we use dynamically gathered coupling information that vary between a number of coupling metrics. The case studies show that we are able to retrieve 90% of the classes deemed important by the original maintainers of the systems, while maintaining a level of precision of around 50%. Copyright © 2008 John Wiley & Sons, Ltd.

As a fine-grained defect detection technique, unit testing introduces a strong dependency on the structure of the code. Accordingly, test coevolution forms an additional burden on the software developer which can be tempered by writing tests in a manner that makes them easier to change. Fortunately, we are able to concretely express what a good test is by exploiting the specific principles underlying unit testing. Analogous to the concept of code smells, violations of these principles are termed test smells. In this paper, we clarify the structural deficiencies encapsulated in test smells by formalizing core test concepts and their characteristics. To support the detection of two such test smells, General Fixture and Eager Test, we propose a set of metrics defined in terms of unit test concepts. We compare their detection effectiveness using manual inspection and through a comparison with human reviewing. Although the latter is the traditional means for test quality assurance, our results indicate it is not a reliable means for test smell detection. This work thus stresses the need for a more reliable detection mechanism and provides an initial contribution through the validation of test smell metrics.

Test code, just like any other code we write, erodes when frequently changed. As such, refactoring, which has been shown to impact maintainability and comprehensibility, can be part of a solution to counter this erosion. We propose a metric-based heuristical approach, which allows to rank occurrences of so-called test smells (i.e. symptoms of poorly designed tests) according to their relative significance. This ranking can subsequently be used to start refactoring. Through an open-source case study, ArgoUML, we demonstrate that we are able to identify those test cases who violate unit test criteria

During initial program comprehension, software engineers could benefit from knowing the most need-to-be-understood classes in the system under study in order to kick-start their software reconnaissance. Previously we have used Webmining techniques on runtime trace data to identify these important classes. Here, we reprise this Webmining technique and make a thorough comparison of its effectiveness when collecting static information of the software system under study. Apache Ant and Jakarta JMeter, two medium-scale open source Java software systems, serve as case studies. From publicly available developers notes we conclude that the Webmining technique in combination with dynamic analysis provides the best results with a level of recall of 90% when comparing with the developers' opinion

The notion of refactoring - transforming the source-code of an object-oriented program without changing its external behavior - has been embraced by many object-oriented software developers as a way to accommodate changing requirements. If applied well, refactoring improves the maintainability of the software. However, it is believed that it does so at the sake of performance. Especially in a C++ context, the introduction of virtual function calls is often blamed for performance reduction because it introduces an extra indirection via the so-called virtual function table. To investigate the performance trade-off involved when introducing virtual functions, we compared the execution time of four benchmark programs which contain large conditionals against refactored versions where the conditionals were replaced by virtual function calls. Depending on the compiler and compiler optimizations being used, we discovered that C++ programs refactored this way often perform faster than their non-refactored counterparts, hence advise programmers not to obfuscate their programs with conditional logic in order to obtain good performance.

Surprising as it may seem, many of the early adopters of the object-oriented paradigm already face a number of problems typically encountered in large-scale legacy systems. Software engineers are now confronted with millions of lines of industrial source code, developed using object-oriented design methods and languages of the late 80s and early 90s. These systems exhibit a range of problems, effectively preventing them from satisfying the evolving requirements imposed by their customers. This paper shares our knowledge concerning the reengineering of object-oriented legacy systems. We draw upon our experiences, to show you techniques and tools we have applied on real industrial OO systems to detect and repair problems. In particular, we discuss issues like reverse engineering, design extraction, metrics, refactoring and program visualisation.

The widespread interest in refactoring—transforming the source-code of an object-oriented program without changing its external behaviour—has increased the need for a precise definition of refactoring transformations and their properties. In this paper we explore the use of graph rewriting for specifying refactorings and their effect on programs. We introduce a graph representation for programs and show how two representative refactorings can be expressed by graph productions. Then we demonstrate that it is possible to prove that refactorings preserve certain program properties, and that graph rewriting is a suitable formalism for such proofs. Copyright © 2005 John Wiley & Sons, Ltd.

The rapid growth of object-oriented development over the past twenty years has given rise to many object-oriented systems that are large, complex and hard to maintain. These systems exhibit a range of problems, effectively preventing them from satisfying the evolving requirements imposed by their customers. In our paper, we address problem of understanding and reengineering such object-oriented legacy systems. The material is presented as a set of "reengineering patterns" - recurring solutions that experts apply while reengineering and maintaining object-oriented systems. The patterns distill successful techniques in planning a reengineering project, reverse-engineering, problem detection, migration strategies and software redesign. The principles and techniques described have been observed and validated in a number of industrial projects, and reflect best practice in object-oriented reengineering.

Before re-engineering a large and complex software system, it is wise to study its change history in order to identify the most valuable and problematic parts. Unfortunately, typical change histories contain thousands of entries, therefore the challenge is to discover those changes which are relevant for both the current and future situations of our product and process. We demonstrate how a simple visualization allows us to recognize relevant changes. Applying the technique on the change history of Tomcat, we have been able to identify (a) unstable components, (b) coherent entities, (c) design and architectural evolution, and (d) fluctuations in team productivity.

Reverse engineering is the process of uncovering the design and the design rationale from a functioning software system. Reverse engineering is an integral part of any successful software system, because changing requirements lead to implementations that drift from their original design. In contrast to traditional reverse engineering techniques ---which analyse a single snapshot of a system--- we focus the reverse engineering effort by determining where the implementation has changed. Since changes of object-oriented software are often phrased in terms of refactorings, we propose a set of heuristics for detecting refactorings by applying lightweight, object-oriented metrics to successive versions of a software system. We validate our approach with three separate case studies of mature object-oriented software systems for which multiple versions are available. The case studies suggest that the heuristics support the reverse engineering process by focusing attention on the relevant parts of a software system.

Code duplication is one of the factors that severely complicates the maintenance and evolution of large software systems. Techniques for detecting duplicated code exist but rely mostly on parsers, technology that has proven to be brittle in the face of different languages and dialects. In this paper we show that is possible to circumvent this hindrance by applying a language independent and visual approach, i.e. a tool that requires no parsing, yet is able to detect a significant amount of code duplication. We validate our approach on a number of case studies, involving four different implementation languages and ranging from 256 K up to 13 Mb of source code size.