engineering bx€¦ · – ecore (emf), mof, xmi, typed graphs, metadepth, … (dsls for...
TRANSCRIPT
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.