Partially safe evolution of software product lines

• Main Author: SAMPAIO, Gabriela Cunha
• Other Authors: http://lattes.cnpq.br/9395715443254344
• Language: English
• Published: Universidade Federal de Pernambuco 2018
• Subjects: Engenharia de software; Linhas de produtos de software
• Online Access: https://repositorio.ufpe.br/handle/123456789/24883

Submitted by Pedro Barros ([e-mail]) 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.