Real-world Software Product Lines (SPLs) need Numerical Feature Models (NFMs) whose features have not only boolean values that satisfy boolean constraints but also have numeric attributes that satisfy arithmetic constraints. An essential operation on NFMs finds near-optimal performing products, which requires counting the number of SPL products. Typical constraint satisfaction solvers perform poorly on counting and sampling.Nemo (Numbers, features, models) is a tool that supports NFMs by bit-blasting, the technique that encodes arithmetic expressions as boolean clauses. The newest version, Nemo2, translates NFMs to propositional formulas and the Universal Variability Language (UVL). By doing so, products can be counted efficiently by #SAT and Binary Decision Tree solvers, enabling finding near-optimal products. This article evaluates Nemo2 with a large set of synthetic and colossal real-world NFMs, including complex arithmetic constraints and counting and sampling experiments. We empirically demonstrate the viability of Nemo2 when counting and sampling large and complex SPLs.& COPY; 2023 The Authors. Published by Elsevier Inc. This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).

Real-world [inline-graphic not available: see fulltext] need [inline-graphic not available: see fulltext] whose features not only have boolean values satisfying boolean constraints, but also have numeric attributes satisfying arithmetic constraints. A key operation on [inline-graphic not available: see fulltext]s finds near-optimal performing products, which requires counting the number of SPL products. Typical constraint satisfaction solvers perform poorly on counting. [inline-graphic not available: see fulltext] (Numbers, features, models) supports [inline-graphic not available: see fulltext] by [inline-graphic not available: see fulltext], the technique that encodes arithmetic as boolean clauses. [inline-graphic not available: see fulltext] translates [inline-graphic not available: see fulltext]s to propositional formulas whose products can be counted efficiently by #SAT solvers, enabling near-optimal products to be found. We evaluate [inline-graphic not available: see fulltext] with a diverse set of real-world [inline-graphic not available: see fulltext], complex arithmetic constraints, and counting experiments in this paper.

Stepwise design of programs is a divide-and-conquer strategy to control complexity in program modularization and theorems. It has been studied extensively in the last 30 years and has worked well, although it is not yet commonplace. This paper explores a new area of research, finding efficient products in colossal product spaces, that builds upon past work.

Efficiently testing large configuration spaces of Software Product Lines (SPLs) needs a sampling algorithm that is both scalable and provides good t-wise coverage. The 2019 SPLC Sampling Challenge provides large real-world feature models and asks for a t-wise sampling algorithm that can work for those models. We evaluated t-wise coverage by uniform sampling (US) the configurations of one of the provided feature models. US means that every (legal) configuration is equally likely to be selected. US yields statistically representative samples of a configuration space and can be used as a baseline to compare other sampling algorithms. We used existing algorithm called Smarch to uniformly sample SPL configurations. While uniform sampling alone was not enough to produce 100% 1-wise and 2-wise coverage, we used standard probabilistic analysis to explain our experimental results and to conjecture how uniform sampling may enhance the scalability of existing t-wise sampling algorithms.

OCL is a standard MDE language to express constraints. OCL has been criticized for being too complicated, over-engineered, and difficult to learn. But beneath OCL's complicated exterior is an elegant language based on relational algebra. We call this language A(ocl), which has a straightforward implementation in Java. A(ocl) can be used to write OCL-like constraints and model transformations in Java. A simple MDE tool generates an A(ocl) Java 8.0 package from an input class diagram for A(ocl) to be used.

Since the mid-2000s, Propositional Logic (PL) has been the de facto language to express constraints in Feature Models (FMs) of Software Product Line (SPLs). PL was adequate because product configurations were formed by binary decisions including or not including features in a product. Inspired by both prior research and practical systems (eg., SPLs that use KConfig), future FMs must go beyond PL and admit numerical (and maybe even text) variables and their constraints. The Object Constraint Language (OCL) is a general-purpose declarative constraint language for Model Driven Engineering (MDE), which admits virtually any kind of variable and constraint in meta-models. We should expect future FMs to be examples of MDE meta-models. This raises a basic question: Should OCL be used to express constraints of future variability modeling language(s)? In this talk, I outline the pros and cons for doing so.

Refactorings, by definition, preserve the behavior of a target program. Such a strong semantic property is encoded by a set of preconditions for each refactoring. Only if all preconditions are satisfied will a target program be transformed. The code transformation that implements the refactoring follows another set of rules to produce syntactically-correct, refactored code. Consequently, it is easy to believe that most behavior-changing violations in refactorings are induced by incorrect preconditions or lack of required checks. In this paper, however, we show that code transformations for Move-Instance-Method Refactoring available in several popular Java Integrated Development Environments do not preserve program behavior. We report these errors and propose solutions for each identified problem.

We present mathematics about random sampling of colossal ( 10) search spaces that allow confidence intervals to be computed on results that are returned.

Finding products that balance multiple competing objectives is a fundamental and difficult optimization problem. Software product lines compound its difficulty as their product spaces are gigantic, sometimes exceeding 1060 distinct configurations. We present new algorithms for (a) true random selection of configurations in gigantic product spaces, (b) discovering the shape of their Pareto fronts, (c) exploring regions of interest on these fronts with greater efficiency than offered by existing algorithms, and (d) using real and previously used systems in our experiments as supporting evidence.

Regression testing checks that recent project changes do not break previously working functionality. Although important, regression testing is costly when changes are frequent. Regression test selection (RTS) optimizes regression testing by running only tests whose results might be affected by a change. Traditionally, RTS collects dependencies (e.g., on files) for each test and skips the tests, at a new project revision, whose dependencies did not change. Existing RTS techniques do not differentiate behavior-preserving transformations (i.e., refactorings) from other code changes. As a result, tests are run more frequently than necessary. We present the first step towards a refactoring-aware RTS technique, dubbed Reks, which skips tests affected only by behavior-preserving changes. Reks defines rules to update the test dependencies without running the tests. To ensure that Reks does not hide any bug introduced by the refactoring engines, we integrate Reks only in the pre-submit testing phase, which happens on the developers' machines. We evaluate Reks by measuring the savings in the testing effort. Specifically, we reproduce 100 refactoring tasks performed by developers of 37 projects on GitHub. Our results show that Reks would not run, on average, 33% of available tests (that would be run by a refactoring-unaware RTS technique). Additionally, we systematically run 27 refactoring types on ten projects. The results, based on 74,160 refactoring tasks, show that Reks would not run, on average, 16% of tests (max: 97% and SD: 24%). Finally, our results show that the Reks update rules are efficient.

Refactoring is a staple of Object-Oriented (OO) program development. It should be a staple of OO Software Product Line (SPL) development too. X15 is the first tool to support the refactoring of Java SPL codebases. X15 (1) uses Java custom annotations to encode variability in feature-based Java SPLs, (2) projects a view of an SPL product (a program that corresponds to a legal SPL configuration), and (3) allows programmers to edit and refactor the product, propagating changes back to the SPL codebase. Case studies apply 2316 refactorings in 8 public Java SPLs and show that X15 is as efficient, expressive, and scalable as a state-of-the-art feature-unaware Java refactoring engine.

Dataflow programs are widely used. Each program is a directed graph where nodes are computations and edges indicate the flow of data. In prior work, we reverse-engineered legacy dataflow programs by deriving their optimized implementations from a simple specification graph using graph transformations called refinements and optimizations. In MDE speak, our derivations were PIM-to-PSM mappings. In this paper, we show how extensions complement refinements, optimizations, and PIM-to-PSM derivations to make the process of reverse engineering complex legacy dataflow programs tractable. We explain how optional functionality in transformations can be encoded, thereby enabling us to encode product lines of transformations as well as product lines of dataflow programs. We describe the implementation of extensions in the \(\mathtt{ReFlO}\) tool and present two non-trivial case studies as evidence of our work’s generality.

Software Product Lines (SPLs) are highly configurable systems. This raises the challenge to find optimal performing configurations for an anticipated workload. As SPL configuration spaces are huge, it is infeasible to benchmark all configurations to find an optimal one. Prior work focused on building performance models to predict and optimize SPL configurations. Instead, we randomly sample and recursively search a configuration space directly to find near-optimal configurations without constructing a prediction model. Our algorithms are simpler and have higher accuracy and efficiency.

Software engineering involves a lot of change as code artifacts are not only created once but maintained over time. In the last 25 years, major paradigms of program development have arisen – agile development with refactorings, software product lines, moving sequential code to multicore or cloud, etc. Each is centered on particular kinds of change; their conceptual foundations rely on transformations that (semi-) automate these changes. We are exploring how transformations can be placed at the center of software development in future IDEs, and when such a view can provide benefits over the traditional view. COPE, a Change-Oriented Programming Environment, looks at 5 activities: (1) analyze what changes programmers typically make and how they perceive, recall, and communicate changes, (2) automate transformations to make it easier to apply and script changes, (3) develop tools that compose and manipulate transformations to make it easier to reuse them, (4) integrate transformations with version control to pro- vide better ways for archiving and understanding changes, and (5) develop tools that infer higher-level transformations from lower-level changes. Characterizing software develop- ment in terms of transformations is an essential step to take software engineering from manual development to (semi-) automated development of software.

Refactoring engines are standard tools in today's Integrated Development Environments (IDEs). They allow programmers to perform one refactoring at a time, but programmers need more. Most design patterns in the Gang-of-Four text can be written as a refactoring script - a programmatic sequence of refactorings. In this paper, we present R3, a new Java refactoring engine that supports refactoring scripts. It builds a main-memory, non-persistent database to encode Java entity declarations (e.g., packages, classes, methods), their containment relationships, and language features such as inheritance and modifiers. Unlike classical refactoring engines that modify Abstract Syntax Trees (ASTs), R3 refactorings modify only the database; refactored code is produced only when pretty-printing ASTs that reference database changes. R3 performs comparable precondition checks to those of the Eclipse Java Development Tools (JDT) but R3's codebase is about half the size of the JDT refactoring engine and runs an order of magnitude faster. Further, a user study shows that R3 improved the success rate of retrofitting design patterns by 25% up to 50%.

Editorial preface for the JLAMP Special Issue on Formal Methods for Software Product Line Engineering

ReFlO is a framework and interactive tool to record and systematize domain knowledge used by experts to derive complex pipe-and-filter (PnF) applications. Domain knowledge is encoded as transformations that alter PnF graphs by refinement (adding more details), flattening (removing modular boundaries), and optimization (substituting inefficient PnF graphs with more efficient ones). All three kinds of transformations arise in reverse-engineering legacy PnF applications. We present the conceptual foundation and tool capabilities of ReFlO, illustrate how parallel PnF applications are designed and generated, and how domain-specific libraries of transformations are developed.

Refactorings, by definition, preserve the behavior of a target program. Such a strong property is encoded by precisely defined preconditions for each refactoring. Only if all preconditions are satisfied will a target program be transformed. Code transformation is done by following the rules defined to produce syntactically-correct, refactored code. Consequently, most behavior-changing violations in refactorings are induced by incorrect preconditions or lack of required checks. In this paper, we show how the transformation rules commonly used in four Java IDEs change program behavior in a Move-Instance-Method Refactoring (MiMr). We report that all have flaws in code transformation and propose solutions for each identified problem in MiMrs.

MDELite is a Java framework to build an MDE application by integrating off-the-shelf tools. Models are relational databases encoded as Prolog facts. Prolog is used to express (a) declarative metamodel constraints and (b) declarative model-tomodel transformations. The motivation for MDELite is to reduce the overhead of using Eclipse MDE tools and improve instruction of MDE concepts to undergraduates and graduates. The first generation of MDELite was not bootstrapped. In this paper, expose the fundamental role of domain constructors in MDE and how a single constructor is sufficient to bootstrap a second-generation implementation of MDELite called Catalina. We present our experiences with Catalina and outline the next steps in MDELite development.

Retrofitting design patterns into a program by hand is tedious and error-prone. A programmer must distinguish refactorings that are provided by an Integrated Development Environment (IDE) from those that must be realized manually, determine a precise sequence of refactorings to apply, and perform this sequence repetitively to a laborious degree. We designed, implemented, and evaluated Reflective Refactoring (R2), a Java package to automate the creation of classical design patterns (Visitor, Abstract Factory, etc.), their inverses, and variants. We encoded 18 out of 23 Gang-of-Four design patterns as R2 scripts and explain why the remaining are inappropriate for refactoring engines. We evaluate the productivity and scalability of R2 with a case study of 6 real-world applications. In one case, R2 automatically created a Visitor with 276 visit methods by invoking 554 Eclipse refactorings in 10 minutes - an achievement that could not be done manually. R2 also sheds light on why refactoring correctness, expressiveness, and speed are critical issues for scripting in next-generation refactoring engines.