Made available in DSpace on 2014-06-12T15:58:08Z (GMT). No. of bitstreams: 2 arquivo3259_1.pdf: 5762420 bytes, checksum: 0af73887e3af768529c1569155447ba5 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / FUNDAÇÃO DE APOIO AO DESENVOLVIMENTO DA UFPE / Linhas de Produtos de Software (LPS) são definidas como conjuntos de sistemas de software que atendem a um mercado especifico, que compartilham caracteristicas em comum, porem sendo suficientemente distintos entre si, e que são desenvolvidos a partir de um conjunto de artefatos reusaveis. Entre os beneficios possiveis com a implantação de LPS podemos citar o reuso em larga escala e o aumento de produtividade. Um fator-chave no desenvolvimento de uma LPS e o mecanismo utilizado para a estruturação fonte. Uma das tecnicas mais comumente utilizadas para a estruturação de variações de código e a compilação condicional, tambem chamada de pre-processamento. Apesar de ser amplamente utilizada, o uso de compilação condicional incorre em problemas de legibilidade, modularidade, manutenibilidade e qualidade. Programação Orientada a Aspectos (POA) e uma alternativa a compilação condicional para a estruturação de variações de codigo em LPS, podendo apresentar melhor legibilidade, modularidade, manutenibilidade, qualidade, entre outros fatores, do que a compilação condicional. Entretanto, o uso de AspectJ, implementação mais popular de POA sobre a linguagem Java, como mecanismo de estruturação de variações gera um overhead (aumento) sobre o tamanho final do codigo compilado. No contexto de LPS de sistemas para plataformas em dispositivos moveis, em plataformas como Java ME, que possuem restrições de memoria, esse overhead pode tornar inviavel o uso do produto final. Neste trabalho, analisamos o impacto do uso de AspectJ como mecanismo de estruturação de variações sobre o tamanho do codigo compilado e investigamos os motivos por tras deste aumento. Para tal, utilizamos o BestLap e o Juggling, duas LPS de jogos para dispositivos Java ME que possuem uma versão puramente pre-processada e uma versão hibrida, que utiliza pre-processamento e AspectJ. Utilizamos o BestLap na analise de tamanho para quanticar o overhead com dois compiladores AspectJ, o ajc e o abc. Em seguida, analisamos o codigo compilado de um subconjunto das construções As pectJ, a fim de identificar quais construções geram overhead no tamanho do codigo compilado e os motivos por tras deste overhead. Esse subconjunto consistiu de todas as construções AspectJ utilizadas na versão híbrida do BestLap e do Juggling, o ultimo utilizado apenas para a elicitação das construções analisadas. Com base nessa investigação, desenvolvemos quatro otimizações para o compilador abc que modificam o codigo compilado de certas construções visando a eliminar o overhead. Apresentamos detalhes da implementação e discutimos as pre-condições e a corretude das otimizações desenvolvidas. Em seguida, apresentamos o resultado da aplicação destas otimizações em duas LPS e discutimos como implementações diferentes, porem equivalentes, da mesma variação em AspectJ podem inviabilizar a aplicação das otimizações Por fim, para garantir que as modificações realizadas pelas otimizações não prejudiquem o desempenho, apresentamos o resultado de testes de desempenho realizados em programas AspectJ usados em benchmarks apos a aplicação das nossas otimizações

Made available in DSpace on 2014-06-12T15:58:11Z (GMT). No. of bitstreams: 2 arquivo3303_1.pdf: 1930482 bytes, checksum: 5203b90b2f2248bb0739907c03b9a717 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2010 / Reúso de software é uma forma viável de obter ganhos de produtividade e melhoria no timeto- market tão desejados pelas empresas. O reúso não sistemático (Ad hoc) pode ser prejudicial, uma vez que a reutilização de artefatos de baixa qualidade pode diminuir a qualidade dos produtos finais. O reúso sistemático através da adoção de Linhas de Produto de Software (LPS) é uma boa alternativa para alcançar metas de qualidade e de redução de custos. Essa abordagem se tornou uma solução efetiva para gerar vantagem competitiva para as empresas. Arquiteturas de linhas de produto devem se beneficiar das comunalidades entre os produtos e possibilitar a variabilidade entre eles. Ao mesmo tempo, como uma arquitetura de software, precisa atender requisitos de atributos de qualidade. O desafio de atender atributos de qualidade em sistemas únicos (single systems) torna-se ainda mais complicada no contexto de linhas de produto porque a variabilidade pode ocorrer também nos atributos de qualidade. A variabilidade em atributos de qualidade é uma questão complexa. Entretanto, ela tem sido negligenciada ou ignorada pela maioria dos pesquisadores, uma vez que as atenções têm se mantido no alcance da variabilidade funcional. O foco deste trabalho é definir um processo para o design de arquiteturas de linhas de produto de software que possa lidar de forma eficaz com variabilidade em atributos de qualidade. O processo aprimora o RiPLE-Design com atividades e guias para o design com variabilidade de atributos de qualidade. Por fim, um estudo experimental é apresentado com o intuito de caracterizar e avaliar as melhorias propostas ao processo

Made available in DSpace on 2014-06-12T16:00:54Z (GMT). No. of bitstreams: 2 arquivo7075_1.pdf: 5003439 bytes, checksum: 070d65264679c7bfd03fc912be7cc61f (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / A indústria de software tem sido cada vez mais desafiada a melhorar suas praticas de engenharia com o objetivo de oferecer produtos de forma mais rápida e confiável. Assim, as práticas de desenvolvimento de software sofreram significativas mudanças nos últimos anos, uma vez que novas e acessíveis estratégias tem sido aplicadas de forma a alcançar tal desafio. Neste contexto, Engenharia de Linhas de Produto de Software surgiu como uma estratégia de engenharia de software destinada a fornecer à indústria oportunidades para alcançar os objetivos de negócio acima mencionados. No entanto, para garantir o retorno do investimento com uma abordagem de Linhas de Produto de Software, um processo de derivação de produtos bem definido é muito importante. Sem esse processo, os produtos podem ser instanciados de maneira não sistemática, aumentando o tempo e o custo de produção. Por outro lado, mesmo com esta relevância, quando comparado com a grande quantidade de pesquisas em desenvolvimento sobre linhas de produtos, relativamente poucos trabalhos tem sido dedicados ao processo de Derivação de Produtos. Alêm disso, ainda existem poucos relatórios disponíveis sobre como as organizações de desenvolvimento de software derivam seus produtos a partir de uma linha de produtos, e, em geral, os existentes têm sido realizados como estudos informais, sem rigor científico suficiente, tornando difícil a sua repetição e validação. Assim, esta dissertação tem como objetivo obter uma melhor compreensão sobre como derivação do produto é realizada e quais práticas são utilizadas na indústria. Reunimos descobertas através de dois estudos de caso realizados na indústria. Alem disso, as evidências obtidas a partir dos estudos de caso, foram comparados entre os casos através da análise Cross-case, com o objetivo de identificar padrões entre eles. A definição do estudo e relatório foram estruturados com base nas diretrizes consolidadas para estudos empíricos de acordo com orientações bem definidas, o que permite a replicação dos estudos e extensão

Made available in DSpace on 2014-06-12T16:01:25Z (GMT). No. of bitstreams: 2 arquivo8976_1.pdf: 2350079 bytes, checksum: 1eef40b33c036ecc8b5b613b08bff0a7 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / Engenharia de Linhas de Produto de Software (ELPS) emergiu rapidamente como uma importante abordagem de desenvolvimento de software durantes os últimos anos. ELPS foca-se na identificação e gerenciamento dos pontos em comum (commonalities) e dos pontos de variação (variabilities) de um conjunto de produtos de software, de forma que artefatos (core assets) possam ser desenvolvidos e (re)usados para construir diferentes produtos com custo reduzido. Além disso, melhoria de produtividade, aumento de qualidade e redução do tempo de entrega dos produtos são alguns dos benefícios proporcionados pela abordagem. Neste contexto, o processo de escopo em linhas de produto de software é responsável pela definição da viabilidade a longo prazo da linha de produtos. Seu principal objetivo é identificar e delimitar produtos, funcionalidades, subdomínios e artefatos (componentes, documentos, etc.) existentes da linha de produtos, onde o investimento em reuso trará benefícios econômicos para a empresa. Normalmente, engenheiros de linha de produtos definem o escopo com informações extraídas da documentação de produtos existentes e baseados no conhecimento de especialistas de domínio. Esta é uma tarefa que demanda muito esforço, pois muito tempo é investido na realização de workshops e entrevistas com os especialistas de domínio. Além disso, frequentemente, os especialistas de domínio não tem tempo disponível para compartilhar o conhecimento deles e a documentação dos produtos existentes é inexistente ou está desatualizada. Assim, a fim de reduzir custos e tempo para a realização do processo de escopo, esta dissertação propõe uma abordagem para auxiliar o processo de escopo baseada no código fonte dos produtos já existentes na empresa. Além disso, são apresentados os requisitos, projeto e implementação de uma ferramenta com o objetivo de guiar os analistas de escopo na identificação de similaridades e variações no código fonte dos sistemas legados. Finalmente, esta dissertação também descreve um estudo empírico que foi utilizado para a elicitação de requisitos e um experimento que foi conduzido para avaliar a viabilidade da ferramenta proposta neste trabalho

Orientador: Cecilia Mary Fischer Rubira / Dissertação (mestrado) - Universidade Estadual de Campinas, Instituto de Computação / Made available in DSpace on 2018-08-15T07:02:41Z (GMT). No. of bitstreams: 1 Assis_WendelMaltade_M.pdf: 3475428 bytes, checksum: a93eaa26b089299962c102e6c3a037c5 (MD5) Previous issue date: 2009 / Resumo: O uso de Linhas de Produto de Software é uma prática comum entre as empresas de software, tendo como objetivo promover o desenvolvimento de um conjunto de produtos de software relacionados através da reutilização de um núcleo comum de ativos de software. Dentre estas empresas, podemos mencionar a Motorola, cujo ambiente de desenvolvimento em que múltiplas linhas de produto são mantidas em paralelo serviu de motivação para este trabalho. Na prática, a complexidade de alguns tipos de negócios apoiados por linhas de produto implica em mudanças na forma como a adoção da abordagem é sugerida pela literatura. Em particular na Motorola, as linhas de produto são baseadas em componentes e a arquitetura da linha de produto possui diversos pontos de variação, onde variantes de componentes representando diversas alternativas de projeto podem ser escolhidas. Além disso, várias linhas de produto são mantidas em paralelo e os componentes e suas variantes podem ser compartilhados entre elas. Neste contexto, a evolução de componentes é uma tarefa complexa, pois a inclusão de novas características nas variantes dos componentes pode impactar não somente a arquitetura e os ativos de uma única linha de produto, mas também das diversas linhas que as utilizam. A principal contribuição deste trabalho é a documentação de uma família de padrões de evolução de componentes compartilhados por múltiplas linhas de produto de software. Além desta família de padrões, também é apresentado um processo para auxiliar na análise do padrão de evolução a ser adotado para implementar uma determinada requisição de mudança / Abstract: The Software Product Line approach is becoming widely used by software companies, whose goal is to promote the development of a set of related software products through the reuse of a common core of software assets. Among these companies, we can mention Motorola, whose development environment where multiple software product lines are maintained in parallel served as the motivation for this work. In practice, the complexity of some types of businesses supported by product lines involves changes in how the adoption of the approach is suggested by the literature. At Motorola, the product lines are based on components and the product line architecture has many variation points, where variants of components representing various design alternatives can be chosen. In addition, several product lines are maintained in parallel and the components and their variants can be shared among them. In this context, the evolution of components is a complex task, because the inclusion of new features in variants of the components can impact not only the architecture and assets in a single product line but also on many products lines that are using them. The main contribution of this work is the documentation of a family of component evolution patterns that are shared between multiple software product lines. Besides that, a process to assist in analyzing the evolution pattern to be taken to implement a specific change request is presented / Mestrado / Engenharia de Software / Mestre em Ciência da Computação

Changes to a software system are the result of changing requirements or defects during the development. Each change consumes resources for the analysis, decision making, implementation, and verification. Hence, having control over changes is crucial for software development projects to meet schedules, keep quality standards and budgets. Reuse of functionality helps to create new products based on already existing building blocks. Integrating mature components enables to create reliable systems. Software product lines provide means to develop several similar systems based on reuse. Often new products also need to be released frequently to fulfil the customer needs. Shortened lead time for the development then strengthens the importance of reuse. At the same time, limited budgets and competition on the market requires projects to utilize resources efficiently. Developing several releases in parallel enables an even distribution of tasks among different roles in a development organization. Both developing software based on a product line approach and parallel releases put requirements on how changes need to be controlled. In this thesis, software engineering literature is reviewed regarding the knowledge areas of software release management, software product lines and software configuration management. Beyond the most considerable research results also related case studies are presented to show how industry practices counter existing problems. The major part of the thesis is a case study conducted at Sony Ericsson Mobile Communications AB. The outcome of the thesis is an identification of challenges of controlling changes regarding parallel development and using software product lines based on available research results and industry case studies. It further provides a case of a software development organization which faces a high market-pace, uses a software product line approach, and develops several software releases in parallel on different sites around the world.

This thesis presents research aimed at investigating different activities involved in software product lines testing process and possible improvements towards achieving developing high quality software product lines at reduced cost and time. The research was performed using systematic review procedures of Kitchenham. The reviews carried out in this research covers several areas relating to software product lines testing. The reasons for performing a systematic review in this research are to; summarize the existing evidence covering testing in software product line context, to identify gaps in current research and to suggest areas for further research. The contribution of this thesis is research aimed at revealing the different activities, issues and challenges in software product lines testing. The research into the different activities in software product lines lead to the proposed SPLIT Model for software product lines testing. The model helps to clarify the steps and activities involved in the software product line testing process. It provides and easy to follow map for testers and managers in software product line development organizations. The results were mainly on how testing in software product lines can be improved upon, towards achieving software product line goals. The basic contribution is the proposed model for product line testing, investigation into, and possible improvement in, issues related to software product line testing activities. / The main purpose of the research as presented in this thesis is to present a clear picture of testing in the context of software product lines, which is quite different from testing in single product. The focus of this thesis is specifically the different steps and activities involved in software product lines testing and possible improvements in software product lines testing activities and issues towards achieving the goals of developing high quality software product lines at reduced cost and time. But, for software product lines to achieve its goals, there should be a comprehensive set of testing activities in software product lines development. The development activities from performing analyses and creating designs to integrating programs in software product line context, component testing and tools support for software product lines testing should be taken into consideration. / 0046762913149 eddy_odia2002@yahoo.co.uk

The Software Product Line (SPL) paradigm has proven to be an effective way to achieve large scale reuse in different domains. It takes advantage of common aspects between different products, while also considering product specific features. The architecture plays an important role in SPL engineering, by providing means to better understand and maintain the product-derivation environment. However, it is difficult to evolve such architecture because it is not always clear where and how to refactor. The contribution of this thesis is twofold. First, the current state of the art of software Product Line Architectures (PLAs) is investigated through a systematic mapping study. It provides an overview of the field through the analysis, and categorization of evidence. The study identifies gaps, trends and provides future directions for research. Furthermore, this thesis addresses the phenomenon of architectural bad smells in the context of SPLs. A case study provides an investigation on the implications of such structural properties in a variability-based environment. Prior to the search for smells, the architecture of a sample SPL in the text editor domain is recovered from the source code. / Software Product Line (SPL) paradigmet har bevisat sig vara ett effektivt sätt att uppnå storskalig återanvändning i olika domäner. Den drar nytta av gemensamma aspekter mellan olika produkter, och överväger samtidigt även produktspecifika egenskaper. Arkitekturen spelar en viktig roll i SPL tekniken, genom att tillhandahålla medel för att bättre förstå och underhålla "product-derivation" miljön. Det är dock svårt att vidareutveckla sådan arkitektur för att det inte alltid är tydligt var och hur den kan omstruktureras. Bidraget från denna avhandling är tvåfaldigt. För det första, den aktuella situationen för "software Product Line Architectures" (PLAs) undersöks genom en systematisk kartläggning. Den ger en översikt av fältet genom analys, och kategorisering av bevis. Studien identifierar luckor, trender och ger framtida riktlinjer för forskning. Vidare adresserar denna avhandling fenomenet arkitektoniska "bad smells" inom kontexten för SPLs. En fallstudie ger en utredning av implikationer av sådana strukturella egenskaper i en variabilitet-baserad miljö. Innan sökningen av "smells", är arkitekturen från en sampel SPL i textredigerar domänen återvunnen från källkoden.

Une particularité importante du logiciel est sa capacité à être adapté et configuré selon différents scénarios. Récemment, la variabilité du logiciel a été étudiée comme un concept de première classe dans différents domaines allant des lignes de produits logiciels aux systèmes ubiquitaires. La variabilité est la capacité d'un produit logiciel à varier en fonction de différentes circonstances. Les systèmes à forte variabilité mettent en jeu des produits logiciels où la gestion de la variabilité est une activité d'ingénierie prédominante. Les diverses parties de ces systèmes sont couramment modélisées en utilisant des formes différentes de ''modèle de variabilité'', qui est un formalisme de modélisation couramment utilisé. Les modèles de caractéristiques (feature models) ont été introduits par Kang et al. en 1990 et sont une représentation compacte d'un ensemble de configurations pour un système à forte variabilité. Le grand nombre de configurations d'un modèle de caractéristiques ne permet pas une analyse manuelle. De fait, les mécanismes assistés par ordinateur sont apparus comme une solution pour extraire des informations utiles à partir de modèles de caractéristiques. Ce processus d'extraction d'information à partir de modèles de caractéristiques est appelé dans la littérature scientifique ''analyse automatisée de modèles de caractéristiques'' et a été l'un des principaux domaines de recherche ces dernières années. Plus de trente opérations d'analyse ont été proposées durant cette période. Dans cette thèse, nous avons identifié différentes questions ouvertes dans le domaine de l'analyse automatisée et nous avons considéré plusieurs axes de recherche. Poussés par des scénarios du monde réel (e.g., la téléphonie mobile ou la vidéo protection), nous avons contribué à appliquer, adapter ou étendre des opérations d'analyse automatisée pour l’évolution, le test et la configuration de systèmes à forte variabilité. / The large number of configurations that a feature model can encode makes the manual analysis of feature models an error prone and costly task. Then, computer-aided mechanisms appeared as a solution to extract useful information from feature models. This process of extracting information from feature models is known as ''Automated Analysis of Feature models'' that has been one of the main areas of research in the last years where more than thirty analysis operations have been proposed. In this dissertation we looked for different tendencies in the automated analysis field and found several research opportunities. Driven by real-world scenarios such as smart phone or videosurveillance domains, we contributed applying, adapting or extending automated analysis operations in variability intensive systems evolution, testing and configuration.

La complexité croissante des systèmes logiciels modernes a motivé la nécessité d'élever le niveau d'abstraction dans leur conception et mis en œuvre. L'usage des langages dédiés a émergé pour répondre à cette nécessité. Un langage dédié permet de spécifier un système logiciel à travers des concepts relatifs au domaine d'application. Cette approche a plusieurs avantages tels que la diminution des détails techniques auxquels les développeurs doivent faire face, la séparation des préoccupations et la participation des experts du domaine dans le processus de développement. Malgré les avantages fournis par l'usage des langages dédiés, cette approche présente des inconvénients qui remettent en question sa pertinence dans des projets réels de développement logiciel. L'un de ces inconvénients est le coût de la construction des langages dédiés. La définition et l'outillage de ces langages est une tâche complexe qui prend du temps et qui requiert des compétences techniques spécialisées. Le processus de développement des langages dédiés devient encore plus complexe lorsque nous prenons en compte le fait que ces langages peuvent avoir plusieurs dialectes. Dans ce contexte, un dialecte est une variante d'un langage qui introduit des différences au niveau de la syntaxe et/ou de la sémantique. Afin de réduire le coût du processus de développement des langages dédiés, les concepteurs des langages doivent réutiliser autant de définitions que possible pendant la construction des variantes. Le but est d'exploiter les définitions et l'outillage définis précédemment pour dunaire au maximum, la mis en ouvre des zéro dans la construction de langages. Afin de répondre à la question de recherche précédemment énoncée, la communauté de recherche autour de l'ingénierie des langages a proposé l'usage des lignes de produits. En conséquence, la notion de lignes de langages a récemment émergé. Une ligne de langages est une ligne de produis où les produits sont des langages. Le principal but dans les lignes de langages est la définition indépendante de morceaux de langage. Ces morceaux peuvent être combinées de manières différentes pour configurer des langages adaptés aux situations spécifiques. D'une manière similaire aux lignes de produits, les lignes de langages peuvent être construites à partir de deux approches différentes: top-down et bottom-up . Dans l'approche top-down, les lignes de langages sont conçues et mis en œuvre au travers d'un processus d'analyse du domaine où les connaissances du domaine sont utilisées pour définir un ensemble de modules de langage qui réalisent les caractéristiques de la ligne de langages. En outre, les connaissances du domaine sont aussi utilisées pour représenter la variabilité de la ligne de langages à travers des modèles bien structurés qui, en plus, servent à configurer des langages particuliers. Dans l'approche bottom-up, les lignes des langages sont construites à partir d'un ensemble de variantes des langages existant au travers de techniques d'ingénierie inverse. À partir des approches précédemment énoncées, nous proposons deux contributions : (1) Des facilités pour supporter l'approche top-down. Nous proposons une approche de modularisation des langages qui permet la décomposition des langages dédiés comme modules de langages interdépendants. En plus, nous introduisons une stratégie de modélisation pour représenter la variabilité dans une ligne de langages. (2) Techniques d'ingénierie inverse pour supporter l'approche bottom-up. Comme deuxième contribution, nous proposons une technique d'ingénierie inverse pour construire, de manière automatique, une ligne de langages à partir d'un ensemble de variantes de langages existantes. Nos contributions sont validées à travers des cas d'étude industriels. / The use of domain-specific languages (DSLs) has become a successful technique in the development of complex systems because it furnishes benefits such as abstraction, separation of concerns, and improvement of productivity. Nowadays, we can find a large variety of DSLs providing support in various domains. However, the construction of these languages is an expensive task. Language designers are intended to invest an important amount of time and effort in the definition of formal specifications and tooling for the DSLs that tackle the requirements of their companies. The construction of DSLs becomes even more challenging in multi-domain companies that provide several products. In this context, DSLs should be often adapted to diverse application scenarios, so language development projects address the construction of several variants of the same DSL. At this point, language designers face the challenge of building all the required variants by reusing, as much as possible, the commonalities existing among them. The objective is to leverage previous engineering efforts to minimize implementation from scratch. As an alternative to deal with such a challenge, recent research in software language engineering has proposed the use of product line engineering techniques to facilitate the construction of DSL variants. This led the notion of language product lines i.e., software product lines where the products are languages. Similarly to software product lines, language product lines can be built through two different approaches: top-down and bottom-up. In the top-down approach, a language product line is designed and implemented through a domain analysis process. In the bottom-up approach, the language product line is built up from a set of existing DSL variants through reverse-engineering techniques. In this thesis, we provide support for the construction of language product lines according to the two approaches mentioned before. On one hand, we propose facilities in terms of language modularization and variability management to support the top-down approach. Those facilities are accompanied with methodological insights intended to guide the domain analysis process. On the other hand, we introduce a reverse-engineering technique to support the bottom-up approach. This technique includes a mechanism to automatically recover a language modular design for the language product line as we as a strategy to synthesize a variability model that can be later used to configure concrete DSL variants. The ideas presented in this thesis are implemented in a well-engineered language workbench. This implementation facilitates the validation of our contributions in three case studies. The first case study is dedicated to validate our languages modularization approach that, as we will explain later in this document, is the backbone of any approach supporting language product lines. The second and third case studies are intended to validate our contributions on top-down and bottom-up language product lines respectively.