Benchmarx is the subject of bidirectional transformation case study for the Transformation Tool Contest 2017. The example is a wellknown model-to-model transformation from the ATL transformation Zoo named "Families to Persons". This paper presents a solution to provide the inter-model consistency using the Epsilon Validation Language (EVL) and domain-specific traceability techniques. We call this approach EVL+Strace.
The EVL+Strace approach defines EVL modules. Modules consist of a set of invariants (constraint s) grouping
in the context. An EVL constraint contains two main parts including check and fix blocks. In the check block,
Copyright c by the paper’s authors. Copying permitted for private and academic purposes.
a condition is specified that must be true. If it is evaluated to be false, the fix block triggers some statements
to resolve the violation. The Epsilon Object Language (EOL) [
EVL+Strace can detect independent updates on the source and target models by checking the information of trace model. Figure 1 illustrates an example of source, trace, and target models for the Families to Persons case study. It presents examples of possible atomic updates on source and target models, including addition (number 1), deletion (number 2), relocation (number 3), and attribute value modification (number 4). As it is demonstrated, for each source or target object, there is an element in the trace that referenced to the object. Since there are not any element referring to m4:MemberFamily, EVL+Strace will recognizes it as a new inserted element. If the manual deletion (shown as number 2 in Figure 1) is performed by user, i.e., p3:´Male is removed from the target model, the reference of pT3:´PersonTargetEnd will become empty; therefore, EVL+Strace recognizes a deletion.
Label 3 in Figure 1 presents the element relocation. The reference from f2:Family to m2:MemberFamily is deleted and a new reference from f1:Family to m2:MemberFamily is added. In other words, The member Liz is moved from Simpson family to Flanders family. Since each reference in the source has a corresponding reference in the target, EVL+Strace can identify this relocation. As it is shown, there is no reference between fT1:FamilySourceEnd and mT2:MemberFamilySourceEnd and the reference between fT2:FamilySourceEnd and mT2:MemberFamilySourceEnd has no correspondence in the source. Therefore, an element relocation will be detected. An example of value modification is presented in Label 4 of Figure 1. In this case, the name of p1´ is updated to ’Flanders, Jim’. This modification is detected by comparing the name of pT1:´PersonTargetEnd with the name of p1:´Male. When the comparison demonstrates the inequality, the value modification is recognized. Note that, since the birthday attribute is not participated in the transformation, the PersonTargetEnd class does not contain this field. 3
In this section, we show how EVL+Strace works using the Families2Persons trace metamodel. Figure 2 shows the case-specific trace metamodel. The root of the metamodel is TraceModel. It has two kinds of trace links that are Reg2RegTraceLink and FamilyMember2PersonsTraceLink. The former connects FamilyRegisterSourceEnd to PersonRegisterTargetEnd. The latter links FamilySourceEnd and FamilyMemberSourceEnd to PersonTargetEnd. The instance object of FamilySourceEnd keeps information of the corresponding Family object in the source model such as the value of name and the references to the MemberSourceEnd objects. To access the corresponding source/target object, the trace link end has a reference type. For instance, FamilySourceEnd defines a familySourceEndType reference, which refers to the Family object in the source model. Note that, the relation between trace links and trace link ends is a bidirectional reference; therefore, accessing the link (end) is possible from the link end (link).
To modularize the EVL+Strace code, some EOL operations are defined for checking or fixing various types of updates. The EVL module consists of pre block, deletion, modification, relocation, and addition constraints. The pre block sets the useXmiIds feature of three resources (models) to true. Through this setting, all created objects in three models have their own xmi:ids. The Bx code deals with objects by means of these ids.
Deletion constraints are defined in the context of the SourceEnds or TargetEnds. They check if a source/target element has been removed and fix the violation by deleting the corresponding TraceLinkEnd instance. In the fix block, the owner link of that link end is notified from this deletion and another constraint in the context of that TraceLink is called. The called constraint deletes all link end objects and their corresponding source/target elements that are referenced by the TraceLink. Addition constraints are specified in the context of source/ target meta-classes. A new element has no fingerprint in the trace model. In other words, if there is no trace link end referring to that object, it is detected as a new element. While an addition in source (target) is recognized, the fix block should first add corresponding object in the target (source). Then, it adds corresponding trace link ends for new inserted elements in the trace. Finally, it links them by a typed trace link.
Modification constraints check and fix modifications of the attribute values. They are specified in the context of the SourceEnds or TargetEnds like deletion constraints. When a modification is recognized by a checking operation, the propagate operation should be called to fix the violation. For instance, modifying the name of Family or Member objects results in changing the name of corresponding Person(s). The developer may want to delete some objects and add new ones when a modification occurs (modifying the last name of a Person object is an example of this situation). Relocation constraints are also defined in the context of the TraceLinkEnds. Each reference in source/ target model has an equivalent reference in the trace model (if that reference is related to the transformation scenario). For instance, the father, mother, sons, daughters references are defined in the trace metamodel. If a reference of trace refers to a trace link end, and its equivalent reference in the source (target) refers to the object that is not corresponding to the mentioned trace link end, an element relocation is detected. Based on the relocation, a fixing strategy should be defined to restore the consistency.
An example of the EVL+Strace constraint is presented in Listing 1. This constraint checks if the name of the FamilyMemberSourceEnd object is modified (self.nameIsModified()). The nameIsModified() operation compare the names of self object and its correspondence (FamilyMember object in source). If the mentioned values are not equal, then it returns true. When the check expression (negation of the nameIsModified() operation) becomes false, EVL shows the message to the user in the validation view. By right clicking on the appeared message in the Validation view, the title of the fix block is presented to the user. When the user clicks on it, the statements of the fix block (here self.namePropagates()) are executed. (For more examples refer to Appendix A) 1 context Families2Persons!FamilyMemberSourceEnd{ 2 guard: not self.isRemoved() and not self.refFamilyMember2Persons.endTypeIsRemoved() 3 constraint nameIsModified{ 4 check: not self.nameIsModified() 5 message: ’name of ’+self +’ is modified’ 6 fix{ 7 title:’Propagate the modification’ 8 do{ self.namePropagates();} 9 }}}
Listing 1: nameIsModified constraint in the context of FamilyMemberSourceEnd
The approach code is verbose, and designing a trace metamodel for each transformation case study is time consuming. Therefore, to automatically produce the trace metamodel and generate main parts of code, we implement a tool called MoDEBiTE 2 (please see Appendix A.3). EVL+Strace provides an interactive transformation system. In special cases, when there is no conflict between the manual changes on the source and target models, it is possible to specify the constraint in order to be executed automatically. To provide auto-fix constraints, the shape of code should be changed, in which fix blocks are removed and their statements are shifted to the check block. When the number of violations in interactive case is enormous, the user must spend extra effort to select from the alternatives. However, being interactive can be beneficial in check-only mode. In this case, the user may only want to know which constraints are broken, but it is not needed to enforce the consistency. EVL+Strace does not need to specify the execution mode. The order of selecting the violated messages, which must be fixed, is important in some cases. Therefore, the approach handles execution order by defining some lazy constraints, which is required to be called from other constraints. 4
To test the solution, we use EUnit and Workflow tools [
From all 34 test cases, automatic EVL+Strace approach has 32 expected pass and two failures. The date value in set birthday operations (defined in PersonHelper.eol) is specified by the cal.getTime() statement that returns the date, time (with millisecond), and time zone. The millisecond and time zone are specified based on the current case of the system. Since the expected target models in our test cases are not actively created, the generated and expected target models are only different in two values (millisecond and time zone). In other words, the birthday values of the generated and expected target models are the same in the first parts. Therefore, some results in Table 1 are determined by star( ) which show this case. 5
This paper presents a bidirectional model-to-model transformation solution to the TTC 2017 Families to Persons case study. The proposed solution is based on a novel approach named EVL+Strace, which uses the EVL language (one of the Epsilon family languages) and a case-specific trace metamodel. The trace metamodel (correspondence 2The tool can be downloaded from the MoDEBiTE link in http://mdse.bahmanzamani.com/tools/ metamodel) is specific to the domains of the Families and Persons case studies. The approach defines constraints to check user updates with the use of EVL. This language enables us to fix the violations if an inconsistency is recognized. It is possible to program more than one fixing ways, and interactively ask the user to restore the consistency. To test the solution, we change the constraints to fix the violations automatically. The evaluation presents that from all 34 test cases, EVL+Strace can pass 32 cases.
A A.1
We divide the EOL operations into four groups including Auxiliary, Delete, Modify, and Add operations. The last three groups have two types, i.e., Check and Fix. Auxiliary operations are used by other EOL operations. They compute values and get or find objects. A Delete operation checks if an object is removed, or in some cases, it deletes an object from models. Following that, Modify operations identifies whether an attribute value is modified, or an element is relocated and then propagates the update. Finally, Add operations investigate if a source/target object is manually added, or in some cases, they insert new elements in models, fix the references, and transform the references from one model into another. For this case study, the MoDEBiTE tool generates 13 auxiliary operations. Three of them compute the values of the name attributes for Family, FamilyMember, and Person objects. Five operations are for getting the source/target objects from the trace link ends and five ones are defined to get the corresponding trace link end for an object in the source/target model. Listing 2 presents examples of auxiliary operations for the case study. 1 operation computeFamilyName(x:String):String 2 { return x.split(’, ’).first; } 3 operation computeMemberName(x:String):String 4 { return x.split(’, ’).second; } 5 operation computePersonName(x:String,y:String):String 6 { return x+’, ’+y; } 7 @cached 8 operation Source!FamilyRegister getTraceLinkEnd() 9 { 10 11 12 13 14 15 16 } var seq = Families2Persons!FamilyRegisterSourceEnd.all.
select(s|not s.familyRegisterSourceEndType.isTypeOf(Families2Persons!EObject)); for (s in seq) if (self.id = s.familyRegisterSourceEndType.id)
return s; return null;
Listing 2: Example of automatically generated Auxiliary operations
Additionally, we define eight auxiliary operations (Listing 3) to make programming easier such as isMale() operation to check if a member is a male person or getFamily() to find the Family object from a member object. 1 operation Source!FamilyMember isFather():Boolean{ return self.fatherInverse.isDefined();} 2 operation Source!FamilyMember isMother():Boolean{ return self.motherInverse.isDefined();} 3 operation Source!FamilyMember isSon():Boolean{ return self.sonsInverse.isDefined();} 4 operation Source!FamilyMember isDaughter():Boolean{ return self.daughtersInverse.isDefined();} 5 operation Source!FamilyMember isMale():Boolean{ return self.isFather() or self.isSon();} 6 operation Source!FamilyMember isFemale():Boolean{ return self.isMother() or self.isDaughter();}
The tool generates five operations from the Add-Check category, named isNew, to check if a source/target object is new inserted or not. The isNew operation for FamilyMember object is shown in Listing 4. var seq = Families2Persons!FamilyMemberSourceEnd.all.
select(s|not s.familyMemberSourceEndType.isTypeOf(Families2Persons!EObject)); for (s in seq) if (self.id = s.familyMemberSourceEndType.id)
return false; return true;
1 operation addFamilyMemberSourceEnd(object: Source!FamilyMember ){ 2 var end = new Families2Persons!FamilyMemberSourceEnd; 3 end.familyMemberSourceEndType = object; 4 end.name = object.name; 5 Families2Persons!FamilyMemberSourceEnd.all.add(end); 6 Families2Persons!TraceModel.all.first.linkends.add(end); 7 return end; 8 }
Listing 5: addFamilyMemberSourceEnd operation for adding MemberSourceEnd in the trace model 2. Two operations for adding trace links (two types of trace links). 1 operation addReg2RegTraceLink (srcFamilyRegisterSourceEnd: Families2Persons!FamilyRegisterSourceEnd, 2 tarPersonRegisterTargetEnd: Families2Persons!PersonRegisterTargetEnd){ 3 var link = new Families2Persons!Reg2RegTraceLink; 4 link.srcRefFamilyRegister = srcFamilyRegisterSourceEnd; 5 link.trgRefPersonRegister = tarPersonRegisterTargetEnd; 6 Families2Persons!Reg2RegTraceLink.all.add(link); 7 Families2Persons!TraceModel.all.first.links.add(link); 8 return link; 9 }
Listing 6: Operations for adding trace links 3. Six operations for inserting new objects in the source and target models. Listing 7 presents the insertFamilyMember operation, which takes a Person object and create a FamilyMember object in the source. 1 operation insertFamilyMember (personObject : Target!Person ): Source!FamilyMember{ 2 var source = new Source!FamilyMember; 3 source.name = computeMemberName(personObject.name); 4 return source; 5 }
Listing 7: insertFamilyMember operation for inserting a member in the source 4. 12 operations for setting source/target references and 12 operations for setting trace references. 5. 24 operations for transforming from source/target references to trace references, and vice versa (Listing 8). 1 operation Families2Persons!FamilySourceEnd copyFamilySourceEndfather () 2 { var modelObject = self.getEndType(); 3 if(self.father.isDefined()) 4 modelObject.setFather(self.father.getEndType()); 5 }//copy from FamilySourceEnd.father to Source!Family.father
Listing 8: copyFamilySourceEndfather operation transforms elements from trace to source 6. Two operations for transforming from the families reference of FamilyRegisterSourceEnd to the persons reference of PersonRegisterTargetEnd, and vice versa (Listing 9). 1 operation copyFamilyRegisterSourceEndfamilies2PersonRegisterTargetEndpersons(){ 2 for(familyRegister in Families2Persons!FamilyRegisterSourceEnd.all) 3 for(family in familyRegister.families) 4 for(familylink in family.refFamilyMember2Persons) There are four Modify-Check operations for checking if the name attribute is modified or not. One example is presented in Listing 10. 1 operation Families2Persons!FamilySourceEnd nameIsModified(): Boolean 2 { 3 if(self.name<> self.familySourceEndType.name) return true; 4 else return false; 5 }
For the Modify-Fix category, three operations are defined. Listing 11 shows one of these operations. 1 operation Families2Persons!FamilySourceEnd namePropagates(){ 2 self.name = self.getEndType().name; 3 for (tr in self.refFamilyMember2Persons){ 4 if(not tr.endTypeIsRemoved()){ 5 tr.trgRefPerson.name = computePersonName(self.name,tr.trgRefPerson.name.split(’, ’).second); 6 var targetObject = Target!Person.all.selectOne(o|o.id = tr.trgRefPerson.personTargetEndType.id); 7 targetObject.name = computePersonName(self.name,targetObject.name.split(’, ’).second); 8 }} 9 return self.name;}
The MoDEBiTE tool generates 12 operations for the Delete-Check category including five operations for checking removed source/target objects from the context of trace link ends, five operations for checking trace link ends from the context of trace links and two ones for checking removed trace links. It also produces five operations for deleting the source/target objects and corresponding trace link ends.
A.2
1 import ’atomicOperations.eol’; 2 pre{ 3 Families2Persons.resource.useXmiIds= true; 4 Source.resource.useXmiIds= true; 5 Target.resource.useXmiIds= true;}
Deletion constraints check if a source/target object is removed and fix the violation. MoDEBiTE generates 10 constraints for checking and fixing deletions. In Listing 13, the isRemoved constraint is defined in the context of FamilyMemberSourceEnd, and check if a FamilyMember object is removed. 1 context Families2Persons!FamilyMemberSourceEnd{ 2 constraint isRemoved{ 3 check: not self.isRemoved() 4 message: ’The ’+self +’ has a removed type’ 5 fix{ 6 title:’delete the ’+self 7 do{ 8 var tracelink = self.refFamilyMember2Persons; 9 delete self; 10 tracelink.satisfies("srcRefFamilyMemberIsRemoved"); 11 }}} 12 }
Modification and relocation constraints check if any attribute value is modified or any element is moved. There are six constraints in this category. Listing 14 demonstrates the code of familyMemberRoleIsRelocated constraint.
Listing 14: familyMemberRoleIsRelocated constraint for detecting element relocation
We define 8 constraints for Addition category. Listing 15 represents the code of the familyObjectIsNew constraint. it checks if the family of one member in the source is moved to a new Family object. 1 context Source!FamilyMember{ 2 constraint familyObjectIsNew{// the generated code of this constraint should be checked 3 guard: not self.isNew() 4 check: not ((self.fatherInverse.isDefined() and self.fatherInverse.isNew()) or 5 (self.motherInverse.isDefined() and self.motherInverse.isNew()) or 6 (self.sonsInverse.isDefined() and self.sonsInverse.isNew()) or 7 (self.daughtersInverse.isDefined() and self.daughtersInverse.isNew())) 8 message: self+’ is related to the new family’ 9 fix{ 10 title: ’Insert the correspondence’ 11 do{ 12 var familyMemberSourceEnd = self.getTraceLinkEnd(); 13 var family; 14 var familyMember2Personslink = self.getTraceLinkEnd().refFamilyMember2Persons; 15 var oldFamilySourceEnd = familyMember2Personslink.srcRefFamily; 16 var oldPerson = familyMember2Personslink.trgRefPerson.getEndType(); 17 var person; 18 family = self.getFamily(); 19 family.satisfies("isNew"); 20 var familySourceEnd = family.getTraceLinkEnd(); 21 familyMember2Personslink.srcRefFamily = familySourceEnd; 22 if((oldPerson.isTypeOf(Target!Female) and self.isMale()) or 23 oldPerson.isTypeOf(Target!Male) and self.isFemale()) 24 {if(self.isMale()) person = insertMale(family,self); 25 else person = insertFemale(family,self); 26 person.birthday = oldPerson.birthday; delete oldPerson.getTraceLinkEnd(); delete oldPerson; var personTargetEnd = addPersonTargetEnd(person); familyMember2Personslink.trgRefPerson = personTargetEnd;} else{ oldPerson.name = computePersonName(family.name,self.name); oldPerson.getTraceLinkEnd().name = oldPerson.name;} copySrc2Trg();} }}}
In automatic EVL+Strace the shape of code is changed, in which fix blocks are removed and their statements are shifted to the check block. Listing 16 shows the excerpt code of this transfiguration. To make the code more readable and modular, we define some new operation and put the statements of fix block in them. 1 context Target!Female{ 2 constraint isNew{ 3 check{ var result = not self.isNew(); 4 if(not result){ 5 if(preferExistingToNewFamily and Source!Family.all.exists(f|f.name = computeFamilyName(self.name))){ 6 if(preferParentToChild){self.fixIsNewExistingFamilyParent();} 7 else{self.fixIsNewExistingFamilyDaughter();}} 8 else{ 9 if(preferParentToChild){self.fixIsNewNewFamilyParent();} 10 else{self.fixIsNewNewFamilyDaughter();}}} 11 return true; 12 }}}
A.3
The MoDEBiTE toolkit is developed to produce the artifacts of EVL+Strace transformation, including the specific trace metamodel and the Epsilon code (EOL operations and EVL constraints). To generate the mentioned artifacts, the toolkit asks the developer to design a weaving model conforming to the MoDEBiTE weaving metamodel. For the Families to Persons case study, MoDEBiTE can automatically generate the specific trace metamodel (presented in Figure 2) from the weaving model. As mentioned in Appendix A.1 and A.2, MoDEBiTE can produce main parts of the transformation code. Table 2 presents that how much of code can be generated by MoDEBiTE.