Towards debugging facilities for graphical modeling languages in web-based modeling tools
DIPLOMARBEIT
zur Erlangung des akademischen Grades
Diplom-Ingenieur
im Rahmen des Studiums
Business Informatics
eingereicht von
HansjörgEder,BSc Matrikelnummer 01426985
an der Fakultät für Informatik der Technischen Universität Wien
Betreuung: O.Univ.Prof.Dipl.-Ing. Mag. Dr.techn. Gertrude Kappel Mitwirkung: Dipl.-Ing. Dr.techn. Philip Langer
Wien, 10. Dezember 2020 Hansjörg Eder Gertrude Kappel
Technische UniversitätWien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.at
Towards debugging facilities for graphical modeling languages in web-based modeling tools
DIPLOMA THESIS
submitted in partial fulfillmentofthe requirements forthe degree of
Diplom-Ingenieur
in
Business Informatics
by
HansjörgEder,BSc Registration Number 01426985
to the Faculty of Informatics at the TU Wien
Advisor: O.Univ.Prof.Dipl.-Ing. Mag. Dr.techn. Gertrude Kappel Assistance: Dipl.-Ing. Dr.techn. Philip Langer
Vienna, 10th December,2020 Hansjörg Eder Gertrude Kappel
Technische UniversitätWien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.at
Erklärung zur Verfassungder Arbeit
Hansjörg Eder,BSc
Hiermit erkläre ich, dass ichdieseArbeit selbständig verfasst habe,dass ichdie verwen- detenQuellenund Hilfsmittel vollständig angegeben habeund dass ichdie Stellen der Arbeit–einschließlichTabellen,Karten undAbbildungen –, dieanderen Werken oder dem Internet im Wortlaut oder demSinn nach entnommensind, aufjeden Fall unter Angabeder Quelleals Entlehnung kenntlich gemacht habe.
Wien, 10. Dezember 2020 Hansjörg Eder
v
Acknowledgements
First of all, Iwouldliketothank my family, withoutwhose motivating and financial support thisstudy would not have been possible. Moreover, Iwouldliketothank my fellowstudentswith whom Iworked for hours on exercises and alsospent many fun evenings. Iwould also like to thank my friends, whohavebeenwith me for years. Although I hadlittle time foractivities,Icouldalwaysrely on theirsupport. Iwouldliketothank O.Univ.Prof. Dr. Gertrude Kappel and Dr.TanjaMayerhofer, who sparkedmyinterest in Model Engineeringduring my Master’sstudies. Iwouldespeciallyliketothank Dr. Philip Langer, without whose constantsupport and valuable feedback,this work would not have been possible. Thankyou forencouraging me to continuewith thisthesis.
vii
Kurzfassung
Die modellgetriebene SoftwareentwicklungbietetVorteile im Entwicklungsprozess, in- demsie die Abstraktionsebeneerhöht und damit die Komplexität einerbestimmten Domäne reduziert. Domänenspezifische Sprachen(DSSs) erhöhen dieProduktivität für Entwickler und verbessern die Kommunikation mitDomänenexperten. DSSs können in textuelle Sprachen (TS) undgrafische Sprachen (GS) unterteilt werden. Die für die Erzeugung vonDSSs erforderlichen Tools undEditoren sind in der Regel tief in eine spezifische Entwicklungsumgebung (IDE) integriert. DieseIDEsverwendenverschiedene Programmierschnittstellen,umdie gleichen Funktionen für verschiedeneSprachen zu implementieren, waszumehrerenImplementierungenfür eineIDE führt. Zu diesem Zweckwurdedas Language Server Protocol (LSP) fürTSund dasGraphicalLanguage ServerProtocol(GLSP) für GS eingeführt.Diese Protokolletrennen den Editorvon den Sprachkonzepten undermöglichen so dieWiederverwendung eines Sprachservers über mehrere IDEs. Die zunehmendeKomplexität in derSoftwareentwicklungführt zu einem erhöhten Auftreten vonFehlern in Programmenund Modellen und erfordert daherDebugging- Möglichkeiten sowohl für TS als auchfür GS. Daher wurde das Debug Adapter Protocol (DAP) eingeführt,umdie Kommunikation zwischender IDE undeinem konkreten Debugger zu standardisieren. Vergleichbar mit den Zielen desLSP und GLSP beabsichtigt das DAPeine generische grafische Benutzeroberfläche pro IDE zu verwenden und dieselben sprachspezifischen Debuggerübermehrere IDEs hinweg wiederzuverwenden. Diese Arbeit analysiertwie das DAPfür TS und das GLSPfür GS kombiniert werden können, um Modelldebuggingineiner webbasierten Umgebungzuunterstützen. Des Weiterenwird evaluiert,obdie bekannten Debugging-Konzeptezum Debuggen vonTS auf GS übertragen werdenkönnen. Diese Arbeit zielt vorallem darauf ab zu untersuchen, ob das DAPauf GS angewendet werdenkann. Darüber hinausbeabsichtigt dieseArbeit, bestehende Debugging-Komponentenund -Frameworks, die in Bezugauf TS entwickelt wurden, wiederzuverwenden. Die Ergebnisse dieser Arbeitwerden anhand vonzwei Anwendungsfällen ausgewertet.Der ersteFallzielt darauf ab zu untersuchen, ob das DAP für TS auf GS wiederverwendet werdenkann. Derzweite Anwendungsfall zielt darauf ab, die Wiederverwendbarkeit des entwickelten FrameworksimHinblickauf weitere GS und Domänenprobleme zu bewerten. Die Ergebnisseder Fallstudie zeigen, dass das DAPeine effiziente Multi-Editor-Integration ermöglicht.Darüber hinaus zeigen dieErgebnisse,dass dasentwickelte Debugging-Framework die Anforderungen einesmodernenDebuggers erfüllt und dieIntegration zusätzlicherDebuggerfür weitere Sprachen erleichtert.
ix
Abstract
Model-drivendevelopment(MDD) offersadvantages in the developmentprocessby raisingthe levelofabstraction and reducing thecomplexity of aspecific domain. Domain- Specific Languages (DSLs) used in MDDraise theproductivity for developers and improve communication with domain experts. DSLs can be divided into textual languages (TLs) and graphical languages (GLs).IDEs provide differentapplication programminginterfaces (APIs) fordeveloping tool support forvarious languages.Iftoolsupport for alanguage is required in multiple IDEs, the implementation of thesame language has to be repeated for eachIDE basedontheir differentAPIs.For thispurpose, the Language ServerProtocol (LSP) forTLs separates theeditor interface fromthe languagelogic and allowsthe reuse of one language serverimplementing thelanguage logicacrossseveral LSP-basedIDEs. Likethe LSP,the Graphical Language Server Protocol (GLSP)was invented to transfer the advantagesofextensibilityand reusability to GLs. Increasedcomplexity in software developmentleads to an increased number of errors in programs and models and,therefore, it requires debuggingfacilities for both TLsand GLs. Therefore, the Debug AdapterProtocol(DAP) wasinvented to standardize the communication between theIDE and aconcretedebugger. The DAPintends that an IDE offersone generic graphical user interface for debuggingfunctionalityand that there isone debuggerper language implementing thelanguage-specific debuglogic that can then be reused among IDEs. Thisthesis analyzesawayofcombining theDAP for TLs and theGLSP for GLs to supportmodel debugging inaweb-based environment. Furthermore, it is evaluated whether thewell-known debugging conceptsfor debugging source code can be transferred to GLs. Thethesis intendstoreuse existingdebugging components and frameworks developedfor TLs. The resultsofthis work are evaluated in two use cases.The first use case is the running example andaimsatinvestigatingwhether the DAPfor TLs can be reused forGLs. The second use caseintends to evaluate thereusabilityofthe developedframework concerning further GLs and domainproblems.The case study’s resultsindicatethat the DAPenablesefficientmulti-editorintegration of debuggers, i.e., one language-specific debugger can efficientlybeintegratedwith aDAP-baseddebugging interface and that aDAP-based debugging interface can efficientlyintegrate with multiple language-specific debuggers. Further, the results showthatthe developeddebugging framework meets therequirements of amoderndebuggerand facilitates the integration of debugging support forfurther GLs.
xi
Contents
Kurzfassung ix
Abstract xi
Contents xiii
1Introduction1 1.1 Motivation ...... 1 1.2 Problem Statement...... 2 1.3 Aim of theWork ...... 3 1.4 Methodology ...... 4 1.5 Structure of the Work ...... 4
2Background 7 2.1 Model-DrivenDevelopment ...... 7 2.2 Domain-Specific Languages ...... 12 2.3 Debugging in Domain-Specific Modeling ...... 19
3Web-based Modeling Tools25 3.1 Language Server Protocol ...... 25 3.2 Graphical Language Server Protocol ...... 29 3.3 DebugAdapterProtocol...... 34 3.4 Summary...... 38
4Applying the DAPtoGLSP 41 4.1 RunningExample:WorkflowModelingLanguage +Diagram Editor .. 41 4.2 Requirements forDebuggingthe WorkflowModelingLanguage ....47 4.3 WorkflowModelingLanguage Debugger ...... 56
5Architecture and Implementation 65 5.1 Technological Background ...... 65 5.2 Implementation Details ...... 69 5.3 Challenges ...... 76
xiii 6Evaluation 81 6.1 StateMachine Modeling Language ...... 81 6.2 Open Problems...... 94 6.3 Interpretation of theResults ...... 95
7Related Work 99 7.1 Debugging Domain-Specific Models ...... 99 7.2 Web-based DSML Environments ...... 103 7.3 Other Related Work ...... 103
8Summary and Conclusion 105 8.1 Summary...... 105 8.2 Comparison with Related Work ...... 106 8.3 Limitations and Future Work ...... 107
Bibliography 111
xiv CHAPTER 1
Introduction
1.1 Motivation
Theprogress of technology leads to theincreasingcomplexity of software components to ensurethe functionalityofmodern systems. Model-driven software development(MDSD) offers advantages in the developmentprocessbyraising the levelofabstractionand reducingthe complexityofaspecific domain. Modeling languages are an essential part of MDSD andlet users design the modelsfor theirsystems. Domain-Specific (Modeling) Languages (DS(M)Ls) are languages that are explicitly definedfor aspecific domain and are represented through aconcretesyntax. Theconcretesyntax canbefurther divided into textual concrete syntax and graphical concrete syntax.The advantagesof the respectivenotation must be determined in relationtothe concept used. If the focus lies on therelationships between objects, graphical languages should be preferred [1]. Although Integrated DevelopmentEnvironments (IDEs) of these DSMLsprovide some sortofcheckand validation on modeledsystems according to therelatedDSML’s syntax and semantics descriptions,they do nothaveabuilt-insupport fordebugging these models [2].That deficiency causesthe model designers not to be sure on thecorrectness of theircreated modelsduring the design phase.The model first hastobetransformed into ageneral-purpose language using code generation. The generated source code can then be viewed with existing developmentenvironments and checkedfor errorsutilizing the integrated debuggers.However, the generationprocesstakes significant effort and time.Therefore, it should be possibletocheck and validate the created model already duringthe design phase.Thus, onlycorrect models are used in thecodegeneration process.
1 1. Introduction
1.2ProblemStatement
Currentdevelopment tools provide differentapplication programming interfaces(APIs) fordeveloping tool support forvarious languages. If tool support for alanguage is required in multiple IDEs, the implementation of thesame language has to be repeated foreachIDE basedontheir differentAPIs.However,this limits the extensibility and reusabilityofexisting components forother languages.Inthis context, theLanguage ServerProtocol1 (LSP) fortextual languages separates theeditorinterfacefromthe language logicand allows thereuse of one language server implementing the language logic acrossseveral LSP-basedIDEs.
These limitationsregardingextensibilityand reusabilitynot onlyrelatetotextual languages,but alsographical languages.Since graphical languages were notconsidered in the LSP from thebeginning,attempts by members within the Eclipse Community2 to extend theLSP directly to include graphical modeling turnedout to be impractical[3]. Instead, adedicatedprotocolfor graphical languages -the Graphical Language Server Protocol3 (GLSP) -was invented to communicatemodel editing operationsbetween the diagram editor and the graphical language server. The use of aclient-serverarchitecture notonly reducesthe efforttointegratenew lan- guages with an editor but also supports the trend towards cloud-based development. Thus, the editor does nothavetobeinstalled locally and can be kept platform-independent. Through theshift to cloud-based solutions,modernweb technologies suchasHTML54 and CSS5 are used,whichoffer newpossibilities for graphical modeling and debugging approaches. Besides structuring the graphical user interface and integratinganimations during the debugging procedure, it furtherenables cloud-based collaborativedevelopment.
Increasing thecomplexity in software programs leadstoanincreasedoccurrenceof errorsinprograms, and thereforeitrequiresdebugging facilities for both textual and graphical languages.Incurrentdevelopment tools, because of thedifferentAPIs used by eachtool, implementing anew debugger involves significanteffort.This issue led to the introduction of the Debug AdapterProtocol6 (DAP) for textual languages to standardize the communication between adevelopment tool andadebugger. The protocol enables to implement only one generic debugger UI perdevelopment tool and reusethe same language-specific debugger across several developmenttools.
It is obvious that thereisaneed to provide debugging facilitiesalso for graphical modeling languages.The questionarises whetherthe DAPdefinedfor textual languages can alsobeused for graphical languagesoranew protocol is required.
1https://microsoft.github.io/language-server-protocol 2https://eclipse.org/community 3https://github.com/eclipsesource/GraphicalServerProtocol 4https://w3schools.com/html 5https://projects.eclipse.org/projects/ecd.sprotty 6https://microsoft.github.io/debug-adapter-protocol
2 1.3. Aim of theWork
1.3Aim of the Work
The work aimstoprovide avisualdebugger for aweb-based graphical modeling editor, which is based on theDAP and supports auser during thedevelopment of software componentsinaspecific domain. As part of this it has to be analyzed, whether the DAPinits currentversion is suitablefor graphical languages or an extension of the protocolisrequired. Therefore, therequirements fordebugging graphical modeling languages are derivedfrom an existingDSML,and potential inconsistencies in theDAP are dissolved.Furthermore,itmustbeanalyzed whether theexisting componentsand frameworksused by debuggers for textual languages,can be reused forgraphicalmodeling languages.Subsequently,ageneric debugger capable of coredebugging functionalities will be designed. Thedebuggerthen is integrated into an existingGLSP client builton top of the Graphical Language Server (GLS) platform7.Totest thegeneric debugger user interface, we require alanguage-specific debugger that resides on aremoteserverand alanguage-specific debug adapter thatconnectsthe developmenttooltothe language- specific debugger.Figure 1.1 illustrates theinteraction between thecomponents,as mentioned above.
Figure 1.1: Arepresentationofhow the individualcomponentsinteract with eachother (adoptedfrom [4]).
Finally,the following researchquestions will be answered: RQ1: What shouldadebug adapter protocol look like to meet the requirements of graphical modelinglanguages? RQ2: Can theDAP for textuallanguages be applied to graphical modeldebugging, and if not,whatneeds to be extendedorchanged? RQ3: What genericclient-frameworksand user interface/debug adapter client com- ponents mayexist forsuchadebug protocolthatcan be reused across debugging use cases for multiplegraphicaldomain-specificlanguages?
The mainquestions (RQ1 and RQ2) are concerned with answeringhow debugging conceptsfor textuallanguages can be applied to graphical modeling languages. RQ2
7https://github.com/eclipsesource/graphical-lsp
3 1. Introduction
analyzes theexisting DAPtoshowwhether it canbeusedfor graphical modeling languages. The question is answered by defining differentDSMLsand derivingthe requirements fromthose languages to implementadebugger. Basedonthese requirements,wecan makeastatementifthe DAPfulfills the purposes or needstobeextended.For the implementation of thedebugger, we use existing componentsand frameworkswhichwe can extend for therequirements.The RQ3isabout whichcomponents thathavebeen developedinthe course of thethesis canbegeneralizedsothat they mayact as ageneric basisfor developingvisual debuggersfor anygraphicallanguage.
1.4Methodology
The objective of Design Scienceresearchistobuild innovativeITartifacts and evaluate them.Since the central part of thethesis is to buildanITartifact thatbenefits its users, we use DesignScience as amethodological approach. A. Hevneretal. present seven guidelines for Design ScienceinInformation SystemsResearch[5]. Followingthese guidelines, thetwo majorsteps are design and evaluation. Design-science research must produce aviableartifact in the form of aconstruct, amodel,amethod, or an instantiation.Inthis work, ageneric debuggercapable of coredebuggingfunctionalities will be designed. The debugger should support the DAP or an extension of it to allow easyintegration of further graphical modeling languages. The debugger then is integrated into an existing GLSPclientbuilt on top of theGLS platform. Adesigned artifact is complete and effectivewhen it satisfiesthe requirementsand constraintsofthe problemitwas meanttosolve. It can be evaluated [6,7] in terms of functionality, completeness, consistency, accuracy,performance,reliability,usability, fit with theorganization, andother relevantqualities[8]. In this work,the artifact to be created is implementedutilizing an already existingDSML.Inthe first step, we derive fromthe DSML the requirements forthe debugger andimplementthem in afurther step. Forthe evaluation, we developanother DSML fromwhichwederivenew requirements and evaluate thecreated artifact. We want to showthat the debuggerwedeveloped can be reused to integratefurtherDSMLseasily.
1.5Structureofthe Work
Thisthesis consists of seven further chapters.Chapter2is concernedwith model-driven developmentingeneral, the introductionintodomain-specific languages,and applying debugging conceptstosource code,models, and other artifacts.Chapter3presents the existing client-serverarchitecture tools this work is basedonsuchasthe Language ServerProtocolfor editingtextual languages,the Graphical Language Server Protocol to createmodelswith graphical modeling languages,and the Debug AdapterProtocol fordebugging textuallanguages.Chapter4introduces an existinggraphicalmodeling languageand subsequently derives the requirements forimplementing adebuggerfor this language. Besides, adebuggerimplementedfor this language and fulfillingthe identified
4 1.5. Structure of the Work requirements will be presented. Chapter 5discusses the detailed experiences that were gained during theimplementation of thedebugger. Theresultsofthe evaluation based on anewlydefinedDSML are describedinChapter6.Related work is presented in Chapter 7. Finally,Chapter 8concludes by summarizing the presentedwork.
5
CHAPTER 2
Background
Thischapter presents essential knowledge regardingthe developmentapproaches and conceptsused inthis work. Thefirst sectionpresents the twomechanisms of code generationand modelinterpretation usedinmodel-driven development. The second section gives an overviewofthe most importantcharacteristicsofdomain-specific modeling languages. In the last section, we focus on debugging conceptsused incodedebugging and howtheseconceptscan be translated into debuggingmodelinglanguages.
2.1Model-Driven Development
In this section,will we introducethe Model-DrivenDevelopment (MDD) approach. Furthermore, we discussthe two mechanismscodegeneration and model interpretation used in MDD.
2.1.1Introduction to MDD MDD aimstofind domain-specific abstractions and makethem accessible through formal modeling.The developmentofsoftware throughMDD consists of creatingahigh-level representation of therequired software facilities and deriving an running application [9–13]. Intermediate steps can be enclosed to enable some kind of user interaction with the generation process [1].
Figure 2.1: Atypical MDD-based software developmentprocess [1].
7 2. Background
Figure 2.1 shows atypical developmentprocess,asdescribed in MDD. In eachphase of themodel developmentprocess,modelsare (semi)automatically generated using a model-to-modeltransformation (M2M). Finally,the designedmodels are translated into the finalsource code utilizing amodel-to-texttransformation.The example fromFigure 2.1 shows thedevelopmentprocess using acodegenerator, while modelinterpretation skipsthe implementation phase and executesthe model directly[1]. In thefurthercourse of this section, we will discuss thesetwo approachesindetailand presentthe advantages of using therespective tools.
2.1.2 Benefitsand Challenges One of themain advantagesofmodel-drivenapproachesisbridging the communication gap between requirements/analysis and the finalimplementation.Looking at theorganization levelinenterprises, this is amajor problem, as thereisalsoagap between businessneeds and IT realizations or support. Modelsare avalidsolution as a linguafranca among stakeholders from businessand IT divisions. Furthermore, modelscapture andorganize the understanding of theapplication in away thatsimplifiesthe discussion among the actors and easesthe integration of newteam members into the developmentprocess.The benefits of MDDcan be summarizedas[1].
• Increasing theeffectiveness of communicationbetween theinvolved parties.
• Raisingthe productivityofthe developmentteam due to the automation of the developmentprocess.
• Reducing thenumberoferrors in the finalcodethrough the automation process.
Onedisadvantage of MDD is thatmodeling andprogramming do not mixverywell. Existing General-purpose language (GPL) tools and IDEs cannot be reused formodeling languages without integration issues. Programminglanguages commonly have atextual concrete syntax,wheresource code is transformedthroughscannersand parser into an abstract syntax tree. Modeling languages have either atextual or graphical concrete syntax in whichthe latterisrepresented in theform of adiagram. Diagram editors manipulatedirectly the abstract syntax [14].Table2.1 shows the main differences between modelingand programming. Table 2.1 shows that debuggers rarely exist for DSLs, while adebuggerisalmost alwaysavailable forGPLs. As discussed in Section 1.2, it takes significanteffortand time to developanew debugger for alanguage andtointegrate the debugger into an IDE. Therefore, manyDSLsare first transformed into GPL code to be abletouse an existing GPLdebugger. Thisconfirms our work to simplify the integration of newdebuggers for graphical modeling languages into web-basedIDEs.
8 2.1. Model-DrivenDevelopment
Modeling Programming Defineyour ownnotation/language Easy Sometimes possible to some extent Syntacticallyintegrate several lan- Possible, depends on tool Hard guages Graphical notations Possible, dependsontool Usually only visualizations Customizegenerator/compiler Easy Sometimes possible basedon open compilers Navigate/query Easy Sometimes possible, depends on IDE and APIs View Support Typical Almost never Constraints Easy Sometimes possiblewith Find- bugs etc. Sophisticated matureIDE Sometimes, effort-dependent Standard Debugger Rarely Almost always Versioning, diff/merge Depends on syntax and tools Standard
Table 2.1: Maindifferencesbetween Modeling and Programming[14].
2.1.3 Code Generation and Model Interpretation Amodel is an executablemodel [15] whenits operational semantics are fully specified. In practice, not all models have to be executablesince the executabilitydepends moreon the adopted execution enginethan on the designed model itself.Onthe one hand, some models are not entirely specified,but there exist executiontools thatcan fillthe gap to execute them. On theother hand, theremightbevery complex and fully specified models, thatcannot be executedbecause an execution engine[16–19] is missing[1]. However, there exists alsomodelinglanguages (e.g. class diagram)that are not executable. These modeling languages are converted to GPL code by code generation and executedwith the GPL executionengine.
In order to execute models, there exist twodifferentalternative approaches: code generation and modelinterpretation.
Code Generation Code generators transform the modelsintoexecutable code forinterpretation or compila- tion inanautomatic way [20,21]. Thisprocess is similartowhat is known fromcompilers, and in this sense,codegenerators are referredtoasmodel compilers.Generators can be classifiedintodeclarative and operational or amixture of both. In thedeclarative approach, semanticmappings between themodel’s elements and thetargetlanguage are defined,whereas the operational approachuses rule-based transformations to produce target code step by step out of thesource model. Typically the target code is some kind of GPL. After generation, thecodeisalready completefrom the perspectiveofamodeler, and no further manipulation is necessary. Nevertheless,itispossible to view and edit the generated code with an IDE before executingthe generated artifact. Figure2.2 shows the processofgeneratingsourcecodefromaset of models [1].
9 2. Background
Figure 2.2: Code generation process [1].
In thefollowing, we summarize several benefits of thecodegenerationapproach[1].
• Code generation protects theintellectualpropertyofthe modeler. By generating the currentapplication, the conceptualizationand design of themodel are not shared with thecustomer. Themodel canbereusedand evolved for future projects. The customers only receivethe source code of theapplication. • The generated code is providedinastandard programming language knowntoany programmer. • Customerscan choose theirruntime environment. As aresult,customers are not dependentontechnologies used by the vendor of theMDD approach. Since code generation usuallyproducescodeinastandard language, thecustomer is not dependentonthe MDD approachinthe future, since the sourcecodecan be refined manually with availableIDEs. • Existing programming artifactscan be reused with code generation. The existing code can be generalizedand usedastemplates forcodegeneration of newpartsof the software. • In contrast to modelinterpreters,codegeneratorsare easier to maintain, debug, and track. An interpreter has ageneric andcomplex behaviortocoverall possible execution cases, whereas code generatorstypicallyconsistofrule-basedtransforma- tions. • Comparing thecodegenerator and modelinterpretation in termsofexecution speed,one cansay that agenerated applicationperforms better thaninterpreting the model.
10 2.1. Model-DrivenDevelopment
In additiontothe advantages of code generation, there arealso disadvantages.One issuewithin code generationisthat thegenerated source code mightnot look familiar to thedevelopers. Although theexecutionbehavesasexpected,and the code is written in the desired programming language, thecode’sstructure canbecompletelydifferentfrom the code the programmerwould write.The developers maynot feel very confident to edit or evolvethe sourcecodeinthe future. Forthis reason, MarcoBrambilla et al. [1] proposed aTuring test for code generation, similar to theclassic Turing test for AI1. Theydefined theTuringtestfor code generation toolsasfollows.
"A human judge examinesthe codegeneratedbyone programmerand one codegener- ation tool for the same formal specification. If the judge cannot reliablytellthe tool from the human, the tool is saidtohave passedthe test." ([1], p. 31)
Code generation tools that passthe Turing test have proved that they can produce code in away thathumans would do and should,therefore, be acceptabletothem.
Model Interpretation Model interpretationuses ageneric engine thatparses theelements of themodel and executesthem on theflywith an interpretation approach. Modelinterpretation can be characterized by the followingpropertiesand benefits [1].
• In the case of modelinterpretation,there is no needtodelve into the application’s source code. The modelreplacesthe code, and thereforenocodeexists whichcould be inspected.
• Modificationsonthe model canbedone during theruntime,ifthe interpreter supports continuing the executionbyparsing theupdated version of the model.
• There is no code generation step required afterchangingthe model.This signifi- cantlyshortensthe turnaround timeinincremental developmentapproaches.
• The runningapplication’s behaviorcan be changedbysimply extending the inter- preterwhile keepingthe same models.
• There is no deployment phaserequired because the designedmodel is alreadythe executableartifact.
• Compared to code generation, modelinterpretation [22,23] allowseasy debugging [24– 26] of models during runtime.Interpreters canprocessmodelsstepbystep. With code generation, it requires sophisticated tools because theexecutable application must be hooked to themodel concepts, and themodelingtoolmust catch events from therunningapplication.
1https://en.wikipedia.org/wiki/Turing_test
11 2. Background
Although manyusersknowabout the advantagesofmodel interpretation,some of them are not ready to makethemselvesdependent on theMDD tool vendor[1]. Since thesource code is not available,one cannot simply continueexecuting and evolvingthe application. Furthermore, performance concerns are often one of thereasons whythis approachisdiscarded [1]. Besides, the users areinstructed to install anew platform (model interpreter) in theirITInfrastructure that maybecritical in large enterprises due to strictITarchitecturepoliciesand securityissues [1].
2.2Domain-SpecificLanguages
Thissection introducesthe characteristics of Domain-Specific Languages (DSLs).The mainingredientsofDSLs,abstract syntax, concrete syntax, and semantics are essential to design avalidDSL and will be introduced in this section. Furthermore, we will presentthe benefits and challengesand givesome examples of DSLs. Please notethat in the modeling realm,DSLs are called Domain-Specific Modeling Languages(DSMLs) to emphasizethatthey are modeling DSLs. However, DSL is by farthe most commonly usedterm, and thereforewewill sticktoitinthe upcomingdiscussions.
2.2.1 IntroductiontoDSLs DSLsraise thelevel of abstraction beyond programming by defining the solutionina language that uses conceptsand rulesfrom aspecific problemdomain[27]. DSLs are programming languages used by humans to instruct computerstodosomething. They should be designed in away thatthey are easier to read and understand. However, DSLs should alsobeexecutable by acomputer. The expressiveness comes fromexpressions and theway they are composed together. DSLs have limitedexpressiveness and should, therefore, onlyprovide the featuresneeded for thespecific domain[27]. Therefore, DSLs are onlyused to implementaparticular aspect of asysteminstead of building an entire system. Finally,DSLshaveaclear focusonasmallapplication domain,whichiswhy they cannotbereused for other domains [27]. General-purpose languages (GPLs)are in contrast to DSLs Turing-complete. This meansthatanythingcomputable with aTuring machine can be implemented with a GPL.Furthermore, all GPLs are interchangeable. Everything thatcan be expressed in one language can alsobeexpressed in anyother language.Nevertheless,there are alsoproblems in the areaofGPLs, where specialfeatures are required [28]. Thus,many differentGPLs have been developed overthe years, e.g. Java,C#, Python.Table 2.2 shows the main differences between GPLs and DSLs. While DSLs and GPLsmay have characteristics from both the second and thethird column, DSLs are morelikely to have characteristicsfromthe third column[14].
12 2.2. Domain-Specific Languages
GPLs DSLs Domain large and complex smaller and well-defined Language size large small Turing completeness alwaysoften not User-definedabstractions sophisticated limited Execution via intermediate GPL native Lifespan years to decades months to years (driven by context) Designed by guruorcommittee afew engineersand domain experts Usercommunity large,anonymousand widespread small, accessibleand local Evolution slow, oftenstandardized fast-paced Deprecation/incompatible changes almost impossible feasible
Table 2.2: Domain-specific languages versus general-purpose languages [14].
Fowler identifiedtwo maincategories of DSLs, namely, internal and external DSLs[27].
• Internal DSLs are usuallybuilt on top of ageneral-purpose language or extending the language. The DSLiswritten using aparticular grammar and onlyusesasubset of thehost language’sfeatures to handleone small aspect of an overall system. The grammar is restricted to thelegal syntax of itsgeneral-purpose language but should givethe feeling of acustomlanguage. Duetothe same syntax rules,the host language’sexisting tools can be reused forthe internalDSL.Besides, error handling and reportinginthe main languagecan be partially reused for the internal DSL.
• ExternalDSLs have theircustom syntax and are separated from themain language of theapplication with which theywork. Amodel of an externalDSL, whether textualorgraphical,isparsed and then executedbyaninterpreter or translated into another language, typicallyaGPL,usingacode generator. In contrast to internal DSLs, thereexist no utilities thatwill support theuse of the newly created language. One will have to figureout apractical wayfor common features like parsing,syntaxhighlighting,exceptionhandling, and reporting.
2.2.2 Benefits and Challenges In thefollowing, thebenefits of DSLs identifiedbyFowler[27],Voelter et al. [14],and Kelly et al. [29] are listed.
• Productivity. Ahigherlevel of abstraction makes it easier to read and understand amodel and leads to better productivity. FewlinesofDSL code replaces alot of GPL code, thus reducingthe overall complexityofaprogram. Thismakes it easier to find errors and modify thesystem.Finally,usersofDSLs are not dependent on learning ahuge and complex GPL likeJava. Instead, they onlyneedtounderstand afractionuseful in theirproblem domain.
• Quality. DSLsincrease not onlyproductivitybut alsoqualityinterms of fewer bugs, better architectural conformance,and increasedmaintainability. Thisapproachis alsoknown as correct-by-construction. If theDSL is designed in the right way, only the constructionofcorrect programs is allowed.
13 2. Background
• Validation and Verification. SinceDSLsare semantically richer thanGPLs, they are not clutteredwith implementation details. DSLs are aware of thedomain concepts.Therefore, error messagesuse moremeaningfulwording, and analyses are easiertoimplement. Duetothe involvementofdomain experts, manual review and validationbecome more efficient.
• InvolvementofDomain Experts. On the onehand, developers arenot aware of thedomain, they communicatewith the domain expertstoconstruct awell- designed DSL.Onthe other hand, domainexperts do not have to dealwithcomplex implementation details but caneasily createprograms.Visualizations or simulations can furtherfacilitateunderstanding.
• ProductiveTooling. ManyexternalDSLscome with theircustom IDEsthat are aware of thelanguage and improve the user experience. Such features include static analyses, code completion, visualizations, debuggers, simulators,and more. Thisnot onlymakes it easierfor newusers to learn the languagebut alsoincreases user productivity.
In addition to benefits, there are also challenges to overcome [14,27, 29].
• Language Cacophony. Using multiple languagesinone project is much more complicated than using asingle one. Fornew projectmembers, it is hardto understand what is goingoninthe system. Manyforget that learninganew DSL is much easier through thelevel of abstraction and takes less effort than learning a GPL.However, it must be considered whether it would be moresensibletolearn the underlyingmodel instead of the DSLused.
• Effort of building theDSLs. Before using aDSL in aproject, one has to build it first. It is importanttoconsider whether theeffort and costsinvolved in generating the DSL are worth it. This must be taken into accountinthe overall cost-benefit analysis rightfromthe start of theproject. FortechnicalDSLs thataddress aspects suchascomponents, state machines, or persistencemappingofsoftware engineering, this questiondoesnot usuallyarisebecause they have great potential forreuse. In the meantime, there are modern tools availablethat significantlyreducethe effort required to developnew DSLs. Generally speaking, threefactors reduce the cost of DSLs: in-depth knowledgeabout adomain, experience of theDSL developer, and productivityofthe tools.
• Language Engineering Skills. As mentionedinthe previous point, it takes acertainamount of experience and skilltobuild anew DSL. Although modern languageworkbenchfacilitates theintroductionofnew languages,thereisstill a certainlearning curve. Buildingrelevantlanguages and defining therightabstraction levelrequires experience and practice, whichcan be gained over time while working with differentlanguages and problem domains.
14 2.2. Domain-Specific Languages
• DSLHell. The constantsimplificationtocreate new DSLsposes another issue. Manydevelopers tend to introduceanew DSL instead of searching forand learning an existingDSL forthat specific domain. This endsupinabunchofincomplete DSLs, each covering commondomains but notcompatible.One waytoavoid this is to createDSLs is such away so they can be easily extended or used as astarting pointfor otherlanguages. Features can be easily addedtothe existing language.
2.2.3 Examples In this section, we discuss examplesofexisting DSLs. In particular, the DSLsHQL, BPMN, and WebML are introduced.
Hibernate Query Language (HQL) HQL2 is aDSL with atextual syntax that combinesobject-oriented codingwith relational databases. HQL is similar to theStructuredQuery Language3 (SQL)syntax, but instead of workingwith database tablesand columns, HQL queriesuse persistentobjects and theirproperties. TheHibernateO-R Mappertranslates the HQL queryintoaSQL statement that matches the corresponding databasetype. Listing2.1 shows an example queryinHQL [27]. select person from Personperson, Calendar calendar where calendar.holidays [’national␣day’] =person .birthDay and person .nationality .calendar=calendar Listing 2.1: HQL example [27].
Business Process Model andNotation (BPMN) BPMN4 is awell-known standardfor businessprocess modeling thatconsistsofnotational structures fordesigningbusinessprocesses basedonflowchartingtechniques. BPMN aimstoprovide business process modeling forbusiness users and technicalusers atthe same time by displaying both simple and complex systems. TheBPMN 2.0 specification5 enables theexecutionofbusiness process modelsaswellasthe transformation of models into other execution languages,especiallyintothe Business Process ExecutionLanguages6 (BPEL) [30]. Furthermore, BPMN wasdesignedtoprovide asimple, readable,and understandable language for all businessstakeholders.This might be the business analystwho creates and completes theprocesses or thetechnical developerwho implementsthe processes or the business manager who controls and managesthe processes. Consequently,BPMN can
2https://docs.jboss.org/hibernate/core/3.3/reference/en/html/queryhql.html 3https://iso.org/standard/63555.html 4http://bpmn.org/ 5https://omg.org/spec/BPMN/2.0 6https://oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
15 2. Background
be usedtoovercome the communication gap, which mightoccurbetween businessprocess design and implementation [30].Figure 2.3 shows aBPMN model,whichdescribesthe process of hiringpeople in acompany.
Figure 2.3: BPMNexample [1].
WebModeling Language (WebML) WebML7 is ahigh-level modeling languagefor hypertext specifications. WebML consists of simple notational constructs that defines ahypertext as aset of pages. The notation consistsofcontrol units,operations, and edges, which connect the control units.WebML is stronglyoriented towards the notation of well-known conceptualmodelinglanguages like Entity-Relationship8 (ER)and Unified Modeling Language9 (UML): every concept hasanotational construct, and specifications are diagrams. Therefore, usersfamiliar with UML or ER do not have to worry about learninganew language [31].Figure 2.4 shows aWebML modelthatdescribes theuser interface of awebsitefor navigating a productcatalog by category.
Figure 2.4: WebML example [1].
7http://webml.deib.polimi.it/page1.do.html 8http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.123.1085 9https://uml.org/
16 2.2. Domain-Specific Languages
2.2.4 DSL LanguageConstructs In this part of thesection,wewould liketodiscuss the components of aDSL, as it is importanttounderstand them when creatinganew language. DSLs, like languages in general,consist of syntax and semantics.The syntax is furtherdividedintoabstract syntax and concrete syntax,wherethe abstract syntax addresses thestructure and grammatical rules of alanguage, and theconcretesyntax defines the representationof the language to the user. Thedefinition of thelanguage’smeaningisreferred to as semantics [1, 14, 29, 32, 33]. Figure2.5 shows the three ingredientsofaDSL and their relationship to each other.
Figure 2.5: The threemainingredientsofamodeling language and theirrelationships [1].
Abstract Syntax Describes the conceptionalstructure of alanguage, itsproperties, modelhierarchy structures,model correctnessrules, andhow the differentelementscan be connected. The abstract syntax is specified in themetamodel [34, 35]. The term "meta" is used because thelanguage specification is one levelofabstraction higher than the models. Figure2.6 shows the metamodel of afinite-state automaton. The metamodelconsistsof the FSAModel containing States and Transitions.Astate has theproperties isInitial, isFinal,and name.Furthermore, astate has optional outgoingand incoming transitions. Transitions have aproperty event to trigger thetransition. Atransitionhas exactly one sourcestate and exactlyone target state. These canbetwo differentstates or one state that representsbothsource and target.The syntax of alanguage alsoincludes grammatical rules (e.g. amodel contains zerooruptoanundefinedamount of states) which aretaken from theproblemdomain. The advantage of defining therules in the languageisthat the effort required to checkthe model forerrors is reduced.Considering several code generators exist for one language, thechecking wouldhave to be done for eachcodegenerator. The grammatical rules determinehow models can be constructed: they define the legal values, relationships between concepts, and howcertainconcepts should be used[1, 29].
17 2. Background
Figure 2.6: The abstract syntax of afinite-state automaton [36].
Semantics Every language has ameaning, alsocalled semantics.When anew elementisaddedto amodel or twoelements are connected, meaningiscreated. Usually, thesemantics are derived directly fromthe problemdomain for which the DSL is designed. Forinstance,the implementation of an infotainment system for acar already has awell-defined meaning within the application domain. In this problem domain,the modeling concepts, likea knob, amenu, or an event, can be found.Ingeneral-purpose languages,itisuptothe developers to adapt the semantics and language conceptstoaspecific problemdomain. Every individualdeveloper implements the mapping between concepts and problem domains differently. Forthis reason, differenttypes of modelsare also created for the same problemdomain. Thisisthe advantage of aDSL thatinsists on using theconcepts and semantics of theapplication domain[29].
In thefollowing, we introducedifferent kinds of methods to formally definethe semantics. Theoperational semantics methodusesaninterpretertodefine alanguage. The interpreterproduces an evaluation history whenitinterprets the program. The evaluation history is asequence of internal interpreter configurations.The meaning of aprogram in the language is the produced evaluationhistory [37]. The denotational semantics methoduses avaluation function to bind aprogram directlytoits meaning, called itsdenotation. In contrast to operational definitions, the denotational definition does not require an interpreter or computation steps [37]. The axiomaticsemantics methoddoesnot explicitly define the meaning of aprogram. Propertiesthatare expressed with axioms and inferencerules fromsymbolic logic are defined forthe language constructs. To construct aformal proof,the propertyofa program is deducedfrom the axioms and rules.The kind of propertiesthat can be proved are used to determinethe character of an axiomatic definition. Axiomaticdefinitions are moreabstract thandenotational and operational definitions. The properties proved about aprogram maynot be enough to completelydetermine theprogram’smeaning[37].
18 2.3. Debugging in Domain-SpecificModeling
ConcreteSyntax The concrete syntax is the most visible partofthe language, as it describes thenotation of thelanguage and is stronglyoriented towards the domain concepts. The representation is either graphical or textualbut can alsobevisualized in theform of amatrix or table. Modeling languages are usually represented graphically combinedwith text. Figure 2.7 shows the domain concept and theassociatednotational structures of afinite-state automaton. Whichform of notation is used for aDSL dependsstrongly on the real representationofthe domain concept.Tostaywith the carexample:Aknob for a car infotainment system should have asimilar visualization in themodelinglanguage. Regarding the completenessofrepresentation and representation fidelity, it canbesaid thatthe presence of exactlyone notational construct foreachconcept is an essential criterion for interpretingdifferentmodeling conceptsand notations.This approachavoids overloading the notational constructs and ensures that all conceptscan be represented with thelanguage [29].
Figure 2.7: The concrete syntax of afinite-state automaton [36].
2.3Debugging in Domain-Specific Modeling
There are two importantfacetsofthe developmentprocessofdomain-specific modeling. Developing transformations anddeveloping models. Model transformation [38–41] in the context of Model-DrivenEngineering (MDE)isused to convert asource modelintoa target model.Ifboththe sourcemodel andthe target modelmatch the same metamodel, this is called an endogenoustransformation and is used to perform model refactoring and optimization. However, if both have adifferentmetamodel, it is an exogenous transformation and used for tasks like code generation and reverse engineering.There exist also studiesthatdeal with thedebugging of modeltransformations[42, 43]. Since this work focuses on thegeneration of models and theirinterpretation,wewill dealin the course of this section onlywith debugging models and artifacts itself,but notwith
19 2. Background
debugging transformations. First, debugging of sourcecode, including the procedure and theadvantagesofdebugging, are discussed.Afterward,the individual debugging conceptsand howthey are used for debugging code are represented.Finally,itwill be analyzed howthese debuggingconceptscan be transferred to modeling languages.
2.3.1 DebuggingCode Debugging is an essential partofevery developing process.Any software thatisdeveloped should be bug-free before delivery.Debugging is aprocessusedbydevelopers and software testers to find errors and fix them [44].Several studies deal with themost common causesoferrors and whysome errorscause moredamage than others [45]. To track down and resolve bugs, concepts like steppingthroughcode, interrupting theexecution, or investigating information aboutthe currentprogram statecan be used. The debugging process canbedivided into six main phases [46]: 1. Identify Error: The earlier theerrorisfound, themore time and costscan be saved. Errors that occur at thecustomer site increase thecostsand damage the company’sreputation. 2. Identifythe ErrorLocation: After theerrorhas been detected,itisnecessary to identify the exact location within the sourcecodethatcausesit. With the knowledgeofthe exact position of thefaulty code, theerror can be fixed faster. 3. Analyze Error: In this phase, asuitable proceduremustbefoundtoanalyzethe error.The debugger provides informationregarding the program’sstate and the data structure to analyze the error. Thisisacriticalphase because by fixingthe bug thathas occurred, new errorscan creep into thecode. 4. Prove theAnalysisResult: Once the errorhas been analyzed, the focus must be on thesoftware’s furthererrors. This includeswriting test cases to ensure the correct functioning of thesoftware. 5. CoverLateral Damage: In this phase, testsmust be performedtocheckthe changedcode. Thosetestcases which do not passthe test must be investigated. As soon as alltest casespass thetest, thedebugging process’s lastphase canbe initiated. 6. Fixand Validate: Thisisthe last phase,all bugsare fixed, andall test scripts are executed. The advantages of software debugging can be summarizedasfollows [46]: • Savestime. Performingdebugging during thedevelopment process savestime because software developersdonot needtowrite complex code to findthe error. • Reports Errors. As soon as errorsoccur, debuggers provideanerrorreport. Thisenables early detectionoferrors and thus simplifies thesoftware development process.
20 2.3. Debugging in Domain-SpecificModeling
• Easy Interpretation. The information provided through thedebugger about the execution state and thedatastructures makesiteasier to interpret errors. The software developercan fix errors before the product is deliveredtothe customer.
The following debugging facilities are commonly used in modern IDEsand their debuggers.However, it is onlyaselected list of all available debugging facilities,but that is sufficientasaneffectivebasisfor debugging source code [42].
ExecutionModes All available IDE debuggers providetwo basicfunctionalities:First, to execute aprogram continuously untilthe program is terminated or interrupted by the developerand second step-by-step execution of one statement at atime.Further execution features are the stop and pause commands for theterminating or non-terminatinghalt of theexecution. Using thestep-by-step mode or thestart/continue command, the programmers re-enters continuous mode [42].
Steps There are usuallythree kindsofstep commands in every debugger: step-over, step-in, and step-out.The step-over command executes the currentstatementasone block.On the step-in command, the debugger goes through all thesub-statements contained by the currentstatementstep-by-step.This furtherrequiresachangeofscope. The step-out command executesthe application untilthe end of thecurrentscopeisreached, and the debugger is one levelhigher in the call stack [42].
Runtime VariableI/O When theapplication’s execution is paused,debuggers providethe functionalitytoread and change theprogram’s global and local variables. While the executionispaused, developers canassign anyvalues to variables, apart from basictypes. Thesignificant advantage of this feature isthatnoprintstatements are necessaryfor theuser to investigatethe program’scurrent state [42].
Breakpoints The developercan specify breakpoints to interrupt the program’sexecutionataspecific pointinthe sourcecode. Breakpoints are set on statementstopausethe execution before the debugger executesthe given statement.Most debuggersalso supportmore advanced breakpoints: Breakpoints with booleanconditions, breakpoints with hit counts, exception breakpoints, data breakpoints,orfunction breakpoints. Condition breakpoints halt the executionifany from the developerspecified condition over thestate is fulfilled. Hit countsfor breakpoints pausethe execution whenthe statementisexecutedan arbitrarynumberoftimes.Exceptionbreakpoints pause theexecutionassoonasa certainexceptionisthrown.DataBreakpoints interrupt theexecutionwhen the value of a
21 2. Background
certainvariablechanges. Function breakpoints leadtoahalt in theprogram whencalling acertainfunction. Exceptionbreakpoints, data breakpoints and function breakpoints are not associated withaspecific source location [42].
Stack Traces Stack tracesprovide the developerwith aview of thefunctioncalls that led theprogram into its currentstate. While the executionispaused,stack traces become visible. The programmercan dive into anyother level in the stack trace for variable viewing and sourcecodeediting [42].
Exceptions Exceptions are thrown during runtime and informthe userthat the system is in an error state and mayhalt theprogram’s execution. Theexceptioncontains information on the error,the type of exception, and thestate (exceptioncontext)ofthe program whenthe error occurred. There are manyexceptions predefined in languages to report events like null-pointerdereferencing and I/O problems. When an error occurs,the runtime system climbs up thecall stackand searchesfor amethodthatcontains ablock of code that can handlethe exception. This code is alsoknown as an exception handler. Appropriate exception handlerscan be defined by developers to catch an exception and handlethe exception (takeappropriate action) to recoverfromthe identified issue.Ifnoexception handler canhandle thethrown exception, the runtime system terminates. Finally,it should be mentionedthatprogrammerscan also implementnew typesofexceptions to enablesupport for system-specific exceptional situations [42].
2.3.2 DebuggingModels Hans Vangheluwe and Raphael Mannadiar [42] identifiedtwo differentdebugging scenarios in domain-specific modeling. These two scenarios have roughly the same basicworkflow but differinthe differentexpertiseofthe users. On theone hand, designersare debugging modeltransformations and artifacts generated by them.They are fully aware of the modeltransformation that describestheirmodels’ semantics and generates artifacts. Their goal is to ensurethe correctness of thegenerated artifact. On theotherhand,the modelers are interested in thecorrectness of theirdomain-specific modeland are only familiar withthe semantics of theirmodel withoutbeing aware of artifacts generated fromthem. Belowwere-visitthe debugging conceptsdescribed in theprevious section and translatethem to debugging in domain-specificmodeling[42].
ExecutionModes Playing and stopping the executionrequire functionalitytorun or kill thegenerated modelorprogram remotely. Consideringstepping,one must first identify howastep can look in aparticular model. Thiscan be challenging, depending on thelanguage. Vangheluwe and Mannadiar [42] propose in theirpaper averygeneral definition.
22 2.3. Debugging in Domain-SpecificModeling
"Any modification of the state of adomain-specificmodel constitutes astep, where the notion of the state encompasses the values of the parameters of every construct in the model." ([42], p. 15)
Likestepping,pausingthe executionalsopresents acertainchallenge. Thepause mode should depend on the structureand semanticsofthe domain-specific model. The most common and widely used approachistopausethe executionrightbefore the execution of thenextstep at themodel level. While this approachissufficientfor modelers,itshould be noted thatitcouldbefurtherrefinedtoapply to designers. It is a great advantage and sometimes even necessary for designers to pause or step on thelevel of generated code statements[42].
Steps The meaningofsteppingover, into and out,may be consideredfrom twoorthogonal perspectives.Onthe one hand, thenotation can be translated one-to-onefor DSLs thatsupport hierarchies and composition. Taking astatechart-based languagewhen the currentstate is within acompositestate, stepping out would continue the execution of themodel untilitleavesthe parentstate.Onthe other hand,considering that an implicithierarchy is created between the generated artifact and thesource model, it can be useful forthe designer, in case of thestep-in command, to switchthe execution pointer of thedebuggertothe corresponding lower-level entities.Keeping up with the statechartexample, the use of thefirst step-in command would allow the designer to step through theunderlying statechart, while another step-in command would allow the designer to step through the statements of thecodegenerated from the statechart. Stepping out would bring the designer back to the higher-level representations. These differentstepping modes confirm the requirement fortwo differentdebug modesfor designersand modelers [42].
Runtime VariableI/O Whilethe executionispaused,variablevaluesofdomain-specific models and lower-level generated artifacts can be viewed and modifiedusing themodel editingtool. Thereal challenge is that achangeofavariableatone level of abstraction must alsobevisible on everyotherlevel to ensure overall consistency [42].
Breakpoints Breakpoints, as knownfrom typical IDE debuggers,can be translated one-to-onetothe DSM world. Nevertheless,there are differencesbetween therequirementsofamodeler and those of adesigner. Forthe modeler, it is sufficienttospecify breakpointsonlyon the model level, whereas forthe designer,itisrelevanttoset breakpoints on eachlevel of abstraction between modeland end artifact. Depending on themodelinglanguage, it must be defined whichelements of amodel can be markedasbreakpoints.Looking
23 2. Background
again at thestatechart-based language, it probablymakes most sense that individual states support thesetting of breakpoints. In the course of transitions that use actions, it should alsobeconsidered whether one can set abreakpointbefore executing theaction and thus pausing theapplication. In thecase of Petri-Nets[47], where the state is implicitly represented, this approachisnot practical. Hans Vangheluwe and Raphael Mannadiar [42] instead porpose for this case that breakpoints are specified as patterns. When the patterns are matched in themodel,the executiongets paused.Asincode IDEs,hit counts and boolean conditionscouldbespecified in thesame manner.While function breakpoints are not importantfor themodeler,they canbeusefulfor the designer concerning generated artifacts and thefunctions called at this level.Exception breakpoints are strongly oriented on howexceptions are handled in thedomain-specific models, and thelowerlevel generated artifacts [42].
Stack Traces As knownfrom code debugging, stacktracesinthe domain-specific modeland artifact debugging are bound to the termsstepping in and steppingout. From theperspective of the modeler, the structures of thehierarchy and composition of DSMLs are reflected.On the other hand, thedesigner debug mode mightdisplaysequences of related actions at different levels between model and generated artifact[42].
Exceptions As we mentionedinthe previoussection about DSMLs, onlycorrect models can be created due to the abstract syntax’s definitions.Therefore, when debuggingmodels, exceptions do notoccuratthe level of themodel butduring the executionofthe synthesized artifact. Although themodelsare animated and updated in real,only the artifacts are executed. Exceptions can be caused by I/O errorsorbugsinthe executionengine or third partylibraries but alsothrough operational semantics transformation of lower-level models. Someofthese exceptions canbetranslated one-to-one into domain-specific terms. In contrast, other exceptions requirepropagation and translation facilities for the presentationtothe designer or modeler. Furthermore, it should be noted that some exceptions are only of minorimportance for the modeler, and others mayprovide informationthatisusefulonly forthe designer. The DSL architect’s task is to decide between exceptions that are passed on to thehighest level of abstraction and those that are silentlyhandled [42].
24 CHAPTER 3
Web-based Modeling Tools
Thischapter discusses existingtechnologiesfor implementing web-based modeling tools. In particular, theprotocols LSP,GLSP,and DAPare introduced.
3.1 Language Server Protocol
The number of programming languages hasincreasedrapidlyoverthe last few years. Besides, more andmore IDEs were created [48]. Nevertheless, it is difficult forthe IDE developertokeep up andconstantlyoffer newlanguage support.Language providers are very interested in offering as manyIDE integrations as possible fortheir languageto gain abroader user community.The resultisanm-times-n complexity to integrate all existinglanguages into every available IDE.In2016, Microsoft, RedHat1,and Codenvy2 introduced the Language Server Protocol3 (LSP) to separatethe language-specific logic fromthe integration into an IDE. The language server,whichisoffering thelanguage logic, can thus be implemented in anyprogramming language. Code-completion, goto definition, and refactoring are onlyafew functionalities computed in alanguage-specific server process [49].
LSP’sgoal is to communicatemessagesoverastandardized protocolbetween the languageserverprocess and theIDE client process,whichintegrates thelanguage into an IDE. Thisprocess reducesthe complexityofintegrating all languages into every existing IDE to m+n. Sincethe introductionofthe LSP,more than 100 language servers and morethan30tools have been implementedthatsupport LSP.Theseinclude popular languages likeJava, TypeScript, C, and Python. On theeditor side,the LSP is supported
1https://redhat.com/en 2https://codenvy.com 3https://microsoft.github.io/language-server-protocol
25 3. Web-based Modeling Tools
by IDEs likeEclipse4 or VSCode5.Inadditiontogeneral-purpose languages, there already exist various language servers fordomain-specific languages (e.g. HTML, LateX6, CSS). However, Xtext7 [50]isthe only language workbenchthatcurrently supportsthe languageserverprotocol. This allowslanguages that are implementedwith Xtext to take advantage of theLSP’s features and benefits [49].
3.1.1 Architecture of the LSP The protocol uses thestateless and lightweightremoteprocedurecall protocol JSON- RPC8 in itsversion2.0, whichuses JSON as adata format.JSON-RPC wasdesigned to transmit remote procedurecallsoveranetwork. However, it canalsobeused to transfer data fromaclienttoaserverrunning on thesame physical machine.Most language serverimplementationsrun on thesame physical machine as theoperated IDE.The LSP distinguishesbetween three differenttypes of messages: requests, responses,and notifications.Arequest message describes arequestbetween theclientand the server. Everyprocessed request must sendaresponse message as aresult of arequestbacktothe senderofthe request. A notification message works likeanevent and notifies thereceiver of an occurred activity. All messagesare divided into aheader and acontent part. The header specifies the content length and content type.The contentpart containsthe actual contentofthe message [51].
Figure 3.1 shows an editing processand theresulting communication between the three actors, the user, the the client (IDE/developmenttool), and the languageserver. The user,shown on theleft side of theillustration, starts the communication between the client andthe server throughits actions. The arrowsbetween theclientand the servermark themessagesthathave been standardizedinthe language server protocol. Thesession startswhen the useropens adocument. Thedevelopment tool then notifies the language server that adocumenthas been opened.Asanext step, the useredits the document. Again,anotification is sent to the server fromthe developmenttool. After theserverhas received thenotification, it analyzes the changesdone by the user. If errorsorwarnings are detected by the server, they are returnedtothe client.Ina furtherstep, the user executes a goto definition action. The client sendsarequestto the server with the currentcursorposition within the document. In Listing 3.1, the request textDocument/definition of the goto definition action is shownindetailasa JSON-RPC call.Besides, theURI to thetextdocument, the line,and character location are transferredtothe languageserver. The serverthen determines the exact position of the variable declarationand sends the resulting location backtothe developmenttoolas aresponse. The corresponding JSON-RPC callisshown in Listing 3.2. Theresponse includesthe new URI and thelocation range of thetarget position. The development
4https://eclipse.org/ide 5https://code.visualstudio.com 6https://latex-project.org 7https://eclipse.org/Xtext 8https://jsonrpc.org/specification
26 3.1. Language Server Protocol tool is responsible for openingthe correct documentbased on thelocation and setting the cursortothe specifiedposition.The last message notifies theserverthatthe user closed thedocument. Based on theexample shown, it can be seenthatthe protocolis basedondocuments and thepositionswithin them.Asaresult,the protocolremains independent of the specific language for which theLSP is used.
Figure 3.1: Communication between thedevelopment tool and thelanguage serverduring the editing session[51].
1{ 2"jsonrpc ": "2.0" , 3"id":1, 4"method ": "textDocument/definition ", 5"params ": { 6"textDocument ": { 7"uri ": "file :///p%3A/mseng/VSCode/Playgrounds/cpp/use.cpp" 8}, 9"position ": { 10 "line":3, 11 "character":12 12 } 13 } 14 } Listing 3.1: Goto definition action in aC++ file [51].
27 3. Web-based Modeling Tools
1{ 2"jsonrpc":"2.0" , 3"id ": 1, 4"result ": { 5"uri ": "file :///p%3A/mseng/VSCode/Playgrounds/cpp/provide .cpp ", 6"range ": { 7"start ": { 8"line":0, 9"character ": 4 10 }, 11 "end ": { 12 "line":0, 13 "character":11 14 } 15 } 16 } 17 } Listing 3.2: Response to the goto definition request in aC++ file [51].
3.1.2 Featuresofthe LSP Sincenot all languages and IDEs support all theprotocolfeatures,the supported features are sentasso-called "capabilities"from the IDE to the languageserverduring the initial requests.The languageserver interprets missing Capabilities as not being supported by the client.Unknown Capabilities are ignored. Thelanguage serverresponds to the initial request with the Capabilities it supports. In thefollowing, we briefly describethe LSP keyfeatures,whichare supported by most language serverimplementations [51].
Code completion. The clientsends therequest codecompletion,including the currentdocumentand the cursorposition within the documenttothe language server. The serverrespondstothe request by sending thecomputedcompletion elementsfor the given position backtothe development tool.The client process then forwards the completion proposals to thecontextmenufrom whichthe user selects the element. In the case of an expensive completion, the completioncan be represented by a handler.As soon as theuser selects an elementfromthe contextmenu, the handler sends another request to the language server to request the entire completion text.
Hover. The developmenttoolsends therequest hover to the language server to computeadditionalinformationshown in atooltip. Thehover menufeature further supports text-formatting,including line breaks, lists, and indentations.
Goto Definition. Through therequest goto definition,the language serverresponses the position of agiven symbolwithin adocument. Therequest goto type determines the position of agiven type.For theimplementation location of agiven symbol, the request goto implementation is available inthe LSP.
28 3.2. Graphical Language Server Protocol
Workspace symbols. The developmenttoolsendsthe request workspacesymbol taking aquerystring to the language server to reveal all matchingworkspacesymbols within the workspace. Workspace symbolsare an index(or tag) fileofnames found in sourceand header filesofvarious programming languages.
Find references. The request find references returnsaproject-wide list of locations basedonthe currentcursorposition. Eachofthe locationsreferencesthe symbols at the currentcursor position.
Diagnostics. Diagnosticsisexecuted by the language server andmight be handled perfile or for acompleteproject. Throughdiagnostics,errors andwarningsare detected and sentvia notification to the developmenttool. If no errorsorwarningsoccurred, the servergenerates anotification with an empty list of diagnostics.Therefore the client always replaces the currentdiagnostics, and no merge is required.
In addition to thecapabilities already mentioned, theLSP alsocontains other in- teresting featuressuchascodelensorsignature help. New features will continue to be integrated into the LSP,and so the LSPinversion 3.16.0will supportfeatureslikecall hierarchy or semantictoken.
3.2Graphical Language Server Protocol
The Graphical Language Server Protocol (GLSP)was introduced by EclipseSource9 in 2018 and follows thesame architectural pattern as theLSP fortextual languages,but usesitfor graphical modeling languages. Initial attempts to reuse the LSP for graphical modeling hadtoberejected due to the differentrequirementsoftextual and graphical languages.Thus, anew protocol has been defined.The GLSP is primarilybased on the client-servercommunication protocolofthe diagram framework Eclipse Sprotty10. Additionally,GLSP comes with editfunctionalities and server-specific communication. Probably the most importantuse case for theprotocolisthe developmentofweb-based diagram editors, which connecttoalanguage serverand transmit messages viathe protocol. Besides the defined protocol, the Graphical Language Server (GLS) platform11 providesaclientand aserverframework that can be integrated into existing IDEs. The client is responsible for renderingand time-criticaloperations,suchasfade out effect, whereas theserverisincharge of thelanguage-specific semantics [52].InChapter4, we will usethe platform in the running example to integrate adiagram editor into the web-based IDE framework EclipseTheia12.
9https://eclipsesource.com 10https://projects.eclipse.org/projects/ecd.sprotty 11https://eclipse.org/glsp 12https://theia-ide.org
29 3. Web-based Modeling Tools
3.2.1 Architectureofthe GLSP As already mentioned, theGLSP builds stronglyonthe client-serverprotocolofEclipse Sprottyand its architecture.Sprottyisaweb-based diagram framework using modern web-technologies like SVGfor renderingand CSSfor styling. Aunidirectional event-cycle is an essential partofthe architecture with avirtualDOM as opposed to themodel- view-controller pattern. Therefore,the eventflow is alwaysclear, does not form feedback loops,and takes less effort to test [53].Figure 3.2 shows an overview of the Sprotty architecture, which is describedinthe following. All relevantinformationregardingthe diagram and theoperations thatcan be performed on it is storedonagraphical language server. Theclientisonly equipped with themostnecessarydetails, whichitneedstorenderthe diagram. Sprottywas developedtotakeoverthe visualization partoflanguage servers. TheSprottyserver extendslanguage servers created with thelanguage workbenchXtext. This facilitates the creation of graphical representationsfor DSLs. It is precisely thisapproachonwhich the GLSP is based: Separation of language logic from IDE integration. Instead of using the LSP for textual languages,the GLSP forgraphicalmodeling languages can be used. Besides, the GLSP extendsthe static visualization of Sprotty with editfunctionalities [52].
Figure 3.2: The architecture of thediagram framework Eclipse Sprotty [53].
30 3.2. Graphical Language Server Protocol
In thefollowing, we describethe main concepts of theEclipse Sprotty architecture, which is essential forthe GLSP [53].
• SModel. The diagram is stored in agraph modelcalled SModel.The diagram’s elementsare organized in atree hierarchy and have the properties parent and chil- dren.Basedonthe model root (i.e. SModelRoot), elements can be searched within the tree throughtheir ID. All elementsofthe model inherit from SModelElement. An SModelElement consistsofaunique ID and atypetoreference its View.A View knows howtoturn agraph model element andits childrenintoavirtual DOM node. To use the client/server architecture of Sprotty,the graph model needs to be serializable.The schemaofanSModelElement is aserialized JSON type. Within the schema, cross-referencesare represented by the ID of theelementtobe referenced. Whenlooking at an edge, an SEdgeSchema referstoits source using the ID of itssource SNode.Finally,tocreate themodel out of thecorresponding schema, deserialization is taken over by an SModelFactory.
• Actions. Actions are executedonthe graph model and itselements. They are defined as JSON objectsand are transmitted between client andserver. From the model sourceorthe Viewer,actions are sentvia the action dispatcher.The action dispatcher takes the received action and converts it into acommand using the appropriate action handler. There aretwo differentwaysonhow to control the model. Firstisthrough alocal modelsource,whichdirectly changesthe modelon the client, and secondly through aremotesourcecontrolled by adiagram server.
• Commands. Commands takethe currentmodel,execute the operation on it,and return anew modeltaken up by the Viewer,whichinitiates anew renderingprocess. Commands are passed to thecommand stack,whichhas aredoand undostackin addition to thestacktobeexecuted. Thus, individualcommands can be repeated or undone. The execution stackcan be usedtomerge individual commands.This makes especiallysense in thecontext of amove command, where onlythe starting pointand endpointare of interest.
• Viewer. The Viewer is in chargeofcreating anew virtual DOMfrom the model. The information necessarytocreate the virtualDOM is storedinthe View of a modelelement. A View must be registered in the ViewRegistry so that the Viewer can look up the View,basedonthe ID of themodel element. Furthermore, it is possibletoadd eventlistenersoranimation to the Viewer usingits Decorators.
• Features. Features are supported by modelelements and describethe interaction between the userand the diagram element.Afeature contains theaction that is triggeredand the corresponding command thathas to be executed. Furthermore, afeature requiresasingleton Symbol as an identifiertocheckifamodel element supports this feature.AnSModelExtension can be added to store further informa- tioninthe model to support the feature.Additionally, listeners canberegistered
31 3. Web-based Modeling Tools
to listen to events thatexecute the interaction on theDOM elements. Finally,a Module is required to registerthe aboveinformation to theclientinfrastructure.
Figure 3.3 shows the communication between theuser,client, and graphical language serverwhile addingnew elements to thediagram. The client’s first message to theserver representsvarious requests fromthe Eclipse Sprottyframework base protocol, which, for example, request themodel and theboundsfrom the server. Thebounds are theposition (x, y) and dimension (width, height) of an modelelement. Then the developmenttool asksthe language server to transmit all available operations.The operationsreceived fromthe server are added to thepalette view of thedevelopment tools’diagram editor. Theycan then be usedtoadd new model elementstothe diagram. In afurther step, the usercreates anew node within the diagram. The client sends a create node operation withthe elementtypeand the location within the diagram to the server. Thismodifies the model and thelanguage serversends thenew modelbacktothe client using an update model action, which triggers the rendering of thediagram with thenew model. In another use case, theuser createsanewedge between twoexisting elements. A create edge operation is executedand sent to the language server. In turn, the server modifies the model and addsanew edge between thetwo,basedonthe sourceand target ID of the respectiveelements. After themodel has been changed, thenew modelissentback to the client,taking over the rendering.
Figure 3.3: Auser invokesaGLSP-basedcommunication between client andserver throughadding new elementstoadiagram [52].
32 3.2. Graphical Language Server Protocol
3.2.2 Featuresofthe GLSP In the following,webriefly describethe keyfeaturesofthe GLSP [52].
Requestand Update Model. The requestmodel action is sentasthe first message fromthe clienttothe graphical language servertoinitiate the communication between the twoand, at thesame time, requestagraphical model. The server responds to this client request, eitherwith a setmodel action or an update model action. The update model action is senttothe client after each modification of themodel on theserver. If the client does nothaveamodel, the update model action behaveslikeaset model action. If amodel already exists, the old model root schema isreplacedbyanew schema.
Operations Request. The request operation action is sentfrom theclienttothe servertorequest thelist of available operations.Operations are requests that change the model.The server,inturn, responds with a setoperation action. GLSPcurrently supportssix differenttypes of operations:
• Create node: Thisaction createsanew node within thediagram. Specifying the elementtype, location,and container within whichthe operation is to be executed.
• Create connection: Thisaction creates anew connection between two elements. The action transfersthe ID of thesource element as well as theIDofthe target element.Thisoperationcan be extended to createedges.
• Delete: Thisaction performsthe deletionofaspecific itembased on the ID.
• Changebounds operation: This action is used to change theposition or dimen- sion of an element.
ElementPop-up. As soon as theuser movesthe mouseoveranelement, the client sends therequest popup model action to the graphical language server to get detailed information aboutthe element.The server responds with a set popupmodel action to display the pop-up menu on the one handand to removeitinthe diagram editor on the otherhand.
Select. A select action is triggered as soon as theuser clicks on aselectableelement. The action can be handled locally by the developmenttoolorsenttothe graphical language servertorespond to aselection change.Furthermore, the server canchange the selection remotely and inform the client about this via the select action. Finally,the GLSPhas a select all action to selectordeselect allthe model elements at once.
Command Palette. The command paletteaction sentfromthe client to the server requests the available operations for oneormore selected elements. The serveruses the received IDstodetermine theavailable operationsand sends them back to the client with a set command palette action.
33 3. Web-based Modeling Tools
Reconnectand Reroute Connection. The reconnect connection action is sent fromthe clienttothe server to change either thesource element or the target element of an existing connection.The transmitted message contains theIDofthe connection, as well as theIDofthe new sourceand target elements. Compared to thedeletion of an existingconnection and theresulting re-creation of aconnection, reconnecting has theadvantage that theobjectidentityand the propertiesofthe connection are already on theserver. The reroute connection action changesthe existing route of aconnection, wherethe new route is transmittedasanarray of routing points.
3.3 Debug Adapter Protocol
The DebugAdapterProtocol(DAP) wasintroduced before the Language Server Protocol but follows asimilar approach. Duetothe differentAPIs of developmenttools, it takes significanteffort to implementadebugger for programming languages.The DAPaims to standardize thecommunication between the developmenttooland debugger and thus to make it possibletoimplement asingle generic user interface that supportsthe DAP on theclient-side and awell-specified protocol on theserver-side. Adebuggerthen implementsthe debugger logicofaparticular language alsofollows theDAP protocol. Thismakes it easy to integratedebuggers for differentlanguagesintoanIDE and re-use debuggers across IDEs. Sinceexisting debuggers maynot adoptthe DAP, the debug adapter shouldadaptexisting debuggers or runtime APIs to theDAP.Figure 3.4 shows on theleft side differentdevelopmenttools, where eachtoolintegrates theimplementation of adebuggeruser interface to support the language-specific debugger.Onthe right side, the developmenttools are using genericdebugger user interfaces. TheDAP-based tools are connected through adebug adapter, supportingthe DAPtothe language-specific debuggers. Thisreducesthe effort to support anew debugger considerably [4].
3.3.1 Architecture of the DAP The DAPwas designed before JSON-RPC wasreleased. Therefore, it uses itsown protocol, whichisverysimilartoJSON-RPC. Themessagesconsist of aheader and a content partseparated by acarriage return and line feed.The most importantdata types which are used by the DAPare Strings because theuser seesexactly this in the graphical userinterface. Thisallows an easy implementation of thedebug adapter. The debug adapter can either function as adebuggeritself or be connected to an external debugger. The DAPhas manyfeatures,but not all debugadapters support them as well. Each feature hasacapabilityflag, which lets the developmenttoolknowifadebug adapter supports this feature or not.Therefore, thesefeature flagsare summarized in theDAP under the interface Capabilities.Ifaflag does notexist, the developmenttoolassumes thatthe adapterdoesnot support this feature [4]. Sincethe DAPisnot stateless, the serverneeds to know all kindsofstates and sequences of what has happened. If the serverterminates,the debug progressonthe client-side is lost[4].
34 3.3. DebugAdapterProtocol
Figure 3.4: Communication between developmenttools and debuggers with and without DAP[4].
The DAPconsistsofthree typesofprotocolmessages. First, requests containing the command thatshould be executedbythe debug adapter and argumentsthatcarry the necessary informationfor the executionprocess.Secondly, responses thatact as acknowledgmentand return thegenerated informationfrom the executionprocess back to the developmenttool. Finally, events initiated by the debug adapterinform the tool about thecurrentstate of theexecution. An exampleofsuchanevent is the stopevent, which informs the developmenttoolthat theexecutionhas been stopped for some reason. Thismay be due to abreakpointoranexception.
Figure 3.5 shows the communication between thedevelopment tool,debug adapter, and aGNU debugger13.The communication is started by the user, creatinganew debug session.Subsequently,the developmenttoolsends the initialize request to the debug adapter. In theinitializationphase,the Capabilities are exchangedbetween theIDE and thedebug adapter.The debug adapterthen connects to the GNUdebuggerand startsthe debugger. In addition to the Capabilities,the initialrequestalso containsother useful information aboutthe developmenttool, suchasits nameorthe format of thefile paths (nativeorURI) used. As soon as thedebug adapter is ready to receiveconfiguration requests, it generates anew initializedevent to inform the developmenttoolabout its status. Due to this process,the adapter does not requireabuffering implementation for configuration information. After receivingthe initializedevent,the developmenttoolstarts sending
13https://gnu.org/software/gdb/
35 3. Web-based Modeling Tools
the configurationinformationtothe debug adapter. Theseare asequence of requests thatset thedifferent typesofbreakpoints, followedbythe configuration done request thatsignals thecompletion of theconfiguration process. Thebreakpoints are forwarded to the GNUdebuggerfor validation, and theresult is sentbacktothe developmenttool via the debug adapter.Afterthe successful completionofthe configurationprocess,the launch request follows,starting the debugger’sexecution. The debugadapter forwards the name of thefile to be debugged to theGNU debugger and runsthe execution.
Figure 3.5: Communication between thedevelopment tool,debug adapter, and debugger during the start of anew debug session following the DAP[4].
3.3.2 Features of theDAP In thefollowing, we representthe features of the DAPregarding thedebugging concepts introduced in Section2.3 [4]. All requests, responses, events,and data typesare clearly presented in theDebug Adapter Protocol specification14.
14https://microsoft.github.io/debug-adapter-protocol/specification
36 3.3. DebugAdapterProtocol
Execution Modes
After adebug session has been started and theconfiguration process has been executed, the client sends the launch request to the debug adaptertostart the debugger. This request contains debugger-specificinformation suchasthe debugger serveraddress or a stop on entryflag. The stop on entryflag informs theGUI that thedebugger will be stopped whenitenters thefile and before the first statementisexecuted. Theexecution mode can be started with or without debugging. Once thedebuggerisstartedand is in the stopstate,the debugger can be continued by using the continue request.Through a pause request sent by the client,the executioncan be stopped again.For thispurpose, thedebug adapter generates astop eventtoinform thedevelopment tool about thehalt of theexecution. After thedebug adapterwas successfully launched,the development tool sends a threads request to the adapterand starts listeningfor newthreadevents. All requests exchanged between thedevelopment tool and thedebug adapter during the debug sessionmust specify the corresponding thread ID. Depending on whetherthe debug adapter supports multiple threads or not,the debugger respondseitherwith all currently existingthreads or at least one (dummy) thread. To terminate the debug session, the developmenttoolsends a terminate request to the debug adapter to terminate thesession gracefully.Thisgives the debugger theabilitytocompleteall remaining tasks and finally ends thedebug session.Ifthe debugger continues to run,the developmenttooltries to terminate the debugger again,but this time it usesthe disconnect request, which terminates the sessionforcefully.
Steps
In order to step through theexecution, the debug adapterprotocolprovidesthe next request to run again for one step.The debug adapterrespondswith anew stop event, including the appropriate reason and threadID, after the step is complete. Using the step-in request, the debug adapter steps into afunction or method,ifpossible. Otherwise, the step-in request behaveslikeanext request. To reach alevel higherafterastep-in command, the clientsendsastep-out request to the adapter.
Runtime VariableI/O
The exchange of thevariables takes place using the variable request, whichreturns all or onlyapart of thevariables. Thechild variablesofavalue canweretrieved using the variable reference.The variablesreference relates to aspecific variable.Inadditionto displaying variables, they canalsobemodified.For this purpose, theDAP providesa set variable request in whichthe nameofthe variable and thenew value are senttothe debug adapter. In response, theadapter sends the new value and itsdatatypetothe client.
37 3. Web-based Modeling Tools
Breakpoints The DAPsupportsmost typesofbreakpoints.For eachtypeofbreakpoint, requests are senttothe debug adapter. Using the set breakpoints request, the developmenttool transmits all breakpoints thatexist forasingle source. Theadapter deletes all previous breakpoints forthis one sourceand then sets the breakpoints contained in therequest. The DAPalso supports function breakpoints. Thetransferredbreakpoints are validated throughthe debugger and sentbacktothedevelopment tool as theactual breakpoints via aresponse message. Thisistocommunicatetothe client if abreakpointcouldnot be setatthe defined position or if thebreakpointwas set to adifferentposition by the debugger. In addition to specifyinghit counts and conditions, exception breakpoints and data breakpoints canalsobetransferredvia the protocol. As soon as abreakpointishit duringexecution, the debug adapter creates anew stop eventand addsthe respective type of breakpoint(e.g. function breakpoint) to signalthe cause of theexecution’s halt.
Stack Traces In order to receivethe stacktrace of thecurrentexecution state, thedevelopmenttool can sendastack trace request to the debugger. The requestcontains argumentstofilter the returned stack frames. Thismeansthatonly those stack framesthatbelong to the threadspecified in therequest are returned. AuniqueIDidentifiesastackframe across all threads.This ID canbeused to obtainthe scopes of aframe using the scopes request or to restart theexecutionofaspecificframe. Thestackframe furtherstoresthe nameof the frame, typicallyamethodname, as well as theline and column of theframewithin the file. Additionaloptional properties, suchasthe sourceofthe frame,can alsobe transferred from thedebugger to thedevelopmenttool.
Exceptions Duringthe executionofaprogram, theremay occur exceptions.Inthis case, the debug adaptergenerates anew stop eventwith the corresponding reason(e.g. an exception). There are two waysanexceptioncan be processed and displayedbyadevelopmenttool. In thefirst, an output eventisgenerated after thestop event. Theoutput eventcan be usedtooutput asequence of characterstothe debug console. In the second variant,the developmenttoolsendsanexception info request to the debug adapter after receiving thestop event. Theresponsethatfollows is filledwithdetailed information about the exception that occurred. After thedevelopment tool hasreceivedthe exception info response, the informationcan be further processed and displayedonthe debug console.
3.4 Summary
To sum up the previous sections, LSP,GLSP,and DAPare protocols thatstandardize the communication between an IDE and alanguage-specific serverthat providesediting or debugging support. TheLSP separates the language-specific logicfrom the actual
38 3.4. Summary editor logic. Sincethe LSP is onlysuitable fortextual languages, theGLSP wasdefined to buildclient-independentlanguage servers forgraphical modeling languages. TheDAP allowsthe implementation of one generic debugger interface for adevelopment tool that can communicatewith differentdebuggers via debug adapters. The debug adapters can be reused across multiple developmenttools, whichsignificantly reducesthe effort to support anew debugger in different tools.
39
CHAPTER 4
Applying the DAPtoGLSP
In Chapter2,wediscussed whichfeatures amoderndebuggershould provide and how thesedebugging concepts canbeapplied to graphical modelingingeneral. Afterward, we introduced both the GLSP and theDAP in Chapter 3and showedwhichfeatures and advantagesthese web-based tools offer. In this chapter, we will discuss howtoapply the DAPtothe GLSP and integrateanew debugger for agraphicalmodelinglanguage. First, we will introduce theWorkflowModelingLanguage (WFML) and itscustomdiagram editor. Therequirements forthe debugger are then derivedfrom the WFML.Finally,we introducethe implemented debugger anddiscussthe featuresusing visualizations.
4.1Running Example: Workflow Modeling Language + DiagramEditor
The WFML1 wasdesignedbyEclipseSource in thecourse of thedevelopment of the Graphical Language Server (GLS) platform.The WFML is an executable/interpretable language andistherefore very well suitedfor thepurposes to developadebuggerfor graphical modeling languages.InSection 2.2, we discussed the components of whicha domain-specific language consistsand thatwere usedtodefine theWFML.The abstract syntax of the WFML wasdefinedusing theEcore Modeling Framework (EMF) [54]. The EMFisamodeling frameworkand code generation facilityfor generating tools and other applications based on astructured data model.The Java code generated from theEMF Ecore model wasintegrated into the server framework of theGLS platform. The concrete syntax wasdesignedusing thediagram framework Eclipse Sprotty,whichwealready presented in the course of theintroductionofGLSP. Thedefaultshapesofthe Sprotty framework can be adapted/extendedtofitthe requirements of theWFML. The WFML describes aworkflowwithin asystemororganization. Thisworkflowcan be aprocess consisting of asequence of tasks and decisions.The language consists of
1https://github.com/eclipse-glsp/glsp-examples
41 4. Applying theDAP to GLSP
task nodes,activitynodes, and edges that connect the nodes. Furthermore, it is possible to introducehierarchical structures within the WFML.Todoso, one can createnew diagrams, which are named according to the respective tasks. The metamodelofthe WFML shown in Figure 4.1 introducesthe relevant language constructs. The WFML metamodel extends theGLSPmetamodel2 which serves as the basic structurefor the GLS platform. Thelanguage constructs of theGLSP metamodel can be extended by the specific languageconstructs. Everyelementofthe model is a GModelElement.AGModelElement can have zero or an undefinedamount of GModelElement children. TheGLSP metamodelshows a GGraph class which extends the GModelRoot class. The GGraph class stores themodel,whichconsistsofEdges, TaskNodes,and ActivityNodes.ATaskNode can be furtherdividedintoamanualtask or an automated taskusing theproperty taskType.The type of an ActivityNode can be specified viathe property nodeType.The WFML distinguishes decisionnodes, merge nodes,fork nodes,and join nodes.The WeightedEdge class has aproperty probability and extends the GEdge class. The GEdge class has theproperties sourceId and targetId. Finally,aGEdge hasoptional source and target model elements.
Figure 4.1: The WFML metamodel extending the GLSP metamodel.
2https://github.com/eclipse-glsp/glsp-server/blob/master/plugins/org. eclipse.glsp.graph/model/glsp-graph.ecore
42 4.1. RunningExample:WorkflowModelingLanguage +Diagram Editor
In thefollowing, we presentthe modeling concepts of theworkflow language in detail: • Task. Atask describes aspecific task, which is to be executedduring the process run. The notation of atask is arounded rectanglewith the task name inside the border. Atask has aproperty duration to specify the time needed to executethe task. The WFML distinguishesbetween the following two tasks. –Manual Task. Amanual taskisexpected to be performed without any process executionengineorapplication. The duration for manual tasks is set to zero. –Automated Task. Aprocess engineexecutesanautomated task.The task is completed when the interpreter has executed the script defined forthe task. An automated taskrequiresacertainamount of time to complete thetask. The time needed is specifiedinthe duration property. The concrete syntax of automated tasks differs from manual tasks in that both have adifferentbackground color.Manual tasks are colored blue and automated tasks are colored gray. Besides, there is an icon next to thename of thetask,which either depicts an "A" for automated or by an "M"for manual. • ActivityNode. Activitynodes are control nodesused to coordinate the flows between other nodes.The workflowlanguagesupports the following four typesof activitynodes: –Decision node. Thisnodeaccepts exactlyone incomingflow and selects exactlyone outgoingflow from one or moreoutgoing flows. Whichofthe flows is taken depends on theevaluationofthe guardsatthe outgoingedges. The notation of adecision node is adiamond-shaped symbol with one ingoingedge and one or moreoutgoing edges. –Merge Node. Thisnodemerges multiple incoming alternateflowstoaccept asingle outgoingflow.Merge nodesare usedtogether with decision nodes. The notation of amerge node is adiamond-shaped symbol with one or more incoming edgesand one outgoing edge. –Fork node. Thisnodeaccepts an incoming flowand hasseveral outgoing flows on theotherside. Theincoming flowissplit into multiple concurrent flows to provide parallelisminworkflow diagrams. Thenotation of afork node is aline segmentwith one incoming edge and two or moreoutgoing edges. –Join node. Thisnodehas multiple incoming flows and onlyone outgoing flowand is usedtosynchronizeincoming concurrentflows. Join nodes are usedtogether with forknodes to support parallelisminworkflowdiagrams. The notation of ajoin node is aline segment with several incoming edges and one outgoing edge. • Edge. Edges are direct connections betweennodes and describethe furtherflow of theprocess. Thesourcenodeand target node of an edge must be in the
43 4. Applying theDAP to GLSP
same diagram as theedge. Weighted Edges have an additional probabilityand are evaluated duringruntime to determinewhichofthe edgeswillbetraversed. Weighted edges are used in thecontext of decision nodes. In thecurrentversion of the WFML,weightededges are the onlyway to define guardsfor decision nodes. Additionalguards canbeintegratedbyextending the relevant componentsofthe client/server frameworkoftheGLS platform.The notation of an edge is an open arrowheadline connecting two nodes.The graphical representation of weighted edges and standardedges is differentincolor. The standard edges are coloredin black,and theweighted edges are shown inblue color.
Figure 4.2 illustrates an exampledefinedwith the WFML.The example shows howthe individuallanguage concepts interactwitheachother duringthe brewingprocess of a coffeemachine. The taskwithout anyincoming edgesisconsidered thestarting point. The process starts when the machine’sbrew buttonrepresented through themanual task "Push" is pushed. Compared to the manual task"Push", the automated task"ChkWt" has an additionalproperty duration,whichspecifies the time needed to executethe task. The automated task"ChkWt"isresponsiblefor checking thewatertank level of the coffee machine and is connected to adecision node viaastandard edge. Thedecision node is recognizable by the number of incomingand outgoingedges. Thedecision node shown hastwo outgoing weighted edges, which are coloredinblue and are selected depending on therespectiveprobability. Depending on which weighted edge is selected,eitherthe manual task"RflWt" orthe automated task"WtOK" is executed. It should be noted thatinarealenvironment, the next stepisdetermined by the resultofthe previously executedmanual task"ChkWt". However, in the currentversion of theWFML,there is onlythe possibilityofmaking decisions based on the weighted edges’ probabilities. The manual task"RflWt" represents theprocess of refilling the water tank, while the automated task"WtOK" represents the outputonthe informationdisplayofthe coffee machine. Amerge node is usedtomerge alternativeflows. The merge node is representedbyanactivitynodewith twoincoming standard edges and exactlyone outgoingstandard edge. From the mergenode, theoutgoing standardedgeleadstothe automated task"ChkTp". Theautomated task"ChkTp" measures thebrewing unit’s currenttemperature and includesthe child diagram shown in Figure 4.3. The diagram to checkthe temperature of thebrewing unit consists of theautomated tasks "ReadSensors", "ProcessData", and "DetermineTp".Wewanttopoint outthatthe diagram is onlyan examplethatallows us to represent the hierarchicalstructure of theWFML.The tasks presented here for measuring thetemperature maydiffer fromthose of arealsystem. The "ChkTp"taskisfollowedbyafurtherdecision-making process. Inthis process, either themanual task"PreHeat"preheats the brewing unit to the required temperature or themanual task"KeepTp" keepsthe currenttemperature. After thedecision-making process hasbeen completed, the alternative flows are merged by anothermerge node. The transition to thelast task"Brew" is executedthrough astandard edge. Thistask is usedtofinally brewthe coffee. Sincethe manual task "Brew" has no outgoingedge, the brewingprocess ends.
44 4.1. RunningExample:WorkflowModelingLanguage +Diagram Editor
Figure 4.2: The WFML diagram editor with thebrewing workflowexample.
Figure 4.3: The WFML diagram to checkthe temperature of thecoffee machine.
Diagram Editor
The GLS platformcomes with abasicimplementation fordiagram editors. The diagram editor is partofthe client framework providedbythe GLSplatform and canbedeployed stand-aloneorintegratedintocustom web-based IDEssuchasEclipse Theia or VSCode. These custom IDEs can be adaptedusing extensions developedbythe communities of theIDEs. Thebasicimplementation of aweb-based IDE such as Eclipse Theia provides various workspace facilities(e.g. create, open,savefile, repeat/undo command, paste,
45 4. Applying theDAP to GLSP
copy, and cut).Additionally, onecan alsoreveal and hide various windowviews, such as thedebug view or theoutput console. Furthermore, throughthe integration of the diagram editor into theweb-based IDE,GLSP specific functions areintegrated into the IDE’sgraphicaluser interface. In thefollowing, we will introduce some of theavailable features of thediagram editor:
• Modification of thediagram view. The GLSPdiagram editor providesseveral featurestomodify the diagram.
–Center. Aligns thedesktop screentothe center of the diagram. –Export. Allowstocreate an SVGrepresentation of the diagram and save it in the same workspace as the model source. –Fit to screen. Rearranges theview of thediagram so that all elementsare visible. –Layout. The layout command aligns all elementsofthe diagram in an orderly manner. –Align. The align command realigns theindividualelements within the diagram. –Resize. The resize command allowschangingthe sizeofthe elements. The heightorthe width of theindividualelements canbeadjusted to the sizeofa selected element.
• Tool Palette. As already mentionedinSection 3.2 about thefeatures of GLSP, available operations canberequested from theserverutilizing the request operation action. Theobtained operationscan then be displayed via theSprottyframework in atoolpalette,asshown in Figure4.2 on theright. TheWFML diagram editor provides operations to createthe previously presented language concepts of theWFML.The design of thetoolpalettecan be individually adaptedtothe requirements of thelanguage. TheWFML tool palette has a selectonclick function represented by the mousepointer icon and delete on click functionrepresented by the erasericon.Toinsert an element into thediagram, theelementispickedfrom the tool palette (e.g. manual task),and added to thediagram by clicking on the desiredposition.
• HoverElements. If theuser movesthe mousepointer over theelementinthe diagram, apop-upappears, displaying detailed information aboutthe element (e.g. the durationofanautomatedtask).
• Command Palette. By right-clicking within the diagram, anotherpop-up appears, which offers theuseradditionalfeatures.Depending on whether theuser clicks on an existing elementorafree position within thediagram, theuser can either delete the existing element or create anew one. Furtherfeatures canbeaddedby extensions of the client or server framework and adapted to the languages used.
46 4.2. Requirements forDebugging theWorkflowModelingLanguage
• Useofthe Keyboard. Besides using themouse, individual features can alsobe controlled viathe computer keyboard. Deleting elementswith the delete keyisan example.
4.2Requirements for Debugging the WorkflowModeling Language
One of the aims of thiswork is to reuseexistingframeworksand parts ofthe graphical userinterfaceofthe Theia-debugextensionfor textuallanguages,thusminimizing the effort requiredtointroduce new graphical modeling language debuggers. In Section 2.3, we discussed the debuggingconceptsfor textuallanguages,and afterward,wediscussed howtotranslate theseconceptsfor debugging graphical modeling languages.Werealized thatthe basicfunctionalities needed for graphical modeling languages are very similarto those of thetextual languages and,therefore, the existing components canbereused. For this reason, we use the existing open-source Theia-debug extension3 fortextual languages, which can be integrated into the Eclipse Theia framework.The Theia-debug extension comes with ageneric graphicaluser interfacefor debugging features.The debugger user interface shown in Figure 4.4 offersvisual representations on digital control panelsto interact with the user. Thedebug view on theleft side of Figure4.4 includesvarious control commands and information views.Besides, there exists an additional debug menutab, which lists all available control commands.InSection 4.3 we will discuss the individualcontrol panelsand informationviews. Furthermore, the Theia-debug extension supports the DAP, and offersvariouscontribution points to adapt/extend the debugger facilities to therequirements forgraphical modeling languages. This way, the specific debug adapter developedfor theWFML willbeintegratedintoEclipse Theia. In the following, we will addressthe requirements fordebugging theWFML and howthe existing frameworks can be used to fulfillthem.
ExecutionModes
The user needsfunctionalities to start,pause, and stop theexecutionofthe model. Furthermore, the userrequiresagraphical user interface that can be usedtooperate thesecommands and display relevant information to the user.
Forthis purpose, we first need to look at theDAP in terms of whether language- specific information is relevantfor therequeststostart, pause,and stopthe execution. Secondly,wehavetoanalyzeifthe debug windowprovidedbythe Theia-debug extension can be reused. Finally,weneed an external debugger that is available on aremote server. Thisdebuggershould knowthe WFML languageconstructs and offer functionstodebug and interpret aWFML model.
3https://npmjs.com/package/@theia/debug
47 4. Applying theDAP to GLSP
Figure 4.4: The debugger GUI of theTheia-debug extension.
1. Language-specificdebugrequest data: Looking at theDAP andthe corre- spondingmessagestostart the debug session, one can see that they are independent of thekind of language used.The initially exchanged messages onlycontain in- formation regardingthe developmenttooland the debug adapter.This allows reusing the componentsfor startingthe debug sessionwithout investingmuchtime in adapting thecomponents.Furthermore, pausing the debug sessionand the pause request fortextual languages can be transferred to graphical modeling languages withoutany further adaptations. Forthis, the running thread’sIDispassed to theadapter,which pausesthe specificthread.Afterthe threadhas been paused successfully,the debug adapterfirst sends the response andthen astop event(with reason’pause’). Upon-receipt,the developmenttoolfirst requests all threads that exist at that pointoftime and then thestacktrace for the threadmentionedin the stopevent.Then the variablesfor thecurrentstackframe are requested.The receivedinformation is displayedvia the debug view.The developmenttoolsends the DAP’s disconnect request to terminate the debugger. The debug adapter sends the response, followedbyaterminate eventthatindicates that debugging of the debugger has terminated.
2. Debug windowofthe Theia-debug extension: The debugwindowand the containing items such as icons, menus, and furtherwindowsofthe Theia-debug extension allow theuser to interactwiththe debugger tools. Thesecomponents use ageneric approachthat supportsvarious textuallanguages.Since the components are not dependent of thesyntax or semantics of thelanguage, thesecomponents can be reused to support graphical languages.
48 4.2. Requirements forDebugging theWorkflowModelingLanguage
3. Language-specificdebugger: Forthe WFML debugger, aclient-server architec- ture is required thatallows the debug adapter to connect to the specific debugger and exchange messages. We assume that both the IDE and thedebuggerare on the same physical machine.Thus, we do nothavetoinclude the diagram filein the start request. We onlysendthe path of thefile to the debugger. In turn, the debugger must be abletoparsethe model,store it accordingly, and execute the model.
Steps The user should be abletostep throughthe model and execute one modelelementat atime.Before looking at which components canbereusedormustbeextended to implement thedefinedrequirementfor theWFML debugger, thequestionarises:"What does it mean to takeastep within the WFML?". As already discussed in Section 2.3, it varies fromlanguage to language, what it meansexecuting astep within the model.In the WFML,weuse astep to execute atask or to control theworkflow. Furthermore, the step-in and step-outcommands are required forhierarchy structures. If the step-in command is used on acomposite task, thechilddiagram should open,and the execution should stop at thefirst task in the child diagram. Using thestep-out command within the child diagram, should open theparent diagram and stop theexecutionbefore the next step.
In thefollowing, we analyze the DAPinterms of whether language-specific information is relevant for the requests to step,step in, and stepout. Besides,the language-specific debugger requires methods to step through amodel,step into achild model,and step out backtothe parentmodel.
1. Language-specificdebugrequest data: The components of the Theia-debug extension suitablefor this purpose are based on thethreadIDofthe executed debug session. The next request of theDAP transmitsthe threadIDtothe debug adapter, which in turn forwardsthe command to the debugger. The debugger performs astep and sends theinformationofthe new stack framebacktothe debug adapter, after thestep is completed.Subsequently,the debug adaptersends astopevent,including the received information to thedevelopmenttool. The DAPoffers requeststotransferstep-in and step-out information between the developmenttooland the debugadapter.These protocol messages depend on the ID of thecurrentrunning thread. To step into thechild model,the development tool sends the stepIn request to the debug adapter.The stepOut request forcesthe debugger to step backintothe parent model. The debug adapter then forwards the informationtothe debugger.
2. Language-specificdebugger: Forthe stepwiseexecutionofthe model,aconcept must be developed in the course of theimplementation of theWFML debugger, which executesthe individualmodel elementsone after theother. Themodel elementsshould be executedinthe order in which they are connected in the
49 4. Applying theDAP to GLSP
diagram by the edges. Theselection of an edge is performed randomlybasedon the specifiedweights. The debugger requires functionalitytostep into the child modeland start anew debugging process for thechild model.When the debugger is forcedtostep out of thechild model,the debugging processofthe child model should be finished andthe executionshould halt at thenextmodel element of the parent model. Besides, asolution must be found on howthe individualmodel elementscan be interpreted to finally execute the task. In Chapter 6, we will deal with this issueindetail and presentone solution.
Breakpoints Liketextual languages,wherebreakpoints can be set in thesource code,the usershould be abletoset abreakpointonaspecific modelelementinthe WFML diagram editor. To support hierarchical structures,eachworkflowisdefinedinaseparate diagramthat is storedinaGLSP modelschema. These modelschemas are treated independently in the graphical language serverofthe WFML.Itshould be noted thatthis allowsmodel elementsindifferentdiagramstohavethe same ID. Thus, breakpoints in aWFML model require areference to therespectivediagram in which theywereset.Abreakpointshould be visible after it has been set by marking thecorresponding element. In additionto the graphical renderingofthe breakpointwithin the diagram, it is alsonecessarythat a breakpointwindowisavailable within the debug window, as knownfrom conventional textual language debuggers. Thisadditionaldisplayofthe breakpoints makes sense because theuser not onlywants to seethe breakpoints within one diagram but alist of all breakpoints within the whole project.Finally,the breakpointwindowshould provide functions to enable and disable breakpoints.
To implement therequirements mentioned above, we first needtoanalyze which existingcomponents of the tools available can be reused and which ones have to be modified. On theone hand,the client framework of theGLS platformisrequired to implement the graphical modificationswithin the diagram. On theotherhand,the Theia-debugextensionisneeded,totakeoverthe managementofthe breakpoints and further to list all breakpoints in the breakpointwindow. At the same time,itisimportant to analyze if one of theexisting DAPrequests for setting breakpoints in the WFML can be reused.
1. Language-specificdebugrequest data: We first analyzed if theexisting proto- col messages for setting breakpoints in textual languages alsomeetthe requirements forgraphical modeling languages.InSection 3.3, we discussed sourcebreakpoints, functionbreakpoints, databreakpoints,and exceptionbreakpoints among thetypes of breakpoints supported by the DAP. Source breakpoints are set within the source code for textuallanguages and store thepathofthe sourcefile as well as the line on which the breakpointislocated. On theother hand,graphical modeling languages have no lines, but consistofconnected modelelements. Theelements of the WFML arebasedonthe diagram frameworkSprotty, which uniquely identifies
50 4.2. Requirements forDebugging theWorkflowModelingLanguage
modelelements via theirID. TheGLSP uses thedatatypeString forthe ID of modelelements, while the line in whichasource breakpointislocatedistransferred overthe DAPasanumber data type.This discrepancy between thedifferentdata typesand the differentrepresentation of elements preventedusfromusingthe set breakpoints request of theDAP forsourcebreakpoints.
Subsequently,welookedatthe setfunctionbreakpoints request thatexists for function breakpoints, whichare alsoprovidedbythe DAP. Function breakpoints compared to sourcebreakpoints are identifiedbythe name of amethod, whereas the property name is storedasaString data type.Model elements within the GLSP alsohave aproperty name,whichisstoredasString data type.This consistencyin the data typeswouldsuggest reusingthe set functionbreakpoints requests.However, function breakpoints are not defined forasingle source file but are valid throughout the entire project. In the WFML,certaintaskswith the same name maybe defined within one diagram or theentire project. Therefore, the executionmight encounterbreakpoints thatwere notmarked by the user. This would contradict the requirementsweidentifiedfor thedebuggertoset breakpoints on individual modelelements. Furthermore, the definitionofafunction correspondstoanentire workflowrather than asingle task. Thesame applies to other DAPrequests,such as exception breakpoints and data breakpoints, to send breakpoints to the debug adapter. Exceptionbreakpointspause theexecutionassoonasacertainexception is thrown.Databreakpoints interruptthe executionwhen the value of acertain variable changes. Furthermore,the data breakpoints and theexception breakpoints are transmittedtothe debug adapter without theunique affiliation to aparticular diagram.
Sincenone of theexisting requests canbeused for therequirements, aconceptmust be designed thatallows the setting of GLSPBreakpoints and theirtransmission to the debug adapter. Forthis purpose, the Theia-debug extension offersthe possibility to extend the protocol with custom requests. Therefore, anew request can be defined,whichtransfers the GLSPBreakpoints to the debug adapter.A GLSPBreakpoint requires,onthe one hand, apropertytostore the ID of themodel element for that abreakpointshould be set and,onthe other hand, apropertythat stores thesource,i.e., the path of thediagram in which the breakpoint is located. As mentionedinitially,model elementscan have the same ID in differentworkflows because eachworkflowisstoredinaseparateGLSP modelschema. Therefore, we needthe model element’s ID and thepathtothe diagram in which the model element wasdefined. Thisallows the breakpointtobeunambiguously assignedto one element.
2. Breakpointwindowofthe Theia-debugextension: The components of the Theia-debugextensionresponsible forthe managementofbreakpoints must be extended to support the newly defined GLSPBreakpoints.This alsoincludes the displayofbreakpoints withinthe breakpointwindow.
51 4. Applying theDAP to GLSP
3. GLSPextensionfor breakpoints: To implement thegraphicalrequirements forthe WFML debugger, theexisting client framework of theGLS platformmust be extended.InSection 3.2, we have already discussed thearchitectureofthe GLSP in detail and mentioned, among other things, features that are supported by modelelements. Forthe model elementsofthe WFML,tosupport breakpoints, anew breakpointfeature must be defined.The breakpointfeature is described in detail in Section5.2.Furthermore, additional actions and the corresponding commands within the client framework of theGLS platformmust be created to support the process of setting breakpoints. On the one hand,anaction is needed thatallows setting breakpoints and,onthe other hand, an action that removes those breakpoints fromthe model elements. Besides, actions and theirassociated commands have to be definedtoenable and disablebreakpoints. Anotherpoint is the extension of thecontext menu, which appears whenthe userright-clicks on amodel element.The commands foradding and removing breakpoints must be added to themenuand connected to the previously mentioned actionsfor setting and removingbreakpoints. Finally,the breakpointfeature requiresadecorator responsible for highlighting the model element’s frame (e.g.displayingthe frame in areddish color). All theseGLSP extensions have to be combinedinaseparate GLSPDebugModule to ensureeasy integration into theclientinfrastructure.InSection 5.2,the breakpoint decorator and the GLSPDebugModule are presentedindetail. 4. Language-specificdebugger: The WFML debuggershould be implementedso thatthe GLSPBreakpoints transmitted by the debug adapter canbestoredbased on thediagram source.Iffurtherbreakpoints are added during execution, the currentbreakpoints should be overwritten by the new ones. As aresult of running the model,eachmodel element must be checkedtosee if thereisabreakpointat thatposition.Ifthis is the case, furtherexecutionshould be stopped,and the user should be informed. As soon as theuser restarts theexecutionvia the development tool,the WFML debugger should continue at theinterrupted state.
StackTrace The user wantstoview the procedurecallsthat arecurrently on thestack. Therefore, a call stackwindowisrequired thatshows the order in whichthe nodes of theWFML are gettingcalled. The stackframe whichiscurrently being called is at thetop of thestack. Below is the stack frame, which called thecurrentstackframe.Atthe bottomofthe stacklies the top call workflowfromwhichthe underlying workflow’scall wasstarted. Besides, the userwants to see thecurrentstackframewithin the diagram. The model element,whichiscurrently executed and lies at thetop of thestack(i.e. the current stackframe), should be highlighted (e.g. agreenframe). As discussed in Section 2.3, the stacktrace in model debugging is strongly bound to theterms stepping in and stepping out.Since theWFML supportshierarchy and composition, thecall stackcan be usedto reflect these structures.
52 4.2. Requirements forDebugging theWorkflowModelingLanguage
Fortheserequirements,wefirsthavetoanalyze if the existing request for stack traces of theDAP can be reused. Second, we have to lookatthe componentsofthe Theia-debugextension, whetherthey canbereusedtocontrol and displaythe stack trace. Third, we have to integrate new actions in the GLSP to highlight thecurrentstack frame. Finally,the language-specificdebugger requires functionalities to deal with the hierarchical structures and to determinethe call stack.
1. Language-specificdebugrequest data: Forthe exchangebetween thedebugger UI of theIDE andthe debug adapter, theDAP offers the stack trace request, which we already introducedinSection 3.3. The interface for stackframesstoresthe nameofthe frame as aString data type andcontains an optional attribute source, which stores the frame’s location.
2. Callstack windowofthe Theia-debugextension: The existingcall stack windowofthe Theia-debug extensionand the corresponding componentsnecessary to determinethe stack trace will be used. This is possible sincethe representation in the call stack windowworks with Stringdatatypes. Thus, we needtosendthe IDs of themodel elements as aString data type to the development tool.
3. GLSPextensionfor currentstackframe: Forthe implementation of the graphical representation of thecurrentstackframe, theclientframework of the GLS platformmustbeextended with furtheractions. On theone hand,anaction and the associated command to set the currentstackframe is needed and, on the other hand, an actiontoremove thestack frame. In Section 5.2, we explainwhat actions and commands look like based on theaction and thecommand thatare necessary to add and remove breakpoints. Thecommand belongingtothe action checks whether themodel element is valid as astackframeornot.Amodelelement is valid as astackframeifitsupportsthe stack framefeature. The feature, as well as theactionsand commands, can be added to the GLSPDebugModule.
4. Language-specificdebugger: The WFML debugger requires aseparateprocess foreachhierarchy level of themodel,determiningthe currentstackframe at each step. Thus, the call stack can be filledwith the stack frames of therespectivemodel levels.When the executionofchild models hasfinished, the WFML debugger must jumpbackintothe process execution of theparent model andcontinuethe execution on the currentstack frame of the model nowpresent.
Runtime Variable I/O Whenthe model’s executionispaused,the userrequires aview wherethe variable values of thecurrentstack frameare shown. To implement these requirements,wefirsthave to analyzethe requests forvariables of the DAP. Second,wewill look at, howwecan reusethe variable view of theTheia-debug extension. Finally,the implementationsfor thelanguage-specific debugger will be derived.
53 4. Applying theDAP to GLSP
1. Language-specificdebugrequest data: In thecourse of representing the key featuresofthe DAP, we have already presentedthe variable request, whichissent to the debug adapter fromthe Theia-debug extension. Furthermore, variables in the DAPare defined by the name of the variable,the valueofthe variable, and thetypeofthe value.The variablesare sentfromthe WFML debugger, where thevariables are stored in termsofthe textual languages (e.g. Java)in which thedebuggerisimplemented. Therefore, aspecific mappingtoreuse the variable request forgraphical languages is not required. Thisaspect further allows reusing notonly existing components formanaging and displaying thevariables in the Theia-debug extension but alsothe corresponding protocolmessagesof the DAP. The debugadaptershould forward the variable request to the WFML debugger, which determines thevariables of thecurrentelement (e.g. duration of an automated task).The WFML debugger should then sendbackthe resultsvia the debug adapter, whichinturn uses theDAP’s set variable response to forwardthe variablestothe developmenttoolor, moreprecisely,tothe Theia-debug extension. The extension should be responsiblefor displaying thereceivedvariables in the graphical user interface.
2. Variableswindow of the Theia-debugextension: The Theia-debug extension hasavariable view,whichispart of thedebug view. As with thecall stackview, the variablesare alsopresented as Stringdatatypes. This allowsustoreuse the existing components for our requirements.
3. Language-specificdebugger: The WFML debuggerrequiresfunctionalities to parseand store variablesofamodel element.After each step or theoccurrenceof an exception, thecurrentvariable, as well as thecorrespondingvalues, should be sent to the developmenttoolvia the debugadapter.
Exceptions The user wantstobeinformedincase an exception occurs during theexecutionofthe modeland what caused theexception. This must be presented to the user, whousually onlyhas knowledgeofthe modeling language,inanunderstandable form. First, we have to analyze,how an exception can occurinthe model interpretation approach. Second,wewill look at thedebug console of theTheia-debugextension to displayexception information. Finally,wediscuss the language-specific debugger implementation.
1. Definitionofexceptionsinaspecificlanguage: In Section 2.3, we talked about thelevelsatwhichexceptions occurand howthey canbetreated. Looking at theWFML,the grammatical rules defined in theabstract syntax canbeusedto ensurethat errors areavoided when creating models, and thus only correct models are constructed. Nevertheless,errors mayoccur during runtime, or moreprecisely, in the case of theexecutionofthe synthesized artifacts (e.g. themodel schema). We mentionedinthe introductionofthe GLSP thatthe graphical modelisstored
54 4.2. Requirements forDebugging theWorkflowModelingLanguage
as aJSON object.Using this object, the model canbeparsed through theWFML debugger, and finally,the elements executedstep by step. In this parsing process, errorsmay already occur, which were caused by an incorrecttranslationofthe graphical modelintothe JSON format.During the execution, furtherexceptions can be triggered due to programming errorsinthe realdebuggerorthe frameworks used.
2. Debug console of the Theia-debugextension: Forthe implementation of exceptions, thecomponentsofthe Theia-debug extension canbeusedagain, since displaying of exceptions is usuallyasingleoutput on thedebug console. In Section 3.3, we discussed the possiblevariants for thetransferofexceptions via the DAP. In thefollowing, we go into moredetailabout the approachusing thedebug console for showing the exceptions to the user. Forthis purpose,wewouldliketotakeasan exampleasituationthat leads theexecutionofthe model into an error state. The WFML allowsdecision nodestobeused with both standard edges and weighted edges, of which the lattercontainacertain probabilityofbeing selectedduring execution. When runningthe model with standard edges,however, there is an error state of theexecutionengine, whichcan be attributedtothe factthat theexecution enginedid notfind anyprobabilitiesinthis situation and could not continuethe execution. The resulting NullPointerException is described in termsofthe language in whichthe debugger waswritten (e.g. Java forthe WFML debugger).This exception has to be catched and converted into domain-specific terms. In thecase of theexample,the outputshould containthe location (e.g.the model element) where theerroroccurred, the cause, and, if possible, suggested solutions.The WFML debugger should stop theexecution and transmit theexceptioninformation to the debug adapter,which, in turn, should generate astop eventinforming the developmenttoolabout the stopofthe executiondue to an exception. Through an output event, thedebug adapter should sendall informationprovidedtoitbythe WFML debugger to output theexceptioninthe developmenttool’s debug console.
3. Language-specific debugger: TheWFMLdebugger must detect the error and provide the appropriate exception handlers that canhandle theoccurringexceptions. Differentexceptions mayoccur dependingonthe language, whichiswhy exceptions handlersmust be adaptedtothe languagesused. Subsequently,the debugger must be abletostop executionafteranexceptionoccurs and sendthe respective informationsuchasthe call stack,variablevalues, and theexceptioninformation to the debug adapter. The debug adapter should onlyberesponsible for forwarding the informationitreceivesfromthe WFML debugger to thedevelopment tool.
Requirements Overview Table 4.1 gives an overviewofthe requirementsfor debugging theWFML.The cells colored in green represent theexisting components we can reuse, whereas thecells colored in redrepresent the components we have to implement/adapt. The shortcut
55 4. Applying theDAP to GLSP
"NA" stands for "No Action", i.e., no implementation or adaption is required. In thefirst column, therequirements mentioned aboveare listed. Thesecond column shows which componentswecan reusefrom the Theia-debug extension.The third column shows the requests and events that can be usedfrom the DAP. Thefourth column representsthe modification using theGLSPtointegrate graphical animations. The fifthcolumn shows the implementationsnecessaryfor theWFML debug adapter. Therefore, we will extend the vscode-debugadaptermodule4 to implement therequirements.The lastcolumn lists all requirementsfor thedebuggerimplementation.This part is the most affordable since we have to implementthe debugger from scratch.
Requirement Theia-debug ex- DAP GLSP Debug Adapter Debugger tension(GUI) (vscode- debugadapter) Start command view launch request open diagram connect to parse, execute, debugger,send and interpret model model Pause command view pauserequest NA forward pause pause execution request Stop command view disconnect request NA forward stop stopexecution request Step command view nextrequest NA forward step get next el- request ement, send element Step In command view stepIn request open child forward stepIn stepintochild diagram request model StepOut command view stepOutrequest open parent forward stepOut stepout of child diagram request model Breakpoints Extending the setGLSPBreakpoints add/remove& sendGLSP- stopexecution breakpoint view request enable/disable Breakpoints on breakpoint forGLSPBreak- breakpoints points Stack Trace callstackview stackTracerequest highlight responsestack sendstack trace current stack trace frame Variable variable view variables request NA response sendvariables variables Exceptions debug console outputevent NA response handle excep- exception tion
Table 4.1: Requirements forDebugging theWFML.
4.3 Workflow Modeling LanguageDebugger
Thissection introducesthe developeddebuggerfor theWFML.Weimplementedthe previously defined requirements and concepts to provide the userwith adebuggerthat supports the debuggingconceptswediscussed in Chapter 2.
Using theexample of amodel in theWFML introduced in Section4.1,wewantto presentthe featuresofthe WFML debugger. In Figure4.5,the web-based IDE containing the debug view window, whichwewereable to reuse from theTheia-debugextension, is shown.The debug view is furthersubdivided into acommand view,threads view,
4https://npmjs.com/package/vscode-debugadapter
56 4.3. Workflow Modeling Language Debugger call stackview,variables view, and breakpoints view. Within the command view,the followingbuttons are providedtocontrol theexecution:
• Play. Starts anew debug session andopens thediagram to be debugged.
• Continue. Starts the debugger to run again after the execution waspaused.
• StepOver. Starts the debugger to run again for one step.
• StepIn. Forcesthe debugger to step into achild diagram. If thereisnotarget to step into,the step-incommand behaveslikestep-over.
• StepOut. Forcesthe debugger to stepout fromachild diagram.
• Restart. Restartsthe execution of thedebug session.
• Stop. Stops theexecutionofthe debug session.
• Pause. Pausesthe executionofthe debug session. Only visible while the execution is continued.
Figure 4.5: The WFML debuggerispaused directly after startingthe debug session.
In thethreads view,the currentthread is displayed, and thestatus in whichthe thread is located. In Figure 4.5, thethreadwith the ID 1 hasthe status "Paused on Entry". Thismeansthatthe debug sessionwas started, and theexecutionstoppedimmediately before the first element. Stopping before the first elementisadebug adapterspecific setting, which is specifiedusing aboolean flag during theinitializationphase between the developmenttooland debug adapter. Amissing flag would mean an immediateexecution of the model after thestart of the debug session. However, if abreakpointwas set,the execution halts at thebreakpoints location (e.g. themodel element). As describedin
57 4. Applying theDAP to GLSP
Section3.3,the DAPalso supportsmultiple threads, which,however, for thesakeof simplicity, were left out of theWFML debugger,and thus only onethreadistreated.
After adebug session has been started,the user canstart to step throughthe model using the step commands.Figure 4.6 shows the debugger after takingthe first step, where thread1changedtothe status "Paused on Step". The informationabout the currentstackframe transmitted by the WFML debugger is nowclearly displayedinthe debug view.Underneath the threads view, thecall stackview is located, whichrepresents the ID of thefirst model element withinthe diagram. The ID of themodel element is displayedbecause,onthe one hand, theWFML is alanguage that supports the reuse of certaintasksinthe model and,onthe otherhand, because edges and activitynodes both have no labels.Nexttothe ID of themodel element,the sourceofthe diagram in whichthe element is stored is shown in the call stack view. Furthermore, the client framework of theGLS platformwas extendedtoadd functionalitytochange thegraphical representation of thecurrent stack frame within the diagram. Figure 4.6 shows that the modelelementthatrepresents thecurrentstackframe is highlighted through itsgreen frame.
Anotherrequirementfor theWFML debugger wastodisplaythe variablesofthe modelelements in areadable form. Forthis, the variable view,whichisshown in Figure 4.6, wasused.The variablesfor the currentelementare listed based on the variable name andthe associated value. Besides,ifthe mouse hovers over thenameofthe variable,the correspondingdata type is displayed.
Figure 4.6: The WFML debuggerispaused at thefirst model element andshows the informationcorrespondingtothe current stack frame.
58 4.3. Workflow Modeling Language Debugger
In addition to steppingthrough the model,the WFML debugger alsooffersthe feature to jumpintoachild diagram. Thischangesthe currentstackframeand the call stack. Figure 4.7 showsthe new call stack.Inthis case, the first task within thenewly opened diagram is on top of thestackframe of theparent model, as shown inthe call stack view.Inadditiontothe IDs of thetwo tasks, the sources of therespectivediagrams are shown.Anotherfeature of the debug view allowsopeningthe corresponding diagramin the editor by double-clicking on the respectivesource. Thus, the usercan easily switch between thediagrams.The new stack frame, recognizable by the green frame, has been movedtothe child diagram’sfirst element. In the furthercourse, theuser can usethe step-out command to jump backintothe higher-level diagram.The remaining tasks of the child diagram arecompleted,and the executionispaused again before the execution of thenextelementofthe parentdiagram. Insteadofusing the step-out command, the usercan also step to the child diagram’slast taskand return to the parent diagramvia a further stepcommand.
Figure 4.7: After thestep-in command wasexecuted, the debugger opensthe child model.
The user can right-clickonamodel element to addorremove abreakpoint. After that, the contextmenupop-upappears, whichisalso usedtoadd and remove elements. Figure4.8 shows the pop-up with the add breakpointand remove breakpointcommands. After thebreakpointhas been marked, it appears in thebreakpoints view, which is part of thedebug view. As in thecall stackview,the element’s ID is usedinthe breakpoints view to identify the breakpointuniquely.Basedonthe source, the user knows in which diagram thebreakpointislocatedand canimmediatelyopenthe corresponding diagram by double-clicking on it.Besides, theclientframework of theGLS platformwas extended as describedinSection 4.1 with further actions to highlightanmodel element with ared frame,ifitwas markedasabreakpoint. In Figure 4.9, twoelements from differentdia- grams were marked with abreakpoint, and thereforethe color of theframes changedtored.
59 4. Applying theDAP to GLSP
Figure 4.8: The context menuappears after aright-clickonone or moremodel elements and providesthe option to addand remove breakpoints.
Figure 4.9: After breakpoints were setinthe individualmodels, they appear in the breakpointwindowand the affected elementsare highlighted with ared frame in the WFML editor.
If abreakpointisset,itisenabled by default. However, the user maydisable break- points, so they are not included in determiningwhen the debugging process should stop next. Abreakpointthatisnolongerrequiredduring debugging can be deletedentirely. In Figure4.10, thepossible optionstoenable, disable,and removebreakpoints through
60 4.3. Workflow Modeling Language Debugger
Figure 4.10: Further commands to enableordisable breakpoints appear after right-clicking into the breakpoints window. the breakpointview are shown. By right-clicking into the breakpointview,anew pop-up appearsthatincludesthe commands to removeall breakpoints, enable all breakpoints, and disable all breakpoints. These commands apply for thewhole projectand alsoremove the red frame markingabreakpointonamodel element.Besidesenabling and disabling all breakpoints, it is also possibletoonly enable and disableasingle breakpointthrough the checkbox shown nexttothe ID of abreakpoint. Figure 4.11 shows twobreakpoints in theirrespectivediagrams, whereasthe first breakpointisuncheckedand thus disabled. The coloring of the element border in the diagram disappeared as well.
After theuser has set thebreakpoints and started theexecutionofthe model,the breakpoints are transmitted to theWFML debugger using the set GLSPBreakpoints request. If the debugger encounters abreakpointduringexecution, the furtherexecution is stopped, and thehalt of thedebuggeriscommunicated to the user.Figure 4.12 shows asituationwhereexactly this case occurred. The executedthreadchangedtothe status "Paused on Breakpoint". Thecall stackview shows the currentstackframe, and the variable view presents the corresponding variables. Within the diagram,the red-colored frame, whichmarksabreakpoint, haschanged to agreenframetodisplaythe current stackframe.Using thestep commands, the usercan step through theremaining elements of themodel or continuethe executionwith the continue command.
There mayalso be errorsinthe executionofthe model,soone of therequirements forthe WFML debugger wasthatexceptions are catched and presentedtothe userin an understandableform.For this use case, the example model waschanged suchthat anotheroutgoing edge wasconnected to atask.The modifiedmodel example canbeseen
61 4. Applying theDAP to GLSP
Figure 4.11: Disabling thebreakpointremovesthe breakpointfromthe executionprocess.
Figure 4.12: The WFML debuggerpaused on abreakpointand presents information about thecurrentstack frame.
in Figure 4.13. In addition to thepreviously existing edgebetween theautomated task ChkWt and adecision node,afurtheredgebetween the task ChkWt and theautomated task WtOK wasadded. TheWFML debugger parses all modelelements at thestart of thedebug session.The elementswill then be executedstep by step in the sequence they are connected. However, when the executionhits the ChkWt task, the debugger onlyexpects one outgoingedgefrom the task. Severaloutgoing edges are knowntothe WFML debuggeronly in the contextofactivitynodes. In thecase of atask having
62 4.3. Workflow Modeling Language Debugger several outgoingedges, thedebuggerisinanerrorstate and can no longer continue the furtherexecutionofthe model.The debugger changestothe status "Paused on Exception". An exception message is shown,whichprovidesthe location of theerror, the cause, andasuggested solution for theoccurrederror. As shown in Figure 4.13, the exception is output via the debug console. Theuser is informedthat alternativeflowsare not allowedonthe element andthat adecision node should be usedinstead. In addition to the outputofthe exceptioninthe debug console, the currentstackframeisshown graphically in thediagram as well as in thedebugview.
Figure 4.13: The WFML debuggerpaused on an exception andpresents the information about the current stackframeand the thrown exception.
In summary,the WFML debugger provides all the necessary features of amodern debugger, and graphical animations have supplemented these. In the course of the development, existing frameworksavailable for textuallanguages could be reused or adaptedfor therequirements of adebuggerfor graphical languages.Finally,the DAP wassuccessfully usedinconnection with theGLSP.For theinterestedreader, we refer to Chapter5for thedetailedarchitecture and implementation of theWFML debugger. In Chapter6,wewill define anotherDSML and implementadebugger for this new language basedonthe developedframework.
63
CHAPTER 5
Architecture andImplementation
Thischapter presents details on theimplementation of theWFML debugger. We first define the technologies used besidesthe web-based modeling tools,namelyEclipse Theia and InversifyJS. After that,weshowhow the main debugging conceptsdescribed in the previouschapter canbeimplemented. Finally,wepresentthe challengeswediscovered during the implementation of theWFML debugger. Mostofthe challengesnot onlyaffect the WFML in particularbut are alsorelevantfor other DSMLs. The implementation of theWFML debugger GUI adaption1 including the WFML debug-adapter, and the WFML debugger2 is availableonGitHub.
5.1 TechnologicalBackground
Thissection introducestechnical background information on thetwo frameworksEclipse Theia and InversifyJS usedinthe practical partofthis thesis.
5.1.1 Eclipse Theia Eclipse Theia3 is an open-source framework for creatingdesktop or web-based IDEs. To support both variantswith asingle source, Theia executes twoseparateprocesses. One of thesetwo processes is the front-end,representingthe client andresponsible for rendering the userinterface. The other process is the back-endrunning on Node.js4.The communication between thetwo processes works through JSON-RPC messagesthat are exchangedvia WebSockets5 or aREST API6 via HTTP7.Inthe desktop-based version
1https://github.com/EderH/graphicalLSP 2https://github.com/EderH/gml-interpreter 3https://theia-ide.org 4https://nodejs.org/en 5https://tools.ietf.org/html/rfc6455 6https://restfulapi.net 7https://w3.org/Protocols
65 5. Architecture andImplementation
Electron, however, both front-end and back-endrun locally.Onthe other hand, in a remote context, theback-endwouldrun on aremotehost.Theiahas been designed so thatasimple extension of thefunctionalities is possibleatany time. Forthis purpose, Theia supports two differentexpansion mechanisms, namely extensions and plug-ins. They maymakeuse of servicesand contribution points.
Extensions. Extensions allow easy access to existingextensions likethe Monaco Editor8 and adapt/extendittoone’scustom requirements.For the communication between theindividualextensions,the Theia framework uses dependency injection, which adds theextensions to theremainingcomponentsduring the build time. We willpresent Dependency InjectioninSection 5.1.2.
Plug-ins. Compared to extensions,plug-insdonot blockTheiacore processessince the code is running in aseparateprocess.Plug-inscan be installed/uninstalled during runtime withoutrecompilingthe whole IDE.This makessense in thecase of atool providerwho delivers afull custom solution, where customers canintegrate theirown plug-ins withoutaffectingthe stabilityofthe base tool. In order to contribute anew plug-in, Theia providesseveral APIs in theTheia API extension Theia-plugin.
Services. Services can be usedbycomponents of other extensions.Whereasplug-ins sticktothe APIs offered by the Theia extension forTheia-plugins.For example, one instance canprovide the SelectionService,sothatotherextensions can get an instance injected and use it. The SelectionService can be reused and extended to selectamodel element of the WFML.
ContributionPoints. In order to provideahookwithin extensionsfor othersto contribute, one should defineacontribution point. Thecontribution pointisdefined as an interface and can then be implemented by other extensions.Anexample of a contribution pointisthe OpenerService within the "Editor Extension", whichallows registering OpenHandlers. OpenHandlers are necessarytoopenanew widgetwithin the editor. The OpenHandler getsbound to thecomponentthrough acontribution provider. Acontribution providerisbasicallyacontainer for contributions where contributions are instancesofabound type.Inthis work, we bound the OpenHandler to the diagram editor to open thediagram widgets.
In order to createanIDE with Theia,apackage.json fileisrequiredthatcontains the package metadatalikename and versionaswell as theruntime and build-time dependencies.Thereare already various Node.jspackagesavailable, whichcan be integrated into custom IDEs andsubsequently adapted, depending on whichindividual requirements are placed on theIDE.
8https://microsoft.github.io/monaco-editor
66 5.1. Technological Background
Debug Extension Figure5.1 gives an overviewofthe Theia-debug extension architecture, focusing on the interaction between thedebug session and thedebug adapter. When auser decidesto debug an application they request aspecific debug configuration, which will be resolved by the debug adapter. In therunning example of the thesis,the launch configuration requests the WFML debug adapter.The launch configuration for theWFML is described in Section 5.2.4. The debug adapter canmodify apasseddebug configuration by adding, changing, or removing attributes.This alreadyhappensbeforethe debug adapteris started. The debug adapterisintegrated into the Theia back-end process (server). After the debug adapter is started anew debug session is initialized on thefront-end process (client). Thedebug session handles thecommunication between theclientand the server. The debug session managercontrols thedebug sessionsonthe client-side.This includes startinganew debug session for thereceiveddebug configuration, managing breakpoints across debugsessions, and terminating arunning debug session. Theclient session factory is usedtointegrate acustomimplementation of thedebug session.Ifanew debug adapterneeds to be added, thedebug contribution is used as acontribution point. Thecontribution providesall available debug configuration typesand tells the server-side architecture howtostart the debug adapter. The adapter factory is used to start thedebug adapter inside aseparatecontainer.After the debug adapter is started, the debug adaptersession getsstarted.The debug adaptersession worksasaproxy between theclientand the debug adapter itself. To customizethe debug adaptersession the adaptersessionfactory can be used. Thedebug service providesfunctionalityto configureand start anew debug adapter sessionbased on thedebug configuration. The debug adapter session managerisresponsibletomanage all available debug adapter sessionsand, therefore,tocreate or remove adebug adapter session from the running application [55].
Figure5.1: Communication between theTheiafront-end process (client) andthe Theia back-endprocess (server) in the Theia-debug extension(adopted from [55]).
67 5. Architecture andImplementation
Furthermore, the Theia-debug extension has ageneric debugger graphical userinter- face whichwereused.The debug windows are implemented as widgets, which canbe integrated into the existing Theia graphical user interface viadependencyinjection. These widgetsget theinformation from the debug session, whichinturn getsall the information fromthe debug adapter.This allowed us to manipulate the flowofinformationsothat informationabout graphical modeling languages can alsobedisplayedinthe debug windows of theTheia-debug extensiongraphical user interface.
5.1.2InversifyJS The open-source framework InversifyJS9 is alightweightinversionofcontrol (IoC) container for TypeScript and JavaScript applications. Inversifyinjects the different dependencies into the componentatcreation time. Listing 5.1 shows howInversify allows aclass to have adirectdependencyonotherclasses. In the example,this canbeseen in theclasses Katana, Shurikan,and Ninja.Eachclass that needs to be injectedmust be annotated with the @injectable decorator. Through the constructor,the twoclasses Katana and Shuriken are injected into the Ninja class, and subsequently, the methods of theinjectedclasses are accessed from the Ninja class. In Line25ofthe example,a container is created. The container API providessomehelpers to resolvemulti-injections and ambiguous bindings. Furthermore, there are additional decoratorslike @inject and @postConstruct.The @inject decorator marks theclassestobeinjected within the constructor or variable declaration. However, this is onlynecessaryfor interfaces, since an identifiermust be defined forthem.Onthe other hand, classeswork withoutthis identifier becausethe TypeScript compilergenerates themetadata for it.The @postConstruct decorator can be usedtoannotateclass methods. These methods are then executedafter an object hasbeeninstantiated, but before anyactivationhandler has been executed. Thisis useful if initializationlogic should be performed after the constructor wascalled, but the componenthas notyet been initialized. Besides, other useful featuresprovidedby Inversifyare used in the course of Eclipse Theia. It is advantageous to familiarize yourself withthe basic featuresofInversifyJS before using Eclipse Theia.
9https://github.com/inversify/InversifyJS
68 5.2. Implementation Details
1 import {Container ,injectable ,inject }from "inversify"; 2@injectable () 3 class Katana{ 4 public hit () { 5 return "cut !"; 6} 7} 8@injectable () 9 class Shuriken{ 10 public throw () { 11 return "hit !"; 12 } 13 } 14 @injectable () 15 class Ninja implements Ninja { 16 private _katana :Katana; 17 private _shuriken: Shuriken; 18 public constructor(katana :Katana, shuriken :Shuriken) { 19 this ._katana =katana ; 20 this ._shuriken=shuriken ; 21 } 22 public fight(){return this ._katana .hit (); }; 23 public sneak () { return this ._shuriken .throw (); }; 24 } 25 var container = new Container (); 26 container .bind
5.2Implementation Details
Thissection provides implementation details about thepracticalpartofthis thesis.It demonstrates howthe client framework of theGLS platformcan be extended to add the graphical requirements derived in the previous chapter.Furthermore,wepresentthe contribution points to implement new debuggersinTheiafor further graphical modeling languages.
5.2.1GLSPExtensionsfor Breakpoints The client framework of theGLS platformoffers contribution points to extend the existingfunctionalities with further actions.For theimplementation of thegraphical representationofthe debug features, it wasnecessarytointroducenew actions. Lines 1-5 in Listing 5.2 shows the structure of the AddBreakpoint action, which is triggered as soon as theuser setsanew breakpointonanelement. Theelements selectedbythe user are passed to theconstructor of theaction. In Lines 6-27, thecorresponding AddBreak- pointCommand is listed. Command injections are created viadependencyinjectionand should takethe respectiveaction as an injected constructor parameter.Commands must define astatic constant KIND,whichisused to map an action kind. Commands further consistofthe methods execute, undo,and redo.The AddBreakpointCommand extends the abstract class SystemCommand,whichisaspecial subtype of the Command class. There are other subtypes like the ResetCommand, PopupCommand, HiddenCommand, and MergableCommand.Compared to theother commands, the SystemCommand is not
69 5. Architecture andImplementation
placedonthe command stack.This means that SystemCommands cannot be influenced by redo and undooperations.
1export class AddBreakpointAction implements Action{ 2 static readonly KIND= ’addBreakpoint ’; 3kind =AddBreakpointAction .KIND ; 4constructor(readonlyselectedElements: SModelElement[]) {} 5} 6@injectable () 7export class AddBreakpointCommand extends SystemCommand{ 8 static readonly KIND= AddBreakpointAction .KIND; 9constructor(@inject(TYPES .Action) public action :AddBreakpointAction){super ();} 10 11 execute(context :CommandExecutionContext ): CommandReturn{ 12 const index =context.root .index ; 13 for (const selectedElementofthis .action .selectedElements){ 14 const element =index .getById(selectedElement .id); 15 if (element && hasBreakpointFeature(element )) { 16 element.breakpoint = true ; 17 } 18 } 19 return context .root ; 20 } 21 undo(context :CommandExecutionContext ): CommandReturn { 22 ... 23 } 24 redo(context :CommandExecutionContext ): CommandReturn { 25 ... 26 } 27 } Listing 5.2: The action and thecorresponding command for addingbreakpoints to model elements.
The execute methodinLine 11 receives aparameter of thetype CommandExecu- tionContext.The CommandExecutionContext stores themodel root through which the modelelements canbeaccessed using theID. Furthermore, the contextcontains the ModelFactory,whichconverts the serializable modelschema into themodel representation. Within the executemethod,one can iterate over theselected elementsand subsequently checkwhether the model element is an elementthat supportsthe breakpointfeature or not. Listing 5.3 shows the BreakpointElement that extends the SModelExtension to add additional propertiestothe modelelement. Regardingthis work, we addedabreakpoint flagtoidentify amodel elementasabreakpoint. Using the hasBreakpointFeature func- tionpresented in Listing 5.3, the model element is verifiedfor whether it supports the breakpointfeature. If this is thecase, the function returns a BreakpointElement where the breakpointflag can be set or removedinthe execute method. After theactionis finished, the modelrootisreturned.
70 5.2. Implementation Details
1export const breakpointFeature =Symbol( ’breakpointFeature ’); 2 3export interface BreakpointElement extends SModelExtension { 4breakpoint : boolean ; 5} 6 7export function hasBreakpointFeature(element :SModelElement ): element 8isSParentElement&BreakpointElement { 9 return element instanceof SParentElement && element .hasFeature(breakpointFeature ); 10 } Listing 5.3: Model element extension for thebreakpointfeature.
Furthermore, we implemented thefollowing actions and theircorresponding com- mands:
• RemoveBreakpointAction and RemoveBreakpointCommand:Responsible for remov- inganactivebreakpoint.
• AnnotateStackAction and AnnotateStackCommand:Responsible for annotating a model elementascurrentstack frame.
• ClearStackAnnotationAction and ClearStackAnnotationCommand:Responsible for removingthe annotation of thecurrent stackframe from amodel element.
• DisableBreakpointAction and DisableBreakpointCommand:Responsible for remov- ingthe graphical representation of an existing breakpoint. Thebreakpointisnot deleted fromthe breakpointview.
• EnableBreakpointAction and EnableBreakpointCommand:Responsible for restoring the graphical representation of an existingbreakpointafter the breakpointwas disabled.
Finally,weneeded a stackFrameFeature,whichcan be supported by modelelements. Forthis, we expanded the model element by a current flag.The AnnotateStackCommand, ClearStackAnnotationCommand,and the StackFrameDecorater checkwhether the model element supportsthe stackFrameFeature and can be represented as acurrent stackframe.
5.2.2 GraphicalRepresentations After abreakpointhas been set,itshould be recognizable by achangeinthe graphical representation.The responsibleclass BreakpointDecorator is showninListing5.4. This class implements the IVNodePostprocessor interface to manipulateanexisting node. The decoratemethodchecks whetherthe element is abreakpointand sets the model element’s CSS class breakpoint.The modified VNode will be returned, the model rendered, and the graphical change is made visibletothe user.
71 5. Architecture andImplementation
1@injectable () 2export class BreakpointDecorator implements IVNodePostprocessor{ 3 4decorate(vnode :VNode ,element: SModelElement ): VNode{ 5 if (hasBreakpointFeature(element) && element .breakpoint){ 6setClass(vnode ,’breakpoint ’, true ); 7} 8return vnode ; 9} 10 11 postUpdate (): void {} 12 } Listing 5.4: The BreakpointDecorator class to modify theCSS style of amodel element annotated withabreakpoint.
Furthermore, we implemented the StackFrameDecorator to highlight amodel element as thecurrentstackframeinthe graphical representation.With the StackFrameDecorater, the class current is set to true instead of theclass breakpoint,asinthe BreakpointDecorator.
5.2.3 GLSP Debug Module Listing 5.5 shows the glspDebugModule to whichthe commands and thedecorators for the graphical modification of themodel areadded. Forthispurpose, anew dependency in- jection container is created which can be injected into the language-specific diagram editor.
1 const glspDebugModule = new ContainerModule((bind ,_unbind ,isBound) => { 2configureCommand({ bind ,isBound},AnnotateStackCommand ); 3configureCommand({ bind ,isBound},ClearStackAnnotationCommand); 4configureCommand({ bind ,isBound},AddBreakpointCommand ); 5configureCommand({ bind ,isBound},RemoveBreakpointCommand ); 6configureCommand({ bind ,isBound},EnableBreakpointCommand ); 7configureCommand({ bind ,isBound},DisableBreakpointCommand ); 8bind(TYPES .IVNodePostprocessor ).to(StackFrameDecorator).inSingletonScope(); 9bind(TYPES .IVNodePostprocessor ).to(BreakpointDecorator ). inSingletonScope (); 10 }); 11 12 export default glspDebugModule ; Listing 5.5: The glspDebugModule,tointegrate theGLSP actionsintothe client infras- tructure.
5.2.4 Debug Adapter Contribution The Theia-debug extension providescontribution points to add anew debugadapter to the web-based IDE easily.Toconnect theWFML debug adaptertothe Theia- debug extension the class AbstractVSCodeDebugAdapterContribution is usedthat inherits from DebugAdapterContribution.InSection 5.1, we have already discussed contribution points within the Eclipse Theia framework.The DebugAdapterContribution servesasa contribution pointtoconnect theWFML debug adapter extension with theTheia-debug extension. The debug-adapter is integrated into theback-endprocess of theTheia-debug extension and communicates through WebSockets with the front-end.
72 5.2. Implementation Details
Forthe implementation of thedebug adapter, we usedthe existing npm-modules vscode-debugadapter10 and vscode-debugprotocol11,whichsimplifies the development of newdebug adapters.Inorder to contribute to the debug-related contribution points, adebug adapterextension requires apackage.json,whichcontainsthe contributions specific to debugextensions.Likeany other extension,the package.json declaresthe fundamental properties likename and versionofthe extension,ascan be seeninListing 5.6. In thedebuggers section of thecontributes section thedebuggerfor theWFML is defined with the attribute type as "workflow-debug". The user cantakethe debug type as areference in launch configurations. Theoptional attribute label can be usedtogivethe debug type apropername whenshowingitinthe userinterface. The program attribute defines the relativepath to thedebug adapterthatimplements thedebug protocol. If the path to the debug adapter is not executable, theoptionalattribute runtime provides an appropriate runtime [57]. The configurationAttributes attribute section contains theschema for launchconfigu- rationarguments specific to the debugger. Thisschema is used to validate the launch.json and support IntelliSense and tool tipwhen editing the launch configuration.The useris instructed to specify the absolute pathtothe diagram to be debugged. Onecan specify whether thedebuggershould stopthe sessionbeforeexecuting the first model element [57].
1 { 2 "name": "theia-workflow-debug", 3 "version": "0.1.0", 4 ... 5 "contributes":{ 6 "debuggers": [{ 7 "type": "workflow-debug", 8 "label": "Theia Worflow Debug", 9 "program": "./out/workflow-debug.js", 10 "runtime": "node" 11 "configurationAttributes": { 12 "launch": { 13 "required":[ 14 "program" 15 ], 16 "properties": { 17 "program":{ 18 "type": "string", 19 "description": "Absolute path to adiagram.", 20 "default": "${workspaceFolder}/${file}" 21 }, 22 "stopOnEntry": { 23 "type": "boolean", 24 "description": "Automatically stopafter launch.", 25 "default": true 26 }, 27 }, 28 }, 29 }, 30 ... 31 }] 32 } 33 } Listing 5.6: package.json fileofthe WFML debug adapter
10https://npmjs.com/package/vscode-debugadapter 11https://npmjs.com/package/vscode-debugprotocol
73 5. Architecture andImplementation
Please notethat the detailed specification of thepackage.json is partlyremoveddue to space limitations. It can be foundinthe code repository12.
Figure 5.2 shows thelaunchconfiguration for theWFML example introduced in Section 4.1. Thelaunchconfiguration is stored in thesettings.json file. Theconfigurations section shows partsofthe attributes mentionedearlier. The requested debugadapter hasthe type "workflow-debug" and is used to launchthe debugging process.The "stopOnEntry" flag is set to true to haltthe executionbeforethe first elementofthe model. The program attributeshowsthe path to the modeltodebug, namely"example1.wf".
Figure 5.2: The launchconfiguration of theWFML example.
5.2.5 Communication between the Actors In Figure 5.3 the communication between theuser,development tool,WFML debug adapter, and WFML debuggerisshown.Beforestarting the debuggingprocess theuser sets abreakpointonthe modelelementwith the ID "task1". Afterthe user invokesthe debugging processthe debug adapter getsstarted and theinitialize phase between the developmenttooland theWFML debug adapter begins. During theinitialize phase the capabilities are exchanged. Afterward, theconfiguration phasestarts,inwhichthe developmenttoolsends the GLSPBreakpoints to the WFML debug adapter. When the configuration phase has finished the launch request starts the debugging of the model. The WFML debug adapter connectstothe externalWFML debugger and sends thepath of thediagram to debug. Furthermore, the WFML debug adapter sends thebreakpoint withthe ID "task1"and the associated pathofthe diagram to the WFML debugger.
12https://github.com/EderH/workflow-example-debug-adapter
74 5.2. Implementation Details
Figure 5.3: Auser invokesthe DAP-basedcommunication between thedevelopment tool, WFML debug adapter, andWFML debugger during thedebugging of aWFML diagram.
In afurther use case, the userinvokesastep on theGUI of thedevelopment tool, which in turn sends the next request to the WFML debug adapter. The WFMLdebug adapterinforms theWFML debugger about therequest by sending a step command. The WFML debuggerperforms astep and responds with thenextmodel element in the diagram. The response includes thediagram pathand the ID of thenextmodel element.Furthermore,the variables of themodel elementare includedinthe response.
75 5. Architecture andImplementation
In this use case,the model element has alocal (i.e. "0" for local and"1" for global) variable "duration"that is an Integerdatatypewith the value "20". Thelast rowofthe response showsthe stack trace. The stack trace in the example consistsofone stack frame, namely "task0". When theWFML debug adapter receives theresponseastopped eventgetsemittedfor "thread 1" and thereason "step". As aresult,the developmenttool requests all available informationfor thementionedthread. This includesinformation about thestacktrace and thevariables. The developmenttoolthen displays thereceived informationinthe appropriate windows of theGUI. In thelast use case, theuser invokesacontinue request sentfromthe development tool to theWFML debug adapter. The WFML debug adapter forwardsthe request to the WFML debugger by sending the continue command. The WFML debuggercontinues theexecution till theend of themodel and sends the end command backtothe WFML debug adapter. The WFML debug adapteremits a terminated eventtoinform the developmenttoolthatthe debugging process hasfinished. Finally,the WFML debug adapter emits an exited eventand exits fromthe running developmenttool.
5.3 Challenges
In thissection, we discuss some of thechallenges of implementing theWFML debugger. The challengeswere identified while working with the differentframeworksfor textual and graphical languages used in thepractical part. Theconceptswehavedeveloped to solve these issuesapply not only to the WFML but alsotothe debuggingframework for graphical modeling languages in general.
Text Editorvs. Diagram Editor The combination of theDAP developed for textuallanguages with theGLSP developed forgraphical modeling languages presented us with various challengesduring develop- ment. To be abletowrite or view sourcecodeatall, eachIDE requires aso-called text editor.The editor providesone with various actions to edit the sourcecode. The Theia-debug-extension,used for theimplementation of theframework wasdeveloped for use in connection with textuallanguages.Asaresult, atexteditorisused to open and edit sourcecodefiles within this component. The text editor usedisthe so-called Monaco Editor13,whichwas created by Microsoftinthe course of thedevelopment of VSCode and whichisnot suitable for editing graphical modeling languages.
In contrast,the GLSplatform providesanextendable diagram editor for creating, displaying,and editing models, whichmust be extended for aspecific modeling language. In thecourse of thedevelopment of theWFML debugger, we hadtothink of aconcept thatwould allowustointegrate theDiagram Editorofthe GLSplatform into the debug session componentofthe Theia-debug extensionand thus replace the Monaco Editor.
13https://microsoft.github.io/monaco-editor
76 5.3. Challenges
In thefollowing, we presentone solution: In the first step, we foundout thatthe Monaco Editorisfirmly anchored in thedefaultimplementation of thedebug session component, which is whythis componentbecame unusable for us. If the debug session’s defaultbehaviorisnot sufficient, theTheia-debugextension provides acontribution pointtointegrate acustomimplementation of thedebug session.This contribution pointiscalled DebugSessionContribution and consistsofthe debug type forwhichthe debug sessioniscreated and a DebugSessionFactory,whichcreatesthe specific debug session.Using this contribution point, it waspossibleinafurther step to create acustom GLSPDebugSession.Insteadofthe Monaco Editor we integrated the GLSPDiagramEditor via dependencyinjectionintothe custom GLSPDebugSession.Through this solution, the modeltodebug will be opened at thestart of thedebug session viathe newly integrated diagram editor and can thus be animated during thedebug session.
Consistencybetween Diagram Editor and BreakpointView Window Synchronizing the diagram editor and thebreakpoints view wasanotherchallengewe faced whenmanaging GLSPBreakpoints.Onthe one hand, it should be possibleto add and remove breakpoints via the diagram editor while ensuringthe correct listingof breakpoints within the breakpoints view.Onthe other hand, thecommands to enable, disable,and removebreakpoints are available to theuservia the breakpoints view.Due to the graphical representation of thebreakpointinthe form of thered-colored frame, it wasnecessarytoinform the diagram editor about thecommands executedvia the breakpointview. This required atwo-way communicationbetween thecomponents of the Theia-debug extension and the client framework of theGLS platform. In theMonacoeditorfor textuallanguages,the editor responds to an editormouse eventand then transmits the position of thebreakpointtothe BreakpointManager of theTheia-debugextension. TheinterfaceIEditorMouseEvent14 is used to listen to the mouseevent.Whenever abreakpointisremovedfromthe breakpointview,the Theia-debug extensioncallsthe editortoremove thebreakpointdecoration.Tochange the decorationthe interfaceIModelDeltaDecoration15 is used. We were not able to reuse anyofthese components requiredfor the communication between theMonaco Editor and theTheia-debug extension, since we usethe diagram editor provided by theGLS platform. In thefollowing,wepresentthe solutionfor addinginteraction behaviorbetween the diagram editor and thebreakpoints view.
The first direction -fromthe diagram editor to thebreakpointviewcomponent-can be managed using the GLSPTheiaSprottyConnector.The GLSPTheiaSprottyConnector bridges thegap between GLSP dependencyinjectioncontainersand aspecific connection client from theTheiadependencyinjectioncontainer.Thus, the GLSPBreakpointManager can be injected into the GLSPDiagramManager to extend the default BreakpointManager
14https://microsoft.github.io/monaco-editor/api/interfaces/monaco.editor. ieditormouseevent.html 15https://microsoft.github.io/monaco-editor/api/interfaces/monaco.editor. imodeldeltadecoration.html
77 5. Architecture andImplementation
implementation of theTheia-debug extension. The GLSPDiagramManager is responsible forcontrolling and managing thediagram editor. Via the connector, themethods of the GLSPBreakpointManager can be accessed within the client framework container of theGLS platform, andthus, breakpoints canbeadded or removedinthe diagram. The GLSPBreakpointManager is then responsible for listing theavailable breakpointsinthe breakpointsview.
The second direction-fromthe breakpoints view componenttothe diagram editor - can be simply accomplished using thenew breakpointactionsdescribed in Section 4.2. In order to use these actions within the breakpointcomponents of the developedframework, access to the action dispatcher of theGLS platformisrequired. We were abletosolve this issue by filtering all existingdiagram widgetsfrom the application shellcontaining an action dispatcher.Finally,the breakpointactions can be triggered via the action dispatcher of theindividualdiagram widgets. The actions, in turn, modify themodel and thus change thegraphical representation of the breakpoint.
ModelInterpretation In Section 2.1, we presented the model interpretationapproachusedinthe course of model-drivendevelopment.This approachaims to interpretthe individualmodel ele- ments and to execute thetask or process thatthe model element represents. ADSML consists of differentabstract syntax elements that have differentexecutionbehavior. Therefore, we needed to develop aconcept that would allow the debugger to execute thesedifferenttypes of model elements.Besides, we had to make sure that the behavior of themodel elementscouldchange in thefuture,oradditionalelements are added to the DSML.Inthe following, we would liketopresentthe solution to the issue described above.
In thecourse of theliterature researchconcerninginterpreters,wecame across the visitorpattern[58], which belongs to the behavioral design patterns [59,60]. The visitor design patternshows howtoseparatethe structure of an object hierarchy fromthe behavioroftraversals overthat hierarchy.Figure5.4 shows the conceptional architecture of thevisitorpattern.The visitor pattern consists of thefollowing concepts.
• Visitor. The visitor interface or abstract class defines aset of visitingmethods in whichconcreteelements of an object structureare passed as arguments. If the language in whichthe program waswritten supportsmethodoverloading,these visitingmethods have the same name, but the type of parameter that is passed differs.
• Concrete Visitor. Every concrete visitor must implementall visit methods declared in the abstract visitor. Eachvisitorisresponsible fordifferentoperations.
• Element. The interface element declares amethodtoacceptavisitor. This methodshould have onlyone parameter, whichhas the visitor interface as the type.
78 5.3. Challenges
• Concrete Element. The concrete elementmust implement the accept method. The taskofthis methodistoredirectthe call to the visitor’s methodcorresponding to the currentelementclass.
• Client. Theclientisthe consumer of theclassesofthe visitorpattern. It usually represents acollection or other complexobjects. The client can accesselements and instructthem to accept avisitortoexecute the associated operation.
Figure 5.4: Architecture of thevisitor pattern[61].
The visitor pattern applied to therunning example of this thesisisshown in Figure 5.5. The client is the specific WFML debugger that we implemented.The WFML debugger hasaparser thatreadsthe model fromaJSON object and stores it in corresponding data structures (e.g. TaskNode, ActivityNode, Edge). Subsequently,the model elements are executedbased on theirconnections to eachother. The currentmodel element to be executedbythe debugger acceptsthe WorkflowInterpreter.The WorklfowInterpreter represents aconcretevisitor and implements thevisitor interface. The visitor interface declares its ownvisit methods fortask nodes, activitynodes, and edges. In the Work- flowInterpreter class, thesevisitmethods are overwritten, and theconcreteoperations are implemented. The classesused to parse and store the modelare extendedbythe accept method.
79 5. Architecture andImplementation
Figure 5.5: The visitor pattern applied to therunning WFML example.
Thissolution for themodel interpretation approachallows easy adaption to the behaviorofindividualmodel elementsinthe future by rewriting the visit methodof the element. Besides, addingnew typesofmodel elementstothe DSML and itsdebug- ger can be done withoutmucheffort. The onlyextensions necessary are creatingnew concreteelements and addingthe corresponding visit methods to the WorkflowInterpreter.
80 CHAPTER 6
Evaluation
The debugger for graphical modeling languages described in chapters4and 5was developedbasedonthe existing WFML.This chapter introducesthe second DSML used, fromwhich, in addition to theexisting requirements, we derivenew onesand evaluate the implemented framework to see whether it can be applied to this newlydefinedlanguage. With this, we want to ensurethe reusabilityofthe framework for other languages and domains.
6.1 State Machine Modeling Language
The StateMachine Modeling Language (SMML) is an executable/interpretable language basedonthe concepts of finite-state machines. Astate machine is afinite machine when it canbeassumed that the number of states is finite. The SMML consistsofthe following language constructs: states, state transitions, and actions.
Astate is adescriptionofthe system’s status thatiswaiting to execute atransition. In thecontext of the SMML,wedefinedthree differentkinds of states. Simple State models asituation during whichsome invariant condition holds. The notation of asimple state is representedasarectanglewith rounded cornersand the state’s name inside the rectangle. Theothertwo kindsofstates are so-calledpseudostates. The Initial Pseudostate is thestarting pointofastatemachine and thesource of asingle transition to asimple state. There canbeatmost one initial state within adiagram. An initial state is represented as asmallsolid filled circle.The Final Pseudostate is astate in a sub-state machine that signifies that theexecutionofthe sub-state machine hasbeen completed. Asub-state machine is adecomposition mechanism that allows factoring of common behaviors and theirreuse.Astateofasub-state machine inherits all the behavioractions andtransitions of thecomposite state. Afinalstate is represented as a circle surroundingasmall solid filled circle.
81 6. Evaluation
Astate transition is atransitionbetween two states. This transition is executed when the defined logical conditions,events, or inputs are fulfilled. Actions determinethe output of afinite-state machine, which takesplace in acertain situation. TheSMML onlysupportsactions thatare triggered through an transition eventand are performed duringastate transition.
Similar to the WFML, we use the EMF to define the abstract syntax of theSMML. The generated Java classes areintegrated into theserverframework of theGLS platform. Figure 6.1 shows the metamodel of theSMML.Aswith the WFML,the SMML metamodel extendsthe GLSP metamodel1 integrated into the GLSplatform.Inthe SMML,the GEdge class is extended by the Transition class having theproperties event and action. The State class extendsthe GNode class and has theproperties name and kind.The kind propertyspecifies thetypeofstate.The SMMLdistinguishes between initialState, simpleState,and finalState.
Figure 6.1: The SMML metamodelextending the GLSP metamodel.
Furthermore, we use the client framework of theGLS platformand the underlying diagram framework Sprotty to define theconcretesyntax of the SMML.The GLSP diagram editor will be extended to fit therequirements for the SMML. Figure 6.2 shows
1https://github.com/eclipse-glsp/glsp-server/blob/master/plugins/org. eclipse.glsp.graph/model/glsp-graph.ecore
82 6.1. StateMachine ModelingLanguage
the result of integratingthe newly defined SMML into the GLSplatform.The tool palette in the diagram editor consists of three nodes:simple state, initialstate,and finalstate. Atransitioncan be usedtoconnect thestates. Theshown example model constructed with theSMML illustrates aBank Automated Teller Machine (ATM)top-level machine. Basedonthe transitionconditions, thestate machine changesbetween states. The Bank ATMisinitially turned off. After the machine is turned on, the ATMperforms a startup action and enters the Self Test state. If thetest fails, theATM goesinto OutOfService state, otherwise,there is atriggerlesstransitiontothe Idle state. In this state, theATM waitsfor customer interaction. The ATMstate changesfrom Idle state to ServingCustomer state whenthe customer inserts abankingcard in theATM card reader. The transition from ServingCustomer state backtothe Idle state couldbetriggered by a cancel eventasthe customer could cancelthe transactionatany time.The same applies to thetransitionfrom ServingCustomer state to the OutOfService state that is triggered by the failure event. When theATM requires maintenance the transition fromthe Idle state to the Maintenance state could be triggered by the service event. If themaintenancefails theATM statechanges in the OutOfService state, otherwise another triggerless transition leads theATM into the Self Test state. Finally,the turn off eventcan be triggered in the Idle state and the OutOfService state to shut down theATM andchange to the Off state. The ServingCustomer state is acomposite state with thesub-state machine shown in Figure 6.3. The sub-state machine consists of the sequential states CustomerAuthentication, SelectingTransaction,and Transaction.Those states have atriggerlesstransitiontochangeintothe next state. After thetransactionis finished another triggerless transition changes theATM state back to the Idle state.
Figure 6.2: The SMML diagram editor integrated into theEclipse Theia framework.
83 6. Evaluation
Figure 6.3: The SMML sub-state machine for the ServingCustomer state.
6.1.1 Requirements forDebugging the State Machine Language In Section 4.2, we derived the requirements foraDSML debugger based on thedebugging conceptswediscussed in Section 2.3 andimplementedthe WFML debugger. In afurther step, we takealook at howthe developedframework can be reused fromthe WFML debugger, to implementanotherdebugger for the SMML.
Before we derive the requirements fordebuggingthe SMML,wewouldliketodiscuss the main differences between theWFML andthe SMML.The WFML differs fromthe SMML mainly because thetransitionfrom one element to the next is not donethrough simple edges, but by event-driventransitions. To controlthese transitions, the debugger GUI needs an input field to interactwiththe user.The further execution of theSMML debugger then takes place viathe eventcontrol of theuser.Furthermore, the states of the SMML are unique within the diagram, and multiple usages, as knownfrom the task nodes of the WFML,are no longer possible. However, this does not affect the debugger, since we use the ID of themodel element andthe path to the diagram in which the modelelementislocatedfor theunique identification. Finally,compared to theWFML, the SMML hasasingle initial state within astate machine, whichisintendedasthe startingpoint for theexecution.This means that thedebuggerdoesnot have to look for the model element that does nothave an incomingedge, but canuse thestate of the type "initialState". The final statemeans an endpointwithin asub-state machine. The debugger no longer has to checkwhether the state has an outgoing edge, but knows from the state type thatitisa"finalState".
84 6.1. StateMachine ModelingLanguage
Similar to the WFML debugger, we alsowanttoprovide the userofthe SMML with adebuggerthat has thebasic features of amoderndebugger. Therefore, we discuss the defined requirements introduced forthe WFML debugger in Chapter 4and consider howthe SMML affectsthese requirements.Inthe following, we analyzethe existing componentsofthe WFMLdebugger, whether they can be reused and howthe new requirements canbeimplemented.
ExecutionModes The user needsfunctionalities to start,pause, and stop theexecutionofthe model. Therefore, the user requires agraphical user interfacethatcan be used to operatethe individualdebugging features and to output relevantinformation to the user. By defining another language, we do notexpect anymodificationsofthe generic graphical user interface providedbythe Theia-debugextension.However, aseparatedebug adapter for the SMML is required,but the existing logic of theWFML debug adapter can be reused. The SMML debugger must be abletoparse, execute,and interpretthe new language constructsaccordingly. In the following, we analyze howthe developedcomponentsfor the executionmodes in theWFML debugger can be applied to theSMML. Applyingthe WFML debugger to the SMML: Likethe WFML debugger, the debug sessionisstartedinthe developmenttool, which in turn, sends the file path of themodel sourcevia the debug adapter to theSMML debugger. The only difference between theWFML and theSMML is the different fileextensionofthe modelsource.Sincethe protocoltransfers the path to the file in aString data format,the onlything to dealwith is the changedfile format at thedebugger- side. To pauseorstop the debugger, theprotocol, and thecomponentsofthe Theia-debug extension, use the threadIDofthe debug session.Thus, an entirely language-independent conceptfor startingadebugsession is available.
Steps The user should be abletostep throughthe model and execute one modelelementata time.The WFML usessimple connectionsbetween modelelements whereas astate in the SMML hasseveral transitions that are triggered through transition events.During the debuggingprocess, theuserwants to trigger theseeventsbymanually selecting them to determinethe furthercourse of theexecution. Thus, the userrequires adialoginputfield thatlists the events available for the currentstate and further allowsthe usertoselect one of thelisted events. During thetransitionfrom one state to another state, actions mightbeexecuted. Hierarchystructures are also supportedbythe SMML,whichmust be handled by the SMML debugger. Finally,the userwants to be informedabout the course of all transitions that were already performed. Forthis purpose,the debug window should be extended by another view where thecurrentevent flow(e.g. turnonevent triggeringthe transitionfrom the Idle state to the Self Test state) isdisplayed. In the following, we discuss the steps necessary forimplementing therequirements mentioned above.
85 6. Evaluation
1. Language-specificdebugrequest data: The DAPdoesnot provideany existing requests thatcan be usedtotransferthe available state events between thedebug adapterand thedevelopment tool. However, as with the GLSPBreakpoints,new custom requests and events between theTheia-debugextensionand the debug adapter can be introduced. It is necessary to introduceanew protocol eventthat transmits all transitions available for thecurrentstate to the developmenttool. Before this, themodel execution must be interrupted using astop event. After receivingthe information, the developmenttoolisincharge of openingthe input field, presenting the received transitionevents, and waiting forthe usertoselect one of them. As soon as theuserconfirms theinput, arequestwhichsetsthe event should be sentfromthe developmenttooltothe debug adapter and further forward the selected eventtothe SMML debugger. Using theobtained information, the SMML debugger should continuethe execution and sendbackthe new eventflow to the development tool’sevent window.
2. Integration of an eventwindowintothe Theia-debug extension: Forthe implementation of thetransitionevents, newcomponents must be integrated into the existing debuggingframework.Acomponent is required, where information about theeventspossible for thenexttransitionreceivedfrom the SMML debugger can be stored,and thatcan be usedtolist the events in the inputdialogwindow. Forthis, aclass GLSPEvent should be implemented,whichconsistsofattributes to store auniqueID, the model element forwhichthe eventisavailable,the event name, and thepathtothe diagram source. Furthermore, the Theia-debugextension must be extended to integratethe eventwindow. Using dependency injection, additional views can be injected into the existing debug viewwindow. Thus, the eventflow of thecurrentdebug session receivedfromthe SMMLdebugger can be listed.
Breakpoints Liketextual languages,wherebreakpoints can be set in thesource code,the usershould alsobeable to set abreakpointonaspecific element in the SMML diagram editor. We expect no differences concerningbreakpoints between the twolanguagesWFML and SMML since breakpoints are stored language-independent basedonthe ID of themodel elements. In thefollowing,weanalyze howthe developedcomponentsfor breakpoints in the WFML debugger can be applied to theSMML.
Applying theWFML debugger to theSMML: The GLSPBreakpoints were defined independently of thelanguage in usesinceonly the ID of themodel element is stored. Thecomponents formanaging, displaying,and transmitting the breakpoints to the debug adapter were alsoimplementedindependently of the language in use. The request fortransferring the GLSPBreakpoints fromthe developmenttooltothedebugadapter onlystoresthe model element’s ID and the path to the diagram file. The actions andcommands defined within the client
86 6.1. StateMachine ModelingLanguage
framework of theGLS platformexecute the operationsbasedonthe ID of themodel element.The graphical animation of thebreakpointwithin the diagram is based on theimplementedbreakpointfeature. Anymodel element in anew language can support this feature.Todescribethe style of themodel elementsand the representation of thebreakpointweuse CSS.Incase thegraphicalrepresentations of anew language do not have frames, breakpoints canstill be easily integrated. Therefore, it makes no differencehow the syntaxofthe element wasdefined.
StackTrace The user wantstoview the procedure calls thatare currently on thestack. Therefore, acall stackwindowisrequired thatshows the order in which the nodes (e.g.states, transitions) of theSMML are getting called. BothWFML and SMML support hierarchy structures that can be displayedvia the call stackview. In the following, we analyze how the components forstacktraces inthe WFML debugger can be appliedtothe SMML.
Applyingthe WFML debugger to the SMML: The representation of the currentstackframeinthe call stack viewalsotakes place viaaString data type. The SMMLdebugger determines the currentstackframe and transmits the ID of the model element as aString data type to the debug adapter. The debug adapter forwardsthe received informationvia the DAPtothe developmenttool. Thus, using aString data type to display and transfer thestackframe we are independent of thelanguage in use.
Runtime Variable I/O Whenthe model’s executionispaused,the userrequires aview,wherethe variable values of thecurrentstackframe are shown.The model elements ofthe SMML have different variablesthan the model elementsofthe WFML.Thus, atransitionhas thetwo variables eventand action,whichmust be represented accordingly. In thefollowing, we analyze howthe developedcomponents forvariables in theWFML debugger can be applied to the SMML.
Applyingthe WFMLdebugger to the SMML: The components forvariables window were developedindependently of thelanguage used and can be reused forthe SMML debugger. The variable attributes(e. g. name, value,type) are transferred between the debug adapter and thedevelopment tool as aString data type and are thereforekept very generic. This makesthe exchangeindependent of thelanguage used.The debugger is responsible for storingthe variablesofthe elementsinthe corresponding data typesduring parsing. Whenever avariable request is executed,the debugger converts the attributesfor therespectivevariable into Strings andtransmits allexisting variables to the debug adapter. Thedebug adapter then redirects thevariables to the development tool.
87 6. Evaluation
Exceptions The user wantstobeinformedifanexceptionoccursduring the execution of the model and to what causethis is due.Thesemustbepresented to the user, whousuallyonly has knowledgeofthe modeling languageinanunderstandable form.Inthe following, we analyze howthe developed components forexceptions in theWFML debugger can be applied to theSMML.
Applying theWFML debugger to theSMML: The implementation of the Theia-debug extensionaswell as theWFML debug adapter implementation can be reused forthe SMML.Exceptions thatoccur duringexecutionmustbeadapted to the SMML so thatusers who are only familiar with this modeling language understand the informationreceivedfromthe debugger. Therefore, newexception handlers must be implemented at theSMML debugger to handle errors specificto the SMML language.
RequirementsOverview Table 6.1 gives an overviewofthe requirements fordebugging theSMML.The cells colored in green represent the existing componentswecan reuse, whereas thecells colored in redrepresentthe components we have to implement/adapt.The shortcut "NA"stands for "No Action", i.e., no implementation or adaption is required. In thefirst column,the requirements mentioned above are listed. The second column shows whichcomponents we can reusefrom the Theia-debug extension. In thistable, we already expected to reuse the componentsdeveloped for theWFML,and therefore some requirements are highlighted in green. The thirdcolumnshows the requests and events that can be usedfrom the DAP. The fourthcolumn representsthe modificationusing theGLSP to integrategraphical animations. The fifthcolumn shows theimplementations necessary forthe SMML debug adapter. We expect to reusethe componentsdeveloped for theWFML debugger. The lastcolumn lists all requirements forthe debugger implementation. Since the language constructs of the SMML are differentfrom the WFML,this part requiressignificant adaption and is themost affordable.
88 6.1. StateMachine ModelingLanguage
Requirement Theia-debug ex- DAP GLSP Debug Adapter Debugger tension (GUI) (WFMLdebug- ger) Start command view launch request open diagram connectto parse, execute, debugger, send andinterpret model model Pause command view pauserequest NA forward pause pauseexecution request Stop command view disconnect request NA forward stop stopexecution request Step command view nextrequest NA forward step get next el- request ement, send element Step In command view stepIn request open child forward stepIn stepintochild diagram request model StepOut command view stepOut request open parent forward stepOut stepout of child diagram request model Breakpoints Extending the setGLSPBreakpoints add/remove & sendGLSP- stopexecution breakpoint view request enable/disable Breakpoints on breakpoint for GLSPBreak- breakpoints points Events Adding event setGLSPEvent NA send stopexecution viewfor request,eventFlow GLSPEvent, on event GLSPEvents, request, response dialog input GLSPEvents event GLSPEvents, field response event flow StackTrace call stackview stackTrace request highlight responsestack send stack trace current stack trace frame Variable variable view variablesrequest NA response sendvariables variables Exceptions debug console output event NA response handleexcep- exception tion
Table 6.1: Requirements forDebugging theSMML.
6.1.2 Implementation
We implemented theSMML debugger based on therequirementsdescribed previously.In the following, we shortlydescribethe SMML debugger features by showing illustrations of thedebuggingprocess within the web-baseddevelopmentenvironment.
The examplediagram in Figure6.4 shows the BankATM model introduced in the previoussection. Thedebug session is already started and paused on the Self Test state markedthroughthe green frame of thestate’s representation. On the leftside of the developmenttool, the debug view is displayed, where the viewsand commands known fromthe WFML debugger are reused. Again,the threadview showsthe currentstatus of theexecution. Thecall stackview displaysthe currentstackframe, and thevariables view shows the state variablesand the corresponding values. Additionally,the debug view shows the newly developedeventsview on thebottom, where thesteps taken so farare represented. From theinitialstate,the debugger went on through the default eventtothe next state Off.Afterwards,the turnoneventtriggered the transition to the currentstate Self Test. From this point, the user canclickonthe step command, and anew dialog window appears. The opened dialog windowshown in Figure 6.5, asksthe usertoselectone of the listed events to trigger thenexttransition. As longasthe windowisopened,the
89 6. Evaluation
Figure 6.4: The SMML debugger is paused at thestate Self Test and presents thecurrent stackframe information.
Figure 6.5: The SMML debugger is paused at the Self Test state, waitingfor theuser to selectatriggerevent forthe next transition.
execution is paused as represented through thethreads view.When the userconfirms the selectedevent,the executioniscontinued,and the SMML debugger movesontothe next state. In Figure 6.6, thethreadispausedatthe state Idle,and within the events view, the lastselectedevent default.
90 6.1. StateMachine ModelingLanguage
Figure 6.6:The SMML debuggerispaused at the Idle stateafter executing thedefault transitionfrom the state SelfTest.
Likethe WFML,the SMML alsosupports hierarchical structures where theuser can step into sub-state machines. To demonstrate this use case,the ServingCustomer state representsacomposite state. When the debugging processispaused at the ServingCustomer state, theusercan use the step-in command to open thecorresponding sub-state machine.The sub-state machine forthe ServingCustomer state consists of one initial state,one finalstate,and severalsimple statesin-between.InFigure 6.7, the SMML debugger opened thediagram for the ServingCustomer state machine,and the execution is paused at the CustomerAuthentication state. In the debug view,the changed call stackisshown,wherethe CustomerAuthentication lies on top of the ServingCustomer frame.The usercan jump between the diagrams by clicking on thediagram source within the call stack view. In theeventsview,the steps taken within the sub-state machine, including the new source, are illustrated.
An importantpointtoconsider with hierarchical structures in the contextofthe SMML is the inheritance of thetransitions fromthe compositestate to the sub-state machine. Theinheritance in case of the ServingCustomer compositestate is shown in Figure 6.8. In addition to the default eventtogofromthe CustomerAuthentication state to the SelectingTransition state within the sub-state machine, both the cancel eventand the failure eventofthe ServingCustomer state are listedinthe input dialogwindow. Thisinheritance affects all state transitions of thesub-state machine.
To get backtothe parent statemachine,the usercan either use the step-out command or step to theend of thesub-statemachine untilthe finalstate has been reached. Using another step command, theusergetsbackintothe parentstate machine.
91 6. Evaluation
Figure 6.7: The step in command forcesthe SMML debugger to step into thesub-state machine.
Figure 6.8: An SMML sub-state machine inheritsthe transitionsofthe calling composite state.
92 6.1. StateMachine ModelingLanguage
As described in theprevious section’s requirements, GLSPBreakpoints can alsobeset using theSMML debugger. Figure6.9 shows three breakpoints within the BankATM diagram. Again,inthe breakpoints view on theleft,all breakpointswithin the project are listed. The knownfeatures from theWFML debugger to enable, disable,and remove breakpoints are also available with the SMMLdebugger.
Figure 6.9: SMML states are markedasbreakpoints and listed in thebreakpointwindow.
Finally,Figure 6.10shows ause case where an exception is thrown during theruntime. In this case,the target ID of thetransitiontriggered through the turnoff eventwas changed. Thiscouldbecausedbyamodeltransformation error or aparsingerror. When the SMML debugger tries to execute thetransition, the target element with the ID ThrowException cannot be found.The corresponding exceptionisdisplayedinthe debug console in aform themodeler can understand. In thedebug view, thethreadispaused due to an exception, and all necessaryinformationlikethe currentstackframe, the variables, and theevent flowisshown. The implementation of theSMML debug-adapter2 and theSMML debugger3 is available on GitHub.
2https://github.com/EderH/graphicalLSP 3https://github.com/EderH/gml-interpreter
93 6. Evaluation
Figure 6.10: The SMMLdebuggerispaused duetoanexception and presents the informationabout the currentstackframeand the thrown exception.
6.2OpenProblems
Thissection discusses theproblems we faced duringthis thesis and that have notbeen solved. First, the extensionofthe DAPregardingthe newly defined protocol messages and second thecommunication between the debug adapter and thedebugger.
6.2.1 Extensionofthe DAP As aresult of the implementationofthe GLSPBreakpoints and the GLSPEvents,we defined custom requests to send the breakpoints and events from thedevelopment tool to the debug adapter. However, the data transmission does not take place basedonadefined standard, as knownfrom other DAPmessages. In this work, however, we were onlyable to identify the request forsetting GLSPBreakpoints as alanguage-independent request. Boththe WFML and theSMML canuse this request.The request for GLSPEvents is not usableinthe context of the WFML but could be reused in other languages because we do notuse language-specific attributes. Graphical modeling languages that require some formofuser-interaction could use this request and control thefurtherexecution. An exampleofthis would be alanguage foragame where theuser interacts with agame character and instructsthe character in which direction to move.Nevertheless,most of theDAP protocol messagescan be usedtoimplementamodern debugger for graphical modeling languages.From our pointofview,itmakes no sense at this stage to define anew protocol to standardize theexchange of GLSPBreakpoints.However, one might consider whether to makethe DAPmore generic regarding breakpoints. An interface could be defined whichuses optional attributes. The differenttypes of breakpoints then onlyuse theattributesthatthey needtotransmit the breakpoints between the
94 6.3. Interpretation of theResults developmenttooland the debug adapter. It should be noted,however, thatthis solution stillprovidesawell-structured overviewofthe individualbreakpoint types. Future experiments should implement furthergraphical modeling languages as well as additional debuggingfeatures(e.g. multiple threads, modify variable). If furthercustom requests hadtobedefinedduring the work, anew evaluation of theDAP should take place and,ifnecessary, it should be discussed whetheraseparateprotocolfor debugging graphical modelinglanguages shouldbedefined.
6.2.2Communication between Debug Adapter andDebugger Server In this work, we have implemented acustomdebuggerfor both WFML and SMML. When starting the debug session, the debug adapterconnectstothe debugger and starts exchanging messages.This exchange between the debug adapterand the DSML debugger does nottakeplace according to astandardized schema. Thisisbecausethe graphical modeling languages in use areself-defined and therefore do not have agenerally known standardasabasis. Forthe purposes of this work,however, it wasnot necessaryto establish aseparateprotocolfor exchanging messagesbetween thedebug adapterand the debugger. The focusofthis work wasmainly on the communication between the developmenttooland debug adapter via the DAPand the generic graphical user interfaces of thedevelopment tool. If thegraphicalmodelinglanguages and thedebuggers implementedare made acces- sibletoabroader community,one canconsider whether aseparateprotocolbetween the debug adapter and thedebugger shouldbedefined.
6.3 Interpretationofthe Results
In this section theresearchquestionsposed in Section 1.3 are answered basedonthe evaluation results presentedinSection 6.1.
RQ1: What shouldadebug adapterprotocol (DAP) look like to meetthe require- ments of graphicalmodeling languages? To answerthis researchquestions, we performed the followinganalysis steps:we translated the debugging conceptsfor debugging textuallanguages into thecontext of debugging graphical modeling languages. Furthermore, we derived the requirementsfor debugging the two case studyDSMLsand thus gained an understanding of howthe DAP should look like to support graphical languages.The main requirements foradebug protocolfor graphical modeling languages are thefollowing:
• ConfigurationProcess. Before thedebug session is started, protocol messages must be exchangedfor thelaunch configuration,whichcontains debugadapter specific, and hencelanguage-specific,information. Theexchanged information is independent of therepresentation of thelanguage i.e. whether it is atextual language or graphical modelinglanguage.
95 6. Evaluation
• ExecutionModes. The DAPshouldprovide messages to start,pause, and stop the executionofthe model.These commands are responsible for controlling the debugging processinthe language-specific debugger.After the start command is executed, thesource code or modelisparsed viathe debugger. Forthe DAP, it is not relevantwhether sourcecodeoramodel is read in.The pausing and stopping of thedebugging process are donebasedonthe currently executed thread. The threadhas an ID that is transferredbetween thedevelopmenttooland the debug adapter to identify the running debugging process.
• Steps. Besides, we requireafeature to run the modelstepwise, whichmakes an identificationofthe currentexecution position necessary. Compared to textual languages, where the line and column identify theposition, thecurrentposition in graphical modeling languages is identifiedbythe model elements, which are usually identified by IDs. In case theDSML supportshierarchical structures,facilities to step into the child model or step backout into the parent model are required. The commands step in and step out force thedebugging process to change to anotherhierachy level. However, the debug adapter onlyneeds thethreadIDofthe currentdebugging process and forwards it to the debugger. The language-specific debugger is responsible for further execution based on thehierarchy structures of the language used, be it atextual language or agraphicalmodelinglanguage.
• Breakpoints. The protocol should have messagestoexchangethe breakpoints using the model element ID andthe path to the model forwhichthe breakpoint wasset.The DAPhas differenttypes of breakpoints (e. g. SourceBreakpoint, FunctionBreakpoint, DataBreakpoint, ExceptionBreakpoint), whichhave been defined forthe requirements of textual languages.Ingraphicalmodelinglanguages, we identify abreakpointusingthe ID anddiagram location of themodel element. None of theexisting breakpointtypes of theDAP have the necessary attributes to transmit the aboveinformation. That’swhy we defined anew breakpointtype with the GLSPBreakpoint.
• Stack Trace. While the executionofthe model is paused, the stack trace should be transferred over the protocol to the developmenttool. Forthe stacktrace, the individualstackframesare transmitted to the developmenttool. However, the stack framesare notindependent of whether atextlanguage or agraphicalmodeling language is used. The reason for this is the use of theline and column to identify astackframewithinthe sourcecode. The twoattributesare notoptional and therefore avaluemust be assigned. Forgraphical modeling languages,weonly need the correspondingIDtoidentify amodel element.Therefore, we cannot assign specific valuestothese twoattributes.However, if astackframehas no source (i.e. path to asource file) in text languages,value "0" is assignedtothese two attributes. The developmenttoolrecognizes this andignores the line and column of astack frame.
96 6.3. Interpretation of theResults
• Runtime Variable I/O. While the executionofthe model is paused, the variables should be transferred over theprotocoltothe developmenttool. Forthe transfer of variableswedid notidentifiedany difference between textuallanguages and graphical modeling languages.The informationabout the variable is converted into aString data type by the debugger. The responseofthe variablestothe developmenttoolisvery generic in that thename, thevalue,and the type of the variableistransmittedasaString data type.The representationinthe variable view is alsodone as aString data type.
• Exceptions. If an error occurs during theexecutionofthe model,the DAPrequires messagestotransfer the program’sstatusand the appropriate error information to the developmenttool. Sincethe exceptionistransferred using the DAPasa Stringdatatypeand is alsorepresented as aString in the debug console it does notmatter if we use atextual language or agraphical modeling language.
RQ2: Can theDAP fortextuallanguages be applied to graphical modeldebugging, and if not, what needs to be extended or changed? Forthe implementation of theWFML and theSMML debugger, we usedthe standard- izedDAP features4 to communicatethe debugging databetween thedevelopment tool and thedebug adapter. We were abletomeetalarge partofthe debuggerrequirements with the DAPasis. However, there were individual situations whereanextension of the DAPwas necessary. First, we couldnot use the existing requests to transfer breakpoints between thedevelopment tool and thedebug adapter duetomissing attributes. We had to define acustomrequest to transfer the GLSPBreakpoints to the debug adapter. The two most important attributesofthe GLSPBreakpoints are themodel element ID stored as aString data type and thepathtothe model.Wecouldnot find this composition in anyofthe existing requests.Second,analyzingthe requirements for theSMML,wewere notable to transmit the transitioneventsavailable forastate to the developmenttool with theexisting protocolmessagesofthe DAP. In thecontext of textual languages,there is no comparable debugging concept that presents the user with aselection of available inputevents, from which theuser must selectanevent for further execution. Thus, we defined anew DAPevent for the transmission of the GLSPEvents to theuser interface. Third,there wasnorequestavailable to send the selectedevent backtothe debug adapter. Therefore, we definedanother custom request to transfer the selected GLSPEvent.In summary,weconcludethat the DAPcan be usedfor graphical modeling languages with afew modifications. Nevertheless, we do notconsider it useful to introduce aseparate protocolfor graphical modeling languages for thesetwo requests.When conducting furtherwork on this topic, suchasreusing the developeddebugging framework for other languages and debugger features,ithas to be re-evaluated whether the definitionofa new protocolshould be forced.
4https://microsoft.github.io/debug-adapter-protocol/specification
97 6. Evaluation
RQ3: What genericclient-frameworksand userinterface/debugadapter client compo- nents existfor suchadebug protocol that canbereusedacrossdebugging use cases for multiplegraphical domain-specific languages? The debugger’s implementation showedthat theexisting Theia-debug extension, which supportsthe DAP, could be reused andextended to fit the requirements of debugging graphical modeling languages.Therefore, we were abletoreuse thegraphical userinterface components of thetheia-debugextensionlikethe debug view,threads view, call stackview,breakpoints view, and thevariables view. Concerning thebreakpoints view,wewere abletoinject the GLSPBreakpoints as afurther data source. Besides, the Theia-debug extension offersvariouscontribution points to adapt thedebugger user interface to thecustom requirements. Thisallowedustointegrate custom components formanaging thedebug session and breakpoints. Furthermore, we were abletointegrate an additional view for displaying the eventflowsofstate machines into the user interface. Besides, theTheia-debug extension allows easy integration of the debug adapters we have implemented for thetwo languages WFML and SMML.For the implementation of the debug adapter,wewere abletouse theexisting npm-modulesvscode-debugprotocol and vscode-debugadapter. The latterserved as thebasisfor thedebug adapter implementation and wasextended to meet therequirements of graphical modeling languages. On the one hand, thedebug adapterhad to be able to handle setGLSPBreakpoints requests and setGLSPEvent requests.Onthe other hand, anew eventwas introduced, which transmits the transitioneventstothe developmenttool. Moreover, the debug adapter hadtobeextended to connecttothe externalDSML debugger and thus be ableto exchange messagesbetween them. Furthermore, we usedthe GLSplatform to create custom DSMLs and thecorrespondingdiagram editors. We usedthe clientframework of the GLSplatform forthe graphical manipulation of themodel.Onthe one hand, we were abletodefine language-independent actions to visualizethe currentstackframe within the diagramand,onthe other hand, to establish further actions that allow the setting of breakpoints within the diagram. Besides, we were abletodefine actions to highlight the model elementsasbreakpoints. Finally,wecan saythatthe developed debugger can be reused to integrate multiple graphical modeling language debuggers into the same IDE due to the debugger framework’s language independence.With the frameworks used, we were abletoimplementall of our previously defined requirements. The Theia-debug extensionhas been developed quitespecificallyfor textuallanguages. However, we were abletoadd custom implementationsvia thecontribution points and thus solvethis discrepancy.
98 CHAPTER 7
Related Work
Alot of related work deals with the debugging of DMSLs that have atextual concrete syntax or with models that are first transformedintoGPL code and then debugged using existingGPL debuggers.Furthermore, theGLSP wasonly recently introduced, and the DAPbecame moreaccessible to abroader audience in thecourse of VSCode in 2015. At the time of writing,wecould not find anyliteratureonthe exact topic of developinga modeldebuggerusing client-serverarchitecture forgraphicalmodelinglanguages.Inthe following, we introducesome of therelevantwork in theareaofmodel execution and debugging.
7.1Debugging Domain-Specific Models
Tezel and Kardas presentedtwo debugging approaches [2] for Multi-Agent System (MAS) DSMLs[62,63]. MASsinclude multiple interactingsoftware agents within an environment, where eachagentperforms atask.MAS DSMLs support both the static and thedynamic aspectsofagentsoftware. Furthermore, they reflect the agents’internal behaviormodel, interactionwith other agents,and the use of other environmententities.The DSMLs provide appropriate IDEs in which both modeling and code generation can be performed. The first approachuses mappinginformationfrom the link between thesource language (DSML)and the target language (GPL). Thedesigned modelistransformedintoGPL code through model-to-texttransformation.The generated code is checkedusingaGPL debugger that sends backthe debugging results to the DSML debuggingperspective. The second approachallows to interpretthe runtime state directly at themodel level. Thisrequiresadditionalruntime states and transitions in themetamodel. Furthermore, amodel interpreter and debuggermustbeimplementedtointerpret and checkthe model entities.The model is then debuggedvia amodel-to-modeltransformationinwhichthe transitions serveassteps between theelements.The runtime statesare used to indicate whether an element is defined as abreakpoint.
99 7. RelatedWork
The first approachdiffersfromour work in thatthe generated model is first trans- formed into GPL code and then checkedfor correctnesswithexisting GPL debuggers. The debugger,wedevelopeddebugs thegenerated model already on the modellevel. However, the work does not provide anycluesonhow the debugging results are sentback to the IDE.Likeour work, the second approachaims to interpretthe model elements already at themodel level. This makesitpossible to implementagenericdebuggerand thus minimize the effort for integratingother languagesintothe IDE. As withthe first approach, it is unclear howthe communication between debugger and IDE shouldbe implemented.
Wu et al. presentedaDSL debugger framework [64] for textuallanguages reusing existing, tried,and familiar debugging facilities (e.g. breakpoints, step, stack trace). The approachdefinedbyWuetal. enables the hidden and automaticconstruction of adetailedmappingbetween modelentities and synthesizedcode. The developed debugger framework uses Eclipse’sbuilt-indebugging facilities.Eclipse servesasatool integration platform thatprovidesnumerousextensionpointsfor customization through aplug-inarchitecture.The Eclipse debugging perspectiveisaframework forbuilding an integratingdebuggers.The debugging perspectivedefinesaset of user interfaces thatdefine debugging functionalities (e.g. breakpoints, threads, and variables). The debugger perspectivedoesnot provide aconcretedebuggerimplementation,but it offers abasicdebuggerinterfacethat can be extended and adapted to aparticular language’s requirements. Theuser interfacelistens to debug events from the debug model interface and updates theuser interfacetoshowthe debugged program’s currentstate.Most debug eventlisteners are implementedasinterfaces that can be extended and adapted to correspond to each debugger’sspecific behavior. Theframework hasadebugger re-interpreter that obtainsasequence of debugging commands from the specificdebug model interface and queriesthe underlyingcommand-line debugger. Using this framework, atoolimplementerdoesnot have to implement anew debugger fromscratchsincethe Eclipse debugging perspectiveisindependent of theGPL and can be usedwith every existing GPL debugger. Using different GPL debuggers,the re-interpreter must be adapted due to thedifferentAPIs of thedebuggers. Fordifferent typesofDSLs, the specific part of theframework is thevariablemappingcomponent, which is represented as additional semantics in theDSL grammar.The framework’s architecture, thestep algorithm, andthe mapping knowledgebase aregeneric parts and can be reused across differenttools and DSLs. However, thecurrent version of the approachcan onlybeused for textual languages and assumes that thegenerated artifact is code.
The GEMOC Studio1 wasinvented by the GEMOCInitiative, an open andinterna- tionalcommunity,whichfocusesonthe coordinated usage of various modeling languages. GEMOCdevelops frameworksand environments to create, integrate, and automate the processing of modelinglanguages.The GEMOCStudio [65–68] provides functionalities
1http://gemoc.org/studio
100 7.1. Debugging Domain-Specific Models for language designersand domain experts to buildand compose newexecutable DSMLs. Furthermore, GEMOCStudio offers amodetocreateand execute modelsconfirming to suchexecutable DSMLs. Likethe GLSplatform,the abstract syntax of themodel is generated with the Ecore Modeling Framework and integratedintothe GEMOC Studio.Using theSirius Designer2 forthe graphical syntax and Xtext for thetextual syntax,editing support for DSMLs is developed. In order to makethe DSML executable GEMOC using anyJava-based language, suchasJava, Xtend3 or Kermeta4 [69,70]. The assemblingofthe DSML concerns is made consistentutilizing the language workbench Melange5 [71, 72] to define theexecution semantics. The GEMOC Studio [73]comeswith an integrated modeldebuggertohelpthe DSML designer duringthe model creation phase.Figure 7.1 illustrates theGEMOC model debugger highlighting thecurrentstackframeofafinite-state machine model.The figurefurthershows the graphical editor on the leftside, where the currentstate S2 is highlighted and markedwith agreenarrow. Additionally,the example furtherincludes atextual notation of themodel on therightside next to the graphical representation. Furthermore, on top of theeditor’s views, the illustrationshows the call stackview, variablesview,and breakpoints view.
Figure 7.1: Modeldebuggerofthe GEMOC Studio [74].
The existingruntime servicesand model executiontools of theGEMOC Studio can be usedfor interpreted and compiled DSLs. Therefore, theGEMOC Studio offersa genericexecutionframeworkthatprovidesvarious genericruntime services, suchas graphical animation, omniscientdebugging, and trace managers. Furthermore, the use of generictools within GEMOCStudio is supportedthrough the introduction of behavioral
2https://obeodesigner.com/en/product/sirius 3http://eclipse.org/xtend 4http://diverse-project.github.io/k3 5http://melange.inria.fr
101 7. RelatedWork
interfaces. Abehavioral interface defines aset of events specifyinghow externaltools can interactwith modelsthatconform to executableDSLsimplementing theinterface. Thisallows the definitionofabstract events thatcan be implemented by similar DSLs, enablingthe use of generic tools overDSLsconfirming to thesame metalanguage. This approachisequivalenttothe one we useinour work with the DAP, which consists of differentinterfaces to standardize the individualrequests, events, andresponses for debugging. The approachproposed by the GEMOCinitiativeallows using areflective eventinjection GUI in conjugation with the generic debugger already provided by the GEMOCStudio.The extended debugger offersvariousdebugging facilities (e.g. pause execution, use stepping operations, and set breakpoints) [75].Thiscorrespondstothe genericdebuggeruser interfaceweuse in the course of our work. Figure 7.2 gives an overviewofthe proposed approachbythe GEMOCinitiativeand shows the interaction between theindividualentities.
Figure 7.2: Overview of the proposedapproach[75].
Furthermore, the approach used by GEMOCStudio includesanevent manager.The eventmanagerisresponsible fordispatching eventoccurrences between relationships basedonthe behavioral interfaces referencedbythe relationship. This implementation relationship describes howthe xDSL providesthe interactioncapabilities that are ex- pected alanguage typedbythe behavioral interface. The implementation relationships are realized through Event-Condition-Action (ECA) rules.Theserules aretriggered wheneventsfrom one sideofthe relationshipsatisfy their associatedconditions. The events are then translated into newevent occurrences belonging to the other sideofthe relationship. Finally,anintegration façade forthe eventmanagerisintroduced to act as an intermediary between theexecutionengineand the eventmanager.Furthermore, the integrationfaçadeisused to define theoperationalsemantics of thexDSL [75]. Thisissimilartothe debug adapterused inour work, whichadapts the debugger’s domain-specific logic to the genericDAP.
102 7.2. Web-based DSML Environments
In thefollowing, we would liketomention further work on existingdebugging approachesfor other languages:Ladybird debugging tool [76–78] for theDSML Sequencer [79], debuggingfor theUnifiedModelingLanguage (UML) [80–84], debugging for the parallel DEVSDSL [85], genericstandard debuggingfor executableDSLs[86–88], and domain-specific debugger definition approaches [89–91].
7.2Web-based DSML Environments
The cloud-based modeling environments AToMPM [92], GenMyModel[93],and We- bGME [94]provide client-serverarchitecture via acommunication protocol.These applications sendanupdatetothe server after eachmodification of themodel.This makes it easier to keep the model consistentacross all clientscollaboratingonthe same model. DifferentDSMLsare integrated via plug-insintothe editor. Additionally, AToMPM offers areleasemodeand debug mode. In release mode,the inputmodel is senttoatransformationengine lying on adedicatedserver. Themodel is transformed completely on theserver, and theresulting modelissentbacktothe client and then displayed on thecanvas. The transformation is animatedatthe client’s canvas and can be executedcontinuously or step-by-step in debug mode. Furthermore, breakpoints canbe set to haltthe executionataspecific pointinthe control flow. Themodel transformation execution is deployed as aplug-inand canbeintegratedintothe AToMPM framework. It is unclear howthe communication between theclientand the server is implemented and whether aprotocolsimilartothe DAPisused.
Severalstand-alone web-based modeling environments (e.g., [95], [96],[97], [98])were introduced. These modeling tools providefull editing functionalities for certaindomain- specific languages in amonolithic environment. The graphical editor andits modeling operationscan be usedtodesign models from graphical modeling languages. Allthe logic to createoredit the modelslies at theclient-side, onlythe latest versionofthe modelisstoredonadatabase server and updated at theend of asession. In contrast, editors basedonthe GLSP provide onlyauser interfacetoexecute modeledit operations at theclient, the logic to createand editthe model is hostedbythe server. Hence,only server-side adaption is required to add the language logic to the environment.
7.3 Other Related Work
There already exist several implementations6 of theDebug AdapterProtocolfor textual languageswithin aclient-server architecture. Among them are popularlanguages like Java,Python, Node,and C/C++, etc.Theseimplementationsprovide valuable insights into the communication between thedevelopment tool and the language-specific debugger. Componentssuchasthe npm-modulesfor thedebug-adapter and thedebug-adapter protocolthatare independent of theconcretesyntax can be reused in this work.
6https://microsoft.github.io/debug-adapter-protocol/implementors/adapters
103
CHAPTER 8
Summary andConclusion
In this chapter, we first summarize our work on this thesis, andsecondly presentthe main results. Furthermore, we compare our work with the related work presented in Chapter 7. Finally,wediscuss the limitations of this work and list some remaining challengesthat can be addressedinfuture work.
8.1 Summary
Thisthesis aimed at investigatingthe existing concepts of theDAP definedfor debugging textual languages and howtheseconceptscan be transferred to debugging graphical modeling languages implemented basedonthe GLSP.Weanalyzed the potentialofusing existingframeworksand components to reduce the effort of integratingnew debuggers for graphicalmodeling languages into IDEs. Forthis, we analyzed the debuggingprocess as well as thedebugging concepts available in moderncodedebuggers.Afterward,we translated theconceptsfor debugging textuallanguages into thecontext of graphical modeling languages.Using theexisting standardizes protocols GLSP,whichisinspired by LSP,and DAP, as well as theweb-based frameworksTheiaand Sprotty, we developed debuggers for two differentgraphicalmodelinglanguages.The LSP separates thelanguage- specific logicofatextuallanguage from theintegration into an editor. Likethe LSP, the GLSP follows asimilar approachbut applies it to graphical modeling languages. Therefore, theGLS platformcomes with aclientand server framework to build web-based diagram editors. Using theDAP allowsimplementing one genericdebuggerinterfacefor adevelopment tool that can communicatewith differentlanguage debuggers via so-called debug adapters.The debug adapterscan be reused across multipledevelopment tools, which significantlyreduces theeffort to support anew debugger in differenttools. From the existing WFML,agraphicalmodelinglanguage for designing workflows,wederived the requirements to investigate if theDAP fits. Basedonthe informationwegainedat analyzingthe DAP, we implementedadebuggertoease theintegration of debugging support for new graphical modeling languages.
105 8. Summary and Conclusion
The following steps were taken to implementthe debugger: First, we created acustom web-based IDE using theEclipse Theia framework.Inadditiontothe basiccomponents of Theia, which arenecessaryfor abasicIDE, we integrated the GLSplatform as well as the Theia-debug extension.The GLSplatform offersadiagram editor and agraphical languageserverwith whichweare abletocreate and edit WFML diagrams.The Theia- debug extension providesageneric debugger GUI, thelogic to manage theindividual debugging features,and allowsthe exchangeofDAP messages between adevelopment tool and adebug adapter. Second, we replaced the components of theTheia-debug extension thatwere not suitablefor graphical modeling languages with custom implementations. Third,weimplementedacustom debugadapter forthe WFML.For this purpose, we usedthe existing vscode-debugadapter module, which includesabasicimplementation of adebug adapter. We extended this debug adaptertomeetthe requirements of the WFML. Furthermore, thedebug adapter connectstoaremoteserver where the WFML debugger is located. Fourth, we developed adebuggerfor theWFML,whichparses the model, is aware of the individual debugging features(e.g. breakpoints,steps,variables), executesthe model,and interprets the individualmodel elementsaccordingly. Finally, we applied theDAP to the GLSP,inwhichweimplementedcustom GLSP actionsand graphical representationstoenable, among other things, setting abreakpointinthe diagram and highlighting the current stack frame. The second DSML wasdefinedtoinvestigatethe reusabilityofthe developeddebugger to integrate new graphical modeling language debuggersintoweb-based diagram editors. We can conclude that by using the DAPdeveloped for textuallanguages alanguage- independent implementationfor alarge partofthe requirementsfor graphical modeling languages is possible. We have managed to usethe generic debugger GUIaswell as the custom implementationsdeveloped for theWFML alsofor thenewlydefinedSMML.For the requirements thatwecouldnot serve with the DAP, we usedcustom requests and events.Thesecustom protocolmessages(e.g. GLSPBreakpoint), whichare additionally defined forgraphicalmodelinglanguages,are recognizedbythe Theia-debug extension and thecustom debug adapters.Furthermore, we were abletouse theGLS platform to introducelanguage-independent GLSP actions to enable graphical animations in the diagram. These actions can be used by both the WFML and theSMML.The GLSP features(e.g. breakpointFeature)wehavedeveloped can be integrated into the individual modelelements. Finally,itcan be saidthatthe componentsimplementedinthis work can be usedasastartingpoint for theimplementation of further graphicalmodeling languagesand theirassociatedtools (e.g.debugger,interpreter). Furthermore, we discussed open problems and future work on thedeveloped debugger.
8.2Comparison with Related Work
As mentionedinChapter 7, we could not find anyliteratureonthe exact topic of using aprotocolfor standardizing thecommunication between developmenttools and real debuggers to supports the debugging of graphical modeling languages. Therefore, the maindifference between the related work and the work at handisthatrelatedwork
106 8.3. Limitations and Future Work addresses debuggers deeply integrated into theIDE. At the same time,this thesis follows agenericway of integratingdebuggers.Furthermore,most of therelated work requires a localinstallationofthe tools.However, this thesis focuses on aclient-server architecture to provide aweb-based modeling tool, includingmoderndebugging facilities.The few related tools available inaweb-based environmentoffer either no debugmodeordeal with thedebugging of modeltransformation.Inthis work, however, we dealwith model interpretationand modeldebugging.
8.3Limitationsand Future Work
In this section, we discuss limitations of thecurrentapproachand presentsuggestions for future work on thedeveloped debugger. This comprisesfurtherdebugging features integratedintothe existing debugger and extensions to thelanguage constructsofthe DSMLsinuse.
8.3.1 Extending theDebugger Facilities
In thefollowing, we presentfeatures that could be implemented to extend thecurrent debugger.
Support of Multiple Threads. The implementeddebuggers currentlyonly support the executionofasingle thread. Therefore, models that support parallelismcannot be executedcorrectly.The WFML usedasthe runningexample offersalanguage structure thatsupportsparallelism in models. Forthe parallel execution of processes, the two activ- itynodes fork node and joinnodewere defined in the WFML.Futurework could analyze whether theWFML debuggercan be extended to supportparallel executionofmodels. Forthis, the DAPprotocolmessagesfor the executionofmultiplethreads should be used in connectionwith graphical modeling languages.Furthermore, it has to be analyzed to what extent theclientframework of theGLS platformhas to be adapted/extended to ensure the correct functioningofthe graphical animations during theparallelexecution.
SetVariables. Anotherimportantpointfor future work on this topicisthe modifi- cation of variablesduring the model’s execution. In addition to the variable request to receivethe variables, the DAPalso supports a setvariable request to modify variable valueswhen the executionispaused.Itshould be noted thatachangeofthe variable value should be reflectedappropriately at every level of abstraction, to ensurecontinued overall consistency. This affectsthe variable view within the debug view,the model source, and thegraphicalrepresentation in theform of thediagram.
Graphical Animations. Finally,the framework developedcan be extended by furthergraphical animations. The Sprotty framework underlyingthe GLSplatform offers several additional features (e.g. visual transition) that can be usedtoimplementthe
107 8. Summary and Conclusion
debugging concepts. The graphical representationsimplementedsofar onlyshowasmall part of what theSprotty framework would offer in terms of animations.
8.3.2 Utilizing Tools andFrameworks Concerning RQ3, we usedexisting tools and frameworks(e.g. Theia, GLS platform, Sprotty, DAP) to implement the debugger. These tools andframeworks were themselves stillinthe developmentphase. It mightcometocompatible issues when upgrading the frameworks to their currentversion. Further work should,therefore, consider thelatest versions of thecomponentsused.
8.3.3 Extending the DSMLs Concerning theresults for theRQ1 andRQ2, we would liketopointout thatwehave created onlytwo DSMLsinthe course of this work and presentedthe results based on thesetwo.The results couldbetheoretically differentifweimplemented further modeling languages.Inthe course of future work, further languages and domains should be implemented,and the existing framework,including the DAP, should be analyzedfor itsreusability. These further experiments should alsoprovide informationastowhether other languages alsoneedfurtherprotocolmessages. It can then be discussed whethera new protocolfor graphical modelinglanguages shouldbedefined. Besides, definingnew DSMLs, the twocase study DSMLs used in this thesiscan be extended by additional language constructs.Inthe WFML,instead of using the probabilityofweightededges, the activity nodes couldalsouse statementsasguards (e.g.[Temperature ok?]: Yes | No). The SMML,inits currentversion, is an abstraction of what one knowsfrom state chart diagrams[99]. Forexample, the SMML could be extendedbythe followingactions:
• Entry action: Thisaction is executedwhile enteringanew state, regardless of the state transition through whichthe new state hasbeenreached.
• Exit action: Thisaction is executedwhen the currentstate is exited, regardless of thestate transition over which the current state is exited.
• Inputaction: Thisaction is generated depending on the currentstate and the input event. Several actions can be assigned to astate.
The entryand exit action do notrequire anymodification of thedebuggersince it can be handledbythe interpreter. Inputactionsare executedwhen acertainevent occurs within astate. The GLSPEvents introduced by us could be usedtohandle theinput events.The debugger must be abletodetermine whether this eventtriggersatransition to anotherstate or performs the action withinastate.
Regarding theseextensions, it is important to analyze whether theexisting compo- nents whichweredeveloped for actions can alsodeal with theabove-defined actions.
108 8.3. Limitations and Future Work
Subsequently,additional language constructs suchasthe activitynodes of theWFML can be added to theSMML,where again, attentionshould be paid on reusability.
8.3.4Debugging for Code Generation Forfuture work it can be considered whether,inadditiontothe model interpretation approachused in this work, the introduced code generation approachdescribedinSection 2.1, can be implemented.InSection 2.3, we briefly talked about debugging model transformations. Debuggers for code generators couldhelpthe userfixerrors in the translationprocessfrom themodel to executablecode.
109
Bibliography
[1] Marco Brambilla,Jordi Cabot, and ManuelWimmer. Model-Driven Software Engineering in Practice:Second Edition.Morgan and ClaypoolPublishers, 2nd edition, 2017.
[2] Baris Tekin Tezel and Geylani Kardas.Towards ProvidingDebugging in the Domain-Specific Modeling Languages for Software Agents.InProceedings of the Second International WorkshoponDebugging in Model-Driven Engineering (MDEbug 2018) co-locatedwithACM/IEEE21st International ConferenceonModel Driven Engineering Languages and Systems(MODELS 2018).CEUR WorkshopProceedings, 2018.
[3] Roberto Rodriguez-Echeverria, Javier L. C. Izquierdo, ManuelWimmer,and Jordi Cabot. Towards aLanguage Server Protocol Infrastructure forGraphical Modeling. In Proceedingsofthe 21thACM/IEEEInternational ConferenceonModel Driven EngineeringLanguages and Systems,MODELS’18, pages 370–380. ACM, 2018.
[4] Microsoft. Debug AdapterProtocoldocumentation. https://microsoft. github.io/debug-adapter-protocol,Accessed: 2020-06.
[5] Alan R. Hevner, Salvatore T. March, Jinsoo Park, and SudhaRam. Design Science in Information Systems Research.InManagement Information SystemsQuarterly, volume28, pages75–105. Societyfor Information Management and TheManagement Information SystemsResearchCenter, 2004.
[6] John Venable,Jan Pries-Heje, and RichardBaskerville.AComprehensiveFramework forEvaluationinDesign ScienceResearch.InProceedingsofthe 7th International ConferenceonDesign Science Research in Information Systems. Advances in Theory and Practice,pages 423–438. Springer, 2012.
[7] Ken Peffers, Marcus Rothenberger, Tuure Tuunanen, and RezaVaezi. Design Science Research Evaluation.InDesign Science Research in Information Systems. Advances in Theory andPractice,pages 398–410. Springer, 2012.
[8] Robert K. Yin. Case StudyResearch: Design and Methods (Applied Social Research Methods).Sage Publications, 4th edition, 2008.
111 [9] SamiBeydeda, Matthias Book, and Volker Gruhn. Model-Driven SoftwareDevelop- ment.Springer, 2005.
[10] Bran Selic. The Pragmatics of Model-Driven Development.InSoftware, IEEE, volume20, pages 19–25. IEEEComputer Society Press, 2003.
[11] DouglasC.Schmidt.GuestEditor’s Introduction: Model-DrivenEngineering.In Computer,volume 39, pages25–31. IEEE Computer SocietyPress,2006.
[12] M. Voelterand I. Groher.ProductLine Implementationusing Aspect-Orientedand Model-Driven Software Development. In 11thInternational Software Product Line Conference(SPLC 2007),pages 233–242. IEEE Computer Society Press,2007.
[13] Thomas Stahl, MarkusVoelter,and Krzysztof Czarnecki. Model-Driven Software Development: Technology,Engineering, Management.John Wileyand Sons, Inc., 2006.
[14] MarkusVoelter,Sebastian Benz, Christian Dietrich,Birgit Engelmann, Mats He- lander, Lennart C. L. Kats, Eelco Visser,and GuidoWachsmuth. DSL Engineering -Designing, Implementing and Using Domain-SpecificLanguages. dslbook.org, 2013.
[15] Erwan Breton and Jean Bézivin. Towards an UnderstandingofModel Executability. In Proceedingsofthe International ConferenceonFormal Ontology in Information Systems -Volume 2001,FOIS’01, pages70–80. ACM, 2001.
[16] Gustavo C. M. Sousa, Fábio M. Costa, Peter J. Clarke, and Andrew A. Allen. Model-Driven Development of DSML ExecutionEngines.InProceedingsofthe 7th Workshop on [email protected],ser.MRT ’12, pages 10–15. ACM, 2012.
[17] K. A. Morris, J. Wei, P. J. Clarke, andF.M.Costa. Towards AdaptableMiddleware to Support Service Delivery Validation in i-DSMLExecution Engines.In2012 IEEE 14th International Symposium on High-Assurance Systems Engineering,pages 82–89. IEEE Computer SocietyPress,2012.
[18] MarkAllison,Peter J. Clarke, and Xudong He. AGeneric Model of Execution for SynthesizingInterpreted Domain-Specific Models. In Procedia Computer Science, volume62, pages 495–504. Elsevier Science Publishers B. V., 2015.
[19] StefanBucur, Johannes Kinder, and George Candea. PrototypingSymbolic Exe- cution Engines for Interpreted Languages. In SIGARCH Comput. Archit.News, volume42, pages 239–254. ACM, 2014.
[20] JackHerrington. Code Generation in Action.ManningPublications Co., 2003.
[21] M. Puschel, J. M. F. Moura, J. R. Johnson, D. Padua,M.M.Veloso,B.W.Singer, Jianxin Xiong, F. Franchetti, A. Gacic, Y. Voronenko, K. Chen, R. W. Johnson, and N. Rizzolo. SPIRAL: Code Generation for DSPTransforms. In Proceedingsof the IEEE,volume 93, pages 232–275. IEEE Computer SocietyPress, 2005.
112 [22] Valentin Besnard,Matthias Brun,PhilippeDhaussy,Frédéric Jouault, David Olivier, and Ciprian Teodorov. Towards One Model Interpreter forBoth Design and De- ployment.InProceedingsofthe 3rdInternational WorkshoponExecutableModeling (EXE2017) colocatedatMODELS2017.CEURWorkshop Proceedings, 2017.
[23] Tanja Mayerhoferand Philip Langer. ARuntime Model forfUML. In Proceedingsof the 7th [email protected](MRT) co-locatedwiththe 15th International ConferenceonModel Driven Engineering Languages and Systems(MODELS’12), pages 53–58. ACM, 2012.
[24] Yoann Laurent, RedaBendraou, andMarie-Pierre Gervais.Executing and Debugging UMLModels: An FUML Extension.InProceedings of the 28th AnnualACM Symposium on AppliedComputing,SAC ’13, pages1095–1102. ACM, 2013.
[25] DanielA.Sadilekand GuidoWachsmuth. PrototypingVisualInterpreters and Debuggers for Domain-Specific ModellingLanguages. In Proceedings of the 4th EuropeanConferenceonModel Driven Architecture: Foundations andApplications, ECMDA-FA’08, pages63–78. Springer,2008.
[26] Erwan Bousse, Jonathan Corley,Benoit Combemale, JeffGray, and Benoit Baudry. SupportingEfficientand AdvancedOmniscientDebugging for xDSMLs.InProceed- ings of the 2015ACM SIGPLAN International ConferenceonSoftwareLanguage Engineering,SLE 2015, pages 137–148. ACM, 2015.
[27] Martin Fowler. Domain Specific Languages.Addison-Wesley,1st edition, 2010.
[28] Tomaz Kosar,Nuno Oliveira,Marjan Mernik, MariaJoão Varanda Pereira,Matej Crepinsek, Daniela Carneiro da Cruz, and PedroRangelHenriques. Comparing General-Purpose and Domain-Specific Languages: An Empirical Study. In Computer Science andInformation Systems,volume 7, pages 247–264. ComSIS Consortium, 2010.
[29] Steven Kelly and Juha-Pekka Tolvanen. Domain-Specific Modeling: Enabling Full Code Generation.Wiley-IEEE Computer Society Press, 2008.
[30] Mark vonRosing, StephenWhite, Fred Cummins, and Henk Man. Business Process Modeland Notation (BPMN),volume 1, pages 429–453. ElsevierScience Publishers B. V. -Morgan Kaufmann, 2015.
[31] Stefano Ceri, MaristellaMatera, FrancescaRizzo, and Vera Demaldé.Designing Data-Intensive WebApplications for Content AccessibilityUsing WebMarts. In Commun.ACM,volume 50, pages55–61. ACM, 2007.
[32] ColinAtkinsonand Thomas Kühne.Model-DrivenDevelopment:AMetamodeling Foundation.InIEEE Softw.,volume 20, pages 36–41. IEEE ComputerSocietyPress, 2003.
113 [33] Mark Strembeck and UweZdun.AnApproachfor theSystematic Developmentof Domain-Specific Languages. In Softw. Pract. Exper.,volume 39, pages 1253–1292. John Wileyand Sons,Inc.,2009.
[34] Thomas Kühne.Matters of (Meta-) Modeling. In Softwareand SystemsModeling, volume5,pages 369–385. Springer, 2006.
[35] Anneke Kleppe. Software Language Engineering: CreatingDomain-Specific Lan- guages Using Metamodels.Addison-Wesley, 2008.
[36] Business Informatics Group. Graphical Modeling Languages [Power- Pointslides]. Retrieved during the Model Engineering Course 2018. https://tiss.tuwien.ac.at/course/educationDetails.xhtml? courseNr=188923&semester=2018W&dswid=2551&dsrid=665,Technische UniversitätWien, Accessed: 2020-06.
[37] David A. Schmidt. Denotational Semantics:AMethodology for Language Develop- ment.Published by Schmidt, David A., 1997.
[38] Shane Sendall and Wojtek Kozaczynski. Model Transformation:The Heartand Soul of Model-Driven Software Development. In IEEE Softw.,volume20, pages 42–45. IEEE Computer SocietyPress,2003.
[39] Anna Gerber, Michael Lawley,Kerry Raymond,Jim Steel, and Andrew Wood. Transformation:The Missing LinkofMDA.InGraphTransformation,pages 90–105. Springer,2002.
[40] TomMensand Pieter [Van Gorp].ATaxonomy of ModelTransformation.In ElectronicNotes in Theoretical Computer Science,volume 152, pages 125–142. Elsevier SciencePublishers B. V., 2006.
[41] K. Czarnecki andS.Helsen.Feature-BasedSurvey of ModelTransformation Ap- proaches. In IBMSyst.J.,volume45, pages 621–645. IBM Corp., 2006.
[42] Raphael Mannadiar and Hans Vangheluwe.Debugging in Domain-Specific Modelling. In SoftwareLanguage Engineering,pages 276–285. Springer,2011.
[43] JonathanCorley,BrianP.Eddy,Eugene Syriani, and JeffGray. Efficientand Scalable OmniscientDebugging for ModelTransformations. In SoftwareQuality Journal,volume 25, pages 7–48. Kluwer AcademicPublishers, 2017.
[44] Ian Sommerville. SoftwareEngineering.Pearson, 10th edition, 2015.
[45] Andreas Zeller. Why Programs Fail: AGuidetoSystematic Debugging.Morgan KaufmannPublishers Inc., 2nd edition, 2009.
[46] Educba. Introduction to Debugging. https://www.educba.com/ what-is-debugging/,Accessed:2020-06.
114 [47] Jack B. Dennis. Petri Nets. In Encyclopedia of Parallel Computing,pages 1525–1530. Springer,2011.
[48] Hendrik Bünderand HerbertKuchen.Towards Multi-editorSupport forDomain- Specific Languages Utilizing theLanguage Server Protocol. In Model-Driven Engi- neering and SoftwareDevelopment,pages 225–245. Springer,2020.
[49] Hendrik Bünder. DecouplingLanguage and Editor -The Impact of theLanguage ServerProtocolonTextual Domain-Specific Languages. In Proceedings of the7th InternationalConferenceonModel-Driven Engineering and SoftwareDevelopment, MODELSWARD 2019, pages129–140. SCITEPRESS-Science and Technology Publications, Lda, 2019.
[50] Sven Efftingeand MarkusVölter. oAWxText: Aframework fortextual DSLs. In WorkshoponModeling Symposium at Eclipse Summit,volume 32. EclipseCon, 2006.
[51] Microsoft. Language Server Protocol documentation. https://microsoft. github.io/language-server-protocol,Accessed: 2020-06.
[52] Eclipse Source. Graphical Language Server Protocol documentation. https: //www.eclipse.org/glsp,Accessed:2020-06.
[53] Eclipse Sprotty. Eclipse Sprottydocumentation. https://github.com/ eclipse/sprotty/wiki,Accessed: 2020-06.
[54] David Steinberg, Frank Budinsky, Marcelo Paternostro, and Ed Merks. EMF:Eclipse Modeling Framework.Addison-Wesley,2nd edition,2008.
[55] Anatolii Bazko. Implementing theDebug AdapterProtocolfor Eclipse Theia and Eclipse Che. https://che.eclipse.org/ implementing-the-debug-adapter-protocol-for-eclipse-theia-d55cac38c59d, Accessed:2020-08.
[56] Remo H. Jansen.InversifyJS documentation. https://github.com/ inversify/InversifyJS,Accessed:2020-06.
[57] Microsoft. VisualStudio Code Debugger Extension. https://code. visualstudio.com/api/extension-guides/debugger-extension,Ac- cessed:2020-06.
[58] JamesH.Hill and AniruddhaS.Gokhale. Using GenerativeProgramming to Enhance Reuse in Visitor Pattern-based DSML Model Interpreters. In IEEE Trans. SP.Institute forSoftware Integrated Systems, Vanderbilt University, 2007.
[59] ErichGamma, RichardHelm, RalphJohnson, and JohnVlissides. Design Patterns: Elements of ReusableObject-OrientedSoftware.Addison-Wesley Longman Publishing Co., Inc.,1995.
115 [60] ElisabethFreeman, Eric Freeman, BertBates, and Kathy Sierra. Head FirstDesign Patterns. O’ Reilly and Associates, Inc., 2004.
[61] Refactoring Guru.VisitorPattern. https://refactoring.guru/ design-patterns/visitor,Accessed: 2020-06.
[62] Christian Hahn.ADomainSpecific Modeling Language for MultiagentSystems. In In Proceedingsofthe 7th International Joint ConferenceonAutonomous Agents and Multiagent Systems,volume1,pages 233–240. AAMAS 2008, 2008.
[63] Federico Bergenti, Eleonora Iotti,Stefania Monica,and AgostinoPoggi.Agent- Oriented Model-Driven Development for JADE with the JADEL Programming Language. In Computer Languages,Systems andStructures,volume 50, pages 142–158. ElsevierScience Publishers B. V.,2017.
[64] Hui Wu,Jeff Gray, and Marjan Mernik. Grammar-Driven Generation of Domain- Specific Language Debuggers.InSoftw. Pract. Exper.,volume 38, pages 1073–1103. John Wileyand Sons,Inc.,2008.
[65] B. Combemale, O. Barais,and A. Wortmann. Language Engineering with the GEMOCStudio.In2017 IEEEInternational ConferenceonSoftwareArchitecture Workshops(ICSAW),pages 189–191. IEEEComputer SocietyPress, 2017.
[66] Benoit Combemale, Julien Deantoni, Olivier Barais,Arnaud Blouin, ErwanBousse, CédricBrun, Thomas Degueule, and DidierVojtisek. ASolution to theTTC’15 ModelExecutionCase Using theGEMOC Studio.In8th Transformation Tool Contest.CEURWorkshop Proceedings, 2015.
[67] Erwan Bousse,ThomasDegueule, Didier Vojtisek, Tanja Mayerhofer,JulienDean- toni, and Benoit Combemale. ExecutionFramework of theGEMOC Studio (Tool Demo).InProceedings of the 2016 ACMSIGPLAN InternationalConferenceon SoftwareLanguage Engineering,SLE 2016, pages 84–89. ACM, 2016.
[68] DorianLeroy,Erwan Bousse, ManuelWimmer,BenoitCombemale, and Wieland Schwinger. Create and Play your Pac-Man Gamewith the GEMOCStudio (Tool Demonstration).InProceedings of the 3rdInternationalWorkshop on Executable Modeling (EXE2017) colocatedatMODELS2017,pages 1–6. CEUR Workshop Proceedings, 2017.
[69] Pierre-Alain Muller, FranckFleurey,and Jean-Marc Jézéquel. Weaving Executability into Object-Oriented Meta-languages. In ModelDriven EngineeringLanguages and Systems,volume3713, pages 264–278. Springer, 2005.
[70] Jean-Marc Jézéquel, OlivierBarais, and FranckFleurey.Model Driven Language Engineeringwith Kermeta.InGenerative and TransformationalTechniques in Soft- wareEngineering III: International Summer School, GTTSE 2009, Braga, Portugal, July 6-11, 2009. Revised Papers,volume 6491, pages 201–221. Springer, 2011.
116 [71] Thomas Degueule, BenoitCombemale, Arnaud Blouin, Olivier Barais, and Jean- Marc Jézéquel. Melange: AMeta-Language for Modular and Reusable Development of DSLs. In Proceedings of the 2015 ACMSIGPLAN International Conferenceon SoftwareLanguage Engineering,SLE 2015, pages 25–36. ACM, 2015.
[72] Thomas Degueule, Benoit Combemale, Arnaud Blouin, and Olivier Barais. Reusing legacy dsls with melange. In Proceedings of the WorkshoponDomain-Specific Modeling,DSM 2015, pages45–46. ACM, 2015.
[73] Erwan Bousse, Tanja Mayerhofer,and Manuel Wimmer. Domain-Level Debugging for Compiled DSLs with theGEMOC Studio (ToolDemo),1rstInternational Workshop on Debugging in Model-Driven Engineering (MDEbug 2017). In Proceedings of MODELS2017 Satellite Event.CEURWorkshop Proceedings, 2017.
[74] GEMOCGroup. GEMOCStudio Documentation. https://download.eclipse. org/gemoc/docs,Accessed:2020-06.
[75] DorianLeroy,Erwan Bousse, ManuelWimmer,Tanja Mayerhofer,BenoitCombe- male, and Wieland Schwinger. Behavioral interfaces for executableDSLs.InSoftware and Systems Modeling,volume 19, pages 1015–1043. Springer,2020.
[76] Tomaž Kos, Marjan Mernik, and Tomaž Kosar.ATool Support forModel-Driven Development:AnIndustrialCase Study fromaMeasurementDomain.InApplied Sciences,volume 9, page 4553. MDPI, 2019.
[77] Tomaž Kos, Tomaž Kosar,Marjan Mernik, andJure Knez. Ladybird: Debugging Support in the Sequencer. In Proceedingsofthe 2011 American ConferenceonApplied Mathematicsand the5th WSEAS International ConferenceonComputer Engineering and Applications,AMERICAN-MATH’11/CEA’11, pages135–139. WSEAS, 2011.
[78] Tomaž Kosar,Marjan Mernik, JeffGray, and Tomaž Kos. Debugging Measurement Systems using aDomain-Specific Modeling Language. In ComputersinIndustry, volume65, pages 622–635. Elsevier SciencePublishers B. V., 2014.
[79] Tomaz Kos, Tomaž Kosar,JureKnez, andMarjan Mernik. Improving End-User ProductivityinMeasurementSystems with aDomain-Specific (Modeling) Language Sequencer.InADBIS,volume639, pages 61–76. CEUR WorkshopProceedings, 2010.
[80] Lidia Fuentes, Jorge Manrique, and Pablo Sánchez. PóPulo:ATool forDebugging UML Models. In Companionofthe 30th InternationalConferenceonSoftware Engineering,ICSE Companion ’08, pages955–956. ACM, 2008.
[81] Michelle L. Craneand Juergen Dingel. TowardsaUML Virtual Machine:Imple- menting an Interpreterfor UML 2Actionsand Activities. In Proceedingsofthe 2008 Conferenceofthe Center for Advanced Studies on Collaborative Research: Meeting of Minds,CASCON’08. ACM, 2008.
117 [82] Andrei Kirshin,Dolev Dotan, and Alan Hartman.AUMLSimulatorBased on a Generic Model ExecutionEngine. In Proceedingsofthe 2006 International Conference on Models in SoftwareEngineering,MoDELS’06, pages 324–326. Springer, 2006.
[83] Dirk Riehle,Steven Fraleigh,Dirk Bucka-Lassen,and Nosa Omorogbe. The Ar- chitecture of aUML Virtual Machine.InProceedingsofthe 16th ACMSIGPLAN ConferenceonObject-OrientedProgramming, Systems,Languages,and Applications, OOPSLA’01, pages 327–341. ACM, 2001.
[84] Dolev Dotanand Andrei Kirshin.Debugging and TestingBehavioral UML Models. In Companion to the 22nd ACMSIGPLAN ConferenceonObject-OrientedProgramming Systems and Applications Companion,OOPSLA’07, pages 838–839. ACM, 2007.
[85] Simon VanMierlo, YentlVan Tendeloo, and Hans Vangheluwe.Debugging Parallel DEVS. In Simulation,volume 93, pages 285–306. Societyfor Computer Simulation International, 2017.
[86] Benoît Combemale, Xavier Crégut,Jean-Pierre Giacometti,PierreMichel,and Marc Pantel.Introducing Simulationand Model Animation in theMDE Topcased Toolkit. European congress on Embedded Real TimeSoftware and Systems (ERTS), 2008.
[87] I. Rath, D. Vago, and D. Varro.Design-time simulation of domain-specific models by incremental pattern matching.In2008 IEEESymposium on VisualLanguages and Human-CentricComputing,pages 219–222. IEEE Computer SocietyPress,2008.
[88] NilsBandener, Christian Soltenborn, and Gregor Engels.Extending DMM Behavior Specifications for Visual Executionand Debugging. SLE’10, pages357–376. Springer, 2010.
[89] Ricky T. Lindeman,Lennart C.L. Kats, and Eelco Visser.Declaratively Defining Domain-Specific Language Debuggers.InSIGPLAN Not.,volume 47, pages 127–136. ACM, 2011.
[90] Andrei Chiş, TudorGîrba,and Oscar Nierstrasz.The Moldable Debugger: AFrame- work forDeveloping Domain-Specific Debuggers.InSoftwareLanguage Engineering, pages 102–121. Springer, 2014.
[91] Andrei Chiş, Marcus Denker, TudorGîrba,and Oscar Nierstrasz.Practical Domain- Specific Debuggers Using theMoldable Debugger Framework.InComput.Lang. Syst. Struct.,volume 44, pages 89–113. Elsevier SciencePublishers B. V., 2015.
[92] Eugene Syriani, Hans Vangheluwe,Raphael Mannadiar, Conner Hansen,SimonVan Mierlo,and HüseyinErgin.AToMPM: AWeb-based Modeling Environment. In Demos/Posters/[email protected] Proceedings,2013.
[93] Michel Dirix, Alexis Muller,and Vincent Aranega. GenMyModel:An Online UML Case Tool. European ConferenceonObject-Oriented Programming, 2013.
118 [94] MiklósMaróti, Tamás Kecskés, RóbertKereskényi, Brian Broll, Péter Völ- gyesi,LászlóJurácz, Tihamer Levendovszky, andÁkosLédeczi.Nextgenera- tion(Meta)modeling:Web-and cloud-basedcollaborativetoolinfrastructure.In MPM@MoDELS,volume 1237, pages 41–60. CEUR WorkshopProceedings, 2014.
[95] LouisM.Rose,Dimitrios S. Kolovos, and RichardF.Paige. EuGENiaLive: A Flexible Graphical Modelling Tool. In Proceedings of the 2012 Extreme Modeling Workshop,XM’12, pages15–20. ACM, 2012.
[96] José P. Leal,HelderCorreia, and José C. Paiva. Eshu: An Extensible WebEditor forDiagrammatic Languages. In 5th Symposium on Languages,Applications and Technologies (SLATE’16),volume 51 of OpenAccess Series in Informatics (OASIcs), pages 12:1–12:13. Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, 2016.
[97] Christian Thum, Michael Schwind, and MartinSchader. SLIM–A Lightweight Environmentfor Synchronous CollaborativeModeling. In Proceedings of the12th InternationalConferenceonModel Driven Engineering Languages and Systems, volume5795 of MODELS’09,pages 137–151. Springer,2009.
[98] ShuheiHiya, KenjiHisazumi, Akira Fukuda,and TsuneoNakanishi. Clooca: Web basedtoolfor Domain Specific Modeling. In ProceedingsofDemos/Posters/Studen- tResearch@ MoDELS,volume1115. CEUR WorkshopProceedings, 2013.
[99] José A. Cruz-Lemus, AnnMaes, MarcelaGenero, GeertPoels, and MarioPiattini. The Impact of Structural Complexityonthe UnderstandabilityofUML Statechart Diagrams. In Inf. Sci.,volume 180, pages 2209–2220. Elsevier Science Publishers B. V.,2010.
119