-In Model-Driven Engineering, the potential advantages of using bidirectional transformations are largely recognized. Despite its crucial function, in certain cases bidirectionality has somewhat limited success because of the ambivalence concerning non-bijectivity. In fact, consistently propagating changes from one side to the other is typically non univocal as more than one correct solution is admitted. This gives place to a form of uncertainty which means that, rather than having a single model, we actually have a set of possible models but we do not know what is the right one. In this paper, we discuss how dealing with multiple solutions is important and requires specialized tools and support. In particular, handling a set of models explicitly is generally non-viable. Thus, we extended the JTL semantics to generate a model with uncertainty which is semantically equivalent to the set of models it represents. The approach is implemented and a metamodel-independent technique is proposed.
In Model-Driven Engineering [
The solution proposed in this paper, is an extension of the JTL semantics and of its engine capable of generating a uniform characterization of the solution in terms of models with uncertainty instead of a set of models, such that a) the approach is metamodel-independent, in sense that starting from an arbitrary base metamodel can automatically generate the corresponding uncertainty metamodel; b) the resulting model conforms to the uncertainty metamodel; and c) each model with uncertainty has to be considered semantically equivalent to the set of its concretizations, i.e. the models obtainable from the uncertainty model by resolving the point of uncertainties.
By way of example, consider the Collapse/Expand State
Diagrams round-trip benchmark [
At this point, the original source model and the revised target model are not consistent any longer. Therefore, the backward transformation T 1 can be used to restore the consistency by propagating the changes in . Not surprisingly, there is not a unique way of updating the source model. In fact, the added transitions in the target may be mapped to either of the nested states as well as to the container state itself, as illustrated in Fig. 1(d), where the dotted edges represent the alternative transitions. Despite the changes on the target model are relatively simple, their impact on the source model is typically exponential. In fact, the overall number of admissible models in this case is jprintj jcompletedj = 4 4
jcritical errorj 3 = 48 where jnamej is the number of alternative model elements called name. It is worth noting that the models in Fig. 1(d) are represented by means of the dotted notation, which is informal: in this case a bidirectional transformation implemented in JTL would generate a collection of 48 distinguished models. Clearly, whenever the implementor is unable to disambiguate the transformation by making it deterministic, the decision must be left to the modeler rather than to the language internals.
It is not difficult to demonstrate that for a specific instance, if n is the number of uncertainty points and m the number of alternative model elements for each of them, then the result consists of mn different alternative solutions. Hence, it is of crucial relevance that modelers are adequately assisted in dealing with the combinatorial explosion of design alternatives as described in the sequel.
The paper is organized as follows. Section II describes related work about this topic, Section III presents the proposed approach to represent uncertainty by means of JTL, Section IV proposes a new semantic for the JTL engine able to generate and manage models with uncertainty. Finally, Section V draws some conclusion and future work.
Uncertainty is ubiquitous within contexts such as requirements
engineering [
Nevertheless, the work in [
Concerning the multiplicity of solutions in bidirectional
transformations, most of the existing languages are
deterministic, i.e., they produce one model at a time. However, in [
With reference to the scenario described in Sect. I, the model with uncertainty corresponding to the admissible 48 solutions, is shown in Fig. 2. In particular, the alternative transitions are collected in the uncertainty point (UTransition) print, completed, new operation which contains the transitions targeting each one of the nested states within Active as well as to the composite state itself.
The main challenge to address in order to let JTL generate the model with uncertainty is to detect those model elements which are shared throughout the solution space, i.e., the certain part of the solution. Referring to Fig. 1(d), it consists of all elements in the model but the dotted edges. This is obtained by logically connecting those elements in the source model which originated the same target elements. Since the JTL engine is a logic program written in ASP, it can derive how models are related by means of a deductive process. In this respect, the existing traceability management offers enough information to understand how the models can be factorized by identifying those elements which are connected among them. In particular, tracing information stores relevant details about the linkage between source and target model elements at execution-time (including the applied transformation rules).
An excerpt of the implemented mechanism is given in Listing 1. In particular, it contains (part) of the ASP encoding of the transitions print present in the modified simple machine in Fig. 1.(c) (line 1) and in the hierarchical state machine in Fig. 1.(d) (lines 3-6); the corresponding trace links are given in lines 8-11. During the execution of the transformation, the engine is able to deduce both the concretization models and/or the model with uncertainty. Any point of uncertainty is derived by calculating the uncertainty set among model elements (lines 15-24). 1 node(SM, p, transition). 2 3 node(HSM, p1, transition). 4 node(HSM, p2, transition). 5 node(HSM, p3, transition). 6 node(HSM, p4, transition). 7 8 trace_link(tl1,s1,t1,r1). 9 trace_link(tl2,s1,t2,r2). 10 trace_link(tl1,s1,t3,r3). 11 trace_link(tl2,s1,t4,r4). 12 13 getID(p,s1). getID(p1,t1). getID(p2,t2). getID(p3,t3).
getID(p4,t4). 14 15 get_uncertainty_set(t1,t2) :16 trace_link(tl1,s1,t1), trace_link(tl2,s2,t2), 17 equals_id(s1,s2), equals_id(t1,t2). 18 19 node(UMM,ID,UMC) :
Due to the metamodel structure (Fig.4), models with uncertainty may over-approximate the sets of transformation candidates. For instance, the scenario in Fig. 1 suggests that only one print transition can exist in the final model. However, the generated model with uncertainty admits also models with multiple print transitions giving place to more concretizations than those expected. Therefore, in order to avoid multiple print transitions, an operation of refining with a constraint on the model is needed in order to reduce the concretizations to cases with one print transition only. The constraints are directly generated by the JTL engine, which possesses all the information in the trace links between models source and target.
It is worth noting how uncertainty is becoming increasingly
important in today’s software based systems. Rather than
ignoring uncertainty, it should be considered as a first-class
concern in the design, implementation, and deployment of
those systems [
In order to reduce the burden of managing a collection
of models, a metamodel-independent approach to uncertainty
representation based on preliminary work in [
The uncertainty metamodel U (M ) is obtained by extending a base metamodel M with specific connectives to represent the multiple outcomes of a transformation. These connectives denote the uncertainty points where alternative model elements are attached. Moreover, such points of uncertainty are traceable in order to ease the traversal of the solution space and to permit the identification of specific concretizations, i.e., instances. Let us consider the metamodel HSM of the hierarchical state machines given in Fig. 3. The uncertainty metamodel U (HSM) in Fig. 4 is automatically obtained by extending the base metamodel as follows: 1) the abstract metaclass TracedClass with attributes trace and ref is added, 2) for each metaclass c in HSM, such that it is non-abstract and does not specialize other metaclasses: 2.1) a direct sub-metaclass uc of c is added, 2.2) c is generalized by TracedClass, 3) each metaclass uc is composed with c, enabling the representation of a point of uncertainty and its alternatives, finally 4) the cardinality of attributes and references are relaxed and made optional in order to permit to express uncertainty also over them.
In particular, the metaclasses UStateMachine, UState and UTransition in U (HSM) are derived from StateMachine, State and Transition in HSM, which are in turn generalized by TracedClass. The purpose of TracedClass is to maintain information about the relationships between the uncertainty points and the correspondent own alternatives in the concretization models.
The above metamodel permits to represent with a single model a set of state machines. For instance, in Fig. 1(d) a set of hierarchical machines are given. Most of the model elements (all the nodes and part of the transitions) are shared among them, they represent the certain part of the models. Whilst, the dotted alternative transitions denoted by print, completed, and critical error correspond to three different uncertainty points of type UTransition, each connected to the related alternative Transition elements.
The main advantage of the approach is that the uncertainty represented by a set of alternative models is leveraged to a first-class status. A complete set of models can therefore be manipulated as whole, for instance with an automated transformation, without iterating over each individual in the set. The above discussion captures the fact that non-injective mappings when reversed can produce multiple results. However, as discussed in the previous section managing a multitude of models is impractical. What is needed is a construction capable of representing a set of models generated by a transformation in an intensional way. Hence, the revised JTL engine is able to distinguish among two different behaviors: – extensional, generate all the models satisfying the relation defined in the bidirectional transformation; – intensional (or with uncertainty), generate a model with uncertainty which is semantically equivalent to the models of the extensional case, i.e., the corresponding set of models can be generated from it.
However, one important issue arising from this scenario is that models with uncertainty may be over-approximations of the sets of transformation candidates. This is due to the ”combinatorial” nature of these models since each point of uncertainty collects the different alternatives. Consequently, it can happen that certain combinations produce concretizations which are not part of the extensional solution space. Therefore, besides the models with uncertainty it is important to generate also those constraints which limit the solution to the admissible concretization only.
Bidirectional model transformations represent at the same time an intrinsically difficult problem and a crucial mechanism for keeping consistent and synchronized a number of related models. One of the prevalent factors within software engineering is the problem of non-determinism in bidirectional transformations. When modellers are not able to fix a design decision they may encode ambiguities in their model transformation specification, e.g. not providing additional constraints that would make the transformation deterministic. The lack of information affects models, for instance ambiguous mapping may cause the generation of multiple solution models each one representing a different design decision.
Therefore, the proposed approach is based on the refinement of the JTL engine, which permits the generation of models with uncertainty in order to leverage the solution space to a first-class concern. The approach has been implemented and can be used for any Ecore artifact.
This research was supported by the EU through the ModelBased Social Learning for Public Administrations (Learn Pad) FP7 STREP project (619583)2.