Made available in DSpace on 2013-08-07T18:43:32Z (GMT). No. of bitstreams: 1 000440403-Texto+Completo-0.pdf: 3359278 bytes, checksum: cbbeb61af35844dc984f05b444694a52 (MD5) Previous issue date: 2012 / Software testing process has a high cost when compared to the other stages of software development. Automation of software testing through reuse of software artifacts (e. g. models) is a good alternative for mitigating these costs and making the process much more efficient and effective. In this sense, the Model-Based Testing (MBT) approach has increased in Software Engineering. MBT is a technique of automatic generation of testing artifacts based on software models, which also includes the specification of the aspects to be tested. This work aims to study techniques and methodologies for MBT and to evaluate the features of the different models applied in MBT. The main contribution of this study is to analyze the features of the models that are used in performance testing of web applications. In another perspective, it presents an approach for generating test cases based on FSM (Finite State Machines). Furthermore, it describes the process of generating the test cases using the HSI method (Harmonized State Identification). Besides, the implementation of a plug-in in the PLeTs tool based on UML SPT profile, which interprets the set of features designed for performance testing, is presented in a real case study. Our work, defines which features must be present in a model when modeling user interactions with a SUT (System Under Test). This will allow the increasing in automation and in reusing testing artifacts throughout the systems development life cycle. Furthermore, our solution is generated automatically by a Software Product Line (SPL). / O processo de teste de software possui um custo elevado se comparado com as demais etapas de desenvolvimento de software. A automação do teste de software por meio do reuso de artefatos de software, e. g., modelos, tem sido uma boa alternativa para mitigar estes custos, reduzindo o tempo de geração e execução dos casos de teste, tornando mais eficiente e eficaz este processo. Nesse sentido, a abordagem de Teste Baseado em Modelos (Model Based Testing - MBT) está crescendo na Engenharia de Software. MBT é uma técnica que consiste na geração automática dos artefatos de teste com base em informações extraídas dos modelos de software, que inclui também a especificação dos aspectos que serão testados. O presente trabalho tem por objetivo estudar técnicas e metodologias para MBT e avaliar as características dos diferentes modelos aplicados em MBT. A principal contribuição deste estudo é a análise das características dos modelos que são utilizados no teste de desempenho em aplicações web. Em outra perspectiva, a pesquisa norteia a investigação de modelos e métodos para geração de sequências de teste. Assim, apresenta a abordagem de geração de casos de teste baseado em MEFs (Máquinas de Estados Finitos), conceituando MEF e ainda, descreve o processo de geração das sequências de teste através do método HSI (Harmonized State Identification). Por outro lado, a implementação de um plug-in para a ferramenta PLeTs, que implementa uma linha de produtos de software, baseado no modelo UML SPT, que interpreta o conjunto de características para teste de desempenho desenvolvido, é apresentado em um estudo de caso real. Com esta análise, definem-se quais características devem estar presentes no modelo para a modelagem das interações do usuário com o SUT (System Under Test), buscando o maior reuso deste modelo ao longo do ciclo de vida de desenvolvimento do software.

Made available in DSpace on 2013-08-07T18:43:35Z (GMT). No. of bitstreams: 1 000435657-Texto+Completo-0.pdf: 3785156 bytes, checksum: 2a6a2c74bb198ad7ec9dca9005145e97 (MD5) Previous issue date: 2009 / The maintenance and software evolution demands a high cost to the organizations. One of the reasons for this high cost is the lack of documentation. The requirements represent an important way of documenting the software. Very commonly the requirements are not updated after the end of the software development project. The requirements are not updated during the maintenance phase. The purpose of this research is to propose a solution to the problem of keeping the software application requirements up to date and consistent during the software maintenance process. The solution is represented by a requirements management model that supports the updating and consistency of the requirements during the maintenance. This model is formed by a Conceptual Model, that represents the concepts involved in the problem and how they are related to each other in order that it is possible to reach the purpose, consistency rules, and a process to track the versions of the requirements. The results are presented through examples, illustrating various possible scenarios, using the prototype developed based on the proposed model. The main contribution of this research is a model that helps to maintain the software requirements up to date and consistent along the maintenance process, besides to help on the impact analysis of change requests. / A manutenção e evolução do software demanda um custo muito alto das organizações. Um dos motivos para este alto custo é a falta de documentação. Os requisitos representam um dos principais meios de documentação do software. Geralmente os requisitos não são atualizados depois do término do desenvolvimento do software, ou seja, não são atualizados durante a fase de manutenção. O objetivo desta pesquisa é propor uma solução para o problema de manter os requisitos de aplicações de software atualizados e consistentes ao longo de processos de manutenção. A solução consiste em um modelo de gerência de requisitos que suporta a atualização e consistência dos requisitos ao longo de processo de manutenção. Este modelo é constituído por um Modelo Conceitual, representando os conceitos envolvidos no problema e como eles devem estar relacionados para que seja possível alcançar o objetivo, regras de consistência, e um mecanismo de versionamento dos requisitos. Os resultados são demonstrados através de exemplos, ilustrando os diversos cenários possíveis, utilizando um protótipo desenvolvido a partir do modelo proposto. A principal contribuição deste trabalho é um modelo que auxilie a manter os requisitos de software atualizados e consistentes ao longo de processos de manutenção, além de auxiliar na análise de impacto das requisições de mudança.

Buscando aumentar a qualidade de software, a área de Engenharia de Software tem produzido ferramentas para auxílio ao desenvolvimento de software assim como tem estudado e produzido formas de controlar o processo de desenvolvimento. A tecnologia existente para coordenação de atividades humanas - incluindo sistemas de Workflow e PSEE (Process-Centered Software Engineering Environments) - possui algumas limitações. Uma das principais é a falta de flexibilidade. Algumas características importantes de processos de software não têm sido levadas em consideração pela tecnologia disponível, como por exemplo: o aspecto humano envolvido, a dificuldade em definir todo o processo antes de executá-lo, o tratamento de mudanças durante a execução, dentre outras. Além disso, quando se considera a construção de PSEEs, notase a necessidade de uma abordagem formal adequada, que permita um melhor entendimento, análise e comparação com outros modelos. Este trabalho apresenta e discute um modelo conceitual e mecanismos para contribuir para o aumento da flexibilidade e do nível de automação fornecidos para execução de processos. Para atingir os objetivos do trabalho, foi proposta uma arquitetura, denominada APSEE, construída a partir de um meta-modelo unificado que integra informações organizacionais, gerenciais, sobre artefatos do processo, e sobre ferramentas do ambiente. O modelo proposto define de forma rigorosa seus componentes. Assim, as propriedades de recursos e pessoas são descritas visando melhorar o controle de sua alocação, permitindo a construção de um mecanismo de apoio à instanciação de recursos e pessoas em processos. Além disso, uma linguagem de modelagem visual de processos de software é proposta. Por fim, é fornecido o mecanismo de execução de processos que permite modificações dinâmicas, verifica a consistência dessas modificações, e permite acompanhamento da execução de processos pelo gerente. Os diferentes componentes envolvidos na definição do modelo APSEE proposto foram especificados formalmente através de método algébrico e também através da abordagem de gramáticas de grafos, constituindo uma base semântica de alto nível de abstração que deu origem a um conjunto de protótipos implementados como ferramentas do ambiente PROSOFT-Java. A implementação também serviu para constatar a viabilidade do uso do APSEE como plataforma de integração para vários serviços de gerência de processos desenvolvidos como atividades de pesquisa no contexto do grupo PROSOFT. Finalmente, são apresentadas considerações acerca dos trabalhos relacionados, os elementos críticos que influenciam a aplicabilidade do modelo e as atividades adicionais vislumbradas a partir do trabalho proposto. / Software Engineering evolved to increase software quality through the definition of tools to support both development and management processes. However, the existing technology to provide automated support for human activity coordination - mainly represented by Workflow Management Systems and Process-Centered Software Engineering Environments (PSEEs) - has some limitations. One of the most important limitations is related to the low level of flexibility provided by current tools. Existing technologies provide limited support for some important software process characteristics, which includes, for example, the humanistic aspect of software processes, the difficult to completely prescribe the process model in advance, and the lack of adequate support for dynamic changes on enacting processes. Besides, the construction of a PSEE demand an adequate formal approach for its specification, which can improve its understandability and analysis, while constitutes a basis for comparison with similar proposals. This work presents and discusses a conceptual model and mechanisms which jointly aim to increase the level of flexibility and automation provided for software processes enactment. In order to reach this goal, a software-based architecture is proposed, named APSEE, which provides a unified meta-model that integrates organizational and management information, along with software artifact and tool support. The proposed meta-model rigorously defines its components. Therefore, resource and people properties are formally described in order to allow better allocation through an automated process instantiation mechanism. In addition, a visual software process modeling language is provided which is, in turn, related to the underlying meta-model. Finally, a flexible process enactment mechanism was specified to support dynamic changes on process models that work together with consistency check and monitoring mechanisms. The required software components for the proposed meta-model were specified using algebraic specification and graph grammar-based techniques which, in turn, were used to build prototypes for the Java-PROSOFT environment. This implementation was also useful to evaluate the feasibility of using APSEE as an integration platform for a number of process management services developed by PROSOFT research group. Finally, it is discussed how this proposal relates to the current technological state-ofthe- art, the critical elements that can influence its applicability and effectiveness, and the expected future activities.

Dissertacão (mestrado)—Universidade de Brasília, Instituto de Ciências Exatas, Departamento de Ciência da Computação, 2012. / Submitted by Albânia Cézar de Melo (albania@bce.unb.br) on 2013-03-06T14:48:58Z No. of bitstreams: 1 2012_GiselleBarbosaGomesMachado.pdf: 2502157 bytes, checksum: 546f74d269d83203ea1a194e81a23681 (MD5) / Approved for entry into archive by Guimaraes Jacqueline(jacqueline.guimaraes@bce.unb.br) on 2013-03-25T11:31:48Z (GMT) No. of bitstreams: 1 2012_GiselleBarbosaGomesMachado.pdf: 2502157 bytes, checksum: 546f74d269d83203ea1a194e81a23681 (MD5) / Made available in DSpace on 2013-03-25T11:31:48Z (GMT). No. of bitstreams: 1 2012_GiselleBarbosaGomesMachado.pdf: 2502157 bytes, checksum: 546f74d269d83203ea1a194e81a23681 (MD5) / Um grande desafio em linha de produtos (LPs) é garantir as propriedades dos produtos gerados. Com o crescimento exponencial do número de produtos em função do número de características, assegurar que qualquer produto cumpre uma dada propriedade é um problema não trivial. Em particular, este é um problema válido para verificar a boa-formação em LPs. Embora tenha sido explorado em alguns níveis de abstração (por exemplo, a implementação), este problema permanece inexplorado para a linha de produtos de pro cesso de negócios que foi desenvolvida usando uma abordagem composicional e possui melhor modularidade. Assim, nesta dissertação, tratamos do problema de verificação da boa-formação em Linha de Produtos de Processo de Negócio, incluindo a definição de regras de boa-formação de processos de negócio, especificação formal de transformações composicionais, a análise de exemplos e contraexemplos gerados pelo model checking, e a prova de que transformações preservam as propriedades de todos os produtos sem realmente ter que instanciá-los. Foi realizada uma formalização de linha de produtos de processo de negócio em Alloy coma ferramenta Alloy Analyzer, que possui uma linguagem de especificação formal e um mecanismo de verificaço de propriedades (model checking). Também foram realizadas formalização de linha de produtos de processo de negócio e provas de teoremas no Prototype Verification System (PVS), que tem uma linguagem de especificação formal e um assistente de provas. ___________________________________________________________________________________ ABSTRACT / Quality assurance is a key challenge in product lines (PLs). Given the exponential growth of the number of products depending on the number of features, ensuring that all products meet given properties is a non-trivial issue. In particular, this holds for well-formedness in PLs. Although this has been explored at some levels of abstraction (e.g., implementa-tion), this remains unexplored for business process PLs developed using a compositional approach, which has better modularity. Accordingly, in this dissertation we treat the problem of verification of well-formedness Business Process in Product Line, including the definition of well-formedness rules of business process, formal specification of com- positional transformations, the analysis of examples and counterexamples generated by model checking, and the proof that transformations preserve the properties of all products without having to instantiate all variants. We performed a formalization of business process product line with the Alloy tool Alloy Analyzer, which has a formal specification language and a mechanism for verifying properties (model checking). Also formalization of business process product line and proofs of theorems were provided in the Prototype Verification System, which has a formal specification language and a proof assistant.

Dissertação (mestrado)-Universidade de Brasília, Instituto de Ciências Exatas, Departamento de Ciência da Computação, 2011. / Submitted by Luciana Monteiro de Barros Reis (lmbreis@gmail.com) on 2012-01-11T14:16:26Z No. of bitstreams: 1 2011_BrunoSouzaCostaPedroso.pdf: 2601476 bytes, checksum: b23810de1299cd885d6bc5f8edee7ec8 (MD5) / Approved for entry into archive by Patrícia Nunes da Silva(patricia@bce.unb.br) on 2012-01-17T14:16:51Z (GMT) No. of bitstreams: 1 2011_BrunoSouzaCostaPedroso.pdf: 2601476 bytes, checksum: b23810de1299cd885d6bc5f8edee7ec8 (MD5) / Made available in DSpace on 2012-01-17T14:16:51Z (GMT). No. of bitstreams: 1 2011_BrunoSouzaCostaPedroso.pdf: 2601476 bytes, checksum: b23810de1299cd885d6bc5f8edee7ec8 (MD5) / Os resultados das pesquisas empíricas sobre os efeitos do Desenvolvimento Guiado por Testes (TDD) ainda são muito pouco conclusivos. Uma das maiores dificuldades enfrentadas por esses estudos reside em controlar o grau de conformidade dos programadores com a técnica. Algumas abordagens já foram propostas para medir essa variável de forma automática, mas muito ainda se tem para evoluir a esse respeito. O objetivo desse trabalho é o de analisar e propor melhorias ao sistema Zorro, bem como o de avaliar o resultado dessas modificações, por meio de um experimento piloto, como estudo de viabilidade. Duas melhorias principais são propostas ao sistema de regras original, uma das quais pode aumentar a precisão do sistema em cerca de 8%. ______________________________________________________________________________ ABSTRACT / The results of empirical research on the effects of Test Driven Development (TDD) are not very conclusive so far. One of the main difficulties of such studies is in controlling the level of conformance of programmers with the technique. Some approaches have already been proposed to automatically evaluate this variable, but there are still many improvement opportunities left. The intent of this work is to analyze and propose improvements to the Zorro system, and to evaluate this modifications through a pilot experiment, as a viability study. Two main improvements have been proposed to the original rules system, one of them can make the system about 8% more precise.

Buscando aumentar a qualidade de software, a área de Engenharia de Software tem produzido ferramentas para auxílio ao desenvolvimento de software assim como tem estudado e produzido formas de controlar o processo de desenvolvimento. A tecnologia existente para coordenação de atividades humanas - incluindo sistemas de Workflow e PSEE (Process-Centered Software Engineering Environments) - possui algumas limitações. Uma das principais é a falta de flexibilidade. Algumas características importantes de processos de software não têm sido levadas em consideração pela tecnologia disponível, como por exemplo: o aspecto humano envolvido, a dificuldade em definir todo o processo antes de executá-lo, o tratamento de mudanças durante a execução, dentre outras. Além disso, quando se considera a construção de PSEEs, notase a necessidade de uma abordagem formal adequada, que permita um melhor entendimento, análise e comparação com outros modelos. Este trabalho apresenta e discute um modelo conceitual e mecanismos para contribuir para o aumento da flexibilidade e do nível de automação fornecidos para execução de processos. Para atingir os objetivos do trabalho, foi proposta uma arquitetura, denominada APSEE, construída a partir de um meta-modelo unificado que integra informações organizacionais, gerenciais, sobre artefatos do processo, e sobre ferramentas do ambiente. O modelo proposto define de forma rigorosa seus componentes. Assim, as propriedades de recursos e pessoas são descritas visando melhorar o controle de sua alocação, permitindo a construção de um mecanismo de apoio à instanciação de recursos e pessoas em processos. Além disso, uma linguagem de modelagem visual de processos de software é proposta. Por fim, é fornecido o mecanismo de execução de processos que permite modificações dinâmicas, verifica a consistência dessas modificações, e permite acompanhamento da execução de processos pelo gerente. Os diferentes componentes envolvidos na definição do modelo APSEE proposto foram especificados formalmente através de método algébrico e também através da abordagem de gramáticas de grafos, constituindo uma base semântica de alto nível de abstração que deu origem a um conjunto de protótipos implementados como ferramentas do ambiente PROSOFT-Java. A implementação também serviu para constatar a viabilidade do uso do APSEE como plataforma de integração para vários serviços de gerência de processos desenvolvidos como atividades de pesquisa no contexto do grupo PROSOFT. Finalmente, são apresentadas considerações acerca dos trabalhos relacionados, os elementos críticos que influenciam a aplicabilidade do modelo e as atividades adicionais vislumbradas a partir do trabalho proposto. / Software Engineering evolved to increase software quality through the definition of tools to support both development and management processes. However, the existing technology to provide automated support for human activity coordination - mainly represented by Workflow Management Systems and Process-Centered Software Engineering Environments (PSEEs) - has some limitations. One of the most important limitations is related to the low level of flexibility provided by current tools. Existing technologies provide limited support for some important software process characteristics, which includes, for example, the humanistic aspect of software processes, the difficult to completely prescribe the process model in advance, and the lack of adequate support for dynamic changes on enacting processes. Besides, the construction of a PSEE demand an adequate formal approach for its specification, which can improve its understandability and analysis, while constitutes a basis for comparison with similar proposals. This work presents and discusses a conceptual model and mechanisms which jointly aim to increase the level of flexibility and automation provided for software processes enactment. In order to reach this goal, a software-based architecture is proposed, named APSEE, which provides a unified meta-model that integrates organizational and management information, along with software artifact and tool support. The proposed meta-model rigorously defines its components. Therefore, resource and people properties are formally described in order to allow better allocation through an automated process instantiation mechanism. In addition, a visual software process modeling language is provided which is, in turn, related to the underlying meta-model. Finally, a flexible process enactment mechanism was specified to support dynamic changes on process models that work together with consistency check and monitoring mechanisms. The required software components for the proposed meta-model were specified using algebraic specification and graph grammar-based techniques which, in turn, were used to build prototypes for the Java-PROSOFT environment. This implementation was also useful to evaluate the feasibility of using APSEE as an integration platform for a number of process management services developed by PROSOFT research group. Finally, it is discussed how this proposal relates to the current technological state-ofthe- art, the critical elements that can influence its applicability and effectiveness, and the expected future activities.

As maiores dificuldades encontradas no teste de software estão relacionadas à definição dos dados de teste e a decisão de quando encerrar os testes. Uma das formas encontradas para minimizar tais dificuldades está centrada na utilização de critérios de cobertura. O principal objetivo dos critérios de cobertura é tornar o processo de testes mais rápido e preciso, fornecendo informações que determinem o que testar em um software para garantir sua qualidade. A modelagem é um dos elementos de maior importância nas atividades relacionadas ao desenvolvimento de software. Os modelos são construídos principalmente para melhor se entender o sistema, descrever a estrutura e comportamento desejados, visualizar a arquitetura e documentar as decisões tomadas durante o seu desenvolvimento. Atualmente, o sistema de notação mais utilizado para a modelagem de sistemas baseados nos conceitos de orientação a objetos é a Linguagem de Modelagem Unificada – UML [LAR 99]. Nesta notação, um sistema é descrito por um conjunto de diagramas que apresentam diferentes aspectos do sistema. As informações disponibilizadas por estes diagramas propiciam, já nas fases iniciais do desenvolvimento da aplicação (análise e projeto), o planejamento dos casos de teste e a definição de critérios de cobertura. Observa-se que nestas fases a maioria das informações necessárias para o teste já estão disponíveis, como por exemplo, a definição das classes com seus atributos, métodos e relacionamentos, a representação da interação existente entre objetos para a realização de um cenário e a descrição dos possíveis estados e transições de um objeto em resposta a eventos externos e internos. Este trabalho propõe um conjunto de diretrizes e critérios de cobertura de teste, tendo como base as especificações diagramáticas UML. As diretrizes estabelecem um conjunto de instruções para que o teste seja feito e os critérios de cobertura identificam os pontos principais e serem considerados durante o teste. Na definição das diretrizes e dos critérios foram avaliadas as informações disponibilizadas pelos diagramas de classes, seqüência, colaboração e estados.

Submitted by João Arthur Martins (joao.arthur@ufpe.br) on 2015-03-10T17:52:54Z No. of bitstreams: 2 Dissertaçao Fabiana Flores.pdf: 3625913 bytes, checksum: 3dd16314b280ed6b6143388ebe93ccce (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-11T17:37:34Z (GMT). No. of bitstreams: 2 Dissertaçao Fabiana Flores.pdf: 3625913 bytes, checksum: 3dd16314b280ed6b6143388ebe93ccce (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2013-07-09 / O desenvolvimento de software tornou-se uma atividade essencialmente dependente do trabalho coletivo, sendo, então, relevante se estudar, neste domínio, como as equipes são concebidas, sua estruturação, caracteres e formação. Com foco na ampliação deste conhecimento e na identificação de fatores importantes ao desempenho das equipes, foi conduzido um estudo qualitativo baseado em análise temática. Trinta e sete artigos, previamente apreciados em trabalho relacionado, foram reexaminados sob uma nova abordagem fundada em diferentes referencial teórico e protocolo de análise. Os resultados da nova pesquisa sugerem que, atualmente: a) não há, na indústria de software, conhecimento formal a respeito de equipes; b) equipes são construídas de diversas maneiras diferentes; c) a construção de equipes se constitui em tarefa dependente de habilidades individuais; d) múltiplos fatores inter-relacionados influenciam os desempenhos das equipes de desenvolvimento de software; e) diversas estratégias são empregadas para o gerenciamento destes fatores.

Made available in DSpace on 2014-06-12T16:00:42Z (GMT). No. of bitstreams: 2 arquivo6892_1.pdf: 12551112 bytes, checksum: f5803d2f7b194b0634e5ba658aaf40fe (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / Conselho Nacional de Desenvolvimento Científico e Tecnológico / A abordagem de Linhas de Produtos de Software (SPL) pode ser considerada uma estratégia eficiente para o reuso de software. SPL oferece significativos benefícios econômicos para as empresas, tais como redução de custos, melhoria da qualidade, e redução do tempo de entrega de produtos. SPL baseia-se no reuso sistemático de artefatos, através da exploração de commonalities (pontos em comum), e o gerenciamento de variabilities (pontos de variação) entre os produtos, desenvolvidos sob uma arquitetura comum. No entanto, a percepção das vantagens de SPL tem um custo associado. Elas demandam maturidade nas técnicas de engenharia de software, planejamento e gerenciamento de reuso, adequadas práticas para gerenciamento e desenvolvimento, sendo capaz de lidar com questões organizacionais e de complexidade arquitetural. Na prática, não é relativamente fácil adotar a abordagem de linha de produto. No contexto de pequenas e medias empresas (SMEs), as dificuldades para adoção de linha de produto são ainda maiores, devido a baixa maturidade organizacional e falta de recursos comum a este tipo de organização. Neste contexto, esta dissertação apresenta um conjunto de evidências empíricas sobre a adoção de linhas de produto em pequenas e médias empresas. O conjunto de evidências contribui para o entendimento da adoção de linha de produto em SMEs por documentar barreiras, as melhores práticas existentes, experiências etc., facilitando a adoção da abordagem de SPL no futuro. Esta dissertação apresenta ainda uma abordagem multi-método para pesquisa empírica em engenharia de software, conduzida através da triangulação, combinando diferentes, mas complementares métodos de pesquisa, aumentando desta maneira a disponibilidade de conhecimento empírico na área.

Submitted by Pedro Barros (pedro.silvabarros@ufpe.br) on 2018-06-21T22:55:48Z No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) DISSERTAÇÃO Gabriela Cunha Sampaio.pdf: 1837542 bytes, checksum: ed41241bb8c57deeb0b4a9a626f13a1a (MD5) / Made available in DSpace on 2018-06-21T22:55:48Z (GMT). No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) DISSERTAÇÃO Gabriela Cunha Sampaio.pdf: 1837542 bytes, checksum: ed41241bb8c57deeb0b4a9a626f13a1a (MD5) Previous issue date: 2017-03-27 / CAPES / Software product lines (SPLs) are sets of related systems that are built based on reusable artifacts. They have three elements: a variability model, that has feature declarations and dependencies among them; implementation artifacts and a configuration knowledge, that maps features to their implementation. SPLs provide several advantages, like software quality and reuse improvements, productivity gains and the capacity to customize a system depending on customers needs. There are several challenges in the SPL development context. To build customizable software and meet all customer needs, SPLs tend to increase over time. The larger a SPL becomes, the higher is the complexity to evolve it. Therefore, it is not trivial to predict which products are affected by a change, specially in large SPLs. One might need to check if products had their behaviour preserved to avoid inadvertently affecting existing users in an evolution scenario. In refactoring and conservative extension scenarios, we can avoid this problem by checking for behavior preservation, either by testing the generated products or by using formal theories. Product line refinement theories support that by requiring behavior preservation for all existing products. This happens in a number of situations, such as code refinements. For instance, in function renaming transformations, all existing products behave exactly as before the change, so we can say that this transformation is safe. Another example of SPL refinement would be changing a feature type from mandatory to optional. In this case, we increase variability, but preserving all products from the original SPL. Although several evolution scenarios are safe (or technically refinement), in many others, such as bug fixes or feature removals, there is a high chance that only some of the products are refined. In these scenarios, the existing theories would give no support, since we can not assume behaviour preservation holds for all products. To support developers in these and o ther non refinement situations, we define partially safe evolution for product lines, that is formalised through a theory of partial refinement that helps to precisely understand which products should not be affected by an evolution scenario. This provides a kind of impact analysis that could, for example, reduce test effort, since products not affected do not need to be tested. Additionally, we formally derive a catalog of partial refinement templates that capture evolution scenarios, and associated preconditions, not covered before. Finally, we evaluate the proposed templates by analyzing commits from two product line systems (Linux and Soletta) and we found evidence that those templates could cover a number of practical evolution scenarios. / Linhas de produto de software (LPSs) são conjuntos de sistemas relacionados desenvolvidos a partir de artefatos reusáveis. Há diversas vantagens de se trabalhar com LPS, como melhorias na qualidade do código e o aumento de reuso, e também ganhos em produtividade e uma maior customização do software, que se torna configurável para atender aos critérios dos clientes. Porém, há também muitos desafios. Os sistemas tendem a crescer com o tempo, o que aumenta a complexidade de evoluir a LPS. Então, a tarefa de descobrir o conjunto de produtos afetados em uma mudança se torna não trivial, principalmente em LPS maiores. Os desenvolvedores eventualmente precisam verificar se os produtos existentes preservaram comportamento para evitar afetar usuários inadvertidamente. Em cenários de refatoração e extensão conservadora, nós podemos evitar esse problema checando se o comportamento dos produtos foi preservado através da realização de testes nos produtos gerados, ou ainda com o uso de teorias formais. De fato, isso acontece em várias situações. Por exemplo, em cenários de refinamentos de código, como renomeações de funções, todos os produtos continuam se comportando exatamente da mesma forma, então nós dizemos que esta evolução é segura. Outro exemplo de refinamento de LPS seria alterar o tipo de uma feature mandatória para opcional. Neste caso, nós estamos aumentando variabilidade, mas preservando todos os produtos da LPS original. Apesar de haver um grande número de cenários de evolução segura (o que tecnicamente, é sinônimo de refinamento), em outros, como correções de defeitos ou remoções de features, existe uma chance razoável de apenas alguns produtos serem refinados. Nestes cenários, as teorias existentes não seriam capazes de dar suporte, já que nem todos os produtos preservam comportamento. Para dar suporte aos desenvolvedores nestes e em outros cenários de não refinamento, nós definimos o conceito de evolução parcialmente segura de linhas de produto de software, que é formalizado através de uma teoria de refinamento parcial, que ajuda a entender precisamente que produtos não devem ser afetados num cenário de evolução. Com isto, nós provemos uma espécie de análise de impacto que poderia, por exemplo, reduzir o esforço envolvido no desenvolvimento de testes, dado que produtos não afetados não precisariam ser testados. Adicionalmente, nós derivamos formalmente um catálogo de templates de refinamento parcial que capturam cenários de evolução, e pré-condições associadas, não cobertos anteriormente. Finalmente, nós avaliamos os templates propostos através de uma análise de commits de duas LPS (Linux e Soletta) e encontramos evidência de que os templates poderiam cobrir uma série de cenários práticos de evolução.