Submitted by Kleber Silva (kleberbs@ufba.br) on 2017-05-31T19:53:55Z No. of bitstreams: 1 Ph.D. Thesis - Ivan Machado - Full Version-1.pdf: 3242625 bytes, checksum: 76299cf9d79afd85a7c46155029ae95e (MD5) / Approved for entry into archive by Vanessa Reis (vanessa.jamile@ufba.br) on 2017-06-06T15:19:55Z (GMT) No. of bitstreams: 1 Ph.D. Thesis - Ivan Machado - Full Version-1.pdf: 3242625 bytes, checksum: 76299cf9d79afd85a7c46155029ae95e (MD5) / Made available in DSpace on 2017-06-06T15:19:55Z (GMT). No. of bitstreams: 1 Ph.D. Thesis - Ivan Machado - Full Version-1.pdf: 3242625 bytes, checksum: 76299cf9d79afd85a7c46155029ae95e (MD5) / Software Product Line (SPL) engineering has emerged as an important strategy to cope with the increasing demand of large-scale product customization. Owing to its variability management capabilities, SPL has provided companies with an efficient and effective means of delivering a set of products with higher quality at a lower cost, when compared to traditional software engineering strategies. However, such a benefit does not come for free. SPL demands cost-effective quality assurance techniques that attempt to minimize the overall effort, while improving, or at least not hurting, fault detection rates. Software testing, the most widely used approach for improving software quality in practice, has been largely explored to address this particular topic. State of the art SPL testing techniques are mainly focused on handling variability testing from a high level perspective, namely through the analysis of feature models, rather than concerning issues from a source code perspective. However, we believe that improvements in the quality of variable assets entail addressing testing issues both from high and low-level perspectives. By carrying out a series of empirical studies, gathering evidence from both the literature and the analysis of defects reported in three open source software systems, we identified and analyzed commonly reported defects from Java-based variability implementation mechanisms. Based on such evidence, we designed a method for building fault models for variability testing, from two main perspectives: test assessment, which focuses on the evaluation of the effectiveness of existing test suites; and test design, which aims to aid the construction of test sets, by focusing on fault-prone elements. The task of modeling typical or important faults provides a means to coming up with certain test inpus that can expose faults in the program unit. Hence, we hypothesize that understanding the nature of typical or important faults prior to developing the test sets would enhance their capability to find a particular set of errors. We performed a controlled experiment to assess the test effectiveness of using fault models to provide SPL testing with support to design test inputs. We observed promising results that confirm the hypothesis that combining fault models in an SPL testing process performs significantly better on improving the quality of test inputs. / A Engenharia de Linhas de Produtos de Software (LPS) surgiu como uma importante estratégia para lidar com a crescente demanda de customização de produtos de software em larga escala. Por sua capacidade de gerenciar variabilidade de forma sistemática, o paradigma de LPS tem proporcionado às empresas métodos eficientes e eficazes para alcançar a entrega de produtos de software com maior qualidade, a um custo de produção reduzido, quando comparado a estratégias tradicionais de desenvolvimento de software. No entanto, a obtenção de tais benefícios não é trivial. O paradigma impõe a necessidade de técnicas de garantia de qualidade eficazes, com bom custo-benefício, que tentem minimizar o esforço global, ao tempo em que se alcance melhorias nas taxas de detecção de falhas. Assim, a disciplina de testes de software, abordagem comumente utilizada na busca por melhoria na qualidade dos produtos de software, tem sido largamente explorada no contexto de LPS. As mais relevantes técnicas de testes em LPS estão focadas principalmente no gerenciamento de testes de variabilidade sob uma perspectiva de alto nível, notadamente através da análise de modelos, em sobreposição aos aspectos de mais baixo nível, isto é, sob o ponto de vista do código fonte. Entretanto, acreditamos que melhorias na qualidade dos artefatos de software variáveis implica na investigação de aspectos da disciplina de testes, em ambas as perspectivas, quer seja alto nível quer seja baixo nível. Através da realização de uma série de estudos empíricos, evidências foram obtidas a partir da análise de textos publicados na literatura, e a partir da análise de defeitos reportados em três sistemas de software de código aberto. Neste último caso, identificamos e analisamos defeitos provenientes do uso de mecanismos de implementação de variabilidade em Java. Com base nas evidências, construímos uma abordagem para construir modelos de falhas que auxiliem o teste de variabilidade, sob duas perspectivas principais: avaliação de teste, que incide sobre a avaliação da eficácia dos casos de testes existentes; e o projeto de teste, que visa auxiliar a construção de casos de teste, concentrando-se em elementos propensos a falhas. A tarefa de modelagem de falhas típicas ou importantes fornece um meio para identificar certas entradas de teste que podem expor falhas na execução do programa. Desta forma, a nossa hipótese é que a compreensão da natureza das falhas típicas, ou importantes, como tarefa anterior ao desenvolvimento dos casos de teste, tende a aumentar a capacidade dos testes em encontrar um determinado conjunto de defeitos, quando executados. Para avaliar a eficácia da abordagem proposta nesta tese, planejamos e executamos um experimento controlado. Os resultados mostraram-se promissores, provendo indícios de que a ideia de se combinar modelos de falha em um processo de teste de LPS pode trazer ganhos significativos a atividade de teste, bem como melhorar a qualidade dos dados de entrada de testes.

Software Product Line Engineering (SPLE) is a development approach used for handling large amounts of variants in software systems. The idea behind this approach is to exploit reusability of various similar and diverse products. Reusable products have various commonalities and differences that can be exploited, and to do so, developers need to define those differences (i.e., variabilities) within them. Variabilities can occur at different abstraction levels, through whole product lifecycle and developer need to handle it through the whole process. To address this problem at the architectural and requirement level, we used pure::variants, a leading variant-management commercial tool, to model variability within requirements in the railway domain. With this tool, we explicitly define a process on how to design a variability model that could be used to model several aspects of requirement variability, which can be reused again in the future, for the requirement engineering. We propose an approach for engineers to automatically generate models from requirement documents and then with the use of pure::variants functions, create various aspects which are then further transformed into feature models. Finally, the results of this transformation made possible the identification between core and variant features presented in these requirements making it easy to define what parts of the software are project specific and what are common for all generated models. Our results indicate that variability modelling using the pure::variants tool is applicable for requirement variant handling in the railway domain.

CoordenaÃÃo de AperfeiÃoamento de Pessoal de NÃvel Superior / Uma Linha de Produto de Software SensÃvel ao Contexto (LPSSC) à uma linha de produto para o desenvolvimento de aplicaÃÃes sensÃveis ao contexto, que alteram dinamicamente o comportamento ou que proveem serviÃos com base em informaÃÃes de contexto. Nesse cenÃrio, a atividade de testes precisa lidar ao mesmo tempo com as peculiaridades das aplicaÃÃes finais, que sÃo sensÃveis ao contexto, e com o paradigma de desenvolvimento em linha de produto. Mediante a complexidade envolvida nos testes de uma LPSSC, à fundamental a existÃncia de mÃtodos ou ferramentas de suporte a essa atividade, especialmente com a intenÃÃo de criar testes a partir dos requisitos da linha. O objetivo dessa geraÃÃo precoce dos testes à permitir a identificaÃÃo e correÃÃo dos defeitos nos estÃgios iniciais de desenvolvimento. Dessa forma, esta dissertaÃÃo tem por objetivo propor um ambiente de geraÃÃo de cenÃrios de testes para uma LPSSC que utiliza especificaÃÃes textuais de casos de uso com informaÃÃes de contexto e que possibilita a reutilizaÃÃo dos testes. Este ambiente à constituÃdo pela proposta de um mÃtodo de geraÃÃo de cenÃrios de testes, de um template para especificaÃÃo textual de casos de uso de uma LPSSC e de uma ferramenta de apoio. O mÃtodo utiliza como base especificaÃÃes textuais de casos de uso com informaÃÃes sobre: funcionalidade, variabilidade da linha, e como o contexto afeta os produtos finais. O ambiente tambÃm contÃm o template para caso de uso que fornece suporte ao uso do mÃtodo e a ferramenta de apoio, que permite a modelagem de casos de uso segundo esse template e implementa o mÃtodo proposto. Com a intenÃÃo de verificar os benefÃcios do ambiente, proposto nesta dissertaÃÃo, quanto a geraÃÃo de cenÃrios de testes para uma LPSSC, conduziu-se uma avaliaÃÃo preliminar na forma de experimento controlado. Baseado nos resultados coletados nessa avaliaÃÃo percebeu-se que: o template favorece o entendimento de um caso de uso de uma LPSSC; o mÃtodo favorece a criaÃÃo de um conjunto de testes com uma maior cobertura para uma LPSSC, se comparado a criaÃÃo de testes de forma nÃo sistemÃtica; e a ferramenta representa um suporte necessÃrio. / A Context-Aware Software Product Line (CASPL) is a product line for developing context-aware applications, which dynamically change their behavior or provide services based on context information. With this kind of line, the productivity can be increased and the development costs of the context-aware application can be cut down. In this scenario, the testing activity needs to deal with the peculiarities of both context-aware applications and the product line development paradigm. Through the complexity involved in testing a CASPL is essential to have methods or tools for supporting this activity, especially with the goal of creating tests from requirements. The aim of this early testing generation is to identify and fix the defects in the early stages of development. Therefore, this work aims to propose an environment for generating test scenarios for a CASPL that takes into account the presence of context information and seeks to maximize the testing reuse. This environment consists of a testing scenario generation method, a template for textual use case specification and a support tool. The method uses as input textual use cases especifications with information about: funcionality, variability, and how the context afect the final products. The environment also has a use case template that supports the use of the method and a tool support, which allows the modeling of use cases according to this template and implements the proposed method. In order to verify the benefits of the environment as a way to testing generation for a Context-Aware Software Product Line, an assessment in the form of controlled experiment is conducted. Based on the collected results, it is observed that: the use of the template makes easy the understanding of a Context-Aware Software Product Line use case; the method favors the creation of a set of tests with higher coverage than a non-systematic testing generation; and the tool is the necessary support for the method

Made available in DSpace on 2014-06-12T15:51:39Z (GMT). No. of bitstreams: 2 arquivo1682_1.pdf: 1782765 bytes, checksum: f72b8949fcd20828665cc0a45ca4034d (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2008 / Dentro da comunidade de desenvolvimento de software, o processo de reutilizar artefatos ao invés de construí-los do zero normalmente conhecido como reuso de software tem se mostrado uma maneira efetiva de evitar os problemas associados ao estouro de orçamentos e cronogramas de projeto. Apesar do imenso potencial, a adoção de reuso em larga escala ainda não prevalece dentro das organizações. Entre os fatores que contribuem para isso, estão os obstáculos econômicos enfrentados pelas empresas, com uma clara preocupação sobre os custos para desenvolver software para e com reuso. Atualmente, as decisões relacionadas com reuso são tratadas sob um ponto de vista econômico, devido ao fato do desenvolvimento de software reutilizável ser considerado pelas organizações como um investimento. Além disso, a adoção de linhas de produto de software dentro desse contexto traz à tona alguns inibidores de reuso, como por exemplo, a aplicação dos modelos de custo para reuso de forma restrita, a falta de uma estratégia para a análise de investimentos, e o fato que poucos modelos de custo possuem uma abordagem baseada na utilização de cenários de reuso. Nesse contexto, esse trabalho apresenta um modelo integrado de custo para engenharia de linhas de produto, com o objetivo de auxiliar as organizações em seus processos de tomada de decisões na avaliação de investimentos em reuso. Os fundamentos para o modelo foram baseados em uma vasta pesquisa sobre modelos de custo para reuso e sua especialização para linhas de produto de software. O modelo apresenta a definição de funções de custo e benefícios, cenários de reuso e uma estratégia de investimento para linhas de produto. Também é apresentado um modelo de simulação baseado na técnica de Monte Carlo. Por último, um estudo de caso discute os resultados de dentro do contexto de um projeto real de desenvolvimento de software, onde o modelo foi aplicado

Made available in DSpace on 2014-06-12T15:51:50Z (GMT). No. of bitstreams: 1 license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2008 / Os mais almejados objetivos da engenharia de software são basicamente alta produtividade, com alta qualidade a um baixo custo e uma possível forma de atingi-los é estabelecer reuso de software o processo de criar sistemas de software a partir de sistemas existentes ao invés de criar do início. Neste contexto, uma abordagem que pode habilitar reuso na prática é Linha de Produto de Software (LPS) um conjunto de sistemas de software que compartilham um conjunto comum e gerenciado de funcionalidades que satisfazem uma necessidade específica de um domínio, e que são desenvolvidas a partir de um conjunto de artefatos reusáveis. Um domínio em particular onde a adoção de tal abordagem pode trazer benefícios é o domínio de jogos móveis principalmente porque os jogos precisam executar em diversos dispositivos e existe uma grande quantidade de jogos do mesmo tipo sendo desenvolvidos com funcionalidades em comum. Entretanto, as características do domínio de jogos móveis geralmente criam barreiras para os processos de LPS na prática, tais como, restrições de memória e de tamanho da aplicação e diferentes implementações de API feitas por diferentes fabricantes. Além disso, os atuais processos de LPS ainda carecem de detalhes em fases relacionadas à implementação de artefatos reusáveis, dificultando a administração apropriada das características mencionadas. Dessa forma, este trabalho objetiva definir uma abordagem prática para implementação de artefatos reusáveis em uma LPS para o domínio de jogos móveis com base nas boas práticas do estado da arte na área. Além disso, com a intenção de avaliar a abordagem, um estudo experimental foi executado com três jogos de plataforma para construir a LPS e um quarto jogo foi derivado dela

Made available in DSpace on 2014-06-12T15:58:03Z (GMT). No. of bitstreams: 2 arquivo3244_1.pdf: 2061206 bytes, checksum: d9bbab1debda0a2122b877cceb8484ed (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2010 / Conselho Nacional de Desenvolvimento Científico e Tecnológico / O reuso de software é um fator extremamente importante para empresas interessadas em aumentar sua produtividade, diminuir os custos e o tempo durante o desenvolvimento de sistemas e melhorar a qualidade de seus produtos e serviços. Nesse contexto, Linhas de Produto de Software (LPS) e Arquitetura Orientada a Serviços (SOA) são duas estratégias que estão atualmente recebendo uma grande atenção, tanto na área acadêmica quanto na indústria de software. Os conceitos de linhas de produto e arquitetura orientada a serviços compartilham alguns objetivos e características que podem ser usados em conjunto para aumentar as taxas de reuso de software. No entanto, para o resultado dessa junção ser otimizado, é necessário utilizar um processo de desenvolvimento bem definido. Caso contrário, a equipe de desenvolvimento poderá produzir software de maneira não sistemática, aumentando as chances de falha, o tempo e o custo de desenvolvimento. Com essa visão, esse trabalho apresenta uma abordagem para o projeto de arquiteturas para linhas de produto orientada a serviços, constituída de um conjunto de atividades e sub atividades com entradas e saídas especificadas, sendo cada uma delas realizada por um conjunto predefinido de papéis com responsabilidades definidas. Essa abordagem visa ajudar arquitetos de software a projetar arquitetura orientada a serviços para domínios específicos. Para garantir a qualidade da abordagem desenvolvida, uma pesquisa extensiva foi realizada para analisar o atual estado da arte de processos para o desenvolvimento orientado a serviços. Foram então considerados os pontos fracos e fortes dos processos estudados com o intuito de identificar e preencher as lacunas neles existentes. Por fim, essa abordagem foi validada e refinada por meio de um estudo acadêmico experimental preliminar

Software Product Lines (SPL) is a relatively new way of working in software development. A SPL is an enforced architecture and a collection of components common for more than one product within a domain. Development using SPL utilizes tools and techniques for creating software systems from a common set of core assets in order to satisfy a certain market. In this study we investigate how to proceed when transitioning to a SPL development approach by evaluating proposed and used adoption approaches, methods and frameworks. We performed a systematic literature review using three main sources; Compendex/Inspec, CiteSeerX and Google Scholar. The results are analyzed using a qualitative analysis technique called Recursive Abstraction where the results are iteratively summarized to extract the essence of the data. A manageable collection of frameworks, methods and approaches are summarized as a starting point for a reader who wants to dig deeper into the subject. A set of guidelines is suggested for companies who are considering a transition to SPL development. We also investigate the link between SPL and organization maturity, with a focus on the benefits of combining a SPL initiative with a CMMI initiative. We conclude that the transition process should not be taken lightly; in most cases it should be made in incremental steps. There is a fairly standard approach to adopt SPL and there are a few frameworks that are commonly accepted. However, we also conclude that most research areas of SPL development lacks in validation. Concerning the link between SPL and CMMI we identify some PA's that are more important when considering SPL development and a few others that may be harder to execute. We conclude that SPL benefits from process maturity and discipline as SPL development is process controlled and a lack in process discipline may cause corrosion of the SPL. A CMMI maturity level of Defined processes should be considered a prerequisite for a complete SPL practice. We could not find any indication that the organization maturity would benefit from SPL practices alone. Neither could we identify any drawbacks of having both an CMMI initiative and SPL transition initiative within the same organization.

The notion of maximizing software reuse among the family of products has gained considerable attention in the last decade. Lots of research has been done on designing and managing the commonalities and variabilities between the products. However, very few metrics have been developed to assist architects in designing product line architectures. The structure of the product line holds immense importance towards increasing the life span of the product line. Since many of the product line architecture design methodologies follow a component based approach, it seems logical to attempt to adapt the component based metrics to the product line domain. In this thesis, we attempt to derive metrics that quantify the structural quality of product line architecture. / +92-42-5727639

This is a Master Thesis at the Computer Science Program at Växjö University. It has been made at BSR in Växjö where the development of a diagnostic tool has been in the running since the beginning of 2008. Previously there was a base developed within the company which I was to use for developing the two layers that I was responsible for – ProtocolLayer and PresentationLayer. In the end it should lead to a XML-based diagnostic tool. The technologies used have been .NET with its language C# and XML. The future purpose for this tool is for it to be used within the company to receive important information about the cars when developing other BSR products. This thesis has focused on developing the tool to be working with the car manufacturer VOLVO and its protocols. The idea is that the diagnostic tool in the future could be extended to be working with all possible car manufacturers’ protocols and to enlighten the extensibility the project has been done using the product-line approach.

Context: A common way to represent product lines is with variability modeling. Yet, there are different ways to extract and organize relevant characteristics of variability. Comprehensibility of these models and the ease of creating models are important for the efficiency of any variability management approach. Objective: The goal of this paper is to investigate the comprehensibility of two common styles to organize variability into models - hierarchical and constrained - where the dependencies between choices are specified either through the hierarchy of the model or as cross-cutting constraints, respectively. Method: We conducted a controlled experiment with a sample of 90 participants who were students with prior training in modeling. Each participant was provided with two variability models specified in Common Variability Language (CVL) and was asked to answer questions requiring interpretation of provided models. The models included 9 to 20 nodes and 8 to 19 edges and used the main variability elements. After answering the questions, the participants were asked to create a model based on a textual description. Results: The results indicate that the hierarchical modeling style was easier to comprehend from a subjective point of view, but there was also a significant interaction effect with the degree of dependency in the models, that influenced objective comprehension. With respect to model creation, we found that the use of a constrained modeling style resulted in higher correctness of variability models. Conclusions: Prior exposure to modeling style and the degree of dependency among elements in the model determine what modeling style a participant chose when creating the model from natural language descriptions. Participants tended to choose a hierarchical style for modeling situations with high dependency and a constrained style for situations with low dependency. Furthermore, the degree of dependency also influences the comprehension of the variability model.