SLE 2012 Model to model transformation co-evolution

Editor's Notes

• #2: Good morning. It is a pleasure for me to be here. I am going to present the work entitled “Model transformation co-evolution: a semi-automatic approach”
• #3: In MDE metamodels are subject to evolution. This is accepted by researchers and practitioners. There are many reasons for this. During design alternative metamodel versions may be developed. During implementation metamodels may be adapted to a concrete metamodel formalism supported by a tool. Finally, during maintenance errors in a metamodel may be corrected. Moreover, parts of the metamodel may be redesigned due to a better understanding or to facilitate reuse The consecuence of this evolution on Mms, is that the artifacts which are related to this metamodel get outdated. This is the case of both models and transformations. - The impact of metamodel changes on models has been studied in several works. On the contrary, transformation co-evolution has received less attention. It was the missing piece
• #4: In MDE metamodels are subject to evolution. This is accepted by researchers and practitioners. There are many reasons for this. During design alternative metamodel versions may be developed. During implementation metamodels may be adapted to a concrete metamodel formalism supported by a tool. Finally, during maintenance errors in a metamodel may be corrected. Moreover, parts of the metamodel may be redesigned due to a better understanding or to facilitate reuse The consecuence of this evolution on Mms, is that the artifacts which are related to this metamodel get outdated. This is the case of both models and transformations. - The impact of metamodel changes on models has been studied in several works. On the contrary, transformation co-evolution has received less attention. It was the missing piece
• #5: The summary of the problem would be: - (contextualizar) MM evolution impacts on transformations, because model to model transformations are specified using concepts from input and output model´s metamodels. - (motivar) Manual migration... - (resolver) Having this into account we propose a... (No comentar las contribuciones. Se comentarán en conclusiones)
• #6: This picture outlines an overview of this process Is a process that, given the original source and target metamodels, the evolved source and/or target metamodel/s and the transformation, generates the adapted transformation model, that will be extracted to an .atl file. -In the first phase, the detection phase 1) given the original and evolved metamodels, simple changes are detected using a comparison tool. 2) Then, these changes are grouped into simple or complex changes where applicable, in a simple to complex transformation. - Then, in the Co-evolution phase we have two auxiliary steps and the co-evolution itself. 3) In the similarity analysis a similarity model is derived from the input and output Mms (las últimas versiones) and will be optionally an input in the adaptation to infere where to map new elements. 4) CNF conversion: On the other hand, conditional expressions might need to be rewritten in CNF conversion phase to make possible to apply minimum deletion algorithms to the transformation. 5) Last, the Migrator performs the actual adaptation. Adaptation is implemented with a transformation modification HOT pattern
• #7: As a comparison tool to obtain the simple changes we use EMF Compare. This tool takes two models as input and obtains the differences along the Difference metamodel. We have done an extension to this metamodel in order to support the concept of complex change. Having this metamodel, we are able to transform the model of simple changes to a model of complex changes using a transformation. The reason for this is that we want changes to conform a meaningful transation on the MM to not miss the intention of the designer and avoid misunderstandings.
• #8: Once we have obtained the changes model, we are going to use it as input in the next phase: the co-evolution Our adaptation approach is based on a taxonomy of changes. This taxonomy of changes is divided into three groups based on the impact on transformations: - NBC: These changes have no impact on the transformation. - BRC: These changes do impact the transformation rules, but this impact is amenable to be automated. - BUC: These changes also impact the transformation, but full automatization is not possible and user intervention is required. We don't have time to see in detail all the changes. We will study 5 scenarios which are representative.
• #9: Before we deal with the adaptation we need two auxiliary steps: one related to subtractive changes and the other related to additive changes. - CNF conversion: CNF is a conjunction of clauses, where a clause is a disjunction of literals. (Es decir, ANDs que dentro tienen ORs) In order to delete transformation structures properly, it is important to have the expressions normalized. - Similarity analysis is used to achieve a higher degree of automatization in additive changes. A similarity analysis is conducted between source and target Mms, to look for a matching element to the new elements. The effectiveness depends a lot on the semantic gap between metamodels. (This is based on metamodel matching works.)
• #10: Now I will use an scenario to illustrate some of the change types: We use a popular transformation from bibliography that transforms exam questions to Web-based exams along the MVC pattern. Left is the Exam MM, which is the input and right the Assistant MM, which is the output I will introduce some examples of changes in a metamodel: -Scenario 1. The AssistantMVC's Multiple class is introduced in the target metamodel. This new class abstracts away the commonality of three existing classes: MultipleChoiceController, MultipleChoiceView and MultipleChoice. - Scenario 2. Property optional is deleted from ExamXML's ExamElement. - Scenario 3. The AssistantMVC's fontColor metaproperty is changed from string to integer. -Scenario 4. The ExamXML's OpenElement class is splitted into OpenEle- ment_1 and OpenElement_2. -Scenario 5. New subclass ExerciseElement is added to ExamElement meta- class, and a new property style is added to View target metaclass.
• #11: Now I will use an scenario to illustrate some of the change types: We use a popular transformation from bibliography that transforms exam questions to Web-based exams along the MVC pattern. Left is the Exam MM, which is the input and right the Assistant MM, which is the output I will introduce some examples of changes in a metamodel: -Scenario 1. The AssistantMVC's Multiple class is introduced in the target metamodel. This new class abstracts away the commonality of three existing classes: MultipleChoiceController, MultipleChoiceView and MultipleChoice. - Scenario 2. Property optional is deleted from ExamXML's ExamElement. - Scenario 3. The AssistantMVC's fontColor metaproperty is changed from string to integer. -Scenario 4. The ExamXML's OpenElement class is splitted into OpenEle- ment_1 and OpenElement_2. -Scenario 5. New subclass ExerciseElement is added to ExamElement meta- class, and a new property style is added to View target metaclass.
• #12: - Scenario 1: It must be noted the importance of having this change as a complex change, otherwise it would be interpreted as a set of simple breaking changes instead of one non-breaking complex change
• #13: - This minimum deletion deserves further explanation
• #14: When a metaclass or a metaproperty is deleted, affected transformation elements have to be removed while keeping the transformation logic coherent. But if we delete everything and leave the transformation empty, it would compile properly but for sure it is not what we expected. What we expect is to removed only the necessary elements. There are different language structures to have into account:Some of them are very intuitive, as concatenations or collections, where we only remove the affected elements, but boolean expressions are not straightforward Boolean expressions are important because they are generally used in rule filters. First, we need to convert the expression to CNF, as we said before, using equivalence rules of Predicate Calculus. Then we need to apply conversion rules. there are two removal policies:- One is R subindex T, which means that the removed literal is satisfied by default- The other is R subindex F, which means that it is unsatisfied by default Why this? In the process of metamodel redesign, the designer could help giving the reason to take the decision of removing a metaproperty from the metamodel. For example, if all students in the university had a very good level of English (because it is a new precondition for the enrollment), it could be consideredas satised by default, and in case of removing the speakEnglish metaproperty, its value could be reinterpreted as removed&satised-by-default (RT). On the other hand, if the university had decided not to participate in the Erasmus Program, no student would have such grant, and in case of removing the ErasmusGrant metaproperty, its value could be reinterpreted as removed&unsatised-by-default (RF). If, in the previous example, there had been this expression not ErasmusGrant or (speakEnglish and enrolledLastYear), and later the redesign process decided to remove the speakEnglish metaproperty, then according to the truth table the expression would be rewritten as not ErasmusGrant or enrolledLastYear ; if the removed metaproperty had been ErasmusGrant with RF policy, then the new expression would have been true.
• #15: The idea is applied in our second scenario Quite common situation: we have the opposite filter in two rules. Using minimal deletion we do not need to delete any of the rules Back to our second scenario (i.e. removal of optional from ExamElement), consider we have two rules whose filters refer to optional : In this way, surgically removal permits to limit the impact of deletion of properties in the associated rules.
• #16: - The problem with the types is that ATL does not check the types in compilation time, so a transformation can be syntactically right, but give an error in runtime “Only few cases are NBC”: this is the case when a type changes to a subclass or in the case of numerical values (integer, double, ...). In the other cases, we can only warn the designer about a possible error
• #17: - The forth scenario is an example of a complex breaking change. As result, rules having OpenElement as source should co-evolved. This is the case of the OpenQuestion rule, which is splitted in two rules: OpenQuestion_1 and OpenQuestion_2. The former contains the bindings related to OpenElement_1 while the latter keeps the bindings for OpenElement_2.
• #18: When the metaclass is splitted, some of the attributes will remain in one metaclass and others in the other. In this case, attr1 remains in OpenElement_1 and attr2 will be moved to OpenElement_2. Bindings corresponding to each attribute will belong to the corresponding rule.
• #19: Additive evolution is a NBC case. However, it is not unusual to need new rules or bindings to maintain the metamodel coverage level. For this purpose we include in the co-evolution the option to generate partially new rules, as they are not fully automatable. If we use a similarity model, the migrator may be able to fulfill the generated skeletons with the missing information
• #20: To sum up, we addressed how metamodel evolution can be semi-automatically propagated to the transformation counterpart. - As contributions we can mention: The simple to complex changes transformation, minimum deletion and the migration itself. - As premises The approach is realized for EMOF/ Ecore-based metamodels and Transformations must have a transformation MM
• #21: In this moment, I think that the logical way to go would be to put the approach through an empirical assessment. For that I need to complete all the functionality that is missing in the prototype and look for a real scenario. Ensure that the verification level is the same before and after the adaptation
• #23: V+V: - Solo nos encargamos de syntactic correctness. - Verification tengo alguna transformación hecha. Tener el Eclipse abierto con el atl. As well as we use transformations to adapt the transformations, we can use transformations as well to verify transformations. We must ensure that the verification level is the same before and after the adaptation - Validation no se cómo se haría. Esta cuestión afecta a las transformaciones en general. ¿Cómo sabemos que una transformación hace lo que tiene que hacer? Mirar bibliografía: contratos? Podría ser que en la adaptación metiésemos algún error?
• #24: there are two removal policies:- One is R subindex T, which means that the removed literal is satisfied by default- The other is R subindex F, which means that it is unsatisfied by default Why this? In the process of metamodel redesign, the designer could help giving the reason to take the decision of removing a metaproperty from the metamodel. For example, if all students in the university had a very good level of English (because it is a new precondition for the enrollment), it could be consideredas satised by default, and in case of removing the speakEnglish metaproperty, its value could be reinterpreted as removed&satised-by-default (RT). On the other hand, if the university had decided not to participate in the Erasmus Program, no student would have such grant, and in case of removing the ErasmusGrant metaproperty, its value could be reinterpreted as removed&unsatised-by-default (RF). If, in the previous example, there had been this expression not ErasmusGrant or (speakEnglish and enrolledLastYear), and later the redesign process decided to remove the speakEnglish metaproperty, then according to the truth table the expression would be rewritten as not ErasmusGrant or enrolledLastYear ; if the removed metaproperty had been ErasmusGrant with RF policy, then the new expression would have been true.
• #25: Type changes are very problematic in transformation languages with dynamic typing. Preguntas de los revisores In simple to complex: what happens if two predicates intersect with each other? Example: Flatten hierarchy and move metaproperty. Flatten hierarchy has priority, as it includes move property. Operators: complex changes are similar to operators. The difference is that with operators the MM evolution has to be done with an specific tool and assume that the person evolving the MM will be the same as the person co-evolving the other artifact. In our case there is freedom to change the MM the way you want.