IVML

During the three decades since the invention of the first variability modeling approach [28], there have been multiple attempts to introduce advanced variability modeling capabilities. More recently, we have seen increased attention on textual variability modeling languages. In this paper, we summarize the main capabilities of state of the art textual variability modeling languages, based on [23], including updates regarding more recent work. Based on this integrated characterization, we provide a discussion of additional concerns, opportunities and challenges that are relevant for designing future (textual) variability modeling languages. The paper also summarizes relevant contributions by the authors as input to further discussions on future (textual) variability modeling languages.

Variability management aims at taming variability in large and complex software product lines. To efficiently manage variability, it has to be modeled using formal representations, such as feature or decision models. Such models are efficient in many domains, where variability is about switching on and off features, or using parameters to customize products of the product line. However, variability can be represented in the form of a topology in domains where variability is about connecting components in a certain order, in specific interconnected hierarchies, or in different quantities.In this experience report, we explore topological variability within a case study of large-scale fire alarm systems. We identify core characteristics of the variability, derive modeling requirements, model the variability using UML2 class diagrams, and discuss the applicability of further variability modeling languages. We show that, although challenging, class diagrams can suffice to represent topological variability in order to generate a configurator tool. In contrast, modeling parallel and recursive structures, cycles, informal constraints, and orthogonal hierarchies were among the main experienced challenges that require further research.

Product Lines (PL) in the systems engineering (SE) domain are one of the largest and most complex ones. The sheer number of different products that can be derived from PL points out to the scale of the challenge that Product Line Engineering (PLE) faces. Various development artifacts describe PL but due to their diversity, variability modeling across PL is a challenging task. Moreover, this complexity is a major obstacle for achieving traceability across PL which is especially important for product verification. In order to support systems engineering by establishing traceability across PL and aid verification planning we propose Multi-View Variability Model (MVVM). MVVM introduces a set of variability models that represent variability in various development artifacts, e.g. architecture, requirements etc. and corresponding inter-model constraints. We provide a formalization of MVVM and perform a transformation of the MVVM model to a Constraint Satisfiability Problem (CSP) where we formulate queries for the CSP model in order to extract information about variability dependencies among MVVM views. Throughout the paper we use a real system from the automotive domain as the working example in order to illustrate the introduced concepts.

There have been several proposals to describe the variability of software product lines by using modeling languages. In larger organizations or projects (e.g., multi product line environments) this can lead to a situation where multiple variability modeling techniques are used simultaneously. Rather than enforcing a single modeling language, we present an integrative infrastructure that provides a unified perspective for users configuring products in such multi product line environments, regardless of the different modeling methods and tools used internally. In this tool demonstration paper, we present a prototypical implementation of our framework based on Web services. So far, the prototype has been used with a feature-based, an OVM-style and a decision-oriented variability modeling approach.

Software product line (SPL) is a software engineering paradigm for software development. A software product within a product line often has specific functionalities that are not common to all other products within the product line. Those specific functionalities are termed “variant features” in a product line. SPL paradigm involves the modeling of variant features. However, little work in SPL investigates and addresses the modeling of variant features specific to user interface (UI). Unified Modeling Language (UML) is the de facto modeling language for object-oriented software systems. It is known that UML needs better support in modeling UIs. Thus, much research developed UML extensions to improve UML support in modeling UIs. Yet little of this work is related to developing such extensions for modeling UIs for SPLs in which variant features specific to UI modeling must be addressed. This research develops a UML extension -Web User Interface Modeling Language (WUIML) to address these problems. WUIML defines elements for modeling variant features specific to user interfaces for Web-based SPLs. The model elements in WUIML extend from the metaclass and BasicActivity of the UML2.0 metamodel. WUIML integrates the modeling of variant features specific to user interfaces to UML. For example, in a Web-based patient registration software product line, member products targeting British users may use British date format in the user interface, while member products targeting United States users may use United States date format in the user interface. Thus, this is a variant feature for this product line. WUIML defines a model element, XOR, to represent such exclusive or conditions in a product line user interface model. WUIML would reduce SPL engineers’ efforts needed in UI development. To validate the WUIML research outcome, a case study was conducted. The results of this empirical study indicate that modeling UIs for Web-based SPLs using WUIML is more effective and efficient than using standard UML.

Trustworthy variant derivation with translation validation for safety critical product lines

Software product lines engineering decreased the complexity of the development of products that share common features, and variability modeling helped define and manage the commonalities and differences between family products. That's why, through the years, many SPL languages have been proposed, tested, extended, experimented in case studies, and then developed even more. The proliferation of the modeling languages has made it difficult for engineers to select the appropriate one, depending on the domain context and on the user requirements. This paper first presents a panorama of the Software product line (SPL) modeling languages that have been proposed in the last two decades. A survey of few selected modeling languages is given in order to clarify their processes and the difference between the notations they use to specify requirements and to express commonality and variability. The article then provides software product line engineer with a guide that helps selecting the appropriate SPL modeling language, depending on the projects' constraints and requirements. The proposed practical guide is composed of a list of criteria that represent a basis for a comparative survey.

Systems engineers seek ways to reuse system models to accelerate the initial design development process on new complex projects. Despite its promise, one such solution ‐‐ the deployment of Model-based Product Line Engineering (MBPLE) ‐‐ presents challenges to practitioners. Not only is deployment costly, but an overwhelming number of variability modeling language options also lack interoperability. While research efforts work towards creating a universal variability modeling language and developing transformations between existing languages, this paper proposes incorporating variability modeling concepts into a system modeling language for a centralized management of product lines. In this work, we highlight SysML v2 as a promising language to use for variability modeling, arguing that it can orthogonally model systems and their variability. Further, we propose a novel metamodel that describes a SysML v2-based approach to modeling conceptual and asset variability spaces. We exemplify the deployment of this metamodel on a simple yet representative example found in a complex development environment. Ultimately, we hope the proposed metamodel will motivate SysML v2 tool vendors to support variability modeling by incorporating instantiation and constraint definition mechanisms and visualization capabilities in future tool releases.

A software ecosystem challenges the architect through additional considerations, because multiple partners with different interests are involved. Therefore, the perspectivesbusiness, organization and high-level architecture need to be taken into account before deriving a detailed software design. In this paper, we present our vision and first results of SECO patterns, which capture solutions for recurring high-level problems in software ecosystems. They can be used standalone, but our vision also includes a two-step decision support system to aid the architect in two complex decisions: At first, it can propose relevant SECO patterns to support feature selection. The proposals are based on the specific characteristics of the software ecosystem of interest, which have to be provided by the architect. In a second step, the decision support system can aid the architect in applying a selected SECO pattern. For this step, we reuse the method and knowledge base of CoCoADvISE to provide guidance on decision making regarding the detailed software architecture.

The paper describes a product-line-oriented approach to reusing requirements for systems with highly complex variability. Software product lines are a powerful means to manage comprehensively of all artifacts produced during system development for reuse. Hence, classical product line approaches provide mechanisms to handle requirements for reuse. But especially in the context of automotive systems, we face the challenge of creating reusable requirements specifications that each contain variability; reuse for requirements specifications of this kind means handling variability of variability models. This paper describes techniques for generating requirements specifications with variability from a so-called requirements library. The research results described originate from a process improvement initiative at DaimlerChrysler. The presented approaches are therefore pragmatic and aimed at current industrial practice but are formally based on a category-theoretical notation. Driven by practical issues, the paper comes up with extended means for variability modeling and a new notion of variability, broadening the scope of what can be managed by product lines.Keywordsautomotive systemscomplex variabilityrequirements engineeringsoftware product linesvariability modeling

One of the central activities of software product line development is variability modeling for a product family. Because variability models are needed at various stages of software product line development, determining whether a variability model has been modeled correctly is an essential activity for successful software product line development. Existing studies proposed various methods for analysis of various aspects of correctness of a variability model. In particular, analyzing whether a variability model is consistent or not is considered the most important analysis perspective since it is impossible to configure products from such a model. There are few studies in the software product line field that locate causes of inconsistency in a variability model. Furthermore, these existing methods cannot locate the exact causes of inconsistency due to the fact that the feature model they are based on allows ambiguity in its parent–child relationship or due to the fact that they are designed to produce explanations rather than locations of causes, resulting in producing long and complex explanations as the size of the feature model increases. In this work, we propose a method that determines whether or not a variability model has an inconsistency and identifies the exact locations of its causes if it has an inconsistency. To evaluate the proposed method, we developed a tool that automatically performs all the steps of the method and used it to conduct experiments with 49 models, including real-world variability models. As a result, the proposed method accurately identified all models with an inconsistency and located all causes of inconsistency in them.

This paper presents the new release of VariaMos, a Java-based tool for defining variability modeling languages, modeling (dynamic) product lines and cyber-physical self-adaptive systems, and supporting automated verification, analysis, configuration and simulation of these models. In particular, we describe the characteristics of this new version regarding its first release: (1) the capability to create languages for modeling systems with variability, even with different views; (2) the capability to use the created language to model (dynamic) product lines; (3) the capability to analyze and configure these models according to the changing context and requirements; and (4) the capability to execute them over several simulation scenarios. Finally, we show how to use VariaMos with an example, and we compare it with other tools found in the literature.

Software evolution is an inevitable process in the development of long-living software systems as, e.g., changes of requirements demand corresponding adaptations. For software product lines, the incorporation of evolution in the development process gets even more complex due to the vast number of potential variants and the set of reusable domain artifacts and their interrelations. To allow for the application of existing analyses also for combined dimensions of variants and versions, recent evolution-aware variability modeling techniques are insufficient for capturing both version and variant information by the same means. In this paper, we propose an extension of annotative variability modeling, also known as 150% modeling, to tackle evolution and variability by the same means. The so called 175% modeling formalism allows for the development and documentation of evolving product lines. A 175% model combines all variant-specific models of all versions of a product line, where elements are mapped to features and versions to specify which version of a variant contains the element. We discuss potential application scenarios for 175% modeling. Furthermore, we propose a bidirectional transformation between 175% and higher-order delta models to exploit the benefits of both modeling formalisms, when solely one type is available.

We address the question of how to select test cases in a controlled model-based software product line development process. CVL, the common variability language, provides a framework for materialization of product models from a given variability model and resolution model. Reflecting common practice, we assume that test case development for product line is independent from product development. In such a setting, the question arises which test cases can be applied to which products. To this end, we describe a procedure and tool set for assigning the outcome of a test case on an arbitrary member of a software product line using UML base and CVL variability models. As a case study, we demonstrate our approach with the example of a product line of automatic espresso machines.

In the software product line research, product variants typically differ by their functionality and quality attributes are not purposefully varied. The goal is to study purposeful performance variability in software product lines, in particular, the motivation to vary performance, and the strategy for realizing performance variability in the product line architecture. The research method was a theory-building case study that was augmented with a systematic literature review. The case was a mobile network base station product line with capacity variability. The data collection, analysis and theorizing were conducted in several stages: the initial case study results were augmented with accounts from the literature. We constructed three theoretical models to explain and characterize performance variability in software product lines: the models aim to be generalizable beyond the single case. The results describe capacity variability in a base station product line. Thereafter, theoretical models of performance variability in software product lines in general are proposed. Performance variability is motivated by customer needs and characteristics, by trade-offs and by varying operating environment constraints. Performance variability can be realized by hardware or software means; moreover, the software can either realize performance differences in an emergent way through impacts from other variability or by utilizing purposeful varying design tactics. The results point out two differences compared with the prevailing literature. Firstly, when the customer needs and characteristics enable price differentiation, performance may be varied even with no trade-offs or production cost differences involved. Secondly, due to the dominance of feature modeling, the literature focuses on the impact management realization. However, performance variability can be realized through purposeful design tactics to downgrade the available software resources and by having more efficient hardware.