This report evaluates the team-structure of three software maintenance teams in order to decide their level of featureness (a term that defines to what extent a team has the quality (the set of characteristics) of being a feature team). Simulations of changes that are expressed as beneficial in an agile environment and that could increase the teams‘ level of featureness within the team structure are performed. The results show that each team‘s level of featureness is affected differently by each change. Partly, this underlines the importance of understanding the current team-structure before implementing changes that aim to increase the level of featureness. And secondly, within the scope of the study, the change where a user expert is declared a team member is concluded as the change that increases the teams‘ level of featureness the most. Based on the results the report also concludes that it is essential to implement changes that affect different, which in combination can increase the level of featureness.

Masters of Science / Coders of databases repeatedly face the problem of checking their Structured Query Language (SQL) code. Instructors face the difficulty of checking student projects and lab assignments in database courses. We collect and categorize common MySQL programming errors into three groups: data definition errors, data manipulation errors, and transaction control errors. We build these into a comprehensive list of MySQL errors, which novices are inclined make during database programming. We collected our list of common MySQL errors both from the technical literature and directly by noting errors made in assignments handed in by students. In the results section of this research, we check and summarize occurrences of these errors based on three characteristics as semantics, syntax, and logic. These data form the basis of a future static MySQL checker that will eventually assist database coders to correct their code automatically. These errors also form a useful checklist to guide students away from the mistakes that they are prone to make.

Les systèmes logiciels sont devenus de plus en plus répondus et importants dans notre société. Ainsi, il y a un besoin constant de logiciels de haute qualité. Pour améliorer la qualité de logiciels, l’une des techniques les plus utilisées est le refactoring qui sert à améliorer la structure d'un programme tout en préservant son comportement externe. Le refactoring promet, s'il est appliqué convenablement, à améliorer la compréhensibilité, la maintenabilité et l'extensibilité du logiciel tout en améliorant la productivité des programmeurs. En général, le refactoring pourra s’appliquer au niveau de spécification, conception ou code. Cette thèse porte sur l'automatisation de processus de recommandation de refactoring, au niveau code, s’appliquant en deux étapes principales: 1) la détection des fragments de code qui devraient être améliorés (e.g., les défauts de conception), et 2) l'identification des solutions de refactoring à appliquer. Pour la première étape, nous traduisons des régularités qui peuvent être trouvés dans des exemples de défauts de conception. Nous utilisons un algorithme génétique pour générer automatiquement des règles de détection à partir des exemples de défauts. Pour la deuxième étape, nous introduisons une approche se basant sur une recherche heuristique. Le processus consiste à trouver la séquence optimale d'opérations de refactoring permettant d'améliorer la qualité du logiciel en minimisant le nombre de défauts tout en priorisant les instances les plus critiques. De plus, nous explorons d'autres objectifs à optimiser: le nombre de changements requis pour appliquer la solution de refactoring, la préservation de la sémantique, et la consistance avec l’historique de changements. Ainsi, réduire le nombre de changements permets de garder autant que possible avec la conception initiale. La préservation de la sémantique assure que le programme restructuré est sémantiquement cohérent. De plus, nous utilisons l'historique de changement pour suggérer de nouveaux refactorings dans des contextes similaires. En outre, nous introduisons une approche multi-objective pour améliorer les attributs de qualité du logiciel (la flexibilité, la maintenabilité, etc.), fixer les « mauvaises » pratiques de conception (défauts de conception), tout en introduisant les « bonnes » pratiques de conception (patrons de conception). / Software systems have become prevalent and important in our society. There is a constant need for high-quality software. Hence, to improve software quality, one of the most-used techniques is the refactoring which improves design structure while preserving the external behavior. Refactoring has promised, if applied well, to improve software readability, maintainability and extendibility while increasing the speed at which programmers can write and maintain their code. In general, refactoring can be performed in various levels such as the requirement, design, or code level. In this thesis, we mainly focus on the source code level where automated refactoring recommendation can be performed through two main steps: 1) detection of code fragments that need to be improved/fixed (e.g., code-smells), and 2) identification of refactoring solutions to achieve this goal. For the code-smells identification step, we translate regularities that can be found in such code-smell examples into detection rules. To this end, we use genetic programming to automatically generate detection rules from examples of code-smells. For the refactoring identification step, a search-based approach is used. The process aims at finding the optimal sequence of refactoring operations that improve software quality by minimizing the number of detected code-smells while prioritizing the most critical ones. In addition, we explore other objectives to optimize using a multi-objective approach: the code changes needed to apply refactorings, semantics preservation, and the consistency with development change history. Hence, reducing code changes allows us to keep as much as possible the initial design. On the other hand, semantics preservation insures that the refactored program is semantically coherent, and that it models correctly the domain-semantics. Indeed, we use knowledge from historical code change to suggest new refactorings in similar contexts. Furthermore, we introduce a novel multi-objective approach to improve software quality attributes (i.e., flexibility, maintainability, etc.), fix “bad” design practices (i.e., code-smells) while promoting “good” design practices (i.e., design patterns).

Bons códigos importam, mas como saber quando a qualidade está baixa? Maus cheiros de código, ou anomalias, auxiliam desenvolvedores na identificação de trechos de código problemáticos, porém a maioria dos maus cheiros catalogados são voltados para práticas e tecnologias tradicionais, criadas entre as décadas de 70 a 90, como orientação a objetos e Java. Ainda há dúvidas sobre maus cheiros em tecnologias que surgiram na última década, como o Android, principal plataforma móvel em 2017 com mais de 86% de participação de mercado. Alguns pesquisadores derivaram maus cheiros Android relacionados à eficiência e à usabilidade. Outros notaram que maus cheiros específicos ao Android são muito mais frequentes nos aplicativos do que maus cheiros tradicionais. Diversas pesquisas concluíram que os componentes Android mais afetados por maus cheiros tradicionais são Activities e Adapters, que pertencem à camada de apresentação. Notou-se também que em alguns aplicativos, códigos da camada de apresentação representam a maior parte do código do projeto. Vale ressaltar que a camada de apresentação Android também é composta por arquivos XML, chamados de recursos, usados na construção da interface do usuário (User Interface - UI), porém nenhuma das pesquisas citadas os considerou em suas análises. Nesta dissertação, investigamos a existência de maus cheiros relacionados à camada de apresentação Android considerando inclusive os recursos. Fizemos isso através de dois questionários e um experimento de código online, totalizando a participação de 316 desenvolvedores. Nossos resultados mostram a existência de uma percepção comum entre desenvolvedores sobre más práticas no desenvolvimento da camada de apresentação Android. Nossas principais contribuições são um catálogo com 20 maus cheiros da camada de apresentação Android e uma análise estatística da percepção de desenvolvedores sobre os 7 principais maus cheiros catalogados. Nossas contribuições servirão a pesquisadores como ponto de partida para a definição de heurísticas e implementação de ferramentas automatizadas e a desenvolvedores como auxílio na identificação de códigos problemáticos, ainda que de forma manual. / We are aware that good code matters, but how to know when quality is low? Code smells, or anomalies, help us identify problematic code snippets, but most of the code smells cataloged are based on traditional practices and technologies, created from the 70s through the 90s, such as object oriented programming and Java. There are still doubts about code smells in technologies that have emerged in the last decade, such as Android, the main mobile platform in 2017 with more than 86% market share. Some researchers have defined code smells related to Android efficiency and usability. Other research concludes that the components most affected by traditional code smells are related to the front-end components, such as Activities and Adapters. Also noticed in some applications, front-end code represent the larger part of the projects code. It is worth mentioning that the Android presentation layer is also composed of XML files, called resources, used to build the user interface (UI), but none of the cited research considered them in their analyzes. In this dissertation, we investigate the existence of code smells related to the Android front-end, including application resources. We performed two online surveys and one online code experiment, summing 316 developers. Our results show that there is a common perception among Android developers about bad practices on Android front-end. Our main contributions are a catalog of 20 code smells related to the Android front-end and a statistical analysis of the perceptions of developers about the 7 main code smells cataloged. Our contributions will provide to researchers a starting point for the definition of heuristics and implementation of automated tools and to developers as an aid in identifying problematic codes.

Bons códigos importam, mas como saber quando a qualidade está baixa? Maus cheiros de código, ou anomalias, auxiliam desenvolvedores na identificação de trechos de código problemáticos, porém a maioria dos maus cheiros catalogados são voltados para práticas e tecnologias tradicionais, criadas entre as décadas de 70 a 90, como orientação a objetos e Java. Ainda há dúvidas sobre maus cheiros em tecnologias que surgiram na última década, como o Android, principal plataforma móvel em 2017 com mais de 86% de participação de mercado. Alguns pesquisadores derivaram maus cheiros Android relacionados à eficiência e à usabilidade. Outros notaram que maus cheiros específicos ao Android são muito mais frequentes nos aplicativos do que maus cheiros tradicionais. Diversas pesquisas concluíram que os componentes Android mais afetados por maus cheiros tradicionais são Activities e Adapters, que pertencem à camada de apresentação. Notou-se também que em alguns aplicativos, códigos da camada de apresentação representam a maior parte do código do projeto. Vale ressaltar que a camada de apresentação Android também é composta por arquivos XML, chamados de recursos, usados na construção da interface do usuário (User Interface - UI), porém nenhuma das pesquisas citadas os considerou em suas análises. Nesta dissertação, investigamos a existência de maus cheiros relacionados à camada de apresentação Android considerando inclusive os recursos. Fizemos isso através de dois questionários e um experimento de código online, totalizando a participação de 316 desenvolvedores. Nossos resultados mostram a existência de uma percepção comum entre desenvolvedores sobre más práticas no desenvolvimento da camada de apresentação Android. Nossas principais contribuições são um catálogo com 20 maus cheiros da camada de apresentação Android e uma análise estatística da percepção de desenvolvedores sobre os 7 principais maus cheiros catalogados. Nossas contribuições servirão a pesquisadores como ponto de partida para a definição de heurísticas e implementação de ferramentas automatizadas e a desenvolvedores como auxílio na identificação de códigos problemáticos, ainda que de forma manual. / We are aware that good code matters, but how to know when quality is low? Code smells, or anomalies, help us identify problematic code snippets, but most of the code smells cataloged are based on traditional practices and technologies, created from the 70s through the 90s, such as object oriented programming and Java. There are still doubts about code smells in technologies that have emerged in the last decade, such as Android, the main mobile platform in 2017 with more than 86% market share. Some researchers have defined code smells related to Android efficiency and usability. Other research concludes that the components most affected by traditional code smells are related to the front-end components, such as Activities and Adapters. Also noticed in some applications, front-end code represent the larger part of the projects code. It is worth mentioning that the Android presentation layer is also composed of XML files, called resources, used to build the user interface (UI), but none of the cited research considered them in their analyzes. In this dissertation, we investigate the existence of code smells related to the Android front-end, including application resources. We performed two online surveys and one online code experiment, summing 316 developers. Our results show that there is a common perception among Android developers about bad practices on Android front-end. Our main contributions are a catalog of 20 code smells related to the Android front-end and a statistical analysis of the perceptions of developers about the 7 main code smells cataloged. Our contributions will provide to researchers a starting point for the definition of heuristics and implementation of automated tools and to developers as an aid in identifying problematic codes.

Les logiciels dépendent de bibliothèques tierces pour réduire les coûts liés à leur développement et à leur maintenance. Elles proposent un ensemble de fonctionnalités robustes dont les développeurs peuvent tirer parti depuis une interface de programmation. Cependant, cette forte dépendance entre un logiciel et ses bibliothèques oblige les développeurs à reconsidérer leur rôle lorsque le logiciel évolue. Dans cette thèse, nous identifions plusieurs problématiques impliquant les bibliothèques tierces dans un contexte de maintenance logicielle. Plus particulièrement, une bibliothèque peut ne plus répondre aux besoins d’un logiciel et doit être remplacée par une nouvelle.Nous nommons cette opération une migration de bibliothèque.Nous soulevons dans ce contexte trois points qui caractérisent les difficultés rencontrées par les développeurs. Vers quelle bibliothèque migrer ? Comment appliquer la migration ? Avec l’aide de quels développeurs ? Cette thèse discute de solutions et apporte des contributions autour de ces problèmes. Nous présentons plusieurs approches et les évaluons lors de différents cas d’étude. L’analyse de l’évolution logicielle sera notre support de travail, dont la méthodologie est basée sur l’observation des changements de logiciels. Nous décrivons les limites actuelles de nos contribu-tions et ouvrons des perspectives futures pour enrichir l’état de l’art dans ce domaine / Software depend on third-party libraries to reduce development and maintenance costs. Developers have access to robust functionalities through an application programming interface designed by these libraries. However, due to the strong relationship with these libraries, developers have to reconsider their position when the software evolves. In this thesis, we identify several re-search problems involving these third-party libraries in a context of software maintenance. More specifically, a library may not satisfy the software new requirements and has to be replaced by anew one. We call this operation a library migration.We leverage three points that characterize the impediments met by developers in this situation.To which library should they migrate ? How to migrate their software ? Who can help them in this case ? This thesis suggests answers and exposes several contributions to these problems. We define three approaches that are evaluated through several case studies. To achieve this work, weuse a methodology based on software evolution analysis to observe and understand how software change. We describe numerous perspectives to overcome the current limitations of our solutions.

The problems of software debugging and system reliability/availability are among the most challenging problems the computing industry is facing today, with direct impact on the development and operating costs of computing systems. A promising debugging technique that assists programmers identify and fix the causes of software bugs a lot more efficiently is bidirectional debugging, which enables the user to execute the program in "reverse", and a typical method used to recover a system after a fault is backwards error recovery, which restores the system to the last error-free state. Both reverse execution and backwards error recovery are enabled by creating memory checkpoints, which are used to restore the program/system to a prior point in time and re-execute until the point of interest. The checkpointing frequency is the primary factor that affects both the latency of reverse execution and the recovery time of the system; more frequent checkpoints reduce the necessary re-execution time. Frequent creation of checkpoints poses performance challenges, because of the increased number of memory reads and writes necessary for copying the modified system/program memory, and also because of software interventions, additional synchronization and I/O, etc., needed for creating a checkpoint. In this thesis I examine a number of different hardware accelerators, whose role is to create frequent memory checkpoints in the background, at minimal performance overheads. For the purpose of reverse execution, I propose the HARE and Euripus hardware checkpoint accelerators. HARE and Euripus create different types of checkpoints, and employ different methods for keeping track of the modified memory. As a result, HARE and Euripus have different hardware costs and provide different functionality which directly affects the latency of reverse execution. For improving the availability of the system, I propose the Kyma hardware accelerator. Kyma enables simultaneous creation of checkpoints at different frequencies, which allows the system to recover from multiple types of errors and tolerate variable error-detection latencies. The Kyma and Euripus hardware engines have similar architectures, but the functionality of the Kyma engine is optimized for further reducing the performance overheads and improving the reliability of the system. The functionality of the Kyma and Euripus engines can be combined into a unified accelerator that can serve the needs of both bidirectional debugging and system recovery.

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

Made available in DSpace on 2016-06-02T19:05:51Z (GMT). No. of bitstreams: 1 3771.pdf: 2012363 bytes, checksum: beac2e75d3e67d4b8d96a9b1c3ce98ef (MD5) Previous issue date: 2011-05-27 / Universidade Federal de Sao Carlos / Aspect-Oriented Programming allows encapsulating the so-called "Crosscutting Concerns (CCC) - software requirements whose implementation is tangled and scattered throughout the functional modules - into new abstractions, such as Aspects, Pointcuts, Advices and Inter-type Declarations. The reengineering of an OO software to an AO is not an easy task due to the existence of different abstractions in these technologies. We develop a set of nine refactorings of annotated OO class models to AO class models. In the context of this work, "annotated class models" are UML class diagrams whose elements (classes, interfaces, attributes and methods) are annotated with stereotypes representing the existing CCC in the application source code. The set of refactorings developed is divided into: i) generic refactorings; and ii) specific refactorings. Three generic refactorings and six specific refactorings to the persistence (which is divided into management and connections, transaction and synchronization) and logging concerns and to the Singleton and Observer design patterns were created. The generic refactorings are responsible for transforming an annotated OO model with indications of CCC into a partial AO model. This model is called partial because it is usually not fully modularized, i.e., there are remaining software elements stereotyped with indications of particular concerns. These refactorings are applicable to any kind of CCC; this is possible, because what is taken into consideration is the scenario in which these concerns appear in the class model. The specific refactorings are responsible for transforming partial AO models into final ones, whose CCC have been fully modularized in aspects. For that, each refactoring has a set of specific steps for modularization of a particular kind of concern. An Eclipse plug-in, called MoBRe was developed to assist the software engineer in the tasks of refactoring application. As a major contribution, the refactorings proposed in this paper allow obtaining well designed AO models. This is so because: i) they provide a step-by-step guide to the modularization of certain CCC and can avoid that software engineers choose inappropriate strategies for modularization of these CCC; and ii) they were prepared based on good design practices recommended by the scientific community. Thus, besides, the models the use of refactorings can lead to generation of better-quality code, for example, free of bad smells. A case study was conducted to assess the applicability of the proposed refactorings in order to compare an AO model generated by them with an AO model obtained from the literature. / Orientação a Aspectos (OA) permite encapsular Interesses Transversais (ITs) - requisitos de software cuja implementação encontra-se entrelaçada e espalhada pelos módulos funcionais - em novas abstrações, tais como, Aspectos, Conjuntos de Junção, Adendos e Declarações Inter-tipo. A reengenharia de um software OO para um OA não é uma atividade trivial em consequência da existência de abstrações diferentes entre as tecnologias envolvidas. Neste trabalho é proposto um conjunto de refatorações que pode ser aplicado sobre modelos de classes OO anotados com indícios de ITs para obtenção de modelos de classes OA. Modelos de classes anotados são diagramas de classes da UML cujos elementos (classes, interfaces, atributos e métodos) são anotados com estereótipos referentes aos ITs existentes no software. O conjunto de refatorações desenvolvido é subdivido em: i) refatorações genéricas; e ii) refatorações específicas. As refatorações genéricas são responsáveis por transformar um modelo OO anotado com indícios de ITs em um modelo OA parcial - modelo cujos ITs existentes não são completamente modularizados. Essas refatorações são aplicáveis a qualquer tipo de IT existente no software, considerando o cenário que esses interesses apresentam no modelo de classes. As refatorações específicas são responsáveis por transformar modelos de classes OA parciais em modelos de classes OA finais - modelos nos quais os ITs foram completamente modularizados em aspectos. Para que isso aconteça, cada refatoração possui um conjunto de passos específicos para modularização de um determinado tipo de interesse. Três refatorações genéricas e seis refatorações específicas foram elaboradas para os interesses de persistência (subdividido em: gerenciamento de conexões, de transações e sincronização), de logging e para os padrões de projeto Singleton e Observer. Um plug-in Eclipse, denominado MoBRe, foi desenvolvido para auxiliar o Engenheiro de Software na tarefa de aplicação das refatorações. Como principal contribuição, a utilização das refatorações propostas neste trabalho pode permitir a obtenção de modelos OA que representam bons projetos arquiteturais, pois: i) fornecem um guia para modularização de determinados ITs, podendo evitar que Engenheiros de Software escolham estratégias inadequadas para modularização; e ii) foram elaboradas com base em boas práticas de projeto OA preconizadas pela comunidade científica. Assim, além dos modelos a utilização das refatorações pode levar à geração de códigos de melhor qualidade, por exemplo, livre da presença de bad smells. Um estudo de caso foi conduzido para verificar a aplicabilidade das refatorações propostas e os modelos OA resultantes foram equivalentes aos modelos obtidos na literatura.