Model transformations need to be configured in order to satisfy particular user requirements in real scenarios. This paper introduces an strategy for configuring ATL transformations. This strategy, that is currently in practice in the MOSKitt tool, follows a model driven approach, where both the specification of configuration options and the user selections of those options are implemented as models. Additionally, the user interfaces that are provided by MOSKitt for selecting the configuration options are briefly introduced.
Model transformations play a key role in model driven software development approaches. Different kinds of model transformation (refinements, refactoring, translations, etc.) are applied during the development process in order to achieve the desired products (source code, reports, etc.). When developing a model transformation, the transformation analyst may identify different options for transforming some elements. One of these options may fit better in some scenario or satisfy some requirement whether other option may be more suitable in other scenarios. Therefore, in an industrial context, mechanisms for configuring the transformation in order to select between different options must be provided by model driven software engineering tools.
In this paper we introduce an approach for supporting the configuration of ATL [
The MOSKitt project aims to provide a set of open source tools and a technological platform for supporting the execution of software development methods which are based in model driven approaches, including graphical modeling tools, model transformations, code generation and collaboration support. This project is led by the Conselleria de Infraestructuras y Transporte (CIT) (Ministry of Infrastructures and Transport) of the Regional Government of Valencia, in Spain. The project was initiated in 2007 and their results are currently in practice by CIT and other companies and ministries in Spain.
The paper is structured as follows. Next in this section a running case study is introduced to illustrate the contents proposed approach. In Section 2 the strategy for implementing the configuration of ATL model transformation is introduced. Section 3 discusses how to deal with the configuration information in ATL transformation. Then, Section 4 presents the user interfaces that are currently available in MOSKitt to select the configuration options. Finally, Section 5 includes some conclusions and outlines our future works in this area. 1.1
Case Study In order to describe the approach for configuring model transformation, the classical transformation from UML2 to database models will be used. In this transformation we can find some patterns in the input models where different options can be selected. In this paper we will use as an example the transformation of UML2 Generalization elements into database elements. currentLevel), adding an extra Column for specifying the kind of Person (Person, Student or Professor). 2. OnlyChildTable: Transforming only leaf Classes into Table elements (Student and Professor in our example) and converting properties into columns (Professor table will have name and account columns whereas Student table will have name and currentLevel columns). 3. AllTables: Transforming every Class into a Table with a Column for every property and adding foreign keys from the Tables derived from specific Classes to the Tables derived from the general Classes (from Student to Person and from Professor to Person).
Of course, other UML2 elements can have transformation configuration options like, for instance, many to many associations, compositions and enumerations. 2
Approach for Configuring Model Transformations
The approach for configuring model transformations introduced in this paper, which
is depicted in Figure 2, follows a model driven strategy. Models are used both for
capturing the information about which are the transformation options and for
specifying the options that a user has selected for executing the transformation.
Attending the classification of configuration techniques that is introduced in [
Rules for Transf. “X”
Input Model “A”
ATL Config.
Initializer for Transf. “X”
Config. of Model A for Transf. “X”
ATL Transformation “X”
Output Model “B”
The metamodel of the Rules Catalog model is depicted in Figure 3. A Catalog is composed of ConfigurationPatterns. Different transformation Rules can be applied to a ConfigurationPattern.
The selected options for an specific execution of the transformation are specified in a transformation configuration model. In our approach, ATL transformations automatically generates the initial configuration with the default options selected for the input model. This configuration model specifies for each configurable element in an input model which rule is selected. Users can modify the transformation configuration model to select the configuration rules that satisfy their needs. The metamodel of the Configuration model is depicted in Figure 4. Finally, the ATL transformation reads the configuration as an input model and modifies their behavior according to the user selections. It is important to note that it is the transformation responsibility taking into account the options that are selected in the configuration model in order to produce the expected output.
As introduced in the section above, two ATL transformations must be implemented to support the configuration of model transformations: the transformation for generating the initial configuration options and the transformation which must support the configuration.
The first transformation (catalog2configuration.atl) takes as input a model with the catalog of configuration rules and the model to be configured and produces the initial configuration: create OUT : CONFIGURATION from IN : CATALOG, INMODEL : UML;
CONFIGURATION!ConfiguredPattern, CONFIGURATION!SpecificInstance } for (param in confPattern.parameter->select(e |
e.lowerValue = e.upperValue and e.upperValue = 1)) { if (param.name = 'Unique Constraint') { if (elem.oclIsTypeOf(UML!Association)) { if (elem.isOneToOne() and elem.betweenClasses()) {
thisModule.generateParameterValue(o, param); } else { } }
} thisModule.generateParameterValue(o, param); } thisModule.resolveTemp(confPattern.eContainer(),'o').patterns <thisModule.resolveTemp(confPattern.eContainer(),'o').patterns.append(o); }
}
As it has been introduced in the previous section, is a transformation responsibility to deal with the configuration information to generate the suitable output. A simple but effective strategy to provide the desired behavior is to implement a different ATL rule for each configuration option. Using this approach, additional conditions are added in the FROM part of the rule checking which configuration option must be applied.
rule GeneralizationParent2Table { from i : UML!Class ( i.oclIsTypeOf(UML!Class) and i.executeGeneralizationRule('OnlyParentTable') and }
… ) do { … }
This strategy performs well when only one configuration pattern is applied to an
element. In case that several kind of options can be selected for one element, we
should implement as rules as possible combination of options. For instance, if
Generalization could also be configured using another criteria with two options, we
should implement (3*2) six rules. In this scenario, a potential strategy to avoid the
explosion in the number of rules would be to implement a unique rule with a DO
section in charge of discriminating the configuration options and calling rules that
implement the different transformation actions. This behavior may be implemented
more naturally adding a transformation phasing [
Our configurable ATL transformation generates DB models and traces taking as input UML2 models and the configuration model. This transformation can be found in the public MOSKitt repository3. create OUT : DB, trace : Trace from IN : UML, modelConf : CONF;
In the configuration of the generalization, we follow the approach where a rule is implemented for every transformation configuration option. Therefore, we have implemented three different rules: rule GeneralizationParent2Table { from i : UML!Class ( i.oclIsTypeOf(UML!Class) and i.isHierarchyParent() and i.isPersistentClass() and i.executeGeneralizationRule('OnlyParentTable') -- generate Parent Table thisModule.generateTable(i); --generate additional attribute: 'tipo_<class_name>' thisModule.createAdditionalColumn(i, i.getTable()); -- process child class if (i.getTable() <> OclUndefined) {
thisModule.processChildFromParentTable(i, i.getTable(), Sequence{}); } }
) do { }
} rule GeneralizationChild2Table { from i : UML!Class ( i.oclIsTypeOf(UML!Class) and i.isHierarchyParent() and i.isPersistentClass() and i.executeGeneralizationRule('OnlyChildTable') ) do { thisModule.processChildFromTakeDownProperties(i, Sequence{i}, Sequence{}); } rule Generalization2Tables {
from i : UML!Class ( i.oclIsTypeOf(UML!Class) and i.isHierarchyParent() and i.isPersistentClass() and i.executeGeneralizationRule('AllTables') ) do { -- generate table thisModule.generateTable(i); -- process child class thisModule.processChildFromAllTables(i); }
} The creation of the tables (and columns, if necessary) has been implemented in ATL called rules in order to facilitate the maintenance of the code 5 User Interface for Configuring Model Transformations MOSKitt provides a forms editor for editing the transformation configuration models. This editor, which is depicted in Figure 5, shows in the left side a tree with the model elements that can be configured. When a configuration is selected in the editor, users can edit their properties in the right side of the editor, including the desired configuration rule and the configuration parameters, if any is available. Once the configuration model has been edited, users can initiate the execution of the transformation from this editor.
Additionally, the functionality of the transformations configurations editor has been integrated as a property sheet of the graphical editors. This property sheet shows the configuration options for the element that is selected in the graphical editor. Therefore, users can select the transformation configuration options while they are editing the model.
The configuration of ATL transformations have also been integrated in the MOSKitt wizard for executing transformations. This wizard provides a sequence of pages (1) for gathering transformation parameters, (2) for providing output about the validation of inputs, (3) for configuring the transformation and (4) for showing the results of the transformation configuration. In the page for configuring the transformation, that is shown in Figure 6, users can select a previously used configuration model, can create a new configuration model or can use the default configuration selections. If a new configuration wants to be created, the configuration editor with the default configuration model is automatically opened.
The approach for configuration ATL model transformations that is introduced in this paper is currently applied in the open source MOSKitt tool. Several ATL transformations can be configured to modify their behavior attending user requirements, including the UML2 to DB transformation with 19 configuration options. This approach is also applied to other kind of transformation like, for instance, code generation transformations implemented with XPand.
As future works, the usability of the editor of configuration models will be analyzed and increased as much as possible, since it is a key piece from the users point of view. Additionally, we plan to extend the rules catalog metamodel to be capable of expressing dependencies (requirements and exclusions) between configuration rules.