A Case Study on Model-Driven Development and Aspect-Oriented Programming: Benefits and Liabilities - Hohenstein, Uwe; Elsner, Christoph (Software Technologies, 2015)
Model-driven development (MDD) and aspect-oriented programming (AOP) are two very different paradigms, having in common that they both aim at increasing development efficiency. In order to investigate their benefits and liabilities, we compared both in context of a case study on an industrial-grade software system, the Open SOA platform. Already having a model-driven XML/XSL-T implementation in place, we re-implemented the corresponding logic of the Open SOA platform with a corresponding AOP implementation in AspectJ. Considering several comparison criteria, the results of our case study indicate that the AspectJ implementation is less redundant, better testable, and improves on understandability and readability. The model-driven approach, in turn, is the more flexible one, as it allows for generating arbitrary artifacts and structures, without the need for compromising on design. Additionally, we expect that MDD can furthermore catch up on readability and understandability, when more advanced MDD tooling can be leveraged. As our case study mainly centers around implementing wrappers and boilerplate-code, which are rather common issues, our results may be transferred to similar problem settings. Furthermore, our evaluation criteria can guide others in making technology choices. To this end, we give an outlook on how combinations of MDD and AOP may leverage the best of both worlds.
UnivIS-Import:2016-02-10:Pub.2015.tech.IMMD.IMMD4.acases
Keywords: AOP; AspectJ; Case study; MDD; XSL-T

A Flexible Approach for Generating Product-Specific Documents in Product Lines - Rabiser, Rick; Heider, Wolfgang; Elsner, Christoph; Lehofer, Martin; Grünbacher, Paul; Schwanninger, Christa (Proceedings of the 14th International Software Product Line Conference (SPLC 2010), 2010)
In software product line engineering various stakeholders like sales and marketing people, product managers, and technical writers are involved in creating and adapting documents such as offers, contracts, commercial conditions, technical documents, or user manuals. In practice stakeholders often need to adapt these documents manually during product derivation. This adaptation is, however, tedious and error-prone and can easily lead to inconsistencies. Despite some automation there is usually a lack of general concepts and there are "islands of automation" that are hardly integrated. Also, research on product lines has so far often neglected the handling of documents. To address these issues, we developed a flexible approach for automatically generating product-specific documents based on variability models. We applied the approach to two industrial product lines of different maturity using the decision-oriented product line engineering tool suite DOPLER. © 2010 Springer-Verlag Berlin Heidelberg.
UnivIS-Import:2015-04-16:Pub.2010.tech.IMMD.IMMD4.aflexi
Keywords: Document Generation; Software Product Line Engineering; Model-Driven Software Development

An Infrastructure for Composing Build Systems of Software Product Lines - Elsner, Christoph; Lohmann, Daniel; Schröder-Preikschat, Wolfgang (Proceedings of 15th International Software Product Line Conference (SPLC 2011), Volume 2, 2011)
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. Copyright © 2011 ACM.
UnivIS-Import:2015-04-16:Pub.2011.tech.IMMD.IMMD4.aninfr
Keywords: Build system integration; Software product line

An Infrastructure for Model-Driven Hierarchical Product Lines (in german) - Elsner, Christoph; Lohmann, Daniel; et al. (GI Proceedings 150 "Software Engineering 2009 - Workshopband": 02.-06. März 2009, Kaiserslautern, 2009)
UnivIS-Import:2015-04-16:Pub.2009.tech.IMMD.IMMD4.einein
Keywords: Hierarchical Software Product Line; Model-Driven Software Development

An Infrastructure for the Life Cycle Management of Multi Product Lines - Holl, Gerald; Grünbacher, Paul; Elsner, Christoph; Vierhauser, Michael (28th Symposium On Applied Computing. Track on Software Architecture: Theory, Technology, and Applications (SAC-SATTA 2013), 2013)
Large-scale industrial systems comprise multiple heterogeneous systems that need to be adapted and configured individually to meet the customers' needs. Product line techniques such as variability modeling and product derivation are frequently used to enable such customization. However, managing the life cycle of multiple product lines in system-of-systems architectures is challenging. For instance, support is lacking for defining the architecture of multi product lines. Further, system architects, modelers and configurers are missing a common infrastructure supporting domain and application engineering. This paper contributes a tool infrastructure providing essential structures and facilities for the development and operation of multi product lines. Based on an analysis of industrial scenarios we developed support for managing the life cycle of multi product lines. This comprises architecture definition and support for sharing and deploying product line models to the involved stakeholders. In this paper we show how the infrastructure supports system architects performing life cycle management of multi product lines. We demonstrate the feasibility of the approach based on a real-world industrial system. Copyright 2013 ACM.
UnivIS-Import:2015-04-16:Pub.2013.tech.IMMD.IMMD4.aninfr
Keywords: Infrastructure; Life cycle management; Multi product lines; Tool support

Architecture Challenges for Internal Software Ecosystems: A Large-Scale Industry Case Study - Schultis, Klaus-Benedikt; Elsner, Christoph; Lohmann, Daniel (Proceedings of the 22nd International Symposium on Foundations of Software Engineering (FSE '14), 2014)
UnivIS-Import:2015-04-16:Pub.2014.tech.IMMD.IMMD4.archit
Keywords: Distinguished Paper Award; Architecture; Software Ecosystems; Experience; ISEco

Architecture-Violation Management for Internal Software Ecosystems - Schultis, Klaus-Benedikt; Elsner, Christoph; Lohmann, Daniel (Proceedings of the 13th Working IEEE/IFIP Conference on Software Architecture (WICSA 2016), 2016)
UnivIS-Import:2016-06-01:Pub.2016.tech.IMMD.IMMD4.archit

Automating Staged Product Derivation for Heterogeneous Multi-Product-Lines - Elsner, Christoph (Friedrich-Alexander-Universität Erlangen-Nürnberg, 2012)
UnivIS-Import:2016-07-26:Pub.2012.tech.IMMD.IMMD4.automa

Challenges in Managing Behavior Variability of Production Control Software - Fang, Miao; Leyh, Georg; Elsner, Christoph; Dorr, Jorg (Proceedings of the 4th International Workshop on Product LinE Approaches in Software Engineering (PLEASE 2013), 2013)
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. © 2013 IEEE.
UnivIS-Import:2015-04-16:Pub.2013.tech.IMMD.IMMD4.challe
Keywords: Behavior Variability; Product Line Infrastructure; Variability Management

Consistent Product Line Configuration Across File Type and Product Line Boundaries - Elsner, Christoph; Ulbrich, Peter; Lohmann, Daniel; Schröder-Preikschat, Wolfgang (Proceedings of the 14th International Software Product Line Conference (SPLC 2010), 2010)
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. © 2010 Springer-Verlag Berlin Heidelberg.
UnivIS-Import:2015-04-16:Pub.2010.tech.IMMD.IMMD4.consis
Keywords: SPL; Software Product Lines; VAMOS; CiAO

Experiences During Extraction of Variability Models for Warehouse Management Systems - Fang, Miao; Leyh, Georg; Elsner, Christoph; Doerr, Joerg (Proceedings of the 20th Asia-Pacific Software Engineering Conference (APSEC 2013), 2013)
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. © 2013 IEEE.
UnivIS-Import:2015-04-16:Pub.2013.tech.IMMD.IMMD4.experi
Keywords: Feature Modeling; Product Derivation; Software Product Line

Fixing Configuration Inconsistencies Across File Type Boundaries - Elsner, Christoph; Lohmann, Daniel; Schröder-Preikschat, Wolfgang (Proceedings of the 37th EUROMICRO Conference on Software Engineering and Advanced Applications, 2011)
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. © 2011 IEEE.
UnivIS-Import:2015-04-16:Pub.2011.tech.IMMD.IMMD4.fixing
Keywords: Model Inconsistency Fixing; Software Configuration; Software Product Line

Leviathan: SPL Support on Filesystem Level - Hofer, Wanja; Elsner, Christoph; Blendinger, Frank; Schröder-Preikschat, Wolfgang; Lohmann, Daniel (Proceedings of the 14th International Software Product Line Conference (SPLC-Poster 2010), 2010)
A lot of configurable software, especially in the domain of embedded and operating systems, is configured with a source preprocessor, mostly to avoid run-time overhead. However, developers then have to face a myriad of preprocessor directives and the corresponding complexity in the source code, even when they might only be working on the implementation of a single feature at a time. Thus, it has long been recognized that tool support is needed to cope with this '#ifdef hell'. Current approaches, which assist the software developer by providing preprocessed views, are all bound to a special integrated development environment. This eliminates them from being used both in industry settings (where domain-specific toolchains are often mandated) and in open-source projects (where diverse sets of editors and tools are being used). © 2010 Springer-Verlag Berlin Heidelberg.
UnivIS-Import:2015-04-16:Pub.2010.tech.IMMD.IMMD4.leviat
Keywords: Leviathan; Software Product Lines; Variability Implementation; Preprocessor-Based Configuration; Toolchain-Independent Variability Support; Filesystem Views; VAMOS

Light-Weight Tool Support for Staged Product Derivation - Elsner, Christoph (Proceedings of the 16th International Software Product Line Conference (SPLC 2012), 2012)
Tool support that checks for configuration errors and generates product parts from configurations can significantly improve on product derivation in product line engineering. Up to now, however, derivation tools commonly disregard the staged derivation process. They do not restrict configuration consistency checks to process entities such as configuration stages, stakeholders, or build tasks. As a result, constraints that are only valid for certain process entities must either be checked permanently, leading to false positive errors, or one must refrain from defining them at all. This paper contributes a light-weight approach to provide tailored tool support for staged product derivation. Compared to previous approaches, it is not tied to a single configuration mechanism (e.g., feature modeling), and also accounts for the stakeholders involved and the build tasks that generate product parts. First, the product line engineer describes the derivation process in a concise model. Then, based on constraint checks on the configuration (e.g., a feature model configuration) that are linked to the modeled entities, comprehensive tool support can be provided: Configuration actions can be guided and restricted depending on the configuring stakeholder in a fine-grained manner, and constraints attached to a build task will only be checked if it actually shall be executed. Finally, in combination with previous work, the paper provides evidence that the approach is applicable to legacy product lines in a light-weight manner and that it technically scales to thousands of constraint checks. Copyright © 2012 ACM.
UnivIS-Import:2015-04-16:Pub.2012.tech.IMMD.IMMD4.lightw
Keywords: Product line; Staged product derivation; Tool support

Managing Emerging Configuration Dependencies in Multi Product Lines - Holl, Gerald; Thaller, Daniel; Grünbacher, Paul; Elsner, Christoph (Proceedings of the Sixth International Workshop on Variability Modelling of Software-Intensive Systems, 2012)
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 toolsupported 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. Copyright 2012 ACM.
UnivIS-Import:2015-04-16:Pub.2012.tech.IMMD.IMMD4.managi
Keywords: Configuration dependencies; Multi product lines; Systems-of-systems; Tool support

Model-Driven Development versus Aspect-Oriented Programming - A Case Study - Hohenstein, Uwe; Elsner, Christoph (Proceedings of the 9th International Joint Conference on Software Technologies (ICSOFT 2014), 2014)
This case study compares two different technologies - model-driven development (MDD) and aspectoriented programming (AOP) - both trying to avoid redundant code, but with very different approaches. A real industrial software system, the OpenSOA platform, which had already applied a model-driven XML/XSL-T approach, is used as the basis for implementation and comparison. For evaluation purpose, we have re-implemented the XSL-T implemented logic with a corresponding AOP implementation in AspectJ. Taking into account several criteria, our case study indicates that the AOP implementation reveals its strengths in avoiding redundancy, better testability, and understandability. However, more advanced tooling could significantly improve the position of MDD for the latter. MDD is in turn the more flexible approach, allowing generation of arbitrary artefacts the design demands. As the main issue of the case study, to generate wrapper classes and boilerplate-code, is rather common, we believe that our results have potential to be transferred to other problem settings. Furthermore, we think that our evaluation criteria will help guiding others in making technology choices. We also give an outlook on how combinations of MDD and AOP may leverage the best of both worlds.
UnivIS-Import:2015-04-16:Pub.2014.tech.IMMD.IMMD4.modeld
Keywords: AOP; Aspectj; Case study; MDD; XSL-T

Model-Driven Engineering Support For Product Line Engineering - Elsner, Christoph; Groher, Iris; Fiege, Ludger; Völter, Markus (Aspect-Oriented, Model-Driven Software Product Lines - The AMPLE Way, 2011)
This chapter describes our approach for mapping the requirements processed by AMPLE techniques and tools, such as ArborCraft (Chapter 3), VML4RE (Chapter 5) and HAM (Chapter 5), to a product line architecture. In contrast to the implementation-related Chapter 6, which focuses on CaesarJ for implementing configurable software components, this chapter concentrates on a model-driven approach based on variability modelling, domain-specific languages (DSLs), architecture blueprints and templates, and libraries of artefacts (arbitrary software components, configuration and deployment data, etc.).Model-driven engineering (MDE) is an approach that captures the key features of the system used in models, and develops and refines these models during development until code is finally generated. Models are defined at different conceptual levels, and are combined and transformed from a higher level of abstraction to a more concrete one. By integrating MDE into software product line engineering (SPLE), solution space artefacts can be systematically derived from problem space concepts, leading to a higher automation in application engineering saving cost and time. Models abstract the problem and facilitate rigorous descriptions using terms and concepts that are familiar to people who work in the domain of the problem, rather than in terms only familiar to IT experts. In particular, essential improvements can be achieved by using DSLs to represent the system design with terminology and abstractions of the problem domain, which is easier to understand for problem domain experts.
UnivIS-Import:2015-04-20:Pub.2011.tech.IMMD.IMMD4.modeld

Moving Towards Industrial Software Ecosystems: Are Our Software Architectures Fit for the Future? - Schultis, Klaus-Benedikt; Elsner, Christoph; Lohmann, Daniel (Proceedings of the 4th International Workshop on Product LinE Approaches in Software Engineering (PLEASE 2013), 2013)
The development of large-scale software productlines within large enterprises commonly involves various internal business units. Although within the same enterprise, each business unit has individual motivations and participation interests. For coordinating development, the emerging discipline of software ecosystems intents to explicitly discover and analyze the different players' interests, and manage them, often by means of a suitable software architecture. Already within a single enterprise, this discipline can be of high value. Instead of detailed managerial orders to coordinate internal interactions, an analysis of the players, their interests, and a suitable software architecture may slacken organizational structures and simplify processes. We have started to analyze the ecosystems of several Siemens internal product-lines in order to determine the different players and their interests, and to derive suitable software architectural requirements from this setting. This will enable us to compare these requirements to the actual architecture, for identifying reusable pain points and best practices of the existing system. However, there is no systematic (A) approach to model and analyze the collaboration among the participants from a technical perspective, as well as (B) to derive reusable architectural design-patterns and anti-patterns from such software ecosystems. By illustrating these problems using an existing software productline that moves towards a software ecosystem, we are looking for answers to the two questions above to evaluate whether our product-lines are fit for a future as internal software ecosystems. © 2013 IEEE.
UnivIS-Import:2015-04-16:Pub.2013.tech.IMMD.IMMD4.moving

Multi-Level Product Line Customization - Elsner, Christoph; Schwanninger, Christa; Schröder-Preikschat, Wolfgang; Lohmann, Daniel (New Trends in Software Methodologies, Tools and Techniques (SoMeT 2010), 2010)
Managing and developing a set of software products jointly using a software product line approach has achieved significant productivity and quality gain in the last decade. More and more, product lines now are becoming themselves entities that are sold and bought in the software supply chain. Customers build more specialized product lines on top of them or derive themselves the concrete products. As customers have different requirements, whole product lines now may vary depending on customer needs-they need to be customized. Current approaches going beyond the scope of one product line do not provide appropriate means for customization. They either are tailored to specific implementation techniques, only regard customization on few levels (e.g., only source code level), or imply a lot of manual effort for performing the customization. The PLiC Approach tackles this challenge by providing a generic, reusable reference architecture and methodology for implementing such customizable product lines. In the reference architecture, a product line consists of so-called product line components (PLiCs), which are flexibly recombinable slices of a formerly monolithic product line, thereby maintaining strict separation of concerns. The approach furthermore comprises a tool-supported methodology for recombination of PLiCs based on customer needs and thus minimizes manual intervention when customizing. We implemented the PLiC Approach for a complex model-driven product line, where it facilitates comprehensive customization on various levels in the models, the model transformation chain, and in the source code with reasonable effort. This gives evidence that our approach can be applied in various other contexts where the same or fewer customization levels need to be considered.
UnivIS-Import:2015-04-16:Pub.2010.tech.IMMD.IMMD4.multil
Keywords: Model-driven development; Software product line architecture; Software product line development

Product Derivation for Solution-Driven Product Line Engineering - Elsner, Christoph; Lohmann, Daniel; Schröder-Preikschat, Wolfgang (Proceedings of the First International Workshop on Feature-Oriented Software Development (FOSD 2009), 2009)
Solution-driven product line engineering is a project business where products are created for each customer individually. Although reuse of results from former projects is widely done, configuration and integration of the results currently is often a manual, time-consuming, and error-prone task and needs considerable knowledge about implementation details. In this paper, we elaborate and approach the challenges when giving automated support for product derivation (i.e., product configuration and generation) in a large-scale solution-driven product line context. Our PLiC approach resembles the fact that, in practice, the domain of a large product line is divided into sub-domains. A PLiC (product line component) packages all results (configuration, generation, and implementation assets) of a sub-domain and offers interfaces for configuration and generation. With our approach we tackle the challenges of using multiple and different types of configuration models and text files, give support for automated product generation, and integrate feature modeling to support application engineering as an extensive development task. Copyright 2009 ACM.
UnivIS-Import:2015-04-16:Pub.2009.tech.IMMD.IMMD4.produc
Keywords: Software Product Line; Feature Modelling

Solution-Driven Software Product Line Engineering - Groher, Iris; Fiege, Ludger; Elsner, Christoph; Schwanninger, Christa; Völter, Markus (Aspect-Oriented, Model-Driven Software Product Lines - The AMPLE Way, 2011)
As described in Chapters 1, 2 and 10, the product- and solution-driven businesses found in industrial settings have different needs on tools and methods. They do not require completely disparate approaches, but their respective focus emphasises different parts of the product line engineering process and its tools. A one-size-fits-all approach to PLE is not feasible.This chapter investigates the characteristics of solution-driven business from the PLE perspective and shows how PLE tools and techniques presented in the previous chapters can be applied in such a setting.
UnivIS-Import:2015-04-20:Pub.2011.tech.IMMD.IMMD4.soluti

Subdomain-oriented Implementation of Model-driven Software Product Lines - Elsner, Christoph (GTTSE 2009 - Pre-proceedings (not publicly published), 2009)
UnivIS-Import:2015-04-16:Pub.2009.tech.IMMD.IMMD4.subdom
Keywords: Software Product Line; Model-Driven Software Development

Supporting Awareness During Collaborative and Distributed Configuration of Multi Product Lines - Holl, Gerald; Gruenbacher, Paul; Elsner, Christoph; Klambauer, Thomas (Proceedings of the 19th Asia-Pacific Software Engineering Conference (APSEC 2012), 2012)
Today's large-scale software systems are frequently based on system-of-systems architectures comprising multiple heterogeneous systems. Multi product lines have been presented as an approach to ease their development through systematic reuse. In multi product lines different users and teams are involved in product derivation. Users configure the involved product lines in a collaborative and distributed manner. It is challenging to ensure awareness regarding the configuration choices of users configuring related product lines in such a setting. We present a tool-supported approach that aims at increasing awareness by discovering dependencies and sharing configuration information during the collaborative and distributed product derivation of a multi product line. Our approach uses a bulletin board mechanism for sharing configuration information. It further implements a request-publish-subscribe mechanism for revealing possible dependencies and presenting the information relevant to the users' specific configuration tasks. We evaluated the usability and utility of our approach in a two-phase study involving twelve industrial experts. The evaluation demonstrates the usability and utility of our approach to foster awareness regarding configuration dependencies during the distributed product derivation of a multi product line. © 2012 IEEE.
UnivIS-Import:2015-04-16:Pub.2012.tech.IMMD.IMMD4.suppor
Keywords: awareness; distributed configuration; empirical study; multi product lines; tool support

Toolchain-Independent Variant Management with the Leviathan Filesystem - Hofer, Wanja; Elsner, Christoph; Blendinger, Frank; Schröder-Preikschat, Wolfgang; Lohmann, Daniel (Proceedings of the 2nd Workshop on Feature-Oriented Software Development (FOSD 2010), 2010)
Preprocessor-configured software needs tool support for the developer to be able to cope with the complexity introduced by optional and alternative code blocks in the source. Current approaches, which assist the software developer by providing preprocessed views, are all bound to a special integrated development environment. This eliminates them from being used both in industry settings (where domain-specific toolchains are often mandated) and in open-source projects (where diverse sets of editors and tools are being used and freedom of tool choice is crucial for the project success). We therefore propose to tackle the problem at a lower level by implementing variant views at the filesystem level. By mounting one or more variants using our Leviathan filesystem, we enable the use of standard tools such as syntax validators, code metric analysis tools, or arbitrary editors to view or modify a variant. The major benefit (and challenge) is the support for automatically writing back to the configurable code base when editing one of the mounted variant views. © 2010 ACM.
UnivIS-Import:2015-04-16:Pub.2010.tech.IMMD.IMMD4.toolch
Keywords: Leviathan; Software Product Lines; Variability Implementation; Preprocessor-Based Configuration; Toolchain-Independent Variability Support; Filesystem Views; Käsebrot; VAMOS; CiAO

Towards Separation of Concerns in Model Transformation Workflows - Elsner, Christoph; Lohmann, Daniel; Schröder-Preikschat, Wolfgang (Proceedings of the 12th Software Product Line Conference (SPLC 2008), Second Volume., 2008)
UnivIS-Import:2015-04-16:Pub.2008.tech.IMMD.IMMD4.toward
Keywords: Aspect Orientation; Model-Driven Software Development; Software Product Lines; Model Transformation Workflows

Using MARTE in Code-centric Real-time Projects Providing Evolution Support - Ulbrich, Peter; Elsner, Christoph; Hoffmann, Martin; Schmid, Reiner; Schröder-Preikschat, Wolfgang (Proceedings of the First Workshop on Model Based Engineering for Embedded Systems Design (M-BED 2010), 2010)
UnivIS-Import:2015-04-16:Pub.2010.tech.IMMD.IMMD4.usingm
Keywords: Real-time System; MARTE; Reverse Engineering; I4Copter

Variability Modelling Throughout the Product Line Lifecycle - Elsner, Christoph; et al. (Proceedings of the ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems (MODELS 2009), Empirical Results Track, 2009)
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. © 2009 Springer Berlin Heidelberg.
UnivIS-Import:2015-04-16:Pub.2009.tech.IMMD.IMMD4.variab
Keywords: Software Product Line; Variability Modelling