I. Introduction

Model Driven Engineering (MDE)

MDE, the use of models to represent software artefacts, helps manage complexity in software engineering by raising the level of abstraction [1]. While MDE comprises many different languages, in simple terms, a model is a graph, a set of nodes and the associations between them. Model transformations receive one model as input and produce another as output, making the changes specified by a set of transformation rules. If the model fragment specified in the match part of a transformation rule is found in the input, the model fragment in the apply part of the rule is produced in the output. For instance, if an automotive company wanted to refactor its software, it would execute model transformations in which existing software models were the input and the transformations rules were based on refactoring techniques.

Domain Specific Language for Transformations (DSLTrans) is a visual language in which such transformations can be performed [4].

Figure 1: Features _F0, _F1 and _F2 signify some three distinct properties of possible products. The feature model specifies that all products must have the property represented by _F0 and that the properties represented by _F1 and _F2 are mutually exclusive.

Software Product Lines (SPLs)

SPLs help manage complexity in software engineering by concisely representing a set of similar product variants, explicitly capturing product commonalities and differences [2]. For instance, the software in a car’s dashboard may differ across countries that use metric and imperial units; this necessitates the existence of a set of product variants. When product variants number in the hundreds or thousands, SPLs are particularly useful representations. Each product variant contained in an SPL corresponds to a unique combination of features, which signify key functionalities of products that may differ across variants. In the case of automotive dashboard software, one feature represents metric units, another, imperial units. A feature model, as seen in Figure 1, specifies constraints on the features. Some elements in an SPL might exist in some product variants and not others; associated with each element is a presence condition, a boolean expression, composed of features, that represents the circumstances under which the element is present.

Research Problem

Although model transformations and SPLs are individually powerful, the transformation of SPLs is traditionally inefficient and computationally expensive [3]. Each product represented by the SPL must be derived and individually transformed, after which the set of transformed product variants is arduously abstracted into a transformed SPL. This project sought to augment the DSLTrans language so that it could support the efficient transformation of entire SPLs instead of individual models.

Figure 2: In this lifted transformation, the input SPL has two match sites where the transformation rule applies. Hence, two apply sites are created. Since there are no commonalities across the apply sites, no merging is needed. The resulting output SPL is identical to the one that would have been created using the circuitous method of deriving individual products.

II. Approach

Lifting

Lifted transformations, as seen in Figure 2, operate on entire SPLs instead of individual models. In a lifted transformation, the transformation rules do not change, but the way in which they are applied to the input does [3]. Match sites are regions, or subgraphs, of the input SPL where a transformation rule can be applied. For each match site, a corresponding apply site, based on the apply part of the same rule, is produced. Identical elements across apply sites are merged to create the final output SPL.

Identifying a match site is complicated by the fact that, depending on the presence conditions, different products may only have fragments of the match site. Appropriate presence conditions must then be constructed so that only products possessing the entirety of a match site can be transformed; the transformed products are then associated with these constructed presence conditions. In Figure 2, the product with A1 and B1 only exists if feature _F1 is selected, so the corresponding transformed product, C1, has _F1 as its presence condition as well. The mutual exclusion of features _F1 and _F2 precludes A1 and A2 from coexisting.

This project focused on the implementation of certain aspects of lifting in an already partially lifted version of DSLTrans, namely existential matching, negative application conditions, and indirect links. Where in universal matching, all of the transformed products resulting from the application of a rule can coexist, existential matching precludes the coexistence of the transformed products. Negative application conditions (NACs) are optional additions to a transformation rule that specify when the rule should not apply. Since any elements satisfying a NAC would invalidate an otherwise valid match site, the transformation must assert the absence of such elements. Indirect links can be added to the match part of a rule to specify that some path should or should not exist between a pair of nodes, adding further expressive power to transformation rules.

III. Conclusion

At the conclusion of this project, the DSLTrans language engine had been lifted successfully so that it could support transformations on entire SPLs instead of just individual models. While a partial implementation of the basic aspects of lifting existed at the onset of this project, support for existential matching, negative application conditions, and indirect links were all newly added. Mechanisms for simplifying presence conditions were also introduced, reducing the size of output presence conditions by 78.6%.

Lifting the language permits modelers to use the same transformations that they have already written for individual models – in the preexisting language – on SPLs. Model transformations and SPLs have applications in areas such as the automotive and telecommunications industries, and lifting has been shown to be a scalable way of performing model transformations on an industrial scale: the technique was applied to convert realistic legacy GM models – with thousands of variants – into the AUTOSAR architecture [4]. The lifted DSLTrans language thus has the potential to be used in similar contexts, where model transformations and SPLs need to be used in conjunction in an efficient manner.

Acknowledgements

I am grateful to Claudio Gomes and Levi Lúcio for their guidance in navigating the DSLTrans and lifted DSLTrans codebases respectively. This research was funded in part by the National Science and Engineering Research Council (NSERC) of Canada.

References

[1] S. Sendall and W. Kozaczynski. Model Transformation: The Heart and Soul of Model-Driven Software Development. IEEE Software, 20(5):42–45, 2003. 


[2] P. C. Clements and L. Northrop. Software Product Lines: Practices and Patterns. SEI Ser. in SE. Addison-Wesley, 2001. 


[3] R. Salay, M. Famelis, J. Rubin, A. Di Sandro, and M. Chechik. Lifting Model 
Transformations to Product Lines. In Proc. of ICSE’14, pages 117–128, 2014. 


[4] Famelis, M., Lúcio, L., Selim, G., Di Sandro, A., Salay, R., Chechik, M., Cordy, J.R., Dingel, J., Vangheluwe, H. and Ramesh S: Migrating Automotive Product Lines: a Case Study. In Proc. of ICMT’15, 2015.