Existing approaches that use CVL have in common the need for a tool that fully supports the CVL standard and that allows customizing/extending the CVL approach to their needs, in order to make the approaches viable.
vEXgine provides a working implementation of the CVL Engine that can be used in third party applications (e.g., at runtime to implement Dynamic SPLs), independently from the CVL tools, and an API to extend our CVL engine.
While existing tools focus on the variability abstraction by providing graphical tools for the definition of the variability and resolution models, vEXgine focuses on the resolution of the variability,
by providing support for the customization of the variation points semantics, in addition to the definition of custom transformations using Opaque Variation Points (OVPs).
The delegation mechanism
During vEXgine execution, it delegates its control to an M2M engine in charge of executing the transformations defined by the variation points.
By extending this delegation mechanism it is possible to modify the way variation points are realized over the base model.
The most basic modification is to use a new M2M transformation engine that supports different transformation languages such as ATL, QVT (Query/View/Transformation), or Epsilon Transformation Language (ETL).
However, it is also possible to execute code instead of model transformations to resolve variability.
vEXgine provides an implementation of the M2M engine in ATL that allows performing any model transformation specified in ATL.
vEXgine extends the CVL metamodel to support:
- Custom semantics for all variation points
- Negative variability
- Multiple MOF references
The semantics of each variation point can be provided as a external and independent file (e.g., an ATL model transformation).
The semantics of the variation points can be executed even when the VSpec bound to the variation point is resolved negatively (i.e., it is not selected in a configuration of the resolution model).
Variation points can reference multiple elements in the base models (e.g., multiple targets).
The CVLEngine class defines the skeleton of the materialization process in an “materialize” operation, deferring some additional steps to subclasses following the Template Method design pattern.
The materialize method completely resolves the variability as specified in the CVL standard, and lets subclasses define certain steps such as the checking of pre and post-conditions.
The CVLEngine delegates its execution to an ExecutionEngine in charge of executing the semantics specified in the variation points.
This ExecutionEngine can be an M2M transformation engine (M2MEngine) or any other implementation (e.g., a JVMEngine for Java, a C++Engine for C++) that performs the modifications defined in the variation points over the base model.
vEXgine also provides a GUI that implements the CVL engine using the vEXgine API.
It is released as an independent Java application, and allows integrating and executing the CVL approach both at design time in SPLs and at runtime for Dynamic SPLs.
vEXgine receives as input the variability model, the resolution model, the base models and their metamodels; and resolves the variability generating a resolved model.
The variability and resolution models conform to the CVL metamodel.
The base models include the core models over which the variability will be resolved, and the models, if needed, that will be used as third-party libraries to be used during materialization (e.g., for the FragmentSubstitution variation point).
By default, vEXgine provides the UML metamodel for base models conformed to UML, but the use of any other DSL is possible by providing its own metamodel.