1. Automated chaining ofmodel transformations withincompatible metamodelsJoint work with Francesco Basciani, Davide Di Ruscio, Ludovico IovinoDipartimento di Ingegneria e ScienzedellInformazione e MatematicaUniversit degli Studi dellAquilaAlfonso PierantonioAPierantonio

2. 2 SummaryIntroductionCompositionProblem StatementAutomating the Chaining ProcessEnhancing ComposabilityMetamodel SimilarityToolConclusionsAPierantonio - ACM/IEEE 17th MoDELS, Valencia 3. 3 IntroductionModel transformations have a vital role in MDE becausethey are employed to bridge different domains and/orabstraction levels.New transformations can be developed by composingexisting ones according to user requirements.Composing transformations is a complex problem: transformations must be discovered and selected from differentAPierantonio - ACM/IEEE 17th MoDELS, Valenciaand 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 compositionComposition can be distinguished in: external composition (black-box): by chaining separatemodel transformations and passing models from onetransformation to another internal composition (white-box): by composing twomodel transformation definitions into a new modeltransformationBoth are important and complement each other, inthis talk we focus on external compositionAPierantonio - ACM/IEEE 17th MoDELS, Valencia 5. 5 Problem statementGiven two metamodels MMi and MMf we would liketo understand whether there is a composition ofexisting transformations bridging them.MMi MMfMMfAPierantonio - ACM/IEEE 17th MoDELS, Valencia 6. Problem statementGiven two metamodels MMi and MMf we would liketo understand whether there is a composition ofexisting transformations bridging them.6MMi MMfAPierantonio - ACM/IEEE 17th MoDELS, ValenciarepositoryMMf? 7. 7Problem statementA repository of metamodels and transformation isconsidered to consistently manage themMMi MMfMM23APierantonio - ACM/IEEE 17th MoDELS, ValenciaMM17repositoryMM2MM6 MM11MM4MM7 MM8MM14MM5MM12MM13MM3MM9MM20MM19MM26MM1MM25 MM27MM18MM21MM30MM10MM24MMfMM31MM1MM17MM22MM1 8. 8 External compositionUnder which conditions, two transformations can becomposed ?So far, only syntactic embedding was allowed, ie.MM2 MM3Alfonso Pierantonio 7th SATToSE, LAquila (Italy) 9. 9Problem statementWe identify the possible transformation pathwaysbased on compatible metamodels.MMi MMfMM23APierantonio - ACM/IEEE 17th MoDELS, ValenciarepositoryMM2MM7 MM8MM14MM9MM20MM19MM27MM18MM MM21 10MMfMM1MM6 MM11MM4MM5MM12MM13MM3MM17MM26MM1MM25MM24MM31MM1MM22MM1MM30 10. 10Problem statementWhat happens if MM MMand MM /MM?9 8 18 30 MM1 MMfMM23APierantonio - ACM/IEEE 17th MoDELS, ValenciarepositoryMM2MM7 MM8MM14MM9MM20MM19MM27MM18MM MM21 10MMfMM1MM6 MM11MM4MM5MM12MM13MM3MM17MM26MM1MM25MM24MM31MM1MM22MM1/MM30?? 11. 11 GoalThe goal of this work is to enhance transformationcomposability by using co-evolution techniques.In many cases output and input metamodels havesimilar informational structures, for instance subsequent versions of the same metamodel state machines in UML 1.4 and UML 2.0Then, metamodel compatibility conditions which aretoo strong would discard transformations thatpotentially might be chained.APierantonio - ACM/IEEE 17th MoDELS, Valencia 12. Automating the chaining process 13. 13 Chaining ProcessWe start with the source and target metamodels.APierantonio - ACM/IEEE 17th MoDELS, ValenciaDiscovery of requiredmodel transformationsDerivation of the modeltransformations chainExecution of the derivedmodel transformations chain12SourceModelTargetMetamodel 14. 14 Chaining ProcessThe chaining process can be described with thefollowing simple activity diagram.APierantonio - ACM/IEEE 17th MoDELS, Valencia1Discovery of requiredmodel transformations2Derivation of the modeltransformations chainSourceModelTargetMetamodelExecution of the derivedmodel transformations chain 15. 15 DiscoveryIt assumes transformations written in differentlanguages are stored in a modeling repository.APierantonio - ACM/IEEE 17th MoDELS, Valencia1Discovery of requiredmodel transformations2Derivation of the modeltransformations chainExecution of the derivedmodel transformations chainSourceModelTargetMetamodel 16. 16 DiscoveryMDE ForgeIt assumes transformations written in differentlanguages are stored in a modeling repository.MDE Forge is a a generic and open repository of artifactswith community workspaces. It is generic because it permits the management of anykind of (modeling and non-modeling) artifacts. It is open because it has an open architecture whichAPierantonio - ACM/IEEE 17th MoDELS, Valenciapermits user-defined extensions.1Discovery of requiredmodel transformations2Derivation of the modeltransformations chainExecution of the derivedmodel transformations chainSourceModelTargetMetamodel 17. 17 DiscoveryIt assumes transformations written in differentlanguages are stored in a modeling repository.APierantonio - ACM/IEEE 17th MoDELS, Valencia1Discovery of requiredmodel transformations2Derivation of the modeltransformations chainExecution of the derivedmodel transformations chainSourceModelTargetMetamodel 18. 18 DerivationThe repository is given as a directed graph where nodesand edges represent metamodels and transformations,respectively.The derivation is performed by analyzing the graph.APierantonio - ACM/IEEE 17th MoDELS, Valencia1Discovery of requiredmodel transformations2Derivation of the modeltransformations chainExecution of the derivedmodel transformations chainSourceModelTargetMetamodel 19. 19 Model Transformations Chaining ProcessThe transformations present within the chain oftransformations are executed.APierantonio - ACM/IEEE 17th MoDELS, Valencia1Discovery of requiredmodel transformations2Derivation of the modeltransformations chainExecution of the derivedmodel transformations chainSourceModelTargetMetamodel 20. 20Enhancing ComposabilityThe distance between the incompatible metamodelscan be viewed as a metamodel evolution.Composability can be enhanced with co-evolutiontechniques.MM1 MMfMM23APierantonio - ACM/IEEE 17th MoDELS, ValenciarepositoryMM2MM7 MM8MM14MM9MM20MM19MM27MM18MM10MMfMM1MM6 MM11MM4MM5MM12MM13MM3MM17MM26MM1MM25MM24MM31MM1MM22MM1MM21MM30 21. Petri Netstarget metamodelof T1source metamodelof T2 22. Petri Netstarget metamodelof T1source metamodelof T2 23. Petri Netstarget metamodelof T11: pull up of the attributename to the new abstractmetaclass NamedElementsource metamodelof T2 24. Petri Netstarget metamodelof T11: pull up of the attributename to the new abstractmetaclass NamedElement2: renaming of themetaclass Net as PetriNetsource metamodelof T2 25. 25 Coupled evolution changesMetamodel changes can be classified according totheir impact over the related artifactsType of change EffectsNon breaking Changes which do not break theconformance of models to the correspondingmetamodel.Breaking resolvable Changes which break the conformance ofmodels even though conformance can beautomatically restored.Breaking non-resolvableChanges which break the conformance ofmodels which cannot automatically co-evolvedand user intervention is required.APierantonio - ACM/IEEE 17th MoDELS, Valencia 26. 26 Coupled evolution changesMetamodel changes can be classified according totheir impact over the related artifactsType of change EffectsNon breaking Changes which do not break theconformance of models to the correspondingmetamodel.Breaking resolvable Changes which break the conformance ofmodels even though conformance can beautomatically restored.Breaking non-resolvableChanges which break the conformance ofmodels which cannot automatically co-evolvedand user intervention is required.APierantonio - ACM/IEEE 17th MoDELS, ValenciaNon-breaking changescorresponds tocompatible metamodels 27. 27 Coupled evolution changesMetamodel changes can be classified according totheir impact over the related artifactsType of change EffectsNon breaking Changes which do not break theconformance of models to the correspondingmetamodel.Breaking resolvable Changes which break the conformance ofmodels even though conformance can beautomatically restored.Breaking non-resolvableChanges which break the conformance ofmodels which cannot automatically co-evolvedand user intervention is required.APierantonio - ACM/IEEE 17th MoDELS, ValenciaWe want to extendcomposability to breakingresolvable changes. 28. repositoryPetriNet 1.0 and PetriNet 2.0 are incompatible.However, they are made different by breakingand resolvable changes.Thus, an adapter which migrates the PN1 modelsinto PN2 can be automatically obtained. 29. 29 Generation of the Adapter transformationThe adapter is synthesized from the differencesbetween the target and source metamodels of thetransformations to be chained.APierantonio - ACM/IEEE 17th MoDELS, Valencia 30. 30 Generation of the Adapter transformationThe adapter is synthesized from the differencesbetween the target and source metamodels of thetransformations to be chained.2: renaming of themetaclass Net asPetriNetAPierantonio - ACM/IEEE 17th MoDELS, Valencia 31. 31Generation of the Adapter transformationFinally, we are able to have a completetransformation pathway from MMi to MMfMM1 MMfMM23APierantonio - ACM/IEEE 17th MoDELS, ValenciarepositoryMM2MM7 MM8MM14MM9MM20MM19MM27MM18MM10MMfMM1MM6 MM11MM4MM5MM12MM13MM3MM17MM26MM1MM25MM24MM31MM1MM22MM1MM21MM30 32. 32ProblemDoes it make sense to generate the adapter for anybreaking and resolvable change?MM1 MMfMM23APierantonio - ACM/IEEE 17th MoDELS, ValenciarepositoryMM2MM7 MM8MM14MM9MM20MM19MM27MM18MM10MMfMM1MM6 MM11MM4MM5MM12MM13MM3MM17MM26MM1MM25MM24MM31MM1MM22MM1MM21MM30 33. 33ProblemDoes it make sense to generate the adapter for anybreaking and resolvable change? Does it makesense to compose any compatible transformation?MM1 MMfMM23APierantonio - ACM/IEEE 17th MoDELS, ValenciarepositoryMM2MM7 MM8MM14MM9MM20MM19MM27MM18MM10MMfMM1MM6 MM11MM4MM5MM12MM13MM3MM17MM26MM1MM25MM24MM31MM1MM22MM1MM21MM30 34. 34 ProblemIt may make sense to restrict composition tometamodels which are in a way similar.distance distanceAPierantonio - ACM/IEEE 17th MoDELS, ValenciaT1T2metamodel coveragesMM2 and MM3 are dissimilarT1T2metamodel coveragesMM2 and MM3 are similar 35. 35 Similarity functionA similarity function between metamodels is definedand measures how similar two metamodels are.It is based on the Similarity Flooding algorithm usedfor schema matching and ontology alignment[Melnik et al, Falleri etAPierantonio - ACM/IEEE 17th MoDELS, Valenciaal]It is evaluated each time a new transformation iscommitted (deleted, or updated) into the repositoryand stored for later use. 36. 36 Similarity functionThe similarity values are maintained in a table like this:Grafcet PetriNet1.0 PetriNet2.0 XML PNMLGrafcet 1 0,20 0,30 0,29 0,26PetriNet1.0 - 1 0,20 0,28PetriNet2.0 0,30 1 0,30 0,30XML 0,29 0,20 0,30 1 -PNML 0,26 - - 0,28 1If the similarity between two considered metamodels ishigher then a fixed threshold (i.e. 0,80) such metamodelsare further analyzed.Then, if the resulting delta model consists of non-breakingand breaking and resolvable changes, thencorresponding adapters are generated.APierantonio - ACM/IEEE 17th MoDELS, Valencia0,890,89 37. A component in MDE Forge has been designed.Implementation 38. 38 1/Upload of the source modelIn the first step the user has to upload his modelA. Pierantonio - ACM/IEEE 17th Intl. Conf.Model Driven Engineering Languages and Systems 39. 39 2/Selection of target metamodelOnce the model has been uploaded, the system is able to detect themetamodel the model conforms to. Afterwards, the user has to select thetarget metamodel as shown in this screenshot:The metamodel list isautomatically retrievedfrom the repository.The system will onlysearch in the repositorythe metamodels targetof all these transforma-tions.A. Pierantonio - ACM/IEEE 17th Intl. Conf.Model Driven Engineering Languages and Systems 40. 40 3/Transformation chain selectionAll the possible chains that satisfy the user request are shown.Each chain ischaracterized by differentattributes, as chain length, metamodel coverage, usage frequency, average executiontime, ect.A. Pierantonio - ACM/IEEE 17th Intl. Conf.Model Driven Engineering Languages and Systems 41. 41 4/ReportOnce the 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 and Conclusions 43. 43 ConclusionsThe work aims at developing new transformations bycomposing existing ones according to userrequirements.The proposed approach makes use of well-known co-evolutiontechniques to enhance the composability oftransformations.Similarity metrics between metamodels are used inorder to avoid information erosion.A repository of artifacts, called MDE Forge has beenbuild in order to overcome the problem of theheterogeneity of the sources.APierantonio - ACM/IEEE 17th MoDELS, Valencia 44. 44 Future workA major drawback is that the composition mechanismis purely syntactical, semantic properties must betaken into account Well-formedness constraints must be considered Some semantic description of the modeling language hasalso to be considered, eg. descriptive logicsBreaking non resolvable changes must be taken intoaccount by adopting partiality and uncertainty.Validation and experimentation necessary to correlateinformation erosion and similarity thresholds.APierantonio - ACM/IEEE 17th MoDELS, Valencia 45. Thank you.