Skip to content
  Kermeta  
 

Reconciling Automation and Flexibility in Product Derivation

Document Actions
Reconciling Automation and Flexibility in Product Derivation

Authors :Gilles Perrouin,Jacques Klein, Nicolas Guelfi and Jean-Marc Jezequel

About the prototype:


This prototype implements a product derivation approach for Software Product Line. First, the tool allows a specification of a pre-configuration of the product by selecting desired features in a feature diagram and automatically composing their related product-line core assets. Then, the tool allows the adaptation of the pre-configured product to its customer-specific requirements via a combination of derivation primitives written by the product engineer.

Installing the prototype


Our prototype is currently under development, but a beta version can be downloaded here. Our tool is developed as an eclipse project using the Kermeta language. The current version is 0.0.1, it is available as a zip file which contains the Kermeta project for eclipse. The tool requires kermeta 1.0.0 or later. Currently, Kompose is not fully integrated in our tool. Consequently, Kompose has to be installed to customize a product (to transform a ‘toto.kompt’ file to a ‘toto.kompose’ file). Moreover, the current version of our prototype does not support the composition of the core assets instantiation constraints, and thus we cannot validate a derived product according to these constraints. A new version of our prototype will be soon available. This version will integrate Kompose and will support the composition of the core assets instantiation constraints.

The zip file contains:

  • The metamodel of feature diagram ‘FeatureDiagram/metamodel/featureDiagram.ecore’ (the file ‘featureDiagram.ecoredi’ is the graphical representation of the metamodel using topcased)
  • The feature modeling constraints written in Kermeta in the files ‘FeatureDiagram/constraint/FDConstraints.kmt’ and ‘FeatureDiagram/constraint/ProductConstraint.kmt’ (the invariants are checked by invoking the method checkAllInvariants on an object)
  • The ‘Kompose-01’ folder which contains the Kompose tool.
  • The file ‘FeatureDiagram/customization/customization.kompt’ which contains the directives to customize a product

  • The folders ‘FeatureDiagram/models’, ‘FeatureDiagram/launcher’ and ‘FeatureDiagram/products’ concerned the Demo presented below.


Note: the metamodel of feature diagram ‘FeatureDiagram/metamodel/featureDiagram.ecore’ has to be registered to correctly work. To do that, right click on the file and choose ‘EPackages registration -> Register EPackages into repository’

Demo: Product Catalog SPL


The zip file also contains an example called ProductCatalog. The feature diagram is depicted in figure 1 and it is implemented in the file ‘FeatureDiagram/models/catalogFeature.xmi’.



Figure 1: ProductCatalog Feature Diagram

The feature diagram ‘catalogFeature.xmi’ is conforms to the metamodel of feature diagram presented in Figure 2. The metamodel is implemented in the file ‘FeatureDiagram/metamodel/featureDiagram.ecore’. Note that to create a new feature diagram, you can open the file ‘featureDiagram.ecore’ with the reflexive editor, and right click on the FeatueDiagram class. Then choose the ‘Create Dynamic Instance…’ option.


Figure 2: Feature Diagram Metamodel

In our approach a feature is related to a set of models defining core assets. The Figure 3 presents the feature model of Figure 1, but with the core assets detailed. These core assets are present in the folder ‘FeatureDiagram/models/CD-CatalogFeatures’.



Figure 3: Example of core assets

The top of Figure 4 represents a subset of features corresponding to a valid product derived from the feature model in Figure 3. The bottom of Figure 4 presents the result of the merge performed with Kompose of the core assets related to the features of the derived product. This figure illustrates the fact that, for instance, classes with the same name are not duplicated but effectively merged. The product skeleton is automatically obtained from the feature model in Figure 3 by selecting the expected features and launching the derivation process written in Kermeta. To select a feature, open the ‘FeatureDiagram/models/catalogFeature.xmi’ file with the ecore reflexive editor and open the eclipse view called ‘Properties’. Then put ‘true’ for the property ‘selected’ of a feature if you want to select this feature. To launch the derivation process, launch the Kermeta file ‘FeatureDiagram/launcher/ProductGenerator.kmt’. Note that the invariant written in the files ‘FeatureDiagram/constraint/FDConstraints.kmt’ and ‘FeatureDiagram/constraint/ProductConstraint.kmt’ allow the validation of the feature diagram and derived product.



Figure 4: Result of the core assets composition for the derived product

Once the product skeleton has been built by composing core assets thus completing the pre-configuration step, our prototype allows the customization of this skeleton with respect to specific requirements. To do so we can use kompose pre and post-directives which are applied on the composed product model. Kompose provide a simple textual language to combine directives. The support of VideoCatalog which require to update thumbnails and to add a new Video class is expressed in the file: ‘FeatureDiagram/customization/customization.kompt’ and as follows:

Post {

create Class as $c

$c.name = "Video"

catalogStructure.eClassifiers + $c

catalogStructure::Product::thumbnail.eType = $c

}


Post states that it is a post-directive block (i.e. processed after model composition). First line of the block use a create directive to create class $c which is then named Video (second line). This new class is added to the model as an element of CatalogStruture package containing the model of the product (third line). Finally thumbnail is updated to support video. This file is transformed into a “.kompose” file instance of the Kompose directive metamodel. This model is actually used by Kompose to process directives.
Our PD process ends with the verification of product validity with respect to the SPL. To do so we check relevant instantiation constraints on the completed product model, this is the case here since we do not have made any change on product name and price attributes.