1

Engineering BX

Richard Paige Dept of Computer Science, University of York

2

Background in Model-Driven Engineering of BX

Richard Paige Dept of Computer Science, University of York

3 Overview •  Mylectureswillfocusonapproachesforengineeringbidirec5onaltransforma5ons.– Withsomeconsidera5onofengineeringtransforma5onsingeneral.

–  Emphasisonapproacheswithtools.•  Touchonpartsoftheengineeringlifecycle:

–  Requirements,architecture,design,implementa5on,verifica5on.

•  WithafocusonModel-DrivenEngineeringconcepts,languages,toolsandtechnologies.

4 Overview

•  Threelectures:1.  Introduc5ontobackgroundonMDEforBX:

founda5onsandconcepts;languagesandtools(stateoftheart);openchallenges.

2.  RequirementsengineeringforBX:concepts,processes,MDElanguagesforREforBX.

3.  Architecture,designandaliOlebitofverifica5onforBX:languages,paOerns,tools.

5 Context

•  Ibuildtoolsformodelmanagement.– E.g.,modeltransforma5on,valida5on,merging,migra5on.

•  AnddoappliedresearchinMDE.– Fourcurrentprojectsonappliedmodelmanagement:scalability;“BX”forassurance;technicalobsolescence;incrementalqueryingfordataanaly5cs.

6 Context

4.1 Epsilon

Epsilon [7] is a mature family of interoperable languages for model management.Languages in Epsilon can be used to manage models of diverse metamodels andtechnologies (detailed below). The core of Epsilon is the Epsilon Object Lan-guage (EOL) [6], an OCL-based imperative language that provides additionalfeatures including model modification, multiple model access, conventional pro-gramming constructs (variables, loops, branches etc.), user interaction, profiling,and support for transactions. EOL can and has been used as a general-purposemodel management language (e.g. for operational model transformation). It isprimarily intended to be reused in task-specific model management languages. Anumber of task-specific languages have been implemented atop EOL, including:model transformation (ETL), model comparison (ECL), model merging (EML),model validation (EVL), model refactoring (EWL) and model-to-text transfor-mation (EGL). These languages reuse EOL in di�erent ways, e.g. by acting as apreprocessor, or by using EOL to define behaviour of rules.

Epsilon is designed to be technology agnostic - that is, the same Epsilonprogram can be used to manage models from di�erent technologies: the conceptsand tasks of model management are independent of how models are representedand stored. To support this, Epsilon provides the Epsilon Model Connectivity(EMC) layer, which o�ers a uniform interface for interacting with models ofdi�erent modelling technologies. New technologies are supported by adding adriver to EMC. Currently, EMC drivers have been implemented to supportEMF [2] (XMI 2.x), MDR [8] (XMI 1.x), pure XML, and Z [9] specificationsin LaTeX using CZT [10] Also, to enable users to compose complex workflowsthat involve a number of individual model management tasks, Epsilon providesANT [11] tasks and an inter-task communication framework discussed in detailin [12].

The technical architecture of Epsilon is illustrated in Figure 3.

Epsilon Model Connectivity (EMC)

Epsilon Object Language (EOL)

Validation Language (EVL)

Transformation Language (ETL)

Code Generation Language (EGL)

EMF MDR

Model Migration Language (Flock)

XML SpreadsheetsMetaEdit+ Z

Comparison Language (ECL)

Merging Language (EML)

Refactoring Language (EWL)

Unit Testing (EUnit)

Fig. 3. Overview of the architecture of Epsilon

As mentioned earlier, EMC enables developers to implement drivers – es-sentially classes that implement the IModel interface of Figure 4 – to supportdiverse modelling technologies. The work in this section illustrates the designand implementation of an additional driver (on top of the existing drivers for

7 Today’s Lecture

•  Founda5onsofMDEforBX:– Terminology:model,metamodel,typesoftransforma5ons,traceability.

– Typicalapplica5onsofBXinMDE.

•  Stateoftheart:MDElanguages&toolsforBX(notjustBX!)

•  Challengesandopenques5ons.

8

Founda5onsofMDEforBX

9 Model •  Astructureddescrip5onofphenomenaofinterest.–  Capturessta5cordynamiccharacteris5cs.–  Processedbyautomatedtools.

•  Structurecanbedefinedinanumberofways:–  Schema(explicitorimplicit),typingrules,constraints,metamodel…

– ManyapproachestodefiningstructureinMDEarebasedongraphs(dis5nc5onfromgrammarware).

–  Thereareaccepteddefactostandards(Ecore)– Don’trestrictourselvesto‘just’Ecore.

10 Metamodel •  Ametamodelisaspecifica5onoftheabstractsyntaxand(partsofthe)sta5cseman5csofalanguage.

•  Therela5onshipbetweenmodelandmetamodeliscalledconformance.– Namely,amodelconformstoametamodel.

•  Technologiesformetamodelling:–  Ecore(EMF),MOF,XMI,typedgraphs,MetaDepth,…(DSLsformetamodelling)

– NB:metamodel!=grammar

11 Example: TED Conference Management

•  Developacustomisededitorfordomainexperts(conferencemanagers).

•  Letsdomainexpertsbuildconferencemodelsthattakeintoaccountimportantconference5metablingconcepts.

•  UseEMF/Ecore

12 Example: Metamodel •  Keydomainconcepts:

– Tracks,consis5ngofanumberofslotsinwhichtalkscanbescheduled.

– Talkshavepar5cipants(whomayhavetogiveseveraltalks,sowemustavoidclashes)

– Lunch•  Indefiningametamodelweiden5fyrecurringconcepts,includingnamingand5ming(abstractthese).

13 Example: Metamodel

14 Constraints

•  Metamodelscapturesomesta5cseman5crules(likemul5plicity).

•  Richerconstraintsmaybeneededtopreventundesirable/illegi5matemodelsfrombeingcreated.

•  Ifmul5plemodels/metamodelsarebeingused,inter-modelconstraintsmaybeusedtoestablishconsistency.–  e.g.,EVL,xlinkit,OCL(withaunionmetamodel)–  e.g.,QVT-Rcheckonlymode

15 Operations

•  Givenmetamodelsandconformingmodels,wemaywanttoapplyopera5onstothem.– Match/compare– Merge– Check(constraint,cri5que)– Generate(text,concretesyntax)– Migrate– Transform(update,source-to-target,bx,…)– ….

16 Comment

•  Ques5ononMonday:“Howdoweactuallydefinetherela5onsbetweenmodels?”

•  Oneway:opera5onsonmodels!– E.g.,comparison– E.g.,transforma5on– E.g.,constraintevalua5onacrossmodels

•  Canalsopopulaterela5onsbyexample.

17 Transformations

•  Unidirec3onal:fromasourcemodeltoatargetmodel.–  Definedintermsofmetamodels,usuallylanguagesare“linguis5callysimilar”.

•  Update-in-place:modifica5onsmadetoonesource/targetmodel;normallyunidirec5onal.

•  Bidirec3onal:sourceandtargetmodelsareestablishedtobeconsistentatwell-definedpointsin5me.–  e.g.,aierrepositorycheck-in;aiercheck-then-enforcehasruninQVT-R

–  Couldbedefinedaspartoflanguageseman5cs,orinexternalprocesses.

•  Model-to-text/grammar:outputisnolongeramodelbuteitherfree-formtextortextconformingtogrammar

18 Traceability •  Allopera5onsonmodelshaveside-effects:theygeneratetrace-links.

•  Trace-linksrelatemodelelements(notjustmodels).–  Differenttypesoftrace-links(e.g.,contains,regenerates,-seeAizenbud-Reshef’swork)

•  ManyMDEtools(Epsilon,ATL)generatesuchtrace-linksandallowthemtobepersisted.

•  Basisforvalida5onandverifica5onofopera5onsonmodels.–  Lossoftrace-linksisonereasonwhytoolbuildersmaybeworriedabout“history-ignorant”BX.

19 Trace Models

f2:Friend

nickname=Maryage=20

f1:Friend

nickname=Jonage=30

e1:Employee

name=Johnsalary=3K

e2:Employee

name=Marysalary=2K

Friendnickname:stringage:int

Employee

name:stringsalary:int

MetamodelM MetamodelN

[=][=][!=]

ModelB(byHR)ModelA(byFacebook)

ExamplefromZinovyDiskin

20 Delta lenses

•  A theory for trace models •  Algebraic structures comprising

– Basic operations over models and model deltas: delta composition, delta reversal, delta propagation, tile composition

– Basic laws these operations and their composition should satisfy

•  Product line: sync scenario ---> delta lens •  …are active research topics

21 Today’s Lecture

•  Foundations of MDE for BX: – Terminology: model, metamodel, types of

transformations, traceability. – Typical applications of BX in MDE.

•  State of the art: – BX scenarios in MDE – MDE languages & tools for BX (not just BX!)

•  Challenges and open questions.

22 MDE BX Scenarios

•  Round-tripengineering(modelstocodetomodels)–  E.g.,obsolescenceworkinMONDOproject

•  Suppor5ngmul5plestakeholdersedi5ngthesamemodels–  Collabora5vemodelling(cfMONDOproject)

•  Synchronisingdocumenta5onandcode–  E.g.,assurancecasesanddesignartefacts(whatifnotallchangescan

beback-propagated?)

•  Reflec5nganalysisresultsinmodels–  E.g.,MARTEmodel->UPPAAL/TRIO->MARTE–  Thisscenarioimplementedusinggeneratedtransforma5ons(more

later)andalsousingtraceability/merge.

23 Languages and Tools

•  NumerouslanguagesandtoolstosupportBX,buildingonMDEtechnologiesandconcepts.

•  The“bigbeast”:theOMG’sQuery,ViewsandTransforma5ons(QVT).– Standardisedearly.– Standardisedtooearly?– Standardisedatthewrong5me?

24 •  OMGstandardformodeltransforma5on•  RFPissuedbyOMGonMOFQuery/Views/Transforma5ons

•  SourceandtargetmodelsconformtoMOFmetamodels.– Transforma5onprogramisalsoamodel

Languages- QVT

25 •  Core

–  PaOernmatchingoveraflatsetofvariables–  Definedusing‘minimal’extensionstoEMOFandOCL–  Finegrained(onemappediden5typerrule)–  “Simple”transforma5onlanguage

•  Rela5ons–  ObjectpaOernmatchingandobjecttemplatecrea5on–  Coarsegrained(manymappediden55esperrule)–  Specifica5onofrela5onsovermodelelements

•  Opera5onal–  Proceduraldefini5onoftransforma5ons–  ExtendsRela5onslanguagewithimpera5veconstructs

QVT Overview

26 •  Core is a small extension of EMOF classes and OCL

expressions –  manipulates trace models explicitly

•  Relations adds –  extended pattern syntax –  implicit trace models

•  Both languages are meant to have a similar evaluation semantics –  multi-direction execution –  incremental update / change propagation semantics –  implicit object creation and deletion

•  Relations is mapped (reduced) to Core to provide its full semantics

Core vs Relations

27 Relations- Abstract Syntax

28 •  Relation

–  Transformation between candidate models is specified as a set of relations that must hold

transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) {..}

–  A relation declares constraints that must be satisfied by the elements of

candidate models

•  Domain •  When Pattern •  Where Pattern

Concrete Syntax

29 •  Dis5nguishedtypedvariablethatcanbematchedinamodel

•  AdomainhaspaOerns–  Setofvariablesandasetofconstraintsthatmodelelementsboundtothosevariablesmustsa5sfytoqualifyasavalidbindingofthepaOernrela3onPackageToSchema/*mapeachpackagetoaschema*{domainumlp:Package{name=pn}domainrdbmss:Schema{name=pn}

}

Concrete Syntax - Domain

30 •  When

–  specifiesthecondi5onsunderwhichtherela5onshipneedstohold(precondi5onsaccordingtoEclipseQVT)

•  Where–  specifiesthecondi5onthatmustbesa5sfiedbyallmodelelementspar5cipa5ngintherela5on(postcondi5onsaccordingtoEclipseQVT)

•  ThewhenandwhereclausesmaycontainanyarbitraryOCLexpressionsinaddi5ontotherela5onexpressions.

When & Where Clauses

31 Example

32 •  Meant to be a “normal form” for QVT transformations •  A QVT Core transformation consists of a number of

Mapping Rules. •  Each Mapping Rule consists of a collection of Patterns •  Patterns consist of variables and OCL expressions. •  A binding of a pattern is a unique set of values for all of

its variables, for which all the OCL expressions hold

QVT Core

33 QVT Core – Abstract Syntax

34 •  Domain

–  Has an associated model type of the transformation (model candidates) •  Area

–  Consists of two patterns •  Pattern

–  Set of variables, predicates and assignments –  Can be matched or enforced –  Can depend on each other

•  Guard Pattern –  Narrow the selection of model elements to be considered for the mapping –  Only used for defined a context

•  Bottom Pattern –  Defines the derivations –  Can have realized variables, assignments and black-box operation

•  Mapping –  One are for the trace and one for each model type –  Defines a relation between bottom patterns

QVT Core

35

c:Class

a:AOribute|a.class:=c;

c2t:ClassTable|c2t.table=t;c2t.class=c;

t:Table

a2c:AOrColumn|a2c.owner:=c2t;a2c.aOr:=a;

a2c.column:=c;

c:Column|c.table:=t;

* * *

1 1 1 1

1 1 1

Class to Table

Attribute to Column

UML Relational UML/Rel

Bottom pattern is evaluated using the variable values of the valid binding of the guard pattern.

Mapping Rule Example

36 Tools

•  Medini QVT – Claims to be a reasonably complete, but

currently unsupported, implementation of QVT-R.

– Claims to implement the QVT standard but diverges from semantics in a number of ways

•  (e.g., deletion of elements, no checkonly mode)

– Open source (EPL)

37 Tools

•  ModelMorf: – From TCS, claims to be an implementation of

QVT-R circa 2007. – Pre-Beta is available to researchers; a

proprietary version is available to commercial users (internal to TCS only).

– Perdita’s research shows it more faithfully implements the QVT standard than Medini, but it’s still not QVT.

38 Tools •  jQVT (QVT-like)

– A QVT-like engine that is defined on the Java type system instead of EMF (uses Xbase language instead of OCL)

– Generates native Java code from jQVT scripts. – Bidirectional

•  Echo: – Uses QVT-R for inter-model consistency and

model repair. – Alloy model finder used to generate models. – Bidirectional.

39 jQVT

40 Tools •  JTL:

– The Janus Transformation Language. – Bidirectional transformations: changes in one

model propagated to the other model. –  If a change makes the other model inconsistent,

an approximation (“closest match”) is computed. – Based on answer set programming: as such,

there can be several solutions to a transformation (results may need to be constrained).

41 Tools

•  EclipseQVT– QVT-Oiswelldefinedandac5ve(EclipseM2M)

– QVT-RandQVT-Core–workinprogress(EdWillink,York)

42 Tools •  XRound

–  Template-basedbidirec5onal(asymmetric)languageforXML-basedmodels.

•  XSugar–  BXbetweentwosyntaxesforthesamelanguage;bijec5ve.

•  Epsilon(EWL+EVL)event-drivenapproach–  Twoupdate-in-placetransforma5ons(onsource,target)executedwheninter-modelconsistencyrulesareviolated–laterthisweek.

43 Tools •  Bidirec5onalisa5onapproaches:

– ATL-Inversion:aHOTthatgeneratesanATLbackwardtransforma5ongivenaforwardone(prototype).

– Seman5cbidirec5onalisa5on,e.g.,Voigtlander(basedoncollec5ngextensionalbehaviour)–seePOPL’09paper.

– GRoundTram,basedonabidirec5onalinterpreta5onofagraphquerylanguage(seeICMT’11paper)

44 Hot Off the Press

•  Excellentfeaturemodel-basedclassifica5onofBXapproachesinJuly2016issueofSOSYM.

•  Mainpointsofvaria5on:technicalspace,correspondence,changes,execu5on.

45 Challenges •  MDEforBXdoespossesssomecleartheoryandpragma5ctools–  rathersiloed(TGG+deltalensworkisbestexample)–  toolsthatevidentlyimplementthetheory?–  allmanagetrace-linksinasystema5cway[deltalenses]

•  TheimportanceofmetamodellingforunderstandingBX(typingisimportant).– Doweyethaveagood“typetheory”forMDEandmetamodelling?(see,e.g.,workbySteelandJezequel,plusothers)

46 Challenges •  Howcantheoryfromothercommuni5esbeappliedinunderstanding,improvingandsimplifyingstandardlanguagesforBXinSE–  QVTiss5lltoocomplex(nowwe’reinaworldwherewemustdis5nguishEclipseQVTandOMGQVT)

•  Morescenariosforbidirec5onality:– Whendowereallyneedit?–  Inmyindustryprojects,Ihaveonlyhadonepreciserequirementfora“BX”(reflectanalysisresults).

–  BXrequirementssome5mesemerge(discussionwithAnthonyonMonday)

47 Challenges •  MDEprac55onerstendtouseopera5onaltransforma5onsalot–  andmodel-to-concrete-syntaxtransforma5ons–  andmodel-to-texttransforma5ons

•  HowdothesefitintotheBXspace?•  WeusemetamodelsbutPLcommunityseemstodofinewithgrammars.–  Lessonstobelearned?Valueadded?

•  Wehaveadiversesetofmodelinglanguagesthatneedtobesupported.

48 Challenges

•  Howdowecombine/unify:–  {Deltalens,…}theory– MDElanguagesthatsupportBX(QVT-R,OCL,Ecore)thatbothexistandareused.

– Supportfortraceability(trace-linksasasideeffectofrunningmodelmanagementopera5ons)

•  bothasapragma5ctoolandasatheore5calbasis.

49 Next time!

•  RequirementsengineeringforBX:– HowdowegatherrequirementsforaBX– Arestandardrequirementsengineeringprocessesapplicable?(preview:yes!)

– HowdowespecifyrequirementsforBX?•  transML.

– ChallengesforREforBX.