Submitted by Irene Nascimento (irene.kessia@ufpe.br) on 2016-09-27T18:16:18Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) dissertação_gjcc.pdf: 1929523 bytes, checksum: 59a910a15e3537942754d106de378d19 (MD5) / Made available in DSpace on 2016-09-27T18:16:18Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) dissertação_gjcc.pdf: 1929523 bytes, checksum: 59a910a15e3537942754d106de378d19 (MD5) Previous issue date: 16-02-29 / FACEPE / During the integration of code contributions resulting from development tasks, one likely has to deal with conflicting changes and dedicate substantial effort to resolve conflicts. While unstructured merge tools try to automatically resolve part of the conflicts via textual similarity, semistructured tools try to go further by exploiting the syntactic structure of part of the artefacts involved. To understand the impact of the unstructured and semistructured merge approaches on integration effort (Productivity) and correctness of the merging process (Quality), we conduct two empirical studies. In the first one, aiming at increasing the existing body of evidence and assessing results for systems developed under an alternative version control paradigm, we replicate an experiment to compare the unstructured and semistructured approaches with respect to the number of conflicts reported by both merge approaches. We used both semistructured and unstructured merge in a sample 2.5 times bigger than the original study regarding the number of projects and 18 times bigger regarding the number of performed merges, and we compared the occurrence of conflicts. Similar to the original study, we observed that semistructured merge reduces the number of conflicts in 55% of the performed merges of the new sample. Besides that, the observed average conflict reduction of 62% in these merges is far superior than what has been observed before. We also bring new evidence that the use of semistructured merge can reduce the occurrence of conflicting merges by half. In order to verify the frequency of false positives and false negatives arising from the use of these merge approaches, we move forward and we conduct a second empirical study. We compare the unstructured and semistructured merge approaches by reproducing more than 30,000 merges from 50 projects, and collecting evidence about reported conflicts that do not represent interferences between development tasks (false positives), and interferences not reported as conflicts (false negatives). In particular, our assumption is that false positives amount to unnecessary integration effort because developers have to resolve conflicts that actually do not represent interferences. Besides that, false negatives amount to build issues or bugs, negatively impacting software quality and correctness of the merging process. By analyzing such critical factors we hope to guide developers on deciding which approach should be used in practice. Finally, our results show that semistructured merge eliminates a significant part of the false positives reported by unstructured merge, but brings false positives of its own. The overall number of false positives is reduced with semistructured merge, and we argue that the conflicts associated to its false positives are easier to resolve when comparing to the false positives reported by unstructured merge. We also observe that more interferences were missed by unstructured merge and reported by semistructured merge, but we argue that the semistructured merge ones are harder to detect and resolve than the other way around. Finally, our study suggests how a semistructured merge tool could be improved to eliminate the extra false positives and negatives it has in relation to unstructured merge. / Durante a integração de contribuições de código resultantes das tarefas de desenvolvimento, frequentemente desenvolvedores têm que lidar com alterações conflitantes e dedicar considerável esforço para resolver conflitos. Enquanto as ferramentas de integração não-estruturadas tentam resolver automaticamente parte dos conflitos através de similaridade textual, ferramentas semiestruturadas tentam ir mais longe, explorando a estrutura sintática de parte dos artefatos envolvidos. Para entender o impacto das abordagens de integração não-estruturada e semiestruturada sobre esforço de integração (Produtividade) e corretude do processo de integração (Qualidade), nós realizamos dois estudos empíricos. No primeiro, com o objetivo de aumentar o atual corpo de evidência e avaliar resultados para sistemas desenvolvidos usando um paradigma de controle de versão alternativo, nós replicamos um experimento para comparar a abordagem não-estruturada e semiestruturada de acordo com o número de conflitos reportados por ambas as abordagens. Nós usamos tanto a integração semiestruturada quanto a não-estruturada em uma amostra 2,5 vezes maior do que a do estudo original em relação ao número de projetos e 18 vezes maior em relação ao número de integrações realizadas, e comparamos a ocorrência de conflitos. Semelhante ao estudo original, observamos que a integração semiestruturada reduz o número de conflitos em 55% das integrações da nova amostra. Além disso, a redução de conflitos média observada de 62% nestas integrações é muito superior à observada anteriormente. Nós também trazemos nova evidência de que o uso da abordagem semiestruturada pode reduzir a ocorrência de integrações com conflitos pela metade. Com o intuito de verificar a frequência de falsos positivos e falsos negativos originados do uso dessas abordagens, nós seguimos adiante e conduzimos um segundo estudo empírico. Nós comparamos as abordagens reproduzindo mais de 30.000 integrações de 50 projetos, coletando evidência sobre os conflitos reportados que não representam interferências entre as tarefas de desenvolvimento (falsos positivos), e interferências não reportadas como conflitos (falsos negativos). Em particular, a nossa suposição é de que falsos positivos denotam esforço desnecessário de integração porque os desenvolvedores têm que resolver conflitos que, na realidade, não representam interferências. Além disso, falsos negativos denotam problemas de build ou bugs, impactando negativamente a qualidade do software e corretude do processo de integração. Ao analisar esses fatores críticos, esperamos orientar os desenvolvedores em decidir qual abordagem deve ser usada na prática. Finalmente, nossos resultados mostram que a abordagem semiestruturada elimina uma parte significativa dos falsos positivos reportados pela abordagem não-estruturada, mas traz falsos positivos próprios. O número global de falsos positivos é reduzido com a integração semiestruturada, e nós argumentamos que os conflitos associados aos seus falsos positivos são mais fáceis de resolver quando comparados aos falsos positivos reportados pela abordagem não-estruturada. Observamos, também, que mais interferências deixaram de ser detectadas pela abordagem não-estruturada, mas foram detectadas pela semiestruturada. No entanto, nós acreditamos que as interferências não detectadas pela abordagem semiestruturada são mais difíceis de detectar e resolver. Por fim, nosso estudo sugere como uma ferramenta de integração semiestruturada poderia ser melhorada para eliminar os falsos positivos e falsos negativos adicionados que possui em relação à não-estruturada.

Submitted by JOSIANE SANTOS DE OLIVEIRA (josianeso) on 2018-04-25T16:10:27Z No. of bitstreams: 1 Maicon dos Santos_.pdf: 3747706 bytes, checksum: ef8b81f35d6d19fc23c56bfba79044c5 (MD5) / Made available in DSpace on 2018-04-25T16:10:27Z (GMT). No. of bitstreams: 1 Maicon dos Santos_.pdf: 3747706 bytes, checksum: ef8b81f35d6d19fc23c56bfba79044c5 (MD5) Previous issue date: 2018-01-18 / Nenhuma / Engenharia reversa de código desempenha um papel fundamental em várias atividades de Engenharia de Software, tais como geração de modelos a partir de código legado e recuperação de funcionalidades (ou features) de sistemas. No contexto de Linha de Produto de Software (LPS), por exemplo, um produto de software é formado por um conjunto de features que são constantemente alteradas para acomodar mudanças de regras de negócio. Consequentemente, o modelo (por exemplo, diagrama de classes da UML) que representa toda LPS precisa ser modificado para refletir as atualizações realizadas. Neste contexto, várias ferramentas têm sido propostas nas últimas décadas, por exemplo, Astah e ArgoUML. Porém, as ferramentas (e suas técnicas) não dão suporte à engenharia reversa orientada a features, são imprecisas no que se refere à completude dos diagramas gerados, bem como exige um alto esforço para atualização dos modelos pois são manuais ou semiautomáticas. Para mitigar esta problemática, este trabalho propõe a TechREF, uma técnica de engenharia reversa orientada a features. De forma automática, a TechREF captura o fluxo de execução do código associado a uma feature, identifica as informações estruturais e comportamentais do código, e gera diagramas de classes UML, bem como persiste tais diagramas. A TechREF foi avaliada através de um estudo de caso tendo cenários reais de engenharia reversa. Esta avaliação buscou verificar o esforço e a corretude das atividades que serão realizadas no experimento com o uso dos modelos orientados a features. / Reverse code engineering plays a key role in various Software Engineering activities, such as model generation from legacy code and retrieval of system features. In the context of Software Product Line (LPS), for example, a software product is composed of a set features that are constantly changed to accommodate changes in business rules. Consequently, the model (for example, UML class diagram) that represents the entire LPS needs to be modified to reflect the updates made. In this context, several tools have been proposed in the last decades, for example, Astah and ArgoUML. However, the tools (and their techniques) do not support feature-oriented reverse engineering, are imprecise in terms of the completeness of the generated diagrams, as well as requiring a high effort to update the models because they are manual or semiautomatic. To mitigate this problem, this paper proposes TechREF, a reverse engineering technique oriented to features. Automatically, TechREF captures the execution flow of code associated with a feature, identifies the structural and behavioral information of the code, and generates diagrams of UML classes, as well as persists such diagrams. TechREF was evaluated through a case study having real reverse engineering scenarios. This evaluation sought to verify the effort and correctness of the activities that will be carried out in the experiment with the use of the models oriented to features.