Improving Prolog programs: Refactoring for Prolog

Refactoring is an established technique from the object-oriented (OO) programming community to restructure code: it aims at improving software readability, maintainability and extensibility. Although refactoring is not tied to the OO-paradigm in particular, its ideas have not been applied to Logic Programming until now. This paper applies the ideas of refactoring to Prolog programs. A catalogue is presented listing refactorings classified according to scope. Some of the refactorings have been adapted from the OO-paradigm, while others have been specifically designed for Prolog. The discrepancy between intended and operational semantics in Prolog is also addressed by some of the refactorings. In addition, ViPReSS, a semi-automatic refactoring browser, is discussed and the experience with applying ViPReSS to a large Prolog legacy system is reported. The main conclusion is that refactoring is both a viable technique in Prolog and a rather desirable one.Comment: To appear in Theory and Practice of Logic Programming (TPLP

Refactorización en código Fortran heredado

Este artículo exhibe los obstáculos hallados por los programadores en las tareas de mantenimiento de software heredado escrito en Fortran. Por un lado se se~nalan las dificultades que se presentan en los procesos de comprensión, adaptación y mejora de este tipo de software. Por otro lado se encuadra una solución a este problema proponiendo la refactorización como técnica para ser aplicada en dichos procesos, intentando además, desmitificar los prejuicios que Fortran ha adquirido dentro del ámbito de la producción de software. Asimismo se describe detalladamente la implementación de algunas refactorizaciones en Photran, una nueva herramienta gráfica automatizada de refactorización para Fortran.Presentado en el VII Workshop Ingeniería de Software (WIS

Refactorización en código Fortran heredado

Este artículo exhibe los obstáculos hallados por los programadores en las tareas de mantenimiento de software heredado escrito en Fortran. Por un lado se se~nalan las dificultades que se presentan en los procesos de comprensión, adaptación y mejora de este tipo de software. Por otro lado se encuadra una solución a este problema proponiendo la refactorización como técnica para ser aplicada en dichos procesos, intentando además, desmitificar los prejuicios que Fortran ha adquirido dentro del ámbito de la producción de software. Asimismo se describe detalladamente la implementación de algunas refactorizaciones en Photran, una nueva herramienta gráfica automatizada de refactorización para Fortran.Presentado en el VII Workshop Ingeniería de Software (WIS)Red de Universidades con Carreras en Informática (RedUNCI

Generating rewritable abstract syntax trees - A foundation for the rapid development of source code transformation tools

Abstract. Building a production-quality refactoring engine or similar source code transformation tool traditionally requires a large amount of hand-written, language-specific support code. We describe a system which reduces this overhead by allowing both a parser and a fully rewritable AST to be generated automatically from an annotated grammar, requiring little or no additional handwritten code. The rewritable AST is ideal for implementing program transformations that preserve the formatting of the original sources, including spacing and comments, and the system can be augmented to allow transformation of Cpreprocessed sources even when the target language is not C or C++. Moreover, the AST design is fully customizable, allowing it to resemble a hand-coded tree. The amount of required annotation is typically quite small, and the annotated grammar is often an order of magnitude smaller than the generated code

Refactoring de código estructurado

Desde su creación los sistemas de software han sido utilizados, probados e incluso modificados. A lo largo de este período el software y los seres humanos han interactuado entre sí en forma cotidiana, no pudiéndose concebir la vida actual del hombre sin la presencia de los sistemas informáticos (comunicaciones, medicina, transporte, etc.). A tal punto que paulatinamente los procesos de negocio consumen cada vez más información procesada por los sistemas de software, incluso hasta a ser controlados y guiados por software. Por ende, las especificaciones y el diseño de estos sistemas requieren de supuestos acerca de la aplicación dada, del dominio de la aplicación y de su ámbito operativo, hecho que a su vez se refleja en el software.Facultad de Informátic

Fortran refactoring for legacy systems

The motivation of this work comes from a Global Climate Model (GCM) Software which was in great need of being updated. This software was implemented by scientists in the ’80s as a result of meteorological research. Written in Fortran 77, this program has been used as an input to make climate predictions for the Southern Hemisphere. The execution to get a complete numerical data set takes several days. This software has been programmed using a sequential processing paradigm. In these days, where multicore processors are so widespread, the time that an execution takes to get a complete useful data set can be drastically reduced using this technology. As a first objective to reach this goal of reengineering we must be able to understand the source code. An essential Fortran code characteristic is that old source code versions became unreadable, not comprehensive and sometimes “ejects” the reader from the source code. In that way, we can not modify, update or improve unreadable source code. Then, as a first step to parallelize this code we must update it, turn it readable and easy to understand. The GCM has a very complex internal structure. The program is divided into about 300 .f (Fortran 77) files. These files generally implement only one Fortran subroutine. Less than 10% of the files are used for common blocks and constants. Approximately 25% of the lines in the source code are comments. The total number of Fortran source code lines is 58000. A detailed work within the source code brings to light that [74]: 1 About 230 routines are called/used at run time. Most of the runtime is spent in routines located at deep levels 5 to 7 in the dynamic call graph from the main routine. 2 The routine with most of the runtime (the top routine from now on) requires more than 9% of the total program runtime and is called about 315000 times. 3 The top 10 routines (the 10 routines at the top of the flat profile) require about 50% of total runtime. Two of them are related to intrinsic Fortran functions. Our first approach was using a scripting language and Find & Replace tools trying to upgrade the source code, this kind of code manipulation do not guarantee preservation of software behavior. Then, our goal was to develop an automated tool to transform legacy software in more understandable, comprehensible and readable applying refactoring as main technique. At the same time a catalog of transformation to be applied in Fortran code is needed as a guide to programmers through this process.Es revisado por: http://sedici.unlp.edu.ar/handle/10915/9703Facultad de Informátic

Scaling testing of refactoring engines.

Definir e implementar refatoramentos não é uma tarefa trivial, pois é difícil definir todas as pré-condições necessárias para garantir que a transformação preserve o comportamento observável do programa. Com isso, ferramentas de refatoramentos podem ter condições muito fracas, condições muito fortes e podem aplicar transformações que não seguem a definição do refatoramento. Na prática, desenvolvedores escrevem casos de testes para checar suas implementações de refatoramentos e se preocupam em evitar esses tipos de bugs, pois 84% das asserções de testes do Eclipse e JRRT testam as ferramentas com relação aos bugs citados anteriormente. No entanto, as ferramentas ainda possuem esses bugs. Existem algumas técnicas automáticas para testar ferramentas de refatoramentos, mas elas podem ter limitações relacionadas com tipos de bugs que podem ser detectados, geração de entradas de testes, automação e performance. Este trabalho propõe uma técnica para escalar testes de ferramentas de refatoramentos. A técnica contém DOLLY um gerador automático de programas Java e C, no qual foram adicionadas mais construções de Java (classes e métodos abstratos e interface) e uma estratégia de pular algumas entradas de testes com o propósito de reduzir o tempo de testar as implementações de refatoramentos. Foi proposto um conjunto de oráculos para avaliar a corretude das transformações, dentre eles SAFEREFACTORIMPACT que identifica falhas relacionadas com mudanças comportamentais. SAFEREFACTORIMPACT gera testes apenas para os métodos impactados pela transformação. Além disso, foi proposto um novo oráculo para identificar transformações que não seguem a definição do refatoramento e uma nova técnica para identificar condições muito fortes. A técnica proposta foi avaliada em 28 implementações de refatoramentos de Java (Eclipse e JRRT) e C (Eclipse) e detectou 119 bugs relacionados com erros de compilação, mudanças comportamentais, condições muito fortes, e transformações que não seguem a definição do refatoramento. Usando pulos de 10 e 25 no gerador de programas, a técnica reduziu em 90% e 96% o tempo para testar as implementações de refatoramentos, enquanto deixou de detectar apenas 3% e 6% dos bugs, respectivamente. Além disso, detectou a primeira falha geralmente em alguns segundos. Por fim, com o objetivo de avaliar a técnica proposta com outras entradas de testes, foram avaliadas implementações do Eclipse e JRRT usando os programas de entrada das suas coleções de testes. Neste estudo, nossa técnica detectou mais 31 bugs não detectados pelos desenvolvedores das ferramentas.Defining and implementing refactorings is a nontrivial task since it is difficult to define preconditions to guarantee that the transformation preserves the program behavior. There fore, refactoring engines may have overly weak preconditions, overly strong preconditions, and transformation issues related to the refactoring definition. In practice, developers manually write test cases to check their refactoring implementations. We find that 84% of the test suites of Eclipse and JRRT are concerned with identifying these kinds of bugs. However, bugs are still present. Researchers have proposed a number of techniques for testing refactoring engines. Nevertheless, they may have limitations related to the bug type, program generation, time consumption, and number of refactoring engines necessary to evaluate the implementations. In this work, we propose a technique to scale testing of refactoring engines by extending a previous technique. It automatically generates programs as test inputs using Dolly, a Java and C program generator. We add more Java constructs in DOLLY, such abstract classes and methods and interface, and a skip parameter to reduce the time to test the refactoring implementations by skipping some consecutive test inputs. Our technique uses SAFEREFACTORIMPACT to identify failures related to behavioral changes. It generates test cases only for the methods impacted by a transformation. Also, we propose a new oracle to evaluate whether refactoring preconditions are overly strong by disabling a subset of them. Finally, we present a technique to identify transformation issues related to the refactoring definition. We evaluate our technique in 28 refactoring implementations of Java (Eclipse and JRRT) and C (Eclipse) and find 119 bugs related to compilation errors, behavioral changes, overly strong preconditions, and transformation issues. The technique reduces the time in 90% and 96% using skips of 10 and 25 in Dolly while missing only 3% and 6% of the bugs, respectively. Additionally, it finds the first failure in general in a few seconds using skips. Finally, we evaluate our proposed technique by using other test inputs, such as the input programs of Eclipse and JRRT refactoring test suites. We find 31 bugs not detected by the developers.Cape

Cobertura entre pruebas a distintos niveles para refactorizaciones más seguras

Esta tesis busca encontrar una práctica metodológica que permita definir distintos niveles de pruebas que operen como garantía de refactorizaciones seguras, independientemente del alcance de las mismas. Se enmarca en el tema general de refactoring, con elementos de Test Driven Development (TDD), utilizando las prácticas recomendadas en el marco de Behavior Driven Development (BDD) y de Acceptance Test Driven Development (ATDD). La práctica de refactoring descansa fuertemente en la existencia de pruebas unitarias automatizadas, que funcionan como red de seguridad que garantiza que el comportamiento de la aplicación no varía luego de una refactorización. Sin embargo, este simple enunciado no prevé que hay ocasiones en que las pruebas dejan de funcionar al realizar las refactorizaciones, con lo cual se pierde la sincronización entre código y pruebas, y la cualidad de red de seguridad de estas últimas. Esto es especialmente cierto ante refactorizaciones estructurales y rediseños macro. Por lo tanto, y dado que el uso de pruebas como red de contención es uno de los supuestos más fuertes de la práctica del refactoring, vamos a desarrollar, como objetivo de esta tesis, una práctica metodológica para permitir definir distintos niveles de pruebas que aseguren distintos tipos de refactorizaciones, validándola con un caso de estudio y apoyándonos en una herramienta automática desarrollada en el marco de este trabajo.Facultad de Informátic

Refactoring Haskell programs

EThOS - Electronic Theses Online ServiceGBUnited Kingdo