Search

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.

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.

Context: It is common to consider Alloy signatures or UML classes as data types that have a canonical fixed interpretation: the elements of the type correspond to terms recursively generated by the type constructors. However, these language constructs resemble data types but, strictly, they are not. Objective: In this article, we propose an idiom to specify data types in Alloy. Method: We compare our approach to others in the context of checking data refinement using the Alloy Analyzer tool. Results: Some previous studies do not include the generation axiom and may perform unsound analysis. Other studies recommend some optimizations to overcome a limitation in the Alloy Analyzer tool. Conclusion: The problem is not related to the tool but the way data types must be represented in Alloy. This study shows the importance of using automated analyses to test translation between different language constructs.

Context: Maintaining software families is not a trivial task. Developers commonly introduce bugs when they do not consider existing dependencies among features. When such implementations share program elements, such as variables and functions, inadvertently using these elements may result in bugs. In this context, previous work focuses only on the occurrence of intraprocedural dependencies, that is, when features share program elements within a function. But at the same time, we still lack studies investigating dependencies that transcend the boundaries of a function, since these cases might cause bugs as well.Objective: This work assesses to what extent feature dependencies exist in actual software families, answering research questions regarding the occurrence of intraprocedural, global, and interprocedural dependencies and their characteristics.Method: We perform an empirical study covering 40 software families of different domains and sizes. We use a variability-aware parser to analyze families source code while retaining all variability information.Results: Intraprocedural and interprocedural feature dependencies are common in the families we analyze: more than half of functions with preprocessor directives have intraprocedural dependencies, while over a quarter of all functions have interprocedural dependencies. The median depth of interprocedural dependencies is 9.Conclusion: Given these dependencies are rather common, there is a need for tools and techniques to raise developers awareness in order to minimize or avoid problems when maintaining code in the presence of such dependencies. Problems regarding interprocedural dependencies with high depths might be harder to detect and fix.

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.

Currently most developers have to apply manual steps and use test suites to improve confidence that transformations applied to object-oriented (OO) and aspect-oriented (AO) programs are correct. However, it is not simple to do manual reasoning, due to the nontrivial semantics of OO and AO languages. Moreover, most refactoring implementations contain a number of bugs since it is difficult to establish all conditions required for a transformation to be behavior preserving. In this article, we propose a tool (SafeRefactorImpact) that analyzes the transformation and generates tests only for the methods impacted by a transformation identified by our change impact analyzer (Safira). We compare SafeRefactorImpact with our previous tool (SafeRefactor) with respect to correctness, performance, number of methods passed to the automatic test suite generator, change coverage, and number of relevant tests generated in 45 transformations. SafeRefactorImpact identifies behavioral changes undetected by SafeRefactor. Moreover, it reduces the number of methods passed to the test suite generator. Finally, SafeRefactorImpact has a better change coverage in larger subjects, and generates more relevant tests than SafeRefactor.

HighlightsWe present a design rule specification language for aspect-oriented systems.We explore its benefits to supporting the modular development of classes and aspects.We discuss how our language improves crosscutting modularity without breaking class modularity.We present a Compiler for LSD and AspectJ (COLA), a tool to automate design rules checking.We evaluate it using a real case study and compare it with other approaches. Aspect-oriented programming is known as a technique for modularizing crosscutting concerns. However, constructs aimed to support crosscutting modularity might actually break class modularity. As a consequence, class developers face changeability, parallel development and comprehensibility problems, because they must be aware of aspects whenever they develop or maintain a class. At the same time, aspects are vulnerable to changes in classes, since there is no contract specifying the points of interaction amongst these elements. These problems can be mitigated by using adequate design rules between classes and aspects. We present a design rule specification language and explore its benefits since the initial phases of the development process, specially with the aim of supporting modular development of classes and aspects. We discuss how our language improves crosscutting modularity without breaking class modularity. We evaluate it using a real case study and compare it with other approaches.

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

To safely evolve a software product line, it is important to have a notion of product line refinement that assures behavior preservation of the original product line products. So in this article we present a language independent theory of product line refinement, establishing refinement properties that justify stepwise and compositional product line evolution. Moreover, we instantiate our theory with the formalization of specific languages for typical product lines artifacts, and then introduce and prove soundness of a number of associated product line refinement transformation templates. These templates can be used to reason about specific product lines and as a basis to derive comprehensive product line refinement catalogues.

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.

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.

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.

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.

Equivalence notions for object models are usually too concrete in the sense that they assume that the compared models are formed by elements with the same names. This is not adequate in several situations: during model refactoring, when using auxiliary model elements, or when the compared models comprise distinct but corresponding elements. So, in this paper, we propose a more abstract and language-independent equivalence notion for object models. It supports, as desired, abstraction from names and elements when comparing models. We use the PVS system to specify and prove properties of our notion. It is illustrated here by comparing simple models in Alloy, a formal object-oriented modeling language, but has also been applied for deriving a comprehensive set of algebraic laws for Alloy.