OnMarryingModel-DrivenEngineeringandProcessMining:ACaseStudyinExecution-based ModelProfiling AlexandraMazakandManuelWimmer BusinessInformaticsGroup(BIG),InstituteofSoftwareTechnologyandInteractiveSystems, TUWien,Favoritenstrasse9-11,1040Vienna,Austria{mazak,wimmer}@big.tuwien.ac.athttp://www.big.tuwien.ac.at Abstract.Inmodel-drivenengineering(MDE),modelsaremostlyusedinprescriptivewaysforsystemengineering.Whileprescriptivemodelsareindeedanimportantingredienttorealizeasystem,forlaterphasesinthesystems’lifecyclesadditionalmodeltypesarebeneficialtouse.Unfortunately,currentMDEapproachesmostlyneglecttheinformationupstreamintermsofdescriptivemodelsfromoperationstodesign,whichwouldbehighlyneededtoimprovesystemscontinuously.Totacklethislimitation,weproposeexecution-basedmodelprofilingasacontinuousprocesstoimproveprescriptivemodelsatdesign-timethroughruntimeinformationbyincorporatingknowledgeinformofprofiledmetadatafromeventlogsgeneratedduringtheexecutionofacodemodel.Forthispurposebinetechniquesofprocessmining(PM)withruntimemodelsofMDE.Inthecourseofacasestudy,weimplementapreliminaryprototypeofourframeworkbasedonatrafficlightsystemexamplewhichshowsthefeasibilityandbenefitsofourexecution-basedmodelprofilingapproach. 1Introduction Inmodel-drivenengineering(MDE),modelsareputinthecenterandusedthroughoutthesoftwaredevelopmentprocess,finallyleadingtoanautomatedgenerationofthesoftwaresystems[13].Inthecurrentstate-of-practiceinMDE[2],modelsareusedasanabstractionandgeneralizationofasystemtobedeveloped.Bydefinitionamodelneverdescribesrealityinitsentirety,ratheritdescribesascopeofrealityforacertainpurposeinagivencontext.Thus,modelsareusedasprescriptivemodelsforcreatingasoftwaresystem[18].Suchmodels@design.timedeterminethescopeanddetailsofadomainofinteresttobestudied.Thereby,differentaspectsofthedomainorofitssolutioncanbetakenintoount.Forthispurposedifferenttypesofmodelinglanguages(e.g.,statecharts,classdiagrams,etc.)maybeused.Ithastobeemphasizedthatengineerstypicallyhavethedesirablebehaviorinmindwhencreatingasystem,sincetheyarenotawareintheseearlyphasesofthemanydeviationsthatmaytakeplaceatruntime[3]. ordingtoBrambillaetal.[2]theimplementationphasedealswiththemappingofprescriptivemodelstosomeexecutablesystemsandconsistsofthreelevels:(i)the 78 modelinglevelwherethemodelsaredefined,(ii)therealizationlevelwherethesolutionsareimplementedthroughartifactsthatareusedintherunningsystem,and(iii)theautomationlevelwheremappingsfromthemodelingtotherealizationphasearemade.Thus,theflowisfrommodelsdowntotherunningrealizationthroughmodeltransformations. Whileprescriptiveordesignmodelsareindeedaveryimportantingredienttorealizeasystem,forlaterphasesinthesystem’slifecycleadditionalmodeltypesareneeded.Therefore,descriptivemodelsmaybeemployedtobetterunderstandhowthesystemisactuallyrealizedandhowitisoperatinginacertainenvironment.Comparedtoprescriptivemodels,theseothermentionedtypesofmodelsareonlymarginalexploredinthefieldofMDE,andifusedatall,theyarebuiltmanually.Unfortunately,MDEapproacheshavemostlyneglectedthepossibilitytodescribeanexistingandoperatingsystemwhichmayactasfeedbackfordesignmodels.Astheoreticallyoutlinedin[12],weproposemodelprofilingasacontinuousprocess(i)toimprovethequalityofdesignmodelsthroughruntimeinformationbyincorporatingknowledgeinformofprofiledmetadatafromthesystem’soperation,(ii)todealwiththeevolutionofthesemodels,and(iii)tobetteranticipatetheunforeseen.However,ouraimisnotto“re-inventthewheel”whenwetrytoclosetheloopbetweendownstreaminformationderivedfromprescriptivemodelsandupstreaminformationintermsofdescriptivemodels.Thereexistalreadypromisingtechniquestofocusonruntimephenomena,especiallyintheresearchfieldofProcessMining(PM)[3].Thus,ourmodelprofilingapproachinitsfirstversionfollowsthemainideabiningMDEandPM.Thecontributionofthispaperistopresentaunifyingarchitectureforbinedbutloosely-coupledusageofMDEapproachesandPMtechniques. Theremainderofthispaperisstructuredasfollows.Inthenextsection,wepresentaunifiedconceptualarchitecturebiningMDEwithPMframeworks.InSection3,wepresentacasestudyinexecution-basedmodelprofilingbasedonatrafficlightsystemexample.InSection4,wepresentrecentworkrelatedtoourapproachanddiscussitsdifferences.Finally,weconcludethispaperbyanoutlookonournextstepsinSection5. 2MarryingModel-DrivenEngineeringandProcessMining Inthissection,webrieflydescribethemainbuildingblocksofboth,MDEaswellasPM,necessaryforthecontextofthispaper,beforewepresentaunifyingarchitectureforbinedbutloosely-coupledusage. 2.1Prerequisites Model-drivenEngineering(MDE).IneachphaseofanMDE-baseddevelopmentprocess“models”(e.g.,analysismodels,designmodels)are(semi-)automaticallygeneratedbymodel-to-modeltransformations(M2M)thattakeasinputthosemodelsthatwereobtainedinoneofthepreviousphases.Inthelaststepofthisprocessthefinalcodeisgeneratedusingmodel-to-texttransformation(M2T)fromthedesignmodel[2].Thesetransformationengineeringaspectsarebasedonthemetamodelsofamodeling 79 language,whichprovidetheabstractsyntaxofthatlanguage.Thissyntaxguaranteesthatmodelsfollowaclearlydefinedstructure,anditformsthebasisforapplyingoperationsonmodels(e.g.,storing,querying,transforming,checking,etc.). Asdescribedin[2],thesemanticsofamodelinglanguagecanbeformalizedby(i)givingdenotationalsemanticsbydefiningamappingfromthemodelinglanguagetoaformallanguage,(ii)givingoperationalsemanticsbydefiningamodelsimulator(i.e.,forimplementingamodelexecutionengine),or(iii)givingtranslationalsemanticsbydefining,e.g.,acodegeneratorforproducingexecutablecode.Inordertogeneratearunningsystemfrommodels,theymustbeexecutable.Thismeans,amodelisexecutablewhenitsoperationalsemanticsisfullyspecified[2].However,executabilitydependsmoreontheusedexecutionenginethanonthemodelitself.ThemaingoalofMDEistogetrunningsystemsoutofmodels. Inourapproach,weconsiderexecutablemodelinglanguageswhichexplicitlystate“what”theruntimestateofamodelis,aswellasallpossibleeventsthatcanurduringexecution[1].Theseexecutablemodelinglanguagesnotonlyprovideoperationalsemanticsforinterpreters,butalsotranslationalsemanticsinformofcodegeneratorstoproducecodeforaconcreteplatformtorealizethesystem. ProcessMining(PM).binestechniquesfromdataminingandmodel-drivenBusinessProcessManagement(BPM)[3].InPM,businessprocessesareanalyzedonthebasisofeventlogs.Eventsaredefinedasprocessstepsandeventlogsassequentialorderedeventsrecordedbyaninformationsystem[15].ThismeansthatPMworksonthebasisofeventdatainsteadofdesignedmodelsandthemainchallengeistocapturebehavioralaspects.Thereby,specializedalgorithms(e.g.,theα-algorithm)producea,whichcanbeeasilyconvertedintoadescriptivemodelinformofaprocessmodel.Toputitinanutshell,thereisaconcrete,runningsystemwhichisproducinglogsandtherearealgorithmsusedputederivedinformationfromthoselogs. GenerallyinPM,eventlogsareanalyzedfromaprocess-orientedperspectiveusingGPLs(e.g.,UML,s)[4].TherearethreemaintechniquesinPM:(i)thewell-establisheddiscoverytechniquebywhichaprocessmodelcanbeautomaticallyextractedfromlogdata[3],(ii)theconformancecheckingtechnique,whichisusedtoconnectanexistingprocessmodelwithaneventlogcontainingdatarelatedtoactivities(e.g.,businessactivities)ofthisprocess[11],and(iii)theenhancementtechniquewhichisusedtochangeorextendaprocessmodelbymodifyingit(i.e.,repair),orbyaddinganewperspectivetothismodel(i.e.,extension)[3].Inrecentwork,vanderAalstalreadybringstogetherPMwiththedomainofsoftwareengineering.Forinstancein[10],theauthorspresentanovelreverseengineeringtechniquetoobtainreal-lifeeventlogsfromdistributedsoftwaresystems.Thereby,PMtechniquesareappliedtoobtainpreciseandformalmodelsandtomonitorandimproveprocessesbyperformanceanalysisandconformancechecking. 2.2UnifyingConceptualArchitecture Inthissection,bineMDEwithPMbypresentingaunifyingconceptualarchitecture.Thealignmentofthesetwodifferentresearchfieldsmayhelpus,e.g.,toverify 80 MetamodelingLevel ModelingLevel PrescriptivePerspectiveDescriptivePerspective DesignLanguage «refersTo» ObservationLanguage «conformsTo» DesignModel «conformsTo» OOObbsbesserevrravvataiottiiononnMMMoododedelesll AutomationLevel CodeGenerator RealizationLevel CodeExecutionPlatform ProcessMiningTools RuntimeVerificationTools SimulationTools MonitoringTools AnimationTools
5 Fig.1.UnifyingconceptualarchitectureforMDEandPM. ifthemappingfeatureofdesignmodelsisreallyfulfilled,orifimportantinformationgeneratedatruntimeisactuallymissinginthedesignmodel. Fig.1presentsanoverviewofthisarchitecture.Ontheleft-handsidethereistheprescriptiveperspective,whereweusemodelsforcreatingasystem,whereasontheright-handsidethereisthedescriptiveperspectivewheremodelsareextractedfromrunningsystems.Inthefollowing,wedescribeFig.1fromlefttoright.Thestartingpointisthedesignlanguagespecificationatthemetamodelinglevelwhichdefinesthesyntaxaswellasthesemanticsofthelanguage.Thedesignmodelatthemodelingleveldescribesacertainsystemandconformstothedesignlanguage.Inourapproach,thisdesignmodeldescribestwodifferentaspectsoftheproblemorthesolution:(i)thestaticaspect,whichisusedtodescribethemainingredientsofthemodeledentityandtheirrelationships,and(ii)thedynamicaspect,whichdescribesthebehavioroftheseingredientsintermsofeventsandinteractionsthatmayurbetweenthem[2].Fortheverticaltransitionfromthemodelleveltotherealizationlevel(i.e.,theprocessoftransformingmodelsintosourcecode),weusecodegenerationattheautomationlevel.Finally,attherealizationleveltherunningsoftwarereliesonaspecificplatformforitsexecution. Attheright-handsideofFig.1(atright),wepresentaloggingmetamodel—theso-calledobservationlanguage.Thismetamodeldefinesthesyntaxandsemanticsofthe(event)logswewanttoobservefromtherunningsystem.Inparticular,wederivethismetamodelfromtheoperationalsemanticsofthedesignlanguage.Thismeansthatthisobservationmetamodelcanbederivedfromanymodelinglanguagethatcanbeequippedwithoperationalsemantics.Fig.1indicatesthistransformationatthemetamodellevel.Theobservationmodel,whichconformstotheobservationlanguage,thumbsthelogsatruntimeandprovidestheselogsasinputforanykindoftoolsusedforcheckingpurposesofnon-functionalproperties(e.g.performance,correctness,ap- 81 propriateness,etc.).Thismeansthatwecantransformalanguage-specificobservationmodeltoaworkflowfileandimportit,e.g.,inaPMtoolaspresentedinourcasestudy. 3CaseStudy:Execution-basedModelProfiling Inthissection,weperformanempiricalexplanatorycasestudybasedontheguidelinesintroducedin[14].ThemaingoalistoevaluateifcurrentapproachesforMDEandPMmaybinedinaloosely-coupledway,i.e.,bothcanstayastheyareinitiallydeveloped,butprovideinterfacestoeachothertoexchangethenecessaryinformationtoperformautomatedtasks.Inparticular,wereportonourresultsconcerningafullymodel-drivenengineeredtrafficlightsystemwhichisenhancedwithexecution-basedmodelprofilingcapabilities.Allartifactsofthecasestudycanbefoundonourprojectwebsite.1 3.1ResearchquestionsAsmentionedabove,weperformedthisstudytoevaluatethefeasibilityandbenefitsbiningMDEandPMapproaches.Morespecifically,weaimedtoanswerthefollowingresearchquestions(RQ):
1.RQ1—Transformability:Istheoperationalsemanticsofthemodelinglanguagerich enoughtoautomaticallyderiveobservationmetamodels?

2.RQ2—Interoperability:AretheobservationmetamodelsamenableforPMtoolsby reusingexistingprocessminingformats?

3.RQ3—Usefulness:Arethegeneratedmodelprofilesresultingfromtheobservation modelsufficientenoughforruntimeverification?
3.2CaseStudyDesignRequirements.Asanappropriateinputtothiscasestudy,werequireasystemwhichisgeneratedbyanMDEapproachequippedwithanexecutablemodelinglanguage,i.e.,itssyntaxandoperationalsemanticsareclearlydefinedandessible.Furthermore,theapproachhastoprovidetranslationalsemanticsbasedonacodegeneratorwhichmaybeextendedbyadditionalconcernssuchaslogging.Finally,theexecutionplatformhostingthegeneratedcodemustprovidesomemeanstodealwithexecutionlogs. Setup.Tofulfillthestatedrequirements,weselectedanexistingMDEprojectconcerningtheautomationcontrollerofatrafficlightsystem.Thissystemconsistsofponents,e.g.,lights(green,yellow,red)forcarsandpedestrians,aswellasacontrollerofthesystem.WemodelledthisexamplebyusingaUML-baseddesignlanguagenamedClass/StateCharts(CSC)resultinginaclassdiagramandatimedstatemachineasprescriptivemodels(cf.Fig.2).Whilethestatemachineshowsallpossibleandvalidtransitions/stateswithinthisexample,theclassTrafficLightControllerspecifiestheblinkcounter(bc)andthedifferentlightswhichcanbeonoroff.ThemodelsofthisexamplehavebeendevelopedbyusingtheEmbeddedEngineer.2Weusethe1/?
page_id=7222 82 UMLclassdiagram TrafficLightController bc:int=0carG:{on,off}carR:{on,off}carY:{on,off}pedG:{on,off}pedR:{on,off} UMLstatemachinediagram SafetyStatecarG=offcarY=offcarR=onpedG=offpedR=on 3sec Car‐>greencarR=offcarG=on 5sec Car‐>yellowcarG=offcarY=on 1sec Ped‐>redpedR=on 2sec Car‐>red carY=offcarR=on 1sec[bc<=5]/bc++ 1sec[bc>5]/bc=
0 Ped‐>blinkentry/pedG=onexit/pedG=off 5sec 1sec Ped‐>green pedR=offpedG=on Fig.2.UMLclassdiagramandstatemachineofthetrafficlightsystem. EmbeddedEngineeralsotoproducePythoncodefromthetrafficlightmodel.Thecodecanbeexecutedonaputer.WeuseasspecificexecutionplatformaRaspberryPi(seeFig.3,atthebottomleft).IthastobenotedthatweaimedforfullcodegenerationbyexploitingamodellibrarywhichallowstodirectlydelegatetotheGPIOmodule(i.e.,input/outputmodule)oftheRaspberryPi. 3.3Results Inthissubsection,wepresenttheresultsofapplyingtheapproachpresentedinSection2.2forthegivencasestudysetup.First,weshowthegeneralarchitecturetorealizeexecution-basedmodelprofilingforthetrafficlightsystemexample.Subsequently,severaldetailsoftherealizationarepresentedbyfocussingontheobservationmetamodelaswellastheusageofanestablishedPMtool. TechnicalRealizationataGlance.Ourprototypicalrealizationofexecution-basedmodelprofilingconsiderstheexecutionlogsofarunningcodemodelastheexperimentalframe.Fig.3givesanoverviewofitsimplementation.WeextendthecodegeneratortoproducePythoncodewhichenablestoreportlogstoalogrecordingserviceimplementedasMicroServiceprovidedbyanobservationmodelrepository.Fordataexchangebetweentherunningsystemandthelogrecordingservice,weuseJSON,whichmeansthattheJSONdatatransferredtotheMicroServiceisparsedintologentryelementsintherepository.WeuseNeo4EMF3tostoretheexecutionlogsinaNoSQLdatabaseforfurtheranalysis.InordertobeabletouseestablishedPMtools,wegenerateXMLfilesfromtherecordedlogs(i.e.,theobservationmodel).Forfirstevaluationpurposes,weimportthisfilesinPromLite.4TheuseofthisPMtoolenablesustogeneratedifferent(PN)modelsfromtherecordedlogs.Inmoredetail,weuseATL[20]astransformationtooltotransformanobservationmodeltoaworkflowinstancemodelandimportitinProMtorunthePNdiscoverer. TheObservationMetamodel.ordingtoPMtechniques,weconsideranobservationmodelasaneventlogwithastartandendtimeregisteredasasequencesoftransactionsthathavingalreadytakenplace.However,wedonotreceiveeventlogs 34/doku.php?
id=promlite 83 CSCModel
(1)AlignmentPPPeeettrtririiNNNeeettt
(2)Augmentation CSC2Python WWWFFFObservation2WF PythonCode GPIO RaspberryPi JSON MicroService ObservationModel ObservationModelRepository Fig.3.Deployedtrafficlightsystemexample. fromanexecutedprocessmodel(i.e.,theactivitiesofabusinessprocessinanorderedmanner),ratherwereceivethetracesfromtransformedlogmessagesofanexecutedcodemodel. Fig.4showstheobservationmetamodelderivedfromtheoperationalsemanticsoftheexcerptofUMLwhichisconsideredinthecontextofthiscasestudy.Itillustratesthatchangesatruntime(rt)arebasicallyvalueupdatesforattributesoftheUMLclassdiagramaswellasupdatesconcerningthecurrentactivestateoftheUMLstatemachine(cf.Fig.4,theseelementsaremarkedwiththertstereotype).TheclassLogrepresentsaloggingsessionofacertainrunningsoftwaresystemwitharegisteredobservationStartandanobservationEnd.TheclassLogconsistsoflogentrieswithauniqueidandatimeStampfororderingpurpose(i.e.,showingwhentheentrywasrecorded).TheLogEntryeitherregistersaAttValueChangeoraCurStateChange.IncaseofaCurStateChangetheLogEntryconsidersthepredecessor(pre)andessor()states.IfanattributehaschangedtheLogEntryincludestheadditionalinformationaboutthepreValueandpostValue. GeneratedModelProfiles.Forgeneratingdifferentmodelprofilesfromtheobservationmodel,weemployexistingPMtools.Forthispurpose,wehavereverseengineeredtheXMLSchemaoftheworkflowloglanguage5intoametamodel,whichallowstotranslateourlanguage-specificobservationmodelintoworkflowinstancesbydefiningdifferentmodeltransformationsbasedontheinformationwhichshouldbediscovered.Forourcasestudy,wehavefirstimplementedamodeltransformationinATLwhichconsidersthestateurrencesofsystemruns,i.e.,itisaviewontheobservationmodeljustconsideringtheCurStateChangeelements.Bythis,wecancheckifthestatemachineisrealizedasintendedbythecodegeneratorandifitexecutesontherealizationlevelasspecified.Inparticular,theirequivalencecanbechecksemanticallyparingthestatespaceofthestatemachinewiththestatespaceoftheobservedoralsosyntacticallybydefiningbi-directionaltransformationruleswhichcanbeusedtochecktheconsistencyoftwoheterogeneousmodels[23].Second,wehave 5/WorkflowLog.xsd 84 CSC(Design+OS) Class 0…* Attribute changedAttname:String1…1«rt»value:String StateMachine 1…10…* State pre «rt»current0…11…
1 CSC(Observation) Log observationStart:StringobservationEnd:String 0…* LogEntry id:StringtimeStamp:String AttValueChange preValue:StringpostValue:String CurStateChange Fig.4.ObservationlanguageforUMLclassdiagram(CD)andstatemachine(SM). developedanotherATLtransformationwhichextractsforeachattributeaworkflowinstancewhichcontainsthesequenceofAttValueChanges.Bythis,wecanextracttheshapeofthevaluesstoredintheattributeandenrichthemodelwiththiskindofinformation,orcheckifcertainvalueconstraintsarefulfilledduringexecution.Forinstance,fortheblinkcounter(bc)attributewehavederivedaPNwhichexplicitlyshowsaloopcountingfromzerotosix.Allthegeneratedartefactscanbefoundonourprojectwebsite. 3.4InterpretationofResults AnsweringRQ1.Theoperationalsemanticscouldbetransferredintoanobservationalviewpoint.Bygeneratingachangeclassforeveryelementinthedesignmetamodelwhichisannotatedwiththertstereotype,weareabletoprovidealanguagetorepresentobservationsofthesystemexecution.Thislanguagecanbealsoemployedtoinstrumentthecodegeneratorinordertoproducethenecessaryloggingstatementsaswellastoparsethelogsintoobservationmodelelements. AnsweringRQ2.Bydevelopingtransformationsfromthelanguage-specificobservationmetamodelstothegeneralworkflow-orientedformatsofexistingPMtools,wecouldreuseexistingPManalysismethodsforMDEapproachesinaflexiblemanner.Notonlythestate/transitionsystemresultingfromthestatemachinecanbecheckedbetweenimplementationanddesign,butalsootherminingtaskscouldbeachievedsuchputingvalueshapesforthegivenattributesoftheclassdiagram.Thus,weconcludethatitispossibletoreuseexistingformatsfortranslatingtheobservations,however,differenttransformationsmaybepreferredbasedonthegivenscenario. 85 AnsweringRQ3.Forruntimeverification,wetookasinputtransformedeventlogs(i.e.,selectedstatechangesasaworkflowfile)andemployedtheα++-algorithmofPromLite1.1toderiveaPN.ThisgeneratedPNexactlycorrespondstothestatemachine,asshowninFig.2ontherighthandside.Wearethereforeconvincedthatthestatemachineisrealizedasintendedbythecodegenerator.Similarly,wehavedonethisforvariablechanges.Asoutputweextractedavalueshape[0..6]storedintheattributeblinkcounter.Bydoingsowedemonstrated,thatwearealsoabletoenrichtheinitialclassdiagramwithruntimeinformationintermsofprofiledmetadata.Finally,wemanuallyimplementedrandomerror-handlingstatesinthePythoncodemodel(notinthedesignmodel)toshowthattheseerrorsareone-to-onereflectedinthegeneratedPN.Byapplyingbi-directionaltransformations,theseadditionalstatesmaybealsopropagatedtothestatemachinemodelinorderpletethespecificationforerror-handlingstateswhichareoftenneglectedindesignmodels[5]. 3.5ThreatstoValidity Tocriticallyreflectourresults,wediscussseveralthreatstovalidityofourstudy.First,inthecurrentrealizationofourapproachwedonotconsidertheinstrumentationoverheadwhichmayincreasetheexecutiontimeoftheinstrumentedapplication.Ofcourse,thismaybecriticalfortimedsystemsandhastobevalidatedfurtherinthefuture.Second,thecurrentsystemisrunningasasinglethreadwhichmeanswearenotdealingwithconcurrency.Extensionsforsupportingconcurrencymayresultintransformingthestrictsequencesinpartiallyorderedones.Third,weassumetohaveaplatformwhichworkesstosendthelogstothemicroservice.Thisrequirementmaybecriticalinrestrictedenvironmentsandmeasurementsworktraffichavetobedone.Finally,concerningthegeneralizabilityoftheresults,wehavetoemphasizethatwecurrentlyonlyinvestigatedonemodelinglanguageandoneexecutionplatform.Therefore,moreexperimentsareneededtoverifyiftheresultscanbereproducedforavarietyofmodelinglanguagesandexecutionplatforms. 4RelatedWork WeconsidermodelprofilingasaverypromisingfieldinMDEandasthenaturalcontinuationandunificationofdifferentalreadyexistingoremergingtechniques,e.g.,dataprofiling[7],processmining[3],plexeventprocessing[6],specificationmining[5],finitestateautomatalearning[8],aswellasknowledgediscoveryanddatamining[9].Allthesetechniquesaimatbetterunderstandingtheconcretedataandeventsusedinorbyasystemandbyfocusingonparticularaspectsofit.Forinstance,dataprofilingandminingconsidertheinformationstoredindatabases,whileprocessmining,FSAlearningandspecificationminingfocusonchronologicallyorderedevents.Nottoetmodels@run.time,whereruntimeinformationispropagatedbacktoengineering.Thereareseveralapproachesforruntimemonitoring.Blairetal.[22]showtheimportanceofsupportingruntimeadaptationstoextendtheuseofMDE.Theauthorsproposemodelsthatprovideabstractionsofsystemsduringruntime.Hartmannetal.[21]goonestepfurther.Thebinetheideasofruntimemodelswith 86 reactiveprogrammingandpeer-to-peerdistribution.Theydefineruntimemodelsasastreamofmodelchunks,likeitmoninreactiveprogramming. Currently,thereisemergingresearchworkfocusingonruntimephenomena,runtimemonitoringaswellasdiscussingthedifferencesbetweendescriptiveandprescriptivemodels.Forinstance,Dasetal.[16]binetheuseofMDE,run-timemonitoring,andanimationforthedevelopmentandanalysisponentsinreal-timeembeddedsystems.Theauthorsenvisionaunifiedinfrastructuretoaddressspecificchallengesofreal-timeembeddedsystems’designanddevelopment.Thereby,theyfocusonintegrateddebugging,monitoring,verification,andcontinuousdevelopmentactivities.Theirapproachishighlycustomizablethroughacontextconfigurationmodelforsupportingthesedifferenttasks.SzvetitsandZdun[17]discussthequestionifinformationprovidedbymodelscanalsoimprovetheanalysiscapabilitiesofhumanusers.Inthiscontext,theyconductacontrolledexperiment.Heldaletal.[18]reportlessonslearnedfromcollaborationswiththreepanies.Theauthorsconcludethatitisimportanttodistinguishbetweendescriptivemodels(usedfordocumentation)andprescriptivemodels(usedfordevelopment)tobetterunderstandtheadoptionofmodelinginindustry.Lastbutnotleast,Ku¨hne[19]highlightsthedifferencesbetweenexplanatoryandconstructivemodeling,whichgiverisetotwoalmostdisjointmodelinguniverses,eachofitbasedondifferent,mutuallypatibleassumptions,concepts,techniques,andtools. 5ConclusionandNextSteps Inthispaper,wepointedtothegapbetweendesigntimeandruntimeinthecurrentMDEapproaches.Westressedthattherearealreadywell-establishedtechniquesconsideringruntimeaspectsintheareaofPMandthatitisbeneficialbinetheseapproaches.Therefore,wepresentedaunifyingconceptualarchitectureforexecutionbasedmodelprofiling,wherebinedMDEandPM.WebuiltthisapproachupontraditionalactivitiesofMDEsuchasdesignmodeling,codegeneration,andexecutionanddemonstrateditforthetrafficlightsystemcasestudy.Whilethefirstresultsseempromising,therearestillseveralopenchallenges,whichwediscussedinthethreatstovaliditysubsectionofthecasestudy.Asnextstepswewillfocusonreproducingourcurrentresultswithothercasestudies,e.g.,byconsideringadomain-specificmodelinglanguageforanelevatorsystem[1]. Acknowledgment ThisworkhasbeensupportedbytheAustrianScienceFund(FWF):P28519-N31andbytheAustrianResearchPromotionAgency(FFG)withintheproject“InteGra4.0HorizontalandVerticalInterfaceIntegration4.0”. References
1.Meyers,
B.,Deshayes,
R.,Lucio,
L.,Syriani,
E.,Vangheluwe,
H.,Wimmer,
M.:ProMoBox:AFrameworkforGeneratingDomain-SpecificPropertyLanguages.In:SLE(2014) 87
2.Brambilla,
M.,Cabot,
J.,Wimmer,
M.:Model-DrivenSoftwareEngineeringinPractice.an&Claypool(2012) 3.vanderAalst,
W.M.P.:ProcessMining:Discovery,ConformanceandEnhancementofBusinessProcesses.Springer(2011) 4.vanderAalst,
W.M.P.:ProcessMining.Commun.ACM,vol.55,pp.76–83.(2012)
5.Dallmeier,
V.,Knopp,
N.,Mallon,Ch.,Fraser,
G.,Hack,
S.,Zeller,
A.:AutomaticallyGener- atingTestCasesforSpecificationMining.IEEETSE,vol.38,pp.243–257,(2012)
6.Luckham,
D.:ThePowerofEvents:AnIntroductiontoComplexEventProcessinginDis- tributedEnterpriseSystems.Addison-Wesley(2005)
7.Abedjan,
Z.,Golab,
L.,Naumann,
F.:Profilingrelationaldata:asurvey.VLDB,vol.24,pp. 557–584,(2015)
8.Giles,LeeC.,,Miller,
B.C.,Dong,
C.,Hsing-Hen,
C.,Guo-Zeng,
S.,Yee-Chun,
L.:Learn- ingandextractingfinitestateautomatawithsecond-orderrecurrentworks.NeuralComputation,vol.4,pp.393–405,(1992)
9.Fayyad,UsamaM.,Piatetsky-Shapiro,
G.,Smyth,
P.:FromDataMiningtoKnowledgeDiscovery:AnOverview.In:AdvancesinKnowledgeDiscoveryandDataMining,pp.1–34,(1996)10.vanderAalst,
W.M.P.,Leemans,
M.:Processmininginsoftwaresystems:Discoveringreallifebusinesstransactionsandprocessmodelsfromdistributedsystems.In:MoDELS(2014)11.Rozinat,
A.,anderAalst,
W.M.P.:Conformancecheckingofprocessesbasedonmonitoringrealbehavior.Inf.Syst.,vol.33,pp.64–95,(2007)12.Mazak,
A.,Wimmer,
M.:TowardsLiquidModels:AnEvolutionaryModelingApproach.In:CBI(2016)13.deLara,
J.,Guerra,
E.,Cuadrado,
J.S.:Model-drivenengineeringwithdomain-specificmetamodellinglanguages.SoSyM,vol.14,pp.429–459,(2015)14.Runeson,
P.,Ho¨st,
M.,Sjoberg,
D.:Guidelinesforconductingandreportingcasestudyresearchinsoftwareengineering.EmpiricalSoftwareEngineering,pp.131–164,(2009)15.Dumas,
M.,vanderAalst,
W.M.P.,terHofstede,
A.H.M.:Process-AwareInformationSystems:BridgingPeopleandSoftwareThroughProcessTechnology.Wiley(2005)16.Das,
N.,Ganesan,
S.,Bagherzadeh,
J.M.,Hili,
N.,Dingel,
J.:SupportingtheModel-DrivenDevelopmentofReal-timeEmbeddedSystemswithRun-TimeMonitoringandAnimationviaHighlyCustomizableCodeGeneration.In:MoDELS(2016)17.Szvetits,
M.,Zdun,
U.:ControlledExperimentontheComprehensionofRuntimePhenomenaUsingModelsCreatedatDesignTime.In:MoDELS(2016)18.Heldal,
R.,ione,
P.,Eliasson,
U.,Lantz,
J.,Derehag,
J.,Whittle,
J.:DescriptivevsPrescriptiveModelsinIndustry.In:MoDELS(2016)19.Ku¨hne,
T.:UnifyingExplanatoryandConstructiveModeling.In:MoDELS(2016)20.Jouault,
F.,Allilaire,
F.,Be´zivin,
J.,Kurtev,
I.:ATL:Amodeltransformationtool.Sci.Comput.Program.vol.72,pp.31–39,(2008)21.Hartmann,
T.,Moawad,
A.,Fouquet,
F.,Nain,
G.,Klein,
J.,LeTraon,
Y.:StreammyModels:ReactivePeer-to-PeerDistributedModels@run.time.In:MoDELS(2015)22.Blair,
G.,o,
N.,France,
R.B.:Models@run.time.IEEEComputer,vol.42,pp.22–27,(2009)23.Czarnecki,
K.,Foster,
J.N.,Hu,
Z.,La¨mmel,
R.,Schu¨rrA.,Terwilliger,
J.F.:BidirectionalTransformations:ACross-DisciplinePerspective.In:ICMT(2009) 88