Various approaches show that software product lines can be implemented using the Model-Driven Engineering concept of successive model re nements. An important aspect of Product-Line Engineering (PLE) is the management of variability. In this paper we propose a strategy to let the model transformation language ATL handle the variability. We consider a transformation sequence that can generate a family of products. Furthermore, we model the variability separately in a feature diagram. In our case, the features from this diagram will have corresponding feature realization artefacts whose blueprints are de ned as meta classes residing in meta models throughout the transformation sequence. We use model-to-model transformations written in ATL to instantiate these feature realization artefacts from the meta models, guided by the feature model's feature selection. This paper shows that the conventional language constructs of ATL (ie. rules) are ine ective in managing variability this way. We therefore extend the concrete syntax of ATL with the concept of variability rules. This yields a rst-class language construct for variability management. Variability rules are declarative, use implicit scheduling and are a true modular extension; they inherit from the normal rule class in the ATL meta model. This means that they have the same quality properties as normal rules. The execution semantics of variability rules { execute i the corresponding variant in the feature model is selected { is implemented in a higher-order transformation, which compiles an extended ATL model back to a normal ATL model, therefore no new ATL plugin needs to be installed.
Various approaches show that software product lines can be implemented using the
ModelDriven Engineering concept of successive model re nement. An important aspect of PLE is the
management of variabilities. This can be done in various ways [
This paper aims to provide rst-class variability management means for the model
transformation language ATL [
Variability rules are best used in the context of a transformation sequence which successively re nes models, and where blueprints of feature realization artefacts reside in the meta models. Thus, meta models de ne the complete product space by de ning feature realizations for every feature. The variability rules instantiate and integrate a particular set of feature realizations into a nal 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, feature realization artefacts in order to enable automatic product derivation. Speci cally, the feature model should be the driver for con guring/assembling a product family member. Rules are purpose-built for de ning 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. 2
This paper rst 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. 3
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. 3.1
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 di erent 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 model FM : a relational database denoted by RDBMS, and an object database GoogleAppEngine. The meta model outMM shows that each Model element has a DatabaseTechnology element aggregated.
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. 3.2
In ATL, rule inheritance could be used for guiding the feature assembly process in the above example, as shown (partially) in Listing 1.1. 14 g 15 16 rule EClass2Model GoogleAppEngine extends EClass2Model f 17 from 18 a : inMM ! EClass ( f a l s e ) 19 to 20 db : outMM ! GoogleAppEngine 21 g
Listing 1.1. Using rule inheritance in normal ATL to deal with variability management is insu cient.
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 speci c variant.
There is a sub rule for each feature, both specializing the rule EClass2Model with a speci c 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. 3.3
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 di erent rules with the same from-clause. But doing something `for each EClass' is now not possible, which was speci cally 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. 4
This section describes the concept of variability rules. The syntax and semantics are not much di erent from normal ATL rules. 4.1
A variability rule looks like a normal rule, prepended with the variability keyword: 1 v a r i a b i l i t y rule RDBMS configures EClass2Model f 2 from to a : inMM ! EClass db : outMM ! RDBMS (
name < a . name+ 'RDBMS ' )
Listing 1.2. Extended concrete syntax of ATL with variability rules.
Observing the example from Listing 1.2, the syntax is a bit di erent than normal rules. In the rst line, `RDBMS' refers to the feature from the feature model. Secondly, `EClass2Model' refers to a normal rule. This variability rule is said to `con gure' a normal rule. Finally, the from-clause is identical to the one in ECLass2Model. 4.2
The semantics is as follows: i) a variability rule `con gures' 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 con gure the same normal rule.
This way, speci c 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 de ned) 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 de ne what should be instantiated if a certain feature is selected.
The next section shows how variability rules are implemented. 5
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 con gure. Then, these consolidated to-clauses are added to the normal rule that is con gured. This results in a set of normal rules whose to-clauses only contain the to-clauses from the relevant variability rules, e ectively 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. 6
During this research we identi ed a di erent 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 de ne 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 rst give an example of this variability type. 6.1
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 de ning 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 con gured, also a variable from this base rule's to-clause is speci ed, 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.4.
A f t e r r u n n i n g t h e HOT, t h e v i e w s a r e bound here , s i n c e t h e v a r i a b i l i t y r u l e s s p e c i f i e d t h i s 25 v a r i a b i l i t y rule TreeView configures 26 EClass2Model . c f 27 from 28 a : inMM ! EClass 29 to 30 v i e w s : outMM ! Tree ( 31 name < a . name+ ' TreeView ' 32 ) 33 g
Listing 1.3. Extended concrete syntax of ATL with variability rules again to handle dependent variability. 6.3
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 con gured. The point from which it is called is, in this case, the Controller with variable c, as thecon gures-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 di er 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. 1 Base r u l e , a f t e r t h e HOT has run 2 rule EClass2Model f 3 from 4 a : inMM ! EClass 5 to 6 7 8 9 10 11 12 e l s e 13 Sequence fg 14 endif , 15 v i e w s < i f c : outMM ! C o n t r o l l e r (
. . . v i e w s < i f thisModule . isAnnotatedWith ( a , ' GridView ' ) then thisModule . Grid ( a )
Sequence fg endif , v i e w s : outMM ! GridView (
name < a . name+ ' TreeView ' v i e w s : outMM ! TreeView ( name < a . name+ ' TreeView ' Listing 1.4. The HOT compiles the variability rules to lazy rules and the bindings are done in the speci ed meta element in the base rule.
The method of annotating the model is also work-in-progress. Our approach will be similar to
[
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 de ning ordinary ATL rules. 7
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 re nement, therefore we explain di erent related approaches brie y.
The approach of [
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 modi ed, 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 a ected, like toclauses or bindings.