Für eine korrekte Darstellung dieser Seite benötigen Sie einen XHTML-standardkonformen Browser, der die Darstellung von CSS-Dateien zulässt.

. .
Suche

SiPL - A Framework for delta-oriented model-based Software Product Line Engineering

Motivation

Model-Based Software Engineering (MBSE) and Software Product Line (SPL) Engineering are widely used approaches to handle complexity of software systems during development and to reduce time-to-market. Model-Based Software Product Line (MBSPL) Engineering combines both approaches. Models replace source code as primary implementation artefacts and are subjected to variability to generate model variants as products of an MBSPL.

Delta-Modeling (DM) is a language-independent, transformational approach for realizing (MB)SPLs. Figure 1 illustrates the overall approach.

Fig. 1: Delta Modeling Approach

Given a Feature Model specifying all products on a conceptual level in terms of Features, the MBSPL is implemented by specifying a Core Model and a set of Delta Modules. The core model represents a concrete product of the MBSPL, i.e. a model variant implementing a valid (sub-)set of features. A delta module defines transformations, also referred to as Delta Actions to realize further individual features and their interactions, which are not covered by the core model, by adding, removing or modifying model elements. Each delta module is attached with an Application Condition that is a propositional formula over the set of available features relating the delta actions defined by a delta module with a set of valid feature configuration. Given a valid feature configuration, the delta actions of all delta modules for which the application condition evaluates to true are applied onto the core model.

Functionality of SiPL

SiPL is a model-based delta-oriented framework that is realized on top of the Eclipse Modeling technology stack and that offers the following functionality:

  • Delta modules can be specified manually using a dedicated DSL, or they can be derived automatically from model differences.
  • Prodcuts can be automatically generated for a given configuration.
  • The overall set of delta modules can be analyzed for various interrelations, such as dependencies or conflicts, that are validated against the feature model to ensure domain compliance, e.g., conflicting delta modules aren't applied together for any valid configuration.
  • Refactoring operations can be assembled from an extensible construction kit of operations, such as merge or intersect, that derive new delta modules from existing ones to remedy detected problems and to simplify the delta modules and their interrelations.
  • An extensible set of quality metrics is offered to identify design flaws and to trigger appropriate refactorings to eliminate them.
  • Finally, visualization facilities are provided to support the developer in understanding occuring problems.