Search

In practice, developers mostly use purely textual, line-based, merge tools. Such tools, however, often report false conflicts. Researchers have then proposed AST-based tools that explore language syntactic structure to reduce false conflicts. Nevertheless, these approaches might negatively impact merge performance, and demand the creation of a new tool for each language. Trying to simulate the behavior of AST-based tools without their drawbacks, this paper proposes and analyzes a purely textual, separator-based, merge tool that aims to simulate AST-based tools by considering programming language syntactic separators, instead of just lines, when comparing and merging changes. The obtained results show that the separator-based textual approach might reduce the number of false conflicts when compared to the line-based approach. The new solution makes room for future studies and hybrid merge tools.

In a collaborative development context, conflicting code changes might compromise software quality and developers productivity. To reduce conflicts, one could avoid the parallel execution of potentially conflicting tasks. Although hopeful, this strategy is challenging because it relies on the prediction of the required file changes to complete a task. As predicting such file changes is hard, we investigate its feasibility for BDD (Behaviour-Driven Development) projects, which write automated acceptance tests before implementing features. We develop a tool that, for a given task, statically analyzes Cucumber tests and infers test-based interfaces (files that could be executed by the tests), approximating files that would be changed by the task. To assess the accuracy of this approximation, we measure precision and recall of test-based interfaces of 513 tasks from 18 Rails projects on GitHub. We also compare such interfaces with randomly defined interfaces, interfaces obtained by textual similarity of test specifications with past tasks, and interfaces computed by executing tests. Our results give evidence that, in the specific context of BDD, Cucumber tests might help to predict files changed by tasks. We find that the better the test coverage, the better the predictive power. A hybrid approach for computing test-based interfaces is promising.

Branching and merging are common practices in collaborative software development. They increase developer productivity by fostering teamwork, allowing developers to independently contribute to a software project. Despite such benefits, branching and merging comes at a cost—the need to merge software and to resolve merge conflicts, which often occur in practice. While modern merge techniques, such as 3-way or structured merge, can resolve many such conflicts automatically, they fail when the conflict arises not at the syntactic, but the semantic level. Detecting such conflicts requires understanding the behavior of the software, which is beyond the capabilities of most existing merge tools. As such, semantic conflicts can only be identified and fixed with significant effort and knowledge of the changes to be merged. While semantic merge tools have been proposed, they are usually heavyweight, based on static analysis, and need explicit specifications of program behavior. In this work, we take a different route and explore the automated creation of unit tests as partial specifications to detect unwanted behavior changes (conflicts) when merging software.We systematically explore the detection of semantic conflicts through unit-test generation. Relying on a ground-truth dataset of 38 software merge scenarios, which we extracted from GitHub, we manually analyzed them and investigated whether semantic conflicts exist. Next, we apply test-generation tools to study their detection rates. We propose improvements (code transformations) and study their effectiveness, as well as we qualitatively analyze the detection results and propose future improvements. For example, we analyze the generated test suites for false-negative cases to understand why the conflict was not detected. Our results evidence the feasibility of using test-case generation to detect semantic conflicts as a method that is versatile and requires only limited deployment effort in practice, as well as it does not require explicit behavior specifications.

Refactoring engines may have overly strong preconditions preventing developers from applying useful transformations. We find that 32 percent of the Eclipse and JRRT test suites are concerned with detecting overly strong preconditions. In general, developers manually write test cases, which is costly and error prone. Our previous technique detects overly strong preconditions using differential testing. However, it needs at least two refactoring engines. In this work, we propose a technique to detect overly strong preconditions in refactoring engines without needing reference implementations. We automatically generate programs and attempt to refactor them. For each rejected transformation, we attempt to apply it again after disabling the preconditions that lead the refactoring engine to reject the transformation. If it applies a behavior preserving transformation, we consider the disabled preconditions overly strong. We evaluate 10 refactorings of Eclipse and JRRT by generating 154,040 programs. We find 15 overly strong preconditions in Eclipse and 15 in JRRT. Our technique detects 11 bugs that our previous technique cannot detect while missing 5 bugs. We evaluate the technique by replacing the programs generated by JDolly with the input programs of Eclipse and JRRT test suites. Our technique detects 14 overly strong preconditions in Eclipse and 4 in JRRT.

Integration conflicts often damage software quality and developers' productivity in a collaborative development environment. For reducing merge conflicts, we could avoid asking developers to execute potentially conflicting tasks in parallel, as long as we can predict the files to be changed by each task. As manually predicting that is hard, the TAITI tool tries to do that in the context of BDD (Behaviour-Driven Development) projects, by statically analysing the automated acceptance tests that validate each task. TAITI computes the set of files that might be executed by the tests of a task (a so called test-based task interface), approximating the files that developers will change when performing the task. Although TAITI performs better than a random task interface, there is space for accuracy improvements. In this paper, we extend the interfaces computed by TAITI by including the dependences of the application files reached by the task tests. To understand the potential benefits of our extension, we evaluate precision and recall of 60 task interfaces from 8 Rails GitHub projects. The results bring evidence that the extended interface improves recall by slightly compromising precision.

Context: Merge conflicts often occur when developers change the same code artifacts. Such conflicts might be frequent in practice, and resolving them might be costly and is an error-prone activity. Objective: To minimize these problems by reducing merge conflicts, it is important to better understand how conflict occurrence is affected by technical and organizational factors. Method: With that aim, we investigate seven factors related to modularity, size, and timing of developers contributions. To do so, we reproduce and analyze 73504 merge scenarios in GitHub repositories of Ruby and Python MVC projects. Results: We find evidence that the likelihood of merge conflict occurrence significantly increases when contributions to be merged are not modular in the sense that they involve files from the same MVC slice (related model, view, and controller files). We also find bigger contributions involving more developers, commits, and changed files are more likely associated with merge conflicts. Regarding the timing factors, we observe contributions developed over longer periods of time are more likely associated with conflicts. No evaluated factor shows predictive power concerning both the number of merge conflicts and the number of files with conflicts. Conclusion: Our results could be used to derive recommendations for development teams and merge conflict prediction models. Project management and assistive tools could benefit from these models.

We extend our investigation of compositional product lines with more subjectsWe also investigate annotative product lines, and propose templates for this contextWe contribute to the body of evidence on safe evolution of product linesWe bring additional evidence of the expressiveness of the proposed templates Software product lines enable generating related software products from reusable assets. Adopting a product line strategy can bring significant quality and productivity improvements. However, evolving a product line can be risky, since it might impact many products. When introducing new features or improving its design, it is important to make sure that the behavior of existing products is not affected. To ensure that, one usually has to analyze different types of artifacts, an activity that can lead to errors. To address this issue, in this work we discover and analyze concrete evolution scenarios from five different product lines. We discover a total of 13 safe evolution templates, which are generic transformations that developers can apply when evolving compositional and annotative product lines, with the goal of preserving the behavior of existing products. We also evaluate the templates by analyzing the evolution history of these product lines. In this evaluation, we observe that the templates can address the modifications that developers performed in the analyzed scenarios, which corroborates the expressiveness of our template set. We also observe that the templates could also have helped to avoid the errors that we identified during our analysis.

Modularity benefits, including the independent maintenance and comprehension of individual modules, have been widely advocated. However, empirical assessments to investigate those benefits have mostly focused on source code, and thus, the relevance of modularity to earlier artifacts is still not so clear (such as requirements and design models). In this paper, we use a multimethod technique, including designed experiments, to empirically evaluate the benefits of modularity in the context of two approaches for specifying product line use case scenarios: PLUSS and MSVCM. The first uses an annotative approach for specifying variability, whereas the second relies on aspect-oriented constructs for separating common and variant scenario specifications. After evaluating these approaches through the specifications of several systems, we find out that MSVCM reduces feature scattering and improves scenario cohesion. These results suggest that evolving a product line specification using MSVCM requires only localized changes. On the other hand, the results of six experiments reveal that MSVCM requires more time to derive the product line specifications and, contrasting with the modularity results, reduces the time to evolve a product line specification only when the subjects have been well trained and are used to the task of evolving product line specifications.

Variant-rich software systems offer a large degree of customization, allowing users to configure the target system according to their preferences and needs. Facing high degrees of variability, these systems often employ variability models to explicitly capture user-configurable features (e.g., systems options) and the constraints they impose. The explicit representation of features allows them to be referenced in different variation points across different artifacts, enabling the latter to vary according to specific feature selections. In such settings, the evolution of variability models interplays with the evolution of related artifacts, requiring the two to evolve together, or coevolve. Interestingly, little is known about how such coevolution occurs in real-world systems, as existing research has focused mostly on variability evolution as it happens in variability models only. Furthermore, existing techniques supporting variability evolution are usually validated with randomly-generated variability models or evolution scenarios that do not stem from practice. As the community lacks a deep understanding of how variability evolution occurs in real-world systems and how it relates to the evolution of different kinds of software artifacts, it is not surprising that industry reports existing tools and solutions ineffective, as they do not handle the complexity found in practice. Attempting to mitigate this overall lack of knowledge and to support tool builders with insights on how variability models coevolve with other artifact types, we study a large and complex real-world variant-rich software system: the Linux kernel. Specifically, we extract variability-coevolution patterns capturing changes in the variability model of the Linux kernel with subsequent changes in Makefiles and C source code. From the analysis of the patterns, we report on findings concerning evolution principles found in the kernel, and we reveal deficiencies in existing tools and theory when handling changes captured by our patterns.

The optimization of software to be (more) energy efficient is becoming a major concern for the software industry. Although several techniques have been presented to measure energy consumption for software, none has addressed software product lines (SPLs). Thus, to measure energy consumption of a SPL, the products must be generated and measured individually, which is too costly.In this paper, we present a technique and a prototype tool to statically estimate the worst case energy consumption for SPL. The goal is to provide developers with techniques and tools to reason about the energy consumption of all products in a SPL, without having to produce, run and measure the energy in all of them.Our technique combines static program analysis techniques and worst case execution time prediction with energy consumption analysis. This technique analyzes all products in a feature-sensitive manner, that is, a feature used in several products is analyzed only once, while the energy consumption is estimated once per product.We implemented our technique in a tool called Serapis. We did a preliminary evaluation using a product line for image processing implemented in C. Our experiments considered 7 products from such line and our initial results show that the tool was able to estimate the worst-case energy consumption with a mean error percentage of 9.4% and standard deviation of 6.2% when compared with the energy measured when running the products.

Non-Hodgkin and Hodgkin lymphomas frequently involve many structures in the abdomen and pelvis. Extranodal disease is more common with Non-Hodgkin’s lymphoma than with Hodgkin's lymphoma. Though it may be part of a systemic lymphoma, single onset of nodal lymphoma is not rare. Extranodal lymphoma has been described in virtually every organ and tissue. In decreasing order of frequency, the spleen, liver, gastrointestinal tract, pancreas, abdominal wall, genitourinary tract, adrenal, peritoneal cavity, and biliary tract are involved. The purpose of this review is to discuss and illustrate the spectrum of appearances of nodal and extranodal lymphomas, including AIDS-related lymphomas, in the abdominopelvic region using a multimodality approach, especially cross-sectional imaging techniques. The most common radiologic patterns of involvement are illustrated. Familiarity with the imaging manifestations that are diagnostically specific for lymphoma is important because imaging plays an important role in the noninvasive management of disease.

A software product line (SPL) encodes a potentially large variety of software products as variants of some common code base. Up until now, re-using traditional static analyses for SPLs was virtually intractable, as it required programmers to generate and analyze all products individually. In this work, however, we show how an important class of existing inter-procedural static analyses can be transparently lifted to SPLs. Without requiring programmers to change a single line of code, our approach SPLLIFT automatically converts any analysis formulated for traditional programs within the popular IFDS framework for inter-procedural, finite, distributive, subset problems to an SPL-aware analysis formulated in the IDE framework, a well-known extension to IFDS. Using a full implementation based on Heros, Soot, CIDE and JavaBDD, we show that with SPLLIFT one can reuse IFDS-based analyses without changing a single line of code. Through experiments using three static analyses applied to four Java-based product lines, we were able to show that our approach produces correct results and outperforms the traditional approach by several orders of magnitude.

Mistakes made when implementing or specifying the models of a Software Product Line (SPL) can result in ill-formed products - the safe composition problem. Such problem can hinder productivity and it might be hard to detect, since SPLs can have thousands of products. In this article, we propose a language independent approach for verifying safe composition of SPLs with dedicated Configuration Knowledge models. We translate feature model and Configuration Knowledge into propositional logic and use the Alloy Analyzer to perform the verification. To provide evidence for the generality of our approach, we instantiate this approach in different compositional settings. We deal with different kinds of assets such as use case scenarios and Eclipse RCP components. We analyze both the code and the requirements for a larger scale SPL, finding problems that affect thousands of products in minutes. Moreover, our evaluation suggests that the analysis time grows linearly with respect to the number of products in the analyzed SPLs.

Texto completo. Acesso restrito. p. 905-933 Submitted by Santiago Fabio (fabio.ssantiago@hotmail.com) on 2013-06-17T14:56:46Z No. of bitstreams: 1 5555555555555.pdf: 2051198 bytes, checksum: e608df6a58cf62557b1b28f9f9fc890d (MD5) Made available in DSpace on 2013-06-17T14:56:46Z (GMT). No. of bitstreams: 1 5555555555555.pdf: 2051198 bytes, checksum: e608df6a58cf62557b1b28f9f9fc890d (MD5) Previous issue date: 2013 Background: Aspect-Oriented Software Development (AOSD) is a paradigm that promotes advanced separation of concerns and modularity throughout the software development lifecycle, with a distinctive emphasis on modular structures that cut across traditional abstraction boundaries. In the last 15 years, research on AOSD has boosted around the world. The AOSD-BR research community (AOSD-BR stands for AOSD in Brazil) emerged in the last decade, and has provided different contributions in a variety of topics. However, despite some evidence in terms of the number and quality of its outcomes, there is no organized characterization of the AOSD-BR community that positions it against the international AOSD Research community and the Software Engineering Research community in Brazil. Aims: In this paper, our main goal is to characterize the AOSD-BR community with respect to the research developed in the last decade, confronting it with the AOSD international community and the Brazilian Software Engineering community. Method: Data collection, validation and analysis were performed in collaboration with several researchers of the AOSD-BR community. The characterization was presented from three different perspectives: (i) a historical timeline of events and main milestones achieved by the community; (ii) an overview of the research developed by the community, in terms of key challenges, open issues and related work; and (iii) an analysis on the impact of the AOSD-BR community outcomes in terms of well-known indicators, such as number of papers and number of citations. Results: Our analysis showed that the AOSD-BR community has impacted both the international AOSD Research community and the Software Engineering Research community in Brazil. Salvador

Software Product Lines can improve productivity and product quality, but product line maintenance is not simple, since a single change can impact several products. In many situations, it is desirable to provide some assurance that we can safely change a SPL in the sense that the behaviour of existing products is preserved. Developers can rely on previously proposed safe evolution notions, by means of transformation templates to ensure safe evolution. However, the existing templates were only applied in scenarios where a product line expands, and have not been evaluated in the context of extracting features from existing code. Therefore, we conducted a study using an industrial system developed in Java with 400 KLOC. This study revealed the need for new templates to address feature extraction scenarios, as well as improving the existing templates notation to address more expressive mappings between features and code assets. As a result of this study, we successfully extracted a product line from this existing system using the proposed templates, and also found evidence that the new templates can help to prevent defects during product line evolution.

The purpose of this study was to describe the brain magnetic resonance imaging (MRI) findings in young patients with hepatosplenic schistosomiasis mansoni without overt neurologic manifestations. This study included 34 young persons (age range = 9–25 years) with hepatosplenic schistosomiasis mansoni who had been previously treated. Patients were scanned on a 1.5-T system that included multiplanar pre-contrast and post-contrast sequences, and reports were completed by two radiologists after a consensus review. Twenty (58.8%) patients had MRI signal changes that were believed to be related to schistosomiasis mansoni. Twelve of the 20 patients had small focal hyperintensities on T2WI in the cerebral white matter, and eight patients had symmetric hyperintense basal ganglia on T1WI. There was a high frequency of brain MRI signal abnormalities in this series. Although not specific, these findings may be related to schistosomiasis.

A component-based decomposition can result in implementations having use cases code tangled with other concerns and scattered across components. Modularity mechanisms such as aspects, mixins, and virtual classes have been proposed to address this kind of problem. One can use such mechanisms to group together code related to a single use case. This paper quantitatively analyzes the impact of this kind of use case modularization. We apply one specific technique, aspect oriented programming, to modularize the use case implementations of two information systems that conform to the layered architecture pattern. We extract traditional and contemporary metrics - including cohesion, coupling, and separation of concerns - to analyze modularity in terms of quality attributes such as changeability, support for independent development, and pluggability. Our findings indicate that the results of a given modularity analysis depend on other factors beyond the chosen system, metrics, and the applied modularity technique.

The educational objectives of this self-assessment module are for the participants to exercise, self-assess, and improve their understanding of the most important features of gossypibomas and the role of imaging in the diagnosis of these masses.

Objective Textiloma and gossypiboma are terms used to describe a mass of cotton matrix that is left behind in a body cavity during an operation. This is an uncommon surgical complication. Gossypibomas are most frequently discovered in the abdomen. Such foreign bodies can often mimic tumors or abscesses clinically or radiologically; however, they are rarely reported because of the medicolegal implications. The manifestations and complications of gossypibomas are so variable that diagnosis is difficult and patient morbidity is significant. Conclusion This article discusses the clinical manifestations, pathophysiologic aspects, and most important complications related to gossypibomas; presents the classic imaging features of gossypibomas using a multitechnique approach; and shows some of the typical and atypical sites of gossypibomas.

Refactorings are usually proposed in an ad hoc way because it is difficult to prove that they are sound with respect to a formal semantics, not guaranteeing the absence of type errors or semantic changes. Consequently, developers using refactoring tools must rely on compilation and tests to ensure type-correctness and semantics preservation, respectively, which may not be satisfactory to critical software development. In this paper, we formalize a static semantics for Alloy, which is a formal object-oriented modeling language, and encode it in Prototype Verification System (PVS). The static semantics' formalization can be useful for specifying and proving that transformations in general (not only refactorings) do not introduce type errors, for instance, as we show here.

Context: To reduce the integration effort arising from conflicting changes resulting from collaborative software development tasks, unstructured merge tools try to automatically solve part of the conflicts via textual similarity, whereas structured and semistructured merge tools try to go further by exploiting the syntactic structure of the involved artifacts. Objective: In this study, aiming at increasing the existing body of evidence and assessing results for systems developed under an alternative version control paradigm, we replicate an experiment conducted by Apel et al. to compare the unstructured and semistructured approach with respect to the occurrence of conflicts reported by both approaches. Method: We used both semistructured and unstructured merge in a sample 2.5 times bigger than the original study regarding the number of projects and 18 times bigger regarding the number of merge scenarios, and we compared the occurrence of conflicts. Results: Similar to the original study, we observed that semistructured merge reduces the number of conflicts in 55% of the scenarios of the new sample. However, the observed average conflict reduction of 62% in these scenarios is far superior than what has been observed before. We also bring new evidence that the use of semistructured merge can reduce the occurrence of conflicting merge scenarios by half. Conclusions: Our findings reinforce the benefits of exploiting the syntactic structure of the artifacts involved in code integration. Besides, the reductions observed in the number and size of conflicts suggest that the use of semistructured merge, when compared to the unstructured approach, might decrease integration effort without compromising correctness.

A product line is often developed in the context of a set of related product lines. When supporting separate feature development, we might have product populations, with product line versions being simultaneously developed in different branches. Multi product lines involve a number of product lines that depend on each other. A product line refinement notion formalizes safe evolution, but this is not sufficient for reasoning over sets of product lines. We propose refinement notions and compositionality properties that help to explain how we can support modular development in these contexts. Thus, we formally define the foundations for safe and modular evolution of product populations and multi product lines, enabling developers to perform changes in a systematic manner.

We present algebraic laws for a language similar to a subset of sequential Java that includes inheritance, recursive classes, dynamic binding, access control, type tests and casts, assignment, but no sharing. These laws are proved sound with respect to a weakest precondition semantics. We also show that they are complete in the sense that they are sufficient to reduce an arbitrary program to a normal form substantially close to an imperative program; the remaining object-oriented constructs could be further eliminated if our language had recursive records. This suggests that our laws are expressive enough to formally derive behaviour preserving program transformations; we illustrate that through the derivation of provably-correct refactorings.

This paper proposes modeling laws for Alloy, a formal object-oriented modeling language. These laws are important not only to define the axiomatic semantics of Alloy but also to guide and formalize popular software development practices. In particular, these laws can be used to formaly refactor specifications. As an example, we formally refactor a specification for Java types.

The purpose of this study was to validate diffusion-weighted magnetic resonance imaging in the prediction of the evolutive course of brain edema and to establish its pathophysiologic presence in patients with eclampsia/severe preeclampsia.Seventeen patients with a clinical diagnosis of severe eclampsia/preeclampsia and T2 hyperintense brain lesions on routine magnetic resonance imaging were evaluated at hospital admission and 8 weeks later.Brain edema was reversible in 13 patients and irreversible in 4 patients, as indicated on follow-up magnetic resonance imaging. Sixteen of 17 patients were differentiated accurately into reversible and irreversible groups on the basis of diffusion imaging on hospital admission. Diffusion-weighted magnetic resonance imaging demonstrated a significant increase in water mobility in abnormal regions compared with normal-appearing brains in patients in the reversible group (1.34+/-0.10 mm(2) vs 0.79+/-0.08 mm(2)/s x 10(-3), P.001). In the irreversible group, restricted water diffusion was present, which was consistent with cytotoxic edema and early brain infarction in 3 of 4 patients.Diffusion-weighted magnetic resonance imaging can predict successfully the evolutive course of brain edema in an acute setting in these patients. Our findings indicate that brain edema is vasogenic, although ischemic/cytotoxic edema was observed less commonly.

This paper reports our experience using AspectJ, a general-purpose aspect-oriented extension to Java, to implement distribution and persistence aspects in a web-based information system. This system was originally implemented in Java and restructured with AspectJ. Our main contribution is to show that AspectJ is useful for implementing several persistence and distribution concerns in the application considered, and other similar applications. We have also identified a few drawbacks in the language and suggest some minor modifications that could significantly improve similar implementations. Despite the drawbacks, we argue that the AspectJ implementation is superior to the pure Java implementation. Some of the aspects implemented in our experiment are abstract and constitute a simple aspect framework. The other aspects are application specific but we suggest that different implementations might follow the same aspect pattern. The framework and the pattern allow us to propose architecture-specific guidelines that provide practical advice for both restructuring and implementing certain kinds of persistent and distributed applications with AspectJ.

International audience; Software product lines (SPL) provide support for productivity gains through systematic reuse. Among the various quality attributes supporting these goals, modularity, stability and expressiveness of feature specifications, their composition and configuration knowledge emerge as strategic values in modern software development paradigms. This paper presents a metric-based evaluation aiming at assessing how well the chosen qualities are supported by scenario-based SPL requirements approaches. The selected approaches for this study span from type of notation (textual or graphical based), style to support variability (annotation or composition based), and specification expressiveness. They are compared using the metrics developed in a set of releases from an exemplar case study. Our major findings indicate that composition-based approaches have greater potential to support modularity and stability, and that quantification mechanisms simplify and increase expressiveness of configuration knowledge and composition specifications.

Hydrometrocolpos is a rare congenital disorder consisting of cystic dilation of the vagina and uterus and accumulation of mucus secretions resulting from genital tract obstruction.1 The obstruction can be produced by imperforate hymen, transverse vaginal membrane, or some degree of vaginal atresia.2 Excessive intrauterine stimulation of the cervical mucus glands by circulating maternal estrogens produces the accumulated fluid.1,3 This was first described by Godfroy in 1856.1,4,5 Only sporadic cases were reported until 1940, when Mahoney and Chamberlain presented their definitive descriptions of the condition. Since then 200 cases have been presented or reviewed in the literature.1,5 Hydrocolpos or hydrometrocolpos commonly first appears either in the neonatal period or at menarche.5 This report describes the antenatal sonographic detection of a cystic pelvic mass subsequently proved to be hydrocolpos in a fetus with ambiguous genitalia and uterovaginal duplication. Few reports on the prenatal diagnosis of hydrometrocolpos by ultrasonography have been published. Davis and coworkers were the first to describe the antenatal sonographic diagnosis of hydrometrocolpos caused by an imperforate hymen.5 Hill and Hirsch reported an additional case of fetal hydrocolpos,3 also caused by imperforate hymen, detected by sonography,1 and Russ and colleagues described a case of hydrometrocolpos occurring with uterus didelphys and septate vagina detected in utero.4 Our case is notable for the association of fetal ascites and uterovaginal duplication in a patient with persistent urogenital sinus.

In this chapter we discuss several previous work on topics like interfaces for non-annotative approaches (such as aspect-oriented programming), separation of concerns and modularity, analyses on preprocessor-based systems, and dataflow analysis. Besides discussing, we compare these works to our approach, pointing out the differences between them.

In this chapter we review essential concepts we explore in this work. Firstly, we review software families and software product lines, since the problem we address here is critical in these contexts. We show the basic concepts and then move towards conditional compilation with preprocessors, a widely used mechanism to implement features in industrial practice. Despite the widespread usage, conditional compilation has several drawbacks. We then present the Virtual Separation of Concerns (VSoC) approach, which can minimize some of these drawbacks. In this work, we intend to address the lack of feature modularity. Thus, we need to catch dependencies between features and inform developers about them. To do so, we rely on dataflow analyses, the last topic we review in this chapter.

In Software Product Lines (SPL), we can bind reusable features to compose a product at different times, which in general are static or dynamic. The former allows customizability without any overhead at runtime. On the other hand, the latter allows feature activation or deactivation while running the application with the cost of performance and memory consumption. To implement features, we might use aspect-oriented programming (AOP), in which aspects enable a clear separation between base code and variable code. In this context, recent work provides AspectJ-based idioms to implement flexible feature binding. However, we identified some design deficiencies. Thus, to solve the issues of these idioms, we incrementally create three new AspectJ-based idioms. Moreover, to evaluate our new idioms, we quantitatively analyze them with respect to code cloning, scattering, tangling, and size by means of software metrics. Besides that, we qualitatively discuss our new idioms in terms of code reusability, changeability, and instrumentation overhead.

Preprocessors are often used to implement the variability of a Software Product Line (SPL). Despite their widespread use, they have several drawbacks like code pollution, no separation of concerns, and error-prone. Virtual Separationof Concerns (VSoC) has been used to address some of thesepreprocessor problems by allowing developers to hide featurecode not relevant to the current maintenance task. However, different features eventually share the same variables and methods, so VSoC does not modularize features, since developers do not know anything about hidden features. Thus, the maintenance of one feature might break another. Emergent Interfaces (EI) capture dependencies between a feature maintenance point and parts of other feature implementation, but they do not provide an overall feature interface considering all parts in an integrated way. Thus, we still have the feature modularization problem. To address that, we propose Emergent Feature Interfaces (EFI) that complement EI by treating feature as a module in order to improve modular reasoning on preprocessor-based systems. EFI capture dependencies among entire features, with the potential of improving productivity. Our proposal, implemented in an opensource tool called Emergo, is evaluated with preprocessor-based systems. The results of our study suggest the feasibility and usefulness of the proposed approach.

Variability-aware systems are subject to the coevolution of variability models and related artifacts. Surprisingly, little knowledge exists to understand such coevolution in practice. This shortage is directly reflected in existing approaches and tools for variability management, as they fail to provide effective support for such a coevolution. To understand how variability models and related artifacts coevolve in a large and complex real-world variability-aware system, we inspect over 500 Linux kernel commits spanning almost four years of development. We collect a catalog of evolution patterns, capturing the coevolution of the Linux kernel variability model, Makefiles, and C source code. Further, we extract general findings to guide further research and tool development.

Aspect-oriented programming (AOP) is a popular technique for modularizing crosscutting concerns. However, constructs aimed at supporting crosscutting modularity may break class modularity. For example, to understand a method call may require a whole-program analysis to determine what advice applies and what that advice does. Moreover, in AspectJ, advice is coupled to the parts of the program advised, the base code, so the meaning of advice may change when the base code changes. Such coupling also hinders parallel development between base code and aspects. We propose some simple modifications to the design of crosscut programming interfaces (XPIs) to include expressive design rule specifications. We call our form of XPIs crosscutting programming interfaces with design rules (XPIDRs). The XPIDR-based approach, by design, supports modular runtime checking and parallel development by decoupling aspects from base code. We also show how XPIDRs allow specification of interesting control flow effects, such as when advice does (or does not) proceed. We have implemented XPIDRs as a simple contract extension to AspectJ. Since XPIDRs do not require any new AspectJ constructs, they can be adopted easily by the AspectJ community.

This paper presents a process-oriented model-driven approach that supports the conduction of controlled experiments in software engineering. The approach consists of: (i) a domain specific language (DSL) for process specification and statistical design of controlled experiments; (ii) model-driven transformations that allow workflow models generations specific to each experiment participant and according to the experiment statistical design; and (iii) a workflow execution environment that allows the monitoring of participant activities in the experiment, besides gathering participants feedback from the experiment. The paper also presents the results of an exploratory study that analyzes the feasibility of the approach and the expressivity of the DSLs in the modeling of a non-trivial software engineering experiment.

Developers evolve software product lines (SPLs) manually or using typical program refactoring tools. However, when evolving a product line to introduce new features or to improve its design, it is important to make sure that the behavior of existing products is not affected. Typical program refactorings cannot guarantee that because the SPL context goes beyond code and other kinds of core assets, and involves additional artifacts such as feature models and configuration knowledge. Besides that, in a SPL we typically have to deal with a set of possibly alternative assets that do not constitute a well-formed program. As a result, manual changes and existing program refactoring tools may introduce behavioral changes or invalidate existing product configurations. To avoid that, we propose approaches and implement tools for making product line evolution safer; these tools check whether SPL transformations are refinements in the sense that they preserve the behavior of the original SPL products. They implement different and practical approximations of a formal definition of SPL refinement. We evaluate the approaches in concrete SPL evolution scenarios where existing product's behavior must be preserved. However, our tools found that some transformations introduced behavioral changes. Moreover, we evaluate defective refinements, and the toolset detects the behavioral changes.

SPL testing has been considered a challenging task,mainly due to the diversity of products that might be generatedfrom an SPL. To deal with this problem, some techniques for derivingproduct specific functional test cases have been proposed.However, this research area still lacks empirical studies showingthe benefits of using such techniques. This paper presents a studythat empirically compares two different black-box manual testdesign techniques: a generic technique that we have observed inan industrial test execution environment and a product specifictechnique whose functional test cases could be derived using anySPL technique that considers variations in functional tests. Weevaluated their impact from the point of view of the test execution process, achieving results that indicate that executing product specific test cases is faster and generates fewer errors.

When maintaining a feature in preprocessor-based Software Product Lines (SPLs), developers are susceptible to introduce problems into other features. This is possible because features eventually share elements (like variables and methods) with the maintained one. This scenario might be even worse when hiding features by using techniques like Virtual Separation of Concerns (VSoC), since developers cannot see the feature dependencies and, consequently, they become unaware of them. Emergent Interfaces was proposed to minimize this problem by capturing feature dependencies and then providing information about other features that can be impacted during a maintenance task. In this paper, we present Emergo, a tool capable of computing emergent interfaces between the feature we are maintaining and the others. Emergo relies on feature-sensitive dataflow analyses in the sense it takes features and the SPL feature model into consideration when computing the interfaces.

Software product lines (SPLs) are commonly developed using annotative approaches such as conditional compilation that come with an inherent risk of constructing erroneous products. For this reason, it is essential to be able to analyze SPLs. However, as dataflow analysis techniques are not able to deal with SPLs, developers must generate and analyze all valid methods individually, which is expensive for non-trivial SPLs. In this paper, we demonstrate how to take any standard intraprocedural dataflow analysis and automatically turn it into a feature-sensitive dataflow analysis in three different ways. All are capable of analyzing all valid methods of an SPL without having to generate all of them explicitly. We have implemented all analyses as extensions of SOOT's intraprocedural dataflow analysis framework and experimentally evaluated their performance and memory characteristics on four qualitatively different SPLs. The results indicate that the feature-sensitive analyses are on average 5.6 times faster than the brute force approach on our SPLs, and that they have different time and space tradeoffs.

During Software Product Line (SPL) maintenance tasks, Virtual Separation of Concerns (VSoC) allows the programmer to focus on one feature and hide the others. However, since features depend on each other through variables and control-flow, feature modularization is compromised since the maintenance of one feature may break another. In this context, emergent interfaces can capture dependencies between the feature we are maintaining and the others, making developers aware of dependencies. To better understand the impact of code level feature dependencies during SPL maintenance, we have investigated the following two questions: how often methods with preprocessor directives contain feature dependencies? How feature dependencies impact maintenance effort when using VSoC and emergent interfaces? Answering the former is important for assessing how often we may face feature dependency problems. Answering the latter is important to better understand to what extent emergent interfaces complement VSoC during maintenance tasks. To answer them, we analyze 43 SPLs of different domains, size, and languages. The data we collect from them complement previous work on preprocessor usage. They reveal that the feature dependencies we consider in this paper are reasonably common in practice; and that emergent interfaces can reduce maintenance effort during the SPL maintenance tasks we regard here.

The adoption of a product line strategy can bring significant productivity and time to market improvements. However, evolving a product line is risky because it might impact many products and their users. So when evolving a product line to introduce new features or to improve its design, it is important to make sure that the behavior of existing products is not affected. In fact, to preserve the behavior of existing products one usually has to analyze different artifacts, like feature models, configuration knowledge and the product line core assets. To better understand this process, in this paper we discover and analyze concrete product line evolution scenarios and, based on the results of this study, we describe a number of safe evolution templates that developers can use when working with product lines. For each template, we show examples of their use in existing product lines. We evaluate the templates by also analyzing the evolution history of two different product lines and demonstrating that they can express the corresponding modifications and then help to avoid the mistakes that we identified during our analysis.

This chapter introduces an extension of the Rational Unified Process (RUP) with a method that supports the progressive, and separate, implementation of three different aspects: persistence, distribution, and concurrence control. This complements RUP with a specific implementation method, called Progressive Implementation Method (Pim), and helps to tame the complexity of applications that are persistent, distributed, and concurrent. By gradually and separately implementing, testing, and validating such applications, we obtain two major benefits: the impact caused by the requirements changes during development is reduced and testing and debugging are simplified. In addition, the authors hope to contribute to solving the lack of a specific implementation method in RUP.

Maintainability of a software product line depends on the possibility to modularize its variations, often expressed in terms of optionally selected features. Conventional modularization techniques bind variations either statically or dynamically, but ideally it should be possible to flexibly choose between both. In this paper, we propose improved solutions for modularizing and flexibly binding varying features in form of idioms in aspect-oriented languages AspectJ and CaesarJ. We evaluate the idioms qualitatively by discussing their advantages and deficiencies and quantitatively by means of metrics.

Although software product lines (PLs) can bring significant productivity and quality improvements through strategic reuse, bootstrapping existing products into a PL, and extending a PL with more products, is often risky and expensive. These kinds of PL derivation and evolution might require substantial effort and can easily affect the behavior of existing products. To reduce these problems, we propose a notion of product line refactoring and associated transformation templates that should be part of a PL refactoring catalogue. We discuss how the notion guides and improves safety of the PL derivation and evolution processes; the transformation templates, particularly when automated, reduce the effort needed to perform these processes.