Various approaches show that software product lines can be implemented using the Model-Driven Engineering concept of successive model refinement. An important aspect of PLE is the management of variabilities. This can be done in various ways [5] [3][1] [2].
This paper aims to provide first-class variability management means for the model transformation language ATL [4], using a separate feature model for configuration. The basic modular construct of rule-based model transformation languages, a rule, is used as a starting point. In ATL, there are five types of rules: normal rules, abstract rules, rules that inherit from other rules (ie. sub rules), lazy rules and called rules. This paper introduces variability rules. Ideally, variability rules should have the same quality properties as normal rules.
Variability rules are best used in the context of a transformation sequence which successively refines models, and where blueprints of feature realization artefacts reside in the meta models. Thus, meta models define the complete product space by defining feature realizations for every feature. The variability rules instantiate and integrate a particular set of feature realizations into a final product, according to the feature model's selection.
The reason for using a transformation rule as key construct for managing variability is the observation that features from a feature model have to be associated with, or mapped to, fea-ture realization artefacts in order to enable automatic product derivation. Specifically, the feature model should be the driver for configuring/assembling a product family member. Rules are purpose-built for defining mappings. Furthermore, since rules have mature mechanisms for matching, querying and creating (instances of) meta model elements, and thus (instances of) feature realization elements, they are well-suited for integrating feature realizations with the rest of the system. Furthermore, rules are modular constructs with a declarative nature, which makes them easy to use and allow elegant implementations as opposed to more imperative solutions.
This paper first explains the need for variability management in model transformations in model transformations in Section 3. Section 4 describes the concept of variability rules, their syntax and semantics. Section 5 explains how the variability rules are implemented in a higher-order transformation.
During this project, a more complex type of variability was discovered. This type of variability not only has a dependency on the feature model, but also on the input model of the transformation. For handling this type of variability, the variability rule concept and concrete syntax are extended a bit further, and this is explained in Section 6. This last part is currently work-in-progress, but there are already some results worth mentioning.
The true open issues are explained in Section 7, followed by Section 8 which shows related work. We conclude this paper in Section 9.
Model transformations are a central concept in MDE, and by using a transformation sequence as a software product line generator, model transformations should be capable of dealing with variabilities.
To illustrate variability management in model transformations, we describe an example case where transformations steer the feature assembly process. This example is based on a real case where input meta models conforming to Ecore are transformed into a model of a web-based, datacentric information systems with basic create/read/update/delete (CRUD) operation support, which is in turn transformed into code. The model-to-model step is shown in Figure 1. The meta model outMM is an excerpt of the real case meta model, and only shows a Model class (note: a Model from the Model-View-Controller pattern), as well as a DatabaseTechnology element.
Every derived instance model of outMM will contain a Model element for each instance of an EClass element from the source meta model inM. This Model element will have the same name as the EClass's name attribute, concatenated with the string 'Model'. In this case there is only one instance of EClass in the source meta model, Person. This results in the instantiation of a Model element with the name attribute set to 'PersonModel'. Note that a different input meta model is likely to have multiple instances of EClass, and will therefore transform in a model with multiple instances of the Model meta class. In the real case, an MVC pattern is generated for each EClass.
The variability in this case (apart from varying the input model) is the type of database technology that a resulting applications uses. There are two variants, as shown in the feature In the feature model FM of this example, the RDBMS variant is selected, so the resulting model outM has an instance of an RDBMS realization artefact for each EClass source element.
The next section shows how implementing this using conventional ATL constructs raises some problems.
In ATL, rule inheritance could be used for guiding the feature assembly process in the above example, as shown (partially) in Listing 1.1. Note that the from-clause in the rule EClass2Model matches on inMM!EClass, stating that the instantiation of the feature realization artefact should be done for each EClass instance. We use rule inheritance to instantiate a specific variant.
There is a sub rule for each feature, both specializing the rule EClass2Model with a specific database technology. According to the selected feature, here simply switched by true if selected, and false otherwise, the correct sub rule is called, and the super rule's content is inherited.
This situation shows that feature realizations often have to be integrated into the common base, according to some rationale, in this case for each EClass. Therefore this case uses rule inheritance, which seems a necessary strategy, but the problem with this is that ATL does not support matching a single source model element by more than one rule. So, what if there are more features, apart from database technology, that also have to be instantiated for each EClass? Or what if both features are allowed, because they are, for instance, both optional (ie. both fromclauses are set to true)? Then, multiple rules should be called for a single source element, which is not supported.
Note that also, the true/false must be switched manually here, or helpers have to be implemented that navigate the feature model and check if a particular feature is selected.
As an alternative, a rule which matches on elements from the feature model FM could be used, instead of matching on the input meta model. This usually avoids having different rules with the same from-clause. But doing something 'for each EClass' is now not possible, which was specifically intended. One could use imperative code, but this is not recommended, nor is it elegant.
Thus, there is not a good way to let features guide a model transformation, at least not without resorting to imperative ATL code. We provide a more elegant, easy to use solution, by extending ATL with the concept of variability rules, as the next section will explain.
This section describes the concept of variability rules. The syntax and semantics are not much different from normal ATL rules.
A variability rule looks like a normal rule, prepended with the variability keyword: Observing the example from Listing 1.2, the syntax is a bit different than normal rules. In the first line, 'RDBMS' refers to the feature from the feature model. Secondly, 'EClass2Model' refers to a normal rule. This variability rule is said to 'configure' a normal rule. Finally, the from-clause is identical to the one in ECLass2Model.
The semantics is as follows: i) a variability rule 'configures' a normal rule, specializing its implementation, just like rule inheritance, ii) A variability rule is executed for each match, but if and only if the corresponding feature is selected in the feature model, iii) multiple variability rules can have the same from-clause, iv) multiple variability rules can configure the same normal rule.
This way, specific feature realization artefacts can be instantiated from the target meta model. Also, multiple rules that match on a single source model element can be called. This solution is very comparable to a conventional declarative mapping in a normal rule, the implicit execution order property still holds.
Furthermore, the concern of selecting features is now cleanly separated. It is the feature model editor's responsibility to facilitate/constraint the selection. Variability rules act as a template; a modular piece of code that is not part of an (explicitly defined) imperative process, used for instantiating a particular feature. Thus, a developer can write one or more variability rules for each feature, without having to worry about concerns like selection constraints or execution order.The developer can just declaratively define what should be instantiated if a certain feature is selected.
The next section shows how variability rules are implemented.
The variability rules are implemented by a higher-order transformation (HOT), as shown in Figure 2. The HOT is created as follows: i) The ATL meta model is extended with a VariabilityRule EClass, yielding the ATL' meta model. ii) The concrete syntax of ATL is extended and a corresponding editor is created. iii) A HOT is developed in ATL which transforms an ATL' model into an ATL model. The HOT will be a used as preprocessing step in a transformation sequence.
The resulting ATL model is subsequently executed, to yield the aimed result. The compilation step of the HOT works as follows. First all the to-clauses of variability rules whose feature is selected are gathered, and these are grouped by the rule they configure. Then, these consolidated to-clauses are added to the normal rule that is configured. This results in a set of normal rules whose to-clauses only contain the to-clauses from the relevant variability rules, effectively resulting in a transformation that transforms a source model into a target model containing the selected features. In other words, the result is semantically equivalent to executing multiple rules that match on the same source model element. Note that since there is no de-facto standard for feature (meta) models, we used our own, which is not shown here. If one would want to use its own, a custom version of the (simple) ATL helper function isSelected(f : F eature) : Boolean (residing in the HOT) should be included in the higher-order transformation.
During this research we identified a different type of variability, which still cannot be solved using the version of variability rules discussed so far, but appeared very relevant. This type is called source model dependent variability, whereas the variability type discussed above is called source model independent variability. The name explains what it means: there is a type of variability that also depends on elements from the source model of the transformation. In other words, whether or not a variability rule should be executed not only depends on the feature model, but also on elements from the source model. At this stage, the implementation of variability rules cannot handle source model dependent variability, because there is no means to define a mapping between a feature from the feature model and a particular (instantiated) class. Therefore the syntax and semantics of variability rules are extended further, as this section shows.
To make things clear, we first give an example of this variability type.
Consider the input model in Figure 3. The model has a Person class, which has a reference to a Task class. In our real-life transformation sequence case, for each class a MVC pattern is created. This means that there is a View class generated for a Person and for a Task. At this point, assume that there are two types of views: a Grid and a Tree view, both displaying the data in their own way. It could very well be that the Person should have a Grid while a Task should have a Tree view. As can be seen, the transformation should only execute a variability rule if its matching element is annotated with Grid or Tree.
The next section explains how the concrete syntax is extended, to allow defining this mapping between source model elements and features.
The variability rule shown in Listing 1.3 shows a small syntax change. Next to referring to a base rule that is configured, also a variable from this base rule's to-clause is specified, in this case c (lines 16 and 26). This target element is the point where the elements from the to-clause of the variability rules will be bound.
This syntax provides enough information for the HOT to compile this into the code shown in Listing 1.
After the HOT is run, the resulting ATL model will look as shown in Listing 1.4. Every dependent variability rule will be compiled into a lazy rule. This lazy rule is called by the rule that is configured. The point from which it is called is, in this case, the Controller with variable c, as theconfigures-clause stated. The lazy rule call is part of an if-then-else expression, where the rule is only called if the source model element isAnnotatedW ith a certain feature.
This if-then-else statement is dynamic (ie. not hardcoded) from the perspective of the compiled ATL model, because it is the nature of the mapping. Hardcoding the binding is not possible, since it can differ per EClass in this case. Thus, the binding needs to be postponed to run-time of the ATL model that is resulted from the HOT. This was done so that the HOT (as shown in Figure 2) does not require the input meta model as an input; just the feature model and the ATL' model. This makes the HOT more modular, and reusable.
The reader might have noticed that this approach allows for illegal feature selections, if the annotations in the input meta model are wrongly put. To see this, assume that the class P erson has two annotations: << Grid >> and << T ree >>. But the feature model states that these are alternatives, so only one is allowed. This check can no longer be the responsibility of the feature model editor, as was the case with source model independent variability. In fact, the semantics of what is allowed and what not can be interpreted in various ways: (i) a Grid and a Tree are alternative per matching element (in this case inM M !EClass), or (ii) model-wide, ie. in the whole model there can be either GridxorT ree views. In our approach situation (i) seems appropriate, and this is what we will implement. This validity check is currently work-in-progress. The method of annotating the model is also work-in-progress. Our approach will be similar to [6], where a separate annotation model is used. A very simple concrete syntax is currently being developed, that can be compared with Cascading Style Sheets (CSS) [7]. CSS is widely-adopted to annotate HTML elements with style features. In our case, we use it to annotated source model elements with features from the feature model. Having a separate annotation model keeps the source model from being cluttered by annotations.
With this syntax, one is still able to create elements according to a rationale, in this case for each EClass. In other words, one can still apply the rationale of matching elements, like that is used when defining ordinary ATL rules.
Two things are currently work-in-progress and have not been solved completely. First, there is not yet a check that validates an annotated model when it comes to the selection of source model dependent features. As discussed, this responsibility cannot be outsourced to the feature model editor. Second, the annotation model implementation is not yet complete.
Our focus is not to give a complete overview of the related work, but to focus on handling variability in step-wise model refinement, therefore we explain different related approaches briefly. The approach of [5] is to weave variability capabilities into meta models using aspects. This means that the variability is not modeled in a separate model, which differs from our approach, where we separate this concern. In [3], also aspects are used, but this approach does use a separate variability model. This approach provides variability management mechanisms in transformation languages where aspects are used in the model transformation language XTend to implement variability management. Our implementation approach (using a HOT) differs from their aspectoriented implementation. Furthermore, their model transformation language is different. The authors of [1] provide an algebraic framework for managing variabilities, which is fundamentally different. The approach in [6] describes a method of annotating the input model which drives the transformation, using a separate annotation model. This approach is combined with our approach in a solution for managing source model dependent variability as described in the previous section. The approach from [2] also uses specialized types of rules to manage variability. However, their rules are implemented using native ATL [4] language constructs, or put differently, their approach is more a software pattern for managing variability. The usage of this pattern means that there is imperative code involved, which our approach avoids.
In this paper we addressed the problem of handling variability in a product line that is implemented using a transformation sequence. We proposed a way for handling variability in the model transformation language ATL. We have shown that normal ATL rules are able to handle variability, but not without problems (ie. imperative code, changing the transformation after the feature selection has changed). Therefore the approach was to create variability management means by introducing a new type of rule called variability rules. The motivation for adding a new type of rule was the observation that rules are purpose-built to do mappings, thus they are a good candidate to do the required mapping between feature model and meta models. Also, rules provide mature mechanisms for matching, querying, and instantiating meta model elements. Our concept achieved at least three things. First, the implicit execution order is maintained, yielding the same modularity properties as normal rules. Second, all the advanced mapping features of normal ATL can be used, as well as the rationale that is behind conventional rules; the developer can use the same rationale (of matching elements) for variability rules as for normal rules. Third, because it is a higher-order transformation, the ATL engine is not modified, so there is not a new ATL version that has to be installed (and maintained!). Instead, one could just chain the HOT into the transformation sequence. We have shown ways to solve two types of variability: source model independent, and source model dependent variability. For the latter, there are some open issues left. Firstly, there is not yet a way to check if a selection is valid. This check can no longer be outsourced to the feature model editor because it needs information from the source model. Secondly, the dependent case needs annotation on the source model of the transformation. This mapping will be done using a separate annotation model. This has not yet been implemented fully.
Finally, we are investigating cases of variabilities where parts of rules are affected, like toclauses or bindings.