The previous sections introduced the notion of change backpropagation. Target changes are translated to corresponding source changes. This translation is realized by the prop- agation functional from Def. 11. To perform the adjustment of the source model, source elements that are affected by the change must be determined. Also, for a single target change, multiple changes in the source models may be required.
In this section, we present the details of this backpropagation of changes. We will first clarify the basic types of changes, then look at the translation of changes between domains and finally discuss the selection of the most suitable propagation option. The latter is needed, if multiple valid possibilities to propagate a change exist.
As we assume that all artifacts are instances of object-oriented metamodels, the ele- ments that can be subject to change are objects, attributes and references. The basic changes that can be applied to these elements are:
• Additions—to create a new object,
• Updates—to change the value of an attribute,
• Couplings—to connect or disconnect objects with a reference, and • Deletions—to remove an element.
For additions, we require a parent element, which can either be an arbitrary model element or the artificial root node mentioned in Sect. 2.1. By building sequences from these basic types of changes, models can be modified in arbitrary ways. For the time being, we will concentrate on the basic modifications and how to propagate them back. The composition of changes to form transactions will be discussed in Sect. 6.5.3.
To translate target changes to source changes, the traceability relation (Def. 12) is used. As explained in Sect. 6.3, our example composition system uses two basic operators—copy and merge. In the following, we will denote projections of the general traceability relation T RACEtfor the respective operator as copyof and mergeof and we
will also use infix notation. For example, bx copyof ax is used to express that element bx
is the result of applyingcopyto element ax. Also, the union of both relations shadowof
is used to denote that an element was either copied or merged.
A close look at the copyof relation reveals that this relation is injective. For any target element there is exactly one source element2. However, this does not imply that
6.4 Detailed Concepts and Process
Target Change Valid Source Change(s) Condition Delete element bx Delete element ax bx copyof ax
Update element bx Update element ax bx copyof ax
Add element bx to parent bp Add bx to ap bp shadowof ap
Coupling element bx to by Couple element ax to ay
bx shadowof ax and
by shadowof ay
Decouple elements bx and by Decouple ax and ay bx shadowof ax and
by shadowof ay
Table 6.1: Change translation strategy based on copyof , mergeof , and shadowof trace- ability relations.
the overall composition is injective too. As discussed before, this is rarely the case, because multiple source models can be composed to form the same target model.
In contrast, the mergeof relation is not injective. Multiple source elements can be merged into a single target element. Moreover, a single source element can be used multiple times in a composition, which implies that mergeof is not surjective either. Consequently, shadowof , being the union of copyof and mergeof cannot be injective. The properties of the three relations will explain some of the subsequent observations.
To understand the interaction between transformation operators, the traceability rela- tion and change translation, consider our running example. The composed state machine contains copies of the models that served as input for the composition (cf. Fig. 6.4). For example, the states start, StateA,StateB, and StateC are copied to create the com- posed model. Also, the transitions t1tot5 can be found in the composition result.
Table 6.1 shows an overview on how changes can be translated. First, if copied ele- ments are deleted, the most natural way to propagate this change to source models is to delete the original, the copy was obtained from. Figure 6.5 shows such a modification. For example, if the final state is deleted from the composed state machine (1), it should be deleted from the respective input model. Second, performing updates on copied el- ements is similar. The respective original element needs to be updated. If StateC is renamed to StateD(2), the original of StateC must be renamed as well.
Third, additions made to the target model must be translated. For example, one can add a new state StateE to the composed model. In this case, the addition can trigger the creation of an equal state in either one of the source models, because the composed model was obtained by merginghost.smandrefine.sm. Thus, it is not clear where the new state must be created. Both options are equally valid. We are facing a situation here where multiple valid propagation options exist. To decide which of the two propagations is the best, the synchronization fitness functions (cf. Sect. 6.4.3) are required. Without further knowledge about the intent of the developer who applied the change, the decision is not deterministic.
6 Backpropagation-based Round-Trip Engineering StateA StateB StateD in out StateA StateB StateCD t1 t2 t3 t1 t2 t3 t4 t5 t4 t5 start start (1) Copy deleted, delete original StateE StateE StateE t6 t6
(4) Copy coupled, couple original
(3) Copy added, create original
(2) Copy updated, update original (5) Copy decoupled, decouple original
Figure 6.5: Propagating changes applied to a composed state machine.
Fourth, connecting elements with a reference (i.e., performing coupling) yields a similar situation. For example, if a transitiont6 (i.e., a reference) is introduced (4), the same reference must be added to the source model. However, if the reference is introduced between elements that result from merging multiple source elements, there are multiple options to create the reference.
Fifth, elements can be disconnected (5), similar to the deletion of model elements. To reflect such a deletion in the source model, the respective reference must be removed. In this case ambiguities can occur, if multiple references between two elements exist.
The examples show that some operations yield multiple options for translating a change. This is caused by the fact that the mergeof relation is not injective. Any change that is applied to a merged target element must therefore consider all elements involved in the respective merge. For example, adding a new state to the composed state machine can imply changing either one of the input models. The same applies to the modification of references. Only deletions and updates can be translated without ambiguity, because they solely rely on the copyof relation.
After examining thecopyandmergeoperator, we can say, that the properties of these operators w.r.t. change propagation are quite profitable. Deletions and updates can be simply applied to the original elements. For additions and couplings, multiple valid propagation options can exist, but these are limited by the number of involved source
6.4 Detailed Concepts and Process
models. For other transformation operators, the derivation of source changes can be quite different and much more complex (cf. Sect. 6.5).
The concrete rules to transform target changes to source changes differ between RTE scenarios. They depend on the employed transformation technique. In particular, the semantics of the basic transformation operators matters in this context. Change transla- tion rules can be reused, if the same operators are used. For example, our state machine composition relied on the copy and mergeoperators. Other transformation techniques, which do also copy or merge elements in the same way, may use the same rules.
From the example we make some general observations about propagating changes:
O6-6 Change propagation rules depend on the transformation operators in use, but not on concrete transformations.
O6-7 Traceability relations between source and target model elements are essential to propagate changes correctly.
O6-8 For a single change, multiple valid backpropagation options can exist.
The first two points imply main tasks when establishing RTE support according to our backpropagation-based approach for a specific scenario. First, one must either reuse or create a set of propagation rules that are feasible for the used transformation oper- ators. This requires a thorough understanding of the operator semantics. Second, the relations between source and target models need to be known. Usually, this involves the implementation of tracing mechanisms to observe the execution of transformations to gain knowledge about the creation of target models.
The concrete complexity of these two tasks—specifying propagation rules and tracing transformations—depends on different factors. The propagation rules are inherently bound to the operator semantics and the effort to create them may therefore vary. For some transformation operators, reasonable rules might not even exist. In contrast, tracing transformations is merely a technical problem. Here, the cost of an adequate solution depends on the involved transformation tools and their support for traceability. The last point—dealing with multiple valid backpropagation options—is particularly interesting. For example, if a target model element “depends” on two source elements, the deletion of the former can trigger the deletion of both source elements, or only one of them. If elements are added to a target model, there might be multiple possibilities for inserting respective source elements.
To deal with such situations, we propose a general procedure called Propagate Replay Evaluate Pick (PREP). This procedure is also depicted in Fig. 6.6. First, we propagate all options in isolation, perform a replay (cf. Sect. 6.4.2) for each of the cases and then use the synchronization fitness functions (cf. Sect. 6.4.3) to evaluate the outcome of each propagation. Based on this evaluation, one of the propagation options is picked.
6 Backpropagation-based Round-Trip Engineering a t b d b‘ a1‘ t b1‘‘ a2‘ t b2‘‘ an‘ t bn‘‘ … … p1 p2 pn
Source Domain Target Domain
Change Backpropagation Replay Synchronization Fitness Function Evaluation … Decision
Figure 6.6: The Propagation Replay Evaluation Pick (PREP) procedure.
More precisely, a change d triggers multiple propagations (p1,p2,. . . ,pn). For each
of this change sets a new source model (a01,a02,. . . ,a0n) is derived. By executing the transformation t on each of these source models, a set of target models (b001,b002,. . . ,b00n) is obtained. All these artifacts serve as input for the synchronization fitness functions, which evaluate the feasibility of each propagation (cf. Sect. 6.4.3 for more details on synchronization fitness functions).
The PREP procedure implements the idea of multiple backpropagation options. Here, some options may yield invalid source models (e.g., because they violate local con- straints). Consequently, these options cannot result in a global consistent state. More- over, some of the remaining options may be more feasible than others. To pick the option that reflects the expectations of the user best, synchronization fitness functions are used. Compared to approaches that use inverse transformations and which try to compute a set of synchronized models directly (cf. Sect. 6.5.1), PREP computes a variety of potential solutions and picks the best one.