Thesis (Ph. D. in Computer Science)--Vanderbilt University, Dec. 2005. / Title from title screen. Includes bibliographical references.

Application Engineering is a field where software organizations develop software products from a predefined Software Product Line. The time and cost allotted to come up with a new product variant is limited. Lack of systematic support in testing leads to redundancy. Redundancy in this context can be found in test-cases that do not contribute towards fault-detection and testing leads to an increased testing effort. This thesis work proposes a framework to reduce the testing effort, aimed at avoiding testing redundancy. Feature Model diagrams have been constructed from the assumed specification requirements. These Feature Model diagrams have been used to derive test models such as Object Model diagram and State Chart diagram. Unit testing and System testing have been performed on test models to obtain test cases that have been stored in the repository. Regression testing has been applied to these test cases to classify them into Reusable, Re-testable and Obsolete.

Thesis (Ph.D.)--University of Texas at Dallas, 2009. / Includes vita. Includes bibliographical references (leaves 224-234)

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.

No description available.

Submitted by Adriely Bruce (adriely_bruce@hotmail.com) on 2016-12-16T15:23:35Z No. of bitstreams: 1 Dissertação - Rafael Normando Cunha.pdf: 2634755 bytes, checksum: 1a601e8e730d9bca00432b2e7038ac0f (MD5) / Approved for entry into archive by Divisão de Documentação/BC Biblioteca Central (ddbc@ufam.edu.br) on 2016-12-22T13:36:58Z (GMT) No. of bitstreams: 1 Dissertação - Rafael Normando Cunha.pdf: 2634755 bytes, checksum: 1a601e8e730d9bca00432b2e7038ac0f (MD5) / Approved for entry into archive by Divisão de Documentação/BC Biblioteca Central (ddbc@ufam.edu.br) on 2016-12-22T13:39:39Z (GMT) No. of bitstreams: 1 Dissertação - Rafael Normando Cunha.pdf: 2634755 bytes, checksum: 1a601e8e730d9bca00432b2e7038ac0f (MD5) / Made available in DSpace on 2016-12-22T13:39:39Z (GMT). No. of bitstreams: 1 Dissertação - Rafael Normando Cunha.pdf: 2634755 bytes, checksum: 1a601e8e730d9bca00432b2e7038ac0f (MD5) Previous issue date: 2013-12-17 / Agência de Fomento não informada / Software Product Lines enable organizations to develop a number of similar products in the same application domain, which reduces development time and maintenance cost, and increases productivity. Software product line specifications need to be evaluated for improving software. In this context, software inspections aims do guarantee complete, consistent and correct artifacts finding defects in early stages in software lifecycle. In this work, we propose SPLIT (Software Product Line Inspection Technique), which is a set of modelbased inspection techniques for evaluating software product line specifications. A feasibility study was conducted for comparing SPLIT against a defect type-based inspection approach. The object of the feasibility study was a Twitter client software product line specification created for the experiment. The results indicated that the set of techniques found a greater number of defects than a defect type-based inspection approach. A second empirical study was conducted for comparing SPLIT against a defect type-based inspection approach using a real software product line for mobile robot vehicles. This study aimed to verify whether the set of techniques fits real world life-cycle development. The second empirical results supported the feasibility study in which SPLIT found a greater number of defects than a defect type-based inspection approach. Thus, software product line quality assurance can be improved using SPLIT for detecting defects in early stage of development. / Linha de produto de software permite que organizações desenvolvem um número similar de produtos específicos em um mesmo domínio de aplicação, reduzindo o tempo de desenvolvimento e o custo de manutenção, e aumentando a produtividade. Especificações de linha de produto de software necessitam ser avaliadas para aumentar a qualidade do software. Neste cenário, inspeções de software visam garantir que os artefatos estejam completos, consistentes e corretos ao encontrar defeitos em estágios iniciais do ciclo de vida de desenvolvimento. Neste trabalho, é proposta a SPLIT (Software Product Line Inspection Technique), um conjunto de técnicas de inspeção baseada em modelos para avaliar especificações de linha de produto de software. Um estudo de viabilidade foi conduzido para comparar a SPLIT com uma abordagem de inspeção baseada em tipos de defeitos. O objeto do estudo de viabilidade foi um cliente de Twitter desenvolvido para a execução do experimento. Os resultados indicaram que o conjunto de técnicas SPLIT encontrou um número maior de defeitos que uma abordagem de inspeção baseada em tipos de defeitos. Um segundo experimento foi conduzido para comparar a SPLIT com uma abordagem baseada em tipos de defeitos usando uma linha de produto de software real para veículos robóticos móveis. Este estudo visou verificar se o conjunto de técnicas se adaptam ao ciclo de vida de desenvolvimento real. O segundo experimento corroborou o resultado do estudo de viabilidade ao encontrar um número de defeitos maior que uma abordagem de inspeção baseada em tipos de defeitos. Com isso, a garantia da qualidade em linhas de produto de software pode ser melhorada ao utilizar a SPLIT para encontrar defeitos em estágios iniciais do desenvolvimento.

The requirements for software products have increased in recent years. This is both due to more complex technology as well as more requirements from the customers. An approach to solve this issue is by using a software product line (SPL) where reusable assets are developed to produce more tailor-made products with reduced time to market. When creating reusable assets, one also wants to reuse the tests for them. In order to do that, it is important to understand what to test, and where to test. A good test strategy is thereby crucial in order to avoid testing becoming a bottleneck for efficient software development. The purpose of this thesis was to investigate how to create a good testing strategy for products in an SPL. This was done by collecting information about the current testing process in order to understand which requirements that exist and how they are addressed. The core foundation of an SPL is to utilize variation to create new products. To understand the existing variation of the product and the test cases a feature modeling and similarity analysis was done. The result from them made it possible to create a test strategy and categorization of test cases that can be used to ease the reuse of test cases for new variants of the product. The resulting test strategy presented proposes feature modeling as the basis of test creation and categorization as a tool to enable easier reuse of test cases. The results of the study indicate that using SPL theory in testing can introduce a better test strategy and test case creation process which is beneficial for the whole development process. / Kraven på mjukvaruprodukter har ökat de senaste åren. Detta beror delvis på mer komplicerad teknologi, men även på att kunderna ställer högre krav på de produkter de använder. Ett tillvägagångssätt för att lösa detta är att använda en software product line. I en software product line utvecklas återanvändningsbara delar som sedan kan kombineras och därmed skapa skräddarsydda produkter på ett mer effektivt sätt. När man skapar återanvändningsbara mjukvarudelar vill man också återanvända testerna för dem. För att göra det är det viktigt att förstå vad som ska testas och varför. En bra teststrategi är därmed avgörande för att undvika att testning blir en flaskhals för effektiv mjukvaruutveckling. Syftet med detta arbete var att undersöka hur man skapar en bra teststrategi för produkter i en software product line. Detta gjordes genom att samla in information om den nuvarande testprocessen för att förstå vilka krav som finns och hur de hanteras. En huvudaspekt i software product lineteori är att använda variation för att skapa nya produkter. För att förstå variationen i produkten och dess testfall gjordes en funktionsmodellering och likhetsanalys. Resultaten från dem gjorde det möjligt att skapa en teststrategi och en kategorisering av testfall som kan användas för att underlätta återanvändningen av testfall för nya varianter av produkten. Den resulterande teststrategin som presenteras föreslår funktionsmodellering som grund för testskapande och kategorisering som ett verktyg för att möjliggöra enklare återanvändning av testfall. Resultaten av studien tyder på att användning av software product lineteori vid testning kan resultera i en bättre teststrategi och enklare process för skapandet av nya testfall.

In software product line engineering, the construction of an architecture for a product family is still an outstanding engineering challenge. In current practice, a framework is used for configuring individual products by combining solution space artefacts into products with specified features according to a feature model. No architectures are created. In contrast, an architecture for a product family would define the architectures for all the products in the family, allowing engineers to reason at a higher level of abstraction. In this thesis, we present a component model that can be used to define architectures for product families, by incorporating explicit variation points.

Research in Software Product Line Engineering (SPLE) traditionally focuses on product derivation. Prior work has explored the automated derivation of products by module composition. However, it has so far neglected propagating changes (edits) in a product back to the product line definition. A domain-specific product should be possible to update its features locally, and later these changes should be propagated back to the product line definition automatically. Otherwise, the entire product line has to be revised manually in order to make the changes permanent. Although this is the current state, it is a very error-prone process. To address these issues, we present a tool called Paan to create product lines of MS Word documents with back-propagation support. It is a diff-based tool that ignores unchanged fragments and reveals fragments that are changed, added or deleted. Paan takes a document with variation points (VPs) as input, and shreds it into building blocks called tiles. Only those tiles that are new or have changed must be updated in the tile repository. In this way, changes in composed documents can be back-propagated to their original feature module definitions. A document is synthesized by retrieving the appropriate tiles and composing them. / text