Christoph Elsner

Consistent product line configuration across file type and product line boundaries

Creating a valid software configuration of a product line can require laborious customizations involving multiple configuration file types, such as feature models, domain-specific languages, or preprocessor defines in C header files. Using configurable off-the-shelf components causes additional complexity. Without checking of constraints across file types boundaries already at configuration time, intricate inconsistencies are likely to be introduced--resulting in product defects, which are costly to discover and resolve later on. Up to now, at best ad-hoc solutions have been applied. To tackle this problem in a general way, we have developed an approach and a corresponding plug-in infrastructure. It allows for convenient definition and checking of constraints across configuration file types and product line boundaries. Internally, all configuration files are converted to models, facilitating the use of model-based constraint languages (e.g., OCL). Converter plug-ins for arbitrary configuration file types may be integrated and hide a large amount of complexity usually associated with modeling. We have validated our approach using a quadrotor helicopter product line comprising three sub-product-lines and four different configuration file formats. The results give evidence that our approach is practically applicable, reduces time and effort for product derivation (by avoiding repeated compiling, testing, and reconfiguration cycles), and prevents faulty software deployment.

Architecture challenges for internal software ecosystems: a large-scale industry case study

The idea of software ecosystems encourages organizations to open software projects for external businesses, governing the cross-organizational development by architectural and other measures. Even within a single organization, this paradigm can be of high value for large-scale decentralized software projects that involve various internal, yet self-contained organizational units. However, this intra-organizational decentralization causes architecture challenges that must be understood to reason about suitable architectural measures. We present an in-depth case study on collaboration and architecture challenges in two of these large-scale software projects at Siemens. We performed a total of 46 hours of semi-structured interviews with 17 leading software architects from all involved organizational units. Our major findings are: (1) three collaboration models on a continuum that ranges from high to low coupling, (2) a classification of architecture challenges, together with (3) a qualitative and quantitative exposure of the identified recurring issues along each collaboration model. Our study results provide valuable insights for both industry and academia: Practitioners that find themselves in one of the collaboration models can use empirical evidence on challenges to make informed decisions about counteractive measures. Researchers can focus their attention on challenges faced by practitioners to make software engineering more effective.

Managing emerging configuration dependencies in multi product lines

Large-scale software-intensive systems often consist of multiple heterogeneous and loosely coupled systems, which work together to form a system of systems (SoS). The individual systems often represent configurable units that need be adapted to customer requirements. In such multi product line environments, configuration dependencies between the product lines need to be discovered and enforced. Based on an analysis of the SoSs of our industry partners in the domains of medical systems and industrial automation, we identify several types of configuration dependencies between product lines. In particular, we point out the importance of emerging dependencies, which are not known in advance, but are detected in the course of the configuration process. For handling such emerging dependencies, we developed tool extensions to the DOPLER tool suite that provide support for the distributed configuration of multi product lines by multiple users and that support the inference of dependencies from emerging dependencies by observing user actions. We conducted a preliminary evaluation to assess our tool-supported approach. Our extensible set of dependency types turned out to be suitable for modeling configuration dependencies between product lines in the study system. The evaluation further showed the usefulness of the tool for capturing emerging dependencies by multiple users during distributed configuration.

Variability Modelling throughout the Product Line Lifecycle

This paper summarizes our experience with introducing feature modelling into several product lines within Siemens. Feature models are used for solving various tasks in the product line lifecycle, starting with scoping the reusable asset base up to support for actual product configuration. Using feature models as primary artefacts for managing variability early in the lifecycle, we could improve the efficiency and transparency of scoping activities considerably and made the development efforts way easier to schedule. On the other end of the lifecycle, feature models lowered the engineering efforts in solution business in supporting product configuration and instantiation.

Fixing Configuration Inconsistencies across File Type Boundaries

Creating a valid software configuration often involves multiple configuration file types, such as feature models, domain-specific languages, or C header files with preprocessor defines. Enforcing constraints across file types boundaries already at configuration is necessary to prevent inconsistencies, which otherwise are costly to discover and resolve later on. We present a pragmatic framework to specify and apply inconsistency-resolving fixes on configuration files of arbitrary types. The framework converts each configuration file to a model, checks it for consistency, applies fixes, and serializes it back again. We argue that conventionally programmed fixes and round-trip mechanisms (i.e., converters and serializers) are indispensable for practical applicability and can provide sufficient reliability when following usual development practices. We have developed round-trip mechanisms for seven different configuration file types and two fixing mechanisms. One fixing mechanism extends previous work by combining automatic detection of correct fix locations with a marker mechanism that reduces the number of locations. A tool-supported process for applying the fixes provides user guidance and integrates additional semantic validity checks on serialized configuration files of complex types (e.g., feature models). Evaluations reveal a speed up in inconsistency fixing and that the performance of the currently integrated round-tripping and fixing mechanisms is competitive.

Constraint Checking in Distributed Product Configuration of Multi Product Lines

Large-scale software-intensive systems are often considered as systems of systems (SoS) comprising multiple heterogeneous but interrelated systems. The engineering of SoS often involves the derivation of system variants from multiple interrelated product lines to meet the overall requirements. If multiple teams and experts are involved in the configuration of these individual systems, their individual configuration choices may conflict with each other or violate constraints. This paper illustrates industrial challenges based on a previously conducted case study on distributed configuration in multi product lines. We then present CoDiM, a tool-supported approach for defining and checking constraints in distributed configuration of an SoS. Our approach is integrated in the product line tool suite DOPLER developed in cooperation with industry partners. An application scenario from a real-world multi product line demonstrates how our approach allows detecting violations of constraints during distributed configuration of an SoS. The approach provides immediate feedback to configurers during product derivation and enables the dynamic definition of constraints even during configuration time to accommodate changes. CoDiM further supports constraint templates which can be parameterized to allow their reuse in different multi product line configurations.

Experiences During Extraction of Variability Models for Warehouse Management Systems

Warehouse management systems (WMS) play a critical role in supply chains and large production processes. WMS pose two crucial challenges for variability modeling and management: Firstly, the physical configuration of each warehouse differs significantly. Numerous different electronic devices like controllers, sensors, and motors are used to automate warehouses. Secondly, the processes running in a warehouse demand control and coordination of these various software and hardware components. These processes have different configurations according to customer requirements. This paper reports on our experiences when applying variability modeling techniques in WMS, in order to improve the degree of reuse and shorten the delivery time to customers. Feature modeling is used to extract commonalities and variability in WMS. More than 200 features were identified, and categorized into three hierarchical layers. Furthermore, we linked the feature models to assets, and utilize feature models to support product derivation. Then, the lessons learned from the experiences are discussed. Based on these experiences, we conclude that feature modeling can be applied nicely for scoping features and tracing features to assets, but is not comprehensive enough to support automated configuration during product derivation in WMS.

An infrastructure for composing build systems of software product lines

Deriving a product from a software product line may require various build tasks, such as model transformations, source code generation, preprocessing, compiling, as well as linking and packaging the compiled sources. Usually implemented using simple scripting languages, such as Apache ant or GNU make, build systems tend to become monolithic entities, which are intricate to adapt and maintain. This makes developing the build system for a multi-- product-line, which is composed of several sub--product-lines and maybe other configurable components, particularly challenging. Several, previously independent build systems--- possibly implemented using different build tools (ant, make, etc.)---need to be integrated. In this paper, we approach this by using models to describe the involved build tasks (including their input and output parameters) as well as their composition. An interpreter evaluates the models and executes the tasks in the composed order with the configured parameters to produce the final product. Our approach enables the interaction of build systems implemented with different tools with only little development effort, whereas the build order and parameter flow is made explicit in the models. We have started to apply our tooling to model the build system of two multi--product-lines, where it reveals sufficient expressiveness and clarifies the build system interaction.

SECO Patterns: Architectural Decision Support in Software Ecosystems

A software ecosystem challenges the architect through additional considerations, because multiple partners with different interests are involved. Therefore, the perspectives business, 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.

Challenges in managing behavior variability of production control software

Software product line engineering helps organizations to achieve systematic software reuse by taking advantage of commonalities and predicted variability. Variability management has been considered as one important issue in product line development. In this paper, a variability analysis in production control systems reveals that the variability in such systems lays in the dynamic behavior and interaction of configured components, which we consider as behavior variability. This paper identifies the three main challenges to be solved for applying a product line approach to the domain of production control systems: (1) the selection or design of a proper variability language for describing the flexible behavior variability, (2) the need to model variability of behavior at different levels of granularity, as well as to map the elements among different levels, (3) the binding of behavioral variation points and variants into the various involved systems in a manageable way.