9,618 research outputs found
Recovering Architectural Variability of a Family of Product Variants
A Software Product Line (SPL) aims at applying a pre-planned systematic reuse
of large-grained software artifacts to increase the software productivity and
reduce the development cost. The idea of SPL is to analyze the business domain
of a family of products to identify the common and the variable parts between
the products. However, it is common for companies to develop, in an ad-hoc
manner (e.g. clone and own), a set of products that share common
functionalities and differ in terms of others. Thus, many recent research
contributions are proposed to re-engineer existing product variants to a SPL.
Nevertheless, these contributions are mostly focused on managing the
variability at the requirement level. Very few contributions address the
variability at the architectural level despite its major importance. Starting
from this observation, we propose, in this paper, an approach to reverse
engineer the architecture of a set of product variants. Our goal is to identify
the variability and dependencies among architectural-element variants at the
architectural level. Our work relies on Formal Concept Analysis (FCA) to
analyze the variability. To validate the proposed approach, we experimented on
two families of open-source product variants; Mobile Media and Health Watcher.
The results show that our approach is able to identify the architectural
variability and the dependencies
Identifying Components from Object-Oriented APIs Based on Dynamic Analysis
The reuse at the component level is generally more effective than the one at
the object-oriented class level. This is due to the granularity level where
components expose their functionalities at an abstract level compared to the
fine-grained object-oriented classes. Moreover, components clearly define their
dependencies through their provided and required interfaces in an explicit way
that facilitates the understanding of how to reuse these components. Therefore,
several component identification approaches have been proposed to identify
components based on the analysis object-oriented software applications.
Nevertheless, most of the existing component identification approaches did not
consider co-usage dependencies between API classes to identify classes/methods
that can be reused to implement a specific scenario. In this paper, we propose
an approach to identify reusable software components in object-oriented APIs,
based on the interactions between client applications and the targeted API. As
we are dealing with actual clients using the API, dynamic analysis allows to
better capture the instances of API usage. Approaches using static analysis are
usually limited by the difficulty of handling dynamic features such as
polymorphism and class loading. We evaluate our approach by applying it to
three Java APIs with eight client applications from the DaCapo benchmark.
DaCapo provides a set of pre-defined usage scenarios. The results show that our
component identification approach has a very high precision.Comment: 11 pages, 5 figure
Object linking in repositories
This topic is covered in three sections. The first section explores some of the architectural ramifications of extending the Eichmann/Atkins lattice-based classification scheme to encompass the assets of the full life cycle of software development. A model is considered that provides explicit links between objects in addition to the edges connecting classification vertices in the standard lattice. The second section gives a description of the efforts to implement the repository architecture using a commercially available object-oriented database management system. Some of the features of this implementation are described, and some of the next steps to be taken to produce a working prototype of the repository are pointed out. In the final section, it is argued that design and instantiation of reusable components have competing criteria (design-for-reuse strives for generality, design-with-reuse strives for specificity) and that providing mechanisms for each can be complementary rather than antagonistic. In particular, it is demonstrated how program slicing techniques can be applied to customization of reusable components
FixMiner: Mining Relevant Fix Patterns for Automated Program Repair
Patching is a common activity in software development. It is generally
performed on a source code base to address bugs or add new functionalities. In
this context, given the recurrence of bugs across projects, the associated
similar patches can be leveraged to extract generic fix actions. While the
literature includes various approaches leveraging similarity among patches to
guide program repair, these approaches often do not yield fix patterns that are
tractable and reusable as actionable input to APR systems. In this paper, we
propose a systematic and automated approach to mining relevant and actionable
fix patterns based on an iterative clustering strategy applied to atomic
changes within patches. The goal of FixMiner is thus to infer separate and
reusable fix patterns that can be leveraged in other patch generation systems.
Our technique, FixMiner, leverages Rich Edit Script which is a specialized tree
structure of the edit scripts that captures the AST-level context of the code
changes. FixMiner uses different tree representations of Rich Edit Scripts for
each round of clustering to identify similar changes. These are abstract syntax
trees, edit actions trees, and code context trees. We have evaluated FixMiner
on thousands of software patches collected from open source projects.
Preliminary results show that we are able to mine accurate patterns,
efficiently exploiting change information in Rich Edit Scripts. We further
integrated the mined patterns to an automated program repair prototype,
PARFixMiner, with which we are able to correctly fix 26 bugs of the Defects4J
benchmark. Beyond this quantitative performance, we show that the mined fix
patterns are sufficiently relevant to produce patches with a high probability
of correctness: 81% of PARFixMiner's generated plausible patches are correct.Comment: 31 pages, 11 figure
- …