A review of OMG MOF 2.0Query/ Views / TransformationsSubmissions

andRecommendationstowardsthefinal Standard

Tracy Gardner Catherine GriffinIBM Hursley DevelopmentLaboratorye-BusinessIntegrationTechnologies

MP 188,IBM Hursley, Winchester, SO212JNUnitedKingdom

email:�tgardner� catherinegriffin � @uk.ibm.com

JanaKoehler Rainer HauserIBM ZurichResearchLaboratory

e-BusinessSolutionsCH-8803Rueschlikon

Switzerlandemail:

�koe � rfh � @zurich.ibm.com

July21,2003

Abstract

Model-to-modeltransformationis a key technologyfor the OMG’s ModelDrivenArchitectureTM . Theneedfor standardizationin this arealeadto theMOF2.0 Query/Views/TransformationsRequestfor Proposals(RFP) from the OMG.TheRFPelicitedeightseparatesubmissions.

Thispapermakesthefollowing contributions:Terminologyfor queries,views,and transformationsis introducedthat is basedon the terminologyusedin thesubmissions,but which is editedfor consistency. A setof commontransformationscenariosis described,which is motivatedby the authors’practicalexperienceswith transformations.Thesubmissionsarereviewed,comparedto eachother, andtheirhighlightsdiscussed.Basedonthereview andtheexperienceof theauthorsindevelopingmodel-driventransformations,recommendationsfor thefinal standardarepresented.

1 Intr oduction

TheOMG’sModelDrivenArchitecture(MDA) [6] is asoftwaredevelopmentapproachin whichmodelsaretheprimaryartifacts.Abstractmodelsarerefinedto moreconcretemodels,eventuallyresultingin platform specificmodelsfrom which executablearti-facts(suchascodeandconfigurationfiles)canbegenerated.MDA differssignificantlyfrom earlierusesof modelinglanguagessuchastheOMG’s UMLTM[5] in which theprimary purposeof modelswasasan aid to understandingandcommunication.Thekey differencewith MDA is thatthemodelsarethekey partof thedefinitionof thesoft-waresystem.Ratherthanthemodelsbeinghandedoverto programmersto implement,all or muchof thestructureandbehavior of a systemis capturedin modelswhich areautomaticallytransformedinto code(andotherplatformartifacts).Theknowledgeoftheplatformis encodedinto transformationswhicharereusedfor many systemsratherthanredesignedfor eachnew system.

In MDA, automatedtransformationsplay a key role. It is importantthat transfor-mationscanbedevelopedasefficiently aspossible.A standardsyntaxandexecutionsemanticsfor transformationis animportantenablerfor anopenMDA toolschain.OnApril, 24, 2002the OMG issueda Requestfor Proposals(RFP)for MOF 2.0 Query,Views,andTransformations(QVT ) [7] to addressatechnologypartof theOMG MetaObjectFacility MOF 2.0 pertainingto the main issuesin the manipulationof MOFmodels:

1. Querieson MOF 2.0models,

2. Viewson MOF 2.0metamodels,

3. Transformationsof 2.0MOF models.

TheRFPhaselicited8 submissions,many submittedjointly by a numberof orga-nizations.Thesesubmissionstotal severalhundredpagesmakingit a time-consumingtaskto adequatelyassessthem.This papermakesthefollowing contributions: In Sec-tion 2, wedefineterminologybasedontheusagein thesubmissionsbut editedfor con-sistency. In Section3, asetof commontransformationscenariosbasedon theauthors’experienceswith modelto modeltransformationis introduced.Theauthorsof thepa-perareprimarily implementersof transformations[1, 10] ratherthanimplementersoftransformationexecutionlanguagesandenvironments.Section4 providesanoverviewof the submissionsandreviews thembasedon the RFPrequirementsandadditionalbenchmarks.Thissectionalsoidentifieshighlightsof theproposalsfrom theviewpointof theauthors.We concludein Section5 with a setof recommendationsfor thefinalQVT standardandgive a shortoutlookon currentlyongoingwork in Section6. Thegoalof thispaperis not to provideyetanotherQVT proposal,but to capturethebestoftheexistingproposalscombinedwith thepracticalexperiencesof theauthors.

2 Terminology

TheQVT RFPintroducessometerminologywhich we clarify here.Furtherterminol-ogy is introducedin thesubmissionsthemselves. In this section,we provide a unified

2

setof definitionsfor QVT -relatedterminologywhichenablestheproposalsto becom-pared.We begin with definitionsof thetermsquery, view, andtransformation, whicharefundamentalto theRFP.

Query A queryis anexpressionthatis evaluatedoveramodel.Theresultof aqueryis oneor moreinstancesof typesdefinedin thesourcemodel,or definedby thequerylanguage.An examplequeryover a UML modelmight be: Returnall packagesthatdo not containany child packages. The resultwould be a collectionof instancesofthePackagemetaclass.A furtherexamplequeryovera UML modelmight be: Doesaparticular attributein thesourcehavepublicvisibility? TheresultwouldbeaBooleanvalue.

The Object ConstraintLanguage(OCL) [5] is an exampleof a query language.Queriescanalsobe constructedusinga UML Action Semantics(asdefinedin UML1.5or UML 2) [5].

View A view is a modelwhich is completelyderivedfrom anothermodel(thebasemodel).A view cannotbemodifiedseparatelyfrom themodelfrom whichit is derived.Changesto the basemodelcausecorrespondingchangesto the view. If changesarepermittedto theview thenthey modify thesourcemodeldirectly. Themetamodeloftheview is typically not thesameasthemetamodelof thesource.

Viewsaretypically notpersistedindependentlyof theirsourcemodels(exceptper-hapsfor caching).Viewsareoftenreadonly. Whereviewsareeditablea changemadevia theview resultsin thecorrespondingchangein thebasemodel.It is thereforenec-essaryfor aneditableview to have a definedreversemappingbackto thebasemodel.A view maybepartial, that is basedon a subsetof thesourcemodel. A view maybecompleteandhave thesameinformationcontentasthe source,just reorganizedfor aparticulartaskor user. A queryis a restrictedkind of view. Views aregeneratedviatransformations.

Transformation A transformationgeneratesa target model from a sourcemodel.Transformationsmayleadto independentor dependentmodels.In thefirst case,thereis noongoingrelationshipbetweenthesourceandtargetmodeloncethetargethasbeengenerated.In thesecondcase,thetransformationcouplesthesourcemodelandtargetmodel.

A transformationmay be top-down, in which casethe target model is not modi-fied after generation,changesarealways madeto the sourcemodel andpropagatedto thetargetvia thetransformation.Transformationsmaybeone-way(unidirectional)in which caseadditionalinformationmaybeintroducedto thesourcemodelafter theapplicationof a transformation.Repeatedapplicationof thetransformationshouldnotoverwrite any information introducedto the target model. Transformationsmay betwo-way(bidirectional)in which caseeachmodelmaybe modifiedafter the applica-tion of the transformation,changesmustbe propagatedin eitherdirection. In somecases,changesmayhave beenmadeto bothmodels.If this is permittedthenthereisthepossibilityof conflictingchangeshaving beenmade.In this case,it is necessaryto

3

detectsuchconflicts,it maynot bepossibleto resolve themautomatically. A transfor-mationin which thetargetmodelreplacesthesourcemodelis referredto asanupdatetransformation.

Whendiscussingbidirectionaltransformationswe adoptthetermsleft-handmodelandright-handmodelto reflectthesymmetryof the relationship.Both modelsactassourceandtargetfor transformations.

A view is a restrictedkind of transformationin which the targetmodelcannotbemodifiedindependentlyof thesourcemodel. If a view is editable,the correspondingtransformationmustbebidirectionalin orderto reflectthechangesbackto thesourcemodel.

TheRFPrequestedadeclarativeapproachto transformationratherthananimpera-tiveapproach.A numberof theproposalschallengedthis requirementsoit is usefultointroducetheterminologyrelevant to bothapproaches.Thefollowing two definitionshavebeentakenfrom theFreeOnlineDictionaryof Computing[4].

Declarative A general term for a relational language or a functional language, asopposedto an imperativelanguage. Imperative(or procedural) languagesspecifyex-plicit sequencesof stepsto follow to producea result, while declarative languagesdescriberelationshipsbetweenvariablesin termsof functionsor inferencerulesandthe language executor(interpreteror compiler)appliessomefixedalgorithmto theserelationsto producea result.Themostcommonexamplesof declarativelanguagesarelogic programminglanguagessuch asProlog andfunctionallanguageslike Haskell.

Imperati ve Any programminglanguage that specifiesexplicit manipulationof thestateof thecomputersystem,not to beconfusedwith a procedural language.

For thepurposesof comparingthe proposals,we alsointroducethe category of ahybrid transformationin additionto puredeclarativeandpureimperativeapproaches.

Hybrid A combinationof declarative andimperative constructsto definetransfor-mations.Typically a declarativeapproachis usedto selectrulesfor applicationandanimperative approachis usedto implementthe detail of rulesthat arenot completelyexpresseddeclaratively. This issueis furtherexaminedin Section4.

Thefollowing termsareusedin thedefinitionof transformations.

Rule Rulesare the units in which transformationsaredefined. A rule is responsi-ble for transforminga particularselectionof the sourcemodel to the correspondingtargetmodelelements.A transformationis specifiedvia a setof rules. Compositionmechanismsfor rulesmaybedefined.A rule maycontaina declarationand/oranim-plementation.A puredeclarativerulewill containonly adeclaration,apureimperativerule will containonly animplementationandahybrid rulewill containboth.

4

Declaration A declarationis a specificationof a relation betweenelementsin theleft-handandright-handmodels.A declarationmaycontainsufficient informationtofully describethetransformationfrom left to right (unidirectional),thetransformationfrom right to left (unidirectional),or both (bidirectional). Alternatively, a declarationmay only be able to constrainthe left and right sidesto determinewhenan associ-atedimplementationshouldbe invoked. Note that in a bidirectionaltransformation,elementsfrom theright andleft sidesareavailablewhenthedeclarationis evaluated.

Implementation An implementationis an imperative specificationof how to createtargetmodelelementsfrom sourcemodelelements.An implementationexplicitly con-structselementsin thetargetmodel. Implementationsaretypically directed,i.e., theyoperatefrom left to right, or they operatefrom right to left. However, implementationsthatcanoperatein eitherdirectionarepossibleandarepermitted.

Match A matchoccursduring the applicationof a transformationwhen elementsfrom the left-handand/orright-handmodelare identifiedasmeetingthe constraintsspecifiedby the declarationof a rule. A matchtriggersthe creation(or update)ofmodelelementsin the target model,driven by the declarative and/orimplementationpartsof thematchedrule.

Incr emental Transformation If individual changesin a sourcemodelcan leadtotheexecutionof only thoseruleswhichmatchthemodifiedelementsthenthetransfor-mationis saidto supportincrementaltransformation.

3 CommonTransformation Scenarios

Theauthorsof thispaperareinvolvedin two, closely-relatedprojectsthatapplymodel-driventransformations:TheModel-DrivenDevelopmentIncubatorProject[1]1 in Hurs-ley andtheBusinessProcessIntegrationandAutomationProject[10]2 in Zurich. In thefollowing, we discusscommonscenariosthata transformationlanguagemustaddressbasedonour practicalexperienceof implementingtransformations.

Simple transformations A simple transformationis onethat transformssingleel-ementsin the sourcemodel to singleelementsin the target model. Quite often, thesourceandtarget modelshave essentiallythe samestructure.Many of the examplesthatareusedin theQVT proposalsareof this kind. A typical exampleis a transforma-tion from UML classes,attributesandoperationsto Java classes,fieldsandmethods.This typeof transformationis straightforward to implementimperatively, andshouldbeamenableto declarativeapproaches.

1Seealsohttp://www.mdbi.hursley.ibm.com.2Seealsohttp://w3.zurich.ibm.com/� koe/bpia-intranet.html.

5

Expressions Transformationsmayhaveto handlestringexpressionsin thesourceortargetmodel.Wherea metamodelfor theexpressionlanguageexists,expressionscanbetreatedasinstancesof thatmetamodelandrequirelittle specialsupport.However,in many casesit may be unnecessaryto fully parsethe expressionandsomesimplesupportfor transformingtext is sufficient.

The authorsof this paperhave workedon transformationswith BPEL4WS[3] asthemajortarget.ThetransformationswehaveimplementedfromUML to BPEL4WS[1]and from businessview modelsto BPEL4WSandAdaptive Entities [10] have sev-eralexamplesof expressionhandling,including transformingsourceexpressionsintoequivalenttargetexpressions,into elements,or into attributesettingson elements.

Naming Anothercommonsituationrequiringtext handlingoccurswhenthesourceandtarget modelshave differentrestrictionson naming,or differentnamingconven-tions. For example,UML allows many charactersin namesthat Java doesnot allow.This mustbehandledin somewaywhengeneratingJava from UML. Oneapproachisto automaticallymanglenamesin a standardway to make themvalid. Any referencesto thosenamesthat occurelsewheremustalsobe mangledfor consistency. Alterna-tively, theJavanamingrestrictionscanbeenforcedon theUML model.

ComplexTransformations Thistypeof transformationbuildsstructuresin thetargetmodelwhichdonotdirectlycorrespondto any individualelementin thesourcemodel.Thetransformationsmaybebasedon complex algorithmsandheuristics.

Thetransformationswe have implementedconvert unstructuredactivity graphsorprocessgraphsinto structuredBPEL4WSactivities. They partition the graphsintosub-graphs,basedon the control flow andothercriteria, andbuild a well-structuredBPEL4WSprocess.This sort of transformationcanbe difficult to describedeclara-tively.

Regenerationand Reconciliation Having useda transformationto generateatargetmodel,it is likely that the userwill want to modify the generatedoutput. Whensub-sequentlythesourcemodelis alsochanged,it wouldbedesirableif thetransformationcanbere-appliedwhile maintainingany changestheuserhasmade.Trying to main-tain userchangesmay leadto conflicts,which mustbe resolved—perhapsby askingtheuserwhatshouldbedone.

Transformation fr om partial sourcemodels It is oftenusefulto beableto gener-atea partial target model from a partial sourcemodel. For example,in the UML toBPEL4WStransformationdescribedin [1] behavior is describedusingactivity graphswhichcanbetransformedto executableBPEL4WS.Duringtop-downdevelopment,anactivity graphcanbegeneratedwhichcontainednamedactivity nodeswith controlflowbut which doesnot yet have all of thedetail of theactionswithin theactivities elabo-rated.Suchamodelcontainssufficient informationto beableto generateaskeletonofaBPEL4WSdocument,which is usefulfor modelerswhoarefamiliarwith BPEL4WSandalsoin scenarioswhereusersarepermittedto addinformationto eithera UMLmodelor its correspondingBPEL4WSdocument.

6

Resilienceto errors Theoccurrenceof anexceptionduringtransformationexecutionshouldnot halt the transformation,i.e., insteadof just aborting,it shouldbe possibleto generatea partial model. Rules that are not affectedby the error in the sourcemodelshouldbeexecutedasusual,resultingin a partial targetmodel. This approachallowsmultipleerrorsto bedetectedin asinglepass.Therequirementof transactionalbehavior of transformationrulesis directly relatedto this feature.

M-to-N Transformations It cannotbeassumedthatthereis aone-to-onecorrespon-dencebetweensourceandtargetmodels.The transformationsmentionedearliertakein a sourcemodelandgeneratemultiple targetmodelsfrom threedifferentmetamod-els(BPEL4WS,WSDL andXSD in onecase,andBPEL4WS,WSDL, andSACL—ametamodelto specify statemachines—inthe other case). Note, even if it is possi-ble to split sucha transformationinto multiple one-to-onetransformationsthis maybeaninefficient implementation.Supportfor one-to-many transformationis particularlyvaluablein caseswheretheresultingmodelswill be interdependentandmustrefer toelementscreatedduringthetransformation.Transformationsthatcombinemodelsthatrepresentdifferentconcerns(or aspects)of a problemarelikely to bemany-to-one.Inthegeneralcase,many-to-many transformationsmustbesupported.

4 A Summary of the Submissions

The QVT standardis viewed asessentialto make Model-DrivenArchitecturesa suc-cess.Thefollowing generalrequirementswereformulated:

� The proposalsshouldbe preciseand functionally complete,but alsominimal-istic. Compliancepointsshouldbe specifiedandexisting standardsshouldbereusedwheneverpossible.

� Theproposalsshouldbecompatibleor clearlyspecifythechangesand/orexten-sionsthey makewith respectto existingOMG specifications.

� The proposalsshouldbe implementationindependent,addresssecurity issueswhereneededandspecifythedegreesof internationalization.

The MDA TechnicalPerspective statesthat relationshipsbetweenmodelsshouldbedefinedat thesamelevel of abstractionastheirmetamodelsdefinedin MOF. Giventhat all modelswill be representedin MOF, a single transformationlanguagefor allMOF modelsis possibleandshouldbeformulatedin theproposals.Mappingsto anynon-OMGlanguageshouldbeobtainablebydefiningaMOF metamodelfor suchalan-guage.Transformationsaredefinedasmappingsandauniquetransformationlanguageis consideredto play a role similar to the role XSLT playsfor XML representations.Queriesarerequiredto filter andselectelementsfrom amodelsimilarto XPATH thatisusedto selectelementsfrom anXML model.Views areconsideredasmodelsderivedfrom othermodels.AlthoughtheRFPinitially callsfor views on metamodels(see[7]andSection2), theremainingRFPdocumentdiscussesviews of concretemodelsthatrevealspecificaspectsof amodeledsystem,not themetamodel.

7

Apart from thesegeneralrequirementsthatareapplicableto almostany standard,morespecificrequirementsareformulatedthataddressQVT -specificissues:

� Proposalsshoulddefinea languagefor transformationdefinitionsthat can bedeclaratively representedin MOF, i.e., a transformationis a MOF modelitself.The languagemustbeexpressive enoughto expressall requiredinformationtoautomaticallygeneratea targetmodelfrom a sourcemodel.Thetransformationlanguageshouldalsoallow to formulateandcreateaview of a metamodel, but ingeneral,all mechanismsshouldoperateon model, i.e., instancesof metamodelsdefinedin MOF 2.0.

� A transformationshouldsupportthepropagationof incrementalchangesoccur-ring in onemodelto theothermodel.Althoughsingletonsetsof modelsarethemain focus, it shouldalsobe possibleto transformmultiple modelsinto eachother.

Theoptionalrequirementssummarizedbelow arealsoveryinterestingandreceivedquitesomeattentionin many of thesubmissions:

� Transformationsshould be definedsymmetricallyand go beyond the simplesource-to-targetapproach.

� Transformationsshouldbe ableto implementupdates,i.e., the target model isthesameasthesourcemodel.

� Inversetransformationsshouldbedefinablesuchthat ������� ���������� .

� Theproposedlanguagesshouldsupportthetraceabilityof transformationexecu-tions. Transformationswith a transactionalcharactershouldbedefinable(com-mit, rollback)thatwouldpreventthataninvalid (notwell-formed)modelresultsfrom a transformationthathasfailedduringexecution.

� A transformationlanguageshouldsupportthe reuseand extensionof generictransformations,it shouldprovidemechanismsfor theinheritanceandoverridingof transformationsandtheability to instantiatetemplatesor patterns.

� Theuseof additionaltransformationdata,which arenot containedin thesourcemodel,but parameterizethetransformationprocess,shouldbepossible.

The OMG Action Semanticsspecification[5] is mentionedas alreadyhaving amechanismfor manipulatinginstancesof UML modelelements.Submittersarethusalsorequestedto discusshow their proposalrelatesto theUML Action Semantics.Inresponseto theRFP, 8 proposalsweresubmittedandarelistedattheOMG website[7]:

1. AdaptiveLtd. (in thefollowing abbreviatedwith ADAPTIVE)

2. DSTC/IBM (abbreviatedwith DSTC)

3. CompuwareCorporation/SunMicrosystems(SUN)

8

4. Alcatel/Softeam/TNI-Valiosys/Thales(THALES)

5. KennedyCarter(KC)

6. TCS,which comprisesArtisanSoftware,Kinetum,Kings College,andtheUni-versityof York (TCS)

7. CodagenTechnologiesCorporation(CODA)

8. InteractiveObjectsSoftwareGmbH/ProjectTechnology(IO)

In thefollowing, wewill briefly summarizethevariousproposalsandhighlight thestrengthsandweaknessesgiventhefollowing criteria:

� Easeof technicaladoption,i.e., could we, asimplementersof transformations,applyaproposedsolutionto solveour transformationproblems,

� Scalabilityof theproposedsolutionin termsof sizeandcomplexity,

� Completenessof the proposaland readability/self-containednessof the docu-mentation.

We alsoconsideredthe benchmarksfor mappingapproachesasthey weredevel-opedin [8], becausethesealsoexpresssomeof our own requirements:

� Bidirectionalmappingsshouldbesupported.

� Both directionsof themappingshouldbecapturedin onedefinition.

� It shouldbepossibleto definerich well-formednessconditionsonmappings.

� Mappingsshouldbeeasyto understandandwrite.

� Mappingdefinitionsshouldfacilitatetheconstructionof tools,which

– given a sourceand a target model and a mapping,decidewhetherthesource/targetpair is a valid instanceof themapping,

– provideautomatedsupportfor reconciliationof dynamicallychangingmod-elsto preventinconsistenciesto occur,

– allow to partially generateonesideof a mappingif a completegenerationis not possiblein a fully automaticmanner,

– inter-operatewith modelingtools.

We would like to mentionthat we found many submissiondocumentsto be in-completeand sometimesso unclearlyformulatedthat we cannotguaranteethat thefollowing review exactly matchesthe intentionsof the submitters.To the bestof ourefforts, it is basedonour understandingof thesubmissionsthatwewereableto derivefrom theavailabledocuments.

9

4.1 Queries

All proposalsseequeriesasa requirednecessarypartof a transformation,i.e.,a querydetermineswhenandhow a transformation(rule) is applicableto a model(or a setofmodels)andhow the resultof the transformationwill be built. Several submissionsproposeto usetheOCL 2.0 language:IO, SUN,TCS.

IO definesqueriesasameansto performmodelanalysis.Executingaquerycanbeseenasa specifictransformationtask,sinceit only returnselementsfrom the model.Note that this understandingis more limited than our own definition as we spelledout beforein Section2. IO alsodiscussesthat queriesmustbe able to crossmodelboundarieswhenusedduringa transformation,i.e.,aquerymustbeableto referto thesourceandtargetmodelaswell asto a transformation’sexecutionhistory.

THALES proposesan extensionto OCL calledTRL. A querycannotonly returnelementsfrom the queriedmodelasan answer, but canalsoreturna compositetype(e.g.,a tupleor collection)or amorecomplex typedefinedby somemetamodel.

TheCODA submissionproposesanextensiontoXQueryandXPATH, calledMTDL,asthe querylanguage.It is definedsimilar to a relationaldatabasequery. A Select-Statementcontainsa PathExpressioncontainingseveral PathStepseachof themcanrefer to a sourceor target model transformationpath to allow “the navigation oversource(or target) elementsfrom the currentelement”. Within the context whereitis written, we understandthis asbeingsimilar to the IO proposalof referring to theexecutionhistoryof a transformation.

KC proposestheUML Action Semantics[5] for queriesandto useits Action Se-manticsLanguageASL [11] asaconcretesyntax.Fromourpointof view, thisamountsto useany arbitraryprogramminglanguageasa querylanguage.We would thereforenotagreewith theKC statementthatthissubmissionproposesa fully declarativesolu-tion, but considerit asanimperativesolution.

TheADAPTIVE proposalcontainsno proposalfor a querylanguage,but only ad-dressestheproblemof views.

TheDSTCsubmissionviews queriesasspecifictransformationsandbuilds on thefact that the transformationsarethemselvesrepresentedasmodels.Thequerymodelis thusa subsetof the transformationmodel,which is basedon F-logic [9]. It is notexplicitly statedin thesubmitteddocument,which subsetof thetransformationmodelconstitutesthe query model, but the transformationmodel containsa Query object,whichassociatesPatternDefinitionsandinheritsaVariableandPatternScope.Queriesareconsideredto returnexistingelementsfrom amodel,not to constructnew elements.

Figure 1 summarizesour understandingof the submissionsalong two importantdimensionsthat we identified. On the X-axis, we distinguishwhetherthe query isselective, in thesensethatit canonly returnelementsfrom thequeriedmodel,or con-structive,in thesensethatit canreturnotherelements/valuesaswell. OntheY-axis,wedistinguishwhetherthequerylanguageis fully declarative,is declarative,but allowstorefer to theexecutionhistory, or is imperative. Sincewe classifiedKC asimperative,wealsobelieve it is constructivedueto theflexibility of theAction Semantics.

10

Figure1: A Classificationof theSubmissionsfor Queries

4.2 Views

Mostof thesubmissionslink viewsverycloselyto queriesand/ortransformations.Theonly exceptionis theADAPTIVE submission,whichproposesto useaportal-basedap-proach,but the documenthasformattingproblemsandappearsvery incompletecon-taining only 8, partially emptypages,suchthat we cannotsaymuch aboutit. Twoanglesof understandingof aview canbeobserved3:

� A view is producedastheresultof aquery, i.e.,aview is thevisualizationof thequeryanswer(CODA)

� A view is theresultof a transformation(THALES, KC, TCS,IO, SUN,DSTC).

Consequently, the proposalscarry over their solutionsto transformationsand/orqueriesto the problemof creatinga view of a model. The CODA proposaldefinesviewsastheresultof queries,whicharerepresentedin MTDL. Transformationscanbedoneonthemodelitself or onany view of it. THALES definesviewsasaprojectiononaparentmodelcreatedby atransformation.Viewsareasqueriesexpressedin theTRLlanguage.KC againproposesto usetheUML Action Semantics.A view is considereda transformationin which thetarget is completelyderivedfrom thesource.SUN seesviewsasspecifictransformationsrepresentedin XMOF. In theTCSsubmission,aviewis a projectionon a parentmodelcreatedby a transformation.IO definesa view asaspecifictransformation(“an abstraction”)whereviewpointswill becreatedby modeleditorsthat operateonly on a subsetof a metamodel. The DSTC submissionalsoconsidersviewsasspecifictransformations,but emphasizesanimportantdifference:

“The only differencebetweena transformationanda view is theunderly-ing implementation.For a transformation,thetargetextentis independent

3However, this differenceis marginal in thesensethatall proposalsseequeriesasan integral part of atransformation.

11

of sourceextent; its objects,links andvaluesare implementedby storingthem. For a view, the target extentremainsdependenton the source ex-tent; its objects,links and valuesare computedusing the source extent.Thedefinitionof transformationsandviewsis thesame(thespecificationof sourceandtargetmodelsandtherelationshipsbetweenthem).”

Weseethefollowing importantdifferencein theunderstandingof views—comparethisalsoto ourdefinitionof viewsin Section2: Is theview linkedto themodelor doesithaveanindependentexistenceandcanit bemanipulatedwithoutnecessarilychangingthemodelfromwhich it wascreated?Only theDSTCproposaladdressesthis issuein aclearway andstatesthatviews remainphysicallylinkedto themodel,i.e.,any changein the modelwill alsooccurin the view if this view containsthe changedpart of themodel.Fromtheotherapproaches,wecouldnotderiveaclearanswerto thisquestion.TheCODA proposalevenseemsto imply thatmodelsandviews canbe manipulatedindependentlyof eachother.

4.3 Transformations

In a nutshell,all proposals(exceptADAPTIVE) adopta unifying solutionto queries,views,andtransformations.In foursubmissions,exactlythesamelanguageis proposedto solveall threeaspects:KC proposestheUML Action Semantics,THALES proposesTRL (anextensionof OCL 2.0),DSTCproposesF-Logic [9], CODA proposesMTDL(anextensionof CMOF).

The othersubmissions(IO, SUN, TCS) proposeto useOCL 2.0 [5] for queries.The queriesare usedinside transformationsto determinewhen a transformationisapplicable.Thetransformationlanguagesareseparatedefinitionscomprisingdifferentelementsandformalisms. Following below, we evaluatethe variousproposalsalongourpreviously introducedcriteria:

Selfcontainedness Most documentsarenot really selfcontained.KC andDSTCes-sentially refer to other languagesdescribedelsewhere. All otherproposalsshow themetamodelsof their languages,but usuallyomit a detaileddescriptionof the seman-tics. The examplesgiven areeitherhighly simplified or non-existent. Therefore,inmany cases,onecanonly obtaina very limited pictureof how a transformationwouldberepresentedandexecuted.

Scalability We distinguishscalingbehavior in termsof the size of transformationmodelsandscalingbehavior in termsof thecomplexity of thetransformationsthatcanbe expressed,cf. the scenariosdiscussedin Section3. Declarative proposalsthatas-sumea uniform rule base(DSTC,IO) canbe assumedto scaleworsethanproposalsthatintroducea structuredtransformationbase(TCS).Thecomplexity of thetransfor-mationsthatcanbeexpressedis determinedby theexpressivity of thetransformationlanguage.KC’sproposalto usetheUML Action Semanticsyieldsthemostexpressivesolutionsinceit allowsto escapeto arbitraryprogramminglanguages.Similarcodees-capesareprovisionedby IO, SUN,andTCS.In contrastto this,THALES, CODA, andDSTCproposedeclarative,decidablelanguages,which arelessexpressive,but should

12

have advantagesin termsof tooling support(e.g.,decidingconsistency of transforma-tionsmayonly bepossiblefor them,not for theothers).

Many approachesassumethatthetransformationrulesetcanbestructuredto someextent. The mostdetailedproposalfor a structuringof the rule setcomesfrom TCS.Rulesin the TCS submissionhave a stateand they canspecializeother transforma-tionsor bedefinedascomposites.A rule cantransformbetweenanarbitrarynumberof domains(classes,associations,packages),but theremustbe uniquenamesfor allattributesanddomains.The proposalenvisionsa hybrid representationfor the trans-formationrules,seeFigure2.

Figure2: TransformationRulesasRelation-MappingPairsin theTCSsubmission

Thedeclarative part is calleda relation, while theimplementationalpart is theac-tualmappingthattakesplace.Relationsaremultidirectionalandnon-executable.Theycan be composedout of other relationsusing NOT, AND, OR subrelationsand so-calledelaborations, which for example,replaceanabstractrelationby asetof detailedrelations.Mappingsareexecutableandcanbe describedin someActions SemanticsLanguage.A mappingcanrefineany numberof relations,i.e., thesameimplementa-tion canbereusedin severaldeclarativerule definitions.

Transformationsare organizedinto an orderedsequenceof stepsthat definetheoperationalpart,cf. Figure3. Eachstepis specifiedby a setof transformationtasks,with eachtaskbeingdefinedasa setof relation-mappingpairs. Transformationtaskscanbe marked as transactional.The traceabilityof a transformationis achieved vialoggingthetransformationsteps.

Simplicity Whethera transformationdefinition is easyto understandandwrite de-pendsalso on personalpreferences.Assumingthat transformationswill be writtenby programmers,any programming-likesolutionusingAction Semanticscouldbeas-sumedto be (fairly) simple. The declarative IO proposalalreadyreportsproblemsin maintainingandcompletinglarge rule sets,but not in writing a single rule. Purelogic-basedlanguages(suchasproposedby DSTC)will beharderto useby thosenotexperiencedin usingtheformalism.

13

Figure3: Structureof a Transformationin theTCSsubmission

Bidir ectional mappings canbeprovidedin termsof transformationdefinitionsandin termsof transformationexecutions. The definition of a transformationis usuallygiven asa setof rules, i.e., a single rule is the basicunit of transformationthat canbe definedandexecuted. Figure4 categorizesthe proposalsalong two dimensions:whetheranimperative,hybrid,or declarative languageis usedto write transformationrules,andwhetherthetransformationrulesareexecutablein only onedirection(fromsourceto target), which we call unidirectional,or from both directions(from sourceand target), which we call bidirectional. Someapproachesenvision mixed typesoftransformationruleswithin thesametransformationmodel,i.e., somerulesareunidi-rectional,while othersarebidirectional.We classifiedthoseapproachesasuni/bi.

Figure4: A classificationof thesubmissionwith respectto theproposednatureof thetransformationlanguagesandtheir possibleexecutiondirections

14

Variousproposalsdiscusswhetherthesourceor targetmodelshoulddrive theex-ecutionof a transformation.Note that whenrulesarebidirectionallyexecutable,theexecutiondirectionmustbe determined,e.g.,by selectingonerule side(pattern)thatshouldbematchedandtheotherrule sidethatshouldbederived,seefor exampletheSUN submission.TheDSTCproposaldiscussesaspect-driventransformations,whichwouldnotbedrivenby specificMOF elementsin thesourceor targetmodel,but ratherby somesemantic,representation-independentconcept.Althoughaspect-driventrans-formationsarean interestingidea,it remainsopenhow they would berepresentedintheQVT standard.While we got theimpressionthatsomeproposalsfavor onesidetodrive thetransformation,othersallow thedriving sideto bearbitrarily specified.

Furthermore,we foundassumptionsin thesubmissionsthatreferto thecardinalityof thesourceandtargetmodelsets.Thereareapproachesthatassumemultiple sourcemodelsfrom whichonetargetmodelis produced,while othersenvisionasinglesourcemodeltransformedinto varioustargets,or in themostflexible case,many sourcemod-elscanbetransformedinto many targetmodels.Figure5 summarizesour findings.4

Figure5: DriversandInput/Output-Cardinalityof Transformations

Easeof Adoption Given our impressionof the currentstateof the proposals,weassumeit to be moreor lessequallyhardto adoptany of them. At the oneside,onecouldsimply applyone’s preferredprogramminglanguageto adopttheKC proposal,i.e., the transformationsthat we have implementedin Java alreadytoday, could beconsideredas an adoption. However, this is of coursenot the intention of the KCsubmission.At the oppositeside,we would locatethe DSTC proposal,of which wethink thatit canonly befully exploitedafterhaving understoodthehundredpageslongpaper[9] until goodtoolingsupportwill beavailable.

Rich Conditions The answerto this criterion correspondsdirectly to the proposedquerylanguage,sinceall submissionsusetheirquerylanguageto formulateconditions

4ADAPTIVE andKC have beenomitted, becausethey do no provide any informationon this aspectof transformations. In the caseof CODA, we are not surewhetherit is really source-driven and someunsecurityalsoremainsin thecaseof SUN andTHALES, whichcouldbemoregeneralthanis visible fromtheir submissiondocuments.

15

in transformations.

Tooling Aspect Many claimsaremade,but it is hard to tell whetherthey aremetwithout undergoinga comprehensive evaluationof the tools,which arenot easilyac-cessible. The importantrequirementsof model reconciliation,failure handling,andconsistency checkingandmodel integrationare widely discussed,but we could notfind a proposalso far that would convincingly demonstratehow theseissuesarere-solved in a tool. The IO submissionfor example,proposesto defineand checkaconstraintbeforethequeryin a mappingrule is executedandbeforethe targetmodelis actuallymodified. Many proposalsadmit that theseissues,althoughimportant,arenotyetaddressedby theirsubmission.Many of theproposalsalsoarguedthatdefiningsymmetricor inversetransformationsor consideringthemassomethingspecialis notvery meaningfuland that the practicalrelevanceof inversetransformationsremainsunclear. Insteadof defining inversetransformations,it wasproposedto definepairsof complementarytransformationrules,seefor examplethe IO submission.Securityaspectswerediscussed,but we did not find many concreteproposals.The problemof updatinga modelis usuallyconsideredasbeinga standardtransformationproblemandwe did not seespecificsolutionsto handleupdatesof thesamemodelexceptthatonemay distinguishbetweenupdaterules that modify a modelandcreaterules thatgenerateanew model,e.g.,in theTHALES submission.

5 Recommendations

This sectionintroducesa set of recommendationsfor the final QVT standard. Therecommendationsarebasedon the highlightsof the initial responsesto the RFPandtheauthors’experiencesin developingmodel-to-modeltransformations.

Recommendation1: Support a hybrid approachto transformation definitions.In the experienceof the authors,a declarative approachis usefulfor specifyingsim-ple transformationsandfor identifying relationsbetweensourceandtargetmodelel-ements. However, many transformationsarenot straightforward. This is especiallytrue when transformingbetweenlanguagesat a similar level of abstraction,suchashorizontaltransformationsandtransformationsto middlewareplatformsthat supporthigh-level abstractions. It may not be possiblefor the target audienceof transfor-mation languagesto constructcomplex transformationsusinga fully declarative ap-proach.An imperative languageis preferablefor the definition of complex many-to-many transformationswhich involvedetailedmodelanalysis.Thefollowing quotebyAdamBosworth [2] supportsour recommendation:

AlanKayis supposedto havesaidthatsimplethingsshouldbesimpleandhard thingsshouldbepossible. It hasbeenmyexperienceover 25 yearsof software developmentthat for mostsoftware products,simplethingsshouldbe declarative and/or visual and hard thingsshouldbe procedu-ral. Declarative languageshavean unfortunatetendencyto metastasizebecausepeopleneedto do thingsthat are hard. Whenthey grow in this

16

way, not only can mostpeoplenot usethesenew features, they find theentire languagemoredaunting.

Recommendation2: Provide a simpledeclarativespecificationlanguage.Also in line with the above quotefrom Bosworth, we recommendthat the languageusedfor declarative specificationis simple. A graphicalconcretenotationfor the lan-guageis likely to beof valueto someusercommunities.Simplicity is somewhatsub-jective, but asa guideline,the capabilitiesof the declarative languageshouldnot gobeyond the point at which a capablemodeler/programmerwould find an imperativespecificationmorestraightforwardto construct,comprehend,andmaintain.

Recommendation3: Usedeclarativequeriesonly.Do notallow to link aqueryto aspecificruntimeexecutionof aQVT session.Keepthequerylanguagefully declarative. Allow it to returnnotonly elementsfrom thequeriedmodel,but alsoanswertypesdefinedby somemetamodel.In thesimplestcase,aquerycanreturna booleanvalueevenif booleansarenot partof thequeriedmetamodel. Itshouldbediscussedwhethera querystatementshouldbedecidableover a model. Inthis case,the full expressivity of programminglanguagesshouldnot be allowed, butlanguagessuchas OCL shouldbe preferred. The recommendedspaceis shown inFigure6.

Figure6: A recommendedSpacefor QueryLanguages

Recommendation4: Provide an abstract syntax for the transformation language.The transformationlanguageshouldhave a definedabstractsyntaxfor composition,declarative, and imperative parts. Wherepossibletheseshouldbe basedon existingOMG standards.The proposalmay specifyan exampleconcretesyntax,but shouldpermitotherdeclarativeandimperativelanguagesto bepluggedin via transformationsto theabstractssyntaxspecifiedin theproposal.

Recommendation5: Adopt commonterminology.In Section2, we put togethera setof definitionsthatprovide a unifying view on themajorconceptsoccurringin theQVT space.We recommendthata final standardwill

17

preciselydefinea commonterminology. In general,we assumethat thefinal standardspecificationwill bea complete,selfcontaineddocument.

Recommendation6: Usethe Action Semanticsasan interchangeformat.Imperativepartsof rulesshouldbeexchangedvia UML Action Semantics.TheUML2.0 Action Semanticswill be appropriatewithin the timescaleof this RFP. This willprovideastandards-basedinterchangeformatfor imperativespecificationsof transfor-mationbehavior while permittingtheuseof particularconcretesyntaxesthatareappro-priatefor usein particulardevelopmentenvironments.Suchconcretelanguagescouldincludetextualor graphicalconcretesyntaxesfor UML Action Semantics,e.g.,theASL[11], imperative languagesspecificallydesignedfor thespecificationof rules(suchastheTRL languageproposedin theTHALES submission),or programminglanguagessuchasJavawhereamappingto UML Action Semanticsis provided.

Recommendation7: Support symmetric rule definitions.It shouldbe possibleto describesymmetricrules that can be executedleft-to-right,right-to-left,or in areconciliationmodewherebothsourceandtargetmodelsexist andeithermayhave beenmodified. Symmetricrule definitionsfacilitatethedevelopmentof bidirectionalmappings,avoid theduplicationthatoccurswhenaruleandits inversearedefinedseparately, andprovideausefulstartingpoint for reconciliation.Symmetri-cally definedrulesmaycontaindirection-dependentimplementationpartsthatareusedwhentherule is executedin thecorrespondingdirection.Figure7 showsthespacethatwerecommendfor therepresentationof rules.

Figure7: A recommendedSpacefor RuleRepresentations

Recommendation8: Support compositionand reuse.It is often valuableto be able to constructa complex transformationfrom multipleintermediatetransformations,eitherbecausesomeof the sub-transformationsalreadyexist, becausetheintermediateresultsareof interest,or to decomposetheproblemintosimplersteps.Theproposalmustsupportcompositionandpackagingmechanismstosupportthedevelopmentof largetransformationsandsystemsconstructedfrom mul-tiple transformations.Thesemechanismsshouldcomefrom UML. A transformation

18

definitionshouldbeanexecutableUML model.Thegeneralizationandtemplatingca-pabilitiesof UML shouldbe consideredfor rulesandtransformations.Furthermore,the transactionalbehavior of composedtransformationsis anotherissuethatdeservesdeeperexploration.

Recommendation9: Support complextransformation scenarios.Thetransformationscenariosdescribedin Section3shouldbesupportedby theadoptedstandard.Therequirementshave all arisenfrom practicalexperienceswith theimple-mentationof transformations.Figure8 shows the spacefor rule executionsthat werecommendto offer the largestpossibleflexibility in supportingcomplex transforma-tion scenarios.

Figure8: A recommendedSpacefor RuleExecutions.

Recommendation10: Provide completeexamples.The final proposalshould include a numberof completenon-trivial transformationspecifications.Theseshouldpreferablybe standards-basedtransformationsof valueto the MDA community. Goodexamplescould be a reversiblemappingbetween(asubsetof?) Java andUML 2.0 Action Languageor an implementationof a MOF 2.0packagemerge(amany-to-onemapping).

Recommendation11: Establish requirementson transformation executions.We foundtheproblemof errorsduringa transformationandtheoptionalrequirementof transcationaltransformationsto beimportantin orderto achieverobusttransforma-tionsin practice.A standardshouldclarify this issueandprovide a solution. Further-more,thequestionof how largetransformationswill behandledshouldbeaddressed,i.e., how will transformationswork in two directions,how will incrementalchangesof modelsand“life modelsynchronizations”besupported,andhow will associationsbetweensourceandtargetmodelelementsbeestablished.

Recommendation12: Emphasizethe tooling aspect.We found the definition of usecasesusefulto derive requirementsthat a tool should

19

satisfyandto show how the standardcansupportthe scenariosdescribedin the usecases.Usability andease-of-useaspectsseemto be of critical importance.Anotherimportantissueseemsto be the consistency andcompletenessproblemsthat shouldbefurtherclarified: How doesa transformationdesignerknow thathis rule setis con-sistentandwill producea valid targetmodel? How doeshe know thathis rule set iscompleteandwill producea completetargetmodel?Are theresultsof rule executionsdeterministicor candifferentoutcomesoccur? If yes,how would we dealwith that?Whatwould it mean?

6 Conclusion

This paperhasprovideda completereview of thesubmissionsto theOMG’s Requestfor Proposals(RFP) for MOF 2.0 Query, Views, and Transformations(QVT ) withrespectto the requirementsstatedin the RFPandthe requirementsof the authorsofthis paperwho anticipatebeingusersof the languagethatwill bedefinedin thefinalQVT standard.

We have introduceda terminologyto clarify the major conceptsoccurringin theQVT spacebasedon the usagein the submissionsbut editedfor consistency. A setof commontransformationscenariosis described,which specifyfeaturesthatthefinalQVT standardmustsupportin orderto enablethe implementationof transformationsof valueto theauthors.Thesubmissionsareclassifiedalongvariousbenchmarksandcriteria that we consideredto be of particularimportancesuchasthe expressivity ofthe query language,the scalability of transformations,the simplicity of transforma-tion definitions,andtheability to flexibly executetransformations.We have alsodis-cussednon-functionalissues,in particularthe usability of the proposedlanguage.Ifthe QVT standardis to be widely implemented,the adoptedtransformationlanguagemustbeusableby thetargetaudience.

Our current work focuseson the developmentof an architectureto implementQVT -basedtransformationsbasedon theexperiencegainedwhile conductingthe re-viewing work describedin this paper. We also further evaluatethe applicability ofF-logic to the transformationswe are interestedin, becauseit is at the heartof theproposalsupportedby IBM.

Theauthorshopethatthispaperwill actasausefuloverview of thesubmittedpro-posalsandasatransformationimplementers’view ontherequirementsfor asuccessfulMOF 2.0Query, Views,andTransformationsstandard.

References

[1] J.Amsden,T. Gardner, C. Griffin, S. Iyengar, andJ.Knapman.UML profile forautomatedbusinessprocesseswith a mappingto BPEL 1.0. IBM Alphaworkshttp://dwdemos.alphaworks.ibm.com/ wstk/ common/wstkdoc/services/demos/uml2bpel/docs/UMLProfileForBusinessProcesses1.0.pdf,2003.

20

[2] A. Bosworth. Dataroutingratherthandatabases:Themeaningof thenext waveof the web revolution to datamanagement.In Proceedingsof the 28th VLDBConference, http://www.cs.ust.hk/vldb2002/VLDB2002-proceedings/,2002.

[3] F. Curberaet al. Businessprocessexecutionlanguagefor web services.www-106.ibm.com/developerworks/webservices/library/ws-bpel/,2002.

[4] FOLDOC. FOLDOC free on-line dictionary of computing.http://wombat.doc.ic.ac.uk/foldoc/.

[5] The Object Managemant Group. MDA specifications.http://www.omg.org/mda/specs.htm.

[6] The Object Managemant Group. OMG model driven architecture.http://www.omg.org/mda.

[7] The Object ManagemantGroup. OMG MOF 2.0 query, views, transforma-tionsrequestfor proposals.http://www.omg.org/techprocess/meetings/schedule/MOF 2.0 QueryView Transf.RFP.html.

[8] S.KentandR. Smith. Thebidirectionalmappingproblem.ENTCS, 82(7),2003.

[9] M. Kifer, G. Lausen,and J. Wu. Logical foundationsof object-orientedandframe-basedlanguages.Journalof theACM, 42(4):741–843,1995.

[10] J.Koehler, R. Hauser, S.Kapoor, F. Wu, andS.Kumaran.A model-driventrans-formationmethod. In Proceedingsof the7th InternationalIEEE ConferenceonEnterpriseDistributedObjectComputing(EDOC). IEEEPress,2003.

[11] I. Wikie et al. ASL languagelevel 2.5. Technicalreport,KennedyCarter, 2003.

OMG, UML andUnified ModelingLanguageareregisteredtrademarksor trademarksof ObjectManagementGroup,Inc. in theUnitedStatesand/orothercountries.

21