Co-Evolution of Metamodels and Model Transformations: An operator-based, stepwise approach for the impact resolution of metamodel evolution on model transformations

Abstract

Withthecontinualincreaseinsizeandcomplexityofmodernsoftwaresystems,the evolution of software remains one of the big challenges of softwareengineering. Model Driven Engineering (MDE) is one approach to meet thischallenge – by breaking down the description of software systems underdevelopmentintomanageableabstractions,eachembodiedbyasuitablekindofartefact. Kinds of artefacts are models and metamodels, along with modeltransformations, (modelling) languages,generators andothers.Yet thebenefitsexpectedfromMDEcanonlybefullyrealisedwhenthecomplexityoftheMDEartefactsandtheirrelationshipsremainmanageablethemselves.

The challenge addressed in this context by this thesis is the co-evolution ofmetamodels and model transformations; expressed as transformationdescriptions in common, dedicated transformation languages. Transformationsareused toproduceoutputmodelsconforming toametamodelbasedon inputmodels conforming to another (or the same)metamodel and are expressed interms of the metamodels used. This enforces a tight coupling betweenmetamodelsandtransformationdescriptions.Inconsequence,anychangemadetooneormoremetamodelpotentiallyinvalidatesexistingtransformationssothatevery change requires the validation and adaptation of all dependenttransformations. This can lead to an exceeding amount of effort necessary tokeep metamodels and transformations consistent as the number oftransformationsandmetamodelsincrease.

This work presents an operator-based, stepwise approach to support softwarearchitectsintheco-evolutionofmetamodelsandtransformations.Tothisendwepropose a set of operators which, when applied to metamodels, perform anevolutionsteponthemetamodel.Theimpactsofsuchachangeintheformofanoperator applied to a metamodel can be predicted for transformations thatdepend on the metamodel. The approach further allows the resolution of theimpactstorestoreconsistency,eitherautomaticallyorwithminimalhumaninput– depending on the type of change and the kind and complexity of thetransformation. In the worst case, the use of operators at least indicates

potentiallyinvalidtransformationpartsthatneedfurthervalidationtofulfiltheiroriginalintendedpurpose.Overalltheapproachreducestheeffortneededforco-evolution.

TheapproachisimplementedandintegratedintoMDEtoolingcommonlyusedfor modelling and transformation creation to demonstrate its feasibility. Theoperators are formalised on the basis of the EssentialMOF (EMOF) and theimpactresolutionisprovidedfortheATLASTransformationLanguage(ATL).

Contents

Abstract

1.Introduction

1.1.Motivation

1.2.ApplicationScenario

1.3.Contribution

1.4.Outline

IFoundations

2.ModelDrivenEngineering

2.1.Model

2.2.Metamodel

2.3.TheMetaObjectFacility(MOF)

2.4.TheEclipseModelingFramework(EMF)/Ecore

2.5.ModelTransformations

3.ModelTransformationLanguages

3.1.ModelTransformationLanguageFeatures

3.2.TheATLASTransformationLanguage(ATL)

3.3.MOFQuery/View/Transformation(QVT)

3.4.TheObjectConstraintLanguage(OCL)

4.SoftwareEvolutionandMDE

4.1.MDEandtheEvolutionofMDS

4.2.ModelRefactoring

II Operator-based Co-Evolution of Metamodels and ModelTransformations

5. Supporting the Evolution of Model Driven Systems: A StepwiseApproach

5.1.ProblemDescription

5.2.Goal:ProvidingSupportforCo-Evolution

5.3.Requirements

5.4.Approach

5.5.Phase1:MetamodelAdaptation

5.6.Phase2:OperatorImpactDetection

5.7.Phase3:ImpactResolution

5.8.TheOverallCo-EvolutionProcess

6.OperatorsforEMOFMetamodelEvolution

6.1. On the Usage of the QVT-R Graphical Notation for OperatorDefinition

6.2.OperatorOverview

6.3.Add/RemoveElement

6.4.MoveProperty

6.5.PushSimpleProperty

6.6.PushComplexProperty

6.7.PullSimpleProperty

6.8.PullComplexProperty

6.9.Restrict(Unidirectional)Property

6.10.Generalise(Unidirectional)Property

6.11.ExtractClass

6.12.InlineClass

6.13.ExtractSuperclass

6.14.FlattenHierarchy

6.15.AssociationtoClass

6.16.GeneralizationtoComposition

6.17.IntroduceCompositePattern

7.ImpactResolutionforATL

7.1.OperatorImpactOverview

7.2.SupportFunctionsandOmissions

7.3.AddElement

7.4.RemoveElement

7.5.RenameNamedElement

7.6.MoveProperty







7.13.ExtractClass

7.14.InlineClass






8.RelatedWork

8.1.Co-EvolutionofMetamodelsandModels

8.2.Co-EvolutionofModelsandOCLConstraints

8.3.Co-EvolutionofofMetamodelsandTransformations

8.4.Comparison

IIIValidationandConclusion

9.Evaluation

9.1.Completeness

9.2.PetriNetEvolutionScenario

9.3.Summary

10.ProofofConceptPrototype

10.1.Overview

10.2.PreliminaryConsiderations

10.3.ATLConcreteandAbstractSyntaxImplementation

10.4.GraphicalModelEditor

10.5.OperatorImplementation

10.6.ImpactDetectionandResolution

11.Conclusion

11.1.Summary

11.2.Benefits

11.3.FutureWork

Appendix

A.ExecutionofExtractSuperclass

B.ATLImplementationinXtext

Glossary

Acronyms

ListofFigures

ListofListings

Index

Bibliography

CHAPTER1

Introduction

Complexityisanessentialpropertyofsoftwaresystemsthatincreasesinanon-linear fashion with the size of the software system [16]. Model DrivenEngineering(MDE)isasoftwareengineeringapproachthataimstoalleviatethiscomplexity in software development andmaintenance by utilisingmodels andmodelling activities to raise the level of abstraction and to automate theproductionofartefacts.Onespecialisedapproachwiththispurposeisthemodeltransformation,whichallowstheautomatedcreationandmodificationofoutputmodels based on input models. Model transformations can be expressed inspecialisedtransformationlanguagestobeexecutedbyatransformationengine.As models and model transformations are used in a productive capacity insoftware engineering, they underlie the same evolutionary pressure thatconventionally build software systems do. Here the tight coupling betweenmodel transformations andmetamodels becomes problematic, as changing theoneoftenresultsintheneedtocheckandadapttheotheraccordingly.

This thesis presents an approach to lessen this co-evolution problem byprovidingasystematicmethodtosoftwarearchitectsofdescribingchangesdoneto a metamodel and determining and resolving the impact on related modeltransformations.

Theremainderofthischaptermotivatesthisapproach.Section1.1describestheco-evolutionproblemformetamodelsandmodeltransformationsinmoredetailandSection1.2providesasimpleillustrationasanapplicationscenario.Section1.3 lists the proposed scientific contributions of this work. An outline of thisthesisisprovidedinSection1.4.

1.1.Motivation

During the MoDELS’08 conference a workshop was held to identify‘ChallengesinModel-DrivenSoftwareEngineering’andtoproposethewaysinwhichtobestaddressthesechallengesinthenext10ormoreyears.Twoofthechallengesbroughtforwardby theparticipantswere the lackofproperprocesssupport for model driven engineering activities and specifically the lack ofsupportformodelevolutionandinconsistencymanagement in large,multi-useranddistributeddevelopmentsettings.[105]

The participants argued that models can become inconsistent wheredependencies between them exist, especially if themodels are developed in adistributedfashion.Asafirststeptoasolution,theneedtoidentifythechangetypes possible and the possible ways to resolve their impact on dependencieswere identified. Furthermore, rapid prototyping for domain-specificmodellinglanguages would be needed, as rapid prototyping provides the advantage of‘continuous, incremental feedback’ for development in MDE. Yet rapidprototyping can only be achieved if handling the dependencies betweenmodellingartefactscanbedoneasrapidlyasevolvingtheprototype.Thefocusherewasmainly on the relationship betweenmodels andmetamodels, but theargumentisalsovalidformodeltransformationsthatdependonthemetamodelstheyarebuildon.[105]

In 2011, Hans Vangheluwe identified the evolution of development artefactsusedinMDE,specificallymodelsandmodellinglanguagesasamajorchallengefor thecommunity,as theevolutionofmodelshas repercussionsonall relatedartefacts, amongst themmodel transformations. He suggest forMDE and therelatedDomainSpecificModelling(DSM):

‘IfMDE andDSM are to be usable at an industrial scale,modelinglanguage evolution has to be dealt with, ideally by (semi-)automaticallyco-evolvingartifacts.’[106]

Figure1.1.:Theimpactonmetamodelevolutionondependentartefacts

Co-evolution is the model engineering task of changing dependent artefactstogethertomaintainconsistency[22].Whatconstitutesconsistencydependsonthe artefacts involved, for metamodels and models it is given in part by theconformance of the models to their metamodels. For metamodels andtransformations, it is for one the suitability of themetamodel to represent theinputandoutputmodelsofthemodeltransformation.Buttheexpectedfunctionofthetransformationalsoneedstobetakenintoaccount;anevolutionarychangecanintroduce inconsistencies thatcausea transformation toproduce thewrongoutput,althoughitisstillexecutable.

Figure1.1illustratestheproblemofmetamodelevolutionandtheimpactithason the artefacts involved in a transformation. It contains a transformation T,which is specified by a transformation model which can be expressed in atransformation language like ATL. The transformation model refers to twometamodelsAandB,whereAservesasthesourceorleft-hand-side(LHS)andBasthetarget,orright-hand-side(RHS)inthiscase.Ifthetransformationmodeldescribesanexecutabletransformationanditisexecutedonsomeinputmodela,theexecutionresultsinaconcretetransformationinstanceandproducesamodelb as output. If the transformation is correct, the model b conforms to itsmetamodelB.Thetransformationinstancecanbeproducedasanactualmodel

intheformofatracemodel1bytheexecutionoritcansimplybetheconcretepairofmodelsaandbthatarelinkedbythetransformation.

EvolutionoccursintheformofsomechangedonetometamodelA,representedby the curved arrow at . An important part of handling the evolution ofdependentartefacts isdeterminingor recordingwhatkindofchangehas takenplace in a metamodel. A variety of different approaches dedicated to thisproblem exist for different purposes and technologies. These are discussed inchapter8.Chapter6introducesanoperator-basedapproachtodescribepossiblechangesmadetoametamodelthatissuitedtoresolvingco-evolutionissueswithdependenttransformationswritteninATL.

Afterthemetamodelischanged,therelationshipstotheotherartefactsinvolvedinthetransformationmaynolongerholdandneedtobeevaluatedandupdatedaccordingly for the transformation to be consistent. This is represented in thefigurebytheflashsymbol.ThefirstrelationisthatofallthemodelsaandtheirmetamodelAat .Thisrelationshipisoneofconformance,indicatingwhetherornotthemodelfulfilsallconstraintsdictatedbyitsmetamodel,orinlinguisticterms,whetherthemodelisavalidstatementinthelanguagethatthemetamodelrepresents. This co-evolution problem has been investigated by numerousresearchersandanumberofdifferentapproachestoaddressitexist(seeSection8.1forfurtherdetails).Thisproblemisnotcoveredfurtherinthisworkandweassumethatitcanbehandledadequately.

The next relationship that may have been impacted is that between themetamodelA andany transformationmodel thatmakesuseof themetamodel.Thisrelationshipisnamed‘refersto’andtheimpactisillustratedat Whetherornottherelationshipisimpactedatallbyanevolutionstepandwhetheritcanbe resolved automatically depends on a number of factors. For example, thetransformation may not even refer to the element that was changed in themetamodelandcontinue to functionasbeforewithoutneedinganyadaptation.Furthermore,ifanimpactoccurs,whatneedstobedonetocheckandresolveitdependsgreatlyonhowitisexpressedinthegiventransformationlanguageormodellingtechnology.WeinvestigatethisproblemforATLasacentralpartofthisworkandsuggestanapproachfortheimpactresolutioninchapter7.

Without looking at the impact of the metamodel change and updating thetransformationmodelaccordingly,theupdatedmodelsamaynolongerfulfiltheroleofsourcemodelsintheirtransformationinstance .Inpracticaltermsthis

means that an executable transformation can no longer read the inputmodelswithout error or even worse, it executes without raising an error but deliversfalseresults.Boththeseproblemscanbereducedtotheproblemofco-evolutionof the metamodel and the transformation model, as when the transformationmodelisupdatedtoreflectthechangeinthemetamodel,re-executingthemodeltransformationleadstoanewandcorrectsetofmodelsbandaccordinglytoasetofnewtransformationinstances.

Figure 1.1 illustrates a metamodel evolution on the left-hand-side of atransformation. The problem can also occur on the right-hand-side and affecttargetmodels.ShouldmetamodelBbechanged,thetargetmodelsbmaybecomeinvalid, i.e. the transformation no longer produces the correct result. Here therelationshipbetween the targetmetamodeland the transformationmodelneedstobeupdatedtoreflecttheevolution.Sourceandtargetelementsarereferredtodifferentlyinmanytransformationlanguagessothatthesideofthechangeplaysanimportantrolewhenresolvingitsimpact.Forthisreasonmanyoftheimpactresolutionsintroducedinchapter7makethisdistinction.

Thenextsectionintroducesanapplicationscenariocontainingtwometamodelsand a transformation between them in ATL. It further illustrates what impactchanges done to one of the metamodels have on the transformation and howresolvinginconsistenciescanbeaddressed.

1.2.ApplicationScenario

This section contains a small example consisting of a model transformationbetweentwometamodelsandascenarioofmetamodelevolutionthataffectsthetransformation.It illustrateshowthechangesmadetoametamodelcanimpactthe validity of a transformation and how this impact can be resolved. Theexampleisalsousedintheremainderofthisworktoillustratedifferentaspectsofoperatorsorresolutions.

Figure1.2.:TheextendedEMF-LibraryMetamodelexample

Bothmetamodelsare slightlymodifiedversionsof thoseweused in [19].Thefirst metamodel as seen in Figure 1.2 is an extended version of the commonEMF-Librarymetamodelexample[101].TheEMF-Library isasimpledomainmodelofapubliclibrary,withentitieslike‘Book’,‘Writer’,‘Borrower’etc. Inthisfictionalscenario,weassumetheEMF-Libraryexamplemetamodelservesasthebasisforthedevelopmentactivitiesforsoftwareapplicationstomanageapubliclibrary.

Figure1.3.:TheIMDBMetamodelexample

Thesecondmetamodelrepresentsasmallandartificialmodelofthedomainofthe Internet Movie Database (IMDB) which is an internet database ofinformation related to films and television programs2 currently owned byAmazon.Themetamodelcontainsentities like‘Film’withattributes like‘title’and‘year’ofreleaseandthe‘Actor’sthatstarinthefilm.Thetwodomainsofthetwometamodelsarerelated,asalibrarymayalsocontainsfilmsthatcanbeborrowedonvideocassette.

The transformation example in listing 1.1 converts instances of the IMDBmetamodel to those of the extended EMF-Librarymetamodel. It is written inATL and consists of two rules.An entity of typeVideoCassette is created foreachIMDBentityFilm.Furthermore,theinformationonanyactorthatstarsasaFigureinthefilmiscreatedasaCastelementandassociatedwiththeFilm.Thistransformationcouldimplementormodelthetaskofaddingnewfilmsintothestockofthelibrary.

Listing1.1:AsimpletransformationbetweentheIMDBMetamodelandtheextendedEMF-LibraryMetamodel

As an example of metamodel evolution, we propose the removal of ashortcomingoftheextendedEMF-Librarymetamodel:initscurrentstate,eachVideoCassettecontainsthegeneralinformationofthefilmonthecassetteandalistofCastMembers that star in the film.This is fine as longas there are fewduplicatecassettesofthesamefilminalibrary.Otherwise,thesameinformationis duplicated for each copy, causing redundant information to be stored andmanaged.Furthermore,ifwewantedtousethemodeltocreatealistofall thefilmsanactorstarredin,thisisnoteasilydone,astheCastMemberisduplicatedforeachnewcassette.

Shouldthelibrarydecidetostartbuyingnumerouscopiesofespeciallypopularfilms, the model can be improved to reflect this change in the domain. Oneapproachwouldbetointroduceanentity‘Film’torepresentthefilmitselfandtoassociate the actorswith the film.The entityVideoCassettewould continue toholdtheinformationontheactualcopiesavailable,likewhoborrowedacassetteandwhetheritisdamagedornotandwouldbelinkedtothefilmthatisonthecassette.

Threestepsarenecessarytoaccommodatethischange:

Figure1.4.:ThemodifiedextendedEMF-LibraryMetamodelexample

1. SomeofthepropertiesneededforthenewentityFilmcurrentlybelongtoparent entities of VideoCassette and are available to VideoCassette byinheritance. These are moved down intoVideoCassette in preparation sothat they can later be moved to Film. The relevant properties arepublicationDate in Item and title andminutesLength in AudioVisualItem.This means that they also need to bemoved down into other subclasseswhich are siblings of VideoCassette so that they remain available there.These are Periodical, Book and BookOnTape for the propertypublicationDate and BookOnTape for both the properties title andminutesLength.

2. InthenextstepwecancreateanewentityFilmandlinkthetwoentitiesbyanassociation.

3. Now we can move the relevant properties and the association to

CastMemberfromVideoCassettetoFilm.

Theresultingmetamodel isshowninFigure1.4.Pleasenote thatotherentitieswere also updated as a result so that Book now also owns an attributepublicationDatedirectly.

Listing1.2:TheupdatedtransformationbetweentheIMDBMetamodelandtheevolvedextendedEMF-LibraryMetamodel

To cater for the evolution of the metamodel, we also need to update thetransformationinlisting1.1:

1. The first changeofmoving theproperties along the inheritancehierarchydowntotheVideoCassetteentitydoesnotaffectthetransformationatall,asthe attributes were previously available by inheritance and are nowavailabledirectly.

2. The second evolution step requires an update of the first transformationrule, as for every newVideoCassette that is createdwe now also need tocreateanewFilmentity(orlinktoanexistingone).

3. Inthethirdstep,propertiesaremovedfromtheVideoCassette totheFilm

entity. Here the first rule needs to be updated again so that the correctvaluesaresetonFilminsteadofVideoCassette.

Theupdated transformation isgiven in listing1.2.When the transformation isupdated, it is valid again and performs the same task as before. Furtherimprovementsforthemetamodelarepossible,likeperformingthesamekindofdifferentiationbetweenthenovelandtheactualphysicalcopies(books)instock.These would require further updates to the accompaning transformations,dependingonthenatureandimpactofthechange.

1.3.Contribution

The central contribution of this work is made in addressing the co-evolutionproblemformetamodelsandmodeltransformations.Itconsistsofthefollowingparts:

An approach for the co-evolution ofmetamodels andmodel transformations.Theapproach is aimed to support software architects in evolvingdependentartefactsoftheModelDrivenSystem(MDS)instepwisefashionbyapplyingpredefinedoperatorsofcommonevolutionstepsonmetamodelsanddetectingandresolvingthepossiblyoccurringimpactsonmodeltransformations.

A Set of Co-evolution Operators for the co-evolution of metamodels andmodel transformations. The operators are based on the Unified ModelingLanguage(UML)EMOFmetamodelandareformalisedasrelationsusingtheObject Management Group (OMG) standard QVT Relations (QVT-R)graphicalnotation.

ASet of ImpactResolutions that address the impact onATL transformationsthatdependonevolvedmetamodels.TheimpactresolutionsareformalizedasQVT-Rrelations for the setofoperators.The impact resolutionscapture thetypeof impactpossible for thedifferentoperatorsandprovidesemi-or fullyautomatedresolutionoftheimpacttorestoreconsistencybetweenmetamodelandmodeltransformation.

APrototypicalImplementationof theapproach, theoperatorsand the impactdetectionandresolution.TheimplementationisintegratedintocommonMDEtoolingforthecreationandeditingofmetamodelsandmodeltransformations.Theimplementationprovidessupporttothesoftwarearchitectwhenapplyinganoperatortoametamodel,indeterminingtheresultingimpactondependentmodeltransformationsandbyprovidingandperformingavailableresolutions.

Thisworkprovidessupportforco-evolutioninMDE.Itaddressestheproblemof complexity and the tight-coupling of dependent artefacts in the context ofsoftware evolution and reduces the effort needed to prevent the occurrence ofinconsistencies due to software evolution tasks for metamodels and modeltransformations.

1.4.Outline

This thesisconsistsof threemainparts. Inpart I the foundationsfor thisworkarelaidout.Itisstructuredasfollows:

Chapter2 introducesthefoundationsconcerningMDE:Section2.1 introducestheconceptof the ‘model’ andSection2.2 that of the ‘metamodel’.Section2.3 covers the Meta-Object Facility (MOF), being the standardisedmetamodelling framework of the UML and Section 2.4 covers Ecore, animplementation ofMOF for the Eclipse IDE. In Section2.5 the concept ofmodeltransformationisdiscussed.

Chapter 3 provides the concepts and languages available for creating modeltransformationused in thiswork.Section3.1 introduces thegeneral featuresof model transformation languages. Section 3.2 covers the transformationlanguage ATL and Section 3.3 the Meta Object Facility (MOF) 2.0Query/View/Transformation (QVT). As the Object Constraint Language(OCL)playsan importantpart inboth languages, it is introduced inSection3.4.

Chapter 4 covers software evolution in the context of MDE. To this end,Section 4.1 relates the co-evolution problem to the MDS and Section 4.2introducestherelatedconceptsintheareaofmodelrefactoring.

PartIIcoversthecentralcontributionsofthisthesis.Itcontains:

Chapter5 covers the approach presented in this thesis. It provides a problemdescription in Section 5.1 and details the goal pursued by our approach inSection 5.2. The requirements for the approach are detailed in Section 5.3afterwhichanoverviewoftheapproachispresentedinSection5.4.Sections5.5 through 5.7 discuss the details of the three phases that make up theapproach,afterwhichasummaryisprovidedinSection5.8.

Chapter 6 provides the formalisation of the operators of our approach forEMOFasQVT-Rrelationsandprovidesadiscussionoftheuseandeffectofeachoperator.

Chapter7coverstheimpactsoftheoperatorsfromthepreviouschapteronATLmodel transformations. Each operator is discussed and the proposed impactresolutionsforATLareformalisedasQVT-Rrelations.

Chapter 8 discusses work related to our approach. Section 8.1 coversapproachesdealingwiththeco-evolutionofmetamodelsandmodels,Section8.2thosethathandleco-evolutionofmodelsandlinkedOCLconstraintsandSection8.3 approaches that compete in the co-evolutionofmetamodels andmodeltransformations.

Finally,partIIIdiscussestheevaluationoftheapproachwiththeimplementationandconcludesthisthesis.Itisstructuredasfollows:

Chapter9coverstheevaluationofourapproach.Section9.1discussesaspectsof completeness of the operators both on the metamodel and thetransformation level. In Section 9.2 the use of operators in a coevaluationscenario containing a stepwise metamodel evolution and the resolution ofimpactsonadependent transformation ispresented.Section9.3summarisesthechapter.

Chapter10 contains theprototypical implementationofourapproach.Section10.1 provides an overview of the prototype and Section 10.2 covers theconsiderationsmadeintheimplementation.InSection10.3thedetailsoftheimplementationforATLarecovered.Theimplementationoftheoperatorsandthe integration into a graphical metamodel editor are discussed in sections10.5 and 10.4 and the implementation of the impact resolutions in Section10.6.

Chapter11concludesthisthesis.Section11.1providesanoverallsummary.InSection 11.2, the benefits seen in this approach are recapitulated. Finally,Section11.3concludeswithanoutlookonfuturework.

1Tracemodelsspecifywhichinputmodelelementwastransformedintowhichoutputmodelelementandallow further aspectsofmodel transformations like traceability and incremental transformationswhicharenotrelevanttothiswork.

2http://www.imdb.com

http://www.imdb.com

PARTI

Foundations

CHAPTER2

ModelDrivenEngineering

ModelDrivenEngineering(MDE)isasoftwareengineeringapproachthataimsto alleviate the complexity of software development and maintenance. Itsupports software engineers with suitable methods and tooling to handle thecomplexityofmodernsoftwaresystems.Thecomplexityofasoftwaresystemisbrokendownintomanageableabstractions,eachembodiedbyasuitabletypeofartefact. The most prominent artefact type is the model, along withtransformations, (modelling) languages, code generators and many others.TogethertheartefactsconstituteaModelDrivenSystem(MDS),whichservesasarepresentationofthesoftwaresystemofinterest-fromasoftwareengineeringperspective. InMDE, models and model engineering are utilized to raise thelevelofabstractionofprimaryartefactsandgenerativetechnologiestoautomatetheproductionofsecondaryartefacts.

Theconceptof‘model’playsacentralroleinMDE.Inthisvein,Bézivincoinedtheprinciple‘Everythingisamodel’asthecommonprinciplebehindthemanydifferenttechniquesandtechnologiesusedinMDE[12].Itismeanttoplaythesamerolethattheprinciple‘Everythingisanobject’doesinobjecttechnologyandisanattempttounifythedifferenttechnologiesandunderstandingsofMDEandthusbetterdefinewhatisandwhatisnotapartofMDE.BézivinseesastepbeyondobjecttechnologyinMDEinwhichmodelstakeupthesignificanceofobjectsandmodeltransformationthatofobjectcomposition:

‘Very differently [to object technology], what seem to be importantnowisthataparticularview(oraspect)ofasystemcanbecapturedbya model and that each model is written in the language of itsmetamodel.[12]

AlthoughBézivindoesnotattributeasingleuniquegoaltoMDE,heseesMDEasaresultofthenecessityfor

‘a complete new rise in abstraction’ in dealing with ‘increasinglycomplexandrapidlyevolvingsystemswearebuildingtoday.’[12]

AtkinsonandKühnefollowthissentiment in thatMDEisafurtherstep in theneedtohandlegrowingandmorecomplexsystems,as

‘Model driven development (MDD) can be regarded as the naturalcontinuationof[thetrendto]...raisethelevelofabstractionatwhichtheactivity[toprogramcomputers]takesplace.’[4]

Modelsareusedbyprogrammerstospecifywhatfunctionality isrequiredofasystemandwhatarchitectureistobeused.Thisholdsthepotentialtoreducethecomplexityofproblemsandachieveahigherdegreeofautomationinsoftwaredevelopment. The underlying goal ofMDE is thus to improve productivity ormaintainproductivitywhensystemsgrowandbecomemorecomplex.AtkinsonandKühnenametwoareasofimprovement[4]:

improving short-term productivity, by increasing the amount offunctionality that can be derived from a software artefact. The mainmechanismtoachievethisgoalistheautomatedgenerationofsourcecodefromvisualmodels.

improving long-term productivity can be achieved by increasing the life-spanofthevalueofartefacts.

KühnefurtherhighlightstheroleofformalmodellingforMDE:

‘Itisoneoftheprimarygoalsofmodeldrivenengineeringtoshifttheemphasis from informal, non-binding models to rigorous, bindingmodels.’[56]

Toachieve thesegoals forMDE inpractice, avarietyof artefacts andartefacttypesareusedtocapturethedifferentaspectsofthedevelopmentprocessandavarietyoftoolstomangethedifferentartefacts,bothfortheinitialdevelopmentand during the maintenance of the system [51]. These artefacts are tightlycoupledby thedifferent dependencies that exist between themandneed to bemanaged along with the software system itself. Therefore, the artefacts usedduring development together with the dependencies between them form acomplexsystemthemselves[9].WeusethetermModelDrivenSystem(MDS)torefertothissysteminthiswork:

Definition1(ModelDrivenSystem):AModelDrivenSystem(MDS)isthecollectionofartefactsandtoolsusedforthedevelopmentofasoftwaresysteminMDEandthedependenciesbetweenthem.

Artefacts that are usually part of the model driven system are models andmetamodels, but also transformations, transformation languages andcodegenerators.Inthenextsectionswelookatmodelsandmetamodelsinmoredetail (2.1, 2.2) and discuss the technologies provided by the UML and theEclipse Modeling Framework (EMF) project to facilitate metamodellingactivities(2.3,2.4)anddiscussmodeltransformationsinSection2.5.Chapter3isdedicatedtothedifferenttransformationlanguagesrelevanttothiswork.

2.1.Model

Stachowiakprovidesageneraldefinitionfortheconceptmodelformodeltheory.He associates three features with the term ‘model’: a mapping feature(Abbildungsmerkmal), as a model is always a representation of something, areduction feature (Verkürzungsmerkmal), as themodelomits attributes that aredeemed irrelevant by the model’s creator or user and a pragmatic feature(PragmatischesMerkmal),asmodelandoriginalmayonlybematchableundercertainconditions.[91,pp.131-133]

Whilemanydifferentusesof the term ‘model’ exist indifferentcontexts [30],models in softwareengineeringarecommonlymadeofhard-or softwarebased,realorlogicalsystems;asrepresentationswiththepurposeofreasoningaboutortoperformanalysisonsomepropertiesofthesystems.

Kühneprovidesadefinitionof‘model’alongtheselines:

‘A model is an abstraction of a (real or languagebased) systemallowingpredictionsorinferencestobemade.’[56]

This narrows down Stachowiak’s definition to the notion of a model in thecontextofMDE:Theoriginalthatamodelrepresentsisconsideredtobearealor abstract system, the reduction feature is anabstraction and the purpose forreductionandthepragmaticfeatureistoreasonaboutthesystem(insteadofthesystem).

ThisdirectlycorrespondstoBézivinsandGerbésdefinitionof‘model’:

‘Amodelisasimplificationofasystembuiltwithanintendedgoalinmind. [...]Themodel shouldbeable toanswerquestions inplaceoftheactualsystem.’[13]

When using the term ‘model’ in this work we further refer to the modelscommonlyusedinsoftwareengineering,whichareabstractandlanguagebased(as opposed to for example mathematical or scale models) and are abstractsystemsthemselves.Assuch,theconceptofamodelrelatestothatofasystem.TheISO/IEC/IEEE12207:2008standarddefinesthetermsystemasfollows:

Definition2(system):Asystemisthe‘combinationofinteractingelementsorganizedtoachieveoneormorestatedpurposes.’[47]

It further limits its scope toman-made systems, that ‘may be configuredwithoneormoreofthefollowing:hardware,software,data,humans,processes(e.g.,processesforprovidingservicetousers),procedures(e.g.,operatorinstructions),facilities,materialsandnaturallyoccurringentities.’[47]

Althoughmanyothertypesofsystemsexistandbroaderdefinitionsofthetermalso cover e.g. biological systems, we deem this definition sufficient for theremainder of this work and take no further position as to what constitutes asystem.Weassumethatmodelsrepresentsystemsingeneralandthatthenatureofthesystemislefttotheuserorcreatorofthemodel(unlessotherwisenoted).

Wecanthereforesummarizethedefinitionofmodelasfollows:

Definition3(model):Anabstractsystemisamodelofanothersystem,ifitis a simplification of the other system, created for a given purpose. Therelationship between the model and the system it represents is namedrepresentationOf.

According to Kühne [56], two classes of models are relevant to softwareengineering,tokenmodelsandtypemodels.Tokenmodels ‘capturesingular (asopposed to universal) aspects of the original’s elements, i.e., they modelindividual properties of the elements in the system.’ Type models instead‘capturetheuniversalaspectsofasystem’selementsbymeansofclassification.’

Whetherornot the relationbetweensystemandmodelholds; i.e. the questionwhetheramodelcorrectlyrepresentsasystemdependsonthepurposeforwhichthe relation is observed. This provides a context under which this relation

betweentwosystemsisthatofonebeingarepresentationoftheother; i.e.onesystemhas the role of a model in the given context (Stachowiak’s pragmaticfeature).Thisallowsfor the treatmentofmodelsassystemsandtheotherwayarounddependingonthecontext.Nevertheless,wepresumeitissafetousethetermmodelasshorthandfor‘asystemintheroleofamodelincontextX’ifthecontextisdeducible.

2.2.Metamodel

Formalandrigorousmodellingrequiresmethodstospecifyandtoreasonaboutthe validity ofmodels. This is achieved in part bymetamodelling concepts inMDE,wheremodelling techniques are applied tomodels as systems. Bézivindefinesthetermmetamodelasfollows:

‘A metamodel is a formal specification of an abstraction, usuallyconsensual and normative. From a given system we can extract aparticularmodelwiththehelpofaspecificmetamodel.Ametamodelactsasapreciselydefinedfilterexpressedinagivenformalism.’[12]

This definition contains two central aspects of metamodelling: a constructiveaspect,asthemetamodelguidesthecreationprocessofamodelfromasystemandarepresentativeaspect,inthatthemetamodelactsasafilteronmodels.

Generally speaking, a metamodel is the model of a modelling language as itdefines the abstract syntax of themodelling language.Kühne states: linguisticmetamodelling is ‘the explicit specification of a language’s wellformednessconstraints’ [57]. The advantages of such an explicit specification are: 1) thespecification is not hidden in the code of a tool; 2) the specification can bealteredbyusersofthetool;and3)onecanreasonaboutthespecificationandthemodelsitdescribes.[57]

Themetamodelmakesitpossibletodeterminewhichmodelsarevalidaccordingto the represented modelling language. Languagebased models are abstractsystems and it is possible to combinemodels into sets and treat these sets asabstract systems. Therefore the metamodel determines which models aremembersofthesetofvalidmodels.Seidewitzdefinesmetamodelsinreferencetosystems(systemunderstudy(SUS))asfollows:

‘AmetamodelisaspecificationmodelforaclassofSUSwhereeachSUSintheclassisitselfavalidmodelexpressedinacertainmodelinglanguage.That is, ametamodelmakes statements aboutwhat canbeexpressedinthevalidmodelsofacertainmodelinglanguage.’[87]

Weadaptthisdefinitionslightlytoincorporatethenotionoftheabstractsystem:

Definition 4 (metamodel): A metamodel is a representation of a set ofmodels,whichcanbecalledamodelling language. Ifamodel isamemberofthisset,itconformstoitsmetamodelandthisrelationshipisnamedconformsTo.

The next section introduces the metamodelling framework of the UML andSection2.4itsimplementationfortheJavaprogramminglanguage.

2.3.TheMetaObjectFacility(MOF)

The Meta-Object Facility (MOF) is a modelling language for metamodels,specifically for themetamodels of the family of languagesmaintained by theOMG,ofwhichtheUMLisaprominentmember.TheMOFisalsoapartoftheUML,as it reusespartsof theUML’sclassmodellingsyntaxandsemantics. Itcontainstwolanguageversions,thefirstbeingaminimalsetofelementsnamedEMOF.TheEMOFisdesignedforsimplicityandreuse:

‘AprimarygoalofEMOFistoallowsimplemetamodelstobedefinedusingsimpleconceptswhilesupportingextensions.’[75,p.31]

ThefullMOF,whichextendsEMOFbymoresophisticatedlanguagecapabilitiesiscalledCompleteMOF(CMOF).[75]

AccordingtoBézivinandGerbé,theMOF‘emergedprogressively’intheworkof different communities like the CASE data interchange format (CDIF)committee and theAmericanNational Standards Institute (ANSI) InformationResource Dictionary System (IRDS) standards. Different metamodels werecompetingwiththeUMLandevolvingseparately,whichbroughtabouttheriskofincompatibility.ThustheMOFwasbuildasa‘globalintegrationframeworkforallthemetamodelsinthesoftwaredevelopmentindustry.’[13]

Inthenextsection,weintroducetheUMLandtheaspectsthatarerelevanttotheMOF.WethencovertheEMOFanditsimplementationforJavainmoredetail,

astheseformthebasisfortheco-evolutionoperatorsdefinedinthiswork.

2.3.1.TheUnifiedModelingLanguage(UML)

TheUnifiedModelingLanguage (UML) is amodelling language for softwaresystems.Itisbasedonobjectorientedprinciplesandisbestknownforitsvisualdiagramtypes,ofwhichtheclassdiagramismostcommonlyknown.Thefirstversion of theUMLwas created byGradyBooch, JamesRumbaugh and IvarJacobson to unify their different object orientedmethods and submitted to theOMGforstandardisationin1997.InNovember1997therevisedUMLversion1.1wasadoptedbytheOMG.Themaintenanceversionsuptoversion1.5wereproducedbyarevisiontaskforceuntilthemajorrevisionUML2.0wasadoptedin2005.[15]

Figure2.1.:StructureoftheUMLSpecificationasofVersion2.4.1[86]

ThecurrentofficialreleaseoftheUMLisversion2.4.1fromAugust2011whileversion2.5isbeingpreparedandcurrentlyavailableforevaluation[78].Unlessotherwisestated,thisworkisbasedonandreferstothecurrentversion2.4.1oftheUMLstandard.

TheUMLSpecificationArchitecture

The organisational structure of theUML specification is relevant to thisworkand changed between versions 2.3 and 2.4.1 [86]. Figure 2.1 provides a shortoverviewofthecurrentconfiguration.

The UML in version 2.4.1 consists of two related specifications: the OMGUnifiedModeling Language Infrastructure (Infrastructure) [76] and theOMGUnifiedModelingLanguageSuperstructure (Superstructure) [77].Both consistof a natural language document and a set of models in the XML MetadataInterchange(XMI)format.

TheInfrastructurespecificationcontainsthelanguagefoundationfor theUML.It contains the core packagesBasic,Constructs, Profiles andAbstractions anddefines language features like namespaces, typing, classes, associations andprofilingetc.

The Superstructure specification defines the language elements of the UMLcommonly used for software system modelling like the UML diagram types,suchastheclassandactivitydiagram.ForthispurposetheSuperstructurereusesandextendstheelementsdefinedbytheInfrastructurespecification.

TheMOFspecificationalso reuses andadaptsboth theSuperstructure and theInfrastructurepackages(seeFigure2.1)sothatallthreespecificationsneedtobeconsultedforthedefinitivespecificationofthelanguageelementsbelongingtotheMOF. Furthermore, the UML provides different levels of compliance thatmodellingtoolscanadhereto.

HowelementscanbeadaptedandextendedforthepurposeofreuseintheUMLandMOFspecifications isdefinedbythepackagemergemechanism,which isdescribedinthenextsection.

PackageMergeMechanism

TheUMLisdividedintofourcompliancelevels(L0–L3),whereL0isdefinedinthe UML Infrastructure specification and the levels grow in the availablefeatures by building on the previous level. The key mechanism used for thisstructure is the package merge, which defines how elements from differentpackagescanbeintegratedtoformnewlanguagespecifications[77,pp.113].Amergeisconceptuallylikea‘generalization’,astheresultofthemergecombinesthe characteristics of the two merged packages. Merging can be applied to

elementsthathavethesamenameandthatrepresentthesameconcept.Mergingrepresentsboththeprocessoftransformationandtheelementresultingfromthetransformation,which isa stand-aloneelement in itsown right.Howelementsaremerged andwhat constraints apply to a successfulmerge is defined in theUML Superstructure specification, while the specifics depend on the type ofelement.[77]

‘Different metatypes have different semantics, but the generalprinciple isalwaysthesame:aresultingelementwillnotbeanylesscapable than itwasprior to themerge.Thismeans, for instance, thatthe resulting navigability, multiplicity, visibility, etc. of a receivingmodelelementwillnotbereducedasaresultofapackagemerge.’[77,p.116]

Therefore,asageneral ruleof thumb,mergingcannot reducecapabilities: fortheavailabilityofproperties,multiplicityorvisibilitythemergealwaysresultsinthemostgeneralcombinationofthemergedelements.

TheMOFSpecificationArchitecture

TheMOFspecificationdefinestwolanguagelevels,theEMOFandtheCMOF.TheEMOFmergestheClasses::KernelpackagefromtheUMLSuperstructurewith own language capabilities. Classes::Kernel merges the Core::BasicpackagefromtheUMLInfrastructureinturn[75,p.32].TheCMOFmergestheEMOFandextendsitwithmoresophisticatedextensionandreflectionfeatures[75,p.47].

The twoMOF levels are designed to be self contained, i.e. aftermerging thelanguageelementsfromthedifferentsources,theEMOFmetamodelisreflectiveinthatitcanbespecifiedbyitself.Thereby,themetamodeloftheEMOFistheEMOF itself. The CMOF further serves as the metamodel for the UMLInfrastructure, Superstructure and compliance levels, as implemented by theMOFXMImodelsofthe‘NormativeMachineConsumableFiles’aspartoftheUMLstandard.[77]

SemanticsoftheUML

UnfortunatelytheUMLdoesnotprovidepreciseformalsemanticsinitscurrentversion.TheabstractsyntaxandstaticsemanticsareprovidedbythenormativeMOFXMImodelsfilesandintheSuperstructureandInfrastructurespecificationdocuments alongwith the concrete (graphical) syntax.Thedynamic semanticsareprovidedin‘precisenaturallanguage’[76,p.22].

Figure2.2.:TheEMOFClassespackage

This lackof formalsemanticshasbeencriticisedearlyon in thehistoryof theUML [29] and has also been discussed for theUML2 revision of the UMLstandard(seeforexampletheworkbytheUML2SemanticsSymposium[17]).Thedifficultiesofprovidingoverallformalsemanticsstemfromthecomplexityof theUMLand the tailoring andvariabilitymechanisms it contains [83].Forsomeofthesophisticatedlanguagefeatures,individualformalisationapproacheshavebeenproposed,likesemanticsforthepackagemergemechanism[110]orfor the association concept [2]. Yet complete formal semantics for the UMLremainanopenresearchproblem.

2.3.2.TheEssentialMOF(EMOF)Model

This section covers the EMOF language architecture and the most importantEMOFelementsinsomedetail,astheco-evolutionoperatorsdefinedinchapter6arebasedonEMOF.

Figure2.3.:TheEMOFTypesandDataTypespackage

EMOF isdefined in clause12of theOMGMetaObjectFacility (MOF)CoreSpecification[75,p.31].Itdoesnotfullyrepeattheelementswhichareimportedfrom the UML Superstructure but rather provides the omissions andredefinitions.TheaccompanyingXMImodelsredefineelementsfromtheUMLSuperstructure using the packagemergemechanism described in the previoussection. EMOF merges the packages Identifiers, PrimitiveTypes,

Extensions and Reflection from MOF, of which the last merges theUML::Classes::Kernel from theUMLSuperstructure specification in turn. Inthis manner most EMOF language features are defined by the Superstructurespecification, while the EMOF specification only makes minor additions andexcludesunnecessaryclassesandattributesfromtheUML::Classes::Kernelviaconstraints.Figure2.2showstheEMOFclasselementwiththerelatedelementsand Figure 2.3 the type and data type elements after package merge of theSuperstructureandMOF(compare[75,pp.33-34]with[77,pp.22-34]).

ThemainconcreteEMOFlanguageelementsare:

Class:Classes are the central elementsof amodel.Classes are classifiers andprovideattributesandoperationsasfeatures.Classesinheritthegeneralizationmechanismfromclassifier,serveastypes,arenamedandpackageable.

Package:Packagesprovideastructuringmechanismforallelements.Theyareuniquely identifiable by a Uniform Resource Identifier (URI) and provideuniqueness to their content. As opposed to CMOF and UML, in EMOFpackageableelementsareredefinedtoalwaysbepubliclyvisible.

Property: Properties declare named relationships of classifiers to values ofsimple or complex type. Properties are owned by classifiers or associationsandcanbepartofanassociation,makingthemanassociationend.Propertiesdefinedonclassifiers(directlyownedorinherited)arealsocalledattributes.Ifapropertyispartofabidirectionalassociation,thepropertyontheotherendisgivenbythe/oppositefeature.

Association:Associationsdefinevalidlinksbetweentypedinstances.InEMOF,an association has a property at each end, which defines the type of theassociationend. The properties may be owned by the classifier at theassociationend or (one for each association) by the association itself. If theproperty is ownedby a classifier, the association is defined to be navigablefromthatclassifier.Ifbothpropertiesareownedbyaclassifier,theassociationis bidirectional. The exact semantics of navigability depend on theimplementationas:

‘Navigability means instances participating in links at runtime(instances of an association) can be accessed efficiently [. . .]. Theprecise mechanism by which such access is achieved isimplementationspecific.’[77,p.38]

Thederivedfeature/endType[1..*]providesthetype(s)ofthepropertiesservingasassociationends.OperationandParameter:Operations allow themodelling of behaviour anddefine what parameters need to be supplied to initiate the behaviour of aninstance and what return type is expected. The implementation is platformdependent.For example, theMOFmakesuseof theOCL to further specifythebehaviourofoperations.

Generalization:Generalizationsprovidetheinheritancemechanismcommontoobjectorientedlanguages.Generalizationsallowtheredefinitionofclassifiersandaparent–childrelationshipbetweenclassifiers.Classesprovidetheclass/ superClass association for convenient access to the classes related by ageneralization.

Enumeration, EnumerationLiteral: Enumerations are data types that haveenumerablevalues,theenumerationliterals.

Comment: Comments allow the annotation of elementswith human readabletext.

InstanceValue:Instancevaluesarevaluespecificationsthatidentifyaninstance,eitherintextualorgraphicalnotation.

LiteralSpecification: The types LiteralBoolean, LiteralInteger,

LiteralNull, LiteralReal, LiteralString andLiteralUnlimitedNatural encode constant values of the correspondingsimpletypes.

DataType and PrimitiveType: Data types represent instances that are onlyidentifiedby their value.Primitive typeshaveno further substructure in theMOF,examplesareBoolean,IntegerandString.

2.4.TheEclipseModelingFramework(EMF)/Ecore

The EclipseModeling Framework (EMF) is amodelling and code generationframeworkfortheJavaprogramminglanguageandtheEclipseplatform[94].Itcontains ametamodel calledEcore, which is closely related to EMOF. EcorestartedoffasaMOFimplementationandwasextendedandadaptedtoprovidea‘highlyefficientJava implementationofacoresubsetof theMOFAPI’ [101].WiththecreationoftheEMOFasasimilarsubsetofMOFinversion2.0,closealignment between Ecore and EMOFwas created.Although some differencesexist,EcorecanreadandwriteserializationsofEMOF.[101]

EMFprovidesmodeldrivenfeaturesontopofEcorefortheJavalanguage,suchas Javacodegeneration fromEcoremodels,XMI serialisation, the creationofmodels from Java code using annotations, notification and adaptationfunctionality of thegenerated Java classes and a reflective JavaAPI to accessEcoremodels.[94]

OneexampleofadifferencebetweenEcoreandEMOF inversion2.4.1 is therelationship of classes, properties and associations (compare [94, p. 107]with[77,p. 29]). InEMOF, attributeswith complex types arebuild as associationswith properties serving as associationends on both sides. Attributes of simpletypearepropertieswithoutassociations(justwithasimpletype).InEcore, thepropertyelement iscalled‘attribute’ (EAttribute)whichonly serves for simpletypes. Association elements connect attributes of complex type to their type-classinstead.WhiledirectionalityisexpressedinEMOFbytheownershipofthe

remote property (if it is owned by the association, it is uni-directional; if it isowned by the remote class it is bidirectional), in Ecore associations arebidirectionaliftwoassociationsbetweentheclassesexistthatareexplicitlysetaseachothersopposite.

2.5.ModelTransformations

Model transformations are the mechanism that allows the automaticmanipulation ofmodels and play a central role inMDE [11, 27, 33, 57, 68].They have been called ‘the heart and soul of Model-driven SoftwareDevelopment’ [88] and according to Bézivin, take up the same importance inMDEthatobjectcompositiondoesinobjecttechnology:

‘Thecentralideaofobjectcompositionisprogressivelybeingreplacedbythenotionofmodeltransformation.’[12]

Kühnedefinestheterm‘modeltransformation’asthe

‘information on amapping from onemodel to another, created by atransformation engineer, for the transformation engine, in order toautomateatranslationprocess.’[56]

Kleppeetal. inturndefine‘transformation’astheprocessitselfandratherusetheterm‘transformationdescription’torefertothemappinginformation:

‘Atransformationistheautomaticgenerationofatargetmodelfromasource model, according to a transformation definition. Atransformationdefinitionisasetof transformationrulesthat togetherdescribehowamodelinthesourcelanguagecanbetransformedintoamodelinthetargetlanguage.Atransformationruleisadescriptionofhowoneormoreconstructsinthesourcelanguagecanbetransformedintooneormoreconstructsinthetargetlanguage.’[52]

Thisdifferencehighlightsthedualusagecommonfortheterm‘transformation’[30]:inthefirstitreferstothemappinginformationbetweentwomodelsandinthe second to the process of applying this information in creating one modelfromanother.

MensandVanGorpproposetheextensionofthedefinitionbyKleppeetal.so

‘that a model transformation should also be applicable to multiplesourcemodelsand/ormultipletargetmodels.’[68]

Although a set ofmodels can also be considered to be amodel, this additionexplicitly allows for transformations to be defined between sets ofmodels. Insummary,wederivethefollowingworkingdefinition:

Definition 5 (model transformation): A model transformation is theinformation on a mapping between two sets of models, to be executed by atransformationengine.Itconsistsofasetofrulesthatdescribehowelementsofthe target language can be created from elements of the source languageautomatically.

Whether or not something constitutes a transformation depends on the term‘model’(seedefinition3).Forexample,it isvalidtoassumethatprogramsaremodels, as they represent an abstract system, conform to their programminglanguage and exist for a specific purpose [12].A common scenario along thisdefinitionisacodegenerator,whichcreatesexecutablecodefromsomemodelon a higher level of abstraction. Kurtev et al. suggest the concept of thetechnologicalspace todifferentiate transformation(andmodelling)concepts indifferenttechnologicalcontexts:

‘A technological space is aworking contextwith a set of associatedconcepts,bodyofknowledge,tools,requiredskills,andpossibilities.Itisoftenassociatedtoagivenusercommunitywithsharedknow-how,educational support, common literature and even workshop andconferenceregularmeetings.’[58]

Examples of technological spaces with transformations are the XML / XSLTransformationsspace[24]ortriplegraphgrammars[85].Welimitthescopeofthis work to transformation languages for MOF-based models, whichcorrespondstoachoiceoftheUML/MOFtechnologicalspace.

Figure2.4.:Favre’sTransformationPattern[32]

Thenextsectionscoversomeoftheimportantaspectsofmodeltransformations.

2.5.1.TransformationsasFunctions

Theabstractsystemrepresentedbyamodeltransformationcanbeseentobeafunctioninsettheory.This transformation function is thesetof transformationinstanceswhicharepairsofrelatedsourceandtargetmodels.Inthissense,thesetofallvalidinputmodelsis thedomainandthesetofalloutputmodels therange.Asmetamodelsdefinesetsofmodelsandallowthereasoningofwhetherornotamodelisvalidi.e.amemberoftheset,metamodelslendthemselvestodefiningdomainandrangeofthetransformationfunction.[32]

2.5.2.TransformationsasModels

Model transformations can be seen as models (as long as one understands ‘‘transformation’ as ‘description of a transformation function’ ’ [56]): Thetransformation conforms to its transformation language (metamodel), itrepresentsthetransformationfunctionbetweenoneormoresetsofmodelsandiscreatedforthepurposeofexecutionbyatransformationengine.

Figure2.4containsapatternofthenotionofmodeltransformationaccordingtoFavre [32]. It illustrates the roles the elements of a model to modeltransformation play in terms of the relationsRepresentationOf (μ),ElementOf(∈)andConformsTo (χ). The transformation itself is given as a transformationfunction, defined between a source and target modelling language. Whenexecuted for a specific pair of models, this one transformation instance is anelementofthetransformationfunction,assourceandtargetmodelsareelementsofthesetofallvalidmodels,i.e.thesourceandtargetmodellinglanguages.Thelanguages are represented by their metamodels, to which all valid modelsconform.Thetransformationfunctionisrepresentedbyatransformationmodel(anexecutabledescriptionofthetransformation)whichisanelementofallvalidtransformations, i.e. a member of the transformation language of choice. Thetransformation language is represented by a metamodel, to which thetransformationmodelconforms.

When transformation functions are represented by models, these models canthemselves serve as input or output of transformations. In this mannertransformationscanbehandledbythemechanismsandtoolscommontoMDEandbetreatedas‘first-classcitizens’ofMDE[57],withanumberofpromisingapplicationcases[103].Thesetransformationsarecalled‘higherorder’[9]:

Definition 6 (higherorder transformation): Higherorder transformationsrepresent transformation functions with transformations as input or outputmodels.

2.5.3.TransformationsasPrograms

ToachievethegoalofMDEofimprovingproductivitywhileraisingthelevelofabstractionofsoftwareartefacts,model transformationsareneeded thatcanbeevaluated and executed automatically. As mentioned above, a transformationmodel can represent a transformation function and can be interpreted andexecutedbyatransformationengine.Whenappliedtoasetofinputmodels,thetransformationengineproducesasetofoutputmodels.

Heretheexecutablemodelofthetransformationfunctiontakestheformofasetofinstructionsandisthusaprogram.ModelsthatmakeupthesourceorinputoftheexecutionarealsoreferredtoresideontheLHSandtargetoroutputmodelsontheRHSofthetransformation.

The transformation model can also be seen as the representation of a set ofmappings betweenmodels. An engine provided with models for both (or all)sides of themapping can then validatewhether themodels are related by thetransformation,i.e.whetherthemappingholdsinthegivencase.Thismakestwomodelsapairintheorderedpairofthetransformationfunction.

While all programming languages are generally suited to programtransformations,dedicatedlanguagesexisttospecifytransformationsindifferenttechnologicalspaceswithpropertiesrelatedtotheirtechnologicalspace[27]. InthenextsectionwelookattwotransformationlanguagesprominentintheUML/MOFtechnologicalspace,theirarchitectureandthesupportivetooling.

CHAPTER3

ModelTransformationLanguages

This chapter covers the ATLAS Transformation Language (ATL) and thelanguages contained in the Meta Object Facility (MOF) 2.0 Query/View/Transformation (QVT) and their supportive tooling in more detail. Bothapproaches are closely related to UML /MOF and have tool support for theEclipseIDEandtheEclipseModelingFramework(EMF).ATLisintroducedinSection 3.2 and QVT in Section 3.3. Both also reuse the Object ConstraintLanguage(OCL)formodelnavigationandexpressions,sothatOCLiscoveredin Section 3.4. The next section provides a short comparison of the twoapproachesintermsoftheirgeneralfeatures.

3.1.ModelTransformationLanguageFeatures

CzarneckiandHelsendevelopedafeaturebasedapproachfortheclassificationof the variety of model transformation approaches and technologies available[26,27].Theclassificationprovidesmeansofcomparisonofthelargenumberofresponses to theOMG’sRequest forProposal forMOF/QVT(seeSection3.3)[26] and a means to make the design choices behind model transformationapproachesexplicit[27].

Theirfeaturemodelprovidesthefollowingtop-levelandmandatoryfeaturesofmodeltransformations:

Transformation rules Model transformations consist of transformationrulesthatdescribehowthetransformationoccurs.Besidesbeingmandatoryfeatures of transformations in Czarnecki and Helsen’s feature model,transformation rules are also part of the definition for modeltransformations (seeDefinition 5 on page 32). The transformation rulesmapelementsof thesourcemodel to theelementsof the targetmodels tomakeupthetransformation.Thedomainofatransformationruleisdefined

bytherulebody,whichmustspecifytheuseofvariables,andcancontainsetsofpatternsandrulelogic.Patternsaredefinedasbeingasetofzeroormore variables used during the transformation process (metavariables), asyntaxandastructure,beingoneofstrings,termsorgraphs.

Rule application control Transformation approaches define how thelocations where in amodel the rules apply are determined and in whichordertherulesareexecuted.

RuleorganizationRulesneedstructuringmechanismstoprovidefeatureslikemodularisationorreusetodevelopers.

Source-target relationship This feature describes how transformationapproaches relate models, like if the source and target are the same orseparatemodels.

Incrementality Incrementalitydefineswhether transformation approachescanupdatetargetmodelsbasedonchangesmadetosourcemodels.

DirectionalityThisdescribesiftransformationscanbeexecutedinoneormoredirections(onlyfromLHStoRHSorinreverseorinthedirectionofanyofanarbitrarynumberofdomains.)

TracingTracingdefinesifandhowthetransformationapproachrecordsthetransformation execution process for later analysis or to provideincrementality.

In respect to this featuremodel, thedeclarative languageprovidesby theATLand thedeclarativeand imperative languagesof theQVTare rule-andpattern-based, and use a combination of implicit and explicit rule application control.Bothalsoprovidemechanismsforruleorganisationandre-use.

Whiletheprimaryuse-caseofATListhetransformationbetweentwodifferentmodels[49],QVTsupportstheuseofanynumberofmodelspertransformation.With theexceptionof theQVTCore(QVT-C) language,all languagesprovidetracingmechanisms and support for incremental transformations by using thetracing information from previous executions. The QVT languages and ATLdiffer in the directionality feature, ATL transformations are defined in thedirectionofaspecificdomain,whileforQVTtransformations,thetargetmodelcanbechosenatruntime.

3.2.TheATLASTransformationLanguage(ATL)

The ATLAS Transformation Language (ATL) is a textual model to modeltransformation language. It ismaintained in the EclipseATLProjectwhich ispartof theEclipseModelingProject [95] and is closely related to theATLASModel Management Architecture (AMMA) platform, which bundles a set ofprojectsconcernedingeneralwithMDEandcontributesinparticulartothetoolsupportofATL[49].

ATLwasdevelopedasaresponsetotheOMGMOF/QVTRequestforProposalforatransformationlanguagefromwhichQVToriginatedandisthussimilartothefinaladoptedQVTspecification.LikeQVT,ATLtransformationsaremadeup of ruleswhichmap elements belonging to a sourcemodel to one ormoreelements of a target model. It consists of both declarative and imperativelanguagestructuresalthoughthemainfocusisonthedeclarativeparts.ATLalsousesOCL (seeSection 3.4) for the navigation ofmodel elements but uses itsown partial implementation of the OMG OCL standard. Unlike QVT, ATLtransformationsareunidirectional[5].

3.2.1.LanguageStructure

TheATLtransformationlanguagesyntaxismadeupofahybridofdeclarativeandimperativeelements.Thepromotedprogrammingstyleisdeclarative,whileimperative language structures are provided for complex mappings. An ATLprogram is composedof a set of rules.Rules canbe eithermatchedrules thatmatchsourcemodelelementsandproducetargetmodelelementsorcalledruleswhich only produce output elements and are called from matched rules as amechanism for re-use and to structure complex cases. Rules use patterns todescribe the model elements they match or create. These in- or out-patternsconsist of pattern elements that bind to matching instances in the source andtargetmodels.[6]

Figure3.1.:TheATLabstractsyntax:ModulesandRules

Figure3.1containsanexcerpt from theATLabstract syntaxmetamodel3. OnetransformationismadeupofoneModule-elementthatreferencesasetofinandout OclModels which define the Ecore source and target metamodels of thetransformation.Each transformation ismadeupofModuleElementswhich canbei either Rules or Helpers. Helpers provide a mechanism to reuse OCLexpressionsandarecalledfromwithintransformationrules.

Figure3.2.:TheATLabstractsyntax:In-andOutPatterns

Rules consist of patterns and an optional ActionBlock that can containimperative statements that are executed after the target model elements areinitialised using the rule patterns. Rules can be either MatchedRules orCalledRules.MatchedrulesexecuteforeachInPatternthatismatchedinthesource model. Called rules can be called from matched rules and provide amechanismtostructurecomplexrulesandcanbereusedfromdifferentmatchedrules.Both rule typeshaveanOutPattern that describes the changesmade tothetargetmodel.ThedetailedsyntaxforpatternsisshowninFigure3.2.

Patterns are used inATL to describe and locate the parts of source and targetmodels that are used in a transformation rule. Patterns aremade up of one ormorePatternElementswhichareOCLvariabledeclarationsandcanbeusedassuch in expressions. The matching process binds concrete model elementinstances to thedeclaredpatternelements (variables)duringexecution.Patternelements are further divided into in-and out-pattern elements for theLHS andRHSsideofthetransformationrule.

Listing3.1:AsimpleexampleofanATLtransformation

Eachmatched rule has one InPattern to describe the sourcemodel part thatmustbematchedfortheruletoexecute.Thein-patternconsistsofexactlyone4SimpleInPatternElement whichmatches amodel element (OCLModel) and ismapped to exactly one out-pattern element.Themapping revealswhich targetelement was created from which source element and can be used for tracingpurposes. The OutPattern of a rule consists of one or moreOutPatternElementswhichcanbeeitheraSimpleOutPatternElement,whichdenotes a single model element that is created in the target model or aForEachOutPatternElement,which allows the creation of a number of targetmodel elements of the same type for eachmatch of the pattern element.Out-patternelementsareinitialisedusingasetofBindings.Abindingdescribeshowthe value for an attribute of a target model element is calculated. The valuecalculation is given by an OCL expression which canmake use of any validOCLvariableinthecurrent(rule)scope,i.e.includingallpatternelementsoftherule.

Listing3.1containsa simpleexampleof anATL transformation. It transformselements of the IMDB metamodel to elements of the extended EMFLibrarymetamodel (see the application scenario introduced in Section 1.2). Thetransformation contains twomatched rules: the first onematches instances oftypeFilmandcreatesinstancesoftypeVideoCassetteinitsout-pattern,setting

a value for the title and the boolean attribute damaged to false (assuming allnew video cassettes in the library are not damaged). The cast association islinkedtothefiguresassociationofthesourcefilmelement,whichmeansthatthevaluesaretobetakenfromtherulethatmatchedthetypeofthegivensourceassociation, which is the second rule of the transformation as it matches theFiguretype.

The second rule creates a CastMember for each Figure. The values of thepropertiesfirstNameandlastNamearecalculatedusingOCLexpressionswhichnavigatethemodelalongtheplayedByassociationtotheassociatedinstanceofActor,fromwhichthevaluesofnameandsurnameareread.

WhenthetransformationisexecuteditcreatesaVideoCassetteforeachFilminthesourcemodelwithanassociatedCastMemberforeachFiguredefinedfortheFilm.ThevaluesoftheCastMemberattributesaretakenfromtheActor-instanceassociatedwiththeFigureinthesource.

TheATLproject[95]providesaneditorfortheEclipseframeworkandavirtualmachinetoexecuteATLtransformations,whichisdescribedinthenextsection.

3.2.2.TheATLVirtualMachine

ATLmakes use of a virtual machine that executes ATL-specific byte-code toperformamodeltomodeltransformation.ThespecificationoftheATLVirtualMachine (ATL VM) describes an abstract computing machine for which twoimplementations exist; a model infrastructure independent referenceimplementationandonebaseddirectlyontheEMFEcoreimplementationwhichisoptimisedforthetransformationofEcore-basedmodels.[6]

Figure3.3.:TheATLcompilationprocess[96]

The compilation process is as follows (see Figure 3.3): Transformations arewrittenintheATLtextualsyntax(.atlfile).Thetextualrulesareprocessedbyaninjector into an Ecore-basedmodel that conforms to theATL abstract syntax.The injector reports any syntax errors. The model is validated and occurringproblemsarecollected inaproblemmodel that links tomarkers in the textualrepresentation to indicate the error sources.After the compilation to theVM-specificbytecode,theresulting.asmfilecanbeinterpretedbytheATLVM.TheintermediatecompilationprocessallowsforalternativelanguagestobeusedtospecifytransformationsontopoftheATLVM.[96]

3.3.MOFQuery/View/Transformation(QVT)

TheMeta Object Facility (MOF) 2.0 Query/View/Transformation (QVT) is amodel transformation framework specified by the OMG as part of the MOFcollection of modelling standards [73]. In general terms, it provides modeltransformation functionality forMOF-based languages like theUML. It catersbothtotheuseoftransformationsasexecutableprograms,whereoutputmodelsare created ormodified based on inputmodels and to the use as relations, todefine and verify rules that must hold between models. Transformations aremadeupofrulesbetweenmodelsexpressedintermsoftheirMOF-metamodelsand additional OCL expressions. They can be defined between an arbitrarynumberofmodels,whereatransformationbetweenthesamemodelasinputandoutput is an in-place transformation, but a transformation can also create amodelbasedonanumberofdifferentinputmodels.Asthedirectioninwhichatransformation is executed can be chosen at runtime, the definition of bi-ormulti-directionaltransformationsispossible.

QVT ismade up of three distinct but related languages: the declarativeQVTRelations(QVT-R)andQVTCore(QVT-C)languagesandtheimperativeQVTOperationalMappings(QVT-O)language.TheQVT-Clanguageisdesignedtobethesmallestandtobeexecutedbyavirtualmachine inanalogyto theJavavirtualmachineandtoserveasthesemanticbasisfortheotherlanguages.Theother two languages aremade to bemoreverbose, resideon a higher level ofabstraction and be better understandable by humans.They can be transformedinto QVT-C for execution, but the standard also foresees tool vendors toimplement the direct execution of the higher-level languages as long as theresultsarecorrect.[73,p.10]

3.3.1.Semantics

TheOMG specification provides no formal semantics of the QVT languages.TheQVT-Rsemantics areprovidedbyamapping toQVT-C,which in turn isonly semi-formally defined [41]. Other scientific work provides someapproachestoaformalisationofpartsoftheQVT,likesupportingQVT-RwithColouredPetriNets bydeLara andGuerra [59], their algebraic semantics forcheck-onlyexecutionofQVT-R[41]orthealignmentofthehybridrelationshipbetweenQVTOperationalMappings(QVT-O)andQVT-Rwithproblemtheoryby Giandini et al. [39]. Further semantic issues stem from the lack offormalisation of OCL, which is used as part of QVT and the lack of formalsemanticsofMOF(seesections3.4and2.3).

3.3.2.TheQVTCoreLanguage

The QVT Core (QVT-C) language is a declarative language to definetransformationson thebasis of patternmatchingover sets of variables againstmodels. Although suited for transformation execution, it is used mainly as afoundationfortheQVTsetoflanguagesasitservestoillustratethesemanticsofQVT-RintheQVTstandard.MostaspectsoftheQVT-RlanguagearedefinedbyatransformationfromtheQVT-RsyntaxtotheQVT-Csyntax.[73,p.163]InthisveinQVT-CisdesignedtobeasexpressiveasQVT-R(andQVT-O)buttobesimpler,whichmakesthetransformationdescriptionsinQVT-Cmoreverbosethanintheotherlanguages.[73,p.145]

The QVT-C language is build for the definition of transformations using anumber ofMappings that relate sets ofPatterns of candidate models to eachother. Patterns define variables, constraints and value assignments and can bematched against model instances in execution to define relevant parts ofcandidatemodels to a transformation (aBinding). The number ofmetamodels(Domains)usableinatransformationisnotfixed;mappingscanbedefinedforinstances ranging fromonemetamodel (in-place transformation) to potentiallyanynumberofmetamodels.

TheexecutionofQVT-Ctransformationsisdefinedfortwomodes.Incheckingmode,bindingsarecalculated forcandidatemodelsanderrorsare reported forinconsistentmappings.Inenforcementmode,onedomainhastobechosenandinconsistent mappings are fixed by creating or deleting elements to fulfil thetransformation. QVT-C specifies a tracing mechanism, but provides no

metamodelfortracingmodelsnoramechanismtoderivesuch.Howthetracinginformation is derived for an execution run is transformation specific andexplicitlyspecifiedineachmappingdefinition.Thetracingmetamodelisassuchonedomainofamulti-directionaltransformation.Inconsequence,thecommonuse case of transforming models of one metamodel into models of anothermetamodelwouldresultinatransformationofthreedomains(source,targetandtracing)whichisexecutedinenforcementmodeinthetargetdirection.

3.3.3.TheQVTRelationsLanguage

TheQVTRelations(QVT-R) languagefeatures thehighest levelofabstractionof the QVT languages. It has a declarative language style and provides thepotential for multi-directional interpretation of relations between multiplemetamodels,while the commoncases foundareunidirectional transformationswithadefinedsourceandtargetorbidirectionaltransformations,ifarelationshipbetween twometamodels is established. TheQVT standard contains a textualconcretesyntaxandthesuggestionforagraphicalvariantoftheconcretesyntaxforQVT-R[73].

ThecentralconceptofallQVTlanguagesisthepatternandtheaccompanyingpatternmatchingsemanticsformodels[73,pp.21].Apatterndefinesapartofamodel that features in a transformation, in termsof itsmetamodel.During theexecution,candidate(input)modelsarecheckedforoccurrencesof thepattern,whereeachvalidmatch isabinding instance.Thisbasicconcept isdefined intheQVTBasepackageandextendedbythedifferentlanguages(QVT-C,QVT-R,QVT-O) for their individual interpretations. In the QVT-R language, atransformation consists of one or more relations, which establish a set ofconstraintsbetweencandidatemodels.Transformationscanbeexecutedin twomodes. In thecheckingmode, the relations (constraints) betweenall candidatemodels are checked and violations are reported. If the constraints hold, thetransformationissaidtobevalid.Inenforcingmode,theconstraintsareenforcedbymodifyingone selectedmodel as the targetof the transformationexecutionuntil all relationshold (or the transformation fails).Themodel ismodifiedbycreatingordeletingelementsandsettingvaluesforsimpleproperties.

Relationsbetweenmodelsareexpressedusingoneormoredomains,whicharetypedvariableswithanassociatedpattern.Relationscandefinefurthervariablesand contain two sets of predicates, thewhen andwhere clauses, that providefurtherdetailtotherelation.Forthetransformationtobevalid,therelationmust

hold only when all constraints in the whenclause hold (pre-condition). If therelationholds,allconstraintsofthewhereclausemustalsohold(postcondition).Other relations can be referred to in the clauses, providing a structuringmechanismforrelationsandsubrelations.

Domain variables and associated patterns are also known as object templateexpressions as they specify how elements for target models are created inenforcing mode. The variables of a domain are bound to values during thematching process. For the remaining unbound (or free) variables, the objecttemplateexpressionspecifieshowvaluesaretobecreated.QVT-RmakesuseofOCLforexpressions tocalculatevaluesornavigateovermodelelements.TheQVT-RabstractsyntaxextendselementsoftheEMOFandOCLmetamodelstotightlyintegratewiththeOMGfamilyoflanguages.

Listing3.2:AsimpleexampleofaQVTtransformation

Listing 3.2 contains a simple transformation in the QVT-R textual syntax. Ittransforms elements of the IMDB metamodel to elements of the extendedEMFLibrarymetamodel(seeSection1.2).Thetransformationismadeupoftworelations:thefirstonecreatesinstancesoftypeVideoCassettefrominstancesoftype Film, setting a value for the title and the boolean attribute damaged tofalse (assuming all new video cassettes in the library are not damaged). ThesecondrelationcreatesaCastMemberforeachFigureandisabitmorecomplex:itdefinesasimplein-patterntomatchallinstancesofFigureandbindsthemtothevariablefigure. This variable is used in the out-pattern / object templateexpressions to set the values for the CastMember instance that is created orupdated. The actual values are calculated using OCL expressions: for theattributefirstNametheexpressionfigure.playedBy.namenavigatesthemodelalongtheplayedByassociationtotheassociatedinstanceofActor,fromwhichthe name attribute is read. For the attribute starsIn, the other relation isreferencedusing thewhenclause: it contains thepre-condition that the relationCreateCastMember only needs to holdwhen the relationCreateVideoCassetteheld previously for the two variables film and cassette, i.e. when aVideoCassettewascreated for theFilm the currentFigure belongs to.WhenthestarsInreferenceisset,thewhenclausealsoensuresthataviablevaluehasbeenboundtothecassette-variable.

Whenthetransformationisexecutedinenforcementmode(notcheck-only),itisexecuted in the direction of the extended EMFLibrary metamodel (alreadynamed target in the transformation) and an empty model is selected as thetarget, this model will contain a VideoCassette for each Film in the sourcemodelwithanassociatedCastMemberforeachFiguredefinedfortheFilmafterexecution. The values of the CastMember are taken from the Actor-instanceassociatedwiththeFigure.

3.3.4.QVTRelationsGraphicalNotation

BecauseofthegeneralsignificanceofthediagrammaticsyntaxoftheUML,theQVTstandardcontainsasuggestionforacomplementarygraphicalnotationtothe textualsyntaxofQVT-R[73,p.38].Unfortunately, thesyntax isnotwell-definedandthestandardonlyprovidesasmallsetofexamplesandexplanationsin natural language, which causes ambiguity and provides room forinterpretation.Thishascausedotherstocreateandusedifferentvariantsofthesyntax(compareforexampleMarkovićandBaar’suseinOCLrefactoring[65]

andWachsmuth’s use in co-adaptingmodels [107]). Nevertheless, their usageshowsthatthegraphicalnotationisverycompactandarguablyintuitive,sothatitisusedinthisworkasdescribedbelow.

Figure3.4.:ThesimpleexampleofaQVTtransformationingraphicalnotation

For each relation, the graphical syntax prescribes a rectangle that contains thepatternsofthedomainsoftherelation,atitlewiththenameoftherelationandoptional regions below for the when-and whereclauses of the relation. ThecontentsoftheclausesisgiveninOCLtextualnotation.(SeeFigure3.4forthetransformationexampleoflisting3.2inQVT-Rgraphicalsyntax.)

Domain patterns are expressed using a notation similar to the UML objectdiagram notation. Table 3.1 details the syntax used and the assumptions andextensionsmadeforthiswork.Weannotateassociationswiththeirassociation-end names where necessary to distinguish between different possible linksbetween elements. In places where the choice of association is unambiguous(becauseonlyoneexistsbetweentwotypes),thenamescanbeomitted.

ObjecttemplatepatternsareexpressedsimilartoUMLobjectdiagrams.Thestereotype-likemarker <<domain>> signals the domain ofthepattern.WhilenotexplicitlystatedbytheQVT standard, we annotate the association-endstodifferentiatethelinksinvolved.

The‘relationsymbol’configurestherelation,where each arrow defines one domain. Itshowsthemodelandmetamodelused(l,r,mandATL,EMOF)andwhetheradirection ischeckableand/orenforceable (C/E).Hereweassume the standard to imply that a relationwith more than two domains has an arrowsperdomains.

This notation represents a set of elements.Unfortunately it does not indicate whichcollection type was used, which makes itambiguous.We suggest using annotations intheformofcommentswherenecessary.

The‘not template’matcheswhennoelementfulfils thetemplateinapattern.Thisis tobeequivalent to a constraint that forces theassociationthatlinkstheelementtobeemptysuchas->isEmpty()or->size()=0.

Constraints can be attached to patternelementsusingthisnotation.It isassumedtobe exchangeablewithusing the constraint inthewhenclause.

Table3.1.:ElementsoftheQVT-RgraphicalsyntaxasadaptedfromtheQVTstandardinversion1.1[73].

3.4.TheObjectConstraintLanguage(OCL)

ThissectionprovidesashortintroductiontoOCLanditsusageintransformationlanguages. Another aspect of OCL is important to this work, namely the co-evolutionproblemofUMLmodelsandassociatedOCLconstraints.ResearchinthatareaprovidessomefoundationandiscoveredindetailinSection8.2.

3.4.1.TheOCLandModelTransformationLanguages

TheObjectConstraintLanguage(OCL)isaformaltextuallanguagetodescribeinvariant conditions or queries for model elements of the OMG family oflanguages(mostcommonlyknowntospecifyconstraintsonUMLclasses).OCLisusablewithMOFandanyMOF-basedlanguagesandisusedintransformationlanguages like QVT and ATL. This work uses OCL according to the OMGObject Constraint Language specification in version 2.3.1 from January 2012[74]orintheformoftheATLOCLdialectwherenoted.

OCLitselfisfreeofsideeffects,meaningthatOCLexpressionscannotchangethemodeltheyareassignedto.ButthespecificationallowsfortheuseofOCLtodescribeoperationsthatmanipulatemodelswhenexecuted.ThismakesOCLusablein transformationlanguagestodescribethechangestheapplicationofaruleperformswhenexecuted.OCLcanalsobeusedtoformulateconstraintsandforitstypesystem.Specifically,OCLfulfilsthreepurposesinthetransformationlanguagesQVTandATL:

FilterExpressions:Filterexpressionsareusedtofurtherrestrictthematchingofmodel elements in rules and thereby the applicability of rules. The initialselectionofmodelelementcandidatesforrulematchingisdonebytype.ThissetofelementscanthenbereducedfurtherbybooleanOCLexpressionsthatareappliedtoeachelement.

ModelNavigation: The selection of sets of elements using some element asstartingpointandthemanipulationofsetsofelementsisachievedwithOCLnavigationexpressionsboth inATLandQVT.Navigationexpressionsbeginwith some variable that refers to a model element and then describe thenavigationacrossassociationstootherlinkedsetsofelements.Thesetscanbereduced using OCL filters and manipulated using set operations. In thismannerOCLprovides themechanisms todefinepatternsofmodelelementsfortransformationlanguages.

ValueCalculation: The values of simple types are calculated using theOCLtypesystemandexpressionsforvaluebindinginATLandQVT.TheavailableoperationsprovideStringandIntegermanipulationforexample.

3.4.2.TheOCLContext

As both QVT and OCL are maintained by the OMG, the QVT syntaxspecificationandabstractsyntaxmodels import theEssentialOCLspecificationand model directly. Variables used in QVT inherit fromEssentialOCL::Variable and expressions are of typeEssentialOCL::OclExpression[73,p.159].

ATLontheotherhandusesitsowndialectandimplementationofOCLinstead.The implementation is not complete, for example, the type-casting OCLexpression .oclAsType() is not available in ATL, which prevents someresolutionstrategiesforATLtransformations(seeSection7.7forexample).

SemanticsoftheOCLContext

OCLexpressionsarewritteninrelationtoasyntacticalcontext; ingeneral thiscontextisgivenbyanobjectmodelonwhichtheexpressionistobeinterpreted.TheOCL standard defines the context forOCL expressions for invariants andpre-andpostconditionswhenusedtoconstrainUMLmodels.ThemostgeneralcontextistheUMLmodelitselfandthedatasignatureΣμofanOCLexpressioncontainsthetypesandoperationsonattributesavailablefortheexpression.[74,p.212]

For invariants and pre-and postconditions the context can further be declaredwiththenotionoffreevariables,whicharedefinedusingacontextclause.Anynumberofvariablescanbeexplicitlydefinedandtypedortheprovidedvariableselfistypedandthenusableinasubjectexpression.

EssentialOCL

In alignmentwith the separation ofMOF intoCMOF and the smaller EMOF(seeSection2.3)andtheEcoreimplementationofEMOFforEclipse,aminimalsetofOCLisavailableforEMOFthatreferencesEMOFtypesexplicitly[74,p.187]. It is calledEssentialOCL and is implemented for Ecore and the EclipseframeworkaspartoftheModelDevelopmentToolsproject5.

3 The graphical representation of figures 3.1 and 3.2 was created from the ATL.ecore abstract syntaxdefinition available in the ATL eclipse plugin org.eclipse.m2m.atl.common in version 3.3.1 availablefromtheEclipseModelingProject[95].

4TheATLabstractsyntaxisimprecisehereasthemultiplicityforin-patternelements(1..*)wouldcaterformorethanoneelementperin-pattern,yettheeditorandconcretesyntaxonlyallowone.[5,p.37]

5http://www.eclipse.org/modeling/mdt/

http://www.eclipse.org/modeling/mdt/

CHAPTER4

SoftwareEvolutionandMDE

Theevolutionofsoftware isoneof thebigchallenges insoftwareengineering[69].Thecomplexityofsoftwaresystemsisconstantlyincreasing.Atthesametime, the business needswhich drive the development of software continue tochange with growing pace and software systems are expected to adaptaccordingly. Depending on the sources, maintaining and adapting softwaresystemsaftertheinitialdevelopmentprocessareestimatedtomakeupto90%oftheoverallcost[89,p.489].

The challenge of software evolution and dealing adequatelywith the growingcomplexity of software systems over time has been known in softwareengineering for a long time. In the 1980s, Lehman proposed eight laws ofsoftwareevolutionbasedoncasestudiesandanalysisofsoftwareprocessesovera20yearperiod.Accordingtotheselawsinsummary,anyreal-worldsoftwaresystem(inthesensethatitprovidesasolutiontoanacceptableapproximationofa realworldproblemor that it is embedded in the realworld as auniverseofdiscourse) is bound to undergo continuous change or become less (cost-)effectiveovertimeinstead.Theneedforevolutionisintrinsictolargesoftwaresystemsandevolutionincreasessoftwarecomplexityunlessactivelycountered.[60,61]

Becauseofthehighcostandslowrealisationassociatedwithsoftwareevolution,in 2000, Bennett and Rajlich draw up a research roadmap for softwaremaintenanceandevolution for thenext tenyears to identifykeyproblemsandfindpromisingsolutions[10].Inthisroadmap,thethreeresearchtopicsdirectlyassociatedwiththesoftwareevolutionstageinthesoftwarelife-cycleare:

1. Architectures which will allow considerable unanticipated change in thesoftwarewithoutcompromisingsystemintegrityandinvariants.

2. Architectureswhichthemselvescanevolveincontrolledways.

3. Managingtheknowledgeandexpertiseofthesoftwareteam.’[10]

Furthermore,

‘ahighlypromisingareaofresearchisthereforetofindwaystoraisethe level of abstraction in which evolution is expressed, reasonedaboutandimplemented.’[10]

Evolution is also recognised as an architectural concern; the ISO/IEC/IEEE42010standardnamesthe‘principlesgoverningtheevolutionofthesystemoveritslifecycle’asapossible‘essentialorfundamentalcharacterization’ofasystemand thereby as possible constituents of architectures and architecturedescriptionsofinterestingsystems[48,p.4].

Therefore, thequestionofhow to formalizeandapplyevolutionand toassistssoftwareengineersinperformingevolutionandanalysingtheimpactofsoftwareevolution on software systems are important and ongoing research topics forsoftwareengineeringingeneral.

ThenextsectioncoversthespecificsofMDEandhowtheproblemofsoftwareevolution relates to the artefacts of the MDS. Refactoring as an approach tosoftwaremaintenancehasbeenadaptedforMDEandmodeltransformationsandisrelatedtoMDSevolution.ItisaddressedinSection4.2.

4.1.MDEandtheEvolutionofMDS

MDEpromisestosupportsoftwareengineerswithsuitablemethodsandtoolingtohandlethecomplexityofmodernsoftwaresystems-duringdevelopmentandmaintenance. In essence, MDE strives to break down the complexity of asoftwaresystemintomanageableabstractions,eachembodiedbyasuitabletypeof artefact.Thebenefits ofMDEhavebeenwidelydiscussedboth in industryandacademia.Amongtheseisthesuperiorexpressivenessofmodelsoversourcecode, the suitability of Domain Specific Languages (DSLs) to capturespecialized domains, the ability of better partitioning systems according to(technical) concerns and describing their relationship using modeltransformations, the increased reusability of artefacts in the developmentprocess,mechanisms for concealing (implementation) detailwhere appropriateandmore.[92]

Yet, theseexpectedbenefitscanonlybe fully realisedwhen thecomplexityoftheMDSitselfremainsmanageable.Duetothehighnumberofartefactsandthecomplexityanddiversityofartefacttypes,theMDSitselfbecomessusceptibletomaintenance issues. Therefore the challenges posed toMDE are the same asthose of regular development methods. These range from applying suitabledevelopment processes, handling distributed development to the versioning ofmodelsandmodeldrivenartefacts.IftheeffortnecessarytomaintaintheMDS(being ‘only’ a representation of the software system of concern) becomesoverwhelming and circumventing changes to the software seem beneficial, itsrepresentative nature and overall use are threatened. For this reason these is aneedformethodsandtoolingfortheevolutionoftheMDS[71].

Atkinson an Kühne relate the problem of evolution in MDE directly to thesoftware artefacts common inMDEand the goal of improving short-termandlong-termproductivity(seesection2).Alargeamountoflong-termproductivitydependson

‘the longevity of a primary software artifact. The longer an artifactremains of value, the greater the return derived from the effort thatwentintothecreationofthatartifact.Thus,asecondandstrategicallyeven more important aspect of MDD is reducing the sensitivity ofprimaryartifactstochange.’[4]

Therefore,onekeyaspectofthevalueofMDEliesinthemeansofhandlingtheevolution of the artefacts involved. Atkinson an Kühne further identify fourfundamental formsofchangewithparticular importance toMDEartefactsandtooling[4]:

Personnel Knowledge and skills are always bound to the developersworkinginprojects;astheprojectstafffluctuates,soincreasestheriskofalossofinformation.Thiscanbealleviatedprimarilybyusinga‘conciseandtailorablepresentation’ofprimaryartefacts.

RequirementsChangingrequirementsareacommonprobleminsoftwareengineering. Atkinson an Kühne especially stress the need to reduce theimpactofrapidrequirementschangesbothonmaintenanceandintermsofdisruption of online services. They see the need to support ‘dynamicadditionofnewtypesatruntime’intermsofprimaryartefacts.

DevelopmentPlatformsTheconstantevolutionofdevelopmentplatformsmayendangerthelongevityofprimaryartefactsshouldthesebedependentonaparticulartool.A‘high-levelofinteroperability’betweenMDEtoolsisneeded.

Deployment Platforms The rapid evolution of platform technology is agrowing problem. Shielding primary artefacts from platform change canincrease their longevity – for example by automating the process ofgenerating platform specific artefacts fromplatform independent artefactsbyapplying‘userdefinablemappings’.

TheneedtoprovideexplicitsupportforthehandlingofevolutionofMDScanbe derived from the first two areas of change. For one, with the fluctuatingnatureofprojectpersonnel,providinga‘conciseandtailorablepresentation’ofthe evolution of theMDS alongwith the primary artefacts should counter theexpected information loss.Furthermore, the thread to the longevityofartefactsfromchangingrequirementscanbecounteredbyprovidingadequatetoolingtodescribe,performandpredicttheimpactofevolution.

Tothisend,Engelsetal.capturetheevolutionofmodelsasatomic,elementarysteps. In their method, model transformations are used to capture singleevolutionsteps.Thesecanbecomposed toexpress thecomplexevolutionofamodel.Foreachstep,theconsistencypreservingpropertiesaredefined.[28]

One advantage of representing evolution as elementary steps and combiningthese to formmore complex evolution tasks is the exploitation of the localityprinciplefromcomponent-basedsoftwaredevelopmentapproachforMDE.Thismeans that the effects of the changes made are kept local. In general, theconsistencyoftheoverallsystemmaybeendangeredbyanevolution.Butiftheconsistencypreservingpropertiesofasetofevolutionstepscanbeshown,anyevolution that is made up of consistency ensuring steps can be performedwithoutharm.Engelsetal.showtheconsistencypreservingattributeofcreationanddeletionrules(evolutionsteps)forspecificdomainelementsandinrelationtotheirchosendomain(notingeneral):

‘Inordertomanipulateagivenmodelwehavetodeterminethekindofchangewewanttoachieveaswellasitslocationinthemodel.Thiscorrespondstotheselectionofaruleanditsapplicationarea.Then,therulemaybeappliedprovidedthatall thoseapplicationconditionsare

satisfied that are required for the consistency properties to bepreserved.Ifthereisnoconsistency-preservingtransformationforthechangeweintendtodo,wehavetoresorttoad-hocevolutionwithacompleteconsistencycheckofthenewmodel.’[28]

Wachsmuthfollowsthisapproachinprovidingamethodfortheco-evolutionofmetamodelsandmodels[107].Co-evolutionisdefinedbyFavreastheproblemof requiring system architecture and implementation to evolve in a‘synchronizedway’,astheyarelinked,becauseotherwise‘architecturaldrift’or‘architecturalerosion’canoccur[31],whicharemaintenanceissuesoftheMDS.According to Favre, the co-evolution problem also occurs for other linkedartefact types, likelanguagesandprograms,modelandmetamodels,andmore.Wethereforedefineco-evolutionforthisworkasfollows:

Definition7 (co-evolution):Co-evolution is the synchronizedevolutionoflinked artefacts to maintain the consistency of the MDS. The co-evolutionproblem refers to inconsistencies that may occur when artefacts are changedindividually.

Wachsmuth’sapproachprovidesforthestepwiseco-evolutionoflinkedmodelsandmetamodels by providing a set of 16 adaptations that can be applied forcommonand recurring typesof changes [107]. The adaptations prescribe howboth models and metamodels need to be adapted to remain consistent. Theapproachisbasedinpartsonconceptsofobject-oriented(OO)refactoringwhichhasbeen adapted toMDE.Thenext section coversmodel refactoring inmoredetail. In chapter 8 a number of different approaches for the co-evolution ofrelatedartefactsoftheMDSarecompared.

4.2.ModelRefactoring

Refactoringplaysan important role in themaintenanceof software systems inOOsoftwareengineering.AccordingtoFowler,

‘Refactoring is the process of changing a software system in such away that it does not alter the external behavior of the code yetimprovesitsinternalstructure.’[34,p.xvi]

Opdykeinitiallyprovidedacatalogueofrefactorings(‘restructuringoperations’)inhisPhD-thesisforprogramswritteninC++[80].Thelistofrefactoringshasbeen extended by Fowler [34] and others. Opdyke defines the behaviour

preserving properties of refactorings according to seven criteria, of which sixrelatetosyntacticcorrectnessandtheseventhprescribes‘semanticequivalence’asfollows:

‘let theexternal interface to theprogrambevia thefunctionmain. Ifthe function main is called twice (once before and once after arefactoring) with the same set of inputs, the resulting set of outputvaluesmustbethesame.’[80,p.xvi].

Therefore a refactoring is correct if it provides a syntactically correct outputprogram from any applicable syntactically correct input program and therefactored program delivers the same output for the same input as before therefactoring. It has been shown that the behaviour preserving property ofrefactorings is difficult to prove in general, so that more fine grained criteriasuchas‘accesspreservation’,‘updatepreservation’and‘callpreservation’havebeenproposedtobeusedinstead[7,70].

Fowlerstatesthatrefactoringservesanumberofpurposes,frommakingsource-codeeasier to readandgraspforhumans topreparingasoftwaresystemtobeextendwithnew features.Refactoring is anongoingprocess, startingwith thefirststepsinimplementationandcontinuingovertheentiresoftwarelife-span.Itisakeyactivityinsoftwareevolution,asitmaintainsevolvability(inimprovingstructure)orinpreparingnewfeatures.[34]

Many approaches have been proposed that carry over the idea of refactoringfromOO-technology toMDE[64], resulting in the field ofmodel refactoring.While refactoring in the object-space is well understood, refactoring in themodel-space is ongoing research,mainly becausewhat constitutes the internalbehaviourofamodelisanopenquestion[104].ApproachesincludecataloguesofrefactoringpatternsforUMLclassdiagrams[3,14]orMarkovićandBaar’sformalisation of themost important refactoring rules forUML class diagramsanddependentOCLconstraints[65].

Inmodelrefactoring,thecentralartefactsofinterestaremodels.Thisprovidesasetofchallengesopentoresearch[67],twoofwhichare:

ModelqualityAsthecentralgoalofrefactoringistheimprovementofthequalityattributesofthemodelinquestion,aprecisedefinitionforqualityintermsofmodels is needed.Models are the representationof a system for

somepurpose,sothatthequalityofthemodelmayhingeonhowwellthemodel fulfils this purpose. Mens et al. further suggest attributes likeusability, readability and performance as possible quality aspects formodels, aswell as the use of design patterns [35, 43] inmodels ofOO-systems[67].

Behaviour preservation The external behaviour of the artefact that isrefactored should not be changed by the refactoring. This requires thedefinitionofwhatpropertiesmakeup theexternal‘behaviour’ofamodelandhow they canbe effectivelymeasured.Onehindrance for theprecisedefinition of such properties for UML models is the lack of formalsemanticsoftheUML[67](seeSection2.3.1).

ModelrefactoringandevolutionapproachesinMDEaresimilarintheiruseofelementarystepstorepresentchangethatcanbeappliedtomodels[7,107].Inboth cases, the simple steps can be combined to represent more complexscenarios.Also, inmany approaches the basic sets of steps available are verysimilar and describe the same or similar kinds of model change. The maindifferencecanbeseeninthefocus:refactoringapproachesaremainlyconcernedwith improving some defined properties of quality of the model in questionwhileexternalbehaviouralorsemanticpropertiesremainunchanged.Thefocusofevolutionaryapproaches isgenerallybroader; thesealsoattempt tomaintainthe quality aspects of the MDS but cater to all kinds of change, explicitlyincluding change of the external or semantic properties of the model [31].Furthermore, co-evolution approaches take the dependencies between modelsand other artefacts into account and attempt tomaintain the quality of relatedartefactsalongwiththechangedartefacts.

PARTII

Operator-basedCo-EvolutionofMetamodelsandModelTransformations

CHAPTER5

SupportingtheEvolutionofModelDrivenSystems:AStepwiseApproach

In this chapter, we introduce an approach to support software architects inperforming common coevolution tasks for metamodels and ATL modeltransformations.Theexpectedbenefitoftheapproachisthereducedeffortwhenperformingcommonlyoccurringchangestometamodelsandthereducedeffortin adapting dependent model transformations accordingly. Depending on thechangeperformedandtheresultingimpact,aportionof theadaptationscanbeperformed automatically while the software architect can be supported whenperformingmanualadaptationfortherest.Furthermore,theapproachallowstheautomaticdetectionoftheimpactsondependenttransformation.

The next section recapitulates the coevolution problem for metamodels andmodeltransformationsfirstintroducedinSection1.1.Section5.2detailsthegoalpursuedinaddressingtheproblemandSection5.3coverstherequirementsthatneedtobefulfilledbyasolution.Section5.4introducesourproposedapproachwhich is detailed in the subsequent sections. The last section covers thecombinedstepsofourproposedapproach.

Figure5.1.:Theextendedproblemillustration

5.1.ProblemDescription

WhenusingMDEmethods todevelopandmanagecomplexsoftwaresystems,the software systems are represented by a possibly high number of varyingmodelling artefacts. The artefacts themselves, their composition and thedependenciesbetweenthemmayalsobeexpectedtobecomplex[9].WerefertotheseartefactscollectivelyasModelDrivenSystem(MDS)(seeDefinition1onpage19).

Figure 5.1 contains the schematic illustration of a typical use case of modeltransformationsaspartoftheMDS,annotatedwiththeartefacttypesoftheATLframework. Itconsistsof: twoormoredifferentmetamodels which specifythe type of models for which the transformation is defined. The metamodelsconform to the common Ecore metametamodel . The transformation isimplementedasasetofATLtransformationprograms whichtransformasetofinputmodels ontheLHSintooutputmodels ontheRHS.Ifvalid,theATLtransformationsconformtotheATLlanguage ,inthattheyconformbothtotheATLconcreteandabstractsyntax.

Theoutputmodelsproducedbythetransformationmayfurtherserveasinputforany number of further automated processes, for instance for the generation ofsourcecode .This usage adds additional artefacts anddependencies via thecodegenerationframeworktotheMDS,likeconfigurationfiles,generationcodetemplatesetc.Thedifferent artefact types involvedare createdandmaintainedby dedicated and specialized tooling, like the ATL editor which providesfunctions like code completion, graphicalmodel editors forEcoremodels thatmanage additional layout information and further typical developmentinfrastructureforversioncontrol,testingetc.tosupporttheprocessasawhole.

MDE promises to support software engineers to handle software systemcomplexitybymeansofthesuperiorexpressivenessofmodelsoversourcecode,the suitability of Domain Specific Languages (DSLs) to capture specializeddomains, the ability of better partitioning systems according to (technical)concerns and describing their relationship using model transformations, theincreasedreusabilityofartefactsinthedevelopmentprocessandmechanismsforconcealing (implementation) detail where appropriate andmore. [92] Yet, theexpected benefits can only be fully realisedwhen the complexity of theMDSitself remains manageable. Due to the high number of artefacts and thecomplexityanddiversityofartefacttypes,theMDSitselfbecomessusceptibletomaintenanceissues.

The artefacts involved in a model transformation can be said to be tightlycoupled [93], asmodel transformationwritten inATLnavigateover andmakeuseofmodelelementsinmanydifferentpartsofthetransformationdescription;such as rule selection, rule application constraints, value calculation, elementcreationandmore.Thereisnodifferencebetweenpublicorprivatesectionsofmodels or transformations and no concept of an application programminginterface. Changes to either the transformation or any of the involvedmetamodelscanpotentiallyimpactanyoftheotherartefacts.

Furthermore, transformations depend on a pattern of input and output modelelements,whicharemorecomplex thanmethodsignatures in theobjectspace.Declarativetransformationlanguagesallowthedefinitionsofrules,sothatonetransformationcanbemadeupofanarbitrarynumberofrules.Theserulesaredefinedonthebasisofoneormoremetamodels,whichmakesthemetamodelsthetypesofthetransformation[93].Yet,typingtransformationsbytheinvolvedmetamodelsisverycoarse-grainedasanychangetothemetamodelwouldmeanthe creation of a new type, even if the transformation is not affected by the

change. As a result, the interface provided by a transformation is not easilydelimited and the internal and external behaviour defined. This makes themaintainability,reusabilityandevolutionoftransformationsmoredifficult.[50,108]

OO-technology explicitly providesmechanisms for the decoupling of artefactsand encapsulation of functionality – like class contracts or method accessmodifiers–whichhelptodifferentiatesourcecoderegionsthatareexpectedtobeaccessiblebyclientsfromthose thatcanbechangedsafelywithoutcausingexternalimpact.ThismeansforinstancethatinJava,theimpactofachangecanbe detected by the development environment inmany cases; especially if thechangeisstaticandtheimpactcanbedeterminedbythecompiler.InJava,anysophisticated development infrastructure has information at hand to determinemany types of impact. When changing a method signature, all uses of themethodinthecurrentprojectcanbedeterminedandadaptedforexample.

Similar concepts either don’t exist formodel technology or are not as readilyavailable: for instance, encapsulation by visibility of package content is onlyavailable in CMOF and not in EMOF [75, p. 35]. Another example is thenavigabilityofassociations;whetherornotanassociationisnavigablemayvarywiththeusecase:

‘If anend [ofanassociation] isnotnavigable, access from theotherendsmayormaynotbepossible,andifitis,itmightnotbeefficient.Note that tools operating on UML models are not prevented fromnavigatingassociationsfromnon-navigableends.’[77,p.38]

This means that non-navigable associationends may be made available fornavigationbyatoolorplatformimplementationregardless.

Thecomplexitycausedby thenumberandvarietyofelements inanMDSandthe tight coupling of elements motivates the need for suitable approaches tosupportsoftwarearchitectsincommondevelopmentandmaintenancetasks.Theprogramming environments used to create metamodels and modeltransformationsplayakeyroleinthisgoal.Modeltransformationlanguagesareprogramming languages and share the commonproperties and functionality ofotherprogramming languages [1].The rules that represent transformations areexpressed as programs consisting of declarative or imperative statements in atextualconcretesyntax.Thestatementsundergolexicalandsyntacticalanalysis

phasesthatprovideanabstractsyntaxtree(AST)ofthetransformationprogram.InthecasesofQVTandATL,theASTisthentranslatedintoasimplerbutmoreverbose code that can be executed by a virtual machine to execute thetransformation[73,95].

The features of model transformation approaches described above areimplementedintextualeditorsthatprovidemechanicstoaidarchitects,likecodecompletion and syntax highlighting. For this purpose, the editors maintain anAST of the current transformation in memory. Changes made to thetransformationprograminsourcecodeareparsedandwhenrecognized,insertedinto the AST immediately. As transformations are closely linked to themetamodels they are defined on, some environments also maintain arepresentation of the metamodels involved in memory and provide codecompletionforexpressionsthatusemodelelements.Oneparticularityoftoolingfortransformationlanguagesasopposedtootherprogramminglanguagesisthatmodels are traditionally created in different environments than the textualprogramming editors. For example, Ecoremodels can be created in graphicalnotations or a table-like view on an XMI document or in pure ExtensibleMarkup Language (XML). This means that the maintenance of the relationbetween the AST of a transformation and the metamodel representation inmemoryneedstobeupdatedacrossdifferenteditorsandlanguagestoofferthesamesupportaspurelytextuallanguages.ThisaddstothecomplexityofMDEtoolsupport[109].

Insummary,thecomplexitycausedbythenumberandvarietyofelementsinaMDS and the tight coupling of elements motivates the need for suitableapproaches to support software architects in common development andmaintenancetasks.Thisconstitutesthegoalofourapproachdiscussednext.

5.2.Goal:ProvidingSupportforCoEvolution

The goal of this work is the development of a method to support softwarearchitects inperformingcommoncoevolution tasks formetamodelsandmodeltransformations.Coevolution tasksentailchangingdependentartefacts togethertomaintainoverallconsistency[22].

Consistency,inthecaseofmetamodelsandmodeltransformations,isforonethesuitability of the metamodel to represent the input and output models of themodel transformation. But the expected function of the transformation also

needs to be taken into account; an evolutionary change can introduceinconsistencies that cause a transformation to produce the wrong output,althoughitisstillexecutable.

ThebenefitofsuchamethodisthereducedeffortofperformingchangestotheMDSdue to the partial automation ofmanaging the dependencies of artefactsand providing a solution to combined evolution. Additionally, the use ofoperatorsasopposedtoad-hocchangessupportsthepredictionoftheimpactanevolutionstephasandtheeffortneededtoresolveit.

5.3.Requirements

Toachievethegoaldescribedintheprevioussection,anumberofrequirementshave to met. These cover the functional aspects of evolution and impactresolution and ensuring correctness. Furthermore, themethod should integratewithstateof-the-artMDEtechnologyandshouldprovidetoolingthat integrateswithcommonMDEtools.Thetopicalsectionsbelowcovertherequirementsindetail.

EvolutionSupportThecentralbenefitofasupportmethodisthereducedeffortof performing changes to metamodels and managing the dependent modeltransformations.Themethodshouldsupportsoftwarearchitectswiththemostcommontypesofchanges:

Requirement 1 (Support common evolutionary changes): The methodshouldsupportasetofevolutionarychangesthatarecommonlyencounteredinmetamodelandtransformationcoevolution.

ImpactDetectionWhen a change is applied to a metamodel, any dependentmodeltransformationsmayormaynotbeaffectedbythechange,dependingon the type of change and the type of relation between metamodel andtransformation.Tosupport the softwarearchitect inpredicting the impactofthe change and finding a suitable strategy to resolve the effect, themethodshould provide a mechanism to detect which parts of dependenttransformationdescriptionsareimpacted:

Requirement2(Detectimpact):Fortheprovidedchangetypes,themethodshouldidentifythepartsofadependenttransformationdescriptionthatmaybeimpactedbythechange.

ImpactResolutionWhentheimpactofachangeonadependenttransformationdescription is known, and an automatic resolution is possible, the methodshouldupdatethetransformationaccordingly:

Requirement3 (Resolve impactsautomatically):The impact of a changeonamodeltransformationshouldberesolvedautomatically,ifpossible.If an automatic resolution is not possible, themethod should provide suitablesuggestionsforamanualresolution:

Requirement4(Supportmanualresolution):Iftheautomaticresolutionoftheimpactofachangeisnotpossible,themethodshouldprovideadequateusersupportforthemanualresolutionoftheimpact.

ApplicationSupportThemethodandthesupportivetoolingshouldensurethatchanges are performed correctly. This means checking that all conditionsnecessary for a change type are met by the metamodel and the targetedelementsbeforethechangecanbeappliedandthatthemetamodelisinavalidstate afterwards. The conditions to be met can be expressed as pre-andpostconditions:

Requirement5(Ensureapplicabilityofchange):Themethodshouldsupplypre-and postconditions for each change type to ensure that the change isapplicableandthat themetamodel is inavalidstatestatebeforeandaftertheoperatorisapplied.

MDETechnologyandPrinciplesRiebischdefines six fundamentalprinciplesofsoftwareengineeringtomanagethecomplexityofsoftwaresystems.Theseare: Abstraction (‘Abstraktion’), Modularisation (‘Modularisierung’),Encapsulation (‘Kapselung’), Hierarchical Decomposition (‘HierarchischeDekomposition’),SeparationofConcerns,andConsistency(‘Einheitlichkeit’)[82,p.72-77].Themethodandthesupportivetoolingshouldgenerallyadheretothesedesignprinciplestobeuseful.Specifically,theuseofMDEmethodsand languages are seen to support the principles of Abstraction andConsistency. Furthermore, formalmethods and languages should be used todescribechangesandimpactresolutionstoimprovecorrectnessandtoavoidambiguityforboththemethodandsupportivetooling:

Requirement6 (Usestateof-the-artmodelling):Theevolutionarychangesand the impact resolutions should be described using stateof-the-art MDEmodellinglanguagesandmethods.

Tool Support Tool support for the method should be integrated with othertooling commonly used in developingmetamodels and transformations andfollowinteractionpatternsclosetothoseprovidedbytoolingforsimilartasks.For instance, refactorings are commonly applied by selecting a set of targetelementsorportionofsourcecodeandchoosingtherefactoringtobeappliedfromacontextmenu.Theapplicationisperformedthroughadialogcalleda‘wizard’whichprovidesapreviewoftheeffectoftherefactoring.Iftheuserissatisfiedwith thepredictedresult, therefactoringisexecuted immediatelyandalleffectstakeplace.(SeetherefactoringsupportprovidedbytheEclipseframework for the Java language [99] or that of the Elipse EMF Refactorplug-inforEMFmodels[97]forexamples).The application of coevolution changes should be performed in a similar

vein,ifpossiblebeintegratedintothetoolingcommonlyusedfordevelopmentand embedded in the general development process. This is expressed asRequirement7:

Requirement7(Integratewithcommontooling):Thetoolsupport forthemethod should integrate with common MDE tooling for metamodel andtransformationdevelopmentandfollowcommonusagepatterns.

Figure5.2.:Thethreegeneralphasesofcoevolution

5.4.Approach

This section introduces our operatorbased approach to describe changescommonly performed on metamodels and deriving impact calculation andresolutionstrategiesfordependentmodeltransformationsfromthese.Thedetailsbelow address the requirements above directly or support the development oftoolingtofulfiltherequirements.

Theapproachisstructuredaccordingtothreegeneralphases,asshowninFigure5.2:

Phase1:MetamodelAdaptationDuringthisphase,thesoftwarearchitectselectsthechangeoperatortobeperformedandthemetamodelelementstoperformthechangeon.Themetamodelisadaptedaccordingly.

Phase 2:Operator ImpactDetectionWhen the operator is applied, thesoftwarearchitectcanselectanumberoftransformationsthataredependenton the metamodel. The impact of the change is detected for eachtransformationandclassifiedaccordingtotheresolutionthatispossible.

Phase 3: Impact Resolution For each detected impact a resolution isperformedtorestoreconsistencyinthisphase.Theresolutionforanimpactis either executed automatically or the software architect is supported inperformingasemi-automaticresolution.

After the phases are complete, consistency of the MDS is restored and thesoftware architect can continue with other development activities or applyanotheroperator.

In thenextsections, theaspectsrelevant toeachphaseand therelevantdesigndecisions are discussed. Based on these, each phase is broken down into theindividualstepsnecessarytocompletethephase.Furthermore,thecontributionseach phase makes to fulfil the requirements described above are discussed.Finally,inSection5.8theoverallprocessispresented.

5.5.Phase1:MetamodelAdaptation

Thefirstphaseofthecoevolutionapproachisconcernedwithhowchangesareperformed.Our approachusesmetamodels for theoriginof changeoperationsand treats transformations as dependent artefacts that need to be updatedaccordingly.Thisdesigndecisionisdiscussedinthenextsection.Section5.5.2coverstheexpectedadvantagesforouruse-caseofanoperatorbasedapproach–as opposed to state recording approaches. In Section 5.5.3 the details of howoperatorsareusedaregiven.Finally,Section5.5.4containstheindividualstepsthatmakeupthefirstphase.

5.5.1.MetamodelsasthePrimaryArtefactsinCoEvolution

To provide a solution that supports the software engineer in handlingcoevolution,onemustdecidewhichofthedependentartefactsareprimaryandwhichare secondary, i.e. onwhich artefact types the change is performed andwhichartefacttypesareupdatedaccordingly.Formetamodelandtransformationcoevolution,eitherthemetamodelorthetransformationcouldbechosenastheprimary artefact type. Choosing the transformation as primary artefact entails

that the software architect performs changes to the transformation and thedependentmetamodels are updated accordingly to coevolve. In this work, wechoosethemetamodelasprimaryartefactinstead,fortwomainreasons:

MetamodelsarecentraltotheMDS.Themetamodel inwhichachangeoccursmaybeinvolvedinnumeroustransformations.Itmayalsobeusedon different sides of the same or different transformations, for examplewhentheoutputmodels(RHS)ofonetransformationbeusedasinputforanother (LHS).Wouldone start by changingone transformation and thenadapting themetamodel afterwards, this changewouldneed to be carriedover to tertiary dependent transformations. At this point the metamodelbecomes the origin of the change and the primary artefact to thecoevolutionproblemof that transformation.Therefore,metamodelsplayacentral role in anMDS so that they present a suitable choice as primaryartefact.

Coevolvingmodelsfrommetamodelsispossible.Therelatedworkonthecoevolution ofmetamodels andmodels (see Section 8.1) shows that it ispossible to coevolve models as secondary artefacts to metamodels usingoperators.Ifthechangeoperationsprovidedforbothmetamodelandmodeland metamodel and transformation coevolution are the same or similar,performingchangemayonlybenecessaryoncetoperformthecoevolutionofboth transformationsandmodels.Thismayreduce theoveralleffortofevolvingtheMDS.

For these reasonswechoosemetamodelsasprimaryartefactsand toadapt themodel transformations as secondary artefacts accordingly in our method. Thereverse approach of changing transformations and adapting dependentmetamodelsinsteadmayholdmeritnon-the-less.Itisconsideredaninterestingbutoutofscoperesearchtopicinthiswork.

5.5.2.ChangeTrackingforCoEvolution

Handlingtheevolutionofasoftwaresystemrequiresthetrackingofchangesthatoccur and representing them adequately. In the case ofMDE,with a focus ofmodelsasprimaryartefacts,a lotofchangeoccurs inmodelsandtheartefactsthataredependentonmodels.Asthetraditional,textbasedmethodsoftrackingand representing changedonot convertwell to graph-basedmodels [72], newmethodsfortheappropriatetrackingofmodelchangesareneededandhavebeen

proposedbydifferent researchers.Theseapproachescanbecategorised in twogeneral classes: state and change-based approaches, where operation-basedapproachareasubclassofchange-basedapproaches[54].

Staterecordingapproachesstorethestateofthemodelaftersomeamountof change occurred. The exact actions performed for the change may ormay not be reconstructible, depending on the chosen time span betweenrecordedstatesandtheatomicityandunambiguityoftheactionsperformed.

Change-based approaches record change while it occurs so that nocomparison of versions is needed as the versions can be constructed byapplying, or (if possible) reversing the recorded change. Operationbasedapproachesareasubclassofthese,astheyprovidepredefinedoperatorstoexpress thechange thatcanbeapplied toamodel toderiveanewmodelversion: operation-based approaches can provide primitive and complexfunctionsthat takeonemodelstateasinputandprovidethechangedstateasoutput[63].

Change-based and operatorbased approaches have been shown to haveadvantagesover state-basedapproaches ingeneral [54] and especially formetamodel and model coevolution [44, 107]. These advantages can beexpected toalsoapply formetamodeland transformationcoevolution, forthefollowingreasons:

Calculating model differences is hard. As Kolovos et al. state,determiningmodeldifferences isbasedonmodelmatching,whichcanbereduced to the graph isomorphism problem, which is NP-hard [55].Potentially,everymodelelementofoneversionneedstobecomparedwitheveryothermodelelementoftheothertodeterminethedifference.Ontheotherhand,recordingthechangewhileitoccursonlyrequirestheartefactsinvolvedinthechange.

Operators are unambiguous in effect. Calculating model differences issubject to heuristics, so that the quality of the solution depends on theintended application [55]. For instance, changing a large portion of theattributes of a class can be indistinguishable from deleting the class andcreatinganew,independentone.Theaccuracyofthematchingdependsonthe heuristic used and can not be ensured for all cases. When usingoperatorsinstead,theimpactofoneunitofchangeiseasiertopredictand

the exact parts of transformation descriptions that are impacted can becalculatedautomatically.

Operators are semantically rich.When using operators to predeterminethe possible impact, additional information besides the pure effect on themetamodelisavailableforcoevolutiontasks.Forinstance,anoperatorforpushing a property down along the inheritance hierarchy of classes (seeSection6.5foradescription)hasthesameeffectasdeletingandaddingtheproperty and is redundant when only considering the effect on themetamodel. But the additional knowledge that the property was pushedallows forabetter resolutionof the impactondependent transformations.(We use this additional knowledge in our proposed resolution of a pushpropertyoperatorasdescribedinSection7.7.)

Furthermore,operatorsprovideaddedbenefitforotherdevelopmenttasks,like reviews, traceabilityanddocumentation:by recordingevolutionstepsundertaken using operators, the nature, impact and source of changes totransformations aremade explicit. In thismanner,more knowledge abouttheevolutionaryhistoryofthesystemcanbemadeavailableforinstancetonewmembersofthesoftwareteam[54].

The disadvantage of specific tooling is lessened. One disadvantage ofrecordingchangeinsteadofcalculatingit is thespecific toolingneededtoperformtherecording(ortheapplicationofoperators)[40].Thismeansthatthe choice of modelling tools is limited and all participants of thedevelopment process need to agree on specific tooling. Yet, whenconsidering bothmetamodel and transformation development, specializedtooling is already widely used, as models are commonly created usinggraphical editors and textual transformation editors benefit from thefunctionalityofunderstandingmodelstoprovidecode-completionanderrorchecking capabilities. Therefore, the use of an integrated developmentinfrastructureforMDEiscommon[94].

Thechange-basedrepresentationandespeciallytheuseofoperatorstodescribeand apply change when performing a metamodel evolution can therefore beexpectedtoholdadvantagesoverstate-recordingapproachesandtorepresentaviableoptiontoaddressthemetamodelandtransformationcoevolutionproblem.

5.5.3.UsingOperators

We make use operators to describe a change that can be performed on ametamodel.Operatorsaredefinedasfollows:

Definition8(Operator):Anoperatorisamappingfromasetofmetamodelelementstoanothersetofmetamodelelements.Forthepurposeofcoevolution,the operator describes how metamodel elements are adapted to perform apredefinedtypeofchange.

Operators encapsulate the changes performed and provide an abstraction fromthe manipulation of individual metamodel elements. To fulfil Requirement 1,Supportcommonevolutionarychangesweproposeasetofoperatorscommonlyusedformetamodelevolution.Thesearedetailedinchapter6.

Wechose todefine theoperatorsusingQVT-Rtocomeascloseaspossible tofulfillingRequirement6,stateof-theartmodelling.WhilethesemanticsofQVT-R are not fully formalised, it iswell integratedwith theUML and as long asoverall formal semantics for the UML are still lacking (see Section 2.3.1),completeformalisationofoperatorsworkingonUML-basedmetamodelsisnotpossible.Yet thegraphical,declarativesyntaxprovidedbyQVT-RcanbeseenasadvantageousforboththedesignprinciplesConsistencyandAbstraction:theapplication patterns of the operators can be modelled in the same level ofabstraction as themetamodels they aredefined for and thegraphical syntax isconsistentwithgraphicalMOFmodels.

Furthermore, we chose to define the operators in chapter 6 for metamodelsconformingtoEMOF.EMOFalsoprovidesastrongformalbackgroundandcanbeconsideredtobewellestablishedinMDEaspartoftheUML.Furthermore,theEMFEcoreimplementationofEMOFfortheEclipseframeworkprovidesagoodfoundationfor theprototypical implementationandintegrationwithotherMDEtooling,toaddressRequirement7(Integratewithcommontooling).

5.5.4.TheMetamodelAdaptationPhase

Figure 5.3 shows the details of the steps performed in the first phase forselecting and applying an operator to perform ametamodel adaptation. Theseare:

Figure5.3.:Theindividualstepsofthemetamodeladaptationphase

1. selecttargetelements:Oneormoreelementsofthemetamodelarechosenbytheusertoperformachangeon.

2. select operator: The user chooses the operator to apply to the elementschoseninthefirststepfromasetofpredefinedoperators.

3. check preconditions: In this step, the applicability of the operator ischecked. One criterion is whether or not the chosen elements match theparameters required by the operator. Furthermore, operators may supplyfurther preconditions thatmust bemet to ensure that the operator can beapplied. Should any precondition fail, the overall process is terminated.ThisphasecontributestoRequirement5(Ensureapplicabilityofchange).

4. adaptmetamodel:Ifallpreconditionsaremet,theoperatorisappliedandtheselectedtargetelementsareadapted.

5. checkpostconditions:Afterthemetamodelischanged,thepostconditionsof the operator are checked. If all postconditions pass, the first phasecompletes.ThisphasealsocontributestoRequirement5.

6. revert-operator:Shouldanypostconditionfail,theoperatorisrevertedandthe metamodel returned to its original stage. At this point the overall

processisterminated.

5.6.Phase2:OperatorImpactDetection

Thesecondphaseoftheprocessisconcernedwiththedetectionoftheimpactofthechange thatwasperformed inphaseonebyapplying theoperator.For thispurpose,alltransformationsthataretobecoevolvedareselectedbythesoftwarearchitect. For these, the impact the operator has on the transformation rules isdetected,toallowtheresolutionoftheimpactinthelastphase.Whichpartsofatransformation rule are affectedby anoperator dependsonwhether or not themetamodel elements that are modified by the operator are relevant to thetransformationrulepart.Findingauseoftheseelementsinatransformationruleequatesdetectinganimpact.HowmetamodelelementsarereferredtoinATLisdiscussed in the next section. Section 5.6.3 summarizes the two steps thatconstitutethesecondphase.

5.6.1.DetectingOperatorImpactonATLRules

AmodeltransformationprogramwritteninATL(seeSection3.2)ismadeupofasetofrules,whereeachruleproducesoneormoretargetmodelelementsfroma source model element. The application of a rule is determined by a sourcepattern, defined in terms of a source metamodel. The created elements areconformanttoatargetmetamodel.ATLreliesonanadaptedversionoftheOCLtoperformmodelnavigationandtocalculatevaluesfortargetproperties.

ToanalysetheimpactofoperatorsontransformationrulesinATL,twofactorsneedtobetakenintoaccount:

Figure5.4.:TheATLsyntaxforamatchedrule

1. TransformationDirectionTheimpactdependsonwhethertheoperatorisused on a metamodel that is a source (LHS) or a target (RHS) of atransformation.Forexample,addinganobligatorypropertyontheLHSofthetransformationhasnoimpactonvalidity,whilethesamechangeontheRHSwillmake the transformation invalid,as it is impossible todeduceacorrectvalue for thegivenpropertyautomatically.Therefore, thepossibleimpacts for each metamodel change are different for LHS and RHSmetamodelsandrequiredifferentresolutions.

2. Locality The impact of an operator further depends on the part of atransformation rule that theelementsaffectedby theoperatorareused in.Weidentifiedthefollowingrelevantruleparts:

Changescanoccurinthedomaindefinitionin-patternofarule(LHSmetamodel),

the filter condition constraints of the in-pattern (LHS metamodel),and

the binding assignment in out-patterns for both LHS and RHSmetamodels.

Figure5.4 shows an informal excerpt of the syntax of anATLMatchedRule,taken from the ATL Language Guide [90]. Metamodel changes due to anoperatorcanimpactthefollowingpartsofanATLruleontheLHS:

The in-pattern , filter condition constraints imposed on the in-patternelement (expressed inOCL),and thevalue calculation forproperties in thebindingassignment,alsoexpressedinOCL.ChangestotheRHSarepotentiallyreflectedin: the targetpattern(eachrulecanhavenumerous targetpatterns)andthe propertiestowhichvaluesareassignedinthevaluebinding.

OCLplaysanimportantroleinATLrules.Itisusedfortwopurposes:toexpressconstraints in filter conditions on the applicability of rules and to calculatevalues in thepropertybindingassignment. Inbothcases,OCLstatementsmaynavigate over models and can potentially involve any part of the LHSmetamodel.Thiscanleadtoverycomplexsourcepatternsforcomplexrules.Todetect the impact of an operator on an ATL transformation requires theincorporationofOCLexpressions.Also,adaptingtheOCLexpressionsthatarepartofatransformationmayprovidebetterimpactresolution.TheroleofOCLisdiscussedinmoredetailinthenextsection.

5.6.2.TheOCLandMetamodelEvolution

OCL plays a central role in transformation languages in the UML / MOFtechnological space, including ATL. This section covers the impact ofmetamodel evolution on OCL expressions in more detail. We provide ourfindings on which impacts can be detected for which OCL language featuresusingstaticanalysisandwhichcannot.Wedefinehowdetectedimpactscanberesolvedandprovideasetofimpactsthatcannotberesolvedautomatically.

Both ATL and QVT use OCL for model navigation, the selection of modelelements and the calculation of values. ATL uses its own variation of OCL,whichdoesnotconformto thestandardand isnotcomplete.ThesemanticsoftheOCL expressions ofATL are only loosely defined. [5, p. 15]QVTon the

otherhandusestheessentialOCLaccordingtotheOMGstandardforOCL2.0[73,p.11].

ThesemanticsoftheOMGOCLversion2.0arenotfullyformalised[18].Ithasto thereforebenotedthat thecorrectnessofaresolutionstrategyforanimpactmaynot beproven completely anddependsultimatelyon the interpretationoftheunderlyingtransformationengine.

RefactoringOCLExpressions

The coupling between OCL expressions and UMLmodels and the impact ofrefactoringUMLmodels on linkedOCL expressions has been investigated byother researchers. Cabot and Teniente for example propose techniques for thegenerationof semantically equivalent syntactic alternativesofOCLconstraints[20]andMarkovićandBaarpublishedasetofoperatorsforthecoevolutionofmodelsandOCLexpressions[65](alsoseeSection8.2).

Yet,whencomparingthecoevolutionofOCLexpressionsandmodelswiththatofOCLexpressionsandtransformations,threegeneraldifferencescanbenoted,whichmaketransferringtheresultsdifficult:

Evolution (and refactoring) has to cover whole transformations. Inotherwords, the transformationstructure, therule inheritanceandtheruleselectionmechanismshavetobeconsideredalongwithOCLexpressionsinthetransformationtoproperlyaddressevolutionimpact.

Transformation languages only use a subset of OCL. As OCLexpressions are used only for model navigation, element selection andcalculationofprimitivevaluesintransformations,onlyasubsetofthefullOCLisusedbytransformationlanguageimplementations.Therefore,OCLlanguage features may not be available or resolution strategies notnecessarythatareneededwhenhandlingmodelsandexpressions.

OCLusedforconstraintsonmodels in itself isadifferentapplicationdomain.OCL constraints defined on (UML)models relate to themodelsthemselves.OCL as it is used for navigation in transformation languagesrelates insteadmainly to themetamodels and sometimes to the primitivevaluesofattributesofmodel instances.Theapplicationcasesaredifferentsothatdifferentresolutionstrategiesareneeded.

ItcanbenotedinsummarythatwhiletheworkonOCLandmodelcoevolutionor refactoring provides good approaches for some cases, the problem is bothbroader and different so that taking only resolution strategies for OCL intoaccountcanbeexpectedtofallshort.

ImpactonEmbeddedOCLExpressions

To assess the impact of metamodel changes on the OCL expressions used intransformations, the types of possible links betweenmetamodels andOCLareimportant. In this section, we first look at howmodel element references areresolved by the OMG OCL standard definition. In preparation of the impactresolution for theATL language,we compare this to theOCL implementationfoundinATLandhighlightthedifferences.

TheOMGOCLstandarddefineswhichpartsofaUMLmodelcanbereferredtoinanOCLexpressioningeneral:

‘OCL expressions can refer to Classifiers, e.g., types, classes,interfaces, associations (acting as types), and datatypes. Also allattributes, associationends, methods, and operations without sideeffectsthataredefinedonthesetypes,etc.canbeused.’[74,p.16]

OCLisastronglytypedlanguage.AllOCLexpressionshavearesult typeandall variables in all places of an expression are typed.AsOCLexpressions arealwayswritten in a context, available types are either the basic and collectiontypesdefinedbyOCLorstemfromtheclassifiersoftheassociatedUMLmodel.[74,p.11]

TheOCLguidesuggeststhefollowingapproachtoresolveboundproperties[74,p. 50]: Properties are always associated with an object at any place in anexpression.Theselfvariableanditerator-variablesincollectionscanbeleftoutandareintroducedimplicitly.Thismakesthebindingprocessdependentonthecontext in which a part of an expression is evaluated. If a property is usedwithoutanexplicitvariable,itisinterpretedonanimplicitvariable.Ifmorethanonevariableisavailableinthecurrentexpressionscopeandtheusedpropertyisdefined formore thanoneobjectof thevariablesavailable, thevariableof themost inner scope is chosen. This means that variable binding and propertyevaluationcanbeambiguousandtheresolutionprocesshastobeundertakeninthecontextoftheentireexpression.

Thevalueofapropertyofanobjectinthecontextofaclassifierisspecifiedwiththeinfixnavigationoperator(’.’)inanOCLexpression.Forexample:

Operationsmaybeprovidedwithparameters,giveninbrackets.Associationendsarenavigatedusingthedotnotation,providingaccesstorelatedobjectsandtheirpropertyvalues:

In thecaseofATL, thecontext forOCLexpressions in transformationrules isprovided by the PatternElements which inherit fromocl:VariableDeclarationorbydirectvariabledeclarationsthatspanthescopeoftherule(seeFigure3.2).TheInPatternElementsprovidevariablesforLHSmodelelements,whileOutPatternElementsarevariablesthatcontainelementsof theRHSmodel.OCLexpressions are featured in the formof theBinding,which refers to an OCL expression to calculate the value of a target modelproperty.Inthiscasetheselfcontextoftheexpressionisthepropertythevalueis assigned to. The properties that are valid in this scope are allPatternElementsandthedeclaredrulevariables.TheothercaseofexpressionusagearefilterexpressionsofInPatternswhichareinterpretedinthecontextoftheInPatternElementthattheyarerelatedto.

The navigation of models is expressed in the OCL variant of ATL by aNavigationOrAttributeCallExp which uses the infix navigation operatormentionedabovetocallpropertiesortonavigateacrossassociationends.

OCLReflection

One problem in determining the impact of metamodel changes are the OCLlanguagemechanisms for reflection. The allInstances() operator allows thecollectionofallavailable instances inanexpressionofa typewhich isnot thecontext.Thismakes itpossible toestablish‘relationships’betweenclasses inarule and at runtime that were not intended in the originalmetamodel. As theOCL reflective operators are only evaluated at runtime, the static analysis for

changeimpactisdifficultandcanbeimpossible,dependingonthecase.Forthisreason, the usage should be discouraged, as many explicit mechanisms oftransformationlanguagescanbecircumventedinthismanner.

Figure5.5.:Theindividualstepsoftheimpactdetectionphase

5.6.3.TheImpactDetectionPhase

Phasetwoperformsthedetectionoftheimpactofthechangethatwasperformedinphaseonebyapplyingtheoperator.Forthispurpose,all transformationsareselectedbythesoftwarearchitectthataretobecoevolved.Thisisnecessary,asmetamodelscanbeusedinanynumberof transformationsandnoexplicit linkbetweenmetamodelsand transformationprograms thatuse themexist inATL;themetamodeltoworkwithisonlyselectedatruntime,priortoexecutionofthetransformation. Then the impact detection for the selected transformation isperformed.Thedetectedimpactsarethenresolvedinthesubsequentthirdphase.Therefore,thetwostepsthatmakeupthesecondphase,asshowninFigure5.5,are:

1. select transformations: The transformations to be coevolved with themetamodelareselectedbythesoftwarearchitect.

2. detectimpacts:Fortheselectedtransformations,theimpactofthechangesisdetected.

The next section covers the third phase, in which the detected impacts areresolved.

5.7.Phase3:ImpactResolution

One or more impacts of applying an operator on one or more ATLtransformation ruleswasdetected in thepreviousphase. In this thirdphaseofourapproach,theseimpactsareattemptedtoberesolved.Theresolutionmayormaynotbeautomated,dependingontheoperatorandtheusageoftheelementsmodifiedbytheoperatorinthedependenttransformationrules.

The next section discusses possible approaches to classifying operatorsaccordingtotheirimpact.

5.7.1.OperatorClassification

The changes performed on a metamodel in coevolution can be classifiedaccordingtotheimpact theyhaveondependentartefacts.Thisclassificationisusefulfromapracticalstandpoint,becauseitallowsthepredictionoftheeffortneeded to resolve the impactof thechange,before thechange isperformed. Itmaybe‘safe’toapplyanoperatorbecauseithasnoimpactatallondependentartefactsortheimpactmaybeautomaticallyresolvableortheusermayneedtoperformamanualresolutionoftheimpact.

Gruschkoetal. identifiedthreeclassesofmetamodelchangeaccordingtotheireffectonconformantmodels[40]:

Not Breaking Changes in this class do not break the conformance ofmodels to the corresponding metamodel, they have no impact on thevalidityofthedependentmodels.

BreakingandResolvableThesechangesbreaktheconformanceofmodelsbutthemodelscanbeadaptedautomaticallytorestoretheirvalidity.

BreakingandUnresolvableChanges in thisclassbreak theconformanceofmodelssothatmodelscannotbeautomaticallycoevolved.Theyrequirefurtheruseractivitytore-establishmodelconformance.

Buildingontheseclassifications,Cicchettietal. identifyasetofoperationsonmetamodelsandcategorisethemaccordingtheirchangeclass,againwithrespectto the conformance ofmodels [23], see Table 5.1. For instance, the operationflattenhierarchyreferstothechangeofeliminatingasuperclassandmovingallits properties to the remaining subclasses. This is a breaking change, as oldmodels no longer conform to the new metamodel, but it can be resolved, asinstancesofthemissingclasscanberemovedfromthemodelandallpropertiesandvaluescopiedtothecorrespondingsubclassinstances.

Changeclass Operation

Non-breakingchanges Generalizemetaproperty

Add(non-obligatory)metaclass

Add(non-obligatory)metaproperty

Breakingandresolvablechanges Extract(abstract)superclass

Eliminatemetaclass

Eliminatemetaproperty

Pushmetaproperty

Flattenhierarchy

Renamemetaelement

Movemetaproperty

Extract/inlinemetaclass

Breakingandunresolvablechanges Addobligatorymetaclass

Addobligatorymetaproperty

Pullmetaproperty

Restrictmetaproperty

Extract(non-abstract)superclassTable5.1.:Metamodelchangeclassificationaccordingtotheimpactonconformingmodelsaccordingto

Cicchettietal.[23]

But Cicchetti et al. argue further that metamodel changes commonly occurneither individually nor independently asmodifications ofmetamodels tend tooccur with arbitrary multiplicity and complexity [22]. This makes a cleardistinctionofchangetypesdifficultandlessusefulinpractice.

Unfortunately,theclassificationaccordingtothebreakingnatureofchangecannotbecarriedovereasilyfrommetamodelandmodelcoevolutiontometamodeland transformationcoevolution.While the impactofanadditivechangeof themetamodeliseasilydeterminedforconformantmodels,asconformancereferstothemodel as awhole, it is different formodel transformations, as applicationpatterns in transformation rules usually only refer to some part of theirmetamodel.Forexample,ifanewpropertyisaddedtoaclass,itcanbesettobeeitherobligatoryornot.Fordependentmodels,ifitisnotmandatory,themodelsremain syntactically conformant and the user has to decide if the attribute is

semantically required for some instances. If the attribute is mandatory, thechangeisalwaysbreakingandmostlikelyunresolvable(bardefaultvalues).Fortransformations, evenan addedmandatorypropertydoesnot imply abreakingchange,as the transformationwill remainsyntacticallyvalidanditdependsonthe intended function of the transformation if the given change requiresadaptation.

Furthermore,whether or not a transformation can be adapted automatically inresponse to the use of an operator depends on how the elements that aremodifiedbytheoperatorareusedinthetransformation,asdiscussedinSection5.6.1.Thesameoperatormayleadtoaresolvableimpactinonetransformationrule and a non-resolvable one in another. In conclusion, operators can not beclassified in isolation when looking at the impact on transformations. Wepropose the classification of the different impact resolutions instead. ThisapproachisdiscussedinSection5.7.4.

5.7.2.ImpactResolution:SyntaxandSemanticPreservation

Marković and Baar distinguish between syntax and semantics preservingrefactoringrulesforthecoevolutionofUML1.5classdiagramsanddependentOCL constraints [65] and illustrate the semantics preserving property of theMoveAttributerule[7].Aruleissyntaxpreserving,if

‘foreverysyntacticallycorrectsourcemodeltheobtainedtargetmodelis syntactically correct as well. Syntactically correct models areexactly thevalid instancesof themetamodel,whatboilsdownto thefollowingthreecriteria:(1)allmodelelementsarewell-typed,(2)allmultiplicityconstraintsaremet,and(3)allwell-formednessrulesareobeyed.’[65]

Whether or not a rule is syntax preserving has to be shown for every validmetamodelthatservesasinput.

The semantic preservation property of a refactoring rule ensures that thesemantics of the model coincide before and after the application of the rule.Opdykedefinesthisasbehaviouralpreservationsothat

‘...ifthefunctionmain[theprogram]iscalledtwice(oncebeforeandonceafterarefactoring)withthesamesetofinputs,theresultingsetof

outputvalueswillbethesame’[80,p.40].

The lack of formal semantics of the common modelling languages poses ahindrancetodefiningcriteriaforsemanticpreservationwhichexplainsthelackofprooftechniquesforsemanticpreservation[7].Thesamecanbeexpectedforthecoevolutionofmetamodelsandtransformations,fortwomainreasons:

BothATLandQVTarebasedonMOFandmakeuseofOCLinternally,sothatthelackofformalsemanticsisascritical.Furthermore, thesemanticsofQVTandATLarealsonotfullyformalised(seesections3.3.1and3.2.2)sothatevenifthesemanticsforthemetamodelevolutioncanbeproved,theresolution strategy may still not be provable for the transformationlanguagesinvolved.

The application of an evolutionary operator is not meant to result in asemantically equivalentmodelbut rather in a semantically correct changeof themodel inaccordancewith the semanticsof theoperator.Therefore,thesemanticsoftheoperatorneedtobetakenintoaccount.

In conclusion this means that the syntactical preservation of evolutionaryoperators for ATL can be shown by showing that all three criteria for modelconformancearegivenforallinputmetamodels.Semanticcorrectnessinsteadisveryhardtoprove,withoutfullyformalisingallinvolvedlanguages.Whetherornotanoperatorperformsasintendedislefttotheuser,whoneedstochecktheresultandadaptitasneeded.

5.7.3.ImpactandResolutionDefinition

Chapter7introducesanumberofimpactresolutionsfortheoperatorsdefinedinchapter 6. For each operator, we discuss the possible impacts on ATLtransformation rules and provide resolutions to restore the consistency of thetransformationinvolved.Toremaininlinewiththeoperatordefinitions,wealsouse QVT-R to define the impact resolutions available for each operator. TheimpactandimpactresolutionforATLaredefinedonthebasisoftheATLASTmodel.Ifanautomaticresolutionoftheoperatorispossible,theASTisadaptedaccording to the resolution. In a tool implementation, the software architectshould be providedwith an overview of the suggested impact resolutions andaccept or reject these individually. The nature of the different impacts isclassifiedinthenextsection.

5.7.4.ClassifyingImpact

Insteadofclassifyingtheoverallimpactofoperatorsaccordingtotheirbreakingorresolvablenature–aspossibleformetamodelandmodelcoevolutionbutnotfor metamodel and transformation coevolution – we need to take the manydifferentkindsof impactanoperatorcanhavedependingonhow thechangedmetamodel elements are used in subject transformations into account. In otherwords, thesameoperatorcanbeautomaticallyresolvableornot,dependingonhow a dependent transformation program is build. Therefore, we define thedifferentimpactspossibleforeachoperatoronATLtransformationsinchapter7andclassifythemaccordingtotheresolutionpossible.Theclassesare:

Figure5.6.:TheIndividualStepsoftheImpactResolutionPhase

none:Themodelelementsthataremodifiedbytheoperatorareusedinatransformation rule,butnochange to the rule isneededas it continues tofunctionasbefore.

automatic: A resolution strategy for the impact is available that can beexecutedautomatically.

warn:An automatic resolution strategy for the impact is available, but itmay not have the effect intended by the software architect. After theresolution, themodel transformation is syntactically correct, however, thesoftwarearchitectmayneedtoperformfurthermanualadaptation.

humanintervention:Noautomaticresolutionstrategyisavailableandthesoftware architect needs to perform a manual adaptation of the modeltransformationruletoresolvetheimpact.

Table7.1onpage136provides anoverviewof the impactdefinitions and theresolutionstrategiespossiblefortheoperatorsdefinedinchapter6.

5.7.5.TheImpactResolutionProcessPhase

The third phase of the approach is structured as shown in Figure 5.6. It isperformedforeachdetectedimpact.Theindividualstepsare:

1. calculateresolution:Foreachimpact,aresolutioniscalculated.

2. warn:Iftheresolutionmayhaveunintendedconsequences,warntheuser.

3. requestintervention:Iftheresolutioncannotbeperformedautomatically,the user needs to provide further information or resolve the impactmanually.

4. resolve impact: If an automatic resolution is possible or the user hasprovidedenoughinformationfortheresolution,theresolutionisperformedandthetransformationisupdatedaccordingly.

5.8.TheOverallCoEvolutionProcess

Figure5.7.:Approach

Theoverall stepsof all threephasesofour approachare shown inFigure5.7.Theapproachisstepwiseandoperatorbasedandsupportssoftwarearchitectsinthe coevolution ofmetamodels andATLmodel transformations.The approachusesoperatorstodefineunitsofchangethatarecommonlymadetometamodels.Thesoftwarearchitectselectsanoperatorandchoosesoneormoremetamodelelementstoapplytheoperatorto,toperformoneevolutionstep.Theoperatorsmaycontainoneormorepreconditionsthatguidetheapplicationtoensurethattheselectedmetamodelelementsareinastateforwhichtheoperatorisintendedandensurethattheresultisvalid.Thepreconditionsarecheckedand,shouldthevalidationpass, theinputmetamodelismanipulatedautomaticallyaccordingtotheoperatorandanevolvedmetamodelisproducedasresult.

Toassistintheevolutionofmodeltransformations,theoperatorandthechangesmadetothemetamodelareusedtocalculatetheimpactonanarbitrarynumberofdependentmodel transformations.Themodel transformations tobecheckedare selected by the software architect. The impact detection stage performs astaticanalysisofthemodeltransformationstodetectATLrulesorrulepartsthatmay be impacted by the change made to the metamodel. For each impact, a

resolution is calculated.The resolutionsarecategorisedaccording tohow theycan be performed, either automatically, with a warning or with humanintervention.Theresolutionsareperformedandthetransformationsareupdatedaccordingly.

The next chapter introduces a set of operators for common evolution tasks tosupportourapproach. Inchapter7, the impact and resolutionof eachoperatorfordifferentpartsofanATLtransformationarediscussed.Chapter9providesanevaluation scenario and chapter 10 covers the prototypical implementation oftoolsupportpossibleforourapproach.

CHAPTER6

OperatorsforEMOFMetamodelEvolution

This chapter introduces a set of operators for the evolution of EMF-basedmetamodels.Theoperatorsstemfromdifferentsourcesandareformalisedusingthe graphical notation for QVT-R.Most operators stem from relatedwork onmetamodelandmodelco-evolution(seeSection8.1)orcoadaptationofmodelsand OCL constraints (Section 8.2) or general model or OO refactoring work(Section4.2). Some of the operators are available in aQVT-R-like syntax forMOForUML1.5and2.0inthesources.AsbothUMLMOFarecloselyrelatedtoEMOF,webuildupontheexistingformalisationstoadaptthemtoEMOF,or(insomecases)tomakethembettersuitedfortransformationco-evolution.

The operators are grouped in topical section. For each operator,we provide aformalisationusingthegraphicalnotationforQVT-R.Insomecases,operatorshave an oppositewith an opposite effect (such as addition and removal of anelement)andcanbeformalisedbythesamerelation;byinterpretingtherelationintheoppositedirection.Thisisnotedinthedescriptionwhereappropriate.WefurtherlisttheOCLpre-andpostconditionsrelevantforeachexecutiondirection.Theseensurethattheoperatorcanbeappliedasintendedandthatthemetamodelresulting from executing the operator remains valid (we assume that the inputmetamodelisvalid).

6.1.OntheUsageoftheQVT-RGraphicalNotationforOperatorDefinition

TheoperatorspresentedinthischapterareexpressedusingtheQVT-Rgraphicalnotation as described in Section 3.3.4. One assumption concerningbidirectionalitywasmade,astheQVTstandardisopentointerpretationinthismatter.We also defined some black-box operations tomake the relations lessverbose.Thesearedescribednext.

We base themetamodels on EMOF and alsomake occasional use of EMOF-functions,likemembersAreDistinguishable()orisEmpty().ThesearedefinedbytheEMOFstandardasdescribedinSection2.3.2.

6.1.1.Black-BoxOperationscreate()andcreateX()

We abstract from the creation of elements from simple values bymeans of ablack-boxoperationintheQVTrelationstomaketherelationsmoreconciseandhideverbosevalueparsing.Otherwise,therelationswhichcreatenewelementswouldneedsimpledomains foreachparameterofanelement.As thecreationrelationsforelementsareusedinotherrelations,theseparameterswouldhavetobe passed on, forcing these relations to again have simple domains for allparameters of all elements they create, distracting from the purpose of theoperator and making relations unnecessarily verbose. To circumvent this, wepropose the introduction of a create() black-box operation, which handles theprovisioningofvaluesforthesimpleattributesofnewelements(likethename).

It is assumed that the create() operation returns a complete and configuredelement. In an implementation of the operation, this could be achieved byproviding a dialog to the userwhen a new element is created for all requiredsimplevalues.Afterthedialogcompletes,thenewelementexistsbutisnotyetownedbyanelementofthemodel(itisnot‘inserted’intothemodel).Usageofthecreate()operationonitsownwouldleavetheresultingmodel inaninvalidstate, as the created element has no owner and other constraintsmay also beviolated. Yet this is permissible, as it is always used in conjunction with acorresponding addElement relation, in which the new element is added to anowningmodelelementandallpre-andpostconditionsneededforavalidadditionarecheckedand,ifmet,themodelisinavalidstate.

Tofurther improve the readabilityof the relations,weassume thatacreate()operationisavailableforeachtypeintheformcreateX()whereXis thetypename.ThecreateoperationforclassesiscalledcreateClass()forinstance.

6.1.2.Black-BoxOperations:clone()andcloneDiscName()

Similar to the create() operation described above, a clone() operation isassumed to provide the functionality to create a copy of an element withoutadding it to the model. The cloned element can then be added to an owning

elementbytherelationthatcallstheclone()operation.Incheckingmode,theclone()operationcanbeseentoverifythatanelementisthecloneofanotherinall features but the owner, evaluating to either true or false. ThecloneDiscName()operation(‘clonediscountingname’)clonestheelementinallregardsbuttheownerandthename,i.e.elementswithadifferentownerandadifferentnamematchinaqueryandacloneiscreatedwithaname-promptfortheusertosupplyanewnameduringexecution.

6.1.3.BidirectionalExecutionandModelCandidates

AsQVTrelationsarepotentiallybi-ormulti-directional (duringexecution,onecandidatemodelischosentobemodifiedindependenceoftheothermodel(s)),the execution direction needs to be defined for the correct semantics of therelationinquestion.Ingeneral,therelationsusedherearedefinedtobeexecuted‘fromlefttoright’,i.e.frommodel‘l’tomodel‘r’.Thereverseisonlymeanttobe useful if explicitly stated. This is the case for all Add/Remove relations,wherethedirection‘l’to’r’addselementsand‘r’to‘l’hastheoppositeeffectand removes elements. When relations call subrelations, the subrelations areexecutedaccordingtothemembershipoftheparameterspassed:ifthevariablebelongstothe‘l’-modelintheparentrelation,itisexpectedtoalsobelongtothe‘l’-model in thesubrelation.Theexecutiondirection is then inherited fromtheparent;‘l’-to-‘r’or‘r’-to-‘l’forallrelations.

Ifthesamemodelischosenforbothcandidatemodels,therelationsarein-placetransformations, with the expected effect of providing an evolution step on asingle (meta-)model. Another possible application is the comparison of twoversionsofthesamemodeltofindtheevolutionthatmayhaveoccurred.Herethe two model versions are chosen as the left and right candidates and therelationsareexecuted incheckingmode, toverify that the twomodelversionsarerelatedbythegivenrelation.

6.2.OperatorOverview

The set of 30 operators and their sources are summarised in Table 6.1. ThesourcesoftheoperatorsaretheworkbyWachsmuth[107],whoproposedasetof16operator-likeadaptationsfortheco-evolutionofmetamodelsandmodels,MarkovićandBarr[65],with15rulesfortheco-evolutionofclassdiagramsandOCLconstraintsandHassametal.[42],with7operationsformetamodelsand

OCLconstraints.Wecover theoperatorsand their formalisationhere,how theapproachespresentedintherelatedworkcomparetoourapproachisdiscussedinchapter8.

Someofouroperatorsarenotcoveredbyanyofthesources(seeTable6.1). InthecaseofAdd/RemoveElementoperators,theyareaddedtoprovideoperatorsfor the addition and removal of all elements of the EMOF metamodel, asdetailed inSection6.3. In thecategoryPropertyManipulation,we addedpushand pull operators for complex properties which were not found elsewhere.Finally,weaddedtheoperatorIntroduceCompositePatternasanexampleofacomplexrefactoringpatternfromFowler[34].

Table6.1.:OverviewoftheoperatorsforEMOFmetamodelevolution

The set of operators defined in the next Section 6.3 covers the addition orremovalofelementstoorfrommodelsforallEMOFtypes.Pleasenotethattheelementcreationisnotcoveredbythegivenrelations,astheprimitivevaluesofattributesarenot includedasprimitivedomains.The relationsonlysummarize

the pre-and postconditions that need to hold for the addition or removal ofelementsofeachtypeandoutlinethesituationbeforeadditionorafterremoval.Relations for the creation and addition of elements (‘introduction’) would bevery verbose and not really helpful, as they only map primitive domains(‘relation parameters’) to the primitive attributes of the types in question.Instead, we make use of the create() operations described above wherenecessaryandcovertheadditionandremovalofelementsbytheoperatorsinthenextsection.

6.3.Add/RemoveElement

Anelementisaddedtoorremovedfromthemodel.ThiscanbeanyinstanceofsubclassesofElement,suchascomments,types,classesbutalsoattributesandassociations in EMOF. Besides behaving in a way expected by the user andmakingnofurtherchangestoanexistingmodel,theoperatormustadheretothestructural requirements and all constraints placed on the added elements byEMOF. For example, EMOFdefines a constraint forElement that no elementmay own itself - neither directly nor transitively: not

self.allOwnedElements()->includes(self)[76,p.75].Thisconstraint

is relevant when adding a new Package and is covered by the more generalconstraint that a package added by the Add Package operator is completelyempty.

EMOFdefinesthefollowingsubclassesofElement(seealsoSection2.3.2)thatare non-abstract and available to be used in models. We define generalconstraintsforaddingorremovingelementsinSection6.3.1andthespecificsofeachelementasfollows:

Class and Package are handled by their respective Add and Removeoperators(seepp.102ff.)

DataType, PrimitiveType and Enumeration are handled by the AddDataTypeandRemoveDataTypeoperators(seesections6.3.6and6.3.7).

EnumerationLiteral ishandledby theAddEnumerationLiteral (Section6.3.8)andRemoveEnumerationLiteral(Section6.3.9)operators.

Property,and Association are handled by their respective Add and

Removeoperators(seepp.107ff.)

OperationantheirParametersareadded toandremovedfromclassesordatatypesusingtheAddOperation/RemoveOperationoperators(sections6.3.14and6.3.15).

Generalisations are introduced between two classes or removed fromthem. This is done using the Introduce Generalisation / RemoveGeneralisationoperators(sections6.3.16and6.3.17).

The subclasses of the abstract class ValueSpecification define constantvalues for simple types (like Integer or String) or a chosenEnumerationLiteral value.Thesebelong to their respectiveowners (likepropertieswithconstantordefaultvalues)andareaddedandremovedwiththem,eliminatingtheneedforseparateoperators.TheseareInstanceValuefor enumeration literals and LiteralBoolean, LiteralInteger,

LiteralNull, LiteralReal, LiteralString andLiteralUnlimitedNaturalforsimpletypes.

CommentsareusedinEMOFforhuman-readableannotationsonlyandhavenoenforced semantics.Thereforenooperator isprovided for theadditionand removal of comments. To maintain the structural validity of modelshowever, a general constraint is given that no element can be removedwhileitstillownsacomment(seethenextsection).

TheseoperatorscoverthecreationandremovalofallelementsthatareavailableforuseinmetamodelsinEMOF.

6.3.1.GeneralConstraints

Two conditions need to be checked for the correct removal of any element.Thesearedefinedbythefollowingconstraints.

All elements inEMOF can be annotated by a human readable comment.ThiscommentisstoredintheCommentelement,whichcanbeownedbyanysubclassof Element and point to the annotated subclass of Element viaComment.annotatedElement. For the removal of elements, we defineconstraintstopreventanycommentpointingtoaremovedelementoraremovedelementowningacomment:

Figure6.1.:TheAdd/RemoveClassrelation

PreconditionsfortheRemove-operatorsofallelements:

–e.ownedComment->isEmpty():theElemente toberemovedhasnoattachedcomments.e removedhasnoattachedcommentse removedhasnoattachedcomments

– context Comment pre: self.annotatedElement -> excludes(e):noCommentcannotatestheElementetoberemoved.

ThesubclassesofClassifiercanredefineotherclassifiers.Whenaclassifierisremovedfromamodel,any redefiningclassifiercouldbecome invalid.This ispreventedbytheconstraint:

PreconditionsfortheRemove-operatorsofanyclassifier:

– context Classifier pre: self.redefinedClassifier ->

excludes(c):noclassifierc2isaredefinitionoftheclassifierctoberemoved.

6.3.2.AddClass

Anemptyclassisaddedtoanexistingpackage.TherelationAddClassisgiveninFigure6.1inthedirectionleft-to-right.

Preconditions:

–p.ownedType->excludes(c):noClasscexistsinPackagep.

Postconditions:

–p.membersAreDistinguishable():allmembersof thegivenPackagep(withtheaddedClassc)areuniqueintheirnamespace.

6.3.3.RemoveClass

Aclassisremovedfromapackage.Theclassisexpectedtobeempty,nottobepart of a generalisation (inheritance) relationship or otherwise be used in themodel.Aclasscanbeputinthisstatebyusingotheroperatorsfirst,forexampleby removing all properties from the classwith theRemove Property operator.TherelationRemoveClassisgiveninFigure6.1inthedirectionright-to-left.

Preconditions:

–c.ownedMember->isEmpty(): theclass toberemovedhasnootherattachedelementslikeattributesoroperations.

–{not}:Class: the class to be removed is not superclass of any otherclass.

–{not}:TypedElement: the class tobe removed isnot the typeof anyremaining typed element, which are parameters, properties andinstancevalues.Furthermore,nooperationcanbetypedbytheclasstoberemoved,asthetypeofanoperationisderiveddirectlybythetypeofthereturnparameter,whichiscoveredbythisconstraint.

–{not}:Operation:theclasstoberemovedisnotanexceptionraisedbyanyoperation.

Postconditions:

–p.ownedType->excludes(c):theremovedclasscnolongerexistsinpackagep.

6.3.4.AddPackage

Anemptypackageisadded,possiblytoanowningparentpackage.Thevalueofthe parent package variable parent may have a value of null to denote theadditionasarootpackage.TherelationAddPackage isgiven inFigure6.2 inthedirectionleft-to-right.

Figure6.2.:TheAdd/RemovePackagerelation

Preconditions:

–parent.nestedPackage->excludes(p):theparentpackagedoesnotownapackagep.

Postconditions:

–parent.membersAreDistinguishable(): allmembers of the packageparentareuniqueintheirnamespaceaftertheadditionofpackagep.

6.3.5.RemovePackage

An empty package is removed, possibly from an owning parent package. Incaseswherepackageswithcontentaretobedeleted,thedeletionofthecontentelementsshouldbeundertakenfirstandthentheemptypackagecanbedeleted.TherelationRemovePackageisgiveninFigure6.2inthedirectionright-to-left.

Preconditions:

–p.packagedElement->isEmpty():thepackageptoberemovedhasnocontent.

Postconditions:

–parent.nestedPackage->excludes(p): the removedpackagepnolongerexistsintheowningparentpackage.

Figure6.3.:TheAdd/RemoveDataTyperelation

6.3.6.AddDataType,PrimitiveType,Enumeration

Adata type, primitive type or enumeration is added to an owning packagep.PrimitivetypesinEMOFarerepresentedbythePrimitiveTypeclass,whichisasubclass of DataType and which introduces no additional features, and canthereforebehandledbythesamerelationasDataType.TheEnumerationclassextendsDataTypebytheownedLiteralassociation,whichholdsanorderedsetofliterals.Itsub-setstheownedMemberassociationandiscoveredbyconstraintson ownedMember. The relation Add DataType is given in Figure 6.3 in thedirectionleft-to-right.

Preconditions:

– p.ownedType -> excludes(t): no data type t exists in the parentpackagep.

Postconditions:

– p.membersAreDistinguishable(): all members of the given parentpackagep(withtheaddeddatatype)areuniqueintheirnamespace.

6.3.7.RemoveDataType,PrimitiveType,Enumeration

Adatatype,primitivetypeorenumerationisremovedfromanowningpackagep.TherelationRemoveDataTypeisgiveninFigure6.3inthedirectionright-to-left.

Figure6.4.:TheAdd/RemoveEnumerationLiteralrelation

Preconditions:

– t.ownedMember -> isEmpty(): the data type to be removed has noattachedelementslikeattributes,operationsorenumerationliterals.

–{not}:TypedElement: thedata type tobe removed isnot the typeofany typed element, like parameter or property. Furthermore, thisconstraintprevents thatany remainingoperation is typedby thedatatype to be removed, as the type attribute of an operation is derivedfromthetypeofthereturnparameteroftheoperation.

Postconditions:

– p.ownedType -> excludes(t): the removed data type t no longerexistsinpackagep.

6.3.8.AddEnumerationLiteral

Anenumerationliteralisaddedtoanowningenumeratione.TherelationAddEnumerationLiteralisgiveninFigure6.4inthedirectionleft-toright.

Preconditions:

–e.ownedLiteral->excludes(l): noenumeration literall exists intheowningenumeratione.

Postconditions:none

Figure6.5.:TheAdd/RemovePropertyrelation

6.3.9.RemoveEnumerationLiteral

Anenumeration literal is removedfromanowningenumeratione.TherelationRemoveEnumerationLiteralisgiveninFigure6.4inthedirectionright-to-left.

Preconditions:none

Postconditions:

–e.ownedLiteral->excludes(l):theenumerationliterallnolongerexistsintheowningenumeratione.

6.3.10.AddProperty

A property of an existing type is added to an existing classifier. Concreteclassifiers can be classes, data types or associations. In the case of anassociation,thepropertybecomestheownedEndoftheassociation.TherelationAddPropertyisgiveninFigure6.5inthedirectionleft-toright.

Preconditions:

–c.attribute->excludes(p):nopropertypexistsasanattributeofclassifierc.

Postconditions:

–p.membersAreDistinguishable():allmembersofthegivenclassifierc(includingtheaddedpropertyp)areuniqueintheirnamespace.

Figure6.6.:TheAdd/RemoveAssociationrelation

6.3.11.RemoveProperty

A (simple) property of some type is removed from a classifier. The relationRemovePropertyisgiveninFigure6.5inthedirectionright-toleft.

Preconditions:

– p.association -> isEmpty(): no association are attached to theproperty p. Associations can be removed using the RemoveAssociation operator in Section 6.3.13. This constraint also ensuresthat no opposite is set for the property, as this is derived from theassociationattached.

Postconditions:

–c.attribute->excludes(p):thepropertyphasbeenremovedfromclassifierc.

6.3.12.AddAssociation

Anassociationbetween twoexistingclassifiers isadded toapackagewith thespecifiedmember-endproperties.Themember-endproperties are added to theclassifiers by diverting to theAdd Property relation in the where-clause. TherelationAddAssociationisgiveninFigure6.6inthedirectionleft-toright.Ifone

oftheclassifiersistheassociationitself,thecorrespondingpropertyisownedbytheassociation(ownedEnd).

Preconditions:

–pkg.ownedType->excludes(a): no association a exists in packagepkg.

Postconditions:

– pkg.membersAreDistinguishable(): all members of the givenpackage(includingthenewlyaddedassociationa)areuniqueintheirnamespace.

6.3.13.RemoveAssociation

An association between two classifiers is removed from an existing package.Themember-end properties of the association are also removed. The relationRemoveAssociation isgiven inFigure6.6 in thedirectionright-to-left. ItcallstheRemoveProperty relation in thewhere-clause to remove themember-endsfromtheowningclassifiers.Ifoneofthepropertiesisownedbytheassociationitself,theassociationmustbegivenasoneoftheowningclassifiers.

Preconditions:none

Postconditions:

–pkg.ownedType->excludes(a):theassociationahasbeenremovedfrompackagepkg.

Figure6.7.:TheAdd/RemoveOperationrelation

6.3.14.AddOperation(Class/DataType)

Anoperationwithasetofparametersisaddedtoaclassordatatype.Adistinctrelation is needed for each case, as the ownership associations of Class andDataTypearenot relatedoravailable inacommonsuperclass.Apart fromthattherelationsareidenticalandgiveninFigure6.7inthedirectionleft-to-right.

Preconditions:

–owner.ownedOperation->excludes(o):nooperationoexistsforthegivenowner.

Postconditions:none

6.3.15.RemoveOperation(Class/DataType)

Anoperationwithasetofparameters is removedfromaclassordata type.Adistinctrelationisneededforeachcase,astheownershipassociationsofClassandDataTypearenot relatedoravailable inacommonsuperclass.Apart fromthat,therelationsareidenticalandgiveninFigure6.7inthedirectionright-to-left.

Preconditions:none

Postconditions:

– owner.ownedOperation -> excludes(o): the Operation o has beenremoved.

Figure6.8.:TheIntroduce/RemoveGeneralizationrelation

Figure6.9.:TheIntroduce/RemoveGeneralizationrelationwithcommonsuperclassifier

6.3.16.IntroduceGeneralization

A generalization is introduced between two classifiers. The relation for thecommoncaseisgiveninFigure6.8inthedirectionleft-to-right.Shouldinsteadthe special case be applicable,where the two classifiers share the same supertype, the generalization for the specific classifier is redundant and can beremoved.ThiscaseiscoveredbytherelationinFigure6.9.

Preconditions:

– not

IntroduceRemoveGeneralization_CommonSuperClassifier(general,

specific,g): for the common case, ensure that the special case isnotapplicableinstead.

– specific.allParents()-> excludes(general): The classifiergeneral is not already part of the generalization hierarchy of theclassifierspecific.

–specific.maySpecializeType(general):Theclassifier specificmaysubclass the classifier general. The operation maySpecializeType()returns true by default if the type of general is the same or moregeneral than that of specific. Subclasses of type Classifier mayintroduce further specialization constraints by overwriting thisbehaviour.[77,p.53].

– general.allParents()-> excludes(specific): The classifierspecific is not part of the generalization hierarchy of the classifiergeneral (to prevent cyclic relationships in the generalizationhierarchy).

Postconditions:none

6.3.17.RemoveGeneralization

A generalization between two classifiers is removed. The relation is given inFigure6.8inthedirectionright-to-left.Shouldthegeneralclassifierinheritfromfurther,moregeneralclassifiers,generalizations to theseneed tobe introducedfor the specific classifier, as otherwise properties previously available fromclassifiers furtherup the inheritancehierarchywouldno longerbeavailable inthespecificclassifier.ThiscaseiscoveredbytherelationinFigure6.9,alsointhedirectionright-to-left.

Figure6.10.:MovePropertyoperatorexample

Preconditions:

– not

IntroduceRemoveGeneralization_CommonSuperClassifier(general,

specific,g): for the common case, ensure that the special case isnotapplicableinstead.

Postconditions:

–specific.allParents()-> excludes(general): The generalizationrelationshiphasbeenremoved.

6.4.MoveProperty

Aproperty ismoved between classes that are linked by an associationwith amultiplicityofone-to-one.Therestrictionontheassociationisnecessarysothatvalues of the property of an instance after the move can unambiguously beassociatedwiththeoriginalinstance.

IntheexampleinFigure6.10,thepropertycityismovedfromWritertoAddressalongtheone-to-oneassociationbetweenthetwoclasses.

TherelationfortheMovePropertyoperatorisgiveninFigure6.11,asreadfromleft-to-right.Therelationisitsowninverse,switchingsourceandtargetclassesrevertstheimpactoftheoperator,movingthepropertyback.

Figure6.11.:TheMovePropertyrelation

Preconditions:none

Postconditions:

–c2.membersAreDistinguishable(): the target class does not alreadydirectlyorindirectlyownamemberofthesamenameasthepropertytobemoved.


ThePushSimplePropertyoperatorisanadaptationforEMOFofFowlersPushDownField refactoring pattern [34].A propertywith a simple type is pushedfrom a superclass into all subclasses that are immediate children of thesuperclass.SubsequentapplicationofPushSimplePropertyon thepropertyon

the child classes can push properties to further removed classes along thegeneralizationhierarchy.Pushingpropertiestoallthechildrenofaclassmakeslittlesenseonitsown,sothepropertycanberemovedfromthosechildrenthatdon’t need it using the Delete Property operator. This fulfils the originaldescriptionofFowler’spattern.Alternatively,PushSimplePropertycanbeusedtoremoveallpropertiesfromasuperclassandthendeleteitusingDeleteClass.

We discern between pushing simple and complex properties as the impact isdifferentandextrastepsareneededtoadjustassociationslinkedtopropertiesforcomplextypes.

Figure6.12.:PushSimplePropertyoperatorexample

Figure6.13.:ThePushSimplePropertyrelation

Wachsmuthproposes a similar versionofPushSimpleProperty forCMOF as’pushProperty’[107],butdoesnotdiscernbetweensimpleancomplexpropertiessothatitdoesnotcaterforassociations.

Figure 6.12 shows a small example of applying the Push Simple Propertyoperator:thepropertydamagedispushedfromtheparentclassAudioVisualItemtobothitschildren.

ThePushSimplePropertyoperatorisdefinedbytherelationinFigure6.13.Intheapplication,thesimplepropertypisclonedandsetontheclassc2matchingthepattern.PleasenotethatLHSpatternproducesamatchforeverychildclassc2thatinheritsfromthesuperclassc1sothatacloneofthepropertyiscreatedforeverychildclass.

Preconditions:

–p.association->isEmpty():ensurethatthepropertypisasimpleproperty.

Postconditions:

– RemoveProperty(p): ensures the correct removal of the originalproperty.

–Clone(p,pC):createapropercloneforeachchildclassc2.

–AddProperty(pC,c2):addtheclonetothechildclassc2.


LikethePushSimplePropertyoperator,thePushComplexPropertyoperatorisusedtopushapropertyfromasuperclasstoall immediatesubclassesandthenremovethepropertyfromthesuperclass.ThePushComplexPropertyoperatorperforms thisoperationonpropertiesof a complex type,where the link to thevalueinstanceanditstypeisestablishedbyanassociation.Theassociationhastobeclonedalongwiththepropertyforeachofthesubclassesthatreceivethepushedproperty,whichmakesthedifferentiationfromthePushSimplePropertyoperatornecessary.

Associations establish links between two instances over the properties of twoclassifiers(complextypes)whichserveasassociation-ends(seeSection2.3.2).Ononeside,thepropertyisalwaysownedbyaclass.Thelinkestablishedbytheassociationisalwaysnavigableinthisdirection.Ontheotherside,thepropertycanbeownedbytheassociationitself,iftheassociationisdirectedandthelink

only navigable in one direction. If the association is bidirectional instead, thepropertyisownedbyaclassontheothersideandnottheassociation.

Theneed toalsoadjust theassociationand theremotepropertyalongwith theproperty being pushed makes a separate operator for complex propertiesnecessary.

Inthecaseofabidirectionalassociation,cloningthepropertyonthefarsideofthepushcanleadtonameclashes,asacloneofthepropertyhastobecreatedforeach receiving child class. As the cloned properties are owned by the sameclassifier, duplicating the name would violate the uniqueness constraint fornames.Herethecloneoperatorneedstoassignuniquenamesorallowtheuserto assign an original name (user intervention). This is enforced by themembersAreDistinguishable()constraintintherelation.

Figure6.14.:PushComplexPropertyoperatorexample

In the example in Figure 6.14, the property status is pushed from the classAudioVisualItem to its subclasses BookOnTape and VideoCassette.As thepropertyislinkedtoabidirectionalassociationandthepropertyitemonthefarside, the association and the remote properties are cloned and the remoteproperties renamed to bookOnTape and videoCassette respectively – tomaintainuniqueness.

ThePushComplexPropertyoperatorisdefinedbytherelationinFigure6.15 .For each occurrence of the target complex property on a superclass-subclasspattern,acloneofthepropertyandacloneoftheassociationiscreatedandtheclonedproperty isassignedto thesubclass.Thepropertyon theremoteendofthe association can be owned either by another class (bidirectional) or theassociationitself(unidirectional),wheretheownerisdesignatedbytheclassifiercXinbotherpatterns.Thetypeoftheremotepropertyisadjustedtothesubclass

c2:Class.Incaseswithmorethanonesubclassandabidirectionalassociation,theremotepropertyisclonednumeroustimes;onceforeachsubclass.Heretheuserneedstoassignnewanduniquenamesfor theclonedproperties toensuredistinguishabilityandtoproperlyreflectthenewsemanticsofeachproperty,asthesetofnavigable instances isdividedupbetween theclonedproperties.ForthisreasonthesubrelationCloneDiscName()(‘clonediscountingname’)isused,whichpromptstheuserforanewname(seeSection6.1.2).

Figure6.15.:ThePushComplexPropertyrelation

Preconditions:none

Postconditions:

– Clone(p, pC); CloneDiscName(p2, p2C); Clone(a, aC): createclonesforeachsubclassofbothpropertiesandtheassociation.Fortheremoteproperty,aclonewithanew,uniquenameiscreated.

– AddProperty(pC, c2); AddProperty(p2C, cX);

AddAssociation(aC, pC, c2, p2C, cX, pkg): add the clonedelementstothemodel.

–RemoveProperty(p);RemoveProperty(p2);RemoveAssociation(a):

removetheoldpropertiesandtheassociation.

– membersAreDistinguishable(): ensure that the newly createdpropertieshaveuniquenames.

A possible alternative approach would be to first split up any bidirectionalassociations to two unidirectional ones and then perform the push only on aunidirectionalassociation.Thiswould leave the reverseassociationpointingatthe superclass and maintain the same set of instances as before. Yet, thereversibility of the association would then not be enforced by the model anylongerandwouldhavetobemaintainedbyothermeansandmoreimportantly,theeffectof thepushpropertyoperatorwouldnotbereversible,aswhetherornottwopropertiesareoppositesandcantakepartinaPullPropertyoperatorcannotbedecidedbasedonthemodelalone.Forthesereasonswechosetomaintainthebidirectionalnatureovermaintainingthewholereverseassociation.

Figure6.16.:ThePullSimplePropertyrelation


ThePullSimplePropertyoperator ‘pulls’equivalentsimpleproperties fromallsubclasses into a common, direct superclass and removes them from thesubclasses.ThisisthereverseeffectofthePushSimplePropertyoperator(6.5).Should some subclass of the superclass not have the given property, it can beaddedfirstbyapplyingCreateElementforthatproperty.Furtherapplicationsoftheoperatorcanpullthepropertyfurtheruptheinheritancehierarchy.

TheexampleinFigure6.12servestoillustratetheeffectofpullingaproperty,asit reversespushing theproperty,byswapping‘before’and‘after’: thepropertydamagedispulledfromthechildrentotheparentAudioVisualItem.

The relation in Figure6.16 defines the behaviour of thePull Simple Propertyoperator. It is almost the reverse of thePushSimpleProperty relation (Figure6.13)withoneexception:apreconditionensuresthatifPushSimplePropertyisapplied,itmustbeappliedforallchildclasses,inotherwords,allsubclassesofthe targetclassmustownacloneof theproperty toallow it tobepulled.The

relationisexecutedforeachoccurrenceofthepropertyonasubclassc2andasingleclonepCremainsonthesuperclassc1.

Preconditions:

–p.association->isEmpty()-ensurethatthepropertypisasimpleproperty.

– c1.class->forAll(child |

child.ownedAttribute.includes(Clone(p)); - ensure that allsubclassesownacloneofthepropertyp.

Postconditions:

– RemoveProperty(p); - ensures the correct removal of the originalproperty.

–Clone(p,pC);-ensuretheexistenceofaclonepCforp.

–AddProperty(pC,c2);-addtheclonetothesuperclassc1.


ThePullComplexPropertyoperatorpullscomplexpropertiesthatareequivalentfrom all subclasses into a common superclass. It has the inverse effect of thePushComplexPropertyoperatorofSection6.6.Like thePullSimplePropertyoperator,itonlyapplieswhenanequivalentpropertyisownedbyallsubclassesof the receiving superclass. Should one bemissing from a subclass, it can beaddedpriortotheoperatorusageusingtheAddPropertyoperator (6.3.10).AnexamplefortheeffectoftheoperatorcanbeseeninFigure6.14,whenreadfromright-to-left: the properties status of the classes BookOnTape andVideoCassettearepushedintotheclassAudioVisualItemandjoined.

Preconditions:

– c1.class->forAll(child | let pc: Clone(p)in

child.ownedAttribute ->includes(pc)and pc.association =

Clone(a)andpc.association.memberEnd->includes(Clone(p2));

- ensures that all subclasses (child) own a suitable property -association-propertyconstruct,ofwhicheachelementfulfilstheroleofaclone.

Figure6.17.:ThePullComplexPropertyrelation

Postconditions:

– Clone(p, pC); Clone(p2, p2C); Clone(a, aC): clones for theelementsconnectedtothesubclassneedtoexistonthesuperclass.

– AddProperty(pC, c2); AddProperty(p2C, cX);

AddAssociation(aC, pC, c2, p2C, cX, pkg): add the clonedelementstothemodel.

–RemoveProperty(p);RemoveProperty(p2);RemoveAssociation(a):

removetheoldpropertiesandtheassociation.

– membersAreDistinguishable(): ensure that the newly createdelementsareunique.

TherelationinFigure6.17definesthebehaviouroftheoperator.Thepropertypis pulled up from the subclass c2 to the parent class c1. This is achieved bycloningboththeproperty,theattachedassociationaandthepropertyp2ontheremote side of the association. The relation matches and is executed for allsubclasses of c1, so that the property is removed from all subclasses. Thecloningandaddition relations in thewhere-clause enforce the existenceof theelementsforthesuperclassc1aftereachexecutioncase.

Figure6.18.:TheRestrictUnidirectionalPropertyrelation


TheRestrictPropertyoperatorreducestherangeofallowedvalueinstancesofacomplex property by specialising the type of the property (and its values).AscomplexpropertiesaremodelledusingassociationsinEMOF,thenatureoftheattached association has to be taken into account: If the association isbidirectional, restricting the type of a property on one side of the associationequates‘pushingdown’thepropertyontheotherside,asitisownedbytheclassservingastype.HerewesuggestusingthePushComplexPropertyoperatorontheremotepropertyandremovingallassociationclonesthathavetheintendedrestrictedtype(seesection6.6).

Iftheassociationisunidirectionalandthustheremotepropertyisownedbytheassociationinsteadoftheoppositeclass,theRestrictPropertyrelationinFigure6.18canbeapplied.

Figure6.18definestheRestrictPropertyoperator.Theapplicationchanges thetypeof thecomplexpropertyp from the superclassc1 to the subclassc2.Thepropertyp2attheremoteendoftheassociationattachedtophastobeownedbytheassociationfortherelationtoapply,whicheffectivelyconstrainstherelationtounidirectionalassociations.

Preconditions:none

Postconditions:none


TheGeneralisePropertyoperatorincreasestherangeofallowedvalueinstancesofacomplexpropertybygeneralisingthetypeoftheproperty(anditsvalues).IthastheoppositeeffectoftheRestrictPropertyoperatorofSection6.9.Like itsopposite,itisonlyappliedtounidirectionalcomplexproperties,asbidirectionalassociations can be handled by pulling the opposite property upwith thePullComplexPropertyoperator(seeSection6.8).

Astheassociationisunidirectionalandthustheremotepropertyisownedbytheassociation instead of the opposite class, the inverse of the RestrictUnidirectionalProperty relation inFigure6.18canbeapplied, in thedirectionright-to-left.

6.11.ExtractClass

Aclassisextractedfromanexistingclassinthesamepackage.Anassociationiscreatedbetweenthetwoclasseswithamultiplicityofone-to-one.Therestrictionontheassociationisnecessarytoensurethatoneinstanceoftheformerclasscanbemappedtoasetofinstancesoftheoldandthenewclassaftertheoperatorisapplied. The newly created class is empty after the operator is applied. In asubsequentadaptationstep,propertiescanbemoved from theoriginalclass tothenewclasswithMoveProperty(seeSection6.4)ornewfeaturescanbeaddedtothenewclassusingAddProperty(seeSection6.3.10).

IntheexampleinFigure6.19,anewclassStatusReport isextractedfromtheclassAudioVisualItemandlinkedbyaone-to-oneassociationtotheclass.TheMovePropertyoperatorcouldbeusednexttomovethedamagedpropertyfromAudioVisualItemtoStatusReport.StatusReportcouldfurtherbeextendedtoholdmoreinformationontheconditionanitemofthelibraryintheexampleisin.

Figure6.20showstherelationfortheExtractClassoperator.Theclassc1 istheparameteroftheoperatorontheLHStowhichtheoperatorisapplied.Thenewlycreatedandaddedelementsaresettobelongtothesamepackageasc1.Subrelationsforthecreationandadditionofthenewelementsarecalledinthewhere-clausetoensureallfeaturesofthenewelementsaresetcorrectlyandallpre-andpostconditionsfortheiradditionaremet.

Figure6.19.:ExtractClassOperatorexample

Figure6.20.:TheExtractClassrelation

Preconditions:none

Postconditions:

– CreateClass(c2); CreateAssociation(a); CreateProperty(p1);

CreateProperty(p2):Thenewelementsarecreated.

–AddClass(pkg,c2);AddProperty(p1,c1);AddProperty(p2,c2);

AddAssociation(a,p1,c1,p2,c2,pkg): The newly created elementsareaddedtotheirrespectiveowners.

6.12.InlineClass

TheInlineClassoperatorhastheoppositeeffectoftheExtractClassoperator:aclassismergedintoanotherclasstowhichitwasconnectedtobyanassociationwith a multiplicity of one-to-one. The class and the association are removedfromthemodel.Werefer to theclass that remainsas the‘target’and theclassthatismergedintoitasthe‘merged’classinthefollowing.Whenlookingattheeffect of the operator on the metamodel level only, it is the same as simplyremovingthemergedclassandtheassociation.Yetwhenhandlingtheimpactontransformations, the distinction between a merge and a deletion becomesimportant.

Themergedclassispurposefullyconstrainedtobeemptyfortheoperatortobeused,aspropertiesorassociationsofthemergedclasscanbetreatedinanumberofdifferentwaysbeforeusingInlineClassbyusingotheroperators likeMoveProperty (seeSection6.4) tomove them to the target class first or simply byremovingthem.

As the effect of this operator is the reverse ofExtract Class, the example inFigure6.19canbeused to illustrate itseffect: If theoperator isapplied to theclass StatusReport on the right-hand side, it is merged into the classAudioVisualItem (which is indistinguishable from removing it, whenconsideringtheeffectonthemetamodellevelonly).

The operator is shown in Figure6.21 . The operator is applied to themergedclassc2,which ismerged into the targetclassc1.Theassociationbetween thetwoandthepropertiesconnecting theassociationareremovedwith themerge.The operator requires no dedicated preconditions as the operators used toremove the elements in thewhere-clause ensure a clean removal, for examplethattheclassc2isemptyfortheoperatortoapplicable.

Preconditions:none

Postconditions:

– RemoveClass(c2); RemoveAssociation(a); RemoveProperty(p1);

RemoveProperty(p2): ensure the proper removal of the givenelements.

Figure6.21.:TheInlineClassrelation


Asuperclassisextractedfromoneormorechildclasses.Aselectionofcommonfeaturesofthechildrencanbepulledupintothenewsuperclass.Thisoperatorhas the inverseeffect to theFlattenHierarchyoperator.Thenewsuperclass isownedbyanygivenpackage.

Preconditions:

–props->forAll(p|c1->forAll(c|letclone:Clone(p,clone)in

c.ownedAttribute.includes(clone)):Acloneofallproperties tobe pulledmust be present in each of the child classes, i.e. before apropertycanbepulleduptothenewparentclass,ithastobepresentwiththesamenameandtypeineverychildclass.

Postconditions:none

Figure6.22.:TheExtractSuperclassrelation


TheFlattenHierarchy operator is used to reduce the inheritance hierarchy ofclasses:thefeaturesofatargetclassaremovedtoallchildclassesandtheclassisdeleted.ThisoperatorisimplementedbyapplyingPushSimpleProperty(6.5)orPushComplexProperty (6.6) forallpropertiesof theparentclassuntil it isempty. The generalizations between the parent and the child classes are thenremovedusing theRemoveGeneralizationoperator (6.3.17).Should theparentclass inherit from another class even further up the inheritance hierarchy, theoperatorensuresthatthechildclassesaresettoinheritfromthatclassinstead,sothatinheritedfeaturesremainavailable.TheparentclassisthenremovedusingRemoveClass(6.3.3).

Althoughthetaskofflatteningthehierarchyisachievedbydelegatingtootheroperators, the existence of a distinct operator for this task is merited, as theimpactresolutionfortransformationscanbeimprovedwiththeknowledgeofitsusage(see7.16).

IntheexampleinFigure6.23,thelevelofhierarchyisreduced,by‘pushing’thepropertytitleoftheabstractclassCirculatingItemdownintothesubclassesand removing the class. The title property was previously available toinstancesof thesubclassesbyinheritanceandisnowmadeexplicitlyavailablebytheoperator.

Figure6.23.:FlattenHierarchyoperatorexample

Figure6.24.:TheFlattenHierarchyrelation

TheFlattenHierarchyoperatordefinedby the relation inFigure6.24matchesevery occurrence of a subclass c2 to the selected superclass c1 so that it isexecutedforeachsubclass.Acloneofeverypropertyoftheclassc1iscreatedineverysubclassandremovedfromthesuperclasswithacalltothePushPropertyoperator.Subsequently,theemptysuperclassandallexistinggeneralizationsareremoved.

Preconditions:none

Postconditions:

– c1.attribute->forAll(p | PushSimpleProperty(p)or

PushComplexProperty (p)): all properties are pushed into thesubclasses.

– RemoveGeneralization(g); RemoveClass(c1): both thegeneralizationandthesuperclassareremoved.


TheAssociation toClass operator replaces an associationbetween twoclassesby a class connecting the two classes instead. This is useful for example if arelationship between two entities needs to be extended to hold informationbeyondthefactthatthetwoentitiesarerelated.Introducinganewclasslikethisfulfils the same purpose as theAssociationClass element available in UML2,whichisanassociationwhichownsfeatures[77,p.44].

In the example in Figure 6.25, the directed association between the classesBorrowerandLendableisreplacedbytheclassLoan.Thisclasscanbeextendedafterwards, for example by adding properties which hold further informationabouttheloan,liketheduedateorthenumberofloanextensions.

Figure6.25.:AssociationtoClassoperatorexample

Figure6.26.:TheAssociationtoClassrelation

TheAssociationtoClassoperatorisdefinedbytherelationinFigure6.26.Theassociation a is replacedby thenewclass ca.To establish the link to thenewclass, the two new associations a1 and a2 are created. The member-endpropertiesoftheoldassociationthatareownedbytheclassesarerepurposedasmember-ends of the new associations on the side of the classes.On the otherside,twonewpropertiesarecreatedforthenewclasscaandgivenanupperandlowerboundof1.Theboundsandnamesof the repurposedpropertiescanbemaintainedtoremainasclosetotheoriginalconfigurationaspossible.Insum,theallowednumberofinstancesonbothsideremainthesame,astheboundsarekeptandarenavigablebythesameproperties(bartheextranavigationstepfromthe new class to the remote end, which can not be avoided). The user canprovide names for the new elements, being the new class and the ownedproperties.ThisisperformedintheCreate..()operationinthewhere-clause.

Preconditions:none

Postconditions:

–CreateClass(ca);AddClass(pkg,ca):Createthenewclassandaddittothepackageowningtheassociation.

– CreateAssociation(a1); CreateProperty(pa1);

AddAssociation(a1,p1,c1,pa1,ca,pkg):Createanassociationandapropertytolinktothenewclassononeside...

– CreateAssociation(a2); CreateProperty(pa2);

AddAssociation(a2,p2,c2,pa2,ca,pkg):...andontheother.

– RemoveAssociation(a,p1,c1,p2,c2,pkg): Remove the associationthatisreplaced.


A generalization between two classes is converted to an association. Theassociationismadeessentialonthesideofthechildclass,withanupperboundof1.Onthesideoftheformerparent,theupperboundis1andifitwasabstract,thelowerboundisset to1,otherwiseit is0.If theparentclass itself inheritedfroma thirdclass,bothclassesare set to inherit from that thirdclassafter theresolution.Hassam and al. call a similar operator ‘InheritanceToComposition’.[42]

Preconditions:none

Postconditions:none

Figure6.27.:GeneralizationtoCompositionoperatorexample

Figure6.28.:TheGeneralizationtoCompositionrelation

Figure6.29.:IntroduceCompositePatternoperatorexample


ThisoperatorservestheintroductionoftheCompositedesignpatternasdefinedbyGammaetal.[35]toamodel.Theoperatorisappliedtoanexistingparent-childcontainmentassociationofaclassanddividestheclassintoaclassintheroleofaleafandoneintheroleofacompositeasprescribedbythepattern.The

classes both inherit from the original class,which ismade abstract andwhichkeeps all previously existing properties and relations left unchanged by theoperator.Thesecanbemovedtoeithertheleaforthecompositeinasubsequentadaptation, if applicable. The parent-child association is redirected as acontainmentassociationbetweenthecompositeandtheabstractoriginalclass.

Inexample6.29,theCompositepatternisintroducedfortheclassLendableandthecontainmentassociationcontent.LendableissplitintoaBook,whichhasnofurtherchildrenandassumes the roleof the leaf in thepattern.TheCollectionclasscancontainchildrenandservesasthecomposite.Collectionscannowbemadeupofbooksor furthercollections.The typeandnameproperties remainwith the class Lendable and can be adapted afterwards. The class Lendablebecomesabstract.

Figure6.30.:TheIntroduceCompositePatternrelation

CHAPTER7

ImpactResolutionforATL

This chapter introduces the impact resolution of the operators discussed inchapter6onATLmodeltransformationsandinaccordancewiththethirdphaseofourapproachdescribedinSection5.7.Theimpactandresolutionssuggestedfor each operator are discussed in detail in separate sections below. The nextsection provides an overview of the resolutions for all operators. The impactresolution for each operator is formalised as aQVT-R relation defined on theATLASTandgiven ingraphicalnotation.Section7.2discusses theomissionsmadeforATLandsupportfunctionsdefinedfortherelationstomakethemlessverbose.

7.1.OperatorImpactOverview

Table7.1summarizestheinfluenceoftheoperatorsonATLtransformationrulesandtheresolutionsuggestedforthem.Theoccurringimpactresolutionsare:

noneTheoperatorhasnoimpact.Itcanbeappliedwithoutendangeringthevalidityofdependentmodeltransformations.

automatic The operator has an impact that needs to be resolved, but theresolution can be achieved automatically andwithout the attention of thesoftwarearchitect.

Operator

AddElement

RemoveElement

RemoveClass

RemoveProperty

Section

7.3

7.4

7.4.1

7.4.2

Page

139

140

ImpactandResolution

ImpactandResolution

none/HIforaddprop.

RemoveAssociation

RemoveGeneralization

RenameElement

MoveProperty

PushSimpleProperty

PushComplexProperty

PullSimpleProperty

PullComplexProperty

Restrict(Unidir.)Property

Generalise(Unidir.)Property

ExtractClass

InlineClass

ExtractSuperClass

FlattenHierarchy

AssociationtoClass

GeneralizationtoComposition

IntroduceCompositePattern

7.4.2

7.4.3

7.4.4

7.5

7.6

7.7

7.8

7.9

7.10

7.11

7.12

7.13

7.14

7.15

7.16

7.17

7.18

7.19

140

141

146

147

147

147

152

154

158

158

159

159

160

161

163

163

none

automatic

automatic,warn

automatic,warn

automatic,warn

automatic

automatic

none,warn,HI

none,warn,HI

none

none,HI

none,HI

none

automatic

automatic,HI

none,automatic

automatic,warn,HI

automatic

none,automatic

automatic,HI

166

167

168

Table7.1.:OverviewofimpactresolutionsforATLtransformations

HITheimpactoftheoperatorcannotberesolvedandhumaninterventionis required. In an implementation, the user should be alerted to the exactpartofthetransformationthatrequiresattention.

warnAnautomatic resolution ispossibleand the syntacticcorrectnessofthe transformation is maintained by the resolution, but the softwarearchitectiswarnedbecausetheresolutionwithoutanyfurtherchangeisnotdeemed tobepracticaloruseful.Thesoftwarearchitect isalerted tosuchcases.

For most operators, a combination of impacts is possible depending on thestructure of the transformation and where in a transformation rule the impactoccurredorwhethertheoperatorwasusedontheLHSorRHSmetamodelofthetransformation.

ThedetailsoftheimpactresolutionforeachoperatorarediscussedindividuallystartingfromSection7.3.

7.2.SupportFunctionsandOmissions

For the impact resolutions defined in this chapter two omissions of the ATLlanguage were made which is deemed permissible when showing the overallapplicability of the approach, yet should be addressed when aiming for acompletetoolsupportinthefuture.Theseare:

Helpers ATL provides the helper mechanisms to structure and reuse OCLexpressions.Helperscanactaseitherglobalvariablesorfunctionsdefinedonmodel elements and are an optional structuringmechanism [6, p. 14].TheyuseOCLexpressionstocalculateavaluebasedonasetofparametersandarecalledfromrulesorotherhelpers.Becausetheyareoptional,theyareomitted

fromthe impact resolutionsdefinedhere,yet,wheneveran impact relates toanOCLexpression,ahelpercouldalsobeimpacted.CompletetoolsupportofATLwouldneed tocoverhelpers inpractice.Asaworkaround for the timebeing,onecaneliminatehelpersfirstbyreplacingallusesofahelperwiththecontainedexpressionandremovingthehelper.Thisway,theapproachisstillusablewithoutexplicithelpersupport.

Imperative rulepart ATL rules can have an optional imperative part. It is aconveniencefeaturethatcontainsoneormoreimperativestatementsthatarecalledaftertargetmodelelementshavebeeninitialisedtoprovidevaluesforuninitializedattributesortomodifyvalues[5,p.42].Theeffectofimperativeparts is difficult to predict and omitted from the impact detection. Ifimperativepartsareused,usersareadvisedtochecksuchrulesmanuallyafteranimpactresolutionisperformed.

Tosimplifytheimpactdefinitions,twocustomblack-boxoperationsareusedinthe relations. These provide basic support functions to be called from therelationswhereneededtomakethemlessverbose.ForanimplementationoftheimpactresolutionsinQVT-R,theblack-boxoperationscouldbeprovidedbytheexecutingengineasdefinedbytheQVTstandard[73].Theyareasfollows:

MatchesTheMatches()operationprovidesthebridgebetweenEMOFandATLtypes. As ATL uses OCL expressions to identify model elements, theexecuting engine and the co-evolution approachneed to identify the correctmodelelement representedbyanOCLexpression.Thematches()operationisdefinedtoreturntruewhenthegivenOCLModelElementcorrespondstothegivenEMOFmetamodelElement.

CloneTheClone() operationcreatesa cloneof anOCLexpression.ASOCLexpressions canbe of arbitrary length, the cloningprocess canbe extensiveand its definition as a set ofQVT-R relationwould be verbose,while onlycreatingacopyofeachtypeofOCLexpressionpossible.Therefore,Clone()isdefinedtoreturnacloneofagivenOCLExpressionelement,orevaluatetotrueifthetwogivenexpressionsarevalidclones.

TheimpactresolutionsforFlattenHierarchyinSection7.16andPushComplexPropertyinSection7.8makeuseoffurthercustomblack-boxoperations.Thesearedefinedtogetherwiththeimpactresolutionastheyarenotreusedelsewhere.

7.3.AddElement

Addinganelementtoametamodelrequiresnoimpactresolutionformosttypesof elements, as the existing metamodel elements remain unaltered and theexisting ATL transformation rules that use them remain valid. For example,whenaddinganewclasstoapackage,anyexistingtransformationwillneitherread nor write instances of the new class until a new rule for this purpose iscreated.

Theonlyexceptionisthecreationofproperties:herethemetamodelcandictatethatacertainamountofvaluesisrequiredfortheproperty,bysettingthelowerboundofthepropertylargerthan0.Modelswithouttheproperamountofvaluesfor the property are invalid. Should such a requirement be defined for a new,RHS property and an existing transformation rule creates instances of theowningclass,therequiredvalueswillnotbesetandtheinstancemodelresultingfrom the transformation isno longervalid.Therefore, the following twocaseshave to be checked for EMOF-basedmodels and require user intervention toprovidemeaningfulvalues:

MultiplicityElement.lower > 0 and

MultiplicityElement.isMultivalued(): The lower bound of amultivaluedpropertyisgreaterthan0,thereforeavaluemustbesupplied.This cannot be adefault value, asmultivaluedproperties cannot have adefaultvalue inEMOF,so thatany transformation rulewith thispropertyon the RHS has to be adapted manually to provide a value(isMultivalued() is true when the multiplicity has an upper boundgreaterthanone).

MultiplicityElement.lower > 0 and not

MultiplicityElement.isMultivalued()andProperty.defaultValue-

>isEmpty():Thenewproperty isnotmultivaluedbutnodefaultvalue isspecifiedsothatanytransformationruleusingtheowningclassontheRHSmustbeadaptedmanuallytoprovideavalue.

Foran implementationinEMFEcore, theattributeETypedElement.requiredfulfils the same function as setting a lower bound greater than 0. It must becheckedalongwiththemultiplicity.

BesidestheserestrictionsfortheAddPropertyoperator,theadditionofelementstomodelshasnoimpactonATLtransformations.

Figure7.1.:TheRemove(LHS)MatchedRulerelation

7.4.RemoveElement

Anelement is removed from themodel.Asopposed to the impact of theAddElement operator, we have to discern between the types of elements that areremoved todetermineand resolve the impact.Deletingoperations,parameters,data types or packages has no influence on existing transformation rules. Thedeletionofclasses,propertiesandassociations ishandledindividually,as thereare a number of possible impacts on transformation rules. These are detailedbelow.

7.4.1.RemoveClass

TheRemoveClassoperatorcan removeaclass fromametamodelbothon theLHSandRHSsideofanATL transformation.On theLHS, theclasscanonlyoccur in in-patterns of rules that match the class. All the other possibleoccurrencesofclassesintransformationrulesarenotpossiblewhentheRemoveClassoperatorisappliedasitconstrainstheclasstobeemptyandtonotbeusedby any other part of the model (as the type of a property, for example).Weassumethattheremovaloftheclassmeansthattherulethatmatchesitcanalsoberemoved.Therefore,theimpactresolutionisstraight-forwardandautomatic:allrulesmatchingtheclassareremoved.ThisisdefinedbytherelationinFigure7.1.

FortheRHS,allout-patternelementsthatcreateinstancesoftheremovedclasscanberemoved.ThisisachievedbytherelationinFigure7.2.

Figure7.2.:TheRemoveOutPatternElementrelation

Figure7.3.:TheRemoveRulewithEmptyOutPatternrelation

Rulescanhavemorethanoneout-patternelement,soonlywhenthisresultsinarulewithanemptyout-pattern,thewholerulecanberemoved,whichisdefinedbytheRemoveRuleWithEmptyOutPatternrelationinFigure7.3.

7.4.2.RemoveProperty

Asimplepropertyisremovedfromaclass.Complexpropertiesarealwaysusedas part of associations which are removed using the Remove Associationoperator instead (see Section 7.4.3 for the impact resolution of the RemoveAssociationoperator.

Insimplecases,rulesthatneedtobeadaptedinresponsetotheRemovePropertyoperatoreitherrefertotheclassfromwhichthepropertyisremovedortooneofitssubclassesinin-orout-patterns,orcontainOCLexpressionsthatrefertotheremovedproperty.

Listing7.1:ATLrulewithconstrainingOCLexpression

Inmorecomplexcases, thepropertycanbeused in rules thatmatchunrelatedclassesandthenuseOCLexpressionstonavigatetothepropertytoberemoved.The suggested impact resolution is the same for both cases but the impactdetection is more complex, as every OCL expression in every rule has to beanalysedforpossibleOCLnavigationexpressionsandusageoftheproperty.

Thefollowingpartsofarulearepossiblecandidatesfortheremovedpropertytooccur:

FilterConditions(LHS)

Referencestotheremovedpropertycanoccurinfilterconditionsrestrictingtheapplicationofarule.Listing7.1containsanexampleofanATLrulematchingan arbitrary class ClassA which is restricted by an OCL expression thatreferencesthearbitraryattributeisMatchedoftypeboolean(line4).

WhentheattributeisMatchedisremovedfromtheclassClassA,theexpressionbecomes invalid. To resolve this, we propose the removal of the conflictingcondition,makingtherulepotentiallymatchmoreoften.Theuseriswarnedofthepossiblyunintendedbehaviourinthiscase.Shouldthepropertyreallyhavebeennecessaryforconditionssuchasthis,theremovalappearstobepremature.

The relation in Figure 7.4 defines the resolution formatched rules with filterconditionscontainingapropertyaffectedbytheRemovePropertyoperator.

Figure7.4.:RemovePropertyimpactresolutionforATLfilterconditions

The domain of the relation consists of the impacted rule and the removedproperty.TheOCLexpressionrestrictingtheapplicationoftheruleinthiscaseis given by the filter reference set on the rule’s InPattern. The filterconditioncanbeanyOCLexpressionevaluatingtoaboolean.WhentheASTof the expression contains aNavigationOrAttributeCallExpwhichnavigatesto the removed property, thewhole filter expression is removed in the impactresolution,asgivenbytheleftsideoftherelationinFigure7.4.

ThegivenrelationonlycoverscaseswheretheremovedpropertyisuseddirectlyinaNavigationOrAttributeCallExp for thesakeofbrevity.OCLexpressionsused as filters can bemade up of any number of OCLExpression elements toform more complex expressions (like if..then..else..endif). These arereferred to here in sum by the element oe:OCLExpression. For animplementationoftheresolutionstrategy,theoe:OCLExpressionASTusedasafilter has to be tested recursively for any occurrence of the NavigationOrAttributeCallExp element referring to the removed property in the filterexpression.Theresolutionstrategyremainsthesamenomatterhowcomplexthefilter expression: the entire filter is removed as soon as any occurrence of theremovedpropertyisfound.

Listing7.2:ATLrulewithbindingassignment

BindingAssignment(LHS)

ForaLHSmetamodel,theremovedpropertycanbepartofabindingassignment(tosetthevalueofaRHSproperty).Fortheimpactresolution,weproposetheremovalofthewholeassignment,iftheRHSpropertyisnon-obligatoryorifithasadefaultvalue.Syntacticcorrectnesswouldbepreserved.Theusershouldbewarnedinthiscase,asaRHSpropertywhichwaspreviouslyassignedavaluenow receives its default value instead. Should the value of the property beobligatory instead, human intervention is needed to create a new assignmentstatementtoprovideavalue.

IntheexampleinListing7.2,thetitlepropertyoftheRHSMovieclassisboundto the title of theLHSVideoCassette class (in line 8).Whenwe remove thepropertytitle of the classVideoCassette, the binding assignment has to bealtered. In this example, the title attribute is mandatory, so the user has tointervene to provide a new value. Since the rule in its current state becomesobsolete,thebestcourseofactionfortheuseristoremovetheentirerule.

The relation inFigure7.5 defines the resolution for ruleswith aLHSbindingassignmentreference toaproperty that is removed.Thedomainsgivenare therule to be adapted and the property. The binding assignment references thepropertyvia aNavigationOrAttributeCallExpwith the nameof the propertyandasourceofaVariableExpreferringinturntoavariabledeclarationofthetype of the owning class. For the resolution, the entire binding assignment isremoved.

Figure7.5.:RemovePropertyimpactonLHSbinding

Same as with the resolution of removed properties used in filter expressionsdescribed above, the given relation only resolves cases where the property isuseddirectlyinaNavigationOrAttributeCallExp.Thepropertyusageinmorecomplex expressions is referred to in sum by the binding elementbinding:Binding for the sake of brevity. For an implementation of theresolutionstrategy,thebindingexpressionASThastobetestedrecursivelyforanyoccurrenceoftheNavigationOrAttributeCallExpreferringtotheremovedproperty.Theresolutionstrategyagainremainsthesame:foranyoccurrence,thewholebindingisremoved.

BindingAssignment(RHS)

Thepropertycanhaveavaluebindingforthetargetpatternoftheclassitwasremovedfrom.Thebindingassignmentisremovedintheresolution.

For example, should thepropertytitle of the classMovie used in the rule inListing 7.2 line 8 be removed by the Remove Property operator, the entirebindingstatementtitle<-video.titleisremovedintheresolution.

Figure7.6.:RemovePropertyimpactonRHSbindingresolution

Figure 7.6 defines the resolution for rules with a RHS binding assignmentreferencetoapropertythatisremoved.Thedomainsarethematchedruletobeadaptedandtheproperty.Thebindingassignmentreferencesthepropertyviaitsnameand thesuperclass is the typeof thecorrespondingOutPatternElement.Fortheresolution,thebindingassignmentandtheexpressionthatwasboundareremoved.

7.4.3.RemoveAssociation

Anassociationandthepropertiesdenotingtheendsoftheassociation(member-end properties) are removed from a package. The impact resolution can bereducedtoresolvingtheremovalofthetwomember-endproperties,asATLdoesnot distinguish between the properties and the association itself. TheRemoveAssociationoperatoralreadydelegates toRemoveProperty, the removalof thepropertiesishandledandnofurtheractionisneeded.

7.4.4.RemoveGeneralization

Ageneralizationbetweenasuper-andasubclassisremoved.Theimpactcanbeequated to the removal of all features of the superclass from the subclass, asthesearenolongeravailablethroughinheritanceafterwards.(Featuresofclassesevenfurtheruptheinheritancehierarchyremainavailable,becausetheRemoveGeneralization operator introduces a generalization between the subclass andthose superclasses in this case.) Therefore, the impact resolution can bedelegatedtothatofRemovePropertyandRemoveAssociationforthesefeatures(seesections7.4.2and7.4.3).

7.5.RenameNamedElement

Allelementswithanamecanpotentiallyberenamed.InthecaseofEMOF,thiscan be any descendant of NamedElement (see Section 2.3.2 on page 27). Ingeneral,asnamesserveasidentifiersformanyelements,theuniquenessofthenamemustbecheckedprior torenaming.Forexample, thenameofanEMOFClass must be unique in the scope of its package. Hassam et al. define theoperation.allConflictingNames()onelementstoexcludenamecollisionsinco-evolutionrulesforOCLconstraintsandmetamodels[42].

Theparsingandbindingmechanismsof transformation languages takecareofidentifying model elements used in transformation descriptions and providereferences to the involved metamodel elements. Name identifiers in thetransformation descriptions can be changed from the old identifier to the newidentifier(barauseincomments).

7.6.MoveProperty

Apropertyismovedfromoneclasstoanother,withthetwoclassesbeinglinkedby an association with a multiplicity of one-to-one. This ensures that everyinstanceof the targetclass is linkedtoexactlyoneinstanceof thesourceclassand the values of the property can be associated correctlywith the previouslyowning instance. In terms of the use in transformations, references to theproperty are impacted and need to be redirected to the new class along theassociation link. This resolution can be handled automatically for the placeswherepropertiescanfeatureintransformationrules,beingbindingassignments(LHS),filterconditions(LHS)andbindingassignments(RHS).

Figure7.7.:MovePropertyLHSbindingassignmentresolution

7.6.1.BindingAssignment(LHS)

TherelationinFigure7.7handlestheresolutionforanLHSbindingassignmentwhichmakesuseofthemovedproperty.TheNavigationOrAttributeCallExpnacx referring to the property p being moved is extended by aNavigationOrAttributeCallExp nacx2 which extends the expression tonavigate along the association to the new location of the property. This isillustratedbytheexampleinlisting7.3.

Intheexample,thepropertycitywasmovedfromtheclassWritertotheclassAddress, which is linked to Writer by the association member-end propertyaddress.Thevaluebinding for thenew instance is extended from theattributecall expression writer.city to navigate the association betweenWriter andAddressaswriter.address.city.

Listing7.3:ExamplefortheimpactofMovePropertyonaLHSpropertybinding

7.6.2.FilterConditions(LHS)

Theimpactforfilterconditionsusingthemovedpropertyissimilartothatonabindingassignment.Theruleintheexampleinlisting7.3isconstrainedtoonlymatchauthorslivinginSantaFeinline3.Aftertheresolution,thevalueofthemoved property city is fetched from the new location by navigating over theaddressassociationmember-endpropertyintheconstrainingexpression.

The relation inFigure7.8 handles the resolution for filter conditions.Again aNavigationOrAttributeCallExpreferringtothemovedpropertyisextendedtonavigateacrosstheassociationbetweenthetwoclasses.

7.6.3.BindingAssignment(RHS)

If the Move Property operator is used on a metamodel on the RHS of atransformation,allvaluebindingsforthemovedpropertyhavetobeadjustedtoreflectthenewlocationoftheproperty.Thepreconditionoftheoperator,thatthesource and target classes of themove are linked by a one-to-one association,dictatesthatanytransformationthatcreatesaninstanceofoneofthetwoclassesalsohastocreateaninstanceoftheotherandcreatethelinkbetweenthetwo.

ThissituationismodelledbytheresolutionrelationinFigure7.9,whereanyrulewith anout-pattern elementoutEl for the source classclass also has an out-pattern element for the target class class2. The instances of the two classescreatedbytherulearelinkedbythevaluebindingbindingforthemember-endpropertyoftheassociationbetweenthetwo.Fortheresolution,thevaluebindingofthepropertythatismoved(binding2)isshiftedtotheout-patternofthetarget

class.Thevalueof thepropertycanbedefinedbyanyOCLexpressionand ismovedalongwiththebindingasexp:OCLExpression.

Figure7.8.:MovePropertyfilterconditionimpact

Figure7.9.:MovePropertyRHSbindingimpact

Listing7.4:ExamplefortheimpactofMovePropertyonaRHSpropertybinding

Intheexampleinlisting7.4,thepropertycitywasmovedfromtheclassWriterto the classAddress. The value binding for the property ismoved to the out-patternelementforthetargetclassAddress.WriterandAddressarelinkedbytheproperty binding for the address property ofWriter, which is an expressionpointingtotheaddressvariable.Therebythecorrectinstancesarelinked.


ThePushSimplePropertyoperator‘pushes’apropertyfromasuperclasstoallits subclasses and removes it from the superclass. For its impact ontransformationsweneedtolookatallrulesthatmakeuseofthepushedpropertyeitherinthecontextofthesuperclassorinthatofoneofthesubclasses.

For rules that use the property in the context of the subclasses, the impact issimple and no adaptation is needed as the property was previously availablethroughinheritance.

Forruleswithausageinthecontextofthesuperclass,weassumethattheusageisno longerwantedas theproperty itself isno longeravailable in theclasses’context.The resolutioncanbeachievedbydelegating to theRemovePropertyimpact resolutionfor thepropertyandsubclass (seeSection7.4.2). In fact, theoperatoritselfalreadydelegatestotheRemovePropertyoperator,sonofurtheradaptation is needed (bar the alternative detailed below). In summary theresolutionis:

For the use of the property in a binding assignment, thewhole assignment isremoved,iftheRHSpropertyisnon-obligatoryorifithasadefaultvalue.Theuseriswarnedandsyntacticcorrectnesswouldbepreserved.Otherwise,humaninterventionisneededtocreateanewassignmentfortheobligatoryvalue.

For the usage of the property in a filter condition, the whole constraint isremoved,whichmakes the rulepotentiallymatchmoreoften.Theuser is alsowarned of this behaviour. Here a more fine-grained resolution approach ispossibleintheorybecauseofthenatureofthePushPropertyoperator,yet it isnot possible for the current implementation of theATLVM.This approach isdetailedinthenextsection.

FortheRHSofatransformation,rulescanhaveavaluebindingforthepushedproperty.Asitisnolongeravailable,thebindingassignmentisremovedintheresolution.

AnAlternativeResolutionStrategyforFilterConditions

An alternative approach to removing the entire constraint in a filter conditionwhichmakesuseofthepushedpropertywouldinvolverefactoringtheconstraint

tomatchthoseinstancesthatstillhaveaccesstothepropertyafteritispushed,being all instances of subclasses. Hassam et al. use a similar approach whenrefactoringOCLannotatedclassdiagramsbyextendingthePushDownPropertyoperationforOCLconstraintsonMOFclassesoriginallyproposedbyMarković[42,65].AnexpressionattachedtoaclasswithapropertywhichispusheddownintheformoclExpression.p[RestExp]istransformedintotheexpression:

oclExpression -> select(m| m.oclIsTypeOf(Son))-> forAll(m|

m.p[RestExp])

Here p is the property, Son is the subclass to where the property is pushed,oclExpressionsomearbitraryleadingpartoftheexpressionand[RestExp]theplaceholderfortheexpressionpartreferringtop.

ThisapproachwouldbetransferabletoATLbyusingatypecheckandcastingfortheinstancesmatchedbytheruleinquestion,tosomethinglike:

Listing7.5:PossibleconstraintadaptationafterPushDownProperty

Unfortunately, ATL does not yet support the type-casting OCL operation.oclAsType() [5, p. 16]. So this approach, although preferable as it providesmuch more fine-grained resolution options, is not possible with the currentdesignoftheATLVM.


TheimpactofpushingcomplexpropertiesonATLrulescanberesolvedinthesame manner as that of simple properties for all rules that use the pushedproperty directly. If the pushed property is part of a bidirectional associationhowever, rules that use the opposite property are also impacted and needresolution.

ThePushComplexPropertyoperatorclonestheassociationandthepropertyonthe opposite end of the association for each subclass and the cloned remoteproperties are renamed. For transformation rules that use the remote property,

adjustments have to be made for the change in name and the changed set ofinstancesnavigablebythenewassociations.

7.8.1.Impactresolutionfordirectusageofcomplexproperties

In the simple casewhere rules use the complexproperty in the context of thesubclasses, no resolution is needed, as the properties were available throughinheritancebeforethePushComplexPropertyoperatorwasapplied.

For use in the context of the superclass, the impact is also the same for alloccurrencesas that forsimplepropertiesand the resolution is thesame:Whenusedinfilterconditions,inqueriesorinthenavigationforvaluebindingsontheLHS,orinavalueassignmentontheRHS,therespectiveusageisremovedbythe applicable impact resolution relation (see 7.7 formore details). The samerestrictionsasforsimplepropertiesapply.

7.8.2.Impactresolutionforoppositeassociation-ends

Shouldthepushedpropertybepartofabidirectionalassociationhowever,extraimpactdetectionandresolutionisrequiredfortheoppositeassociation-end.Theassociation and the opposite property are cloned by the operator for eachsubclassandtheclonedpropertiesarerenamedtopreventnameclashes.Thisishandledbytheimpactresolutionasfollows:

For any occurrence of the opposite property in OCL expressions for valuecalculationornavigation,theexpressionisadaptedtocoverthecombinedsetofvalues of the new properties. For example, in the value binding item <-

statusReport.item thevalueboundto thearbitrarypropertyitem isgivenbytheattribute-callexpressionstatusReport.item.As thepropertyitem issplitup in example 6.14, the value-binding needs to be changed to item <-

statusReport.bookOnTape->union(statusReport.videoCassette).

Thismakesitnecessarytobreakdowntheresolutionintoanumberofsteps:onestep to create a value-binding to any one of the new member-end properties(arbitrarilychosen)oftheformstatusReport.bookOnTapeandsubsequentstepsfor each further member-end property as ->union(statusReport

.videoCassette).

Toassistinthechainingoftheseexpressions,theblack-boxoperationsMark()andisMarked() are used (see figures7.10 and7.11). Mark() ‘marks’ the firstandanysubsequentexpressionstobeextendiblebya->union()expression.Asthe OppositeAssociationEndOther relation is restricted to only apply toexpressions that are marked by a call to isMarked(), the first unmarkedexpressionischosenasachainingstartandallotherexpressionsarechainedon.

Figure7.10.:TheOppositeAssociationEndFirstrelation

ThisresolutionisprovidedbytherelationinFigure7.10forthefirststepandtherelationinFigure7.11forthesubsequentsteps.Intherelationforthefirststep,the NavigationOrAttributeCallExp for the changed member-end property ischangedtopoint tooneof the(new)namesofclonedproperties.Themarkingmechanism is used to indicate that the expression can be extended by asubsequentstepbyaunionexpression.Inthesubsequentstepsperformedonceforeachfurtherclonedassociation, thenewmember-endname is insertedasaNavigationOrAttributeCallExp (nacx2), as an argument of a new union-expression as given by the oc: CollectionOperationCallExp statement. Thiseffectively chains together all new association-end properties into a combinedunion-statement.

Figure7.11.:TheOppositeAssociationEndOtherrelation


Whenasimplepropertyispulledfromallsubclassestoacommonsuperclass,noexistingATLrulesareaffected.Asoneprecondition, thePullSimplePropertyoperatorofSection6.7ensuresthatallsubclassesownthepropertytobepulledprior to execution, therefore the property was available directly before and isavailablenowviainheritance.Thismeansthatnoresolutionisneeded.


As complex properties are linked to associations which are potentiallybidirectional, the impact of pulling complex properties has to cover both thelocal property that is being pulled and the remote association member-endproperty.

For the local property, no change is needed, just as with resolving the PullSimplePropertyoperatordescribedinSection7.9.

The case of the remote property is not as simple if the association isbidirectional,aspotentiallydifferentsetsofinstancespreviouslyavailableunderdifferentpropertiesarenowmergedintoone.

Furthermore, the type of the new combined remote property is that of thesuperclass to which the property is pulled, where previously the instances ofeach of the subclasses where available through their own distinct property.Therefore, the user may wish to use some feature of the linked instances, tomaintain the distinction. This could be achieved by type-checking for thesubclassesandexcludingunwantedonesorcheckingsometertiaryproperty.

Asanexample,iftheresolutionforthePullComplexPropertyoperatorweretofully reverse the impact resolution of the Push Complex Property operator(whichisreasonabletoexpect)statementsoftheformitem<-statusReport.bookOnTape->union(statusReport.videoCassette) should be combined intosomethinglikeitem<-statusReport.item(seeSection6.6).

Yet,as themakeupof thesetsof instancescanonlybedeterminedat runtimeandcandiffer foreachmodel instance,noassumptioncanbemadeas to howstatementsusingremotemember-endpropertiesshouldberefactored.Therefore,userinterventionisneeded.


TheimpactoftheRestrictPropertyoperatoronATLrulesisconfinedtoplaceswhere rulesmake use of the property itselfwhile the remote property can bedisregarded as it is not navigable (and not owned by a class). The possibleoccurrences of the restricted property are the same as for the Push SimpleProperty operator: LHS filter conditions, value calculations in LHS bindingassignmentsandtargetsofRHSvaluebindingassignments.

On the LHS for both filter conditions and value calculations no resolution isrequiredastheexpressionsremainsyntacticallyvalidandthereductionofthesetofinstancesthepropertylinksistheintendedoutcomeofrestrictingtheproperty.

OntheRHS,rulesmayexistthatattempttoassigninstancesofthesuperclasstotherestrictedproperty.Heretheuserneedstointervene,assuchatransformationrulewouldbecome invalidotherwise.Thiskindof impactcannotbe resolvedautomatically,astheintentioncannotbederivedandanumberofresolutionsaresensible, like changing the matched type of such a rule or restricting thecandidateinstancesusingan.oclIsTypeOf(subclass)expression.


TheimpactoftheGeneralisePropertyoperatoronATLrulesisconfinedliketheRestrictPropertyoperatortoplaceswhererulesmakeuseofthepropertyitself:inLHSfilterconditions, invaluecalculationsinLHSbindingassignmentsandastargetsofRHSvaluebindingassignments.Noneof theserequireresolution,as the set of possible value instances is extended by the operator and all oldinstance continue tomatch.After the use of the operator, the user can extendrulesandemploythegeneralisedpropertyinitswiderapplication.

Figure7.12.:RelationfortheimpactresolutionofExtractClassonRHSmetamodels

7.13.ExtractClass

The impact of the Extract Class operator only needs to be resolved if theoperatorwasusedontheRHSmetamodelofatransformation.FortheLHS,all

rulesremainvalid,as theclassfromwhich thenewclass isextracteddoesnotchange and ismatched asbefore and all its properties remain accessible tobeused invaluebindings.Should thenew,extractedclassbeadapted further, theimpact resolution for operators like Move Property or Add Element can behandledinasubsequentstep.

FortheRHS,allruleswhichcreatedinstancesoftheclassfromwhichthenewclassisextractedneedtobeadaptedtoalsocreateinstancesofthenewclassandtosettheassociationlinkbetweenthetwo.Thisimpactresolutioncanbefullyautomated,seeFigure7.12:Foreveryrulewithanout-patternelementmatchingtheclassc1fromwhichweextract,anewout-patternelement is introducedtocreateaninstanceofthenewclassc2,andavaluebindingtocreatethelinkforthenewassociation.

Listing7.6:ExamplefortheimpactresolutionofExtractClassonaRHSmetamodel

Theexample in listing7.6 shows a rule after impact resolution,where a classStatusReport was extracted from the class AudioCassette. The rule nowcreatesinstancesofbothclassesfromonesourceinstance.TheassociationlinkbetweenthetwoissetbythevaluebindingonBookOnTape,wherethepropertystatusissettothevariablestatusReportoftheintroducedout-patternelementaddedintheimpactresolution.

7.14.InlineClass

The impact of the Inline Class operator needs to be resolved both formetamodelsthatareusedontheLHSandtheRHS.Againwerefertotheclassthatismergedasthe‘merged’classandtheclassthatremainsasthe‘target’.

Theuseof theoperatoreffectively removes themergedclassand thepropertymember-endoftheassociationbetweenthetwoclassesonthesideofthetargetclass. Therefore, the resolution has to handle the removal of a class and apropertyinasuitablemanner.

For the LHS of a transformation and the removal of the merged class, theknowledgeabout themergeallows for rules thatmatch themergedclass tobediverted to match the target class instead. This resolution can be appliedautomaticallybytherelationgiveninFigure7.13.

For ruleswhichmatch the targetclass,nochange isneededas theclass isnotmodified.

Figure7.13.:RelationtodivertamatchedrulefromamergedclassfortheInlineClassoperatorontheLHS

If theremovedpropertyisusedtoderiveavalueinaLHSvaluebinding,userintervention is required, as somenewway to derive the value is needed.Thiscasemay also indicate that the current rule and some other rulematching themergedclasscanbecombinedintoamoreconciseversion,whichtheusermaywishtocreate.

FortheRHS,asthemultiplicityoftheassociationbetweenthemergedandthetarget class must be one-to-one for the operator to be usable, every validtransformationwhichcreatesaninstanceofthemergedclassmustalsocreateaninstance of the target class and set the association link between the two. This

meansthattherulemustfeatureoneout-patternelementforeachclassorrefertoaninstancecreatedbyanotherruletolinkthetwo.

As both themerged class and themember-end property are removed,we canremove thevaluebindingon the targetclass for themember-endproperty.Wethen need to remove all out-pattern elements which create instances of themergedclasstocoverbothpossiblecasesdescribedabove.

Theremovalofboththeclassandthepropertiescanbeachievedusingrelationsforthegeneralremovaloftheseelements:thevaluebindingisremovedbytherelation for the removal of properties on theRHSdefined inFigure 7.6 . Theremoval of the out-pattern elements is handled by theRemoveOutPatternElement relation defined for the removal of classes, seeFigure7.2.


Asuperclassisextractedfromoneormorechildclasses.Commonfeaturesofthechildrenarepulledupintothenewparentclass.Thisoperatorhasnoeffecton theapplicabilityof rules,but rulescanbe simplified inonecase: if twoormorerulesmatchtwoormoreofthechildclassesandonlythecommonfeaturestobepulled to theparentclassareused in the rulesand theout-patternof therulesmatch, the rules canbecombined intoone rulematching thenewparentclassinstead.ThisbehaviourisinversetotheduplicationofrulesintheFlattenHierarchy.


TheFlattenHierarchyoperator(6.14)reducestheinheritancehierarchybetweenclasses by pushing all properties from a parent class to all children and thenremovingtheparentclass.AlthoughthisisachievedbyrepeatingtheoperatorsPushSimple /ComplexProperty (6.5,6.6) and then removing the parentwithRemove Class (6.3.3), the impact resolution for Flatten Hierarchy can beimprovedbeyond the combined impact resolutionof theoperators involved inonecase,wichisdiscussedinthenextsection.

7.16.1.ImpactResolutionofFlattenHierarchyonLHSSuperclassRules

AssumingFlattenHierarchy isusedontheLHSmetamodelandthereisarulethatappliestothesuperclassinthesourcepattern.Beforethechange, thisrulewould be executed for all instances of subclasses as well as for those of thesuperclass.Iftheruleissimplyremoved(aswouldbetheimpactoftheRemoveClassoperator),targetelementsarenolongercreatedwheretherulepreviouslymatchedsubclassinstances,althoughonlythesuperclasswasremovedfromthemodel.Thisisdeemedanunexpectedresult.

Listing7.7:ExamplefortheimpactofFlattenHierarchyontheLHS(before)

Weproposethefollowingresolutioninstead:Withtheextraknowledgeavailablewhen theFlattenHierarchy operator is used explicitly, a copyof the rule thatmatches the superclass is created for each subclass and its source pattern ischangedtomatchthatsubclass.Thentheoriginalruleforthesuperclasscanberemoved.

The resolution is illustrated by the following example. Before the operator isapplied,theruleinlisting7.7matchesthesuperclassCirculatingItemtocreateelementsofthetypeCatalogueEntry.

When the classCirculatingItem is now removed to flatten the hierarchy (asseeninFigure6.23),theruleneedstobeduplicatedandadaptedtocontinuetocreate CatalogueEntrys for all instances of the subclasses Book andVideoCassette.Theresultingtransformationisgiveninlisting7.8.

ThisresolutionforsuperclassrulesisgivenbytherelationisFigure7.14 .Foreveryrulethatmatchesthesuperclasscinanin-pattern,anewrule(rule2)iscreated, which matches the subclass c2 instead. The cloning of the rule isperformed by the relation in Figure 7.15 . This relation is defined betweenelementsoftheATLdomainonbothsides, i.e. it isahelper-relationthatsolely

modifiesATLstatementswithoutanyreferencetoEMOF.Itcreatesadeepcopyofamatched-rulebyrecursivelycloningtheentireexpressiontreeoftherule.Inthe overall process, two black-box operations are used. The CloneSubTree()operationcreatesacloneofanexpression, includingallcontainedexpressions,i.e. a clone of the whole AST sub-tree of the expression. TheSpecialiseMatchedRule()operationchangesthein-patternelementofaruletomatchanotherclass.In thismanner, theclonedrulesareassignedtomatchthesubclassesintheflattenedhierarchy.

Listing7.8:ExamplefortheimpactofFlattenHierarchyontheLHS(after)

Figure7.14.:RelationfortheimpactofFlattenHierarchyonsuperclassrules

Figure7.15.:Relationtocloneamatched-ruleandallchildstatements

7.16.2.ImpactResolutionofFlattenHierarchyforOtherCases

Rulesthatusethesubclassarenotimpacted,neitherfortheLHSnortheRHS.The subclasses only receive features that were available previously throughinheritanceandthatarenotchangedotherwise.

The finalpossiblecase for impactoccurson theRHS,where rulesmaycreateinstancesofthesuperclass.HeretheresolutionoftheRemoveClassoperatorcanbe applied, which removes the out-pattern element for that class and furtherremovesrulesthathaveemptyout-patternsasaconsequence(seeSection7.4.1).


TheAssociation toClass operator replaces an associationbetween twoclassesbyaclassconnectingthetwoclassesinstead.

On the LHS, the operator impacts all parts of a transformation rule whereselectionornavigationoverthereplacedassociationoccurs.Thisisexpressedinstatementsthatusethepropertiesthatservedasmember-endsoftheassociation.Astheassociationisreplacedbyaclassthatisconnectedtotheoriginalendsoftheassociationby twonewassociations, thenavigationorselectionstatementsneed to be extended by an extra step across the new class. The resultingSequenceneedstobeflattenedtoreceivethesameSequenceasbefore.Thisisachieved by using the OCL collect() operation. An expression likeborrower.borrowedwouldbemodifiedtoborrower.borrowed->collect(l|l.lendable)(assumingthatthepropertyborrowedidentifiestheassociationthatwas replaced in the type of the variable borrower). This resolution can beperformedautomaticallybothforLHSbindingassignmentsandfilterconditions.

For the impact resolution on metamodels used on the RHS, whenever aninstance of the remote side of the replaced association was created, now aninstanceofthereplacementclasshastobecreatedalso.


Fortheapplicationof theGeneralization toCompositionoperatoron theLHS,we discern between rules that apply to the parent and those that apply to thechildclass.

Rulesthatapplytotheparentclassbeforetheuseoftheoperatordonotneedtobeadaptedasthesetoffeaturesintheparentclassandthenumberofinstancesremainthesameaftertheoperatorusage.

For rules that apply to the child class, references to properties of the formerparent class need to be redirected using the new association to point to theassociatedinstanceoftheformerparentclass.

For theRHS,rulescreatingparentclassescanremainunchanged.Ruleswhichpreviouslycreatedchildclassesarechangedtocreateaparentclassforallparent

properties and an associated instance of the new class for all properties thatpreviouslybelongedtothechildclass.


TheimpactresolutionfortheuseoftheIntroduceCompositePatternoperatoronLHSmodelshastodifferentiatebetweenrulesthatmakeuseoftheparent-childassociationandrulesthatdon’t.Forthelattercase,rulescanremainunchangedas for bothof thenewly introduced classes (leaf andcomposite) all propertiesandrelationsremainavailablethroughinheritance.

Forrulesthatmakeuseoftheassociation,wesuggestthefollowingresolution:Theruleisduplicatedandeachcopyisspecializedtomatchaspecificsubclass(leaf or composite). Then the association usage is removed from the rulematching the leaf, if possible.This is not the case if it is bound to a requiredpropertyontheRHSanduserinterventionisneeded.

For the RHS, all rules that create instances of the target class prior to theoperatorusage require resolution,as theclass ismadeabstractby theoperatorandadecisionhas tomadeofwhether tocreatean instanceof thenew leaforcomposite classes.This ‘nature’ of the instanceswas previously determined atruntime: if an instancehaschildren it acts likeacomposite, ifnot, likea leaf.This information has to be made explicitly at design time after the operatorusage,sotheuserneedstoprovidefurtherinformation.

CHAPTER8

RelatedWork

In general, any coevolution solution for two linked or dependent types ofartefactsoftheMDScanbeconsideredrelatedtotheapproachpresentedinthiswork.Wefoundthreegeneralcategoriesofapproachesaccordingtothetypeofdependentartefactsthatareaddressed:Coevolutionofmetamodelsandmodels,coevolutionofmodelsandassociatedOCLconstraintsandapproachesthatlikeours,dealwiththecoevolutionofmetamodelsandtransformations.Wediscussthe threecategoriesbelow, indicating their relevanceforourapproach.Section8.4providesanoverallcomparisonoftherelatedapproaches.

8.1.CoEvolutionofMetamodelsandModels

AvarietyofapproachesinscientificresearchonMDEaddress thecoevolutionproblem between metamodels and models. The aim is to reconcile brokenmodelswithchangedmetamodelswithavaryingfocusonautomation.Mostareconcerned with bulk adaptation to cater to the evolution of large numbers ofmodels for thesamemetamodel.Thoseapproaches thatareoperationbasedorthat provide sets of complex adaptation or refactoring steps are of particularinterest as they are closest to our approach.Of these,Herrmannsdoerferet al.proposes the most comprehensive approach to our knowledge, providing acatalogue of 61 operators and tool support for the coevolution of Ecoremetamodels and models [44]. Another closely related approach is given byCicchetti et al. [22], as they provide a classification for 16 metamodelmodificationsaccordingtowhethertheycanberesolvedautomaticallyorrequirehumaninterventionintermsoftheimpactondependentmodels.TheapproachbyWachsmuthisdeemedclosestasheproposesastepwiseapproachandusesanQVT-like syntax in the operator formalisation [107]. Some of the operatorsintroducedinchapter6areadaptedfromWachsmuthsworkonmetamodelandmodelcoevolution.

Wachsmuthproposesamanual,stepwiseapproachofmetamodelsanddependentmodelstohandlecoevolution.Theapproachconsistsofasetof16adaptationsforwhich the semanticand instance-preservationpropertiesarediscussed.Theadaptationsare taken fromworkon refactoringandgrammarwareengineering.TheadaptationsareprovidedinanQVT-R-likesyntaxandnaturallanguageforthemetamodelpart.Forthemodelpart,theimpactoftheadaptationsisgivenasa‘transformationpattern’,beingapartialtransformationthatistobeinstantiatedfortheconcretecase.[107]

We base a number of our operators on Wachsmuth’s adaptations, modifyingthem to co-evolving transformations and formalizing them for EMOF usingstandard QVT-R graphical syntax. Section 6.2 provides an overview of ouroperatorsandtheirsources.

Cicchetti et al. provide a set of 16 common and complex modificationsperformed on metamodels and analyse the impact on dependent models. Thechangesare classifiedaccording to a scheme, establishing theclassof1)non-breakingchanges,requiringnoco-adaptationofdependentmodels;2)breakingbutresolvablechangesforwhichtheconformancerelationcanbere-establishedautomatically, and 3) breaking and unresolvable changes for which userinterventionisrequiredforadaptation.[21,22]

They further propose the use of a model difference calculation to determinewhich of the changes has taken place. These changes are recorded using adifference model, which expresses for each metamodel entity, involved in achange,whether itwasadded,removedormodified.Eachof theseadaptationscanbecategorisedaseitherbreakingresolvableorbreakingunresolvable.Theypropose the generation ofATLmodel transformations for the changes in bothcategories to automate the adaptation of dependent models. The generatedtransformations for the breaking unresolvable category are only ‘stubs’ to beextendbyhandbytheuser.[23]

Herrmannsdoerferetal. propose anoperator-and recording-based approach forthe coevolutionofmetamodels andmodels.Theyprovide an editor to adapt ametamodel using pre-defined operators and record the operator usage andresulting changes. The impact of each operator on conformingmodels is pre-definedanddeterministic.Inthismanner,anynumberofconformingmodelscanbe adapted automatically. Since the nature of the coevolutionmay be domainspecificand isnotpre-determinable ingeneral,userscandefinenewoperators

forspecificcases.Anexampleistheadditionofpropertieswithrequiredvalues.Models have to provide values to be syntactically conformant and the valuesdependontheowninginstanceandthedomaintobealsosemanticallyvalid.Theoperator for this case could contain an algorithm to derive semantically validvalues for all encountered cases, thus being domain specific in nature. Thesuccessofsuchanoperator-basedapproachisdependentontheusedlibraryof(reusable)operators.[44]

The catalogue of operators is comprised of 61 operators for metamodel andmodel coevolution and covers all our operators except for the IntroduceComposite Pattern operator which reproduces the ‘introduce composite’refactoringfromOOrefactoringwork[34].Theoperatorsareneitherformalizedformetamodelsnor formodelsas suchbut implemented instead in tooling forEcore.ThemetamodelformalismusedisEMOF-like.Thetoolingisdesignedtobe extendible so that domain specific, custom operators can be created to co-evolvemodels.[44,45]

8.2.CoEvolutionofModelsandOCLConstraints

TheareaofcoevolutionofmodelsandOCLconstraintsprovidesapproachesforthevalidationandadaptationofOCLexpressionslinkedtochangingmodels(ormetamodels).WhileCorreaandWerner[25]andCabotandTeniente[20]focuson the refactoring of OCL constraints in isolation, the relationship between amodel andattachedconstraints canbe treatedas a coevolutionproblem:whenthemodel ischanged theconstraintsneed tobeadaptedaccordingly to remaincorrect anduseful [42,65].OCLconstraints are text-basedand refer tomodelelementsandcanbeinterpretedinthecontextoftheelements(seeSection3.4).

ThecoevolutionproblemforOCLconstraints isverysimilar to that formodeltransformations,as:

1. OCLexpressionsandmodeltransformationsaretextualstatementsthatareattachedtoprimarilygraphicalmodels,

2. OCL is declarative in nature, like the largest parts of the transformationlanguagesATLandQVT-Rand

3. ATLandQVTbothmakeuseofembeddedOCLexpressionsforanumberofpurposessothatOCLexpressionsinsidethetransformationsneedtobe

consideredalongwiththetransformations.

TheimpactofmetamodelchangesontheOCLconcretesyntaxinthecontextofmodeltransformationsislookedatindepthinchapter5.6.2.

Marković and Barr present a set of refactoring rules for UML 1.5 ClassDiagramsandlinkedOCL2.0expressions.Thesetcontains15rules,wherethethree push down rules are only specified for cases with one subclass. Therefactoring rules are provided as transformations in a QVT-R-like graphicalsyntax.The impactof the refactoring ruleson theOCLexpressionsembeddedintotheUMLdiagramsisalsoprovidedintheQVT-R-likegraphicalsyntaxanddiscussedinnaturallanguage.[65]

Hassam et al. propose an assistance system for the coevolution of OCLconstraintsandmetamodels.Thesystemiscomprisedof19operationsofwhich7aredefinedbyHassametal.usingaQVT-R-likegraphicalsyntaxbothfortheevolutionof themetamodelandthecoevolutionof the linkedOCLexpression.[42]

Acomparisonof thefeaturesof the twoOCLcoevolutionapproacheswith themetamodelandmodelcoevolutionapproachesisprovidedinTable8.1below.

8.3.CoEvolutionofofMetamodelsandTransformations

AnoverviewoftherelatedworkformetamodelandtransformationcoevolutionisgiveninTable8.2.

Garcésetal.proposeanapproachthatusesexternaltransformationcompositionto tackle the problem of metamodel and transformation coevolution [36, 37].Insteadofadaptingexistingtransformationsinresponsetoametamodelchange,theysemi-automaticallygenerateasetofnewtransformationsthatarechainedtotheoriginaltransformationtoproducearesultinaccordancewiththemetamodelevolution. The original transformation remains unchanged. The metamodelchangesarenot specifiedby theuserbutdiscovered semi-automatically.TheirapproachisbasedonEMFmetamodelsandATLtransformations.Itcoversasetof10changeoperatorsthatarenotexplicitlyspecified.

Levendovszkyetal.proposeacoevolutionapproachsuitableforthecoevolutionof Domain Specific Language (DSL)s andmodel interpreters, which take the

form ofmodel transformations [62]. The transformations and the models andmetamodels involved are based on the Graph Rewriting and Transformation(GReAT) language and tooling framework [8]. The changesmade to theDSLmetamodelareexpectedtobemadeavailableinaproprietarymodelwhichalsoserversasabasisforthecoevolutionofdependentmodels.Allchangesmadearecaptured by one such changemodel and executed in bulk to adapt dependenttransformations. The approach covers fully automated and semi-automatedchangesbutnotthosethatareconsidered‘fullysemantic’.Anexampleofafullysemantic change is the addition of a new model element, as the intendedtransformationtargetontheRHSisunknown.Theydiscussasetof10possiblemetamodelchangesofwhich8areaddressedbytheirapproach.Theimpactofthe changes and the resolutions are not formalized but providedprogrammaticallyaspartoftheGReATtoolset.

Méndezetal. outlineanoperator-basedapproach for transformationmigration[66]. It is not a fully implemented approach so that some details are notavailable. The set of ten available operators and the possible resolution fordependentATLmetamodelsaredescribedusingnaturallanguage.

Whether the changeoperators are detectedor their application recorded is notspecified.

García and Díaz provide an approach based on the detection of simple andcomplexoperatorsbymodeldifferencing[38].Thedetectionprocessoccurs intwo steps: first, simple metamodel changes are detected using a modeldifferencingframework.Inthesecondstep,complexchangesaredetectedonthebasisof thesimplechangesandexpressedasoperators.Theoperatorsare thenusedtosemi-automaticallyadaptdependentATLmodeltransformationsinbulk.The impact of the detected complex operators is described using semi formalpredicates and implemented usingATL transformations that take the impactedtransformation and the detected operator as input and produce an updatedtransformationasoutput.Casesthatrequirehumaninterventioneitherleadtoawarningduring theprocessor leave theresulting transformation incompletesothattheusercanperformmanualchangesafterwards.

DiRuscioetal.proposeanapproachtoperformmetamodelandtransformationcoevolutionwithafocusonpredictingthesignificanceofametamodelchangeintermsofitsimpactondependentmodeltransformationsbeforethechangeisperformed[84].The approach is demonstrated forEMFmetamodels andATL

transformations. Like Levendovszky et al. they require the changes to beperformedonametamodeltobeavailableinasuitableformatbeforeinitiatingthe impactanalysis.Thesuitabilityofametamodelevolution isdeterminedbycalculating the cost of each evolution step in terms of the impact on a set ofdependent transformations. The cost function considers a weighted sum ofimpact resolutions according whether they can be performed automatically,semi-automaticallyorsolelybyhand.TheysuggesttheuseoftheirEMFMigratetool toperform thebulkadaptationof impacted transformations if theeffort isdeemedappropriatebytheuser.EMFMigrateusesmigrationrulestodescribedchanges performed onmodel transformationswhich can be customised by theusertoperformmanualadaptation.

8.4.Comparison

Thefeaturesoftheoperator-basedcoevolutionapproachesformodelsandOCLconstraintsandmetamodelsandmodelsaresummarizedinTable8.1below.Thefollowingaspectswereregarded:

metamodel The metamodel column indicates which metamodellinglanguage the operators of the approach are designed for. They can beappliedtomodelsconformingtothesemetamodels.

targetartefactThiscolumn indicates the typesofartefacts thatare tobeco-evolvedintheapproach.

formalismTheformalismcolumncontainsthelanguagetheoperatorsweredescribedin.

nr.ofoperatorsThisisthenumberofoperatoravailableintheapproach.

automationThiscolumnindicateswhetherornottheapproachisaimedatautomatingthecoevolutiontask.

impactdescriptionThiscolumnindicateshowthe impactof theoperatoronthedependentartefactisformalised.

Fortheoperator-basedapproaches,weseeavaluablecontributioninourworkintheformalisationofboththeoperatorandtheimpactinQVT-RandthecompletesupportoftheEMOFmetamodel.Weexpectthatourstepwiseapproachcanwellbe combined with approaches for other target elements, so that an overall

coevolutionapproachmaybepossible,usingasinglesetofoperators.Wedeemthistobefuturework(seeSection11.3).

Table8.2providesacomparisonoftheavailableapproachesforthecoevolutionofmetamodelsandmodeltransformations.Thefollowingaspectsaredetailed:

source/target This column lists the side of the transformation themetamodelchangecanbeaddressedon.‘S’indicatessource(LHS)and‘T’target(RHS)metamodels;‘S&T’both.

requiresheuristicsWhetherornot theapproachdependsonheuristics todeterminethedifferencebetweentheevolutionarystates.

supportedchangetypesThis is thenumberofdifferent typesofchangesare supported by the approach. For operator-based approaches, this is thenumberofoperators.

tech.spaceThiscolumnliststhetechnologicalspacetheapproachisbuildfor;i.e.which transformationframeworkand language issupported in thecoevolution.

change description How are the changes that an operator makesformalised?

impact description How are the impacts an operator has on a modeltransformationformalised?

modeofexecutionThiscolumnindicateswhethertheapproachisdesignedfor the bulk adaptation of transformations after a number of changesoccurredorwhetherastepwiseadaptationisintended.

For the related coevolution approaches for model transformation, the greatestdifferencebetweenourapproachandtheothersliesinourfocusonprovidingastepwise method so that coevolution and development activities can beundertakenclosely together.Acoevolutionmodificationcanbeperformedandall transformations updated to be consistent, after which forwardengineeringtasks can follow immediately.We support this approach by demonstrating theclose integrationwith commonMDE tooling. Furthermore, our approach doesnot relyonheuristics andprovides formalisationofboth theoperators and theimpact onATL transformations.We expect that a descriptionof operators and

impacts that is aspreciseaspossible tobenecessary, to accuratelypredict thebehaviour of both and to be able to provide an unambiguous implementation.Furthermore, to our knowledge, our approach is the only one to support thecompleteEMOFmetamodel.

Table8.1.:Comparisonofoperator-basedapproachesforcoevolution

Table8.2.:Comparisonofapproachesformetamodelandtransformationcoevolution

PARTIII

ValidationandConclusion

CHAPTER9

Evaluation

Thischaptercoverstheevaluationoftheco-evolutionapproachandtheimpactresolution for ATL transformations as presented in chapter 5.4. Section 9.1discussesaspectsof completenessof theoperatorsbothon themetamodel andthe transformation level. InSection9.2 theuseofoperators ina co-evaluationscenario containing a stepwise metamodel evolution and the resolution ofimpactsonadependenttransformationispresented.Section9.3summarisesthechapter.Aproofofconceptprototypeofintegratedtoolsupportfortheapproachisdiscussedindetailinthenextchapter.

9.1.Completeness

In terms ofmetamodel evolution, a set of operators is complete if any sourcemetamodel can be evolved into any target metamodel [45]. This level ofcompleteness is achieved by the operators presented in this thesis for EMOFmetamodels. It can be demonstrated by reducing any sourcemetamodel usingtheRemoveElementoperatorsuntil it isemptyandthenrebuildingitusingthecorrespondingAddElementoperatorsofSection6.3:

We begin by removing all associations between classes from any givenmetamodel. Next, all properties and operations are removed and thegeneralisationhierarchycanbediscarded.Thenalltypesareremoved,includingenumerations and enumeration literals, data types and the classes. Finally, theemptypackages canbe removedand themetamodel is empty.Themetamodelcan be rebuild using the inverse approach and theAddElement operators: thepackages are created first, then all types, the inheritance hierarchy and finallypropertiesandassociations.

Completenessonthesideofthetransformationsisverydifficulttoachieveandpossiblyimpractical.Herecompletenesswouldmeanthatanyvalidevolutionof

ametamodelanddependent transformation intoanothercanbeachievedusingthe operators. As transformation languages like ATL and QVT are Turingcomplete, the set of operators would need to be very powerful to achievecompleteness.Thepracticaluseofsuchanoperatorsetmayalsobedoubtful,asitwouldneedtocovertheadditionandremovalofeverypossibletransformationlanguageconstructandanyvalidcombinationofconstructs.Suchanoperatorsetwould inevitably be very large and present management issues of its own.Therefore thepracticalusefulnessof theapproachlieswith theapplicabilityofthe operators, and the ability to use the co-evolution approach in closeconjunction with other development and modelling activities and notcompletenessonthetransformationallevel.

9.2.PetriNetEvolutionScenario

This section covers an evolution scenario of a metamodel evolution incombinationwithaco-evolvingATLmodeltransformationscenario.

9.2.1.MetamodelEvolution

The evolution is performed in several steps from a simple to a moresophisticatedmetamodelforPetrinets[107].Thestatesofthemetamodelduringthe evolution are given in Figure 9.1 . The first state e0 describes a simpleversion of a metamodel for Petri nets; it consists simply of transitions andconnectedplacesso thateach transition is required tohaveat leastonesourceandtargetplace.Duringthecourseoftheevolution,themetamodelisextendedbytheconceptofaweightedarcinsteadofsimpleconnections.

e0:

e1:

e2:

e3:

e4:

Figure9.1.:Petrinetmetamodelevolution[107]

Thearcisrepresentedbyaclasswithaweightproperty,whichcanbeassignedfor each instance, extending the Petri net concepts that can be modelled.Furthermore, ageneral superclass is addedwhichprovidesanameproperty toelements.Thefinalstateisshownine4.

Thisevolutionfromstatetostatecanbereproducedusingoperatorsasfollows:

e0Thisistheinitialstate.

e1 The Association To Class operator is used on both associations betweenPlaceandTransitiontointroducethetwonewclassesPlaceToTransArcandTransToPlaceArc in thedirectionofPlace toachieve thisstate.Thismeansthat for every instance ofTransition before the evolution, one instance ofeachofthenewclassesPlaceToTransArcandTransToPlaceArcisexpected.The operator introduces the extra associations needed and adjusts themultiplicity of the association-ends accordingly and the names of theassociation-end properties as provided by the software architect in theresolution.

e2A new abstract classArc is introduced, fromwhich both of the previouslyadded classes PlaceToTransArc and TransToPlaceArc inherit. This can beachieved using the Extract Superclass operator. As the Arc class is to becontained by the PetriNet class, a new association between the two isintroduced.ThiscanbedoneusingtheAddAssociationoperator.

e3TheabstractclassArcreceivesanewpropertyweightoftypeint.ThiscanbeperformedbytheAddPropertyoperator.

e4TheclassesPlace,TransitionandPetriNetaregivenacommonabstractsuperclassElementwithapropertyname.This canagainbeachievedusingtheoperatorsExtractSuperclassandAddProperty.

9.2.2.TransformationImpactResolution

We chose a transformation from a transformation scenario in the ATLTransformationZooasabasisforanimpactanalysis[46],asitcloselymatchesthe finalmetamodel in statee4. The transformation scenario provides a set oftransformations to convertbetweenPetrinets andpathexpressions.Figure9.3containsanexampleofaPetrinet andFigure9.2amatchingpathexpression.Path expressions describe the directed graph underlying a Petri net in textualformasorderededgeswhile thePetrinetmodeluses thecommon ‘place’ and‘transition’semantics.

pathf;(g;h+k;m*;n);(p+q);sendFigure9.2.:Textualpathexpression[46]

Figure9.3.:Petrinetexample[46]

Figure9.4showsthemetamodelthatservesasASTforsuccessfullyparsedpathexpressions and is used on the LHS of the model transformations in thisscenario. We chose the PathExp2PetriNet transformation to reconstruct the

evolution impact of the metamodel evolution presented above. Thetransformationisgiveninlisting9.1inabridgedform6.

For theoffset for theevolutionwithstatee0,weprovide the transformation inlisting9.2toconvertbetweenpathsandinstancesofthesimplemetamodel.

The impact resolution for the evolution of the Petri netmetamodel performedthroughoperatorapplicationisasfollows:

Listing9.1:AbridgedPathExp2PetriNettransformation[46]

Listing9.2:Primarytransformationstatematchinge0

Figure9.4.:Thepathexpressionmetamodel[46]

i1 TheAssociation To Class operator for the associations between Place andTransition introduces two new classes PlaceToTransArc andTransToPlaceArc. Impact is detected for the Transition rule. In theresolution, newout-pattern elements are created for instances of the classesPlaceToTransArcandTransToPlaceArcalongwiththePetrinetTransition.ThenewinstancesarelinkedtotheTransitionusingtheoriginalsourceandtargetStatesof thepathexpressionTransition.Thisconcludes the impactresolutionforthefirstevolutionstep.

i2 First, a new abstract class Arc is introduced using the Extract Superclassoperator. No impact occurs as there are no rules in the transformation thatmatch theclassesPlaceToTransArc andTransToPlaceArc.Otherwise, suchrulescouldhavebeenmerged.InadditiontotheintroductionoftheclassArc,anewassociationisadded.Thisadditionhasnodetectableimpact.TheuserhastoextendtheMainruletoprovidethecontainmentconditionforallarcs:arcs<-thisModule.allTransitions. This value binding makes use of thehelperallTransitionswhichisalsoaddedmanually.

i3Duringthisstep,theabstractclassArcreceivesanewpropertyweightoftypeint using the Add Property operator. The transformation isextended toprovideadefaultvalueof‘1’forallweights.Thisisasemanticchangeandisperformedmanually.

step

operator impact

automaticresolution

manualaddition

i1 AssociationtoClass

yes yes no

i1 AssociationtoClass

yes yes no

i2 ExtractSuperclass no n.a. no

i2 AddAssociation no n.a. yes

i3 AddProperty no n.a. yes

i4 ExtractSuperclass no n.a. no

i4 AddProperty no n.a. yes

Table9.1.:Resultoverviewoftheevolutionandthematchingimpactresolution

i4TheclassesPlace,TransitionandPetriNetaregivenacommonabstractsuperclassElementusingtheoperatorExtractSuperclassandanewpropertynameusingAddProperty.Bothoperatorshavenoimpact.Thetransformationagainhasnorulesthatarethesameforanycombinationofthethreeclassesso thatExtractSuperclasshasno impact.Thenameproperty isoptionalandrequiresnodefaultvalue. Instead, theusercanextend therules toprovideabindingfornameusingvaluesfromthepathexpressionmetamodel:name<-pet.namefortheruleTransitionoradefaultvaluename<-’’forState.

Table9.1providesasummaryoftheoperatorsused,theirimpactandtheimpactresolutionperformed.

9.3.Summary

Thischaptercovers theevaluationofourapproach.While thecompletenessofthesetofoperatorsonthemodellevelcanbeshownandisuseful,completenessonthetransformationlevelisdifficulttoachieveandmostlikelyimpracticalinuse. Instead, the close integration with other MDE tooling and activities isimportant. How such integration can be achieved is demonstrated in the nextchapter in detail.ThePetri net scenario discussed inSection9.2 demonstrateshow the operators and the impact resolution can be applied to the stepwiseevolutionofametamodelandadependentmodeltransformation.Theevolutioncontains both restructuring and extension steps. The proof of concept of theoveralltoolsupportisdiscussednext.

9.2.3.Discussion

As can be seen in Table 9.1, the entire evolution of the metamodel can beperformed using operators. Furthermore, the impact on the dependenttransformationwas detected and resolved automatically. Some of the changesperformedwereextensionsofthesemanticsofthemetamodeland,althoughnotcreating an impact to the syntactic correctness of the transformation, requiredmanualadditionstothetransformationtobecomplete.Thissuggeststhatacloseintegrationof co-evolution tooling anddevelopment tooling is sensible so thatthetwoactivitiescanbeperformedineasysuccession.Theotheradvantageoftheapproachcanbeseeninthereliableimpactdetection,asonlytheoperatorsfortheadditionofelementsrequireduserattention,potentiallyreducingthetimeneededtosearchforimpactsonallrules.

The next chapter covers the design and implementation details of integratedtooling for the operators, the impact detection and the approach as a proof ofconcept. Itdemonstrateshow theclose integrationwithcommonMDE toolingcan be achieved and that the stepwise approach is suitable to be used inconjunctionwithotherMDEdevelopmentandmodellingactivities.

6ThetransformationwasshortenedbyremovingthisModule.resolveTemp()statementsandcomments.

CHAPTER10

ProofofConceptPrototype

This chapter covers the prototypical tooling for the coevolution approach formetamodels and model transformations. The purpose of the tooling is thedemonstration of the feasibility of the approach in combinationwith commonMDE tooling. The next section introduces the general aspects of theimplementation and Section 10.2 discusses the main prerequisites for anintegrated tooling. InSection10.3 the details of theATL textual editor and inSection10.4thoseofthegraphicalmetamodeleditorarecovered.Sections10.5and10.6coverthedetailsoftheimplementationfortheoperatorsandtheimpactresolution respectively. In addition, Appendix A provides a set ofcomplementaryscreen-shotsoftheoperatorapplicationandimpactresolutionintheprototype,startingonpage223.

10.1.Overview

This section provides a general overview of the projects that make up theprototypical implementation of our approach and the tool integration. Figure10.1 contains a UML 2.5 Model Diagram of the project structure. Eachcomponentoftheprototypeisdiscussedinmoredetailintherestofthischapter.

Figure10.1.:Themajorcomponentsandrelationshipsoftheprototypicalimplementation

ToprovideeditingsupportforATLtransformations,anintegrationwithanATLtextualeditorisneeded.TheeditorneedstosupportthemodificationoftheASTbehind themodel transformation code by an impact resolution andmirror thechangesbacktothetextualrepresentation.Thisisachievedintheprototypebygeneratingatool-setforATLusingtheEclipseXtextProjectframeworkfortheEclipseIDE.(ThedetailsarediscussedinSection10.3below.)Forthispurpose,anXtextgrammarforboththeATLandtheATLdialectofOCLwerecreated.Fromthegrammars,EcoremodelsofboththeOCLASTandtheATLASTwerecreated.TheXtext generator frameworkwas thenused togenerate the toolingand the ANTLR parser [81] for the conversion between the textualrepresentation and the AST. The generated tooling provides basic support forfeatureslikecontentassist,anoutlineview,quick-fixes,aformatter,aserialiser,scopingandvalidationsupport.

Thede.covolprojectscontain thecentralpartsof theprototypeand import theATLeditorprojects.Thede.covol.atlprojectcontainsbindingsupporttomapthemodel typesused in theATL transformation code to actualmodel elements inmemory. The de.covol.operator project contains the implementation of ouroperators for Ecore models (Section 10.5) and the impact detection andresolution for ATL transformations(Section 10.6). The de.offis.graphiti.editorproject contains a graphical editor for Ecore models based on the EclipseGraphitiProject.ItisdiscussedindetailinSection10.4.

10.2.PreliminaryConsiderations

Two general design decision were made for the prototypical implementation.ThefirstisconcernedwiththechoiceofMDEtoolingtointegrateourapproachinto. This choice is discussed in the next section. In Section 10.2.2 theconsequentialadaptationoftheoperatorsfortheEMFimplementationofEMOFare laid out. From Section 10.3 onwards, the implementation details of theprototypearediscussed.

10.2.1.ToolIntegration

Requirement7callsforthecloseintegrationofthetoolsupportforcoevolutionwiththatcommontometamodelandtransformationdevelopmentandtofollowsimilarusagepatterns(seepage72).Forthisreason,thetoolingprovidedbytheEclipseATLProjectforthedevelopmentofATLtransformationsandthe(meta-)modelling tools provided by the EclipseModeling Project were chosen as astarting point.The required integration is twofold; for one, the user should beabletoapplytheoperatorsintheeditorusedfortheeditingofmetamodelsandsecond,theimpactsontransformationsandtheirresolutionsshouldbedisplayedintheeditorusedforATLtransformations.

Forthemetamodelpart,theeditormustsupporttheselectionofelementsandtheselection of the operator to apply to these elements. The choicewasmade toextend an existing graphical Ecore model editor to support the usage ofcoevolutionoperators.ThedetailsofthegraphicaleditoraredescriedinSection10.4.

ThetextualeditorsavailableinEclipsearecommonlybackedbyamodeloftheASTand convert between the concrete textual syntax and theASTon the fly.This means that a good integration approach for the impact resolution is the

manipulationoftheASTmodelusedbytheeditortoperformthecoevolution,sothat changes are immediately reflected in the textual view. Unfortunately theAST used by the ATL editor provided by the Eclipse ATL Project provedinaccessible so that thedecisionwasmade to create aprototypicalATLeditorusingtheEclipseXtextProject.OtherbenefitsofusingXtextaretheavailabilityofsyntax-highlightingoftextsnippets,whichweuseforpreviewsoftheimpactresolution(seeSection10.6.2below)andbettersupportforeditingfeatureslikecodecompletionanderrorhighlighting[102].TheATLtextualeditorisdetailedinSection10.3.

10.2.2.ImplementationforEcore

AstheavailableATLtoolingandespeciallytheATLVMisbasedontheEMFimplementation of EMOF, the operators needed to be translated to the Ecoremetamodel for theprototype.TheEcore implementation isclose toEMOFbuthassomedifferencesthatneededtobetakenintoaccount(seeSection2.4).

Firstoff,EcoreknowstheelementsEAttributeforsimpleandEReference forcomplexpropertiesinsteadofthecombinationofpropertiesandassociationsasin EMOF. Therefore, operators manipulating complex properties wereimplemented to handle EReference elements and those for simple propertiesEAttributeelements.

Secondly, in Ecore, bi-directionality of complex properties is modelled usingtwo EReferences with an opposite property pointing to the pairwise otherproperty,insteadofusingassociation-ends.Thisisregardedforimplementationsof operators for complex properties. The simple types defined for EMOF aremapped toequivalent Java types inEcoreso that thoseareused instead in theimplementation.

Finally,EcorerequiresthatonlyonerootelementexistsineachmodelsothatanXMIserialisationisalwayspossible.Thisistakencareofintheimplementationbyalwayschoosingacontainingelementwhennewelementsarecreated.

10.3.ATLConcreteandAbstractSyntaxImplementation

TheATLtextualeditorusedtodemonstrate thetoolingintegrationwascreatedusingthelanguagetoolingandgeneratorsprovidedbytheEclipseXtextProject.Xtext allows thedefinitionof a languagegrammarwhichdefines the concrete

syntax of aDSL and provides different generators for the creation of anASTmodel, editors for full or partial texts in the DSL with features like syntaxhighlighting,code-completion,errordetectionandhighlightingandmore[102].

AlthoughtheATLASTmodelreleasedwiththe(current)versionoftheEclipseATL Project (Eclipse Helios ATLAS Transformation Language SDK 3.2.1) isbasedonEcoreandwouldbesuitableasabasisforanXtextgrammardefinition,it is not accompanied by a EMF Genmodel (which is needed for the Xtextgenerators)forthegeneratedASTJavaclasses,nordidtheincludeEcoremodelpermitthecreationofsuchanEMFGenmodelduetocontainmenterrorsinthemodel.ThereforeanewATLecoremodelwasbuild for theprototype inclosealignment to the official one and a custom version of the ATL AST wasgenerated using the tools provided byXtext. Since the structure is almost thesame, converting between the officialASTmodel and the customASTmodelshouldbepossible.WerefertothecustomASTimplementationfromnowonas‘theATLAST’unlessotherwisenoted.

Figure10.2.:ScreenshotofthecustomATLeditorimplementation

ThegrammarcreatedfortheATLeditorissplitintotwoparts,onefortheOCLdialectusedbyATLandonefor theATLsyntaxitselfwhichimports theOCL

part.ThefullgrammardefinitionsaregiveninAppendixB,beginningonpage227.The finishedATL editor implementationwith features such as an outlineview,syntaxhighlightingandcodecompletionisshowninFigure10.2.

SomeoftheprimarydifferencestotheofficialATLsyntaxandASTmodelare:

TheAST does not support theATL Query construct, as queries are usedprimarilytoreasonaboutmodels,notfortransformationdefinitionsandarethereforeoflesserconcernforcoevolution.

The Library construct is missing, as it is an alternative structuringmechanismforHelperswhichcanbeusedinaModuledirectlyinstead.

Listing10.1:NewATLASTmodelelements

SupportforcommentsinLocatedElementwasremoved,asXtextprovidesadifferentmechanismforcomments.

AnewASTmodelelementforvariabledefinitionswasintroducedforATL,tobetterseparatetheATLandOCLASTmodels.Itisshowninlisting10.1.

SomefurtherchangesweremadetotheusageofOCLinATLtoimprovetheconformancetotheOCLstandard.

Insumtheseomissionsandchangeswouldneedtobeaddressedtoprovidefullyfunctional tooling forATL or the integration of the impact resolution into theofficialATL tooling could be attempted.Non-the-less, the current prototypicalimplementation is deemed suitable to demonstrate that the integration of ourcoevolutionapproachwithcommonMDEtoolingisfeasible.

10.4.GraphicalModelEditor

The implementation of our approach is build into a graphical editor formetamodels to integrate as close as possible with established workflows formodelling. This fulfils Requirement 7 for common tool integration. For thispurpose we chose a model editor based on the Eclipse Graphiti Projectframework [98]. It was developed by Klaas Oetken to demonstrate differentrefactoringsforEcoremodels[79]andextendedandadaptedtobeabletoselectand perform the coevolution operators. Figure10.3 shows the extended EMF-Library Metamodel example introduced in Section 1.1 in the Covol ModelEditor.

Figure10.3.:ScreenshotoftheintegratedCovolModelEditor

Figure10.4.:Screenshotoftheapplicationofoperatorsinthegraphicaleditor

The editor provides the basic functionality to create, edit and manipulate agraphicalrepresentationofanEcoremodelfile.Thisgraphicalrepresentationisanalternativeviewto thestandard, table-basedrepresentationofEcoremodelsprovided by the EMF. The Eclipse Graphiti Project provides a framework ofbasic functionality common to graphical editors that can be extended andcustomized for graphicalDSLs.TheGraphiti extensionmechanism to interactwiththegraphicalelementsoftheeditorreliesonsocalledfeatures,whereeachfeature encapsulates an action that the user can perform on the model. Theintegration of the operators into the editor is achieved by creating a customfeatureforeachoperator.

Figure10.5.:Detailsofthefeature.operatorpackage

Theavailableoperatorfeaturesareprovidedasapop-upcontextmenuasshowninFigure10.4.Themenuiscontextsensitivetothecurrentlyselectedelementsin the graphical model editor. Whether or not an operator feature is enableddepends on the selected elements and the pre-conditions defined by eachoperator so thatonly thoseoperatorscanbeexecuted forwhichall constraintsare met. For instance, in Figure 10.4, the operators Push Simple Property,ExtractClassandFlattenHierarchyareapplicabletotheselectedItemclass.

Theexecutiondetailsoftheoperatoraredelegatedbythefeaturestoindividualoperatorimplementations.Theuserisguidedthroughthecoevolutionprocessbyadialogwhichcontainsanumberofindividualpagesforeachstep.Thistypeofdialogisalsoknownawizard.

Therelationshipbetweentheoperatorimplementations,theoperatorfeaturesandindividualwizardpagesisshowninFigure10.5.Therelevantclassesare:

OperatorFeature The abstract class OperatorFeature provides the bridgebetween the graphical interface of the model editor and the operatorimplementations. It extends the AbstractCustomFeature extensionmechanismof thegraphiti framework for custom features.The term featurerefersheretobuttonsorwidgets that theusercaninteractwithintheeditor.The operator features are provided as menu items in the context menu of

diagram elements of the editor (see the pop-up menu in Figure 10.4) andextend the basic functionality of OperatorFeature as subclasses for eachoperator available. Each subclass handles the specifics of its operator bytranslating thecurrentlyselectedmodelelements into theparametersneededbytheoperatorandbyprovidingthespecializedwizardpagesfortheoperator.The general functionality provided by OperatorFeature for all operatorfeaturesis:

getName():StringReturnsthenameoftheoperatorforuseinthecontextmenuentry.

canExecute(context: ICustomContext): boolean This method isprescribed by AbstractCustomFeature. It checks whether this operatorfeaturecanbeexecutedunderthecurrentcircumstancesasprovidedbythegiven ICustomContext. The ICustomContext provides the currentlyselectedmodelelements,forinstance.

execute(context:ICustomContext)Executes thisoperator feature for thecontext provided. This entails starting the coevolution wizard andinitializingthelistofchangestheoperatorperformsontheselectedmodelelements.

applyOperator()Aftertheuserprovidesallfurtherinformationrequiredinthecorrespondingwizardandacceptsthechangesproposedbytheoperatorto the currentmodel, thismethod is called to perform the changes. Thismethodisabstractandhastobespecializedforeachoperatortype.

detectImpact():ATLFileImpactSet[0..*] Thismethod is called to detectall impactsonallATLfilescurrentlyactive in theuserworkspace.ThesearereturnedasanATLFileImpactSetforeachATLfile.

resolveImpact()Iftheuseracceptstheimpactsandtheirresolutionofferedbytheoperator,thismethodiscalledtoadapttheATLfilesaccordingly.

Implementations of OperatorFeature Each operator has a matchingimplementation of OperatorFeature. These handle the extraction of theparameters needed by each operator from the currently selected modelelementsandthewizardpagesuniquetotheoperator.

Implementations ofWizardPage Some operators require further informationfrom theuser toperform their functionbesides thecurrently selectedmodel

elements. For instance, the Extract Super Class operator (see page 126)requires a new name for the extracted class and a selection of attributes toextract. These are obtained from the user by the specializedExtractSuperclassWizardPage page. The specialized wizard pages areintegratedintothecoevolutionwizardwhentheoperatorfeatureisexecuted.ThedetailsofthewizardpagesarediscussedfurtherinSection10.5.1.

Implementations of IOperator The behaviour and the impact detection andresolution of the different operators is handled by implementations of theIOperator interface contained in the package de.covol.operator. Thedetailsoftheoperatorimplementationsarediscussedinthenextsection.

10.5.OperatorImplementation

The operators introduced in chapter 6 are implemented as subclasses of theIOperatorinterfaceinthede.covol.operatorpackage.Thepackagecontents,the relevant attributes and operations and the relevant relations to the de.covol.operator.impactpackageareshowninFigure10.6.

IOperator The interface IOperator prescribes the minimal set of operationsrequired by an operator implementation to function in the current modeldiagrameditor.Theseare:

getName():Stringprovidetheuniquenameoftheoperator.

setWorkspaceContext(context: WorkspaceContext) The operatorimplementations require information on a general context to operate, likeallATLfilesinusethatmaybeimpactedbyanapplicationoftheoperator.In the current implementation, this information is provided by animplementationofWorkspaceContextandsetusingthismethod.

canApply(eObjects: EObject[1..*]): boolean This method encapsulatesthe checking of pre-and post-conditions of the operator. It returns truewhentheoperatorcanbeappliedtothegivensetofmodelelements.Thismethod is used by the view to enable or disable features based on thecurrentlyselectedsetofmodelelements.

apply()Thismethodiscalledwhentheoperatorismeanttobeapplied.Itisassumed that each operator implementation provides its own specificmethodstosetthemodelelementstowhichtheoperatorisapplied.

detectImpact(): ATLFileImpactSet[0..*] This method is called todetermine the potential impact this operator has on all the ATL filesprovidedbythecurrentWorkspaceContext.Theimpactisreturnedasalist,withoneATLFileImpactSetforeachATLfile.

resolveImpact() When the user accepts the determined impacts and theresolution suggested, this method is called to perform the resolution andupdatetheATLfilesinthecurrentWorkspaceContext.

Figure10.6.:Detailsoftheoperatorpackage

AbstractOperatorTheAbstractOperatorimplementstheIOperator interfaceand provides basic and common functionality for concrete operatorimplementations.Themainfocusliesonanimpactdetectionmechanismthatwalks over theATLof a potentially impactedATL transformation and callsindividual methods for the different parts of a transformation that may beimpacted.Theconcreteoperator implementations that extend this classonlyneed to implement the abstractmethods for the types of the transformationrelevant to them. For instance, to handle the impact of the Inline Classoperator (seepage161), onlyMatchedRules need to be considered so thatonly the detectImpactMatchedRule method needs to be overwritten andimplemented by the concrete InlineClass operator as a subclass ofAbstractOperator.

TheimpactdetectionrequirestypebindingofthevariablesencounteredintheATLtransformationsunderinspectionandtherelevantmetamodels.This isperformedby theclassATLOCLBinderwhich is passed into everymethod.Themethodsareasfollows:

detectImpact(binder: ATLOCLBinder): Impact[0..*] A call of thismethod initiates the walking process. A correctly bound ATL AST isprovided by the given ATLOCLBinder. The method returns the list ofdetected Impact entries, collected from implementations of the methodsbelow.

detectImpactInPatternElement(inPatternElement: InPatternElement,context: MatchedRule, binder: ATLOCLBinder): Impact[0..*] ThismethodiscalledforeachInPatternElementencounteredintheboundATLAST of the transformation under inspection. The owningMatchedRule isprovidedascontext.

detectImpactOutPatternElement(outPatternElement:OutPatternElement, context: Rule, binder: ATLOCLBinder):Impact[0..*] This method is called for each OutPatternElement

encounteredintheboundATLASTofthetransformationunderinspection.

detectImpactRuleVariableDeclaration(ruleVariable Declaration:RuleVariableDeclaration, context: Rule, binder: ATLOCLBinder):Impact[0..*] This method is called for each RuleVariableDeclarationencounteredintheboundATLASTofthetransformationunderinspection.

detectImpactFilter(inPattern: InPattern, binder: ATLOCLBinder):Impact[0..*]ThismethodiscalledforeachInPatternencounteredintheboundATLAST of the transformation under inspection. It should returnanyimpactsduetoanoccuranceintheFilteroftheInPattern.

detectImpactHelper(helper: Helper, binder: ATLOCL Binder):Impact[0..*] This method is called for each Helper encountered in theboundATLASTofthetransformationunderinspection.

10.5.1.Operator-specificWizardPages

Some operators require further information beyond a set of selected modelelementstobeperformed.ThisisthecaseforexamplefortheExtractSuperclassoperator (as defined in Section6.13 on page 126), forwhich the name of theextracted class and the selection of attributes to pull up are needed. Thisinformationisdifferentforeachoperatorsothatthecoevolutionwizardcanbeextended by a set of extra pages for each operator implementation. These arecontained in the de.covol.operator.gui package as shown on the left-handside in Figure 10.5 . Thewizard page for theExtract Superclass is shown inFigure10.7.

Figure10.7.:Theoperator-specificwizardpageforExtractSuperclass

Figure10.8.:Thestepwiseexecutionofoperators

10.5.2.OperatorExecution

The individual changes an operatormakes to the selectedmodel elements areprovidedtotheuserintheformofalistsothattheresultcanbereviewed.Thisisimplementedasawizardpageforthecoevolutionwizard(seeFigure10.8foranexampleofthechangesmadebytheExtractSuperclassoperator).Theuserisgiven the option of inspecting each change by executing the changesindividuallyorallatonce.Thestepsareexecutedtop-downin theordergivenby the operator, where the completed ones are shown in the top half of thewizardpageandtheremainingonesinthebottomhalf.Theeffectofthechangecanalsobeseeninthecurrentmodelview,as it isperformed.Shouldtheuseraborttheoperator,themodelisrevertedintoitsoriginalstateandallchangesare

undone.(Foracompletestep-by-steprun-downofanoperatorexecutionpleaserefertosectionAstartingonpage223intheappendix.)

Figure10.9.:Detailsoftheimpactspackage

10.6.ImpactDetectionandResolution

10.6.1.ImpactDetection

TheimpactdetectionisinitiatedbyacalltothedetectImpact()methoddefinedin the IOperator interface (see Figure 10.6). The AbstractOperator classprovides a tree-walking implementation to detect impacts on the AST of thetransformation in question, as described above. As a result, it returns a

ATLFileImactSet instance for each ATL transformation that was found to beimpacted by the operator. The ATLFileImpactSet in turn provides a list ofinstances of implementations of the Impact interface, where eachimplementationrepresentsadifferenttypeofimpact.Theimpactimplemntationsare contained in the package de.covol.operator.impact as shown in Figure10.9.

Theclassesrelevanttotheimpactdetectionareasfollows:

ATLWSUnit This class represents anATL transformation in the currentworkspaceoftheuser.Itreferencesanactualfilecontainingthetransformationanda set of in and out model names, that are used in the transformation toreferencethedomainmodelsofthetransformation.

ATLFileImpactSet The ATLFileImpactSet holds all the impacts detected foroneATLWSUnit.TheseareprovidedbythedetectionprocessperformedbytheoperatorimplementationsofIOperator.

ImpactTheImpact interfaceprescribesall the featuresnecessaryfora reviewby the user of the potential impact resolution and the resolve() methodwhichiscalledtoinitiatetheresolutionprocess.Thefeaturesare:

title:StringThenameoftheimpact.

message: String A description in natural language of the nature of theimpact.

stateBefore: String A String containing the relevant part of thetransformationasitisbeforetheresolutionisperformedinconcretesyntax(ATL).

stateAfter:StringAStringcontainingthestateofthetransformationaftertheresolutionisperformed.

beforeHighlighter: Highlighter[0..*] The Highlighter contains one ormore regions of characters in the concrete representation of thetransformationasgivenbystateBeforethatarehighlightedtoindicatetheexactpartsofthetransformationthatareaffectedbytheresolution.

afterHighlighter:Highlighter[0..*]Aswith thebeforeHighlighter, theafterHighlighterhighlightstheexactpartsofthetransformationthataretobechangedbytheimpactresolution.

AbstractImpactanditssubclassesThedifferentimpactsandtheirresolutionsareimplementedassubclassesofAbstractImpact,whereeachclasscontainsthe specifics of one type of impact. For instance, the MergeRulesImpactcontainstwoMatchedRulesthataremergedintooneasaresultoftheimpactresolution. The resolution is performed on the transformation given by theassociatedATLWSUnitwhentheresolve()methodiscalled.

getName():Stringprovidetheuniquenameoftheoperator.

setWorkspaceContext(context: WorkspaceContext) The operatorimplementations require information on a general context to operate, likeallATLfilesinusethatmaybeimpactedbyanapplicationoftheoperator.In the current implementation, this information is provided by animplementationofWorkspaceContextandsetusingthismethod.

canApply(eObjects: EObject[1..*]): boolean This method encapsulatesthe checking of pre-and post-conditions of the operator. It returns truewhentheoperatorcanbeappliedtothegivensetofmodelelements.Thismethod is used by the view to enable or disable features based on thecurrentlyselectedsetofmodelelements.

apply()Thismethodiscalledwhentheoperatorismeanttobeapplied.Itisassumed that each operator implementation provides its own specificmethodstosetthemodelelementstowhichtheoperatorisapplied.

detectImpact(): ATLFileImpactSet[0..*] This method is called todetermine the potential impact this operator has on all the ATL filesprovided by the current WorkspaceContext. The impact is returned as alist,withoneATLFileImpactSetforeachATLfile.

resolveImpact() When the user accepts the determined impacts and theresolution suggested, this method is called to perform the resolution andupdatetheATLfilesinthecurrentWorkspaceContext.

10.6.2.ImpactResolution

Theproposedimpactresolutionsareprovidedtotheuserusingthelastpageofthecoevolutionwizard.TheATLfilesinthecurrentworkspacethatareimpactedareshownasalistwiththedetectedimpactsassubitems(seeFigure10.10).For

each impact, theproposedresolution isprovided inasplit screen,showing thestateof the transformationbefore theresolutionon the leftand thestateof thetransformation after the resolution on the right. The user can review eachresolutionindetailandacceptorrejecttheapplicationoftheoperator.

Figure10.10.:Thewizardpagefortheproposedimpactresolutionontransformations

CHAPTER11

Conclusion

Thischapterconcludesthethesis,summarisingthemaincontributionsinSection11.1.Thebenefitsof thisworkforsoftwarearchitectsandMDEingeneralaredescribed inSection11.2.Finally,Section11.3providesanoverviewof issuesandchallengesforfuturework.

11.1.Summary

This thesis provides an approach to the semi-automatic coevolution ofmetamodels and model transformations. The approach supports softwarearchitects in evolving dependent artefacts of theMDS in stepwise fashion byapplying predefined operators on EMOF-basedmetamodels and detecting andresolvingthepossiblyoccurringimpactsonmodeltransformations.

Themaincontributionsofthisworkareasfollows:

ApproachTheapproachpresentedinchapter5allowsthestepwisecoevolutionofmetamodelsandmodeltransformations.Itconsistsofthreephases,startingwith the adaptation ofmetamodels using an operator selected from a set ofoperators. In the secondphase, the impacton an arbitrarynumberofmodeltransformationthatdependonthemetamodelisdetected.Allpossibleimpactsarecollected.Inthethirdphase,theresolutionsfortheimpactsaresuggestedtothesoftwarearchitectandperformedeitherautomatically,ifpossible,orthesoftware architect is supported in providing a manual resolution. With theconclusionoftheapproach,theMDSisleftinanupdatedandvalidstate.Thesoftware architect can perform the next evolution step by choosing andapplyingthenextoperator.

OperatorsetChapter6introducesasetofoperatorsadaptedfromrelatedworkoncoevolutiontobesuitabletoourapproach.TheoperatorsarebasedontheUML EMOF metamodel and are formalised as relations using the OMG

standardQVT-Rgraphicalnotation.Pre-andpostconditionsareusedtoensuretheapplicabilityoftheoperators.

ImpactresolutionTheimpactdetectionandresolutionforthesetofoperatorsisdefinedforATLinchapter7.TheresolutionsarealsoformalisedasQVT-RrelationsfortheATLabstractsyntax.Theimpactresolutioncanbeautomatedwhere possible, to update the impacted transformation rule or rule part inaccordancewiththeoperatorused.Ifanautomaticresolutionisnotpossible,the software architect is warned of the impact and can perform a manualadaptation.

ImplementationTheprototypicalimplementationoftheapproach,theoperatorsand the impact detection and resolution is described in chapter 10. Theimplementationis integratedintocommonMDEtoolingfor thecreationandediting of Ecore metamodels and ATL model transformations. Theimplementationprovidesfeedbacktothesoftwarearchitectaboutthechangesmadebyapplyinganoperatortoametamodel,theresultingimpactonmodeltransformationsandtheresolutionsthatareavailable.

Ingeneral,theapproachcontributestothesolutionforthecoevolutionproblemfor MDS. It addresses the problem of complexity and the tightcoupling ofdependent artefacts in the contextof software evolutionand reduces the effortneeded to prevent the occurrence of inconsistencies due to software evolutiontasksformetamodelsandmodeltransformations.

11.2.Benefits

The results of this thesis supports software architects when performingevolutionarychangestoanMDS,specificallywhenmetamodelsanddependentmodeltransformationsundergocoevolution.

The benefit of the approach presented here is the reduced effort whenperformingcommonlyoccurringchangesduetothesupportprovidedtoperformsuch changes through the application of operators and the reduced effort inresolving the impact on dependent model transformations. Depending on thechange performed and the resulting impact, a range of resolutions can beperformed automatically, while the software architect can be supported whenperformingmanualresolutionfortherest.Furthermore,theapproachallowstheautomaticdetectionof possible impact ondependent transformation causedby

metamodelevolutionandnarrowsdownthenumberoftransformationrulesthatrequireworktobedone.

Asadistinctivefeaturecomparedtoexistingsolutions,ourcoevolutionapproachisdesignedtobestepwiseandisdirectlyintegratedintotoolingcommonlyusedfor the creation of transformations and metamodels. We furthermore provideformalized definitions of both operators and impact resolutions in QVT-RgraphicalsyntaxandsupportthefullEMOFstandardmetamodel.

Theindividualbenefitsofourworkareasfollows:

SetofoperatorsTheoperatorspresentedinthisthesiscanbeusedforcommoncoevolution tasks and are complete on the metamodel level. Each operatordefines a valid state before and after the application and ensures that themetamodelremainsvalid.

FormalisedoperatorsFormalisingtheoperatorsusingQVT-Randrepresentingthem in thegraphical notationhas thepotential advantageof precisionoverinformal methods or natural language. This advantage may come into playwhentheexactbehaviourandimpactofanoperatorforanimplementationisneeded. Furthermore, by providing a formal foundation, the impact ofoperators on different transformation languages or other metamodel-dependentelementsoftheMDSmaybecomeeasiertocompare.

Impact resolution for ATL The impact resolution presented in this thesissupports the software architect in handling the coevolution problem byprovidingameanstopredicttheimpactachangetoametamodelmayhaveona dependent ATL transformation and providing the means for automaticresolutioninmanycases.Thisgreatlyreducestheeffortastheexactpartsofatransformationthatareimpactedareknownsothatitisnolongernecessarytocheck every part of every transformation for consistency after an evolutionstep. Furthermore, the automatic resolution prevents the software architectfromimplementationworkneededafteraresolvableimpactisdetected.

StepwiseapproachThestepwisenatureofourapproachensuresthatitcanbeintegratedintothenormalworkingenvironmentandtoolingusedbysoftwarearchitectsinMDE.Thismeansthatcoevolutionanddevelopmenttaskscanbeperformedinquicksuccessionandsupportingrapiddevelopmentapproaches.

Tosummarise,theapproachpresentedinthisthesishelpssoftwarearchitectsby(1)reducingtheeffortneededforcommoncoevolutiontasks,(2)byprovidingameans to predict the impact of different metamodel evolution steps on

transformationsandby(3)reducingthenumberoftransformationrulesthatneedtobevalidatedafteranevolutionisperformed.

Furthermoreitadvancesthestate-of-the-artinMDEandbenefitsresearchersinsoftwareevolutionby(1)providingaformalizedsetofcoevolutionoperatorsforEMOF metamodels, by (2) providing a set of formalised impact resolutionrelations forATL and by (3) demonstrating the integration of our approach incommonMDEtooling.

11.3.FutureWork

Thissectiondiscusses ideasandopenissuessummarizedasfuturework.Shorttermfutureworkrequiressmallerconceptualcontributionsandimplementationwork,whilelong-termfutureworkrequiresin-depthsnewconceptsandmayforexamplebetackledinfutureresearchorindustryprojects.

Fullscale integratedtoolingWhile theprototypical implementationpresentedin chapter 10 shows how the integration of the approach with other MDEtoolingcouldbedone,industrialuseoftheapproachrequiresfullintegrationwiththestandardEMFtools,liketheEcorereflectiveeditor.Tothisend,theinteractionwithmodel elements in the tree structure provided by the editorwould need to be investigated so that software architects can select theelements on which to apply an operator in a similar fashion as in theprototype. Further application patterns may also be needed, as Ecoremetamodelscanalsobecreatedintextualeditorsforinstance.Furthermore,tosupport the standard ATL editor, it would need to be extended withfunctionalitytoaccessandmodifytheASTunderlyingthetextualviewandtomirrorchangesperformedtotheASTbackintothetextualview.Furthermore,functionalitytohighlightATLcoderegionsthatareimpactedisneeded.Thiscanmainlybeseenasanindustryproject.

OperatorapplicationextensionThecurrentsetofoperatorscoverstheEMOFmetamodel of MOF and thereby Ecore as an implementation. ThecompletenessforEMOFwasdiscussedinSection9.1.TheoperatorscouldbeextendedtocoverallofMOF,i.e.toalsoincludetheCMOFmetamodel.Thiswould make them potentially more widely applicable and introduce thepossibilityofprovidingimpactdetectionandresolutionforalargervarietyof

transformationlanguagesoverall.ThekindofoperatorsneededforacoverageofCMOFremainsaresearchquestion.

Extend the set of operators Although operator completeness in terms of themetamodelisreachedforEMOF,completenessforthetransformationpartisrelativetotheapplicationscenarioandcanbeimproved.Whichoperatorsareneededandshouldsensiblybeadded(orareunnecessaryandcanberemoved)requires long term experience with the tool support in a practical setting.Furthermore, the frequency of use of the operators and the occurrence ofimpact may also depend on the kind of metamodel and dependenttransformations and the nature of the evolution taking place, so that oneoperator may prove more useful than another depending on the project athand.Topinpointsuchfactorsandtheirrelevancewouldrequirealarge-scaleand long-running industrial case study. Such results would furthermore behelpfultoresearchonothercasesofMDScoevolution.

Support forother transformation languagesTheapproachcouldbeadaptedtoothertransformationlanguages,asthiswouldextendthepracticaluseoftheapproach and the tooling. QVT-R is a promising next candidate as it isstructurally similar to ATL and some tool support for Eclipse IDE exists.Defining the impact detection and resolution for QVT-Omay yield furtherinsight, as it isan imperativeandnotadeclarative transformation language.Before a practical integration of other transformation languages can beachieved,furtherresearchontheoperatorimpactonsuchlanguagesisneeded.

Integration with other coevolution As related research covers the use ofoperatorsforothercasesofMDScoevolution,suchasmetamodelandmodelcoevolution or model and OCL coevolution, the investigation of theapplicability of the same operators in all cases holds promise. To ourknowledge, no such overall approach exists so far. Such an approach couldprovide holistic support for the coevolution of theMDS, by providing oneoverallsetofoperatorsanddeterminingandresolvingtheimpactonalltypesofdependentartefacts.Forinstance,aftermodifyingametamodel,dependenttransformations and at the same time the set of models conforming to themetamodel could be updated in one step. This would allow the immediatetestingof the result,as theupdated transformationcouldbeexecutedon theupdated set ofmodels to see the result. This is expected to require a largeresearchprojectastheresultsofdifferentareasneedtobeincorporated.

Reversing the approach The approach presented in this thesis assumes achange originates in a metamodel and a dependent model transformationneeds to be updated in response. Reversing the approach may also yield avaluable result. The changes that a software architect makes to a model

transformation could be recorded or also provided as operators and themetamodelsofthetransformationthenbeupdatedaccordingly.Howmanyusecases of this approach exist would have to be determined first but couldprovidefurtherinsighttothecoevolutionproblem.

Transformation ‘bad smells’ Wachsmuth suggests the use of metamodeladaptation to remove structural bad smells from architecture [107] as anextension of the code-centric bad smells suggested by Fowler for OOrefactoring(seeSection4.2).Badsmellsindicatepartsofcodethatshouldbeimprovedbytheapplicationofarefactoring[34].Coevolutionoperatorscouldserve the same purpose for dependent artefacts of anMDS. In the case ofmetamodels and transformations, the use of our coevolution operators mayindicate a bad smell in the structure of theMDS – as an extension of theconceptofcodebadsmellsandarchitecturebadsmells.WeseeanopportunityforfutureresearchintheareaofqualityofMDShere.

Toconclude,thisthesisisasteptowardsaddressingthecoevolutionproblemforMDS. Software architects are supported in coevolution tasks and the effort toresolve impacts on transformations is reduced. Further research in the area ofcoevolutionforother transformationlanguagesorcoevolutioninotherareasoftheMDSmayprovidewidersupportforthecoevolutionproblemandstrengthentheapplicabilityinpractice.

Appendix

APPENDIXA

ExecutionofExtractSuperclass

AppendixA contains a full run-down in screen-shots of the applicationof theExtractSuperclassoperatoron theextendedEMF-LibraryMetamodelexampleoftheapplicationscenariointroducedinSection1.2.Thescreen-shotsareoftheprototypicalimplementationdiscussedinchapter10.

FigureA.1.:Choosingoperatorforselectedelements

FigureA.2.:Providingadditionalinformationforoperator

FigureA.3.:Performingindividualmodelchanges

FigureA.4.:Completedsetofoperatorchanges

FigureA.5.:Previewofimpactsandresolution

FigureA.6.:Updatedmodeltransformationafterimpactresolution

FigureA.7.:Updatedmodelafteroperatorapplication

APPENDIXB

ATLImplementationinXtext

AppendixBcontains theEclipseXtextProjectgrammarfor theATLandOCLtextualsyntaxusedtodemonstratethetoolingintegrationasdiscussedinchapter10.

GrammarofATL

ListingB.1:XtextimplementationoftheATLconcreteandabstractsyntax

GrammarofATL-OCL

ListingB.2:XtextimplementationoftheOCLconcreteandabstractsyntax

Glossary

ANTLRisaparsergeneratorfortextual(programming)languages[81].

ATLTransformationZooAcollectionof103model transformationscenariosinATL(asofthiswriting)[100].

co-evolution the synchronized evolution of linked artefacts to maintain theconsistencyof theMDS.Theco-evolutionproblem refers to inconsistenciesthatmayoccurwhenartefactsarechangedindividually.

conformsToTherelationshipbetweenamodelanditsmetamodel.

consistency In thecaseofmetamodelsandmodel transformations,consistencyisthesuitabilityofthemetamodeltorepresenttheinputandoutputmodelsofthemodeltransformation.

Eclipse ATL Project The Eclipse IDE project for the ATL languageimplementationandtransformationengine[95].

Eclipse Graphiti Project An Eclipse project that provides an extendableframeworkforgraphicaleditorsforEclipseIDE[98].

EclipseIDEEclipse isan integrateddevelopmentenvironment (IDE) for JavaandotherprogramminglanguagesandDSLs.Itprovidesapluininfrastructureand plug-ins formany different development purposes, among them toolingforMDEprojects.

Eclipse Modeling Project The Eclipse IDE project for MDE relatedtechnologiesoftheEclipseplatform.

Eclipse Xtext Project An Eclipse IDE project for the generation of textualDSLsandaccompanyingtooling[102].

EcoreEcoreisanimplementationoftheEssentialMOF(EMOF)forJava.ItispartoftheEclipseModelingFramework(EMF).

EMF Genmodel A type of model used in the EMF to customise the codegenerationofJavasourcecodefromEcoremodels[94].

grammarware engineering Engineering discipline for the development andmaintenanceofgrammarsandgrammar-dependentsoftware,wheregrammar‘is used in the sense of all established grammar formalisms and grammarnotations includingcontext-freegrammars, classdictionaries,XMLschemasaswellassomeformsoftreeandgraphgrammars’[53].

higher-order transformation Higher-order transformations representtransformationfunctionswithtransformationsasinputoroutputmodels.

metametamodelTherepresentationofalanguagedesignedformetamodelling.

metamodelAmetamodel is a representationof a setofmodels,whichcanbecalledamodellinglanguage.Ifamodelisamemberofthisset,itconformstoitsmetamodel.

modelAnabstractsystemisamodelofanothersystem,ifitisasimplificationoftheothersystem,createdforagivenpurpose.

Model Driven System A Model Driven System (MDS) is the collection ofartefactsandtoolsusedforthedevelopmentofasoftwaresysteminMDEandthedependenciesbetweenthem.

Model Transformation A model transformation is the information on amapping between two sets of models, to be executed by a transformationengine. It consists of a set of rules that describehowelementsof the targetlanguagecanbecreatedfromelementsofthesourcelanguageautomatically.

ObjectConstraintLanguageA formal textual language to describe invariantconditionsorqueriesformodelelementsoftheOMGfamilyoflanguages.

operator A mapping from one set of metamodel elements to another set ofmetamodelelements.Forthepurposeofco-evolution, theoperatordescribeshowmetamodelelementsareadaptedtoperformapredefinedtypeofchange.

real-world software systemA software system that provides a solution to anacceptableapproximationofareal-worldproblemorthatitisembeddedintherealworldasauniverseofdiscourse.AlsocalledE-typesystembyLehmann[61].

refactoring‘Refactoringistheprocessofchangingasoftwaresysteminsuchaway that itdoesnot alter theexternalbehaviorof thecodeyet improves itsinternalstructure’[34,p.xvi].

representationOf ‘The relationship between the model and the system itrepresents.

reusabilityReusability is the property or properties of a development artefactthatenhanceitssuitabilityforreuse.

system The ‘combination of interacting elements organized to achieve one ormorestatedpurposes’[47].

technologicalspace ‘A technological space is aworkingcontextwith a setofassociated concepts, body of knowledge, tools, required skills, andpossibilities.’[58].

UnifiedModelingLanguageAmodellinglanguageforsoftwaresystems.

wizard A usage interface dialog consisting of a number of different pages toperformanoveralltask.

Acronyms

AMMA ATLASModelManagementArchitecture.ANSI AmericanNationalStandardsInstitute.AST abstractsyntaxtree.ATL ATLASTransformationLanguage.ATLVM ATLVirtualMachine.

CDIF CASEdatainterchangeformat.CMOF CompleteMOF.

DSL DomainSpecificLanguage.DSM DomainSpecificModelling.

EMF EclipseModelingFramework.EMOF EssentialMOF.

GReAT GraphRewritingandTransformation.

IDE integrateddevelopmentenvironment.IMDB InternetMovieDatabase.IRDS InformationResourceDictionarySystem.

LHS left-hand-side.

MDE ModelDrivenEngineering.MDS ModelDrivenSystem.MOF Meta-ObjectFacility.

OCL ObjectConstraintLanguage.

OMG ObjectManagementGroup.OO object-oriented.

QVT MetaObjectFacility(MOF)2.0Query/View/Transformation.QVT-C QVTCore.QVT-O QVTOperationalMappings.QVT-R QVTRelations.

RHS right-hand-side.

UML UnifiedModelingLanguage.URI UniformResourceIdentifier.

XMI XMLMetadataInterchange.XML ExtensibleMarkupLanguage.

ListofFigures

1.1.Theimpactonmetamodelevolutionondependentartefacts1.2.TheextendedEMF-LibraryMetamodelexample1.3.TheIMDBMetamodelexample1.4.ThemodifiedextendedEMF-LibraryMetamodelexample

2.1.StructureoftheUMLSpecificationasofVersion2.4.1[86]2.2.TheEMOFClassespackage2.3.TheEMOFTypesandDataTypespackage2.4.Favre’sTransformationPattern[32]

3.1.TheATLabstractsyntax:ModulesandRules3.2.TheATLabstractsyntax:In-andOutPatterns3.3.TheATLcompilationprocess[96]3.4.ThesimpleexampleofaQVTtransformationingraphicalnotation

5.1.Theextendedproblemillustration5.2.Thethreegeneralphasesofco-evolution5.3.Theindividualstepsofthemetamodeladaptationphase5.4.TheATLsyntaxforamatchedrule5.5.Theindividualstepsoftheimpactdetectionphase5.6.TheIndividualStepsoftheImpactResolutionPhase5.7.Approach

6.1.TheAdd/RemoveClassrelation6.2.TheAdd/RemovePackagerelation6.3.TheAdd/RemoveDataTyperelation6.4.TheAdd/RemoveEnumerationLiteralrelation6.5.TheAdd/RemovePropertyrelation6.6.TheAdd/RemoveAssociationrelation6.7.TheAdd/RemoveOperationrelation6.8.TheIntroduce/RemoveGeneralizationrelation6.9. The Introduce / Remove Generalization relation with common super

classifier

6.10.MovePropertyoperatorexample6.11.TheMovePropertyrelation6.12.PushSimplePropertyoperatorexample6.13.ThePushSimplePropertyrelation6.14.PushComplexPropertyoperatorexample6.15.ThePushComplexPropertyrelation6.16.ThePullSimplePropertyrelation6.17.ThePullComplexPropertyrelation6.18.TheRestrictUnidirectionalPropertyrelation6.19.ExtractClassOperatorexample6.20.TheExtractClassrelation6.21.TheInlineClassrelation6.22.TheExtractSuperclassrelation6.23.FlattenHierarchyoperatorexample6.24.TheFlattenHierarchyrelation6.25.AssociationtoClassoperatorexample6.26.TheAssociationtoClassrelation6.27.GeneralizationtoCompositionoperatorexample6.28.TheGeneralizationtoCompositionrelation6.29.IntroduceCompositePatternoperatorexample6.30.TheIntroduceCompositePatternrelation

7.1.TheRemove(LHS)MatchedRulerelation7.2.TheRemoveOutPatternElementrelation7.3.TheRemoveRulewithEmptyOutPatternrelation7.4.RemovePropertyimpactresolutionforATLfilterconditions7.5.RemovePropertyimpactonLHSbinding7.6.RemovePropertyimpactonRHSbindingresolution7.7.MovePropertyLHSbindingassignmentresolution7.8.MovePropertyfilterconditionimpact7.9.MovePropertyRHSbindingimpact7.10.TheOppositeAssociation-EndFirstrelation7.11.TheOppositeAssociation-EndOtherrelation7.12.RelationfortheimpactresolutionofExtractClassonRHSmetamodels7.13.RelationtodivertamatchedrulefromamergedclassfortheInlineClass

operatorontheLHS7.14.RelationfortheimpactofFlattenHierarchyonsuperclassrules7.15.Relationtocloneamatched-ruleandallchildstatements

9.1.Petrinetmetamodelevolution[107]9.2.Textualpathexpression[46]9.3.Petrinetexample[46]9.4.Thepathexpressionmetamodel[46]

10.1. The major components and relationships of the prototypicalimplementation

10.2.ScreenshotofthecustomATLeditorimplementation10.3.ScreenshotoftheintegratedCovolModelEditor10.4.Screenshotoftheapplicationofoperatorsinthegraphicaleditor10.5.Detailsofthefeature.operatorpackage10.6.Detailsoftheoperatorpackage10.7.Theoperator-specificwizardpageforExtractSuperclass10.8.Thestepwiseexecutionofoperators10.9.Detailsoftheimpactspackage10.10.Thewizardpagefortheproposedimpactresolutionontransformations

A.1.ChoosingoperatorforselectedelementsA.2.ProvidingadditionalinformationforoperatorA.3.PerformingindividualmodelchangesA.4.CompletedsetofoperatorchangesA.5.PreviewofimpactsandresolutionA.6.UpdatedmodeltransformationafterimpactresolutionA.7.Updatedmodelafteroperatorapplication

ListofListings

1.1.A simple transformationbetween the IMDBMetamodel and the extendedEMF-LibraryMetamodel

1.2.TheupdatedtransformationbetweentheIMDBMetamodelandtheevolvedextendedEMF-LibraryMetamodel

3.1.AsimpleexampleofanATLtransformation3.2.AsimpleexampleofaQVTtransformation

7.1.ATLrulewithconstrainingOCLexpression7.2.ATLrulewithbindingassignment7.3.ExamplefortheimpactofMovePropertyonaLHSpropertybinding7.4.ExamplefortheimpactofMovePropertyonaRHSpropertybinding7.5.PossibleconstraintadaptationafterPushDownProperty7.6.ExamplefortheimpactresolutionofExtractClassonaRHSmetamodel7.7.ExamplefortheimpactofFlattenHierarchyontheLHS(before)7.8.ExamplefortheimpactofFlattenHierarchyontheLHS(after)

9.1.AbridgedPathExp2PetriNettransformation[46]9.2.Primarytransformationstatematchinge0

10.1.NewATLASTmodelelements

B.1.XtextimplementationoftheATLconcreteandabstractsyntaxB.2.XtextimplementationoftheOCLconcreteandabstractsyntax

Index

.asmfile,→

.atlfile,→

Abbildungsmerkmal,→ATLASTransformationLanguage(ATL),→

behaviouralpreservation,seesemanticspreservationcalledrule,→changetracking,→compliancelevel,→conformsTo,→

designprinciples,→

eclipsemodelingproject,→

in-pattern,→

levelofabstraction,→matchedrule,→Metamodel,→model,→refactoring,→token,→type,→

ModelDrivenEngineering(MDE),→modeldrivensystem,→modelrefactoring,→modeltransformation,→MOFComplete,→Essential,→,→MetaObjectFacility,→

ObjectManagementGroup(OMG),→out-pattern,→

packagemerge,→patternATL,→

PragmatischesMerkmal,→

QVTCore(QVT-C),→MOF2.0Query/View/Transformation,→

OperationalMappings(QVTO),→Relations(QVT-R),→Relations(QVT-R)GraphicalNotation,→

refactoring,→representationOf,→semanticpreservation,→settheory,→syntaxpreservation,→system,→

technologicalspace,→,→tightcoupling,→transformationdomain,→function,→higher-order,→range,→

UMLInfrastructure,→Superstructure,→UnifiedModelingLanguage,→

unifyingprinciple,→

Verkürzungsmerkmal,→

Bibliography

[1]AlfredV.Ahoetal.Compilers:Principles,Techniques, andTools (2ndEdition). PearsonAddisonWesley,2007.isbn:0-321-48681-1.

[2]CarstenAmelunxenandAndySchürr.‘FormalisingmodeltransformationrulesforUML/MOF2’.In:IETSoftware2.3(2008),pp.204–222.ISSN:1751-8806.DOI:10.1049/iet–sen:20070076.

[3]DaveAstels.‘RefactoringwithUML’.In:Proc.3rdInt’lConf.eXtremeProgrammingandFlexibleProcessesinSoftwareEngineering(2002),pp.67–70.

[4]ColinAtkinsonandThomasKühne.‘Model-DrivenDevelopment:AMetamodelingFoundation’.In:Software,IEEE20.5(2003),pp.36–41.DOI:10.1109/MS.2003.1231149.

[5]ATLASgroupLINA&INRIANantes.ATL:AtlasTransformationLanguage,ATLUserManual -version 0.7 -. 2006. URL:http://www.eclipse.org/atl/documentation/old/ATL_User_Manual[v0.7].pdf (visited on01/02/2010).

[6]ATLASgroupLINA& INRIANantes.ATL:Atlas Transformation Language, Specification of theATL Virtual Machine - version 0.1 -. 2005. URL:http://www.eclipse.org/atl/documentation/old/ATL_VMSpecification%5Bv00.01%5D.pdf

(visitedon01/02/2010).[7]ThomasBaarandSlavišaMarković.‘AGraphicalApproachtoProvetheSemanticPreservationof

UML/OCL Refactoring Rules’. In: Perspectives of Systems Informatics, 6th International AndreiErshovMemorial Conference, PSI 2006, Novosibirsk, Russia, June 27-30, 2006. Revised Papers.LectureNotesinComputerScience4378(2007).Ed.byIrinaVirbitskaiteandAndreiVoronkov,pp.70–83.DOI:10.1007/978-3-540-70881-0_9.

[8]DanielBalasubramanian et al. ‘TheGraphRewriting and Transformation Language:GReAT’. In:Electronic Communications of the EASST - Proceedings of the Third International Workshop onGraph Based Tools (GraBaTs 2006) 1 (2007). issn: 1863-2122. URL:http://www.isis.vanderbilt.edu/node/3505.

[9] Mikaël Barbero, Frédéric Jouault and Jean Bézivin. ‘Model Driven Management of ComplexSystems: Implementing theMacroscope’sVision’. In:15thAnnual IEEE InternationalConferenceandWorkshopsontheEngineeringofComputer-BasedSystems.ECBS’08.Washington,DC:IEEEComputerSociety,2008,pp.277–286.DOI:10.1109/ECBS.2008.42.

[10]KeithH.Bennett andVáclavT.Rajlich. ‘SoftwareMaintenance andEevolution:ARoadmap’. In:Proceedingsof theConferenceonTheFutureofSoftwareEngineering. ICSE’00.NewYork,NY:ACM,2000,pp.73–87.DOI:10.1145/336512.336534.

[11]JeanBézivin. ‘FromObjectComposition toModelTransformationwith theMDA’. In:TOOLS’01Proceedingsofthe39thInternationalConferenceandExhibitiononTechnologyofObject-OrientedLanguagesandSystems(TOOLS39)I(Aug.2001),p.350.DOI:10.1109/TOOLS.2001.10021.

[12]JeanBézivin.‘OntheUnificationPowerofModels’.In:SoftwareandSystemsModeling4.2(2005),pp.171–188.issn:1619-1374.DOI:10.1007/s10270-005-0079-0.

[13]JeanBézivinandOlivierGerbé.‘TowardsaPreciseDefinitionof theOMG/MDAFramework’. In:Proceedingsof the16th IEEE InternationalConferenceonAutomatedSoftwareEngineering (ASE2001)(Nov.2001),pp.273–280.DOI:10.1109/ASE.2001.989813.

[14]Marko Boger, Thorsten Sturm and Per Fragemann. ‘Refactoring Browser for UML’. In:Objects,Components, Architectures, Services, and Applications for a Networked World, InternationalConference NetObjectDays, NODe 2002 Erfurt, Germany, October 7–10, 2002 Revised Papers.LectureNotes inComputer Science 2591 (2003). Ed. byMehmetAksit,MiraMezini andRainerUnland,pp.366–377.DOI:10.1007/3-540-36557-5_26.

http://www.eclipse.org/atl/documentation/

http://www.eclipse.org/atl/documentation/old/ATL_VMSpecification%5Bv00.01%5D.pdf

http://www.isis.vanderbilt.edu/node/3505

[15]GradyBooch, JamesRumbaugh and Ivar Jacobson.UnifiedModelingLanguageUserGuide, The(2Nd Edition) (Addison-Wesley Object Technology Series). Addison-Wesley Professional, 2005.ISBN:0321267974.

[16] Frederick P. Brooks. ‘No Silver Bullet — Essence and Accident in Software Engineering’. In:Proceedings of the IFIP Tenth World Computing Conference. Ed. by H.-J. Kugler. Amsterdam:ElsevierScienceB.V.,1986,pp.1069–1076.

[17]ManfredBroyetal.‘2ndUML2SemanticsSymposium:FormalSemanticsforUML’.In:ModelsinSoftwareEngineering.Ed.byThomasKühne.Vol.4364.LectureNotesinComputerScience.Berlin,Heidelberg: Springer Berlin Heidelberg, 2007, pp. 318–323. ISBN: 978-3-540-69488-5. DOI:10.1007/978-3-540-69489-2_39.

[18]AchimD.Brucker,JürgenDoserandBurkhartWolff.‘SemanticIssuesofOCL:Past,Present,andFuture’.In:ElectronicCommunicationsoftheEASST5(2006).ISSN:1863-2122.

[19]ErikBurgeretal. ‘View-basedModel-drivenSoftwareDevelopmentwithModelJoin’.In:SoftwareandSystemsModeling(2014),pp.1–24.DOI:10.1007/s10270-014-0413-5.

[20] Jordi Cabot and E Teniente. ‘Transformation Techniques for OCL Constraints’. In: Science ofComputer Programming, Special Issue on Model Transformation 68.3 (2007). Ed. by AlfonsoPierantonio, B. Selic Vallecillo and J. Gray, pp. 179–195. ISSN: 0167-6423. DOI:10.1016/j.scico.2007.05.001.

[21]AntonioCicchetti,DavideDiRuscioandAlfonsoPierantonio.‘AMetamodelIndependentApproachto Difference Representation’. In: Journal of Object Technology 6.9 (2007), pp. 165–185. URL:http://www.jot.fm/issues/issues_2007_10/paper9.

[22]Antonio Cicchetti, DavideDi Ruscio andAlfonso Pierantonio. ‘ManagingDependent Changes inCoupled Evolution’. In: Theory and Practice of Model Transformations, Second InternationalConference, ICMT 2009, Zurich, Switzerland, June 29-30, 2009. Proceedings. Lecture Notes inComputer Science 5563 (2009). Ed. by Richard F. Paige, pp. 35–51. DOI: 10.1007/978-3-642-02408-5_4.

[23]AntonioCicchettietal. ‘AutomatingCo-evolution inModel-drivenEngineering’. In:TwelfthIEEEInternationalEDOCEnterpriseComputingConference.LosAlamitos,CA:IEEEComputerSociety,2008,pp.222–231.doi:10.1109/EDOC.2008.44.

[24] James Clark. XSL Transformations (XSLT) Version 1.0. 1999. url:

http://www.w3.org/TR/1999/REC-xslt-19991116(visitedon11/10/2013).[25]AlexandreCorreaandCláudiaWerner.‘RefactoringObjectConstraintLanguageSpecifications’.In:

SoftwareandSystemsModeling6.2(July2006),pp.113–138.doi:10.1007/s10270-006-0023-y.[26] Krzysztof Czarnecki and Simon Helsen. ‘Classification of model transformation approaches’. In:

Proceedingsof the2ndOOPSLAWorkshoponGenerativeTechniques in theContextof theModelDrivenArchitecture.Citeseer,2003,pp.1–17.

[27] Krzysztof Czarnecki and Simon Helsen. ‘Feature-based Survey of Model TransformationApproaches’. In: IBM Systems Journal 45.3 (2006), pp. 621–645. issn: 0018-8670. doi:10.1147/sj.453.0621.

[28] Gregor Engels et al. ‘Consistency-Preserving Model Evolution through Transformations’. In:<<MML>>2002-TheUnifiedModelingLanguage.LectureNotesinComputerScience2460(Sept.2002). Ed. by Jean-Marc Jézéquel, Heinrich Hussmann and Stephen Cook, pp. 212–227. doi:10.1007/3-540-45800-X_18.

[29]AndyEvansetal.‘TheUMLasaFormalModelingNotation’.In:TheUnifiedModelingLanguage.<<UML>>’98:BeyondtheNotation.LectureNotesinComputerScience1618(1999).Ed.byJeanBézivinandPierre-AlainMuller,pp.336–348.doi:10.1007/978-3-540-48480-6_26.

[30] Jean-Marie Favre. ‘Megamodelling and Etymology’. In: Transformation Techniques in SoftwareEngineering. Dagstuhl Seminar Proceedings 05161. Dagstuhl: Internationales Begegnungs-undForschungszentrum für Informatik (IBFI), Schloss Dagstuhl, Germany, 2006. url:

http://drops.dagstuhl.de/opus/volltexte/2006/427.

[31] Jean-Marie Favre. ‘Metamodel and Model Co-evolution within the 3D Software Space’. In:Proceedings of theELISAWorkshoponEvolutionofLarge-scale Industrial SoftwareApplications(Sept. 2003), pp. 98–109. URL: http://soft.vub.ac.be/FFSE/Workshops/ELISA-

submissions/16-Favre-full.pdf.

http://www.jot.fm/issues/issues_2007_10/paper9

http://www.w3.org/TR/1999/REC-xslt-19991116

http://drops.dagstuhl.de/opus/volltexte/2006/427

http://soft.vub.ac.be/FFSE/Workshops/ELISA-submissions/16-Favre-full.pdf

[32]Jean-MarieFavre.‘TowardsaBasicTheorytoModelModelDrivenEngineering’.In:InProc.ofthe3rd UML Workshop in Software Model Engineering (WiSME’2004). 2004. URL: http://www-adele.imag.fr/Les.Publications/intConferences/WISME2004Fav.pdf.

[33]Jean-MarieFavreandTamNGuyen.‘TowardsaMegamodeltoModelSoftwareEvolutionThroughTransformations’.In:ElectronicNotesinTheoreticalComputerScience127.3(Apr.2005),pp.59–74.ISSN:15710661.DOI:10.1016/j.entcs.2004.08.034.

[34]Martin Fowler.Refactoring: Improving theDesign of ExistingCode. Boston,MA,USA:AddisonWesleyLongman,Inc.,1999.ISBN:0-201-48567-2.

[35]ErichGammaetal.DesignPatterns:ElementsofReusableObjectorientedSoftware.Boston,MA,USA:Addison-WesleyLongmanPublishingCo.,Inc.,1995.ISBN:0-201-63361-2.

[36]KellyGarcésetal.AdaptationofModelstoEvolvingMetamodels.Tech.rep.RR-6723.2008.URL:https://hal.inria.fr/inria-00338695/document.

[37]KellyGarcésetal. ‘AdaptingTransformations toMetamodelChangesviaExternalTransformationComposition’.In:SoftwareandSystemsModeling13.2(2014),pp.789–806.ISSN:1619-1366.DOI:10.1007/s10270-012-0297-1.

[38] Jokin García, Oscar Diaz and Maider Azanza. ‘Model Transformation Co-evolution: A Semi-automaticApproach’.In:SoftwareLanguageEngineering-5thInternationalConference,SLE2012,Dresden,Germany, September 26-28, 2012, Revised SelectedPapers. LectureNotes in ComputerScience7745(2013).Ed.byKrzysztofCzarneckiandGörelHedin,pp.144–163.ISSN:03029743.DOI:10.1007/978-3-642-36089-3_9.

[39] Roxana Giandini, Claudia Pons and Gabriela Pérez. ‘A two-level formal semantics for the QVTlanguage.’ In:Memorias de la XII Conferencia Iberoamericana de Software Engineering (CIbSE2009).Medellín,2009,pp.73–86.

[40]BorisGruschko,DimitriosS.KolovosandRichardF.Paige. ‘TowardsSynchronizingModelswithEvolvingMetamodels’. In:Proceedings of the InternationalWorkshop onModel-Driven SoftwareEvolutionheldwiththeECSMR.Citeseer,2007.

[41] Esther Guerra and Juan de Lara. ‘An Algebraic Semantics for QVT-Relations Check-onlyTransformations’. In:FundamentaInformaticae114.1 (2012),pp.73–101.issn: 1875-8681.doi:10.3233/FI-2011-618.

[42] Kahina Hassam et al. ‘Assistance System for OCL Constraints Adaptation during MetamodelEvolution’.In:201115thEuropeanConferenceonSoftwareMaintenanceandReengineering(Mar.2011),pp.151–160.doi:10.1109/CSMR.2011.21.

[43]WilhelmHasselbring et al. ‘Projekt-orientierte Vermittlung von Entwurfsmustern in der SoftwareEngineeringAusbildung’. In:Engineering. Ed. by Andreas Zeller andMarcus Deininger. dpunktVerlag,2007,pp.45–58.

[44] Markus Herrmannsdoerfer, Sebastian Benz and Elmar Juergens. ‘COPE - Automating CoupledEvolutionofMetamodelsandModels’. In:ECOOP2009–Object-OrientedProgramming.Ed.bySophiaDrossopoulou.Vol.5653.LectureNotes inComputerScience.SpringerBerlinHeidelberg,2009,pp.52–76.DOI:10.1007/978-3-642-03013-0_4.

[45]MarkusHerrmannsdoerferetal. ‘AnExtensiveCatalogofOperators for theCoupledEvolutionofMetamodelsandModels’.In:SoftwareLanguageEngineering,ThirdInternationalConference,SLE2010,Eindhoven,TheNetherlands,October12-13,2010,RevisedSelectedPapers.Springer-Verlag,2010,pp.1–20.

[46] Inria. PathExpression to PetriNet & PetriNet to PathExpression. 2005. url:

http://www.eclipse.org/atl/atlTransformations/PathExp2PetriNet/ExamplePathExp2PetriNet[v00.01].pdf

(visitedon23/02/2015).[47]ISO/IEC/IEEE15288:2008SystemsandSoftwareEngineering-SystemLifeCycleProcesses.Tech.

rep. Geneva, Switzerland: International Organization for Standardization (ISO)/InternationalElectrotechnicalCommission(IEC),InstituteofElectricalandElectronicsEngineers,2008.

[48]ISO/IEC/IEEEStd42010:2011–Systemsandsoftwareengineering–Architecturedescription. LosAlamitos,CA:IEEE,2011.

[49] Frédéric Jouault et al. ‘ATL: a QVT-like Transformation Language’. In:Companion to the 21thAnnual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and

http://www-adele.imag.fr/Les.Publications/intConferences/WISME2004Fav.pdf

https://hal.inria.fr/inria-00338695/document

http://www.eclipse.org/atl/atlTransformations/

Applications, OOPSLA 2006. Portland, Oregon: ACM Press, 2006, pp. 719–720. DOI:10.1145/1176617.1176691.

[50] Lucia Kapová et al. ‘Evaluating Maintainability with Code Metrics for Model-to-ModelTransformations’.In:ResearchintoPractice–RealityandGaps.Ed.byGeorgeT.Heineman,JanKofron and Frantisek Plasil. Lecture Notes in Computer Science. Prague: Springer BerlinHeidelberg,2010,pp.151–166.DOI:10.1007/978-3-642-13821-8_12.

[51] Stuart Kent. ‘Model Driven Engineering’. In: Integrated Formal Methods, Third InternationalConference,IFM2002Turku,Finland,May15–18,2002Proceedings.LectureNotesinComputerScience2335.2(Apr.2002).Ed.byMichaelButler,LuigiaPetreandKaisaSere,pp.286–298.DOI:10.1007/3-540-47884-1_16.

[52]AnnekeGKleppe, JosWarmer andWimBast.MDAExplained: TheModel Driven Architecture:Practice andPromise. Boston,MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2003.ISBN:032119442X.

[53]PaulKlint,RalfLämmelandChrisVerhoef.‘TowardanEngineeringDisciplineforGrammarware’.In:ACM Transactions on Software Engineering andMethodology 14 (2005), pp. 331–380. DOI:10.1145/1072997.1073000.

[54]MaximilianKoegeletal. ‘ComparingState-andOperation-BasedChangeTrackingonModels’. In:201014thIEEEInternationalEnterpriseDistributedObjectComputingConference(Oct.2010),pp.163–172.DOI:10.1109/EDOC.2010.15.

[55]DimitriosS.Kolovosetal. ‘DifferentModels forModelMatching:AnAnalysisofApproaches toSupport Model Differencing’. In: Proceedings of the 2009 ICSE Workshop on Comparison andVersioningofSoftwareModels(2009),pp.1–6.doi:10.1109/CVSM.2009.5071714.

[56]ThomasKühne.‘Mattersof(Meta-)Modeling’.In:SoftwareandSystemsModeling5.4(July2006),pp.369–385.issn:1619-1366.doi:10.1007/s10270-006-0017-9.

[57]ThomasKühneetal.‘ExplicitTransformationModeling’.In:Proceedingsofthe2009InternationalConferenceonModelsinSoftwareEngineering.MODELS’09.Berlin,Heidelberg:Springer-Verlag,2010,pp.240–255.doi:10.1007/978-3-642-12261-3_23.

[58] Ivan Kurtev, Jean Bézivin and Mehmet Aksit. ‘Technological Spaces: An Initial Appraisal’. In:International Conference on Cooperative Information Systems (CoopIS), DOA’2002 FederatedConferences,IndustrialTrack(2002),pp.1–6.

[59]JuandeLaraandEstherGuerra.‘FormalSupportforQVT-RelationswithColouredPetriNets’.In:ModelDrivenEngineeringLanguagesandSystems.Ed.byAndySchürrandBrianSelic.Vol.5795.LectureNotesinComputerScience.BerlinHeidelberg:SpringerBerlinHeidelberg,2009,pp.256–270.isbn:978-3-642-04425-0.doi:10.1007/978-3-642-04425-0_19.

[60] Meir M. Lehman. ‘Laws of Software Evolution Revisited’. In: Software Process Technology 5thEuropeanWorkshop,EWSPT’96Nancy,France,October9–11,1996Proceedings.LectureNotesinComputer Science 1149 (1996). Ed. by Carlo Montangero, pp. 108–124. doi:

10.1007/BFb0017737.

[61]MeirM.Lehman.‘Programs,LifeCycles,andLawsofSoftwareEvolution’.In:ProceedingsoftheIEEE68.9(1980),pp.1060–1076.doi:10.1109/PROC.1980.11805.

[62] Tihamer Levendovszky et al. ‘ANovel Approach to Semi-automated Evolution of DSMLModelTransformation’. In: Software Language Engineering. Lecture Notes in Computer Science 5969(2010).Ed.byMarkvandenBrand,DragenGaševićandJeffGray,pp.23–41.doi:10.1007/978-3-642-12107-4_4.

[63]ErnstLippeandNorbertvanOosterom.‘Operation-basedMerging’. In:NewsletterACMSIGSOFTSoftware Engineering Notes 17.5 (1992). Ed. by Peter G. Neumann, pp. 78–87. doi:

10.1145/142868.143753.

[64]MohamedMaddeh,MohamedRomdhaniandKhaledGhedira.‘ClassificationofModelRefactoringApproaches’. In: Journal of Object Technology 8.6 (Sept. 2009), pp. 121–126. issn: 1660-1769.DOI:10.5381/jot.2009.8.6.a3.

[65] Slaviša Marković and Thomas Baar. ‘Refactoring OCL Annotated UML Class Diagrams’. In:SoftwareandSystemsModeling(SoSyM)7.1(2008),pp.25–47.doi:10.1007/s10270-007-0056-x.

[66]DavidMéndezetal.‘TowardsTransformationMigrationAfterMetamodelEvolution’.In:ModelandEvolution Workshop. inria-00524145. Oslo, 2010, pp. 1–6. url: https://hal.inria.fr/inria-00524145.

[67]TomMens,GabrieleTaentzerandDirkMüller.‘ChallengesinModelRefactoring’.In:1stWorkshoponRefactoringTools.Vol.98.UniversityofBerlin,2007.

[68] Tom Mens and P. Van Gorp. ‘A Taxonomy of Model Transformation’. In: Electronic Notes inTheoreticalComputerScience152(2006),pp.125–142.issn:15710661.DOI:doi:10.1016/j.entcs.2005.10.021.

[69]TomMensetal. ‘Challenges insoftwareevolution’. In:ComputerApril (2005).issn:1550-4077.url:http://www.computer.org/portal/web/csdl/doi/10.1109/IWPSE.2005.7.

[70]TomMens et al. ‘FormalizingRefactoringswithGraphTransformations’. In: Journal of SoftwareMaintenance and Evolution: Research and Practice 17.4 (2005), pp. 247–276. doi:

10.1002/smr.316.

[71] Parastoo Mohagheghi et al. ‘MDE Adoption in Industry: Challenges and Success Criteria’. In:ModelsinSoftwareEngineering.LectureNotesinComputerScience5421(2009).Ed.byMichelR.V.Chaudron,pp.54–59.doi:10.1007/978-3-642-01648-6_6.

[72] Tien N. Nguyen et al. ‘An Infrastructure for Development of Objectoriented, Multi-levelConfiguration Management Services’. In: Proceedings of the 27th international conference onSoftware engineering - ICSE ’05. New York, NY: ACM Press, 2005, pp. 215–224. isbn:1595939632.doi:10.1145/1062455.1062504.

[73] ObjectManagement GroupOMG.Meta Object Facility (MOF) 2.0 Query/ View/ TransformationSpecificationVersion1.1-January2011.2011.

[74]ObjectManagementGroupOMG.OCL:ObjectConstraintLanguageVersion2.3.1.2012.[75] ObjectManagement GroupOMG.OMGMeta Object Facility (MOF) Core Specification Version

2.4.1.2013.URL:http://www.omg.org/spec/MOF/2.4.1/.[76]ObjectManagementGroupOMG.OMGUnifiedModelingLanguage (OMGUML), Infrastructure

Version2.4.1.Aug.2011.URL:http://www.omg.org/spec/UML/2.4.1/.[77]ObjectManagementGroupOMG.OMGUnifiedModelingLanguage(OMGUML),Superstructure

v2.4.1.Aug.2011.URL:http://www.omg.org/spec/UML/2.4.1/.[78]ObjectManagementGroupOMG.OMGUnifiedModelingLanguage(OMGUML)Version2.5.Sept.

2013.URL:http://www.omg.org/spec/UML/2.5/Beta2/.[79] Klaas Oetken. ‘Übertragung von objektorientierten Refactoring-Patterns in die Software-

Modellierung’.BachelorarbeitinInformatik.CarlvonOssietzkyUniversitätOldenburg,2012.[80] WF Opdyke. ‘Refactoring Object-Oriented Frameworks’. PhD thesis. University of Illinois at

Urbana-Champaign,1992,p.197.[81]TerenceParr.TheDefinitiveANTLRReference:BuildingDomain-SpecificLanguages.ThePragmatic

Bookshelf,2007.ISBN:0-9787392-5-6.[82] Ralf Reussner andWilhelm Hasselbring.Handbuch der Software-Architektur. 1st ed. Heidelberg:

dPunkt.verlag,2006.ISBN:3-89864-372-7.[83]BernhardRumpeandRobertFrance.‘VariabilityinUMLLanguageandSemantics’.In:Softwareand

SystemsModeling 10.4 (Aug. 2011), pp. 439–440. ISSN: 1619-1366.DOI:10.1007/s10270-011-0210-3.

[84]DavideDiRuscio,Ludovico IovinoandAlfonsoPierantonio. ‘AMethodologicalApproachfor theCoupledEvolutionofMetamodelsandATLTransformations-6thInternationalConference,ICMT2013, Budapest, Hungary, June 18-19, 2013. Proceedings’. In: Theory and Practice of ModelTransformations.LectureNotes inComputerScience7909 (2013).Ed.byKeithDuddyandGertiKappel,pp.60–75.DOI:10.1007/978-3-642-38883-5_9.

[85]AndySchürr.‘SpecificationofGraphTranslatorswithTripleGraphGrammars’.In:Graph-TheoreticConcepts inComputerScience,20th InternationalWorkshop,WG’94Herrsching,Germany, June16–18,1994Proceedings.LectureNotes inComputerScience903 (1995).Ed.byErnstW.Mayr,GuntherSchmidtandGottfriedTinhofer,pp.1–17.DOI:10.1007/3-540-59071-4_45.

[86]EdSeidewitz.UML2.5:SpecificationSimplification-PresentedattheThirdBiannualWorkshoponEclipse Open Source Software and OMG Open Specifications. URL:

https://hal.inria.fr/inria-00524145

http://www.computer.org/portal/web/csdl/doi/10.1109/IWPSE.2005.7

http://www.omg.org/spec/MOF/2.4.1/

http://www.omg.org/spec/UML/2.4.1/

http://www.omg.org/spec/UML/2.4.1/

http://www.omg.org/spec/UML/2.5/Beta2/

http://de.slideshare.net/seidewitz/uml-25-specification-simplification (visited on05/10/2014).

[87]EdSeidewitz. ‘Whatmodelsmean’. In:Software,IEEE20.5 (2003),pp.26–32. ISSN:0740-7459.URL:http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1231147.

[88] S. Sendall and W. Kozaczynski. ‘Model Transformation: The Heart and Soul of Model-drivenSoftwareDevelopment’.In:Software,IEEE20.5 (Sept.2003),pp.42–45. ISSN:0740-7459.DOI:10.1109/MS.2003.1231150.

[89] Ian Sommerville. Software Engineering (7th Edition) (International Computer Science Series).Seventh Edition. Addison Wesley, May 2004. ISBN: 0321210263. URL:http://www.amazon.com/exec/obidos/redirect?tag=citeulike07-20&path=ASIN/0321210263.

[90] Jörn Guy Süss et al. ATL/User Guide - The ATL Language. last seen: 2013-10-02. The EclipseFoundation.Nov.2012.URL:http://wiki.eclipse.org/ATL/User_Guide_-_The_ATL_Language.

[91]HerbertStachowiak.AllgemeineModelltheorie.Wien,NewYork:Springer-Verlag, 1973. ISBN:3-211-81106-0.

[92]ThomasStahletal.ModellgetriebeneSoftwareentwicklung -Techniken,Engineering,Management.2.Auflage.Heidelberg:dpunkt.verlag,2007.ISBN:978-3-89864-448-8.

[93]JimSteelandJean-MarcJézéquel.‘OnModelTyping’.In:SoftwareandSystemsModeling6.4(Jan.2007),pp.401–413.ISSN:1619-1366.DOI:10.1007/s10270-006-0036-6.

[94]DaveSteinbergetal.EMF:EclipseModelingFramework.Ed.byErichGamma,LeeNackmanandJohnWiegand.2nded.Addison-Wesley,2009.ISBN:0-321-33188-5.

[95]TheEclipseFoundation.ATL.2014.URL:http://eclipse.org/atl/(visitedon20/10/2014).[96] The Eclipse Foundation. ATL/Developer GuideTitle. 2014. URL:

http://wiki.eclipse.org/ATL/Developer_Guide(visitedon05/11/2014).[97] The Eclipse Foundation. EMF Refactor. 2015. URL: https://www.eclipse.org/emf-refactor/

(visitedon12/01/2015).[98] The Eclipse Foundation. Graphiti - a Graphical Tooling Infrastructure. 2015. URL:

https://eclipse.org/graphiti/(visitedon14/02/2015).[99] The Eclipse Foundation. Java Development User Guide: Refactoring Support. 2015. URL:

http://help.eclipse.org/luna/index.jsp?topic

=/org.eclipse.jdt.doc.user/concepts/concept-refactoring.htm(visitedon12/01/2015).[100] The Eclipse Foundation. The ATL Transformations Zoo. 2015. URL:

http://www.eclipse.org/atl/atlTransformations/(visitedon23/02/2015).[101] The Eclipse Foundation. The Eclipse Modeling Framework (EMF) Overview. 2005. URL:

http://help.eclipse.org/kepler/topic/org.eclipse.emf.doc/references/overview/EMF.html

(visitedon13/08/2013).[102]TheEclipseFoundation.Xtext.2014.URL:http://eclipse.org/Xtext/(visitedon20/10/2014).[103] Massimo Tisi et al. ‘On the Use of Higher-Order Model Transformations’. In: Model Driven

Architecture-FoundationsandApplications5thEuropeanConference,ECMDA-FA2009,Enschede,TheNetherlands, June 23-26, 2009.Proceedings.Vol. 5562.LectureNotes inComputer Science.SpringerBerlinHeidelberg,2009,pp.18–33.DOI:10.1007/978-3-642-02674-4_3.

[104] Ragnhild Van Der Straeten, Viviane Jonckers and Tom Mens. ‘Supporting Model RefactoringsThrough Behaviour Inheritance Consistencies’. In: <<UML>> 2004 — The Unified ModelingLanguage.ModelingLanguagesandApplications.LectureNotesinComputerScience3273(2004).Ed.byThomasBaaretal.,pp.305–319.DOI:10.1007/978-3-540-30187-5_22.

[105] Ragnhild Van Der Straeten, Tom Mens and Stefan Van Baelen. ‘Challenges in Model-DrivenSoftwareEngineering’.In:ModelsinSoftwareEngineering,WorkshopsandSymposiaatMODELS2008,Toulouse,France,September28-October3,2008.ReportsandRevisedSelectedPapers.Ed.by Michel R V Chaudron. Vol. 5421. Lecture Notes in Computer Science. Springer BerlinHeidelberg,2009,pp.35–47.DOI:10.1007/978-3-642-01648-6_4.

[106]HansVangheluwe. ‘InvitedTalk:PromisesandChallengesofModel-DrivenEngineering’. In:15thEuropean Conference on Software Maintenance and Reengineering (CSMR), 2011. Ed. by TomMens,YiannisKanellopoulosandAndreasWinter.LosAlamitos,CA:IEEE,2011,pp.3–4.ISBN:978-1-61284-259-2.DOI:10.1109/CSMR.2011.62.

http://de.slideshare.net/seidewitz/uml-25-specification-simplification

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1231147

http://www.amazon.com/exec/obidos/redirect?tag=citeulike07-20&path=ASIN/0321210263

http://wiki.eclipse.org/ATL/User_Guide_-_The_ATL_Language

http://eclipse.org/atl/

http://wiki.eclipse.org/ATL/Developer_Guide

https://www.eclipse.org/emf-refactor/

https://eclipse.org/graphiti/

http://help.eclipse.org/luna/index.jsp?topic =/org.eclipse.jdt.doc.user/concepts/concept-refactoring.htm

http://www.eclipse.org/atl/atlTransformations/

http://help.eclipse.org/kepler/topic/org.eclipse.emf.doc/references/overview/EMF.html

http://eclipse.org/Xtext/

[107]GuidoWachsmuth.‘MetamodelAdaptationandModelCo-adaptation’.In:ECOOP2007–Object-OrientedProgramming.Ed.byErikErnst.Vol.4609.LectureNotes inComputerScience.Berlin,Heidelberg: Springer Berlin Heidelberg, 2007, pp. 600–624. ISBN: 978-3-540-73588-5. DOI:10.1007/978-3-540-73589-2.

[108]DennisWagelaar. ‘CompositionTechniques forRule-BasedModelTransformationLanguages’. In:TheoryandPracticeofModelTransformations.LectureNotesinComputerScience(2008).Ed.byAntonio Vallecillo, Jeff Gray and Alfonso Pierantonio, pp. 152–167. DOI: 10.1007/978-3-540-69927-9_11.

[109]ManuelWimmerandGerhardKramler.‘BridgingGrammarwareandModelware’.In:SatelliteEventsat theMoDELS2005Conference. LectureNotes inComputer Science 3844 (2006).Ed. by Jean-MichelBruel,pp.159–168.DOI:10.1007/11663430_17.

[110]AlannaZito,ZinovyDiskinandJuergenDingel.‘PackageMergeinUML2:Practicevs.Theory?’In:ModelDrivenEngineeringLanguagesandSystems.Ed.byOscarNierstraszetal.LectureNotesinComputerScience.SpringerBerlinHeidelberg,2006,pp.185–199.DOI:10.1007/11880240_14.

BibliografischeInformationderDeutschenNationalbibliothekDieDeutscheNationalbibliothekverzeichnetdiesePublikationinderDeutschenNationalbibliografie;detailliertebibliografischeDatensindimInternetüberwww.dnb.deabrufbar.

©SteffenKruseHerstellungundVerlag:BoD–BooksonDemandGmbH,NorderstedtISBN978-3-7392-5722-8

http://www.dnb.de

http://www.bod.en

Documents

Co-Evolution of Metamodels and Model Transformations: An operator-based, stepwise approach for the impact resolution of metamodel evolution on model transformations