Comparison-Based Feature Location in ArgoUML Variants

Software companies need to provide a large set of features satisfying functional and non-functional requirements of diverse customers, thereby leading to variability in space. Feature location techniques have been proposed to support software maintenance and evolution in space. However, so far only one feature location technique also analyses the evolution in time of system variants, which is required for feature enhancements and bug fixing. Specifically, existing tools for managing a set of systems over time do not offer proper support for keeping track of feature revisions, updating existing variants, and creating new product configurations based on feature revisions. This paper presents four challenges concerning such capabilities for feature (revision) location and composition of new product configurations based on feature/s (revisions). We also provide a benchmark containing a ground truth and support for computing metrics. We hope that this will motivate researchers to provide and evaluate tool-supported approaches aiming at managing systems evolving in space and time. Further, we do not limit the evaluation of techniques to only this benchmark: we introduce and provide instructions on how to use a benchmark extractor for generating ground truth data for other systems. We expect that the feature (revision) location techniques maximize information retrieval in terms of precision, recall, and F-score, while keeping execution time and memory consumption low.

Software Product Lines (SPL) adoption can affect several aspects of an organization and it involves significant investment and risk. This way, SPL risk management is a crucial activity of SPL adoption. This study aims to identify SPL risks during the scoping and requirement disciplines to provide information to better understand risk management in SPL. In order to achieve the previous stated goal, a case study research was applied in an industrial project in the medical information management domain. Using the captured risks, a classification scheme was built and risk mitigation strategies were identified. We spent five months, totaling 79 hours, performing risk management (RM) in the scoping discipline and twelve months, totaling 148 hours, performing RM on the requirements discipline. We identified 32 risks during the scoping discipline and 20 risks during the requirements discipline, 14 risks occurred in both disciplines. Some identified risks are not particular to SPL development, however, they have their impact increased due to the SPL characteristic. All the study results and lessons learned are useful for all project managers and researchers who are considering the introduction of SPL risk management in industry or academia.

Feature Location (FL) aims to locate observable functionalities in source code. Considering its key role in software maintenance, a vast array of automated and semi-automated Feature Location Techniques (FLTs) have been proposed. To compare FLTs, an open, standard set of non-subjective, reproducible “compare-to” FLT techniques (baseline techniques) should be used for evaluation. In order to relate the performance of FLTs compared against different baseline techniques, these compare-to techniques should be evaluated against each other. But evaluation across FLTs is confounded by empirical designs that incorporate different FL goals and evaluation criteria. This paper moves towards standardizing FLT comparability by assessing eight baseline techniques in an empirical design that addresses these confounding factors. These baseline techniques are assessed in twelve case studies to rank their performance. Results of the case studies suggest that different baseline techniques perform differently and that VSM-Lucene and LSI-Matlab performed better than other implementations. By presenting the relative performances of baseline techniques this paper facilitates empirical cross-comparison of existing and future FLTs. Finally, the results suggest that the performance of FLTs partially depends on system/benchmark characteristics, in addition to the FLTs themselves.

<italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Feature Location (FL)</i> is a core software maintenance activity that aims to locate observable functionalities in the source code. Given its key role in software change, a vast array of Feature Location Techniques (FLTs) have been proposed but, as more and more FLTs are introduced, the <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">selection of an appropriate FLT</i> is an increasingly difficult problem. One consideration is the <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">characteristics of the features</i> being sought. For example, in the code associated with the feature, programmers may have named identifiers consistently, and with meaningful naming conventions, or not, and this may impact on the suitability of different FLTs. The suggestion that such characteristics matter has implicit support in the literature: An analysis of existing FLT empirical studies reveals that the system under study can often have a stronger impact on FLT performance than differing FLTs themselves. To understand this interaction between feature characteristics and FLTs better, this paper proposes <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">a suite of feature-characteristic metrics</i> that are postulated to control FLTs’ performance, holistically across FLTs and impacting on individual FLTs to different degrees. To evaluate the suite, a controlled experiment is performed, using 878 features, to probe the relationship between the metrics and the performance of four FTL techniques: three commonly-used techniques and one state-of-the-art technique. The evaluation is performed using four commonly used evaluation measures and extended by employing 41 other established source-code metrics as extraneous variables. Results of the empirical evaluation suggest that the feature-metric suite presented impacts FLT performance holistically, and impacts different FLTs to different degrees. Thus, this paper moves towards the more standard selection of appropriate FLTs, with respect to the prominent feature characteristics in the software systems under study, and more rigorous consideration of the features selected to compare FLTs.

Software product line adoption is a challenging task in software development organisations. There are some reports in the literature of how software product line engineering has been adopted in several companies using different variability management techniques and patterns. However, to the best of our knowledge, there are no empirical reports on how variability management is handled in companies that do not know about software product line methods and tools. In this paper we present an experience report observing variability management practices in a software development company that was unaware of software product line approaches. We briefly report how variability management is performed in different areas ranging from business architecture to software assets management. From the observation we report some open research opportunities for the future and foster further similar and more structured empirical studies on unaware software product line companies.

The extractive adoption of Software Product Lines (SPL) relies on the reuse of the already developed systems, employing a reengineering process. However, due to the diversity of options found in the daily practice of SPL development, rigorous planning of scenarios is critical to perform SPL reengineering. This diversity is the result of different organizational aspects, such as team experience and product portfolio. Hence, a proper planning process must consider technical and organizational aspects, however, most existing studies in the field do not take into account organizational aspects of the companies. In this work, we present SPLReePlan, an automated framework to aid the SPL reengineering planning taking into account technical and organizational aspects. Our framework is supported by a web-based tool, ready to be used in the industry. To investigate how flexible is SPLReePlan to support the SPL reengineering planning in diverse situations, we extracted eight different scenarios from the SPL literature, which are used as input for the evaluation of SPLReePlan. The results indicate that SPLReePlan can be satisfactorily customized to a variety of scenarios with different artifacts, feature retrieval techniques, and reengineering activities. As a contribution, we discuss the lessons learned within the evaluation, and present challenges that were faced, being a source of information for tool builders or motivating new studies.

Presence of large number of Feature Location Techniques (FLTs) poses difficulties when selecting an appropriate FLT, given a software maintenance task. This problem is aggravated by extensive heterogeneity in empirical designs employed to evaluate the FLTs and one such heterogeneity that may feed into conflicting findings across studies, is the feature set sought in evaluations. An analysis of the empirical findings of FL studies suggests that (sought) feature characteristics can have a stronger impact on FLTs performance than differing FLTs. Towards understanding their impact, this paper proposes two feature metrics that are hypothesized as affecting FLTs performances. To evaluate the presented metrics, a controlled experiment on 461 features gathered from four software systems was performed. The focus was to establish the relationship between the metrics and FLT performance. Results of the empirical evaluation suggest that the presented feature metrics strongly impact performance of different FLTs, as measured using established evaluation measures. Thus, this paper facilitates a more standard, transparent selection of feature benchmarks towards fair comparison of FLTs.

Software maintainers are often challenged with source code changes to improve software systems, or eliminate defects, in unfamiliar programs. To undertake these tasks a sufficient understanding of the system (or at least a small part of it) is required. One of the most time consuming tasks of this process is locating which parts of the code are responsible for some key functionality or feature. Feature (or concept) location techniques address this problem. This paper introduces Conclave, an environment for software analysis, and in particular the Conclave-Mapper tool that provides a feature location facility. This tool explores natural language terms used in programs (e.g. function and variable names), and using textual analysis and a collection of Natural Language Processing techniques, computes synonymous sets of terms. These sets are used to score relatedness between program elements, and search queries or problem domain concepts, producing sorted ranks of program elements that address the search criteria, or concepts. An empirical study is also discussed to evaluate the underlying feature location technique.

New customers often require custom features of a successfully marketed product. As the number of variants grow, new challenges arise in the maintenance and evolution activities. Software product line (SPL) architecture is a timely answer to these challenges. The SPL adoption however is a large one time investment that affects both technical and organizational issues. From the program code point of view, the extractive approach is appropriate when there are already several product variants. Analyzing the feature structure, the differences and commonalities of the variants lead to the new common architecture. In this work in progress paper we report initial experiments of feature extraction from a set of product variants written in the Magic fourth generation language (4GL). Since existing approaches are mostly designed for mainstream languages, we adapted and reused reverse engineering approaches to the 4GL environment. We followed a semi-automatic feature extraction method, where the higher level features are provided by domain experts. These features are then linked to the internal structure of Magic applications using a textual similarity (IR-based) method. We demonstrate the feasibility of 4GL feature extraction method and validate it on two variants of a real life logistical system each consisting of more than 2000 Magic programs.

Trusted Product Lines

A Software Product Line (SPL) is a set of systems that share a group of manageable features and satisfy the specific needs of a particular domain. The features of an SPL can be used in variable combinations to derive product variants in the SPL domain. Because SPLs promote product development through reuse, it is vital to have a means to measure their quality in terms of quality attributes like complexity, reusability,… In this paper, we propose a set of metrics to evaluate the quality of an SPL at three levels: the feature model, design and code. We adapted a set of metrics for software quality and defined new metrics to deal with the inherent characteristics of SPLs, specifically the feature model and the traceability between features, design and code. Furthermore, to assist in interpreting the quality of a given SPL, we conducted an empirical study over ten open source SPLs to identify thresholds for the proposed metrics.

BackgroundThe software product lines (SPL) enable development teams to fully address a systematic reuse of shared assets to deliver a family of similar software products. Mobile applications are an obvious candidate for employing an SPL approach. This paper presents our research outcomes, based on empirical data from an industry-level development project. Two development teams were confronted with the same functionalities set to be delivered through a family of native mobile applications for Android and iOS.MethodsEmpirical data was gathered before, during and after a year of full-time development. The data demonstrate the impact of a SPL approach by comparing the SPL and non-SPL multiple edition development. One family of products (Android apps) was developed using an SPL approach, while another (iOS apps), functionally the same, was developed without employing an SPL approach. The project generated a volume of raw and aggregated empirical data to support our research questions.ResultsThe paper reports a positive impact of an SPL approach on product quality (internal and external) and feature output per week. As data shows, it also increases the delivery of functionalities (240% in 6 more editions), while investing the same amount of effort needed for a single-edition development. As a result of system-supported separation of development and production code, developers had a high confidence in further development. On the other hand, the second team delivered less new functionalities, only two new application editions, and lower software quality than the team that manages multi-edition development by employing an SPL approach.

A systematic mapping study on software product line evolution: From legacy system reengineering to product line refactoring

Feature location is a maintenance task to identify the implementation of a feature within the source code. To automate or support the task, extensive studies have been conducted on feature location techniques. In this paper, we focus on certain static and dynamic constraints regarding feature additions to object-oriented programs, and construct an interactive feature location procedure based on the constraints. We manually conducted a case study for several features of a real-world program on the assumption that the user always correctly answers the questions asked by the procedure. The results show that over 75% of the feature's implementation could be efficiently covered by the procedure with relatively small number of execution traces.

Beyond the main purpose of Open Source Software (OSS) to open industrial Provide and personal solutions, pieces of OSS are Also the subject of many research efforts. In this work we focus on OSS usage the case study subjects in the context of extractive adoption of software product lines. This field of research is related to re-engineering the existing system towards more variants systematic reuse for the creation and management of a family of products. By analyzing the catalog of case studies, We provide an overview and a discussion of the current research state-of-the-practice of OSS usage across the different phases of the process re-engineering. We complement this work with the identification of available OSS tools to support this process to show the conclusion, the healthy contribution que OSS communities are directly or Indirectly making to this active research field.