Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-08-31T23:09:48Z No. of bitstreams: 1 GUSTAVO WAGNER DINIZ MENDES - DISSERTAÇÃO PPGCC 2014..pdf: 7175302 bytes, checksum: c99a663c85f93c308e26cc6d963f5d2e (MD5) / Made available in DSpace on 2018-08-31T23:09:48Z (GMT). No. of bitstreams: 1 GUSTAVO WAGNER DINIZ MENDES - DISSERTAÇÃO PPGCC 2014..pdf: 7175302 bytes, checksum: c99a663c85f93c308e26cc6d963f5d2e (MD5) Previous issue date: 2014-03-13 / Refatorar um programa é o ato de mudar sua estrutura visando melhorar algum aspecto arquitetural, sem que se mude seu comportamento observável. Desenvolvedores utilizam ferramentas como Eclipse e NetBeans para auxiliá-los no refatoramento de seus programas. Essas ferramentas implementam um conjunto de condições para garantir que as transformações realizadas não mudem o comportamento observável do programa. Porém, não é trivial identificar todas as condições necessárias para que um refatoramento seja correto devido à complexidade da semântica das linguagens e por não haver uma definição formal das linguagens e consequentemente dos refatoramentos. Os desenvolvedores de ferramentas de refatoramento costumam, por não haver uma definição formal, implementar os refatoramentos de acordo com seus conhecimentos da linguagem de programação. Na prática, desenvolvedores utilizam coleções de testes para avaliar a corretude de suas implementações. Entretanto, não existem evidências que os desenvolvedores utilizem um processo sistemático na definição dessas coleções. Neste trabalho, propomos uma técnica para testar implementações de refatoramentos de programas C. Ela consiste em cinco fases. Primeiramente, geramos automaticamente diversos programas C para serem refatorados a partir do CDOLLY, que foi proposto baseado em uma especificação em Alloy. Depois, geramos automaticamente uma coleção de testes de unidade dos programas via o CATESTER. Em seguida, aplicamos o refatoramento através do CREXECUTOR nos programas gerados utilizando a ferramenta a ser testada. Após isso, executamos a coleção de testes nos programas refatorados e, por fim, classificamos os erros de compilação e mudanças comportamentais identificados em bugs. Avaliamos a nossa técnica na implementação de oito refatoramentos do Eclipse CDT. Estes refatoramentos não só modificam a estrutura do programa, como também o corpo das funções, como o refatoramento Extract Function. Detectamos 41 bugs, que introduzem erros de compilação no programa resultante, e seis bugs relacionados a mudanças comportamentais. Replicamos manualmente os bugs encontrados em implementações de refatoramentos do NetBeans CND, Xrefactory e OpenRefactory e detectamos 29 bugs nessas ferramentas. / Refactoring a program is the act of changing its structure in order to improve any architectural aspect, without changing its observable behavior. Developers use tools like Eclipse and NetBeans to help refactoring their programs. These tools implement a set of conditions to ensure that the transformations performed do not change the observable behavior of the program. However, it is not easy to identify ali the necessary conditions for a refactoring to be correct due to the semantic complexity of the languages, mainly because the languages are not formally proved and neither the refactorings. In practice, developers often use collections of tests to assess the correctness of their implementations. However, there is no evidence of having systematic process in the definition of this collection. In this work, we propose a technique to test refactoring implementations of C programs. It consists of five phases. First, we generate automatically several C programs to be refactored from CDOLLY, which has been proposed based on a specification in Alloy. Then, we generate automatically a collection of unit tests of the programs via CATESTER. We then apply the refactoring through CREXECUTOR on the generated programs using the tool to be tested. After this, we execute the test collection in the refactored programs and finally we classify the compilation errors and behavioral changes in bugs. We evaluated our technique in the implementation of eight refactorings of Eclipse CDT. These refactorings not only modify the program structure, but also the body functions, such as the refactoring Extract Function. We detected 41 bugs, which introduce compilation errors in the resulting program, and six bugs related to behavioral changes. We analyzed manually these bugs in refactoring implementations of NetBeans, Xrefactory and OpenRefactory and identified 29 bugs in these tools.