DOCSLIB.ORG

Towards Debugging Facilities for Graphical Modeling Languages in Web-Based Modeling Tools

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Towards Debugging Facilities for Graphical Modeling Languages in Web-Based Modeling Tools 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
Load more

Recommended publications
  • Trace Server Protocol
    Introducing: Trace Server Protocol Bernd Hufmann, Ericsson AB 2018-10-25 2019Ericsson-03- 28Internal | Ericsson | 2018-02-21 1 Agenda — Motivation and goal — Background — Trace Server Protocol (TSP) — Opportunities — Ongoing work / Demo — Open discussions 2019Ericsson-03- 28Internal | Ericsson | 2018-02-21 2 Motivation — Increasing popularity of web-based technologies — Integration with next generation IDEs (e.g. Theia) — Success of Language Server Protocol — Automated trace analysis — CI environment — Trouble reports — Scale trace analysis for traces larger than local disk space 2019Ericsson-03- 28Internal | Ericsson | 2018-02-21 3 Goals of presentation — Present idea of Trace Server Protocol — Create awareness and interest in the community — Collect early feedback — Collaboration 2019Ericsson-03- 28Internal | Ericsson | 2018-02-21 4 Next generation IDE Language Server Protocol (LSP) Debug Adapter Protocol (DAP) Language Debug Server Server 2019Ericsson-03- 28Internal | Ericsson | 2018-02-21 5 Next generation IDE Language Server Protocol (LSP) Debug Adapter Protocol (DAP) Trace Server Protocol (TSP) Language Debug Trace Server Server Server 2019Ericsson-03- 28Internal | Ericsson | 2018-02-21 6 What is a trace? — A series of events over time — Events collected at tracepoints during program execution — Each event has a type and content fields (payload) Event Event Event Time Type Content (payload) - Field 1 - Field 2 - … - Field N 2019Ericsson-03- 28Internal | Ericsson | 2018-02-21 7 What can we do with events? — Show the raw events in an events table 2019Ericsson-03- 28Internal | Ericsson | 2018-02-21 8 What can we do with events? — Use as input for further analysis, e.g. — Write state machines — Create patterns — Analyze timing (measuring time between events) — Create execution graphs like critical path — Follow resource usage — ...
    [Show full text]
  • Red Hat Codeready Workspaces 2.4 End-User Guide
    Red Hat CodeReady Workspaces 2.4 End-user Guide Using Red Hat CodeReady Workspaces 2.4 Last Updated: 2020-12-18 Red Hat CodeReady Workspaces 2.4 End-user Guide Using Red Hat CodeReady Workspaces 2.4 Robert Kratky [email protected] Michal Maléř [email protected] Fabrice Flore-Thébault [email protected] Yana Hontyk [email protected] Legal Notice Copyright © 2020 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
    [Show full text]
  • Red Hat Codeready Workspaces 2.1 Administration Guide
    Red Hat CodeReady Workspaces 2.1 Administration Guide Administering Red Hat CodeReady Workspaces 2.1 Last Updated: 2020-07-02 Red Hat CodeReady Workspaces 2.1 Administration Guide Administering Red Hat CodeReady Workspaces 2.1 Supriya Takkhi Robert Kratky [email protected] Michal Maléř [email protected] Fabrice Flore-Thébault [email protected] Yana Hontyk [email protected] Legal Notice Copyright © 2020 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
    [Show full text]
  • Visual Studio Code® and Yocto Project® Rob Woolley, Wind River
    Visual Studio Code® and Yocto Project® Rob Woolley, Wind River Yocto Project Virtual Summit Europe, October 29-30, 2020 Outline • Introduction • What is Visual Studio Code? • Demo 1: Bitbake Extension • Demo 2: Debugging BitBake • Developing with SDKs • Demo 3: SDK Development • Remote Development • Demo 4: Development with WSL2 • Conclusion 2 Yocto Project® | The Linux Foundation® Why? • Why do all the junior engineers use VSCode? • Can we improve working remotely during COVID-19? • How may we adopt modern, cloud-native tools? • Can we develop apps using SDKs? • Does the YP community want tooling for VS Code? 3 Yocto Project® | The Linux Foundation® What is Visual Studio Code? • Available for Linux, Windows, and macOS • Based on Electron (Chromium and Node.js so you can build your app with HTML, CSS, and JavaScript) • Code completion, debugging, refactoring, navigation and more • Many useful extensions for embedded development in the Visual Studio Marketplace • New Linux ARMv7 and ARM64 support for Raspberry Pi and Chromebooks 4 Yocto Project® | The Linux Foundation® VSCode for Tool Developers • Language Server and Debug Adapter architecture • Written in Typescript transpiled to Javascript • JSON configuration with user, workspace, and project-level settings • MIT licensed source code with a binary available under a Microsoft license • VSCodium with Open-VSX.org marketplace https://code.visualstudio.com/api/language-extensions/language- server-extension-guide#testing-the-language-server • Eclipse Theia uses the same extension model and
    [Show full text]
  • Visual Studio Code and Yocto Project
    Visual Studio Code® and Yocto Project® Rob Woolley, Wind River Yocto Project Virtual Summit Europe, October 29-30, 2020 Outline • Introduction • What is Visual Studio Code? • Demo 1: Bitbake Extension • Demo 2: Debugging BitBake • Developing with SDKs • Demo 3: SDK Development • Remote Development • Demo 4: Development with WSL2 • Conclusion 2 Yocto Project® | The Linux Foundation® Why? • Why do all the junior engineers use VSCode? • Can we improve working remotely during COVID-19? • How may we adopt modern, cloud-native tools? • Can we develop apps using SDKs? • Does the YP community want tooling for VS Code? 3 Yocto Project® | The Linux Foundation® What is Visual Studio Code? • Available for Linux, Windows, and macOS • Based on Electron (Chromium and Node.js so you can build your app with HTML, CSS, and JavaScript) • Code completion, debugging, refactoring, navigation and more • Many useful extensions for embedded development in the Visual Studio Marketplace • New Linux ARMv7 and ARM64 support for Raspberry Pi and Chromebooks 4 Yocto Project® | The Linux Foundation® VSCode for Tool Developers • Language Server and Debug Adapter architecture • Written in Typescript transpiled to Javascript • JSON configuration with user, workspace, and project-level settings • MIT licensed source code with a binary available under a Microsoft license • VSCodium with Open-VSX.org marketplace https://code.visualstudio.com/api/language-extensions/language- server-extension-guide#testing-the-language-server • Eclipse Theia uses the same extension model and
    [Show full text]
  • Why Cloud Ides Are the Future?
    Containing your development – why Cloud IDEs are the future? Steve Poole @spoole167 Andy Watson @AndyRWatson About me Steve Poole Andy Watson @spoole167 @AndyRWatson Developer advocate for Developer advocate for Runtimes Eclipse CodeWind Cloud: it’s what we always wanted Today, our Cloud story is really a container story Containers are giving us new opportunities As long as the answer is “container” We’re all set on a future with containers Containers offer immutability and repeatability Enabling new architectures The idea was to swap larger long running systems With many, many fast starting , short lived ones Initially we thought containers made it easy.. FROM jetty RUN apt-get update COPY my.war /webapps Store code Compile and Build the image Push the image in Git Test locally locally It’s not turned out that way It’s tough being a container developer #worksfineonjdk9 #workslikeheavenonjdk11 What does the dev environment look like? Add in the build cycle #worksfineonjdk9 #workslikeheavenonjdk11 Add IDEs, tests, test data and quality tools.. #worksfineonjdk9 #workslikeheavenonjdk11 Wait, there’s more… #worksfineonjdk9 #workslikeheavenonjdk11 The CI/CD Pipeline Now add more frameworks and languages Add containers and clouds… In a container in your desktop In a container in your CI system Your development Lifecycle Runs on your desk To produce an image … Doesn’t look very “immutable” does it? In a container in your desktop In a container in your CI system Your development Lifecycle Runs on your desk To produce an image … Do these match?
    [Show full text]
  • Db2 for Z/OS Developer Extension —
    Db2 for z/OS Developer Extension — Patrick Bossman Senior Technical Staff Member Db2 for z/OS Development [email protected] https://www.linkedin.com/in/bossman Agenda Objectives VSCode overview • IBM Db2 for z/OS Developer Extension • Zowe Extension Transform the Db2 for z/OS user experience and provides a consistent • IBM Z Open Editor experience in a multicloud environment for application development 2 Transform user experience Key objectives Increase developer talent pool by reducing Z domain specific skills and tools required to work with Db2 for z/OS Reduce cost to development, debug, and tune Db2 for z/OS applications Increase velocity of feature development through improved productivity Extension design is reusabe, portable, easy to integrate with multiple IDE Web-enabled, support client & clientless, cloud ready Align with System Z cloud native development (IBM Z Open Development) 3 How will transforming Db2 for z/OS help Deb Deb Use Web IDE with Db2 services to New z/OS Developer • Code, debug, and tune Java, COBOL, PL1, Node applications that access Db2 for z/OS via SQL • Code, analyze, run, tune SQL statements • Code, debug, and tune Db2 for z/OS stored procedures • Develop Db2 for z/OS Native Rest services 4 Why VSCode Key Points Market Leading IDE • Market leading IDE used Atom 13.3 • Lightweight PyCharm 13.4 • Broad language support Eclipse 14.4 • Z support – Zowe, IBM Z Open Development extensions Android Studio 16.9 • Cloud and desktop IDE Sublime Text 23.4 • Rich git integration Vim 25.4 • Terminal support IntelliJ 25.4
    [Show full text]
  • Web-Based Modeling Tools Theia And
    Building Web-based Modeling Tools with Theia and Che Philip Langer & Maximilian Koegel EclipseSource © 2019 EclipseSource | https://eclipsesource.com | Dres. Langer and Koegel | Building Web-based Modeling Tools with Theia and Che 1 Why web-based tools? ● Accessibility ○ No client installation ○ Access through a web link ○ Simple client updates ○ Physical resource sharing ● Usability ○ Modern UI look and feel ○ SWT vs. HTML5 ○ GEF 3 vs. SVG ● Maintainability ○ Room for evolution ○ Availability of developers © 2019 EclipseSource | https://eclipsesource.com | Dres. Langer and Koegel | Building Web-based Modeling Tools with Theia and Che 2 A prototypical (modeling) tool Workbench Forms Diagrams Text Analysis Generator © 2019 EclipseSource | https://eclipsesource.com | Dres. Langer and Koegel | Building Web-based Modeling Tools with Theia and Che 3 Key enablers for building domain-specific, web-based tools ● Eclipse Theia ○ Extensible cloud IDE ○ Default frontend for Eclipse Che ● Eclipse Che ○ Kubernetes-native IDE platform ○ Management of workspaces and dev environments ● Monaco & Language server protocol (LSP) ○ Protocol enabling the separation of editor (front-end) and language implementation (back-end) ○ Feature-rich and broadly adopted (VS Code) ⇒ Related talk: “Eclipse Theia and Che, explained and explored!”, Today 17:00, Theater Stage © 2019 EclipseSource | https://eclipsesource.com | Dres. Langer and Koegel | Building Web-based Modeling Tools with Theia and Che 4 Reinventing the wheel? ● Which components can be reused? ● What needs
    [Show full text]
  • Visual Programming with Pyworkflow
    Visual Programming with PyWorkflow: A Web-Based Python IDE for Graphical Data Analysis - Milestone 3 Report Samir Reddigari, Matthew Smith, Diego Struk, Matthew Thomas, Cesar Agustin Garcia Vazquez Division of Continuing Education, Harvard University CSCI E-599: Software Engineering Capstone Dr. Peter Henstock May 7th, 2020 2 Index Index 2 Journal Paper 4 Abstract 4 Introduction 5 Review of Literature 6 Visual Programming: A Combination of Necessity and Value 6 Data Workflows as Directed Graphs 6 Existing Visual Programming Platforms for Data Science 7 Web-based IDEs and the Language Server Protocol 8 Visual Programming with PyWorkflow 9 Conclusion and Future Work 12 References 14 Introduction 14 ​ Visual Programming: A Combination of Necessity and Value 14 ​ Data Workflows as Directed Graphs 14 ​ Existing Virtual Programming Platforms for Data Science 15 ​ Web-based IDEs 15 Design of the System 16 ​ Workflow Model 16 ​ Workflow 17 ​ Node 21 Exceptions 24 User Interface 25 ​ Main application screen 25 ​ Node configuration 26 ​ Front-end Architecture 27 Test Results 31 Workflow model 31 ​ REST API Endpoints 32 ​ UI 33 Development Process 34 Meeting the Requirements 34 Technical Decision-Making 35 ​ ​ 3 Estimates 36 Risks 39 Team Dynamic 40 Appendix 43 Screenshots/Wireframes 43 Requirements and Initial Estimation 47 ​ System Installation Manual 49 Relevant Journals 49 4 Abstract Scientists in all fields are tasked with analyzing increasingly large and convoluted datasets. The educational tax of understanding not only the data and their domain, but the analysis software has made the advent of visual programming tools invaluable at all levels of expertise. However, existing solutions lack features critical to modern data science, such as web-friendliness and native support of the Python data ecosystem.
    [Show full text]
  • Automated Migration of Eugenia Graphical Editors to the Web
    Automated Migration of EuGENia Graphical Editors to the Web Fatima Rani Pablo Diez Enrique Chavarriaga UGROUND GLOBAL, S.L UGROUND GLOBAL, S.L UGROUND GLOBAL, S.L Madrid, Spain Madrid, Spain Madrid, Spain [email protected] [email protected] [email protected] Esther Guerra Juan de Lara Universidad Autónoma de Madrid Universidad Autónoma de Madrid Madrid, Spain Madrid, Spain [email protected] [email protected] ABSTRACT 1 INTRODUCTION Domain-specific languages (DSLs) are languages tailored for partic- Model-Driven Engineering (MDE) [29] is a software paradigm that ular domains. Many frameworks and tools have been proposed to prescribes an active use of models during the construction process. develop editors for DSLs, especially for desktop IDEs, like Eclipse. Thus, models are used to describe, validate, simulate, generate code We are witnessing the advent of low-code development plat- and maintain the software, among many other activities. These forms, which are cloud-based environments supporting rapid appli- models can be built using general-purpose modelling languages, cation development by using graphical languages and forms. While such as the Unified Modelling Language (UML), but the useof this approach is very promising, the creation of new low-code plat- Domain-Specific Languages (DSLs) is also common [16]. forms may require the migration of existing desktop-based editors DSLs are languages tailored to a specific problem, containing to the web. However, this is a technically challenging task. customized concepts representing the abstractions within the do- To fill this gap, we present ROCCO, a tool that migrates Eclipse- main [10, 21, 22]. This way, the definition of (graphical) DSLs, and based graphical modelling editors to the web, to facilitate their their modelling environments is recurrent when building MDE integration with low-code platforms.
    [Show full text]
  • The Eclipse Cloud Devtools Ecosystem: Defining the Future of Cloud Native Software Development
    The Eclipse Cloud DevTools Ecosystem: Defining the Future of Cloud Native Software Development White Paper 2 Eclipse Foundation White Paper The Eclipse Cloud DevTools Working Group offers a vendor-neutral ecosystem of open source projects focused on defining, implementing, and promoting best-in-class web and cloud-based development tools. COPYRIGHT (C) 2021, ECLIPSE FOUNDATION, INC. | THIS WORK IS LICENSED UNDER A CREATIVE COMMONS ATTRIBUTION 4.0 INTERNATIONAL LICENSE (CC BY 4.0) 3 Eclipse Foundation White Paper Open Source Software Accelerates Migration of Developer Tools to the Cloud ver the past two decades, most relevant business applications have been migrated to the cloud. More recently, there’s growing awareness that the cloud is also an innovation O platform that accelerates software development.1,2 It’s now well understood that with cloud-based IDEs and For many enterprises, using proprietary cloud tools, developers can more efficiently migrate and build development tools doesn’t make sense because the applications than they can with desktop tools. Cloud tools don’t provide adequate flexibility or control over native tools also enable large and diverse developer the development ecosystem. The flexibility to adapt teams to share the same configuration and runtime tools to domain-specific requirements increases environments, increasing productivity and reducing, developer efficiency. And control over the development if not eliminating, setup times. ecosystem mitigates critical risks associated with developer tools that are often the backbone of business So why has adoption of cloud-based developer tools models and the resulting intellectual property. lagged behind other types of cloud migration? A number of commercial businesses certainly recognized For these and other reasons, open source software the potential early on.
    [Show full text]
  • The Impact of the Language Server Protocol on Textual Domain-Specific Languages
    Decoupling Language and Editor - The Impact of the Language Server Protocol on Textual Domain-Specific Languages Hendrik Bunder¨ itemis AG, Bonn, Germany Keywords: Textual Domain-Specific Languages, Model-Driven Development, Language Server Protocol, Case Study. Abstract: Model-Driven Software Development using Domain-Specific Languages (DSL) has been widely adopted throughout research and industry. The language workbenches required to efficiently build Domain-Specific Languages and the associated editor support are often deeply integrated into a specific Integrated Development Environment (IDE). Thereby, the chosen Domain-Specific Language workbench predicts the IDE required to use the DSL. Yet, this IDE might not be the best choice for further implementing, testing, and debugging the generated code. A case study was conducted to analyze how the Language Server Protocol could be utilized to decouple the DSL implementation from a specific editor integrated into an IDE. First, the Language Server Protocol capabilities are exemplified by building editor support for an Entity-DSL that is integrated into two different IDEs. Second, a SWOT analysis is carried out to identify strengths and weaknesses as well as oppor- tunities and threats for Domain-Specific Languages utilizing the Language Server Protocol. The case study’s results indicate that the Language Server Protocol enables efficient multi-editor integration. Further, the results of the SWOT analysis imply potential benefits for cross-functional teams specifying a shared domain model. 1 INTRODUCTION liJ (JetBrains, 2018) or Eclipse (Vogel and Beaton, 2013). While the deep integration enables semi- Model-Driven software development focuses on the automatic, efficient creation of language editors, it abstract, formal description of domain models, that also causes a tool lock-in by interweaving the DSL declaratively describe real-world concepts.
    [Show full text]