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

A crescente demanda por novas aplicações informatizadas, e a evolução da sua complexidade, faz com que seja cada vez mais importante a correta aplicação de esforços no processo de desenvolvimento de software. Apesar da dificuldade em se obter dados, estudos empíricos sobre a evolução do software podem auxiliar na criação de modelos e teorias que aperfeiçoem os esforços de desenvolvimento. Tendo acesso a uma base de informações de mais de cinco anos de solicitações de mudanças (que incluem melhorias e correções) de uma mesma organização de desenvolvimento, o problema da pesquisa era obter indicadores dos projetos de desenvolvimento que estivessem relacionados aos maiores custos de mudanças. A partir dessa formulação, foi definido como objetivo efetuar a análise dos custos de mudanças e, para isso, os casos com os maiores tempos de desenvolvimento foram classificados (utilizando a classificação ODC – Orthogonal Defect Classification), analisados individualmente, comparados entre si e com outros estudos. Como resultado do trabalho de análise dos custos de mudanças de software, são apresentadas faixas de valores (no início de entrada em produção e ao final de vinte meses de utilização em produção) de métricas de software pela quais são efetuadas comparações e que, eventualmente, podem ser utilizadas como comparação para outros projetos da mesma ou de outras empresas. Foram identificadas características em um projeto em específico que propõe associar a métrica de entrelaçamento de pacotes, no momento de entrada em produção, com o principal impacto da dimensão ODC. Essa associação pode ser considerada como a principal indicação relacionada aos custos de manutenção do software e, por meio do estabelecimento dessa associação entre métricas observadas durante o processo de desenvolvimento de sistemas, pode-se diminuir custos futuros na etapa de manutenção de software. / The increasing demand for new computer applications and the evolution of its complexity makes increasingly important the correct application of effort in the process of software development. Despite the difficulty in obtaining data, empirical studies on the evolution of software can assist in the creation of models and theories that enhance development efforts. Having access to a database of information of more than five years of change requests (including improvements and fixes) of the same development organization, the research problem was to obtain indicators of development projects that were related to higher costs of change. From this formulation, was set to perform the objective analysis of the costs of change and, therefore, the cases with the greatest development times were classified (using the ODC - Orthogonal Defect Classification) analyzed individually, compared with each other and with other studies. Resulting of the work for examining costs of software changes, ranges of values are presented (early start of production and at the end of twenty months of production use) software metrics for which comparisons are made and eventually may be used as a comparison to other projects of the same or other companies. There were characteristics, in a specific project, that proposes to associate the Package tangle index at the time of entry into production, with the main impact of the size ODC. This association can be regarded as the main indication related to software maintenance costs, and by establishing an association between this metric observed during the development of systems, can reduce future costs in the software maintenance phase.

A classificação das issues ou questões nos repositórios de manutenção de software é realizada atualmente pelos desenvolvedores de software. Entretanto, essa classificação manual não é livre de erros, os quais geram problemas na distribuição das issues para as equipes de tratamento. Isso acontece porque os desenvolvedores, geralmente os propositores das issues, possuem o mal hábito de classificá-las como bugs. Essas classificações errôneas produzem a distribuição de issues para uma equipe de tratamento de outro tipo de issue, gerando retrabalho para as equipes entre outras desvantagens. Por isso, o principal objetivo almejado com o estudo é a melhoria dessa classificação, utilizando de uma abordagem de classificação das issues realizada de maneira automatizada. Essa abordagem foi implementada com técnicas de Aprendizado de Máquina. Estas técnicas mostram que as palavras-chave discriminantes dos tipos de issues podem ser utilizadas como atributos de classificadores automáticos para a predição dessas issues. A abordagem foi avaliada sobre 5 projetos open source extraídos de 2 issue trackers conhecidos, Jira e Bugzilla. Por se tratarem de issue trackers de longa data, os projetos escolhidos forneceram boa quantidade de issues para este estudo. Essas issues, cerca de 7000, foram classificadas por especialistas humanos no trabalho [Herzig, Just e Zeller 2013], produzindo um gabarito utilizado para a realização deste estudo. Este trabalho produziu um classificador automático de issues, com acurácia de 81%, capaz de discriminá-las nos tipos bug, request for enhancement e improvement. O bom resultado de acurácia sugere que o classificador concebido possa ser utilizado em sistemas de encaminhamento de issues para as equipes de tratamento, com a Ąnalidade de diminuir retrabalho dessas equipes que ocorre em virtude da má classificação. / The classification of issues in software maintenance repositories is currently done by software developers. However, this classification is conducted manually and is not free of errors, which cause problems in the distribution of issues to the maintenance teams. This happen because the developers, which usually are the proponents of the issues, have the bad habit of classifying them as bugs. This erroneous rating generates rework and other disadvantages to the teams. Therefore, the main objective of this study is to improve this classification, using an issue classification approach conducted in an automated manner. In turn, this approach was implemented based on machine learning tecniques. These tecniques show that keywords discriminant of issues types can be used as attributes of automatic classifiers for prediction of these issues. The approach was evaluated on five open source projects extracted from two widely used issue trackers, Jira and Bugzilla. Because they are old issue trackers, the chosen projects provided good number of issues for this study. These issues, about 7.000, were classified by human experts at work [Herzig, Just e Zeller 2013], producing a feedback which was used for this study. This present work produced an automatic issues classifier, with 81% of accuracy, able to predict them in types of bug, request for enhancement and improvement. The result of accuracy obtained by this classifier suggests that it can be used in delivery systems to treatment teams with the purpose of reducing rework that occurs in these teams because of the poor issues rating. / Dissertação (Mestrado)

Submitted by Nayara Passos (nayara.passos@ufpe.br) on 2015-03-13T13:04:40Z No. of bitstreams: 2 TESE Yaguaratã Cerqueira Cavalcanti.pdf: 2989671 bytes, checksum: cdde3d6cea6de1cabb90748865421b78 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-13T13:04:40Z (GMT). No. of bitstreams: 2 TESE Yaguaratã Cerqueira Cavalcanti.pdf: 2989671 bytes, checksum: cdde3d6cea6de1cabb90748865421b78 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2014 / The efficient management of Change Requests (CRs) is fundamental for successful software maintenance; however the assignment of CRs to developers is an expensive aspect in this regard, due to the time and expertise demanded. To overcome this, researchers have proposed automated approaches for CR assignment. Although these proposals present advances to this topic, they do not consider many factors inherent to the assignments, such as: developers’ workload, CRs severity, interpersonal relationships, and developers know-how. Actually, as we demonstrate in this work, CR assignment is a complex activity and automated approaches cannot rely on simplistic solutions. Ideally, it is necessary to consider and reason over contextual information in order to provide an effective automation. In this regarding, this work proposes, implements, and validates a context-aware architecture to automate CR assignment. The architecture emphasizes the need for considering the different information available at the organization to provide a more context-aware solution to automated CR assignment. The development of such architecture is supported by evidence synthesized from two empirical studies: a survey with practitioners and a systematic mapping study. The survey provided us with a set of requirements that automated approaches should satisfy. In the mapping study, in turn, we figured out how state-of-the-art approaches are implemented in regarding to these requirements, concluding that many of them are not satisfied. In addition, new requirements were identified in this mapping study. For the implementation of the proposed architecture, we developed a strategy to automate CR assignments which is based on two main components: a Rule-Based Expert System (RBES) and an Information Retrieval (IR) model. The strategy coordinately applies these two components in different steps to find the potential developer to a CR. The RBES takes care of the simple and complex rules necessary to consider contextual information in the assignments, e.g., to prevent assigning a CR to a busy or unavailable developer. Since these rules vary from one organization/project to another, the RBES facilitates their modification for different contexts. On the other hand, the IR model is useful to make use of the historical information of CR assignments to match CRs and developers. Results from the validation study showed that our solution is promising. It is, by comparing the solution with an approach that uses only a machine learning algorithm, such as the Support Vector Machine (SVM), we could improve the accuracy of assignments by almost 50%. The analysis of the solution’s payoff also pointed that such an accuracy is able to pay for the efforts necessary to deploy the solution.-------------------------------------O gerenciamento eficiente de solicitações de mudança (SM) é fundamental para o sucesso das atividades de manutenção e evolução de software. Entretanto, a atribuição de SMs a desenvolvedores é um aspecto custoso desse gerenciamento, pois demanda tempo e conhecimento apropriado do projeto de software. Várias pesquisas já propuseram métodos de atribuição automática de SMs. Embora representem avanços na área, existem fatores inerentes a atribuição de SMs que não são considerados nessas pesquisas e são essenciais para a automação. Como demonstrado nesse trabalho, a atribuição automática deve, por exemplo, considerar a carga de trabalho, a experiência e o conhecimento dos desenvolvedores, a prioridade e a severidade das SMs, a afinidade dos desenvolvedores com os problemas descritos nas SMs, e até mesmo os relacionamentos interpessoais. Para tornar esse cenário ainda mais complexo, esses fatos podem variar de acordo com o projeto de software que está sendo desenvolvido. Assim, uma solução para o problema de atribuição de SMs depende de informações contextuais. Assim, esse trabalho propõe, implementa e valida uma solução arquitetural sensível ao contexto para atribuição automática de SMs. Dado o aspecto contextual da solução, a arquitetura considera diversas fontes de informações presentes na organização, assim como a necessidade de se desenvolver algorítimos que implementem diferentes estratégias de atribuição. Nossa proposta de solução é embasada em resultados de duas pesquisas quantitativas: um estudo de mapeamento sistemático da literatura, e uma pesquisa de questionário com desenvolvedores de software. Esse último forneceu um conjunto de requisitos que a solução automatizada deve satisfazer para que as estratégias de atribuição sejam atendidas, enquanto o mapeamento da literatura identificou técnicas, algoritmos, e outros requisitos necessários a automação. A implementação da arquitetura segue uma estratégia de automação, definida nesse trabalho, que possui dois componentes principais: um sistema especialista baseado em regras (SEBR); e um modelo de recuperação de informação (MRI) com técnicas de aprendizagem. Em nossa estratégia, esses dois componentes são executados alternadamente em momentos diferentes a fim de atribuir uma SM automaticamente. O SEBR processa regras, considerando informações contextuais do projeto de software e da organização que o desenvolve. O MRI é utilizado para fazer o casamento entre SMs e desenvolvedores de acordo com o histórico de atribuições. Os resultados do estudo de validação apontaram que a solução é promissora. Isto é, ao compararmos nossa solução com uma abordagem que utiliza apenas um algoritmo de aprendizado de máquina, como o Support Vector Machine (SVM), pudemos melhorar em quase 50% a acurácia de atribuição. Já a análise de custo de implantação apontou que a acurácia atingida pela solução possui um bom custo benefício.

Submitted by Renata Lopes (renatasil82@gmail.com) on 2017-01-16T13:41:31Z No. of bitstreams: 1 marcosalexandremiguel.pdf: 10203756 bytes, checksum: 35844967ee919f58955320a1c591c5dc (MD5) / Approved for entry into archive by Diamantino Mayra (mayra.diamantino@ufjf.edu.br) on 2017-01-31T10:34:46Z (GMT) No. of bitstreams: 1 marcosalexandremiguel.pdf: 10203756 bytes, checksum: 35844967ee919f58955320a1c591c5dc (MD5) / Made available in DSpace on 2017-01-31T10:34:46Z (GMT). No. of bitstreams: 1 marcosalexandremiguel.pdf: 10203756 bytes, checksum: 35844967ee919f58955320a1c591c5dc (MD5) Previous issue date: 2016-09-01 / Muitas organizações encontram problemas na tentativa de estimar esforço em atividades de manutenção de software. Quando a estimativa de esforço não está bem definida ou é imprecisa, os resultados obtidos podem refletir diretamente na entrega do software, causando insatisfação do cliente ou diminuição da qualidade do produto. O sucesso ou fracasso de projetos depende da precisão do esforço e do cronograma das atividades envolvidas. O surgimento de métodos ágeis no campo de desenvolvimento de software tem apresentado muitas oportunidades e desafios para pesquisadores e profissionais da área. Um dos principais desafios é a estimativa de esforço para as atividades de manutenção no desenvolvimento ágil de software. Nesse contexto, este trabalho apresenta um framework, nomeado GiveMe Effort, o qual objetiva apoiar as atividades de estimativa de esforço na manutenção de software usando dados históricos e informações de compreensão de software. / Many organizations encounter problems when estimating effort for software maintenance activities. When estimating effort is not well defined or are inaccurate, the results may reflect directly into the software delivery, causing customer dissatisfaction or decreased product quality. The success or failure of projects depends on the accuracy of the effort and the schedule of involved activities. The rise of agile methods in software development has presented many opportunities and challenges for researchers and professionals. In this context, a key challenge is the effort estimate for maintenance activities in the agile software development context. This work presents a framework, called GiveMe Effort, to support the effort estimation activities in software maintenance. It is based on historical data and software comprehension information.

Submitted by Geandra Rodrigues (geandrar@gmail.com) on 2018-10-30T13:39:57Z No. of bitstreams: 1 helenodesouzacamposjunior.pdf: 1434985 bytes, checksum: 4307be9bfd2ca9825bcd2ce10bfc824e (MD5) / Approved for entry into archive by Adriana Oliveira (adriana.oliveira@ufjf.edu.br) on 2018-11-23T12:26:30Z (GMT) No. of bitstreams: 1 helenodesouzacamposjunior.pdf: 1434985 bytes, checksum: 4307be9bfd2ca9825bcd2ce10bfc824e (MD5) / Made available in DSpace on 2018-11-23T12:26:30Z (GMT). No. of bitstreams: 1 helenodesouzacamposjunior.pdf: 1434985 bytes, checksum: 4307be9bfd2ca9825bcd2ce10bfc824e (MD5) Previous issue date: 2018-09-19 / CAPES - Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / Testes de regressão são executados após cada mudança no software. Em ambientes de desenvolvimento de software que adotam práticas da Engenharia de Software Contínua, como a Integração contínua, por exemplo, software é modificado, e testado diversas vezes em curtos prazos. Cada execução dos testes pode levar horas para terminar, gerando atraso em relação à descoberta de falhas no projeto. Para prevenir esse atraso, técnicas de otimização são utilizadas. Uma delas é a priorização de casos de testes (TCP). Nessa técnica, a execução dos testes é reordenada de acordo com um objetivo, que normalmente é a detecção de falhas. Dessa forma, testes que têm maior probabilidade de falhas são executados primeiro. Um problema com essa abordagem é que existem diversas técnicas na literatura, mas pouca evidência em relação ao seu uso. Além disso, quase não existe infra estrutura para apoiar a adoção dessas técnicas no contexto industrial. O objetivo deste trabalho é planejar e implementar um framework que permita o uso, experimentação e implementação de técnicas de TCP. Esperamos que isso ajude praticantes a adotar essas técnicas no contexto industrial, principalmente da engenharia de software continua. Esperamos também que a criação dessa infra estrutura ajude pesquisadores a executar mais estudos experimentais sobre a eficiência do uso dessas técnicas. Para mostrar a viabilidade do framework proposto, é executado um estudo experimental com 16 técnicas de priorização diferentes, executadas em um total de 22 versões de 2 projetos open source. Os resultados coletados sugerem que o uso das técnicas de priorização resultam em retornos mais rápidos em relação à existência de falhas nos projetos, possivelmente resultando em ciclos mais rápidos de desenvolvimento. / Regression tests are executed after every change in software. In a software development environment that adopts Continuous Software Engineering practices such as Continuous Integration, software is changed, built and tested many times in a short period. Each execution can take hours to finish, delaying feedback about failures to the developer. To prevent this, regression test optimization techniques are used. One such technique is test case prioritization (TCP), which reorder the execution of the test cases according to some goal. The most common goal is fault detection, in which test cases are ordered so that those that have higher probability of detecting faults are executed first. One problem with this approach is that there are lots of different available techniques in the literature, but the amount of evidence of its use is low. Furthermore, there is almost no infrastructure support to adopt those techniques at the industry context. The goal of this work is to design and implement a framework that allows the use, experimentation and implementation of TCP techniques. We hope that this will help practitioners on adopting these techniques at the industry context, more specifically, in the continuous software engineering environment. We also hope that creating this infrastructure will encourage researchers on performing more empirical studies regarding test case prioritization techniques effectiveness. In order to show the feasibility of the proposed framework, we perform an empirical study with 16 different TCP techniques executed on a total of 22 versions of 2 different open source projects. Results suggest that using those TCP techniques result in faster feedback about the existence of failures in the projects, possibly resulting in shorter development cycles.

Orientador: Cecília Mary Fischer Rubira / Tese (doutorado) ¿ Universidade Estadual de Campinas, Instituto de Computação / Made available in DSpace on 2018-08-21T03:56:22Z (GMT). No. of bitstreams: 1 Tizzei_LeonardoPondian_D.pdf: 4801081 bytes, checksum: 4be6c243f0c9f62c50e330561161fcdd (MD5) Previous issue date: 2012 / Resumo: Arquiteturas de linhas de produtos são essenciais para facilitar a evolução das linhas, pois ajudam a lidar com sua complexidade, abstraindo seus detalhes de implementação. A variabilidade arquitetural difere arquiteturas de linhas de produtos de arquiteturas de sistemas únicos. Ela reflete a existência de alternativas de projeto arquitetural e é expressa por meio de um conjunto de pontos de variação e variantes arquiteturais. A variabilidade arquitetural pode dificultar a evolução de arquiteturas de linhas produtos, pois a implementação da variabilidade software pode aumentar a complexidade da arquitetura com a possível adição de elementos e dependências extras. A variabilidade de linhas de produtos é usualmente capturada modelo de características e implementado pela arquitetura de linha de produtos. Entretanto, a implementação de características, pontos de variação e variantes podem estar espalhados por diversos elementos arquiteturais, o que dificulta a sua evolução. Em geral, cenários de evolução de linhas de produto envolvem adição e/ou remoção de características, mudança de uma característica obrigatória para opcional, entre outros. Quando cenários de evolução afetam características cujas implementações estão espalhadas na arquitetura, eles podem causar impacto de mudança em vários elementos arquiteturais. Estudos recentes exploram o uso de aspectos para modularizar a implementação de características em arquiteturas de linhas de produtos. Aspectos são usados para modularizar interesses transversais que, no contexto de linhas de produtos, são interesses que afetam diversas características. Contudo, esses estudos não consideram (i) arquiteturas componentizadas com interfaces explícitas e (ii) o uso integrado de componentes e aspectos para modularizar a implementação da variabilidade arquitetural. Idealmente aspectos devem ser modelados o mais cedo possível, de preferência, junto com o modelo de características para possibilitar a criação de arquiteturas bem estruturadas com aspectos. Todavia, não existem modelos que integrem o modelo de características e aspectos, nem métodos que consideram aspectos para gerar arquiteturas de linhas produtos a partir do modelo de características. A solução proposta nesta tese envolve inicialmente um estudo comparativo para mostrar a facilidade de evolução de arquiteturas de linhas de produtos propiciada pelo uso integrado de componentes e aspectos. Em seguida, é proposta uma visão estendida do modelo de características que permite representar características transversais. Essa visão, chamada de visão de características orientada a aspectos, é usada para criar arquiteturas de linhas de produtos orientadas a aspectos. Além disso, um modelo arquitetural de componentes é estendido para integrar aspectos para modularizar a variabilidade arquitetural. Por fim, o método FArM, que provê o mapeamento de modelo de características para modelos de arquitetura de linha de produtos, é estendido para considerar características transversais. Foram conduzidos dois estudos empíricos: um para avaliar se o uso integrado de componentes e aspectos facilita ou não a evolução de arquiteturas de linhas de produtos. O outro estudo empírico avalia a modelagem de características transversais e a extensão do método FArM propostos para projetar arquiteturas de linhas de produtos que sejam fáceis de evoluir. Os dois estudos apresentaram resultados promissores indicando que a solução proposta nesta tese facilita a evolução de arquiteturas de linhas de produtos / Abstract: Product line architectures are essential to facilitate the evolution of product lines, as they handle their complexity by abstracting implementation details. Architectural variability is what differs product line architectures from single system architectures. It reflects the existence of alternative design options and it is expressed by a set of architectural variation points and variants. Architectural variability can hinder product line architecture evolution because the implementation of software variability can increase architecture complexity by possibly adding extra elements and dependencies. Product line variability is usually captured in the feature model and it is implemented by product line architectures. However, the implementation of features, variation points, and variants may be scattered over architectural elements, which can hinder its evolution. In general, product line evolution scenarios involve feature addition/removal, changing a mandatory feature to an optional feature, and so forth. When evolution scenarios affect features whose implementations are scattered over architecture, they can cause a great change impact on several architectural elements. Recent studies have explored the use of aspects to modularize feature implementation in product line architectures. Aspects can modularize crosscutting concerns, which, in the context of product lines, are concerns that affect several features. Nevertheless, these studies do not consider (i) componentized architectures with explicit interfaces, and (ii) the integration of aspects and components to modularize the implementation of architectural variability. Ideally, aspects should be modeled as soon as possible, preferably, together with the feature model in order to enable the design of well structured product line architectures with aspects. However, there are neither models which integrate features and aspects, nor methods that considers aspects to design product line architectures from the feature model. The solution proposed in this thesis involves a comparative study that presents the support for product line architecture evolution provided by the integration of components and aspects. Then, it is proposed an extended view of the feature model which enables to represent crosscutting features. This view, called aspect-oriented feature view, is used to design product line architectures with aspects. Lastly, the FArM method, which provides guidelines to map from the feature model to the product line architecture model, is extended to consider crosscutting features. Two empirical studies were conducted: one to assess whether the integration of components and aspects facilitates product line architecture evolution. The other empirical study evaluates whether the crosscutting feature modeling and the FArM method extension proposed supports the design of evolvable product line architectures. Both studies presented promising results which indicate that the solution proposed in this thesis facilitates product line architecture evolution / Doutorado / Ciência da Computação / Doutor em Ciência da Computação

No description available.

Le contrôle de version est la pierre angulaire des processus de développement de logiciels modernes. Tout en construisant des logiciels de plus en plus complexes, les développeurs doivent comprendre des sous-systèmes de code source qui leur sont peu familier. Alors que la compréhension de la logique d'un code étranger est relativement simple, la compréhension de sa conception et de sa genèse est plus compliquée. Elle n'est souvent possible que par les descriptions des révisions et de la documentation du projet qui sont dispersées et peu fiables -- quand elles existent. Ainsi, les développeurs ont besoin d'une base de référence fiable et pertinente pour comprendre l'historique des projets logiciels. Dans cette thèse, nous faisons les premiers pas vers la compréhension des motifs de changement dans les historiques de révision. Nous étudions les changements prenant place dans les métriques logicielles durant l'évolution d'un projet. Au travers de multiples études exploratoires, nous réalisons des expériences quantitatives et qualitatives sur plusieurs jeux de données extraits à partir d'un ensemble de 13 projets. Nous extrayons les changements dans les métriques logicielles de chaque commit et construisons un jeu de donnée annoté manuellement comme vérité de base. Nous avons identifié plusieurs catégories en analysant ces changements. Un motif en particulier nommé "compromis", dans lequel certaines métriques peuvent s'améliorer au détriment d'autres, s'est avéré être un indicateur prometteur de changements liés à la conception -- dans certains cas, il laisse également entrevoir une intention de conception consciente de la part des auteurs des changements. Pour démontrer les observations de nos études exploratoires, nous construisons un modèle général pour identifier l'application d'un ensemble bien connu de principes de conception dans de nouveaux projets. Nos résultats suggèrent que les fluctuations de métriques ont le potentiel d'être des indicateurs pertinents pour gagner des aperçus macroscopiques sur l'évolution de la conception dans l'historique de développement d'un projet. / Version control is the backbone of the modern software development workflow. While building more and more complex systems, developers have to understand unfamiliar subsystems of source code. Understanding the logic of unfamiliar code is relatively straightforward. However, understanding its design and its genesis is often only possible through scattered and unreliable commit messages and project documentation -- when they exist. Thus, developers need a reliable and relevant baseline to understand the history of software projects. In this thesis, we take the first steps towards understanding change patterns in commit histories. We study the changes in software metrics through the evolution of projects. Through multiple exploratory studies, we conduct quantitative and qualitative experiments on several datasets extracted from a pool of 13 projects. We mine the changes in software metrics for each commit of the respective projects and manually build oracles to represent ground truth. We identified several categories by analyzing these changes. One pattern, in particular, dubbed "tradeoffs", where some metrics may improve at the expense of others, proved to be a promising indicator of design-related changes -- in some cases, also hinting at a conscious design intent from the authors of the changes. Demonstrating the findings of our exploratory studies, we build a general model to identify the application of a well-known set of design principles in new projects. Our overall results suggest that metric fluctuations have the potential to be relevant indicators for valuable macroscopic insights about the design evolution in a project's development history.