Downloaded 11 times
![35 Similarity function
A similarity function between metamodels is defined
and «measures» how similar two metamodels are.
It is based on the Similarity Flooding algorithm used
for schema matching and ontology alignment
[Melnik et al, Falleri et
APierantonio - ACM/IEEE 17th MoDELS, Valencia
al]
It is evaluated each time a new transformation is
committed (deleted, or updated) into the repository
and stored for later use.](https://image.slidesharecdn.com/2014models-141001044102-phpapp01/85/Automated-chaining-of-model-transformations-with-incompatible-metamodels-35-320.jpg)
Uploaded byAlfonso Pierantonio
Automated chaining of model transformations with incompatible metamodels
The document discusses automating the chaining of model transformations between incompatible metamodels. It proposes enhancing composability by using co-evolution techniques to determine when metamodels that are technically incompatible may still allow transformations to be chained. When the incompatibility is due to resolvable changes between metamodel versions, an adapter transformation can be automatically generated to migrate models between the metamodels. This approach allows more transformations in a repository to be discoverable and composable when chaining is needed between seemingly incompatible metamodels.
More Related Content
Similar to Automated chaining of model transformations with incompatible metamodels
Automated chaining of model transformations with incompatible metamodels
- 1. Automated chaining of model transformations with incompatible metamodels Joint work with Francesco Basciani, Davide Di Ruscio, Ludovico Iovino Dipartimento di Ingegneria e Scienze dell’Informazione e Matematica Università degli Studi dell’Aquila Alfonso Pierantonio APierantonio
- 2. 2 Summary Introduction Composition Problem Statement Automating the Chaining Process Enhancing Composability Metamodel Similarity Tool Conclusions APierantonio - ACM/IEEE 17th MoDELS, Valencia
- 3. 3 Introduction Modeltransformations have a vital role in MDE because they are employed to bridge different domains and/or abstraction levels. New transformations can be developed by composing existing ones according to user requirements. Composing transformations is a complex problem: – transformations must be discovered and selected from different APierantonio - ACM/IEEE 17th MoDELS, Valencia and heterogeneous sources ∙ eg., ATL Zoo, GitHub, etc. – the common way to compose transformations is to chain them, ie. by passing models from one transformation to another
- 4. 4 External vs.Internal composition Composition can be distinguished in: – external composition (black-box): by chaining separate model transformations and passing models from one transformation to another – internal composition (white-box): by composing two model transformation definitions into a new model transformation Both are important and complement each other, in this talk we focus on external composition APierantonio - ACM/IEEE 17th MoDELS, Valencia
- 5. 5 Problem statement Given two metamodels MMi and MMf we would like to understand whether there is a composition of existing transformations bridging them. MMi MMf MMf APierantonio - ACM/IEEE 17th MoDELS, Valencia
- 6. Problem statement Giventwo metamodels MMi and MMf we would like to understand whether there is a composition of existing transformations bridging them. 6 MMi MMf APierantonio - ACM/IEEE 17th MoDELS, Valencia repository MMf ?
- 7. 7 Problem statement A repository of metamodels and transformation is considered to consistently manage them MMi MMf MM23 APierantonio - ACM/IEEE 17th MoDELS, Valencia MM17 repository MM2 MM6 MM11 MM4 MM7 MM8 MM14 MM5 MM12 MM13 MM3 MM9 MM20 MM19 MM26 MM1 MM25 MM27 MM18 MM21 MM30 MM10 MM24 MMf MM31 MM1 MM17 MM22 MM1 …
- 8. 8 External composition Under which conditions, two transformations can be composed ? So far, only syntactic embedding was allowed, ie. MM2 MM3 Alfonso Pierantonio – 7th SATToSE, L’Aquila (Italy)
- 9. 9 Problem statement We identify the possible transformation pathways based on compatible metamodels. MMi MMf MM23 APierantonio - ACM/IEEE 17th MoDELS, Valencia repository MM2 MM7 MM8 MM14 MM9 MM20 MM19 MM27 MM18 MM MM21 10 MMf MM1 … MM6 MM11 MM4 MM5 MM12 MM13 MM3 MM17 MM26 MM1 MM25 MM24 MM31 MM1 MM22 MM1 MM30
- 10. 10 Problem statement What happens if MM MMand MM / MM? 9 8 18 30 MM1 MMf MM23 APierantonio - ACM/IEEE 17th MoDELS, Valencia repository MM2 MM7 MM8 MM14 MM9 MM20 MM19 MM27 MM18 MM MM21 10 MMf MM1 … MM6 MM11 MM4 MM5 MM12 MM13 MM3 MM17 MM26 MM1 MM25 MM24 MM31 MM1 MM22 MM1 / MM30 ? ?
- 11. 11 Goal Thegoal of this work is to enhance transformation composability by using co-evolution techniques. In many cases output and input metamodels have similar «informational» structures, for instance – subsequent versions of the same metamodel – state machines in UML 1.4 and UML 2.0 Then, metamodel compatibility conditions which are too strong would discard transformations that potentially might be chained. APierantonio - ACM/IEEE 17th MoDELS, Valencia
- 12. Automating the chainingprocess
- 13. 13 Chaining Process We start with the source and target metamodels. APierantonio - ACM/IEEE 17th MoDELS, Valencia Discovery of required model transformations Derivation of the model transformations chain Execution of the derived model transformations chain 1 2 Source Model Target Metamodel
- 14. 14 Chaining Process The chaining process can be described with the following simple activity diagram. APierantonio - ACM/IEEE 17th MoDELS, Valencia 1 Discovery of required model transformations 2 Derivation of the model transformations chain Source Model Target Metamodel Execution of the derived model transformations chain
- 15. 15 Discovery Itassumes transformations written in different languages are stored in a modeling repository. APierantonio - ACM/IEEE 17th MoDELS, Valencia 1 Discovery of required model transformations 2 Derivation of the model transformations chain Execution of the derived model transformations chain Source Model Target Metamodel
- 16. 16 Discovery MDEForge It assumes transformations written in different languages are stored in a modeling repository. MDE Forge is a a generic and open repository of artifacts with community workspaces. • It is generic because it permits the management of any kind of (modeling and non-modeling) artifacts. • It is open because it has an open architecture which APierantonio - ACM/IEEE 17th MoDELS, Valencia permits user-defined extensions. 1 Discovery of required model transformations 2 Derivation of the model transformations chain Execution of the derived model transformations chain Source Model Target Metamodel
- 17. 17 Discovery Itassumes transformations written in different languages are stored in a modeling repository. APierantonio - ACM/IEEE 17th MoDELS, Valencia 1 Discovery of required model transformations 2 Derivation of the model transformations chain Execution of the derived model transformations chain Source Model Target Metamodel
- 18. 18 Derivation Therepository is given as a directed graph where nodes and edges represent metamodels and transformations, respectively. The derivation is performed by analyzing the graph. APierantonio - ACM/IEEE 17th MoDELS, Valencia 1 Discovery of required model transformations 2 Derivation of the model transformations chain Execution of the derived model transformations chain Source Model Target Metamodel
- 19. 19 Model TransformationsChaining Process The transformations present within the chain of transformations are executed. APierantonio - ACM/IEEE 17th MoDELS, Valencia 1 Discovery of required model transformations 2 Derivation of the model transformations chain Execution of the derived model transformations chain Source Model Target Metamodel
- 20. 20 Enhancing Composability The «distance» between the incompatible metamodels can be viewed as a metamodel evolution. Composability can be enhanced with co-evolution techniques. MM1 MMf MM23 APierantonio - ACM/IEEE 17th MoDELS, Valencia repository MM2 MM7 MM8 MM14 MM9 MM20 MM19 MM27 MM18 MM10 MMf MM1 … MM6 MM11 MM4 MM5 MM12 MM13 MM3 MM17 MM26 MM1 MM25 MM24 MM31 MM1 MM22 MM1 MM21 MM30
- 21. Petri Nets targetmetamodel of T1 source metamodel of T2
- 22. Petri Nets targetmetamodel of T1 source metamodel of T2
- 23. Petri Nets targetmetamodel of T1 δ1: pull up of the attribute name to the new abstract metaclass NamedElement source metamodel of T2
- 24. Petri Nets targetmetamodel of T1 δ1: pull up of the attribute name to the new abstract metaclass NamedElement δ2: renaming of the metaclass Net as PetriNet source metamodel of T2
- 25. 25 Coupled evolutionchanges Metamodel changes can be classified according to their impact over the related artifacts Type of change Effects Non breaking Changes which do not break the conformance of models to the corresponding metamodel. Breaking resolvable Changes which break the conformance of models even though conformance can be automatically restored. Breaking non-resolvable Changes which break the conformance of models which cannot automatically co-evolved and user intervention is required. APierantonio - ACM/IEEE 17th MoDELS, Valencia
- 26. 26 Coupled evolutionchanges Metamodel changes can be classified according to their impact over the related artifacts Type of change Effects Non breaking Changes which do not break the conformance of models to the corresponding metamodel. Breaking resolvable Changes which break the conformance of models even though conformance can be automatically restored. Breaking non-resolvable Changes which break the conformance of models which cannot automatically co-evolved and user intervention is required. APierantonio - ACM/IEEE 17th MoDELS, Valencia Non-breaking changes corresponds to compatible metamodels
- 27. 27 Coupled evolutionchanges Metamodel changes can be classified according to their impact over the related artifacts Type of change Effects Non breaking Changes which do not break the conformance of models to the corresponding metamodel. Breaking resolvable Changes which break the conformance of models even though conformance can be automatically restored. Breaking non-resolvable Changes which break the conformance of models which cannot automatically co-evolved and user intervention is required. APierantonio - ACM/IEEE 17th MoDELS, Valencia We want to extend composability to breaking resolvable changes.
- 28. repository PetriNet 1.0and PetriNet 2.0 are incompatible. However, they are made different by breaking and resolvable changes. Thus, an adapter which migrates the PN1 models into PN2 can be automatically obtained.
- 29. 29 Generation ofthe Adapter transformation The adapter is synthesized from the differences between the target and source metamodels of the transformations to be chained. APierantonio - ACM/IEEE 17th MoDELS, Valencia
- 30. 30 Generation ofthe Adapter transformation The adapter is synthesized from the differences between the target and source metamodels of the transformations to be chained. δ2: renaming of the metaclass Net as PetriNet APierantonio - ACM/IEEE 17th MoDELS, Valencia
- 31. 31 Generation ofthe Adapter transformation Finally, we are able to have a complete transformation pathway from MMi to MMf MM1 MMf MM23 APierantonio - ACM/IEEE 17th MoDELS, Valencia repository MM2 MM7 MM8 MM14 MM9 MM20 MM19 MM27 MM18 MM10 MMf MM1 … MM6 MM11 MM4 MM5 MM12 MM13 MM3 MM17 MM26 MM1 MM25 MM24 MM31 MM1 MM22 MM1 MM21 MM30
- 32. 32 Problem Doesit make sense to generate the adapter for any breaking and resolvable change? MM1 MMf MM23 APierantonio - ACM/IEEE 17th MoDELS, Valencia repository MM2 MM7 MM8 MM14 MM9 MM20 MM19 MM27 MM18 MM10 MMf MM1 … MM6 MM11 MM4 MM5 MM12 MM13 MM3 MM17 MM26 MM1 MM25 MM24 MM31 MM1 MM22 MM1 MM21 MM30
- 33. 33 Problem Doesit make sense to generate the adapter for any breaking and resolvable change? Does it make sense to compose any compatible transformation? MM1 MMf MM23 APierantonio - ACM/IEEE 17th MoDELS, Valencia repository MM2 MM7 MM8 MM14 MM9 MM20 MM19 MM27 MM18 MM10 MMf MM1 … MM6 MM11 MM4 MM5 MM12 MM13 MM3 MM17 MM26 MM1 MM25 MM24 MM31 MM1 MM22 MM1 MM21 MM30
- 34. 34 Problem Itmay make sense to restrict composition to metamodels which are in a way «similar». distance distance APierantonio - ACM/IEEE 17th MoDELS, Valencia T1 T2 metamodel coverages MM2 and MM3 are dissimilar T1 T2 metamodel coverages MM2 and MM3 are similar
- 35. 35 Similarity function A similarity function between metamodels is defined and «measures» how similar two metamodels are. It is based on the Similarity Flooding algorithm used for schema matching and ontology alignment [Melnik et al, Falleri et APierantonio - ACM/IEEE 17th MoDELS, Valencia al] It is evaluated each time a new transformation is committed (deleted, or updated) into the repository and stored for later use.
- 36. 36 Similarity function The similarity values are maintained in a table like this: Grafcet PetriNet1.0 PetriNet2.0 XML PNML Grafcet 1 0,20 0,30 0,29 0,26 PetriNet1.0 - 1 0,20 0,28 PetriNet2.0 0,30 1 0,30 0,30 XML 0,29 0,20 0,30 1 - PNML 0,26 - - 0,28 1 If the similarity between two considered metamodels is higher then a fixed threshold (i.e. 0,80) such metamodels are further analyzed. Then, if the resulting delta model consists of non-breaking and breaking and resolvable changes, then corresponding adapters are generated. APierantonio - ACM/IEEE 17th MoDELS, Valencia 0,89 0,89
- 37. A component inMDE Forge has been designed. Implementation
- 38. 38 1/Upload ofthe source model In the first step the user has to upload his model A. Pierantonio - ACM/IEEE 17th Intl. Conf.Model Driven Engineering Languages and Systems
- 39. 39 2/Selection oftarget metamodel Once the model has been uploaded, the system is able to detect the metamodel the model conforms to. Afterwards, the user has to select the target metamodel as shown in this screenshot: The metamodel list is automatically retrieved from the repository. The system will only search in the repository the metamodels target of all these transforma-tions. A. Pierantonio - ACM/IEEE 17th Intl. Conf.Model Driven Engineering Languages and Systems
- 40. 40 3/Transformation chainselection All the possible chains that satisfy the user request are shown. Each chain is characterized by different attributes, as • chain length, • metamodel coverage, • usage frequency, • average execution time, • ect. A. Pierantonio - ACM/IEEE 17th Intl. Conf.Model Driven Engineering Languages and Systems
- 41. 41 4/Report Oncethe chain has been executed some statistical data are produced, presented to the user, and stored in the system. APierantonio - ACM/IEEE 17th MoDELS, Valencia
- 42. Future Work andConclusions
- 43. 43 Conclusions Thework aims at developing new transformations by composing existing ones according to user requirements. The proposed approach makes use of well-known co-evolution techniques to enhance the composability of transformations. Similarity metrics between metamodels are used in order to avoid information erosion. A repository of artifacts, called MDE Forge has been build in order to overcome the problem of the heterogeneity of the sources. APierantonio - ACM/IEEE 17th MoDELS, Valencia
- 44. 44 Future work A major drawback is that the composition mechanism is purely syntactical, semantic properties must be taken into account – Well-formedness constraints must be considered – Some semantic description of the modeling language has also to be considered, eg. descriptive logics Breaking non resolvable changes must be taken into account by adopting partiality and uncertainty. Validation and experimentation necessary to correlate information erosion and similarity thresholds. APierantonio - ACM/IEEE 17th MoDELS, Valencia
- 45.
Editor's Notes
- #19 Referring to a graph representation of the repository.
- #20 Fin qui abbiamo visto solo il caso standard nel quale la compatibilità tra 2 MM è data semplicemente dall’NsURI (o dal nome del file, o dall’ID dell’artefatto salvato su DB)
- #30 A partire da un modello delle differenze, che rappresenta le differenze tra 2 MM incompatibili, l’approccio è capace di generare trasformazioni di adattamento come quella del caso di studio tra PetriNet1.0 e PetriNet2.0 L’approccio si basa sulle HIGH ORDER TRANSFORMATION. Questo si è reso necessario per far fronte al problema della coupled evolution.
- #31 A partire da un modello delle differenze, che rappresenta le differenze tra 2 MM incompatibili, l’approccio è capace di generare trasformazioni di adattamento come quella del caso di studio tra PetriNet1.0 e PetriNet2.0 L’approccio si basa sulle HIGH ORDER TRANSFORMATION. Questo si è reso necessario per far fronte al problema della coupled evolution.
- #36 Another element to consider is the similarity function
- #37 Another element to consider is the similarity function