Made available in DSpace on 2014-06-12T16:01:17Z (GMT). No. of bitstreams: 2 arquivo7562_1.pdf: 3512712 bytes, checksum: d7dd3b157b1e7c89309ff683efdc8a2f (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / Atualmente a decisão de trabalhar, ou não, com Linhas de Produtos de Software (LPS) se tornou um requisito obrigatório para o planejamento estratégico das empresas que trabalham com domínio específico. LPS possibilita que as organizações alcancem reduções significativas nos custos de desenvolvimento e manutenção, melhorias quantitativas na produtividade, qualidade e satisfação do cliente. Por outro lado, os pontos negativos em adotar LPS são demanda extra de investimentos para criar os artefatos reusáveis, fazer mudana¸s organizacionais, etc. Além disso, teste é mais complicado e crítico em linhas de produtos do que em sistemas simples. Porém, continua sendo a forma mais efetiva para garantia de qualidade em LPS. Por isso, aprender a escolher as ferramentas certas para teste em LPS é um benefício que contribui pra redução de alguns desses problemas enfrentados pelas empresas. Apesar do crescente número de ferramentas disponíveis, teste em LPS ainda necessita de ferramentas que apoiem o nível de teste de sistema, gerenciando a variabilidade dos artefatos de teste. Neste contexto, este trabalho apresenta uma ferramenta de teste de linhas de produtos de software para construir testes de sistema a partir dos casos de uso que endereçam desafios para teste em LPS identificados na revisão literária. A ferramenta foi desenvolvida com o intuito de reduzir o esforço necessário para realizar as atividades de teste no ambiente de LPS. Além disso, esta dissertação apresenta um estudo exploratório sistemático que tem como objetivo investigar o estado da arte em relação a ferramentas de teste, sintetizando as evidências disponíveis e identificar lacunas entre as ferramentas, disponíveis na literatura. Este trabalho também apresenta um estudo experimental controlado para avaliar a eficácia da ferramenta proposta

Due to a high competitive pressure on the global software market, in many areas the software industry is moving from hand crafting to semi-automatic or automatic software construction based on Software Product Lines (SPL). Techniques to automate the construction of software products from SPLs are widely available. These can handle variability in source code artifacts but they are inappropriate to handle variability in Graphical User Interfaces (GUIs). The main reason is that they are not designed to handle such fine grained configurations as they are required to configure GUI frameworks or toolkits. To nevertheless employ them in GUI generation tasks is complex and time consuming. However, in the Human Computer Interaction (HCI) community approaches to develop GUIs in a model-based manner and with constraint-based techniques are worked on that help automate the construction of GUIs. Therefore, the main hypothesis of the proposed research is that constraint-based GUIs techniques are a well suited basis for reducing the customization effort of generated GUIs of SPLs. The paper proposes a research plan to employ these new HCI techniques in generating GUIs for SPLs.

Both feature and class modeling are used in Software Product Line (SPL) engineering to model variability. Feature models are used primarily to represent user-visible characteristics (i.e., features) of products; whereas class models are often used to model types of components and connectors in a product-line architecture. Previous works have explored the approach of using a single language to express both configurations of features and components. Their goal was to simplify the definition and analysis of feature-to-component mappings and to allow modeling component options as features. A prominent example of this approach is cardinality-based feature modeling, which extends feature models with multiple instantiation and references to express component-like, replicated features. Another example is to support feature modeling in a class modeling language, such as UML or MOF, using their profiling mechanisms and a stylized use of composition. Both examples have notable drawbacks: cardinality-based feature modeling lacks a constraint language and a well-defined semantics; encoding feature models as class models and their evolution bring extra complexity. This dissertation presents Clafer (class, feature, reference), a class modeling language with first-class support for feature modeling. Clafer can express rich structural models augmented with complex constraints, i.e., domain, variability, component models, and meta-models. Clafer supports: (i) class-based meta-models, (ii) object models (with uncertainty, if needed), (iii) feature models with attributes and multiple instantiation, (iv) configurations of feature models, (v) mixtures of meta- and feature models and model templates, and (vi) first-order logic constraints. Clafer also makes it possible to arrange models into multiple specialization and extension layers via constraints and inheritance. On the other hand, in designing Clafer we wanted to create a language that builds upon as few concepts as possible, and is easy to learn. The language is supported by tools for SPL verification and optimization. We propose to unify basic modeling constructs into a single concept, called clafer. In other words, Clafer is not a hybrid language. We identify several key mechanisms allowing a class modeling language to express feature models concisely. We provide Clafer with a formal semantics built in a novel, structurally explicit way. As Clafer subsumes cardinality-based feature modeling with attributes, references, and constraints, we are the first to precisely define semantics of such models. We also explore the notion of partial instantiation that allows for modeling with uncertainty and variability. We show that Object-Oriented Modeling (OOM) languages with no direct support for partial instances can support them via class modeling, using subclassing and strengthening multiplicity constraints. We make the encoding of partial instances via subclassing precise and general. Clafer uses this encoding and pushes the idea even further: it provides a syntactic unification of types and (partial) instances via subclassing and redefinition. We evaluate Clafer analytically and experimentally. The analytical evaluation shows that Clafer can concisely express feature and meta-models via a uniform syntax and unified semantics. The experimental evaluation shows that: 1) Clafer can express a variety of realistic rich structural models with complex constraints, such as variability models, meta-models, model templates, and domain models; and 2) that useful analyses can be performed within seconds.

Thesis (M.S.)--West Virginia University, 2008. / Title from document title page. Document formatted into pages; contains xi, 126 p. : ill. (some col.). Includes abstract. Includes bibliographical references (p. 121-126).

Submitted by Pedro Henrique Rodrigues (pedro.henriquer@ufpe.br) on 2015-03-05T19:54:44Z No. of bitstreams: 2 rcaa-dissertacao.pdf: 2306258 bytes, checksum: c627fb646b9c6f3cadf93565c0b59dd9 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-05T19:54:44Z (GMT). No. of bitstreams: 2 rcaa-dissertacao.pdf: 2306258 bytes, checksum: c627fb646b9c6f3cadf93565c0b59dd9 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2012-03-02 / FACEPE, CNPq, INES / Companies are adopting the Software Product Line (SPL) development paradigm to obtain significant improvements in time to market, maintenance cost, productivity, and quality of products. SPL encompasses a family of software-intensive systems developed from reusable assets. By reusing such assets, it is possible to construct a large number of different products applying various compositions. There is a variety of widely used techniques to develop SPLs, such as aspect-oriented programming (AOP), feature-oriented programming (FOP), and conditional compilation. These techniques differ in the type of composition to create a product within the SPL static or dynamically. In this context, it is important to define when certain features should be activated in the product due to specific client requirements and different application scenarios. Thereby, the binding time of a feature is the time that one decides to activate or deactivate the feature from a product. In general, static and dynamic binding times are considered. For example, products for devices with constrained resources may use static binding time instead of dynamic due to the performance overhead introduced by the latter. For devices without constrained resources, the binding time can be flexible, features can be activated or deactivated statically or users may do it on demand (dynamically). To provide flexible binding time for features, researchers proposed an AOP idiom based on AspectJ and design patterns named Edicts. The idea consists of supporting binding time flexibility of features in a modular and convenient way. However, we observe modularity problems in the Edicts idiom. Although we usually use aspects to tackle crosscutting concerns common in classes, such a problem now appears within the own aspects. Indeed, several studies indicate that these concerns hurt software modularity. This way, we observe that Edicts clones, scatters, and tangles code throughout its implementation, which may lead to time consuming tasks, such as maintaining duplicated code. This way, we develop three idioms and implement them to provide flexible binding time for features of four different applications. In addition, we evaluate Edicts and the three idioms quantitatively by means of metrics with respect to code tangling, scattering, cloning, size, and also try to guarantee that our idioms do not change feature code behavior among the different implementations.

Scoping in Software Product Lines (SPL) is the first step to identify products, features, and assets in a market segment. Traditional approaches for SPL scoping are heavyweight and upfront processes in scenarios with unpredictable changes and little resources. An incurred key challenge is handling systematically the iterativeness, adaptability, and feedback in the SPL scoping process. As a final consequence, the software industry can hamper investment in the SPL scoping. In this context, the Scrum framework, as the most popular agile approach to foster the iterativeness, adaptability, and feedbacks, can address that challenge. Previous studies have combined Scrum into some SPL activities with good results. This thesis provides a process, named of RiPLE-SCA, for SPL scoping inspired in the Scrum practices. This process bases on industrial evidence (a case study of a traditional SPL scoping), expert opinion on agile SPL (through a survey), and scientific literature about agile SPL (a systematic mapping). A feasibility study and a cross-case study carried out with two industrial partners indicated that the RiPLE-SCA is practicable and appropriate for an industrial setting as well as fosters iterativeness, adaptability, and feedbacks detecting early obsolete features and changes in domain, requirements, features, and technology. / Submitted by João Arthur Martins (joao.arthur@ufpe.br) on 2015-03-12T18:58:41Z No. of bitstreams: 2 Tese Ivonei Freitas da Silva.pdf: 9233841 bytes, checksum: 6029df71deecd12c97bd99e1787a8361 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-12T18:58:41Z (GMT). No. of bitstreams: 2 Tese Ivonei Freitas da Silva.pdf: 9233841 bytes, checksum: 6029df71deecd12c97bd99e1787a8361 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2013-10-29 / CNPq / A atividade de escopo em linhas de produto de software é o primeiro passo para identificar produtos, características e ativos de software em um segmento de mercado. As abordagens tradicionais para escopo de linhas de produto de software são processos densos e abrangentes em cenários com mudanças imprevisíveis e com poucos recursos. Um desafio chave nesse cenário é o gerenciamento sistemático da iteratividade, adaptabilidade e do feedback no processo de escopo de linhas de produto de software. Como último efeito, a indústria de software pode restringir investimentos no processo de escopo. Neste contexto, o framework Scrum, abordagem mais popular para incentivar a iteratividade, a adaptabilidade e o feedback, pode lidar com esse desafio. Estudos anteriores têm combinado Scrum com algumas atividades de linhas de produto de software obtendo bons resultados. Esta tese define um processo, denominado de RiPLE-ASC, para o escopo da linha de produtos de software inspirado nas práticas do Scrum. Este processo basea-se nas evidências da indústria (um estudo de caso real de escopo de linhas de produto usando uma abordagem tradicional), na opinião de especialistas em linhas de produto de software ágeis (através de um survey) e na literatura científica sobre linhas de produto de software ágeis (uma mapeamento sistemático). Um estudo de viabilidade e um estudo de caso “cross-case” executados com dois parceiros industriais de nosso grupo de pesquisa indicaram que o RiPLE-ASC tem aplicação prática e adequa-se em um ambiente de produção de software industrial bem como incentiva a iteratividade, adaptabilidade e o feedback detectando cedo características obsoletas e mudanças no domínio, requisitos, características e tecnologia

Made available in DSpace on 2014-06-12T15:57:06Z (GMT). No. of bitstreams: 2 arquivo3140_1.pdf: 4172532 bytes, checksum: b7cc6b23a678d29aa1a5c9c9da0617e9 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2010 / Fundação de Amparo à Ciência e Tecnologia do Estado de Pernambuco / Com o objetivo de produzir produtos individualizados, muitas vezes, as empresas se deparam com a necessidade de altos investimentos, elevando assim os preços de produtos individualizados. A partir dessa necessidade, muitas empresas, começaram a introduzir o conceito de plataforma comum, com o objetivo de desenvolver uma grande variedade de produtos, reusando suas partes comuns. No contexto de linha de produto de software, essa plataforma em comum é chamada de arquitetura de referência, que prove uma estrutura comum de alto nível onde os produtos são construídos. A arquitetura de software, de acordo com alguns pesquisadores, está se tornando o ponto central no desenvolvimento de linha de produtos, sendo o primeiro modelo e base para guiar a implementação dos produtos. No entanto, essa arquitetura sofre modificações com o passar do tempo, com o objetivo de satisfazer as necessidades dos clientes, a mudanças no ambiente, além de melhorias e mudanças corretivas. Desta forma, visando assegurar que essas modificações estão em conformidade com as especificações da arquitetura, não introduziram novos erros e que as novas funcionalidades continuam funcionando como esperado, a realização de testes de regressão é importante. Neste contexto, este trabalho apresenta uma abordagem de regressão utilizada tanto para reduzir o número de testes que precisam ser reexecutados, da arquitetura de referência e da arquitetura dos produtos, quanto para tentar assegurar que novos erros não foram inseridos, depois que essas arquiteturas passaram por uma evolução ou mudança corretiva. Como regressão é vista como uma técnica que pode ser aplicada em mais de uma fase de teste, neste trabalho regressão é aplicado durante a fase de integração, uma vez que, ao final desta fase teremos as arquiteturas da linha de produto testadas. Desta forma, uma abordagem de integração também foi proposta. Esta dissertação também apresenta uma validação inicial da abordagem, através de um estudo experimental, mostrando indícios de que será viável a aplicação de testes de regressão nas arquiteturas de uma linha de produto de software

The architecture of a software system is defined by significant decisions that drive the way in which the software is designed implemented and maintained. In the context of software product lines, these decisions will determine the design of an architec- ture that provides the software with the ability to be configured for different product variants and extended to accommodate future requirements. Although, variability models describe the different configurations of current and fu- ture products that the product line supports, the knowledge of how the architecture was designed to support variations of a product in space and time exists only in the architects’ mind or remains implicit in architectural models. This thesis argues that the knowledge found in architectural models and design rationale can be used to facilitate the derivation of product variants and the evolution of the product line. To support this notion, we propose the AKinSPL method for capturing the architec- tural knowledge in software product lines. The method is founded on the factors that architects take into consideration when designing the architecture, and a meta-model that represents the mental models and processes architects follow during the creation of a product line architecture. To validate the concepts of AKinSPL, its guidelines were mapped to activities of the PuLSE-DSSA methodology and new artifacts were created to capture architectural knowledge on the basis of those guidelines. Next, it was applied to capture the archi- tectural knowledge of an embedded software system for automatic control of agricul- tural equipment. The results showed that diagrams augmented with design rationale enable a faster understanding of the purpose of the architectural models. Similarly, the prescriptions of the architecture with respect to the implementation are conveyed more easily. / jmercadoh@gmail.com Tel: +4916099058545

Software reuse is perceived as the key to successful software development because of the potential for shortened time to market, increased quality and reduced costs. In recent years software product lines have emerged as a promising way to achieve large scale software reuse. Challenges against successful reuse when developing in a software product line involves management of the differences between products, and the differences between different releases of the products. In this thesis we present the experiences from a series of case studies within four software companies. Based on these we present a taxonomy of the technical solutions to manage product differences, a historical essay of how components in a software product line can evolve and what mechanisms that are used to support this evolution. From this we elaborate on the connection between evolution and variability, i.e. the ability of the software architecture and components to support the differences between products. We argue that evolution is strongly connected to variability, and that by foreseeing the evolution, the software can be instrumented with appropriate variability mechanisms accordingly. Moreover, we argue that some types of evolution are more frequent than others, and that the efforts should mainly go in the direction of foreseeing and instrumenting for these types of evolution.

Developing software for complicated systems is often done by collaboration and consists of deliverables by a multitude of organisations. The deliverables can range from smaller devices and commercial-off-the-shelf software components, to larger systems. This is the situation during the development of the embedded system for large vehicles or machines. Many companies within the embedded industry are transitioning to using Service-Orientation to develop high-quality software and reduce costs. However, when integrating different external systems with an internal, service-oriented system there may arise difficulties since the communication patterns, i.e. interface, cannot be changed to fit the internal system. This study aims to develop a design solution that can be used to integrate different external systems with an internally developed service-oriented system in an entire software product line, including the handling of variability by parametrization. The solution is evaluated by software developers at a company in such a situation. To develop the design solution design science methodology is applied, which is an iterative process that continuously improves the candidate solution until satisfactory according to various stakeholders. The resultant design solution includes the use of wrappers-based interaction between systems, where so-called adapters are used when the internal system acts as a client to an external system, and using gateways for when the internal systems acts as a server to an external system. We also observe the need for a system integration view to describe the relations and available communication mechanisms between systems, i.e. the gateways and adapters. We conclude that to integrate a service-oriented software system with non-service-oriented systems, there can be benefits to using an abstraction layer between systems to protect the internally developed software architecture from being affected by the nature of the external system. Attempting to integrate external systems with an internal system as if also developed internally may become troublesome in terms of defining and upholding an appropriate service-oriented architecture. This is especially important when considering variability of the complete system, where different external systems are used or replaced in specific variants.