In annotative approaches to model-driven software product line engineering variability annotations express in which variants model elements are included. Although (single-variant) model transformations (SVMTs) are mature by now, they cannot process these annotations. Considering them calls for multi-variant model transformations (MVMTs) which ideally reuse existing transformations. In trace-based approaches annotations are propagated by exploiting the information of traces written alongside the transformation. Depending on the granularity of the trace, di erent strategies can be applied. For instance, ne-granular traces record not only all source and target elements of a rule application but list context elements. The latter have been created in previous rule applications and are necessary for creating the new elements. In this paper we demonstrate an example in which a propagation based on context elements fails. Contrastingly, we propose to propagate only annotations of 1:1 mappings and to, thereafter, calculate the annotations for elements still missing one. Moreover, we introduce a new evaluation criterion based on incremental transformations, allowing to take the multi-variant context into account.
In model-driven software engineering (MDSE) [
Furthermore, in model-driven software product line engineering (MDPLE)
[
In annotative approaches to MDPLE [
In this paper we contribute a novel trace-based approach to MVMTs solely using 1:1 mappings. In a post-processing step annotations for target elements still missing one are determined from dependencies inside the target model. Furthermore, we introduce an incremental commutativity criterion to evaluate the correctness of the annotated target MVM, allowing to consider the multi-variant context in the evaluation. Applying the procedure on an example transformation, in which other approaches fail, achieves the desired behavior.
In the next section we delimit our MVMT approach from existing ones. Then, we describe an example violating commutativity and provide a solution to the problem. From the ndings future work is conducted. 2 2.1
Di erent strategies for realizing MVMTs can be roughly categorized in black-box and white-box solutions, requiring no or all internals of the SVMT, respectively.
The lifting algorithm [
Contrastingly, black-box approaches only know the input and output of the
transformation. The SVMT remains exactly the same. Annotations can, then,
be propagated by applying di erent strategies: In [
Traces are another source of information for propagating annotations. A
tracebased solution [
In a simpli ed way Algorithm 1 describes how to propagate annotations based
on a complete trace [
For validating the correctness of the propagation, a commutativity criterion
(Figure 1) is postulated for annotative approaches in [
In [
. Trace composed of trace elements te . Process all trace elements sequentially . Annotations of source elements . Annotations of context elements . Annotation for target elements
. Process all target elements . Annotate the target element lated computational model and, thus, failing to commute. For that reason, we state the following questions: 1. To which granularity can the information of traces be helpful? Are context elements (always) decisive for the success of the MVMT? 2. Are batch transformations appropriate for evaluating commutativity?
The following scenario is based on a benchmark evaluating bidirectional (and
incremental) model transformations [
Let us migrate a database storing persons to one storing families. As depicted on the left hand side of Figure 2, named persons (composed of the last name followed by the rst name) are registered as male or female. In contrast, the family database records families by their last names and a family references its members according to their role (mum, dad, etc.) inside the family.
The family database is created from the persons database as follows (tsv): Each person is inserted as member in a family with the respective last name. If there is no appropriate family, a Family element is created and the person is inserted as parent. If the family exists but the parent role is not occupied, the member will also be a parent. If both parents exist, the member becomes a child. 3.2
Now let us consider the example in the context of a software product line. The feature model (top left of Figure 2) consists of the optional features parent (P) and children (C). As depicted on the right of Figure 2, on instance level, the person model consists of two men with the same last name 'Smith'. Ben is annotated with the feature P since he is the father of the family, and Tom should be a child (feature C). Transforming this model with the tsv described above, creates a Family Smith with a member Ben as father and a member Tom as son. A complete trace would record three elements as listed in Table 1. Please note: The last row states the rule application with Tom as source element. It lists the family as context element because it already exists and is necessary for inserting the member Tom as a child.
The trace-based propagation (Algorithm 1) as explained in Section 2.2 annotates the target elements as depicted in Figure 2: The member Ben and the family receive Ben's annotation as they are both recorded as its target elements. Secondly, Tom's annotation is the conjunction of the annotation of its source element (C) and of its context element (P), the Family.
Finally, products are derived and commutativity is evaluated. Deriving, for instance, a database containing only children, we lter both, ms and mt, by the feature con guration DB ^ :P ^ C. The derived source product m0s includes the elements as expected: only the male Tom remains. Filtering mt, however, results in a product m0t consisting of the database only. Although this is not the desired semantic result, m0t could still be correct w.r.t. the commutativity criterion (in the case tsv creates an equivalent model m0t0 with m0s as input). Hence, for verifying commutativity, we execute tsv with the product m0s as input. The output, m0t0, however, is semantically incorrect, too: Tom becomes the father of the family as from the transformation's point of view the family and a parent are missing. Thus, Tom triggers the creation of the family and is added as father. Since m0t and m0t0 are not equivalent, commutativity is violated.
Summing it up, (semantic) misbehavior appears at three locations: 1. The annotation attached to the Family element in mt is wrong since the family must exist as soon as any member is present. 2. The annotation of Tom in mt might be wrong. Tom should be part of a target product whenever its counterpart exists in a source product. 3. Applying tsv on the source product m0s creates a semantically wrong target m0t0. 4 4.1
The rst two aforementioned problems tackle the propagation of annotations. The new procedure should adhere to Algorithm 2, assuming all metamodels to be instances of the Ecore meta-metamodel (i.e., directed, acyclic graphs). At rst, only the annotations of 1:1 mappings are copied from the source to the (main) target element1. In the post-processing phase (l. 6-10), rstly, all elements missing annotations are collected top-down. For each unannotated element e the annotations of elements required for its existence (l. 7) and the ones requiring e's existence (l. 8) are determined. The contents of the sets are discussed in Section 4.3. Then, the annotation is calculated as in line 9 of Algorithm 2, i.e., e is present if all the elements it needs are present, and, if at least one of the elements needing e's presence exists. Finally, the annotation is set on e (l. 10).
For evaluating commutativity, batch transforming the source products results in an unintended target model (3rd problem). Therefore, we propose an incremental commutativity criterion: Firstly, the MVMT is executed as before 1 Copying the annotation of the source to its corresponding target is trivially correct as the target element should exist when its corresponding source element exists. Algorithm 2 Improved propagation of annotations. propagateBasicMappings(te) for e 2 mt.getUnannotatedElements() do
. Process target elements without annotation in topological order var annneeded = mt.getAnnsOfNeeded(e)
. Annotation of elements needed for the existence of e var annneeding = mt.getAnnsOfNeeding(e)
. Annotation of elements needing the existence of e var annt := V annneeded _ W annneeding e.setTargetAnnotation(annt) . Annotate the target by reusing the single-variant (batch) transformation tsv. As opposed to the commutativity criterion postulated in Section 2.2, source products (m0s) are transformed incrementally. Thus, decisions made in the multi-variant context, e.g., a person's role in the family, are taken into account. the annotations of the basic mappings are applied. Tom and Ben alike receive only the annotations of their corresponding source elements. Thereafter, the Family still expects an annotation being calculated in the post-processing step. The element receives the presence condition DB _ (P _ C). It is composed of the annotations of the elements needed for its existence, the database (DB), and of the elements requiring its existence (Ben and Tom) combined in a disjunction.
Evaluating commutativity by incrementally executing tsv, Ben is removed and Tom's role remains the same in m0t0. Moreover, ltering the annotated target model mt by the same feature con guration behaves well: the family and Tom are not removed anymore. Thus, the example now commutes.
Accordingly, the questions stated in Section 2.2 may be answered as follows: 1. In our example context elements hinder the correct annotation of target elements. Context elements may change when switching from the multi-variant to the single-variant context. Contrastingly, 1:1 mappings are trivially correct and do not require ne-granular trace information. 2. Commutativity should be evaluated based on incrementally transforming source products considering, thus, decisions of the multi-variant context. 4.3
Our solution is the rst step to an automatic trace-based propagation supporting the most general form of (an incomplete) trace. The two-step procedure is still trimmed to the example needing further evaluation.
The key di culty has been moved to the post-processing step. It seems to be reasonable to combine annotations of required and requiring elements as stated in Algorithm 2. However, the de nition is silent on the elements belonging to the respective sets. They must be determined from the output (meta-)model and depend on the granularity of annotating model elements. For instance, required elements subsume at least the container but might also be the types of all referenced typed elements, supertypes and operation parameters in the case complete objects are annotated. Requiring elements are at least all contained objects. Moreover, if too much elements are unannotated after the basic propagation, calculating the annotation automatically may become impossible.
Finally, the incremental evaluation is bene cial when elements are deleted upon ltering. However, if a ltered source model (m0s) adds a new element or changes it di erently than in the MVMT, this change will not be part of the MVM mt and, hence, of m0t2. Moreover, not all, though many, languages support incremental transformations in an unconstrained way. 5
To sum it up, we present a novel approach to circumvent problems arising in trace-based approaches to MVMT. Instead of exploiting ne-granular traces, 2 For a correct MVM, changes resulting from transforming source products should be integrated into mt, which may violate single-variant semantics. which are rarely present, we only propagate annotations of 1:1 mappings. They form part of every trace and copying them is de nitely correct. Missing annotations are calculated based on already present annotations and dependencies inside the model. For evaluating commutativity we propose to perform incremental transformations on product level taking into account the multi-variant context. Applying the approach on initial examples achieves the desired result.
As next steps, we like to generalize the approach and provide extensive evaluation. In particular, the post-processing should be investigated in greater detail.