Made available in DSpace on 2014-06-12T15:53:55Z (GMT). No. of bitstreams: 2 arquivo6386_1.pdf: 3378493 bytes, checksum: 2ea65399678659e12b1393a14ebbb799 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2007 / Refatoramentos são geralmente propostos de maneira ad hoc, porque é difíıcil provar formalmente que eles preservam comportamento. Na prática, desenvolvedores, mesmo utilizando ferramentas de refatoramento, têm que usar compilação e testes para garantir que os refatoramentos são corretos. Esse cenário não é desejado principalmente no desenvolvimento de sistemas críticos. No caso de refatoramento de modelos de objetos, boa parte das transformações se baseia em argumentações informais. Um outro problema é que as noções de equivalência para modelos de objetos são muito concretas, no sentido que elas assumem que os modelos devem possuir operações, ou os mesmos nomes e estruturas. Isso não é adequado em várias situações: durante refatoramento de modelos, quando usamos elementos do modelo que são auxiliares, ou quando os modelos comparados possuem elementos distintos, mas que são relacionados. Neste trabalho, nosso objetivo é propor um conjunto de transformações que preservam semântica para Alloy, que é uma linguagem formal de modelagem orientada a objetos. Nós especificamos em PVS um conjunto de regras de boa formação e estendemos a semântica para Alloy, e mostramos que as transformações propostas são corretas no provador de teoremas de PVS. Mostramos também que este conjunto de transformações ´e relativamente completo no sentido que, com ele, podemos derivar um conjunto representativo de transformações. Além disso, propomos uma noção de refinamentos mais abstrata e flexível para modelos de objetos, na qual nosso conjunto de transformações se baseia. Esta noção foi especificada em PVS, onde provamos algumas propriedades da mesma. Além de provarmos que ela é composicional, relacionamos a mesma com a noção de refinamento de dados para Z. Estas transformações são úteis não só para derivarmos refatoramentos formalmente, como também para otimizações. Além disso, mostramos que as transformações podem ser utilizadas para derivar refatoramentos que introduzem formalmente padrões de projeto em Alloy

Submitted by Maria Medeiros (maria.dilva1@ufcg.edu.br) on 2018-06-05T13:58:29Z No. of bitstreams: 1 MELINA MONGIOVI CUNHA LIMA SABINO - TESE (PPGCC) 2016.pdf: 4752189 bytes, checksum: e1034c42632a733df07a498a7eea6d0b (MD5) / Made available in DSpace on 2018-06-05T13:58:29Z (GMT). No. of bitstreams: 1 MELINA MONGIOVI CUNHA LIMA SABINO - TESE (PPGCC) 2016.pdf: 4752189 bytes, checksum: e1034c42632a733df07a498a7eea6d0b (MD5) Previous issue date: 2016 / Capes / 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.

Submitted by Kilvya Braga (kilvyabraga@hotmail.com) on 2018-05-14T14:15:46Z No. of bitstreams: 1 Flavio Medeiros - Tese.pdf: 4026286 bytes, checksum: b8f88ed9bff48d2f4eed7e9d7039c5ba (MD5) / Made available in DSpace on 2018-05-14T14:15:46Z (GMT). No. of bitstreams: 1 Flavio Medeiros - Tese.pdf: 4026286 bytes, checksum: b8f88ed9bff48d2f4eed7e9d7039c5ba (MD5) Previous issue date: 2016 / Desde os anos 70, o pré-processador C é amplamente utilizado na prática para adaptar sistemas para diferentes plataformas e cenários de aplicação. Na academia, no entanto, o pré-processador tem recebido fortes críticas desde o início dos anos 90. Os pesquisadores têm criticado a sua falta de modularidade, a sua propensão para introduzir erros sutis e sua ofuscação do código fonte. Para entender melhor os problemas de usar o pré-processador C,considerando a percepção dos desenvolvedores, realizamos 40 entrevistas e uma pesquisa entre 202 desenvolvedores. Descobrimos que os desenvolvedores lidam com três problemas comuns na prática: erros relacionados à configuração, testes combinatórios e compreensão do código. Os desenvolvedores agravam estes problemas ao usar diretivas não disciplinadas, as quais não respeitam a estrutura sintática do código. Para evoluir famílias de programas de forma segura, foram propostas duas estratégias para a detecção de erros relacionados à configuração e um conjunto de 14 refatoramentos para remover diretivas não disciplinadas. Para lidar melhor com a grande quantidade de configurações do código fonte, a primeira estratégia considera todo o conjunto de configurações do código fonte e a segunda estratégia utiliza amostragem. Para propor um algoritmo de amostragem adequado, foram comparados 10 algoritmos com relação ao esforço (número de configurações para testar) e capacidade de detecção de erros (número de erros detectados nas configurações da amostra). Com base nos resultados deste estudo, foi proposto um algoritmo de amostragem. Estudos empíricos foram realizados usando 40 sistemas C do mundo real. Detectamos 128 erros relacionados à configuração, enviamos 43 correções para erros ainda não corrigidos e os desenvolvedores aceitaram 65% das correções. Os resultados de nossa pesquisa mostram que a maioria dos desenvolvedores preferem usar a versão refatorada,ou seja,disciplinada do código fonte,ao invés do código original com as diretivas não disciplinadas. Além disso,os desenvolvedores aceitaram 21 (75%) das 28 sugestões enviadas para transformar diretivas não disciplinadas em disciplinadas. Nossa pesquisa apresenta resultados úteis para desenvolvedores de código C durante suas tarefas de desenvolvimento, contribuindo para minimizar o número de erros relacionados à configuração, melhorar a compreensão e a manutenção do código fonte e orientar os desenvolvedores para realizar testes combinatórios. / Since the 70s, the C preprocessor is still widely used in practice in a numbers of projects, including Apache,Linux ,and Libssh, totail or systems to different platforms and application scenarios. In academia,however, the preprocess or has received strong critic is msinceatl east the early 90s. Researchers have criticized its lack of separation of concerns, its proneness to introduce subtle errors, and its obfuscation of the source code. To better understand the problems of using the C preprocessor, taking the perception of developers into account, we conducted 40 interviewsandasurveyamong 202 developers. We found that developers deal with three common problems in practice: configuration-related bugs, combinatorial testing, and code comprehension. Developers aggravate these problems when using undisciplined directives (i.e., bad smells regarding preprocessor use), which are preprocessor directives thatdo notrespect thesyntactic structureof thesource code. To safely evolve preprocessor based program families, we proposed strategies to detect configuration-relatedbugs and bad smells, and a set of 14 refactorings to remove bad smells. To better deal with exponential configuration spaces, our strategies uses variability-aware analysis that considers the entire set of possible configurations, and sampling, which allows to reuse C tools that consider only one configuration at a time to detect bugs. To propose a suitable sampling algorithm, we compared 10 algorithms with respect to effort (i.e., number of configurations to test) andbug-detection capabilities (i.e.,numberofbugs detected in the sampled configurations). Based on the results, we proposed a sampling algorithm with an useful balance between effort and bug-detection capability. We performed empirical studies using a corpus of 40 C real-world systems. We detected 128 configuration-related bugs, submitted 43 patches to fix bugs not fixed yet, and developers accepted 65% of the patches. The results of our survey show that most developers prefer to use the refactored (i.e., disciplined) version of the code instead of the original code with undisciplined directives. Furthermore, developers accepted 21 (75%) out of 28 patches submitted to refactor undisciplined into disciplined directives. Our work presents useful findings for C developers during their development tasks, contributing to minimize the chances of introducing configuration-related bugs and bad smells, improve code comprehension, and guide developers to perform combinatorial testing.

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.

Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-08-31T23:21:36Z No. of bitstreams: 1 MELINA MANGIOVI CUNHA LIMA SABINO - PPGCC DISSERTAÇÃO 2013..pdf: 29220438 bytes, checksum: 42486beccb60e73d444ba221ab430942 (MD5) / Made available in DSpace on 2018-08-31T23:21:36Z (GMT). No. of bitstreams: 1 MELINA MANGIOVI CUNHA LIMA SABINO - PPGCC DISSERTAÇÃO 2013..pdf: 29220438 bytes, checksum: 42486beccb60e73d444ba221ab430942 (MD5) Previous issue date: 2013-03-11 / CNPq / Refatoramentos são transformações que melhoram a estrutura interna do programa preservando seu comportamento observável. Na prática, desenvolvedores utilizam testes de regressão e ferramentas para garantir que o refatoramento preservou o comportamento do programa. Entretanto, ferramentas de refatoramentos possuem bugs. Além disso, a coleção de testes pode ser modificada pela transformação aplicada manualmente ou pela ferramenta. Se a transformação não for aplicada corretamente, esta pode modificar a coleção de testes incapacitando-a de detectar a mudança comportamental. Por fim, a coleção pode não ser adequada para testar a transformação, pois os casos de testes podem não exercitar as entidades impactadas pela transformação. Este problema se torna maior se a coleção de testes for grande, tornando a execução de toda a coleção de testes custosa. Nós propomos uma abordagem para avaliar preservação de comportamento em refatoramentos baseada em geração automática de testes e análise de impacto da mudança. A abordagem analisa o impacto da mudança e gera automaticamente testes apenas para os métodos impactados pela transformação. Implementamos uma ferramenta chamada SafeRefactorlmpact para avaliar a preservação de comportamento. Esta utiliza Safira, ferramenta que implementamos para realizar a análise de impacto. Avaliamos SafeRefactorlmpact em um conjunto de 10 transformações aplicadas a um sistema real, e em uma técnica para testar implementações de refatoramentos. Além disso, comparamos SafeRefactorlmpact com SafeRefactor, uma ferramenta que também avalia preservação de comportamento em refatoramentos mas não utiliza análise de impacto. Nós comparamos com relação às mudanças comportamentais identificadas, quantidade de métodos identificados para geração de testes, tempo total da análise da transformação, quantidade de casos de testes gerados e cobertura da mudança dos testes gerados. O SafeRefactorlmpact conseguiu identificar mudanças comportamentais não identificadas pelo SafeRefactor, reduziu em torno de 60% o tempo para testar implementações de refatoramentos, mostrou-se menos sensível ao tempo limite passado para o gerador automático de testes, além da análise de impacto permitir a diminuição de algumas limitações do gerador automático de testes enfrentadas pelo SafeRefactor. / Refactorings are transformations that improve the internal structure of the program while preserving its observable behavior. In practice, developers use regression tests and refactoring tools to ensure that the refactoring has preserved the behavior of the program. However, refactoring tools may have bugs. In addition, the test suite may be modified by the transformation applied manually or using a refactoring tool. If the transformation is applied incorrectly, it can change the test suite by disabling it to detect the behavioral change. Finally, the test suite may be inappropriate to test the transformation because the test cases may not exercise the change. This problem can get worse if the test suite is large. This way, it is time consuming executing the entire test suite. We propose an approach for evaluating whether a transformation is behavior preserving based on change impact analysis. This approach performs a change impact analysis and it automatically generates tests only to the methods impacted by the transformation. We implemented a tool called SafeRefactorlmpact to evaluate behavior preservation. It uses Safira, a tool that we implemented to identify the methods impacted by a change in the program. We evaluate SafeRefactorlmpact in a set of 10 transformations applied to a real system and to a technique to test refactoring implementations. Moreover, we compared the SafeRefactorlmpact with SafeRefactor, a tool that also evaluates whether a transformation preserves the program behavior. The difference is that SafeRefactor does not use the impact analysis. The SafeRefactorlmpact managed to identify behavioral changes not identified by SafeRefactor; it reduced in 60% the total time to analyze the refactoring implementations; it showed to be less sensitive to the time limit to generate the tests; and the impact analysis allows the reduction of some limitations of the automatic tests generator faced by the SafeRefactor.