[pt] A organização participante deste trabalho buscou implantar atividades relacionadas à manutenção de software em função de problemas relacionados à grande ocorrência de defeitos, constantes retrabalhos, entre outros. Para suprimir esses problemas, inicialmente, foi elaborado um estudo preliminar do sistema em questão, avaliando o estado atual da manutenção de software. Diante do diagnóstico realizado, ficou evidente a necessidade de mudanças na maneira como eram conduzidas as atividades de manutenção do sistema. Com isso, iniciou-se a busca por alternativas de melhorias com objetivo de reduzir a ocorrência de defeitos e também aumentar a manutenibilidade do sistema. Sabendo quais são os problemas e o que poderia ser feito para melhorar, propôs-se adotar algumas práticas do modelo de maturidade de manutenção de software - SMmm e integrar os conceitos destas práticas em um processo definido e adaptado às necessidades do sistema. Para apoiar essa implementação, a infraestrutura utilizada foi a plataforma Team Foundation Service - TFS que colaborou com a implementação das práticas selecionadas segundo as exigências do modelo SMmm, resultando em um processo definido apoiado pelo TFS que implementa parcialmente o modelo SMmm. Este trabalho apresenta um estudo de caso com o objetivo de avaliar os benefícios proporcionados pela utilização de algumas práticas do modelo SMmm. A avaliação realizada confronta os dados do estudo preliminar com dados coletados após adoção das práticas, os resultados analisados apontaram uma redução significativa da quantidade de defeitos. / [en] The company participating in this work sought to implement activities related to software maintenance due to problems related to the great occurrence of defects, constant rework, among others. To suppress these problems, a preliminary study of the system in question has been elaborated, evaluating the current state of software maintenance. In view of the diagnosis, the necessity of changes became evident concerning the way that the system maintenance activities were conducted. With this, the search for alternatives of improvements began with the objective of reducing the occurrence of defects and also increase the maintainability of the system. Knowing the problems and what could be done to improve; it was proposed to accede some practices of the software maintenance maturity model - SMmm and to integrate the concepts of these practices into a defined process and adapted to the needs of the system. To support this implementation, the infrastructure used was the Team Foundation Service - TFS platform that collaborated with the implementation of the selected practices according to the requirements of the SMmm model, resulting in a defined process supported by the TFS that partially implements the SMmm model. This paper presents a case study with the objective of evaluating the benefits provided by the use of some practices of the SMmm model. The evaluation carried out compared the data from the preliminary study with data collected after adoption of the practices, the analyzed results pointed out a significant reduction in the number of issues.

[pt] A Mineração de Repositórios de Software é um campo de pesquisa que extrai e analisa informações disponíveis em repositórios de software, como sistemas de controle de versão e gerenciadores de issues. Atualmente, diversos trabalhos nesta área de pesquisa têm utilizado as ferramentas da Web Semântica durante o processo de extração a fim de superar algumas limitações que as abordagens tradicionais enfrentam. O objetivo deste trabalho é estender estas abordagens que utilizam a Web Semântica para minerar informações não consideradas atualmente. Uma destas informações é o relacionamento existente entre as revisões do controle de versão e as mudanças que ocorrem no Abstract Syntax Trees dos arquivos modificados por essas revisões. Adicionalmente, esta nova abordagem também permite modelar a interdependência entre os projetos de software, suas licenças e extrair informações dos builds gerados por ferramentas de integração contínua. A validação desta nova abordagem é demonstrada através de um conjunto de questões que são feitas por desenvolvedores e gerentes durante a execução de um projeto e que foram identificadas em vários trabalhos da literatura. Demonstramos como estas questões foram convertidas para consultas SPARQL e como este trabalho consegue responder às questões que não são respondidas ou são respondidas parcialmente em outras ferramentas. / [en] The Mining of Software Repositories is a field of research that extracts and analyzes information available in software repositories, such as version control systems and issue trackers. Currently, several research works in this area have used Semantic Web tools during the extraction process to overcome some limitations that traditional approaches face. The objective of this work is to extend the existing approaches that use Semantic Web tools to mine information not considered in these works. The objective of this work is to extend these approaches using the Semantic Web to mine information not currently considered. One of these information is the relationship between revisions of version control and the changes that occur in the Abstract Syntax Trees of files modified by these revisions. Additionally, this new approach also allows modeling the interdependence of software projects, their licenses and extracting information from builds generated by continuous integration tools. The validation of this approach is demonstrated through a set of questions that are asked by developers and managers during the execution of a project and have been identified in various works in the literature. We show how these questions were translated into SPARQL queries and how this work can answer the questions that are not answered or are partially answered in other tools.

[pt] Características são abstrações-chave para o desenvolvimento e manutenção de linhas de produto de software. Um desafio encarado na manutenção de linhas de produto de software é o entendimento das dependências que existem entre características. No código-fonte, uma dependência entre características ocorre sempre que um elemento de programa dentro dos limites de implementação de uma característica depende de elementos externos a esta característica. Exemplos são atributos ou métodos definidos na implementação de uma característica, mas utilizados no código responsável pela implementação de outra característica. A medida que desenvolvedores modificam o código-fonte associado com uma característica, eles devem garantir que outras características são consistentemente atualizadas com as novas mudanças – as chamadas propagações de mudanças. No entanto, a apropriada propagação de mudanças não é uma tarefa trivial, pois características geralmente não são modularizadas no código-fonte. Dessa forma, dado uma mudança em uma determinada característica, é desafiador revelar quais (partes de) outras características também devem ser alteradas. Propagação de mudanças se torna, portanto, um aspecto central e não-trivial da manutenção de linhas de produto de software. Desenvolvedores podem negligenciar partes importantes de código que deveriam ser revisadas ou alteradas, portanto não propagando mudanças de forma completa. Por outro lado, desenvolvedores também podem analisar de forma desnecessária partes de código que não são relevantes para a tarefa de manutenção de características, portanto aumentando o esforço de manutenção ou até propagando mudanças de forma indevida. A criação de um bom modelo mental da estrutura das dependências de características se torna essencial para ganhar compreensão sobre o complexo relacionamento de características com o objetivo de propagar mudanças de forma apropriada. Infelizmente, não existe entendimento no estado-da-arte sobre propriedades estruturais de dependências de características que afetam a propagação de mudanças. Este entendimento ainda não é possível, pois: (i) não existe meios de caracterização e quantificação para propriedades estruturais de dependências de características, e (ii) não existem investigações empíricas sobre a influência dessas propriedades na propagação de mudanças. Nesse contexto, esta tese apresenta três contribuições para superar os problemas acima mencionados. Primeiro, foi desenvolvido um estudo para entender a propagação de mudanças na presença de dependência de características em várias linhas de produto industriais. Segundo, é proposto um arcabouço de medidas com o propósito de quantificar propriedades estruturais de dependências de características. Nesse contexto, também foi desenvolvido um estudo revelando que métricas convencionais tipicamente aplicadas em trabalhos de linha de produto, tais como a métrica de acoplamento, não são indicadores efetivos da propagação de mudanças em linhas de produto de software. As métricas propostas nesta tese superaram consistentemente as métricas convencionais estudadas. Terceiro, esta tese propõe um método para auxiliar a propagação de mudanças encarando informações sobre a organização de dependência de características encarando-as como um problema de agrupamento. Foi avaliado se a organização de informações proposta nesta tese tem potencial para auxiliar desenvolvedores a propagar mudanças em linhas de produto de software. / [en] Features are the key abstraction to develop and maintain software product lines. A challenge faced in the maintenance of product lines is the understanding of the dependencies that exist between features. In the source code, a feature dependency occurs whenever program elements within the boundaries of a feature s implementation depend on elements external to that feature. Examples are either attributes or methods defined in the realisation of a feature, but used in the code realising other features. As developers modify the source code associated with a feature, they must ensure that other features are consistently updated with the new changes – the so-called change propagation. However, appropriate change propagation is far from being trivial as features are often not modularised in the source code. In this way, given a change in a certain feature, it is challenging to reveal which (part of) other features should also change. Change propagation becomes, therefore, a central and non-trivial aspect of software product-line maintenance. Developers may overlook important parts of the code that should be revised or changed, thus not fully propagating changes. Conversely, they may also unnecessarily analyse parts that are not relevant to the feature-maintenance task at hand, thereby increasing the maintenance effort or even mis-propagating changes. The creation of a good mental model based on the structure of feature dependencies becomes essential for gaining insight into the intricate relationship between features in order to properly propagate changes. Unfortunately, there is no understanding in the state of the art about structural properties of feature dependencies that affect change propagation. This understanding is not yet possible as: (i) there is no conceptual characterisation and quantification means for structural properties of feature dependency, and (ii) there is no empirical investigation on the influence of these properties on change propagation. In this context, this thesis presents three contributions to overcome the aforementioned problems. First, we develop a study to understand change propagation in presence of feature dependencies in several industry-strength product lines. Second, we propose a measurement framework intended to quantify structural properties of feature dependencies. We also develop a study revealing that conventional metrics typically used in previous research, such as coupling metrics, are not effective indicators of change propagation in software product lines. Our proposed metrics consistently outperformed conventional metrics. Third, we also propose a method to support change propagation by facing the organisation of feature dependency information as a clustering problem. We evaluate if our proposed organisation has potential to help developers to propagate changes in software product lines.

[pt] Em um sistema de software, as anomalias de código indicam problemas estruturais que podem ser resolvidos através da refatoração. No entanto, desenvolvedores podem negligenciar ou acabar criando novas anomalias ao refatorar. Pouco foi relatado sobre os efeitos benéficos e prejudiciais da refatoração de anomalias de código. Evidências sugerem que os desenvolvedores frequentemente precisam aplicar uma sequência de refatorações (refatoração em lote) para remover completamente as estruturas anômalas. Assim, nesta tese, realizamos uma série de estudos para entender o impacto de refatorações simples e em lote em anomalias de código. Em nossos primeiros estudos, analisamos com que frequência os tipos de refatoração comumente usados afetam a densidade de anomalias ao longo das histórias de dezenas de projetos. Mesmo que 79,4 por cento das refatorações tenham tocado em elementos anômalos, 57 por cento não reduziram suas ocorrências. Surpreendentemente, apenas 9,7 por cento das refatorações removeram anomalias de código, enquanto 33 por cento induziram a introdução de novas. Por um lado, observamos padrões nocivos de introdução de anomalias. Por outro lado, observamos que muitas anomalias podem ser removidas apenas por refatorações em lote. Assim, nossos últimos estudos investigam o impacto de refatorações em lote nas anomalias. Mesmo quando aplicadas em lotes, as refatorações tendem a não afetar ou mesmo aumentar a densidade de anomalias. Também identificamos padrões entre tipos de lotes e tipos de anomalias, levando-nos à criação de heurísticas que podem orientar os desenvolvedores durante tarefas de remoção de anomalias de código. O último estudo avaliou essas heurísticas e concluímos que os resultados são promissores. / [en] Code smells in a program represent indications of structural quality problems, which can be addressed by software refactoring. However, developers may neglect or end up creating new code smells through single refactoring. Little has been reported about recurring beneficial and harmful effects of refactoring on the program structural quality. As a consequence, developers still miss guidance along non-trivial smell-removing tasks. In fact, evidence suggests developers often need to apply a sequence of refactorings, so-called batch refactoring, to entirely remove a smelly code structure. Thus, in this thesis, we have conducted a series of studies to understand the impact of single and batch refactorings on code smells. In our first studies, we analyze how often commonly-used types of single refactoring affect the density of code smells along the version histories of dozens of projects. Even though 79.4 percent of the refactorings touched smelly elements, 57 percent had no impact on the smell removal. Surprisingly, only 9.7 percent of refactorings removed smells, while 33 percent induced the introduction of new ones. On one hand, we observed that harmful refactoring-smell patterns could be used to guide developers to avoid smell-inducing refactoring. On the other hand, we observed that many smells can be removed only through batch refactoring. Thus, our last studies investigate the impact of batch refactorings on smells. Even when applied in batches, refactorings tend to maintain or even increase the density of code smells. We also identified common batch-smell patterns, which enable us to create heuristics that can guide developers through smell-removing tasks. The last study evaluated those heuristics, and we conclude the outcomes are promising.

[pt] Os elementos de código geralmente mudam ao longo da evolução do sistema, o que implica em uma eventual degradação estrutural do código fonte. Sintomas recorrentes de tal degradação são chamados anomalias de código. Estudos sugerem que quanto mais anomalias de código afetam um sistema, mais alta se torna a propensão a bugs dos elementos de código. Para lidar com tal degradação da qualidade estrutural do código, desenvolvedores geralmente aplicam refatorações no código fonte. No entanto, aplicar refatorações pode não ser suficiente para reduzir a propensão a bugs dos elementos de código degradados. Um estudo recente sugere que refatorações induzem bugs frequentemente. No entanto, os autores não analisam se o código refatorado está, de fato, diretamente relacionado à introdução de bugs. Com isso, nesta dissertação, realizamos dois estudos longitudinais de múltiplos projetos para avaliar a propensão a bugs do código refatorado. Nossa metodologia teve como objetivo abordar várias limitações de estudos anteriores. Por exemplo, definimos duas propriedades complementares da propensão a bugs do código refatorado, sendo elas, frequência e distância. Enquanto a primeira propriedade quantifica a frequência com que um código refatorado está relacionado a bugs que emergiram no código fonte, a distância quantifica o quão próximo um bug surge depois que uma refatoração é aplicada. Nosso primeiro estudo tem como objetivo avaliar a propensão a bugs de refatorações isoladas. Primeiro, nossos resultados mostram que 80 porcento dos elementos degradados que se tornaram bugs não foram previamente refatorados. Este resultado implica que um código refatorado é menos propenso a bugs do que um código não refatorado. Em segundo lugar, em 75 porcento das vezes um bug surge depois de 7 mudanças feitas a partir da operação de refatoração, o que geralmente corresponde à 3 meses nos projetos analisados. Nosso segundo estudo tem como objetivo avaliar a propensão a bugs de refatorações em lote, ou seja, refatorações aplicadas em sequência. Nossos resultados mostram que, na maioria dos casos, o código refatorado em lotes é mais resiliente à introdução de bugs do que o código refatorado por meio de refatorações isoladas. / [en] Programs often change along the system evolution, which implies an eventual code structure degradation. Recurring symptoms of such degradation are code smells. Studies suggest that the more frequently code smells affect a system, the higher becomes the bug-proneness of the code elements. To tackle code structural quality degradation, developers often apply refactorings on smelly program elements. However, applying refactorings might not suffice to reduce the bug-proneness of such degraded program elements. Previous empirical studies do not systematically analyze the bug-proneness of refactored code. Even though a recent study suggests that refactoring induces bugs frequently, the authors do not analyze to what extent refactored code is indeed closely related to the bug occurrence. Thus, in this dissertation, we conducted two longitudinal multi-project studies to assess the bugproneness of refactored code. Our methodology aimed to address various limitations of previous studies. For instance, we have defined two complementary properties of the bug-proneness of refactored code, i.e., frequency and distance. While the former quantifies how often a refactored code is related to emerging bugs, the latter quantifies how close a bug emerges after a refactoring has been applied. The quantitative analysis of such properties was complemented by a manual analysis of refactorings closely related to the bug occurrence. Our first study aims at assessing the bug-proneness of code refactored through isolated refactorings, i.e., a single refactoring operation not performed in conjunction with other refactoring operations. This study reveals that 80 per cent of the smelly elements that became buggy were not previously refactored. This result suggests the refactored code is much less bug-prone than non-refactored code. Moreover, in 75 per cent of the times, a bug emerges in 7 changes far from the refactoring operation; this amount of changes usually corresponds to 3 months in the analyzed projects. Our second study aims at assessing the bug-proneness of code elements refactored through batch refactorings, i.e., a sequence of inter-related refactoring operations. Our results show that code refactored through batches is often more resilient to the introduction of bugs as compared to code refactored through isolated refactorings.

[pt] A refatoração de código é uma transformação de código que visa aprimorar a estrutura interna do código. Uma refatoração isolada raramente é suficiente para remover completamente uma estrutura de código ruim, como uma anomalia de código. Os desenvolvedores então aplicam refatorações compostas para remover totalmente uma anomalia de código. Uma refatoração composta consiste em duas ou mais refatorações inter-relacionadas. Um refatoração composta é considerada completa quando elimina totalmente a anomalia de código alvo. Estudos relatam que os desenvolvedores geralmente falham em remover completamente as anomalias de código alvo por meio de refatorações compostas. Refatorações compostas concluídas podem não ser totalmente benéficas para a estrutura do código. Pois, estas podem induzir efeitos colaterais, como a introdução de anomalias de código ou a propagação de anomalias existentes. Há uma compreensão limitada sobre a completude das refatorações compostas e seus possíveis efeitos colaterais. Esta tese investiga como as refatorações compostas removem totalmente as anomalias de código sem induzir efeitos colaterais. Descobrimos que 64 por cento das refatorações compostas completas são formadas por tipos de refatoração não recomendados anteriormente. Dessa forma, derivamos um catálogo de recomendações para apoiar os desenvolvedores na aplicação de refatorações compostas. Na avaliação do catálogo, 85 por cento de 21 desenvolvedores relataram que usariam as recomendações do catálogo e que suas próprias soluções de refatoração teriam induzido efeitos colaterais. Também avaliamos qualitativamente três abordagens existentes para recomendar automaticamente refatorações compostas. Nesse estudo, a maioria (80 por cento) dos 10 desenvolvedores relatou que as abordagens existentes frequentemente induzem efeitos colaterais. No geral, as descobertas e o catálogo proposto podem ajudar os desenvolvedores a realizar refatorações compostas completas. / [en] Code refactoring is a code transformation that aims to enhance the internal code structure. A single refactoring is rarely sufficient to achieve the full removal of a poor code structure, such as a code smell. Developers then apply composite refactorings to fully remove a code smell. A composite refactoring (or, simply, composite) consists of two or more interrelated single refactorings. A composite is considered complete when it fully eliminates the target smell. However, studies report that developers often fail in completely removing target code smells through composites. Even when composite refactorings are complete they may still not be entirely beneficial to the code structure. They may induce side effects, such as the introduction of new smells or the propagation of existing ones. There is a limited understanding of the completeness of composite refactorings and their possible effects on structural quality. This thesis investigates whether and how composite refactorings fully remove smells without inducing side effects. We found that 64 per cent of complete composites in several software projects are formed of refactoring types not previously recommended in the literature. Based on this study, we derived a catalog of recommendations for supporting developers in applying composite refactorings. Out of twenty one developers evaluating our catalog, 85 per cent reported that they would use the catalog recommendations and that their own refactoring solutions would have induced side effects. We also qualitatively evaluated three existing approaches to automatically recommend composite refactorings. In our study with ten developers, most (80 per cent) developers reported that existing approaches frequently induce side effects. Overall, the findings and the proposed catalog can help developers to perform complete composite refactorings with better awareness of possible side effects.

[pt] Refatorar código-fonte consiste em aplicar transformações sobre a estrutura de código-fonte de projetos de software. Refatoração é bastante usada para remover estruturas pobres que dificultam a manutenção de sistemas de software. Poucas transformações isoladas são capazes de remover por completo estruturas pobres, mesmo as mais simples. Por exemplo, encurtar um método longo usualmente requer a extração de vários métodos. Até 60 por cento das transformações são inter-relacionadas e aplicadas em lotes, durante a dita refatoração em lote, ao invés de aplicadas isoladamente. Embora lotes serão frequentes na prática, o conhecimento sobre as características que constituem lotes está fragmentado na literatura. Qual o tamanho usual de lotes? As transformações internas a lotes costumam variar? Não há uma sumarização de conhecimento que responda tais questões. Ademais, são poucas as evidências sobre o efeito de lotes sobre a manutenção de sistemas. Lotes tendem a introduzir ou remover estruturas pobres, especialmente aquelas indicadas por anomalias de código-fonte? A resposta a perguntas como essa é insuficiente para apoiar a aplicação de lotes. Esta dissertação de mestrado apresenta dois estudos experimentais complementares visando resolver as limitações supracitadas. A dissertação começa com uma revisão da literatura sobre refatoração em lote baseada em 29 estudos. Nós identificamos sete características de lotes tais como o escopo de código-fonte afetado pela aplicação de um lote, mais sete tipos de efeito de lotes sobre a manutenção de sistemas, tais como a remoção de anomalias. As características e tipos de efeito identificadas foram sumarizadas por um mapa conceitual. A dissertação encerra-se com uma análise quantitativa de 57 projetos de sistemas abertos e fechados. Ao computar 4.607 lotes com uma heurística, nós descobrimos que a maioria dos lotes leva um único commit para ser aplicada (93 por cento) mas afeta mais do que um só método (90 por cento). Surpreendentemente, a maioria dos lotes introduz (51 por cento) ou não remove (38 por cento) anomalias. Revelamos também lotes até então desconhecidos mas capazes de remover por completo certas anomalias. Esta dissertação sugere trabalhos futuros com base em conflitos identificados na literatura quanto a características e tipos de efeito de lotes. / [en] Code refactoring means applying transformations on the code structure of a software project. Refactoring usually intends to remove poor code structures that harm the software maintenance. Each single transformation rarely suffices to fully remove poor code structures, even the simplest ones. For instance, shortening a long method often requires many method extractions. Up to 60 percent of the refactorings in software projects are constituted of a set of interrelated transformations, the so-called batches, rather than single transformations applied in isolation. Although batches are frequent in practice, the knowledge of batch characteristics is fragmented across studies. What is the usual size of batches? How do transformations vary within a batch? There is no summary that helps to address these questions. More critically, there is little empirical evidence of the batch effect on maintenance. Are batches more likely to introduce or remove poor code structures, especially those spotted by code smells? The current answer to questions like this is insufficient to support the batch application in practice. This Master s dissertation presents two complementary empirical studies that address both aforementioned literature gaps. The dissertation starts with a literature review of batch refactoring with 29 studies. We identified seven batch characteristics such as the scope in which batches are applied to code structures, plus seven types of batch effect on software maintenance, including code smell removal. All batch characteristics and types of effect were summarized in a conceptual map. The dissertation ends with the quantitative analysis of 57 open and closed software projects. From 4,607 heuristic-computed batches, we found that most batches occur entirely within one commit (93 percent) but affect more than just one method (90 percent). Surprisingly, batches mostly end up introducing (51 percent) or not removing (38 percent) code smells. Our results enabled us to reveal certain forms of batches, not documented by previous studies, that are useful to fully remove certain types of code smells.