Better Refactoring Tools for a Better Refactoring Strategy

Refactoring tools can improve the speed and accuracy with which we create and maintain software – but only if they are used. In practice, tools are not used as much as they could be; this seems to be because they do not align with the refactoring strategy preferred by the majority of programmers: floss refactoring. We propose five principles that characterize successful floss refactoring tools – principles that can help programmers to choose the most appropriate refactoring tools and also help toolsmiths to design more usable tools

Domain-Specific Acceleration and Auto-Parallelization of Legacy Scientific Code in FORTRAN 77 using Source-to-Source Compilation

Massively parallel accelerators such as GPGPUs, manycores and FPGAs represent a powerful and affordable tool for scientists who look to speed up simulations of complex systems. However, porting code to such devices requires a detailed understanding of heterogeneous programming tools and effective strategies for parallelization. In this paper we present a source to source compilation approach with whole-program analysis to automatically transform single-threaded FORTRAN 77 legacy code into OpenCL-accelerated programs with parallelized kernels. The main contributions of our work are: (1) whole-source refactoring to allow any subroutine in the code to be offloaded to an accelerator. (2) Minimization of the data transfer between the host and the accelerator by eliminating redundant transfers. (3) Pragmatic auto-parallelization of the code to be offloaded to the accelerator by identification of parallelizable maps and reductions. We have validated the code transformation performance of the compiler on the NIST FORTRAN 78 test suite and several real-world codes: the Large Eddy Simulator for Urban Flows, a high-resolution turbulent flow model; the shallow water component of the ocean model Gmodel; the Linear Baroclinic Model, an atmospheric climate model and Flexpart-WRF, a particle dispersion simulator. The automatic parallelization component has been tested on as 2-D Shallow Water model (2DSW) and on the Large Eddy Simulator for Urban Flows (UFLES) and produces a complete OpenCL-enabled code base. The fully OpenCL-accelerated versions of the 2DSW and the UFLES are resp. 9x and 20x faster on GPU than the original code on CPU, in both cases this is the same performance as manually ported code.Comment: 12 pages, 5 figures, submitted to "Computers and Fluids" as full paper from ParCFD conference entr

Refactoring Tools: Fitness for Purpose

Refactoring tools can improve the speed and accuracy with which we create and maintain software -- but only if they are used. In practice, tools are not used as much as they could be: this seems to be because sometimes they do not align with the refactoring tactic preferred by the majority of programmers, a tactic we call floss refactoring. We propose five principles that characterize successful floss refactoring tools -- principles that can help programmers to choose the most appropriate refactoring tools and also help toolsmiths to design tools that fit the programmer\u27s purpose

What Algebraic Graph Transformations Can Do For Model Transformations

Model transformations are key activities in model-driven development (MDD). A number of model transformation approaches have emerged for different purposes and with different backgrounds. This paper focusses on the use of algebraic graph transformation concepts to specify and verify model transformations in MDD

A framework for the simulation of structural software evolution

This is the author's accepted manuscript. The final published article is available from the link below. Copyright @ 2008 ACM.As functionality is added to an aging piece of software, its original design and structure will tend to erode. This can lead to high coupling, low cohesion and other undesirable effects associated with spaghetti architectures. The underlying forces that cause such degradation have been the subject of much research. However, progress in this field is slow, as its complexity makes it difficult to isolate the causal flows leading to these effects. This is further complicated by the difficulty of generating enough empirical data, in sufficient quantity, and attributing such data to specific points in the causal chain. This article describes a framework for simulating the structural evolution of software. A complete simulation model is built by incrementally adding modules to the framework, each of which contributes an individual evolutionary effect. These effects are then combined to form a multifaceted simulation that evolves a fictitious code base in a manner approximating real-world behavior. We describe the underlying principles and structures of our framework from a theoretical and user perspective; a validation of a simple set of evolutionary parameters is then provided and three empirical software studies generated from open-source software (OSS) are used to support claims and generated results. The research illustrates how simulation can be used to investigate a complex and under-researched area of the development cycle. It also shows the value of incorporating certain human traits into a simulation—factors that, in real-world system development, can significantly influence evolutionary structures

Visualising Java Coupling and Fault Proneness

In this paper, a tool is described for visualising the Coupling Between Objects (CBO) metric for Java systems, decomposing it into coupling collaborators and using colour to denote the object-oriented mechanisms at work for each couple. The resulting visualisation is also envisaged to be useful for general program comprehension and is integrated into Java development in the Eclipse IDE. Evidence is also given that the visualisation may help detect classes tending to be less fault-prone than would be expected from inspection of their CBO values alone

What to Fix? Distinguishing between design and non-design rules in automated tools

Technical debt---design shortcuts taken to optimize for delivery speed---is a critical part of long-term software costs. Consequently, automatically detecting technical debt is a high priority for software practitioners. Software quality tool vendors have responded to this need by positioning their tools to detect and manage technical debt. While these tools bundle a number of rules, it is hard for users to understand which rules identify design issues, as opposed to syntactic quality. This is important, since previous studies have revealed the most significant technical debt is related to design issues. Other research has focused on comparing these tools on open source projects, but these comparisons have not looked at whether the rules were relevant to design. We conducted an empirical study using a structured categorization approach, and manually classify 466 software quality rules from three industry tools---CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either not design (55%) or design (19%). The remainder (26%) resulted in disagreements among the labelers. Our results are a first step in formalizing a definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on Software Architecture 2017 (Gothenburg, SE

Code Smells and Refactoring: A Tertiary Systematic Review of Challenges and Observations

In this paper, we present a tertiary systematic literature review of previous surveys, secondary systematic literature reviews, and systematic mappings. We identify the main observations (what we know) and challenges (what we do not know) on code smells and refactoring. We show that code smells and refactoring have a strong relationship with quality attributes, i.e., with understandability, maintainability, testability, complexity, functionality, and reusability. We argue that code smells and refactoring could be considered as the two faces of a same coin. Besides, we identify how refactoring affects quality attributes, more than code smells. We also discuss the implications of this work for practitioners, researchers, and instructors. We identify 13 open issues that could guide future research work. Thus, we want to highlight the gap between code smells and refactoring in the current state of software-engineering research. We wish that this work could help the software-engineering research community in collaborating on future work on code smells and refactoring

Automated Coevolution of Source Code and Software Architecture Models

Zur Entwicklung komplexer Softwaresysteme, werden neben dem Quelltext zusätzliche Artefakte, wie beispielsweise Architekturmodelle, verwendet. Wenn die verwendeten Architekturmodelle während der Entwicklung und Evolution eines Softwaresystems konsistent mit dem Quelltext sind, können Softwarearchitekten und Softwareentwickler bei der Entwicklung der Systeme besser unterstützt werden. Architekturmodelle, die auf dem aktuellem Stand sind, vereinfachen Entwicklungs- und Evolutionssaufgaben, da einfacher beantwortet werden kann wie und wo neue Funktionen implementiert werden sollen. Außerdem ist es möglich, modellbasierte Analysen mit Hilfe der Softwarearchitekturmodelle vorzunehmen. Beispielsweise können mit dem Palladio Komponentenmodell (PCM) Performanzvorhersagen durchgeführt werden, wenn ein Architekturmodell des Softwaresystems vorhanden ist und dieses Verhaltensspezifikationen beinhaltet. Wenn Architekturmodelle bei der Softwareentwicklung und Softwareevolution verwendet werden, können die beiden bekannten Probleme Architekturdrift und Architekturverletzung auftreten. Diese Probleme treten für gewöhnlich auf, wenn bei voranschreitender Entwicklung des Quelltextes die Architektur nicht konsistent zu diesem gehalten wird. Dies führt zu veralteten und schlussendlich nutzlosen Architekturmodellen. Viele existierende Ansätze, zur Vermeidung dieser Probleme, zielen darauf ab, Quelltext und UML-Klassendiagramme konsistent zu halten, oder sie zielen darauf ab, Architekturinformationen in den Quelltext einzubetten. In letzterem Fall wird die Notwendigkeit, die Architektur konsistent mit dem Quelltext zu halten, umgangen, da die Architektur integraler Bestandteil des Quelltextes ist. In der vorliegenden Dissertation beschreiben wir einen neuen Ansatz, um komponentenbasierte Architekturmodelle, welche sich auf einer hohen Abstraktionsebene befinden, konsistent mit dem Quelltext zu halten. Wir beschreiben, wie Instanzen des PCMs konsistent mit Java-Quelltext gehalten werden können. Um Konsistenz zu erreichen, werden Architekturelemente erzeugt, gelöscht oder geändert, sobald ihre entsprechende Quelltextelemente geändert wurden, und umgekehrt. Für die Umsetzung der Konsistenzerhaltung stellen wir einen änderungsgetriebenen Ansatz vor. Dieser verwendet benutzerdefinierte, änderungsgetriebene Abbildungsregeln, um die Konsistenz zwischen den beteiligten Modellen sicherzustellen. In dieser Dissertation stellen wir vier konkrete Mengen von Abbildungsregeln zwischen Architekturmodellen und Quelltext vor. Diese haben wir in einer prototypischen Implementierung des Ansatzes umgesetzt. Wir stellen außerdem einen Mechanismus vor, der mit den Benutzern des Konsistenzerhaltungsansatzes interagiert, wenn die Konsistenz nicht automatisch erhalten werden kann, sondern die Benutzer zuerst ihre Intention, die sie mit einer bestimmten Änderung verfolgen, dem Ansatz mitteilen müssen. In diesem Fall müssen die Benutzer das genaue Vorgehen für die Konsistenzerhaltung spezifizieren. Da der vorgestellte Ansatz änderungsgetrieben funktioniert, ist es notwendig, dass wir alle Änderungen in den beteiligten Architektur- und Quelltexteditoren aufzeichnen können. Um es Benutzern zu erlauben, vorhandene Editoren, mit denen sie sich auskennen, wiederverwenden zu können, haben wir Beobachter für diese Editoren implementiert. Diese Beobachter zeichnen alle Änderungen an einem Modell auf und informieren unseren Ansatz über jede durchgeführte Änderung. Der in dieser Dissertation vorgestellte Ansatz erlaubt es auch, verhaltensbeschreibende Architekturmodelle konsistent mit dem Quelltext zu halten. Um dies zu erreichen, haben wir einen Ansatz implementiert, der es ermöglicht, Service Effect Specifications des PCMs inkrementell aus Methoden zu erstellen, nachdem diese geändert wurden. Die Service Effect Specifications werden innerhalb des PCMs genutzt, um das Verhalten einer Komponente zu spezifizieren. Um bereits bestehende Architekturmodelle und bestehenden Quelltext innerhalb unseres Ansatzes verwenden zu können, stellen wir je eine Integrationsstrategie für die Architektur und den Quelltext vor. Um bestehende Architekturmodelle zu integrieren, simulieren wir deren Erstellung. Während dieses Erstellvorgangs zeichnen wir die Änderungen auf, die nötig sind, um das Architekturmodell zu erstellen. Diese Änderungen werden als Eingabe für den Konsistenzerhaltungsprozess verwendet, um daraus den entsprechenden Quelltext zu erzeugen. Um vorhandenen Quelltext einzubinden, stellen wir einen Ansatz vor, der auf Architekturrekonstruktionsverfahren basiert, d.h., zuerst wird die Architektur eines bestehenden Softwaresystems rekonstruiert. Die erstellte Architektur wird anschließend zusammen mit dem bestehenden Quelltext in unseren Coevolutionsansatz integriert. Oftmals ist bestehender Quelltext jedoch nicht so aufgebaut, wie es die Abbildungsregeln vorschreiben. Innerhalb der Integrationsstrategie für Quelltext stellen wir deshalb einen Ansatz vor, der in der Lage ist, solche Quelltexte dennoch zu integrieren. Dieser Ansatz ermöglicht es, nicht nur diese Art von Quelltext zu integrieren, sondern diesen auch mit speziell definierten Abbildungsregeln automatisch konsistent zu halten. Wir haben unseren Ansatz in verschiedenen Fallstudien evaluiert. Dabei haben wir zunächst gezeigt, dass es möglich ist vorhandene Architekturmodelle zu integrieren, indem ihr Aufbau simuliert wird. In der durchgeführten Fallstudie ist es mit unserem Ansatz und den vorgestellten Abbildungsregeln möglich, zwischen 98% und 100% der unterstützten Elemente zu integrieren. Als nächstes haben wir gezeigt, dass unser Ansatz in der Lage ist, existierenden Quelltext zu integrieren und Änderungen am integrierten Quelltext konsistent mit der Architektur zu halten. Für diese Fallstudie haben wir zunächst den Quelltext von vier quelloffenen Projekten in den Ansatz integriert. Als nächstes haben wir gezeigt, dass es möglich ist, Änderungen am Quelltext konsistent mit der Architektur zu halten. Dazu haben wir eine alte Version des Quelltextes integriert und Änderungen die zwischen einer alten und neueren Version durchgeführt wurden, aus einem Versionskontrollsystem extrahiert und erneut auf den Quelltext angewendet. Im Rahmen dieser Evaluation haben wir auch gezeigt, dass es möglich ist Änderungen, die innerhalb von Methoden durchgeführt werden, mit einem Verhaltensmodell konsistent zu halten. Wir haben außerdem eine Evaluation der Leistungsfähigkeit unseres Ansatzes durchgeführt und gezeigt, dass unser Ansatz in den meisten Fällen in der Lage ist, die Architektur in einer Zeit zwischen einer und fünf Sekunden konsistent zu halten, nachdem eine Änderung am Quelltext durchgeführt wurde. Als letztes haben wir gezeigt, dass es möglich ist, coevolvierte Modelle für die Performanzvorhersage zu verwenden. Dazu haben wir zuerst die Modelle in einem Parametrisierungsschritt mit den nötigen Ressourcenverbräuchen angereichert. Als nächstes konnten wir die Performanzvorhersage durchführen. In unserer Fallstudie zeigte sich, dass der Vorhersagefehler für die Antwortzeit eines Systems bei ca. 10% liegt, und damit die coevolvierten Modelle für die Abschätzung der Performanz eines realen Systems verwendet werden können