[pt] Este trabalho apresenta uma ferramenta baseada em modelos para derivação de produtos de LPSs, denominada GenArch. O objetivo principal da ferramenta é permitir que a comunidade de desenvolvimento de software tradicional, utilize conceitos e fundamentos de abordagens de LPSs na produção de seus sistemas ou partes de seus sistemas sem a necessidade do entendimento de modelos e conceitos complexos. A abordagem implementada pela ferramenta foi elaborada com base em fundamentos do desenvolvimento dirigido por modelos. Centrada na definição de três modelos (características, implementação e configuração), a ferramenta permite a derivação automática de produtos ou frameworks existentes. O trabalho também define um conjunto específico de anotações Java que possibilitam a geração automática dos modelos de derivação a partir dos elementos de implementação da arquitetura de uma LPS. A plataforma Eclipse e as tecnologia EMF e openArchitectureWare foram utilizadas como base para a implementação da ferramenta. Uma extensão da ferramenta que atende especificamente aos modelos de componente Spring e OSGi, também é proposta nessa dissertação. Tal extensão permite a instanciação automática da LPS e aplicações através de diferentes tipos de customizações, variando da configuração fina de propriedades de componentes até a seleção automática de quais componentes irão compor o produto final. Como parte de validação da abordagem, a ferramenta foi utilizada na derivação automática de três diferentes estudos de caso: (i) o framework JUnit; (ii) uma LPS de jogos J2ME; e (iii) uma aplicação web baseada em serviços. Diversas lições aprendidas e resultados do uso da ferramenta nestes três diferentes cenários são também apresentadas. / [en] This work presents a model-based tool for product derivation, called GenArch, which aims to enable the mainstream software developer community to use the concepts and foundations of the SPL approach, without the need to understand complex concepts or models. The tool approach is build on top of model-driven development techniques. It is centered on the definition of three models (feature, implementation and configuration models), which enable the automatic instantiation of software product lines (SPLs) or frameworks. A set of specific Java annotations are also defined to allow generating automatically many of the models, based on existing implementations elements of SPL architectures. The Eclipse platform, and EMF and openArchitectureWare technologies are used as the base for the implementation of the tool. The dissertation also presents a GenArch extension that addresses the new abstractions provided by the Spring and OSGi component models. Different kinds of customizations are provided by this extension varying from fine-grained configuration of component properties to the automatic selection of components that will compose the final product. As part of the approach validation, the tool was used in the derivation of three case studies: (i) JUnit framework; (ii) a J2ME games SPL; (iii) a service oriented Web application. Several lessons learned and discussions resulting from the use of the tool also are described.

A abordagem de linha de produtos de software oferece benefícios ao desenvolvimento de software como economia, qualidade e desenvolvimento rápido, pois se baseia em reuso de arquitetura de software mais planejado e direcionado a um domínio específico. Neste contexto, o gerenciamento da variabilidade é uma questão chave e desafiadora, já que esta atividade auxilia a identificação, projeto e implementação dos novos produtos derivados da linha de produtos de software. O objetivo deste trabalho é definir um processo de gerenciamento de variabilidade de linha de produtos de software. Este processo, denominado GVLPS, identifica a variabilidade, extraindo as variantes a partir de diagramas de casos de uso e modelando-as através de features, especifica a variabilidade identificada e utiliza como suporte, na criação de variantes, um mecanismo de variabilidade baseado em modelos de objetos adaptáveis e em reflexão. A aplicação do processo é realizada através de um estudo de caso sobre o software de um veículo espacial hipotético, o Lançador de Satélites Brasileiro (LSB). / The Software Product Line approach offers benefits such as savings, large-scale productivity and increased product quality to the software development because it is based on software architecture reuse which is more planned and aimed to a specific domain. The management of variability is a key and challenging issue, since this activity helps identifying, designing and implementing new products derived from software products line. This work defines a process for the variability management of software product line, called GVLPS. After modeling the variability, extracting the variants from use case diagrams and features, the next step is to specify the variability that was identified. Finally, the proposed process uses a variability mechanism based on adaptive object model and reflection as support in the creation of variants. The proposed process uses as case study the software system of a hypothetic space vehicle, the Brazilian Satellites Launcher (LSB).

Linhas de produtos de software (LPS) são coleções de sistemas que compartilham características comuns, desenvolvidas de forma sistemática a partir de um conjunto comum de ativos centrais. Dentre as técnicas propostas por vários autores para o desenvolvimento de LPS, dois padrões podem ser observados: o processo de desenvolvimento geralmente é sequencial e o foco do projeto (design) costuma estar em interesses técnicos, como alocação de componentes e separação em subsistemas, e não em um modelo de domínio. Embora essas práticas sejam reportadas como bem-sucedidas, um outro paradigma de desenvolvimento, baseado em métodos ágeis e em um conjunto de princípios de projeto conhecido como domain-driven design, é apresentado neste trabalho e pode produzir resultados mais satisfatórios, comparados aos métodos tradicionais. Essa hipótese é sustentada por comparações entre padrões de modelagem e por um estudo de caso feito neste trabalho / Software product lines (SPL) are collections of systems that have common features. Those systems are systematically developed from a common set of core assets. Two patterns outstand among the various techniques proposed by several authors for developing software product lines: the development process is generally sequential and the primary design concerns deal with technical issues, such as component allocation and system partitioning (into subsystems). The importance of a domain model is often neglected. Although such practices have been reported as successful, this work proposes another paradigm, which can yield more satisfactory results. This paradigm is based on agile methods and a set of design principles known as domain-driven design. This hypothesis is supported by comparing different modeling patterns and by developing a case study

A abordagem de linha de produtos de software oferece benefícios ao desenvolvimento de software como economia, qualidade e desenvolvimento rápido, pois se baseia em reuso de arquitetura de software mais planejado e direcionado a um domínio específico. Neste contexto, o gerenciamento da variabilidade é uma questão chave e desafiadora, já que esta atividade auxilia a identificação, projeto e implementação dos novos produtos derivados da linha de produtos de software. O objetivo deste trabalho é definir um processo de gerenciamento de variabilidade de linha de produtos de software. Este processo, denominado GVLPS, identifica a variabilidade, extraindo as variantes a partir de diagramas de casos de uso e modelando-as através de features, especifica a variabilidade identificada e utiliza como suporte, na criação de variantes, um mecanismo de variabilidade baseado em modelos de objetos adaptáveis e em reflexão. A aplicação do processo é realizada através de um estudo de caso sobre o software de um veículo espacial hipotético, o Lançador de Satélites Brasileiro (LSB). / The Software Product Line approach offers benefits such as savings, large-scale productivity and increased product quality to the software development because it is based on software architecture reuse which is more planned and aimed to a specific domain. The management of variability is a key and challenging issue, since this activity helps identifying, designing and implementing new products derived from software products line. This work defines a process for the variability management of software product line, called GVLPS. After modeling the variability, extracting the variants from use case diagrams and features, the next step is to specify the variability that was identified. Finally, the proposed process uses a variability mechanism based on adaptive object model and reflection as support in the creation of variants. The proposed process uses as case study the software system of a hypothetic space vehicle, the Brazilian Satellites Launcher (LSB).

[pt] A configuração de produto é uma atividade chave para permitir a customização em massa. Ela corresponde a produção de um sistema computacional a partir de uma linha de produtos de software, respeitando as necessidades individuais dos clientes. Na prática, a atividade de configuração do produto pode se tornar uma tarefa complexa, principalmente porque envolve várias partes interessadas com diferentes competências para tomar decisões. Vários trabalhos proprõem decompor a atividade de configuração em estágios pré-estabelecidos, atravrés dos quais os interessados podem tomar suas decisões de forma separada e coerente. No entanto, quando há uma descentralização geográfica do conhecimento necessário em cada etapa e/ou quando os requisitos do cliente forem imprecisos e mudarem com frequência, essas soluções propostas não se aplicam. Para resolver essas questões, este trabalho proprõe uma abordagem de configuração dinâmica e colaborativa de produtos com base na metáfora de assistência pessoal. Os assistentes pessoais num ambiente cooperativo coordenam as decisões dos stakeholders e pró-ativamente executam tarefas, tais como o raciocínio sobre as implicaçõoes das decisões, integrando as decisões distribuídas e resolvendo os requisitos divergentes. Uma ferramenta protótipo, chamada Libertas, e dois cenários ilustrativos que avaliam a aplicabilidade da nossa abordagem também são apresentados. O primeiro cenário analisa o processo de configuração para configurar um sistema operacional para suportar os requisitos de negócio de uma empresa. O segundo aborda um cen´ario com uma linha de produtos de software para portais web. / [en] Product configuration is a key activity for enabling mass customization. It corresponds to tailoring a software application from a software product line, respecting individual customer requirements. In practice, the product configuration activity is challenging, mainly because it involves numerous stakeholders with different expertise making decisions. Several works claim to decompose the configuration activity into pre-arranged stages, whereby stakeholders can make their decisions in a separated way and coherent fashion. However, due to the decentralization in geography of the knowledge required in each stage and that customer requirements could be imprecise and change frequently, the proposed solutions do not apply. To address these issues, this work proposes a dynamic and collaborative product configuration approach based on the personal assistant metaphor. Personal assistants in a cooperative way coordinate stakeholders´ decisions and proactively perform tasks, such as reasoning about the ramifications of decisions, integrating distributed decisions and resolving divergent requirements. A tool prototype, called Libertas, and two case studies that evaluate the applicability of our approach are also presented. The first case study analyzes the configuration process to configure an operational system to support the business requirements of an enterprise. The second one addresses a scenario of a software product line for web portals.

Linhas de produtos de software (LPS) são coleções de sistemas que compartilham características comuns, desenvolvidas de forma sistemática a partir de um conjunto comum de ativos centrais. Dentre as técnicas propostas por vários autores para o desenvolvimento de LPS, dois padrões podem ser observados: o processo de desenvolvimento geralmente é sequencial e o foco do projeto (design) costuma estar em interesses técnicos, como alocação de componentes e separação em subsistemas, e não em um modelo de domínio. Embora essas práticas sejam reportadas como bem-sucedidas, um outro paradigma de desenvolvimento, baseado em métodos ágeis e em um conjunto de princípios de projeto conhecido como domain-driven design, é apresentado neste trabalho e pode produzir resultados mais satisfatórios, comparados aos métodos tradicionais. Essa hipótese é sustentada por comparações entre padrões de modelagem e por um estudo de caso feito neste trabalho / Software product lines (SPL) are collections of systems that have common features. Those systems are systematically developed from a common set of core assets. Two patterns outstand among the various techniques proposed by several authors for developing software product lines: the development process is generally sequential and the primary design concerns deal with technical issues, such as component allocation and system partitioning (into subsystems). The importance of a domain model is often neglected. Although such practices have been reported as successful, this work proposes another paradigm, which can yield more satisfactory results. This paradigm is based on agile methods and a set of design principles known as domain-driven design. This hypothesis is supported by comparing different modeling patterns and by developing a case study

Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-03-15T15:21:11Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) TESE_SABRINA.pdf: 1152470 bytes, checksum: a89ffc94cb3ee813cf52ca2c043171ba (MD5) / Made available in DSpace on 2016-03-15T15:21:11Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) TESE_SABRINA.pdf: 1152470 bytes, checksum: a89ffc94cb3ee813cf52ca2c043171ba (MD5) Previous issue date: 2015-03-31 / Software Product Lines (SPLs) allow engineers to systematically build families of software products, defined by a unique combination of features—increments in functionality, improving both the efficiency of the software development process and the quality of the software developed. However, testing these kinds of systems is challenging, as it may require running each test against a combinatorial number of products. We call this problem the High Dimensionality Problem. Another obstacle to product line testing is the absence of Feature Models (FMs), making it difficult to discover the real causes for test failures. We call this problem the Lack of Feature Model Problem. The High Dimensionality Problem is associated to the large space of possible configurations that an SPL can reach. If an SPL has n boolean features, for example, there are 2n possible feature combinations. Therefore, systematically testing this kind of system may require running each test against all those combinations, in the worst case. The Lack of Feature Model Problem is related to the absence of feature models. The FM enables accurate categorization of failing tests as failures of programs or the tests themselves, not as failures due to inconsistent combinations of features. For this reason, the lack of FM presents a huge challenge to discover the true causes for test failures. Aiming to solve these problems, we propose two lightweight techniques: SPLat and SPLif. SPLat is a new approach to dynamically prune irrelevant configurations: the configurations to run for a test can be determined during test execution by monitoring accesses to configuration variables. As a result, SPLat reduces the number of configurations. Consequently, SPLat is lightweight compared to prior works that used static analysis and heavyweight dynamic execution. SPLif is a technique for testing SPLs that does not require a priori availability of feature models. Our insight is to use a profile of passing and failing test runs to quickly identify test failures that are indicative of a problem (in test or code) as opposed to a manifestation of execution against an inconsistent combination of features. Experimental results show that SPLat effectively identifies relevant configurations with a low overhead. We also apply SPLat on two large configurable systems (Groupon and GCC), and it scaled without much engineering effort. Experimental results demonstrate that SPLif is useful and effective to quickly find tests that fail on consistent configurations, regardless of how complete the FMs are. Furthermore, we evaluated SPLif on one large extensively tested configurable system, GCC, where it helped to reveal 5 new bugs, 3 of which have been fixed after our bug reports. / Software Product Lines (SPLs) allow engineers to systematically build families of software products, defined by a unique combination of features—increments in functionality, improving both the efficiency of the software development process and the quality of the software developed. However, testing these kinds of systems is challenging, as it may require running each test against a combinatorial number of products. We call this problem the High Dimensionality Problem. Another obstacle to product line testing is the absence of Feature Models (FMs), making it difficult to discover the real causes for test failures. We call this problem the Lack of Feature Model Problem. The High Dimensionality Problem is associated to the large space of possible configurations that an SPL can reach. If an SPL has n boolean features, for example, there are 2n possible feature combinations. Therefore, systematically testing this kind of system may require running each test against all those combinations, in the worst case. The Lack of Feature Model Problem is related to the absence of feature models. The FM enables accurate categorization of failing tests as failures of programs or the tests themselves, not as failures due to inconsistent combinations of features. For this reason, the lack of FM presents a huge challenge to discover the true causes for test failures. Aiming to solve these problems, we propose two lightweight techniques: SPLat and SPLif. SPLat is a new approach to dynamically prune irrelevant configurations: the configurations to run for a test can be determined during test execution by monitoring accesses to configuration variables. As a result, SPLat reduces the number of configurations. Consequently, SPLat is lightweight compared to prior works that used static analysis and heavyweight dynamic execution. SPLif is a technique for testing SPLs that does not require a priori availability of feature models. Our insight is to use a profile of passing and failing test runs to quickly identify test failures that are indicative of a problem (in test or code) as opposed to a manifestation of execution against an inconsistent combination of features. Experimental results show that SPLat effectively identifies relevant configurations with a low overhead. We also apply SPLat on two large configurable systems (Groupon and GCC), and it scaled without much engineering effort. Experimental results demonstrate that SPLif is useful and effective to quickly find tests that fail on consistent configurations, regardless of how complete the FMs are. Furthermore, we evaluated SPLif on one large extensively tested configurable system, GCC, where it helped to reveal 5 new bugs, 3 of which have been fixed after our bug reports.

Linhas de Produtos de Software (LPS) abstraem a semelhança entre produtos e envolvem o conceito de reúso de software para desenvolver software em larga escala com mais rapidez e qualidade. O reúso dos artefatos em uma LPS é planejado e executado desde sua concepção, sendo assim possível armazenar esses artefatos em um repositório (núcleo de ativos reusáveis) para utilização posterior. Porém, ao se construir um repositório para uma certa LPS, este atende apenas às especificações desta arquitetura e não promove o reúso desses ativos em outras LPS, causando uma certa perda no potencial de reusabilidade dos ativos produzidos e armazenados. Além disso, a definição e os dados da execução do processo de desenvolvimento dessas LPS também não são armazenados prevendo o reúso, o que gera retrabalho para definir e instanciar um processo de software sempre que uma nova LPS é criada. Neste contexto, este trabalho tem por objetivo apresentar uma abordagem baseada em um conjunto de serviços para promover o amplo reúso de ativos produzidos e de elementos de processo utilizados, além de facilitar a criação e o desenvolvimento de linha de produtos de software, permitindo o gerenciamento do núcleo de ativos reusáveis. Por possuir uma interface baseada em serviços, esta abordagem poderá ser incorporada também a outros ambientes. Para validar a abordagem, verificar vantagens e sugerir melhorias, foi conduzida uma prova de conceito com sua aplicação. Os resultados dessa prova comprovaram a viabilidade da abordagem em cumprir os objetivos propostos. / Software Product Lines (SPL) extract the similarity among products and use the software reuse concept to produce large-scale software with increased quality and reduction in the development time. Reuse in SPL is planned and executed since the beginning for each artifact resulting from the development process, and then these artifacts are stored in a repository (reusable core assets) for later use. However, when a repository is built for a specific SPL, it supports only the specifications for that architecture and do not promote the reuse of these assets among distinct SPL, which inhibits their reuse potential. In addition, the definition and execution data of the development process applied are not stored properly for reuse, which causes a re-work to define and instantiate a software process when creating a new SPL. In this context, this work aims at present a service-based approach to promote the wide reuse of the produced assets and process elements, also to facilitate the creation and the management of SPL and to allow the management of the reusable core assets. Once this approach has a service-based interface, it can be embedded into other environments. In order to validate this approach, point out advantages and suggest improvements, a concept proof was performed applying it. The results of this proof ensured the approach viability to fulfill the proposed goals.

Os geradores de aplicação são ferramentas que recebem uma especificação de software, validam essa especificação e geram artefatos automaticamente. Os geradores de aplicação podem trazer benefícios em termos de produtividade por gerarem automaticamente artefatos de baixo nível com base em especificações de nível mais alto. Um dos problemas dos geradores de aplicação é o seu alto custo de desenvolvimento. Os geradores de aplicação configuráveis são adaptados para fornecer apoio em domínios específicos, ou seja, são considerados meta-geradores utilizados para obter geradores de aplicação específicos. Este trabalho delineia um processo de desenvolvimento com geradores confi- guráveis, define a arquitetura e as características de um gerador configurável e apresenta a ferramenta Captor, que é um gerador de aplicação configurável desenvolvido para facilitar a construção de geradores específicos. Três estudos de caso nos quais a Captor é configurada para domínios de aplicação específi- cos são apresentados: persistência de dados, gestão de recursos de negócios e bóias náuticas / Application generators are tools that receive as input a software specification, validate it and automatically generate artifacts based on it. Application generators can bring several benefits in terms of productivity, as they automatically generate low-level artifacts based on higher abstraction level specifications. A major concern of application generators is their high development cost. Con- figurable application generators are those generators that can be adapted to give support in specific domains, i.e., they are considered as meta-generators through which it is possible to obtain specific application generators. This work presents an approach for software development supported by configurable application generators. It defines the architecture and main features of a configurable application generator and presents Captor, which is a configurable application generator developed to ease the creation of specific generators. Three case studies were conducted to show the configuration of the Captor tool to different application domains: objects persistence, business resource management and floating weather stations.

Made available in DSpace on 2014-12-17T15:48:02Z (GMT). No. of bitstreams: 1 MatheusAS_DISSERT.pdf: 2078765 bytes, checksum: 519489af2ea8e5db40a4abaa98e99b28 (MD5) Previous issue date: 2010-11-18 / With the increase of processing ability, storage and several kinds of communication existing such as Bluetooth, infrared, wireless networks, etc.., mobile devices are no longer only devices with specific function and have become tools with various functionalities. In the business field, the benefits that these kinds of devices can offer are considerable, because the portability allows tasks that previously could only be performed within the work environment, can be performed anywhere. In the context of oil exploration companies, mobile applications allow quick actions could be taken by petroleum engineers and technicians, using their mobile devices to avoid potential catastrophes like an unexpected stop or break of important equipment. In general, the configuration of equipment for oil extraction is performed on the work environment using computer systems in desktop platforms. After the obtained configuration, an employee goes to equipment to be configured and perform the modifications obtained on the use desktop system. This management process equipment for oil extraction takes long time and does not guarantee the maintenance in time to avoid problems. With the use of mobile devices, management and maintenance of equipment for oil extraction can be performed in a more agile time once it enables the engineer or technician oil can perform this configuration at the time and place where the request comes for example, near in the oil well where the equipment is located. The wide variety of mobile devices creates a big difficulty in developing mobile applications, since for one application can function in several types of devices, the application must be changed for each specific type of device, which makes the development quite costly. This paper defines and implements a software product line for designing sucker-rod pumping systems on mobile devices. This product line of software, called BMMobile, aims to produce products that are capable of performing calculations to determine the possible configurations for the equipment in the design suckerrod pumping, and managing the variabilities of the various products that can be generated. Besides, this work performs two evaluations. The first evaluation will verify the consistency of the products produced by the software product line. The second evaluation will verify the reuse of some products generated by SPL developed / Com o aumento da capacidade de processamento, armazenamento e a variedade de tipos de comunica??o existentes, como Bluetooth, infravermelho, redes sem fio, etc., os dispositivos m?veis deixaram de ser apenas dispositivos com fun??o especifica e passaram a ser ferramentas com diversos tipos de funcionalidade. No campo empresarial os benef?cios que estes tipos de dispositivos oferecem s?o consider?veis, uma vez que a portabilidade permite que tarefas que antes s? poderiam ser executadas dentro do ambiente de trabalho, possam ser realizadas em qualquer lugar. No contexto de empresas de explora??o de petr?leo, aplica??es m?veis permitem que a??es r?pidas possam ser tomadas por engenheiros e t?cnicos de petr?leo, usando seus dispositivos m?veis, de forma a evitar poss?veis cat?strofes como a parada de um po?o ou quebra de um equipamento importante. Em geral, a configura??o de equipamentos para extra??o de petr?leo ? realizada no ambiente de trabalho usando sistemas computacionais em plataformas desktop. Ap?s a configura??o ser determinada, algum funcion?rio deve ir ao equipamento a ser configurado e executar as modifica??es obtidas na utiliza??o do sistema desktop. Este processo de gerenciamento de equipamentos para a extra??o de petr?leo demanda muito tempo e n?o garante a manuten??o em tempo h?bil de forma a evitar maiores problemas. Com a utiliza??o de dispositivos m?veis, o gerenciamento e manuten??o de equipamentos para extra??o de petr?leo pode ser realizada de forma mais ?gil, uma vez que permite que o engenheiro ou t?cnico de petr?leo possa realizar essa configura??o no momento e local aonde chega a solicita??o, por exemplo, pr?ximo ao po?o onde est? localizado o equipamento. A grande variedade de tipos de dispositivos m?veis gera uma grande dificuldade no desenvolvimento de aplica??es m?veis, uma vez que para que uma aplica??o possa funcionar em diversos tipos de dispositivos, a aplica??o deve sofrer altera??es para cada tipo especifico de aparelho, o que torna o desenvolvimento bastante custoso. Este trabalho define e implementa uma linha de produto de software para dimensionamento de bombeio mec?nico em dispositivos m?veis. Esta linha de produto de software, denominada BMMobile, tem como objetivo gerar produtos que sejam capazes de realizar c?lculos para determinar as configura??es poss?veis para os equipamentos no dimensionamento de bombeio mec?nico, al?m de gerenciar as variabilidades dos diversos produtos que podem ser gerados. Al?m disso, esse trabalho realiza duas avalia??es. A primeira avalia??o permite verificar a consist?ncia dos produtos produzidos pela linha de produto de software. A segunda avalia??o permite avaliar o reuso em alguns produtos gerados pela LPS desenvolvida