In Model-Driven Engineering, the potential advantages of using bidirectional transformations are largely recognized. Despite its crucial function, bidirectionality has somewhat limited success also because of the ambivalence concerning non-bijectivity. In fact, in certain situations more than one admissible solution is in principle possible, despite most of the current languages generate only one model at time, possibly not the desired one. In this paper, we propose to manage non-determinism during the design process. The approach aims to analyze bidirectional transformations with the purpose to detect ambiguities and support designers in solving non-determinism in their specification.
models. However, the JTL transformation engine is not able to detect non-deterministic rules, i.e., rules that can give place to multiple solutions, at static-time.
There have been several works analyzing semantic issues and idiosyncrasies of
bidirectional model transformations. [
In this paper, we present an approach to statically detect non-determinism in
bidirectional transformations, i.e., without executing them. To this end, Answer Set
Programming (ASP) [
2
(a)
Person name {is_primary}
Worker working_address
{persistent} department
{persistent} number_of_publication (b)
PK name working_address department
PK name
working_address
department
number_of_publication
Scenario Let us considering a typical round-trip problem based on a non-bijective
class diagram to relational data base (UML2RDBMS) benchmark scenario [
persistent classes are mapped to correspondent tables and their attributes to columns in the tables, including inherited attributes. In order to preserve all the information of the source diagram, attributes of non-persistent classes have to be distributed over those tables stemming from persistent classes which access non-persistent ones.
The UML model in Fig. 1(a) shows the package university that is composed of an inheritance hierarchy of classes, whereas the correspondent schema is depicted in Fig. 1(b). Let us suppose that the generated model is manually modified (e.g., for satisfying new requirements) as depicted in Fig. 2(a): a new column email has been added in the table employer. This gives place to an interesting situation since such modifications can be reflected to the source model in Fig. 1(a) in three alternative ways: the attribute (corresponding to the manually added column) can be a member of the class employer or with each of parent classes worker and person, as in Fig. 2(b).
diagrams and relational database models, has been implemented by means of the Janus
In Listing 1.1 we report a fragment of the transformation which is expressed in the textual concrete syntax of JTL and applied on models given by means of their Ecore representation within the EMF framework3. In particular, the following relations are defined:
tribute2Column, which relates attibutes and columns in the two different metamodels and c) SuperAttribute2Column, which relates attributes of the parent class to columns of the corresponding child table. The when and where clause specify conditions on the relation. In particular, the when clause in Line 18 allow to navigate the parent classes of each attribute, then the where clause in Line 19 generates the correspondent columns.
UML model is mapped to the correspondent RDBMS model. As aforementioned the
transformation is non-injective. The back propagation of the changes showed in Fig. 2 gives place to the following situation: the transformation execution produces a set of three models each one represents a different solution where the column email belongs to each of the three different classes of the hierarchy. In particular, the modified RDBMS target model in Fig. 2(a) is mapped back to the UML source models in Fig. 2(b).
Such non-determinism can be resolved by specifying in the transformation that any new column of the table must be mapped to the corresponding attribute of the class from which the table is generated (for instance, the new column email of the table employer is mapped to the attribute email of the class employer).
fine mapping from source to target metamodel elements, and viceversa. By
considering existing relational languages [
Analysis of model transformations can be used for a wide range of assessments
including the satisfaction of specific requirements, verifications/validation, and
performance analysis. Existing approaches and tools involve testing (e.g., test case
generation for model transformations), or analysis performed on executing programs (e.g.,
run-time monitoring) [
Non-determinism is a critical aspect in bidirectionality. Thus, detecting the ambiguous fragments of a transformation at design-time may prevent unwanted behaviors like a severe increase of the solution space. At this scope, it is of paramount relevance to support the designer in understanding which rule is ambiguous and how to refactor the transformation in order to reduce non-determinism. This is intrinsically difficult as it not unusual that the backward (forward) execution of an seemingly deterministic forward (backward) transformation generates more than one alternative. The challenge consists of precisely identifying those combinations of rules which are responsible of the solution multiplicity.
The analysis is performed by considering not only the behavior of individual statements and declarations, but rather including the complete transformation. Information obtained from the analysis are used for detecting possible coding ambiguities. In particular, the approach aims to detect so-called non-deterministic portions of the transformation represented by collections of rules that if executed together may cause multiple alternative solutions. Please note how the degree of non-determinism of a single fragment depends on the model instance given as input.
In this paper, we propose to use the Answer Set Programming (ASP) [
(1) Translation of the transformation into the analysis notation A model transformation consists of a set of rules which define mapping among element types of the involved left- and right-metamodels. Generally, a rule is constrained with pre- and post-conditions that limit its applicability and behavior. This step defines a
characterization that permits to capture only the information which is relevant for
performing the analysis (neglecting irrelevant details which are not pertinent to our
purpose). The notation used for representing the elicited information is the Transformation
Analysis Language (see Fig. 3). Each rule is represented by means of two sets
containing the left- and right-patterns, respectively. Whereas, each pattern is represented by a
class and values for any of its properties and references. As defined in OCL6, a pattern
can be viewed as a set of variables, and a set of constraints that model elements bound to
those variables must satisfy to qualify as a valid binding of the pattern. In other words, a
pattern can be considered a template for objects and their properties that must be located
in a candidate model to satisfy the rule. The model representing the bidirectional model
transformation (Bidirectional Transformation Model in Fig. 3) must be translated into
the corrisponding model for the analysis (Transformation Analysis Model) by means of
a semantic anchoring [
STEP 1
STEP 2 Bidirec'onal Transforma'on
Language
C2 Bidirec'onal Transforma'on
Model
Transforma'on Analysis Language
C2 traslate
Transforma'on Analysis Model e d o c n e input annotate
ASP Transf. Analysis Model
ASP Analysis
Result Model IN
OUT
Logical Analysis ASP rules and constraints
ASP solver Once the analysis models are generated by abstracting from the concrete transformations, they need to be translated into ASP in order to be analyzed. The analysis models and the metamodels involved in the transformations are consistently consistently encoded as a knowledge base, whereas the properties which are required to be checked are translated in constraints and verified by ASP rules. As aforementioned the scope of the analysis is to provide an automated detection of non-deterministic rules. In particular, it generate sets of logically related rules whose simultaneous applications may generate multiple admissible solutions. When the ambiguous rules are marked by the analysis process, the designer can refactor the initial specification by resolving the non-determinism. In Listing 1.2 a fragment of the ASP rules for the detection of non-deterministic code is presented. In particular, the rule in Lines 1-4 deduces pairs of equal domains by comparing patterns and predicates of each domain. The rule in Lines 6-9 deduces non-deterministic relations; in particular, for each transformation direction, relations with equal domains are detected. Finally, the rule in Lines 11-13 6 http://http://www.omg.org/spec/OCL/ deduces pair of ambiguous relations which cause non-determinism if simultaneously executed. 1 are_equal_domains(ID1, ID2, Dom) :2 have_equal_patterns(ID1, ID2, Dom, MC, MCName), 3 have_equal_predicates(ID1, ID2, Dom, MC, MCName), 4 not have_different_patterns(ID1, ID2, Dom). 5 6 non_deterministic_relation(ID, RelName, DomLeft) :7 are_equal_domains(ID, ID2, DomRight), 8 relation_name(ID, RelName), 9 tranformation_model(DomRight), tranformation_model(DomLeft), DomRight != DomLeft. 10 11 are_ambiguous_relations(ID1, ID2, DomLeft) :12 are_equal_domains(ID1, ID2, DomRight), 13 tranformation_model(DomRight), tranformation_model(DomLeft), DomRight != DomLef
In this section, we present an application of the proposed approach to the UML2RDBMS example presented in Sect. 2. The goal is to illustrate how to use of the approach in practice by exploiting the developed environment. In particular, we analyze the JTL implementation of the UML2RDBMS transformation7. First, the bidirectional transformation is translated into the analysis model. Then, the analysis is executed to highlight those rules which may be responsible of non-determinism.
(a)
(b) (1) Translating UML2RDBMS into the analysis language Starting from the specification of the UML2RDBMS transformation by means of JTL described in Sect. 2 (see Listing 1.1), the corresponding JTL model in Ecore is represented in Fig. 4(a). As aforesaid, in JTL the mapping between candidate models are
represented by means of a set of relations defined by two domain patterns. Each relation includes a pair of when and where predicates which specify the pre- and postconditions that must be satisfied by the elements of the candidate models.
The JTL model in Fig. 4(a) is translated into the correspondent analysis model in Fig. 4(b) by means of an automated model-to-model transformation implemented in ATL. In particular, all the mapping rules (including pre- and post- conditions) of the source JTL model are translated in the corresponding sets of patterns of the target analysis model. For instance, let us consider the Class2Table relation, then every predicate belongs to the UML or RDBMS domain pattern, is represented by an OCL expression, and is evaluated as follows: (i) each Object Template Expression is transformed in a named Pattern of the analysis model; (ii) each statement is evaluated and transformed in a correspondent predicate; finally (iii) each condition is considered as a pattern and added to the correspondent Domain in the analysis model. (2) Executing the analysis of the UML2RDMBMS transformation The transformation analysis model, generated during the previous step is entered into the ASP-based engine. In order to perform the analysis, model transformation and the involved metamodels have to be encoded in the ASP language. For instance, in Listing 1.3 a fragment of the ASP encoding of the analysis models in Fig. 4(b) is showed. In particular, it declares the class2table relation with an identifier 1 (in Lines 1) and the correspondent patterns and predicates for the domain UML (in Lines 2-10) and the patterns and predicates for the domain RDBMS (in Lines 11-17), as well. 1 relation_name(1, class2table). 2 relation_domain(1, uml). 3 relation_pattern(1, uml, c, class). 4 relation_predicate(1, uml, c, is_persistent, true). 5 relation_predicate(1, uml, c, name, cn). 6 relation_predicate(1, uml, c, attrs, attr). 7 relation_pattern(1, uml, attr, attribute). 8 relation_predicate(1, uml, attr, name, an). 9 relation_predicate(1, uml, attr, owner, c). % added from where 10 relation_predicate(1, uml, attr, is_primary, false). % added from where 11 relation_domain(1, rdbms). 12 relation_pattern(1, rdbms, t, table). 13 relation_predicate(1, rdbms, t, name, cn). 14 relation_predicate(1, rdbms, t, cols, col). 15 relation_pattern(1, rdbms, col, column). 16 relation_predicate(1, rdbms, col, name, an). 17 relation_predicate(1, rdbms, col, owner, t).
Starting from the ASP encoding, the analysis is now able to detect the non-deterministic rules. In particular, the analysis outcome consists of a number of rule sets; each of which includes logically related relations whose simultaneous applications may generate multiple solutions. For instance, Listing 1.4 shows a fragment of the result of the analysis executed on the UML2RDBMS specification (in Listing 1.1). In particular, when the transformation is executed in the RDBMS-to-UML direction, the set of nondeterministic relations class2table, superAttribute2column and superAttribute2column is detected. In particular, in the scenario described in Sect. 2, more than one alternative solutions can be obtained because of the simultaneous executions of the three ambiguous mappings. 1 %%%% Analysis Model 2 %%%% sets of non-deterministic relations (UML to RDBMS direction): 3 [] 4 %%%% sets of non-deterministic relations (RDBMS to UML direction): 5 [(1,class2table), (3,superAttribute2column), (5,superAttribute2column)] 6 [(..), (...)]
6
Non-determinism is a recurrent aspect affecting model transformation design and
implementation. As said, most of the current languages (e.g.,[
Existing approaches and tools involve testing (e.g., test case generation for model
transformations), or analysis performed only on executing programs (e.g., run-time
monitoring) [
transformations at static-time, i.e., without executing the transformation. The intention is to provide transformation implementors with a tool capable of analyzing transformations in order to return feedback which could resolve potential non-determinism. The approach has been demonstrated on a small yet significant case study implemented in
approach completely language-independent additional implementation efforts are required which we intend to do in the near future. Furthermore, the logical foundation of the engine makes possible the verification of different formal properties by translating them in ASP, with the scope to provide a mean for improving the quality of model transformation specifications.