Documenting Application-Specific Adaptations in Software Product Line Engineering

Abstract

Software product line engineering distinguishes between two types of development processes: domain engineering and application engineering. In domain engineering software artefacts are developed for reuse. In application engineering domain artefacts are reused to create specific applications.Application engineers often face the problem that individual customer needs cannot be satisfied completely by reusing domain artefacts and thus applicationspecific adaptations are required. Either the domain artefacts or the application artefacts need to be modified to incorporate the application-specific adaptations. We consider the case that individual customer needs are realised by adapting the application artefacts and propose a technique for maintaining traceability between the adapted application artefacts and the domain artefacts. The traceable documentation of application-specific adaptations is facilitated by an application variability model (AVM) which records the differences between the domain artefacts and the application artefacts of a particular application. The approach is formalised using graph transformations.

Software product line engineering and variability management: achievements and challenges

“…In most industrial cases, customer-specific applications cannot be derived entirely from the domain artifacts alone. Therefore, so called customer-specific extensions have to be implemented during application engineering [1], [8], [9].…”

“…Product line variability is documented in so-called variability models. The SPLE framework in Figure 1 differentiates between two types of variability models: Domain variability models and application variability models (cf., [1], [8]).…”

“…In this case, customer-or market-specific extensions or adjustments of the common and variable artifacts are required. The required adjustments can be made by either adjusting the domain artifacts (e.g., introducing additional product line variability) or by adaptations of the application artifacts [8].…”

“…Each valid combination of features represents a potential product line application. 8 Since the introduction of Feature-Oriented Domain Analysis (FODA) by Kang et al in the 1990ies, over 40 different feature model dialects have been proposed [17]. Based on the expressiveness of those extensions, they can be grouped into three categories: basic feature models (offering mandatory, alternative and 'or' features, as well as 'requires' and 'excludes' cross-tree constraints), cardinality-based feature models (offering, in addition, UML-like multiplicities for feature selection [m..n]), and extended feature models (adding arbitrary feature attributes; e.g., to express variation in quality requirements).…”

Evaluating Comprehension and Utilization of Variability Aspects in UML-Based Models

“…Variability is specified in terms of mandatory vs. optional features, alternatives, OR features, 'require' and 'exclude' dependencies among features, feature groups, and composition rules. UML-based methods (e.g., [ 13], [ 26], [ 28], [ 32], and [ 34]) usually suggest profiles for handling variability-related issues, including specification of mandatory and optional elements, dependencies among elements, variation points, and possible variants [ 15]. Some UML-based methods suggest extending UML or representing variability aspects orthogonally to "regular" UML models of the product families, e.g., [ 14].…”