Sven Schuster

Guaranteeing Configuration Validity in Evolving Software Product Lines

Software Product Lines (SPLs) are an approach to capture families of closely related software systems in terms of commonalities and variabilities where individual variants are defined by configurations of selected features. Specific (partial) configurations may be of particular importance to SPL manufacturers, e.g., if they are very popular or used by major customers. SPLs are subject to evolution, which may inadvertently break existing configurations, e.g., if a previously selected feature does no longer exist. This is problematic as it may delay or completely prevent creation of previously existing important variants causing monetary loss and customer dissatisfaction. In this paper, we present a method to lock specific configurations to ensure their validity during evolution of the SPL. For this, we present Temporal Feature Models (TFMs) and dedicated evolution operations as a semantic-enriched first-class notion for evolution of feature models, which we use to assess the impact on existing configurations. Using the presented method, it is possible to guarantee that locked configurations remain valid during SPL evolution and make statements on which part of the evolution would break the configurations.

Delta-Trait Programming of Software Product Lines

Delta-oriented programming DOP is a flexible approach for implementing software product lines SPLs. DOP SPLs are implemented by a set of delta modules encapsulating changes to class-based object-oriented programs. A particular product in a DOP SPL is generated by applying to the empty program the modifications contained in the delta modules associated to the selected product features. Traits are pure units of behavior, designed to support flexible fine-grained reuse and to provide an effective means to counter the limitations of class-based inheritance. A trait is a set of methods which is independent from any class hierarchy and can be flexibly used to build other traits or classes by means of a suite of composition operations. In this paper, we present an approach for programming SPLs of trait-based programs where the program modifications expressed by delta modules are formulated by exploiting the trait composition mechanism. This smooth integration of the modularity mechanisms provided by delta modules and traits results in a new approach for programming SPLs, delta-trait programming DTP, which is particularly well suited for evolving SPLs.

A toolchain for delta-oriented modeling of software product lines

Software is increasingly individualized to the needs of customers and may have to be adapted to changing contexts and environments after deployment. Therefore, individualized software adaptations may have to be performed. As a large number of variants for affected systems and domains may exist, the creation and deployment of the individualized software should be performed automatically based on the software’s configuration and context. In this paper, we present a toolchain to develop and deploy individualized software adaptations based on Software Product Line (SPL) engineering. In particular, we contribute a description and technical realization of a toolchain ranging from variability modeling over variability realization to variant derivation for the automated deployment of individualized software adaptations. To capture the variability within realization artifacts, we employ delta modeling, a transformational SPL implementation approach. As we aim to fulfill requirements of industrial practice, we employ model-driven engineering using statecharts as realization artifacts. Particular statechart variants are further processed by generating C/C++ code, linking to external code artifacts, compiling and deploying to the target device. To allow for flexible and parallel execution the toolchain is provided within a cloud environment. This way, required variants can automatically be created and deployed to target devices. We show the feasibility of our toolchain by developing the industry-related case of emergency response systems.

Object-oriented design in feature-oriented programming

Object-oriented programming is the state-of-the-art programming paradigm for developing large and complex software systems. To support the development of maintainable and evolvable code, a developer can rely on different mechanisms and concepts such as inheritance and design patterns. Recently, feature-oriented programming (FOP) gained attention, specifically for developing software product lines (SPLs). Although FOP is an own paradigm with dedicated language mechanisms, it partly relies on object-oriented programming. However, only little is known about feature-oriented design and how object-oriented design mechanisms and design principles are used within FOP. In this paper, we want to raise awareness on design patterns in FOP and stimulate discussion on related topics. To this end, we present an exemplary review of using OO design patterns in FOP and limitations thereof from our perspective. Subsequently, we formulate questions that are open and that we think are worth to discuss in the context of feature-oriented design.

Structural feature interaction patterns: case studies and guidelines

Feature interactions have been an intensive field of research for more than a decade. Recently, it gained much attention in the context of software product lines (SPLs), a methodology that takes features explicitly into account to distinguish between similar yet different programs. In its very essence, feature interactions occur whenever the presence of two or more features leads to a considerable (and maybe unwanted) change of the behavior of the underlying program. Amongst others, feature interactions may occur on source code level, for example, in form of additional code that is needed due to interacting features. In this paper, we focus on such structural interactions. Particularly, we investigate structural feature interaction patterns, that is, patterns that are related to structural feature interactions, and vice versa. To this end, we propose an approach to detect design patterns in feature-oriented SPLs. We show that such design patterns exist on feature level and these patterns involve feature interactions. Based on our results, we reason about feature interactions in the presence of design patterns. Particularly, we show when feature interactions occur and that they are beneficial, for example, to achieve a higher degree of abstraction. Furthermore, we propose an initial guideline when certain design patterns are applicable.

Detecting and Describing Variability-Aware Design Patterns in Feature-Oriented Software Product Lines.

Software Product Lines (SPLs) enable customization by reusing commonalities and variabilities within a family of similar software systems. Design patterns are best practices of established solutions in object-oriented source code for recurring design challenges. Although certain design patterns realize variability, they are only defined in the context of stand-alone systems and not for SPLs. Employing design patterns to realize variability allows using best practices in design for SPL development. However, the exact usage of design patterns within SPLs has not been explored, and a formal notation to capture their usage within different features does not exist. In this work, we provide a model-based analysis method to determine the variability-aware usage of design patterns in source code within the context of Feature-Oriented Programming (FOP). Moreover, we introduce Family Role Models (FRMs) as an extension to role modeling, which offer a language-independent, unified, formal notation for decomposed design patterns. We apply the analysis method in a case study on the variability-aware usage of design patterns in feature-oriented SPLs and derive FRMs from the results.

Towards a development process for maturing Delta-oriented software product lines

A Software Product Line (SPL) exploits reuse-in-the-large to enable customization by explicitly modeling commonalities and variabilities of closely related software systems. Delta-Oriented Programming (DOP) is a flexible implementation approach to SPL engineering, which transforms an existing core product to another desired product by applying transformation operations. By capturing product alterations related to configurable functionality within delta modules, DOP closely resembles a natural process of software development, which proves beneficial in early stages of development. However, increasing complexity for a growing SPL in later development stages caused by the invasiveness of DOP drastically impairs maintenance and extensibility. Hence, a process utilizing the invasiveness of DOP in early development stages and restricting it in later stages would allow developers to mature growing delta-oriented SPLs. Moreover, ever-increasing complexity requires means to migrate into less invasive development approaches that are more suited for large-scale configurable applications. To this end, we propose a development process for delta-oriented SPLs including explicit variability points, metrics and refactorings as well as a semi-automatic reengineering of a delta-oriented SPL into a development approach based on blackbox-components. In this paper, we sketch this development process with its constituents and point out required research essential for successfully maturing a delta-oriented SPL.

Name resolution strategies in variability realization languages for software product lines

Software Product Lines (SPLs) exploit reuse-in-the-large to enable customization by explicitly modeling commonalities and variabilities of closely related software systems. Different approaches exist to enable SPL development and product creation by using modular languages, such as Feature-Oriented Programming (FOP) (compositional) or Delta-Oriented Programming (DOP) (transformational). These languages incorporate, e.g., object-oriented languages, adding a layer of variability. Creating a variabilityaware Abstract Syntax Graph (ASG), i.e., an ASG that contains the complete variability of the SPL, facilitates family-based analyses and is essential for supporting developers during SPL development. To this end, name resolution has to be performed. However, name resolution for these languages is a challenge as multiple declarations for the same element may occur in different modules. In this paper, we propose four name resolution strategies for compositional and transformational SPL realization languages and discuss their benefits and drawbacks, categorized by relevant application scenarios of the ASG.