Grants and Contributions:

Grant or Award spanning more than one fiscal year. (2017-2018 to 2022-2023)

A 'one size fits all' software system is no longer practical; customizations to fit various hardware and user requirements are often necessary. For example, Hewlett-Packard produces over 40 printer models, and the Linux kernel supports 32 computer architectures that are included in devices ranging from mobile devices to enterprise servers. Software is often designed for a specific product in mind, and when new requirements arise, the old product is copied and modified to fit these new requirements. This copying approach is cumbersome, and managing separate related products is error-prone and can lead to redundancy (e.g., applying the same bug fix to different products). Software Product Lines (SPLs) avoid exactly this situation. An SPL is a shared, configurable platform that provides a set of features (units of functionality) that can be combined to create a specific software product, while respecting given feature dependencies documented in a variability model . Advantages of SPLs include an easier approach to produce tailor-made software with reduced cost, improved quality, and reduced time to market.

Unfortunately, software systems are often conceived as individual products; only later, after multiple related products have been produced, does it become obvious that they should have been better developed as part of a single coherent SPL. However, migrating a set of related software products into an SPL is costly and requires high manual effort. The long-term goal of my research program is to create methods and respective tools that provide automated support for SPL migration. My overall methodology relies on leveraging code evolution and process knowledge mined from software repositories (e.g., version control systems) along with insights gained from quantitative and qualitative empirical studies involving practitioners. My proposal integrates two research activities, each targeting a set of problems that address the above goal.

Re-engineering related products: What re-engineering steps can consolidate related products into a single shared configurable system? Depending on the programming language and initial design of these products, what is the most suitable architecture for supporting variability?

Reverse-engineering variability models: Can we automatically determine feature dependencies and explain them to stakeholders? Can we automatically infer dependencies that stem from domain knowledge?

The contributions of this research program will enable more systematic reuse of existing software, saving software architects valuable time spent in manual migration and allowing software producers to cope with the increasing demand for software. The HQP trained through this research program will gain experience in designing and conducting quantitative and qualitative empirical studies, mining software repositories, and analyzing source code and other software artifacts.