[pt] Anomalias de código podem sinalizar a degradação da arquitetura de software. No entanto, a identificação de anomalias de código arquiteturalmente relevantes (ou seja, aquelas que implicam em deficiências arquiteturais) é particularmente difícil devido: (i) a falta de compreensão sobre a relação existente entre anomalias de código e degradação arquitetural, (ii) ao fato do processo de detecção de anomalias ter como foco somente o código fonte, sem considerar como ele se relaciona com sua arquitetura, e (iii) a falta de conhecimento sobre a confiabilidade das técnicas de detecção em revelar anomalias de código que são arquiteturalmente relevantes. Esta tese apresenta técnicas para identificar anomalias de código que são arquiteturalmente relevantes. Métricas sensíveis à arquitetura e estratégias de detecção foram definidas para superar as limitações das técnicas de detecção convencionais. Estas métricas e estratégias aproveitam rastros que podem ser estabelecidos entre as visões arquiteturais e a implementação dos sistemas. A tese também documenta padrões de anomalias de código (ou seja, relações recorrentes de anomalias) que estão relacionados com problemas arquiteturais. Uma ferramenta, chamada de SCOOP, foi desenvolvida para coletar as métricas sensíveis à arquitetura, aplicar as novas estratégias de detecção, e identificar os padrões de anomalias de código. Usando esta ferramenta, a técnica proposta foi avaliada em uma série de estudos empíricos, comparando sua acurácia com técnicas convencionais de detecção durante o processo de identificação de anomalias de código que são arquiteturalmente relevantes. / [en] Code anomalies can signal software architecture degradation. However, the identification of architecturally-relevant code anomalies (i.e. code anomalies that strongly imply architectural deficiencies) is particularly challenging due to: (i) lack of understanding about the relationship between code anomalies and architectural degradation, (ii) the focus on source code anomaly detection without considering how it relates to the software architecture, and (iii) lack of knowledge about how reliable these detection techniques are when revealing architecturally-relevant code anomalies. This thesis presents techniques for identifying architecturally-relevant code anomalies. Architecture-sensitive metrics and detection strategies were defined to overcome the limitations of conventional detection strategies. These metrics and strategies leverage traces that can be established between architectural views and system implementation. The thesis also documents code anomaly patterns (i.e. recurring anomaly relationships) that are strongly related to architectural problems. A tool, called SCOOP, was developed to collect the architecture-sensitive metrics, apply the new detection strategies, and identify the documented code anomaly patterns. Using this tool, we evaluated our technique in a series of empirical studies, comparing its accuracy with that of conventional detection techniques when identifying architecturally-relevant code anomalies.

[pt] Um dos principais sintomas de declínio da qualidade arquitetural em projetos de software é a manifestação contínua de anomalias de código. Quando estas anomalias não são detectadas e removidas com antecedência, a capacidade de evoluir e manter estes sistemas pode ser comprometida, e, eventualmente, uma reestruturação completa de suas arquiteturas é inevitável. Apesar da existência de diversas técnicas e ferramentas para detecção automática de anomalias de código, a identificação de anomalias que efetivamente causam problemas arquiteturais é ainda uma tarefa desafiadora e não trivial. Ademais, estudos realizados no contexto desta dissertação ostraram que desenvolvedores tendem a refatorar mais frequentemente anomalias que não causam problemas arquiteturais. Em especial, percebeu-se que desenvolvedores priorizam a refatoração de elementos de código que não afetam a arquitetura dos sistemas, como métodos privados ou módulos internos de um componente arquitetural. Neste contexto, o presente trabalho propõe uma abordagem para priorização de anomalias de código. Esta abordagem é composta por heurísticas que exploram diferentes fatores para identificar e ordenar as anomalias detectadas de acordo com suas relevâncias arquiteturais. Tais fatores compreendem desde a quantidade de mudanças realizadas no código ao longo da evolução dos sistemas, até os papéis arquiteturais por ele desempenhados. Foi ainda implementada uma ferramenta para aplicar tais heurísticas de priorização automaticamente em projetos Java. A abordagem proposta foi avaliada em 4 projetos de software de diferentes domínios. Tal avaliação revelou que mantenedores de software poderiam ser beneficiados pelas recomendações de priorização produzidas pela ferramenta, de modo a investir seus esforços de refatoração na solução de problemas arquiteturalmente relevantes. / [en] The progressive manifestation of code anomalies in a software system is a key symptom of its architecture quality decline. When those anomalies are not detected and removed early, the maintainability of software projects can be compromised irreversibly, and, eventually, a complete redesign is inevitable. Despite the existence of many techniques and tools for code anomaly detection, identifying anomalies that are more likely to cause architecture problems remains a challenging task. In fact, studies performed in the context of this dissertation show that even when there is tool upport for detecting code anomalies, developers seem to invest more time refactoring those that are not related to architectural problems. Moreover, we also found that developers frequently prioritize refactoring of code elements that do not contribute to a better adherence to the intended software architecture. In this context, this dissertation proposes a prioritization approach for identifying which anomalies in a system implementation are more harmful to the architecture. The proposed approach is composed of heuristic strategies that exploit several software project factors to identify and rank code anomalies by their architecture relevance. These factors range from the change characteristics to the potential architecture roles of software modules. Furthermore, we implemented tool support for applying our prioritization approach in Java projects. We also evaluated the prioritization approach on 4 software projects from different application domains. Our evaluation revealed that software maintainers could benefit from the recommended rankings for identifying which code anomalies are harming architecture the most, helping them investing their refactoring efforts into solving the architecturally relevant problems.

[pt] Problemas de design decorrem de violações de princípios de design em um sistema de software. Tais problemas podem prejudicar a manutenção de sistemas e, logo, devem ser identificados e eliminados sempre que possível. Porém, identificar problemas de design não é trivial. Isso pois a documentação de design desses sistemas é em geral obsoleta ou inexistente. Assim, o desenvolvedor de um sistema tende a analisar o código-fonte em busca de problemas de design. Estudos sugerem anomalias de código-fonte como indicadores úteis desses problemas. Porém, outros estudos recentes mostram que uma única anomalia não é indicador suficiente. De fato, em torno de 80 por cento dos problemas de design estão associadas com múltiplas anomalias. Estas inter-relacionam-se na forma de aglomerações de anomalias. Embora as aglomerações de anomalias possam ajudar o desenvolvedor a identificar problemas de design, certas aglomerações contêm muitas anomalias. Isso então dificulta o raciocínio sobre a existência de um problema de design. Além disso, mesmo as propostas mais recentes de abordagens para a visualização de aglomerações de anomalias provêm suporte bastante limitado à identificação de problemas de design. Essa limitação é evidente quando um problema de design afeta múltiplos elementos na implementação de um sistema. Esta dissertação objetiva tratar essa limitação ao propor uma abordagem inovadora para a visualização de aglomerações de anomalias. Tal abordagem baseia-se em evidências coletadas a partir de vários experimentos propostos e conduzidos por nós. Contamos com a participação de desenvolvedores da academia e da indústria em cada experimento. Nossos resultados de estudo sugerem que vários desenvolvedores podem utilizar nossa abordagem de visualização para identificar de forma precisa problemas de design, especialmente aqueles que afetam múltiplos elementos de programa. Nossos resultados também apontam melhorias necessárias à abordagem com base na percepção dos desenvolvedores. / [en] Design problems are characterized by violations of design principles affecting a software system. Because they often hinder the software maintenance, developers should identify and eliminate design problems whenever possible. Nevertheless, identifying design problems is far from trivial. Due to outdated and scarce design documentation, developers not rarely have to analyze the source code for identifying these problems. Past studies suggest that code smells are useful hints of design problems. However, recent studies show that a single code smell might not suffice to reveal a design problem. That is, around 80 percent of design problems are realized by multiple code smells, which interrelate in the so-called smell agglomerations. Thus, developers can explore each smell agglomeration to identify a design problem in the source code. However, certain smell agglomerations are formed by several code smells, which makes it hard reasoning about the existence of a design problem. Visualization approaches have been proposed to represent smell agglomerations and guide developers in identifying design problems. However, those approaches provide a very limited support to the identification of specific design problems, especially the ones affecting multiple design elements. This dissertation aims to address this limitation by proposing a novel approach for the visualization of smell agglomerations. We rely on evidence collected from multiple empirical studies to design our approach. We evaluate our approach with developers from both academy and industry. Our results suggest that various developers could use our visualization approach to accurately identify design problems, in particular those affecting multiple program elements. Our results also point out to different ways for improving our visualization approach based on the developers perceptions.

[pt] Um problema de projeto é a manifestação de uma ou mais decisões de projeto inadequadas que afetam negativamente requisitos não funcionais. Por exemplo, Fat Interface, um problema que indica quando uma interface expõe serviços não coesos, no qual dificulta a extensibilidade e a manutenibilidade de um sistema de software. Apesar de problemas de projeto serem prejudiciais aos sistemas, identificá-los é uma tarefa difícil, especialmente quando o código-fonte é o único artefato disponível. Embora pesquisadores venham investigando técnicas para ajudar os desenvolvedores a identificar problemas de projeto, há pouco conhecimento sobre o processo de identificar problemas de projeto. Por exemplo, anomalias de códigos, um indicador de problemas de projeto, têm sido usadas para ajudar desenvolvedores a identificar problemas de projeto. No entanto, ainda não sabemos se elas são suficientes para ajudá-los ou não. Em particular, nenhum estudo tentou entender como os desenvolvedores identificam problemas de projeto. Nesse contexto, nós realizamos alguns estudos para entender a identificação de problemas de projeto. Em nossos dois primeiros estudos, nós investigamos o papel que as anomalias de código desempenham durante a identificação de problemas de design. Nossos resultados indicam que as anomalias de código são relevantes para os desenvolvedores na prática, por exemplo, eles são relevantes para indicar elementos a serem refatorados. Apesar da relevância, descobrimos que as anomalias de código não são suficientes para ajudar os desenvolvedores a identificar problemas de projeto. Nesse sentido, conduzimos outro estudo para investigar quais outros indicadores os desenvolvedores usam na prática e como eles são usados. Este estudo resultou em uma teoria sobre como os desenvolvedores identificam problemas de projeto na prática. A teoria revela quais são os indicadores que os desenvolvedores usam, como eles usam esses indicadores e as características de tais indicadores que os desenvolvedores consideram úteis. Os resultados encontrados nos forneceram uma melhor compreensão do processo de identificação de problemas de projeto, abrindo caminho para a elaboração de técnicas mais eficazes em ajudar os desenvolvedores a identificar problemas de projeto. / [en] A design problem is the manifestation of one or more inappropriate design decisions that negatively impact non-functional requirements. For example, the Fat Interface, a problem that indicates when an interface exposes non-cohesive services, hampers the extensibility and maintainability of a software system. Despite its harmfulness, identifying a design problem in a system is difficult, especially when the source code is the only available artifact. Although researchers have been investigating techniques to help developers in identifying design problems, there is little or no knowledge about the process of identifying design problems. For instance, code smells, microstructures that are a surface indication of design problems, have been used in several techniques to support developers during the design problem identification. However, there is no knowledge if code smells suffice to help developers to identify design problems. In particular, no study has tried to understand how developers identify design problems in practice. Thus, in this thesis, we have conducted a series of studies to understand design problem identification. In our two first studies, we investigated the role that code smells play in supporting developers during the design problem identification. Our results indicate that code smells are relevant for developers in practice; for instance, they are relevant to indicate elements that need to be refactored. However, we found that code smells, despite their relevance, do not suffice in helping developers to identify design problems. In this vein, we conducted another study to investigate what indicators developers use in practice, and how they use them. This study resulted in a theory about how developers identify design problems in practice. For instance, the theory reveals the indicators that developers use, how they use these indicators, and the characteristics of such indicators that are perceived as helpful by developers. The results found by our studies provided us with a better understanding of the process of identifying design problems thitherto nonexistent. Moreover, our findings pave the way for the elaboration of more effective techniques to identify design problems in the source code.

[pt] Sistemas de software estão evoluindo frequentemente devido a diversas requisições de mudanças. A medida que o software evolui, seu tamanho e complexidade aumentam, e consequentemente, sua arquitetura tende a se degradar. Sintomas de degradação arquitetural são por muitas vezes uma consequência direta da inserção progressiva de anomalias de código. Uma anomalia de código é uma estrutura da implementação recorrente que possivelmente indica problemas mais severos no projeto arquitetural. Anomalia de código é considerada crítica quando ela está relacionada problemas estruturais na arquitetura do software. Sua criticidade origina-se da sua influência negativa em uma ampla gama de requisitos não-funcionais. Por exemplo, a presença e anomalias e código críticas dificulta a manutenibilidade e software., ex. uma grande refatoração pode ser necessária para remover um problema arquitetural. Diversas abordagens tem sido propostas para a detecção de anomalias em sistemas de software, mas nenhuma delas suporta eficientemente a priorização e classificação de anomalias de código críticas de acordo com seu impacto na arquitetura. O presente trabalho investiga como a priorização e classificação dessas anomalias críticas de código pode se melhorado com o uso de blueprints arquiteturais. Blueprints arquiteturais são providos pelo arquiteto de software desde estágios iniciais de desenvolvimento do sistema. Blueprints são modelos de projeto informais normalmente definidos para capturar e comunicar as principais decisões de projeto arquitetural. Embora blueprints normalmente sejam incompletos e inconsistentes com respeito a implementação do sistema, eles podem contribuir para o processo de priorização e classificação de anomalias de código críticas. Com o intuito de alcançar nossos objetivos de pesquisa, um conjunto de estudos empíricos foram realizados. O trabalho também propõe e avalia um conjunto de heurísticas para auxiliar desenvolvedores na priorização e classificação de anomalias de código em 3 sistemas de software. Os resultados mostraram uma acurácia média de mais de 60 porcento na priorização e classificação de anomalias de código associadas com problemas arquiteturais nesses sistemas. / [en] Software systems are often evolving due to many changing requirements. As the software evolves, it grows in size and complexity, and consequently, its architecture design tends to degrade. Architecture degradation symptoms are often a direct consequence of the progressive insertion of code anomalies in the software implementation. A code anomaly is a recurring implementation structure that possibly indicates deeper architectural design problems. Code anomaly is considered critical when it is related with a structural problem in the software architecture. Its criticality stems from its negative influence on a wide range of non-functional requirements. For instance, the presence of critical code anomalies hinders software aintainability, i.e. these critical anomalies require wide refactoring in order to remove an architectural problem. Symptoms of architecture degradation have often to be observed in the source code due to the lack of an explicit, formal representation of the software architecture in a project. Many approaches are proposed for detecting code anomalies in software systems, but none of them efficiently support the prioritization and ranking of critical code anomalies according to their architecture impact. Our work investigates how the prioritization and ranking of such critical code anomalies could be improved by using blueprints. Architecture blueprints are usually provided by software architects since the early stages of the system development. Blueprints are informal design models usually defined to capture and communicate key architectural design decisions. Even though blueprints are often incomplete and inconsistent with respect to the underlying implementation, we aim to study if their use can contribute to improve the processes of prioritizing and ranking critical code anomalies. Aiming to address these research goals, a set of empirical studies has been performed. We also proposed and evaluated a set ofheuristics to support developers when prioritizing and ranking code anomalies in 3 software systems. The results showed an average accuracy higher than 60 percent when prioritizing and ranking code anomalies associated with architectural problems in these systems.

[pt] Problemas de projeto afetam quase todo sistema de software, fazendo com que a sua manutenção seja cara e impeditiva. Como documentos de projeto raramente estão disponíveis, desenvolvedores frequentemente precisam identificar problemas de projeto a partir do código fonte. Entretanto, a identificação de problemas de projeto não é uma tarefa trivial por diversas razões. Por exemplo, a materialização de problemas de projeto tende a ser espalhada por diversos elementos de código anômalos na implementação. Infelizmente, trabalhos prévios assumiram erroneamente que cada anomalia de código individual – popularmente conhecida como code smell – pode ser usada como um indicador preciso de problema de projeto. Porém, evidências empíricas recentes mostram que diversos tipos de problemas de projeto são frequentemente relacionados a um conjunto de anomalias de código inter-relacionadas, conhecidas como aglomerações de anomalias de código. Neste contexto, esta dissertação propõe uma nova técnica para a síntese de aglomerações de anomalias de código. A técnica tem como objetivo: (i) buscar formas variadas de aglomeração em um programa, e (ii) sumarizar diferentes tipos de informação sobre cada aglomeração. A avaliação da técnica de síntese baseou-se na análise de diversos projetos de software da indústria e em um experimento controlado com desenvolvedores profissionais. Ambos estudos sugerem que o uso da técnica de síntese ajudou desenvolvedores a identificar problemas de projeto mais relevantes do que o uso de técnicas convencionais. / [en] Design problems affect almost all software projects and make their maintenance expensive and impeditive. As design documents are rarely available, programmers often need to identify design problems from the source code. However, the identification of design problems is not a trivial task for several reasons. For instance, the reification of a design problem tends to be scattered through several anomalous code elements in the implementation. Unfortunately, previous work has wrongly assumed that each single code anomaly - popularly known as code smell - can be used as an accurate indicator of a design problem. There is growing empirical evidence showing that several types of design problems are often related to a set of inter-related code anomalies, the so-called code-anomaly agglomerations, rather than individual anomalies only. In this context, this dissertation proposes a new technique for the synthesis of code-anomaly agglomerations. The technique is intended to: (i) search for varied forms of agglomeration in a program, and (ii) summarize different types of information about each agglomeration. The evaluation of the synthesis technique was based on the analysis of several industry-strength software projects and a controlled experiment with professional programmers. Both studies suggest the use of the synthesis technique helped programmers to identify more relevant design problems than the use of conventional techniques.

[pt] Estudos recentes mostram que os sistemas são desenvolvidos por pelo menos quatro linguagens. Ao utilizar estas linguagens, boas práticas de desenvolvimento também são diferentes. Estes aspectos de heterogeneidade dificultam a concepção de soluções que apoiem desenvolvedores na construção de sistema multilinguagem com qualidade. Em particular, diversas abordagens têm surgido nos últimos anos com o objetivo de auxiliar os analistas nas tarefas de compreensão e manutenção desses sistemas. Porém, ainda existe uma carência de abordagens com foco na detecção de anomalias de código em sistemas multilinguagem. Dessa forma, o objetivo desse trabalho é oferecer suporte a identificação de sintomas de degradação arquitetural através do uso de estratégias baseadas em métricas em sistemas multilinguagem. / [en] Recent studies show that the systems are designed with at least four languages. Using these languages, best practices to development are also different. These aspects of heterogeneity make it difficult to design solutions that support developers activities on developing of multi-language system with quality. In particular, several approaches have emerged with the aim to assist analysts in comprehension and maintaining systems. However, there is still a lack of approaches focused on detection of code anomaly on multi-language systems. Thus, the aim of this work is to support the identification of symptoms of architectural degradation through the use of metrics-based strategies on multi-language systems.

[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] 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.