DOCSLIB.ORG

Moving Model Driven Engineering from Eclipse to Web Technologies

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Moving Model Driven Engineering from Eclipse to Web Technologies Moving Model Driven Engineering from Eclipse to Web Technologies Sören Domrös Master’s Thesis November 15, 2018 Prof. Dr. Reinhard von Hanxleden Real-Time and Embedded Systems Group Department of Computer Science Kiel University Advised by Alexander Schulz-Rosengarten Selbstständigkeitserklärung Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Kiel, iii Abstract Eclipse is a popular IDE for model-driven-development. It is a current trend to move IDEs to the web. Web technologies enable to use flexible frameworks for UI development. Moreover, they enable container-based development. An IDE can be used in the web with nothing more than a browser with zero configuration and setup time. Web IDEs need separation between business logic and UI, which is not facilitated by Eclipse. The academic KIELER project is an Eclipse-based IDE for model-driven engineering of SCCharts and other synchronous languages. KIELER can only run as a desktop application and still uses a SWT-based UI. A migration to web technologies seems promising and provides new opportunities for Human Computer Interaction (HCI). Web technologies enable to design applications, which run in the web or locally as an Electron app. In this thesis the Theia framework is used to migrate KIELER from Eclipse to a client server archi- tecture called KEITH using the Language Server Protocol (LSP). The already existing implementation of KIELER is reused to generate a language server backend using Xtext. The LSP and Xtext allow to support KIELER and KEITH development at the same time. The qualitative evaluation of this migration project shows that web technologies can be used to develop an IDE and that Theia is a viable IDE framework, which is highly extensible. The resulting KEITH tool promises to be usable for teaching and conferences. The flexible UI allows to test and develop new UI concepts using HCI. The different setup methods of KEITH make it a highly flexible and configurable development tool. v Acknowledgements I want to give special thanks to my advisor Alexander Schulz-Rosengarten and my professor Dr. Reinhard von Hanxleden for reading everything I gave them and giving constructive criticism. Moreover, I want to thank Steven Smyth for coming up the name KEITH (for Rich Charts (RiCharts)). Without him the resulting tool would be named something less awesome. I want to thank Darth Vader, my friends, Niklas Rentz, and everyone else who supported me during my thesis. Last but not least I want to thank Keith Richards for his music and the similarity of his name to the developed tool. vi Contents 1 Introduction 1 1.1 Cloud Integrated Development Environment (IDE)......................1 1.1.1 Theia............................................2 1.2 The Language Server Protocol.................................2 1.3 Problem Statement........................................3 1.4 Outline...............................................4 2 Preliminaries 7 2.1 IDE Features............................................7 2.2 Eclipse...............................................8 2.3 Kiel Integrated Environment for Layout Eclipse Rich Client (KIELER)...........9 2.3.1 SCCharts and other Grammars.............................9 2.4 Xtext................................................ 10 2.5 The Language Server Protocol................................. 11 2.6 Theia................................................ 13 2.7 TypeScript............................................. 17 2.7.1 Yarn and npm....................................... 19 3 Related Work 21 3.1 Project Migration......................................... 21 3.1.1 ARNO Project....................................... 21 3.1.2 Backtory.......................................... 23 3.1.3 Migration using Model-Driven Engineering..................... 24 3.1.4 Dublo Pattern....................................... 25 3.1.5 General remarks..................................... 26 3.2 Cloud IDEs ............................................. 27 3.2.1 CEclipse.......................................... 27 3.2.2 Eclipse Che........................................ 27 3.2.3 CoreD........................................... 28 3.2.4 Yangster.......................................... 29 3.3 Diagram extension for KIEL Environment Integrated in Theia (KEITH)........... 29 3.4 Alternative LSP projects...................................... 30 3.5 Monto................................................ 30 3.6 Debugging Protocols....................................... 31 4 Migration from Eclipse to Web Technologies 33 4.1 Migration Strategy Discussion................................. 33 4.1.1 Migration Reasons.................................... 33 4.1.2 Migration Strategy.................................... 33 4.1.3 Reusing the Backend................................... 34 4.1.4 Migration Obstacles................................... 37 4.1.5 Operating System (OS)-Independence......................... 38 vii Contents 4.1.6 Migration of Knowledge................................. 39 4.1.7 The Migrated Product.................................. 39 4.1.8 Generalization of IDE Migration Problems...................... 39 4.2 UI Design in Web-based IDEs ................................... 40 4.2.1 Eclipse........................................... 40 4.2.2 Comparison to Modern web IDEs ............................ 40 5 Transforming KIELER into KEITH 43 5.1 Migration Strategy........................................ 43 5.2 Features.............................................. 44 5.3 Build Setup............................................ 47 5.3.1 Bamboo Build....................................... 48 5.3.2 Prerequisites........................................ 49 5.3.3 Building a Product for different OSs .......................... 50 5.4 Migration Process and Development.............................. 50 5.4.1 Upgrading Xtext..................................... 50 5.4.2 Syntax Highlighting for Theia............................. 51 5.4.3 Prototype for KEITH .................................... 51 5.4.4 Extending the KEITH Prototype............................. 51 5.5 Language Server......................................... 52 5.6 Theia extension.......................................... 53 5.6.1 Theia Backend...................................... 53 5.6.2 Theia Frontend...................................... 55 5.6.3 Creating a widget.................................... 57 5.7 Extending the LSP ......................................... 59 5.7.1 Server side LSP extension................................ 59 5.7.2 Client Side LSP Extension................................ 60 5.7.3 Combining two LSP extensions in Theia........................ 61 5.8 Development Setup........................................ 62 6 Evaluation and Experience Report 65 6.1 Migration Process......................................... 65 6.1.1 Language Server..................................... 65 6.1.2 Theia Extension...................................... 68 6.1.3 OS-Independence..................................... 71 6.2 Development Tools........................................ 72 6.2.1 Development in VSCode................................. 72 6.2.2 Development in Eclipse................................. 73 6.3 Performance Testing....................................... 73 6.3.1 Reactivity......................................... 73 6.3.2 Scalability......................................... 74 6.3.3 Maintainability...................................... 75 6.4 Use of KEITH in Teaching..................................... 76 6.5 Comparison............................................ 76 viii Contents 7 Conclusion 79 7.1 Summary.............................................. 79 7.1.1 Migration......................................... 79 7.1.2 Implementation...................................... 79 7.2 Future Work............................................ 80 7.2.1 Restructuring of KEITH and Further Development.................. 80 7.2.2 Build Setup and Automation.............................. 81 7.2.3 Future Tools for Theia and KEITH ............................ 81 7.2.4 Usage for Teaching.................................... 81 7.2.5 Build Language Server as fat jar............................ 82 7.2.6 Publishing of Xtext Fragment.............................. 82 7.2.7 Research regarding Usability of KEITH ......................... 82 Bibliography 83 Abbreviations 87 ix List of Figures 1.1 m IDEs n languages solution...................................3 1.2 Yang for four IDEs .........................................4 2.1 UI of KIELER ............................................ 10 2.2 Language server communication during a session..................... 11 2.3 Communication with multiple language servers....................... 13 2.4 Theia browser and Electron version.............................. 14 2.5 Communication for different Theia products......................... 15 2.6 Theia package composition................................... 16 2.7 Theia started using docker................................... 16 2.8 Variation of defect proneness of languages for a given domain [RPF+14]........ 18 3.1 The Amadeus Germany System [Tep09]........................... 22 3.2 Continuous delivery using microservices [BHJ16]...................... 23 3.3 Team restructuring for DevOps [BHJ16]........................... 24 3.4 Model-driven migration principle [FBB+07]......................... 25 3.5 Structural view on
Load more

Recommended publications
  • Alnao Debian Handbook
    AlNao Debian HandBook Nao Alberto (www.alnao.it) December 5, 2020 AlNao Debian 10 HandBook Autore Nao Alberto ([email protected]) Disponibile su www.alnao.it Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Docu- mentation License, Version 1.2 or any later version published by the Free Software Foundation. E` garantito il permesso di copiare, distribuire e/o modificare questo documento in base ai termini della GNU Free Documentation License, Versione 1.2 o ogni versione successiva pubblicata dalla Free Software Foundation. Scritto da Nao Alberto (www.alnao.it - [email protected]) con LATEX con l'editor Kile Forse un giorno riuscir`oa finire questa maledetta cosa che chiamo manuale Prima edizione (solo appunti, versione Debian 3.1 Sarge): 2006 Seconda edizione (versione Debian 4 Etch): 2008 Terza edizione (in inglese, incompleta, Debian 5): 2011/2012 Quarta edizione (versione Debian 8): 2015/2016 Quinta edizione (versione Debian 9): 2018 Sesta edizione (versione Debian 10): 2020 Contents 1 Introduzione 7 1.1 Perch`equesto manuale? . 7 1.2 Perch´eLinux? . 7 1.3 Note e Convenzioni . 8 1.4 Correttezza di questo manuale . 9 2 Installazione di Debian 10 2.1 Come e dove trovare Debian . 10 2.1.1 Le versioni di Debian . 11 2.2 Avvio dell'installazione . 11 2.3 Configurazioni del sistema (rete, partizioni ed utenti) . 12 2.4 Copia del sistema base e impostazioni finali . 12 2.5 Il primo avvio . 13 2.6 Installazione dalla versione live . 13 3 Configurazioni base 15 3.1 Gestione di cartelle e file .
    [Show full text]
  • An Overview of Platforms for Cloud Based Development G
    Fylaktopoulos et al. SpringerPlus (2016) 5:38 DOI 10.1186/s40064-016-1688-5 REVIEW Open Access An overview of platforms for cloud based development G. Fylaktopoulos1, G. Goumas2, M. Skolarikis1, A. Sotiropoulos3 and I. Maglogiannis4* Abstract This paper provides an overview of the state of the art technologies for software development in cloud environments. The surveyed systems cover the whole spectrum of cloud-based development including integrated programming environments, code repositories, software modeling, composition and documentation tools, and application man- agement and orchestration. In this work we evaluate the existing cloud development ecosystem based on a wide number of characteristics like applicability (e.g. programming and database technologies supported), productiv- ity enhancement (e.g. editor capabilities, debugging tools), support for collaboration (e.g. repository functionality, version control) and post-development application hosting and we compare the surveyed systems. The conducted survey proves that software engineering in the cloud era has made its initial steps showing potential to provide con- crete implementation and execution environments for cloud-based applications. However, a number of important challenges need to be addressed for this approach to be viable. These challenges are discussed in the article, while a conclusion is drawn that although several steps have been made, a compact and reliable solution does not yet exist. Keywords: Cloud computing, Integrated Development Environment (IDE), Code repositories, Software modeling, Orchestration tools Background application side, large families of applications including Within the past few years, cloud computing has emerged desktop, business, entertainment (Simmhan et al. 2010; as a dominant computing model in IT infrastructures, Schmidt 2012; Hobfeld et al.
    [Show full text]
  • Eclipse Theia Vs Che Vs VS Code.Pdf
    Eclipse Theia vs Che vs VS Code Jonas Helming EclipseSource © 2020 EclipseSource | https://eclipsesource.com | Dr. Jonas Helming | Eclipse Theia vs Che vs VS Code 1 Agenda ● VS Code vs. Eclipse Theia ● VS Codespaces vs. Eclipse Che ● Conclusion © 2020 EclipseSource | https://eclipsesource.com | Dr. Jonas Helming | Eclipse Theia vs Che vs VS Code 2 Eclipse Theia vs. VS Code (online, project) © 2020 EclipseSource | https://eclipsesource.com | Dr. Jonas Helming | Eclipse Theia vs Che vs VS Code 3 What is VS Code? ● An extensible Code Editor / IDE ○ Free of charge / built on open source ○ Thousands of extensions available ○ Downloadable desktop tool © 2020 EclipseSource | https://eclipsesource.com | Dr. Jonas Helming | Eclipse Theia vs Che vs VS Code 4 What is the VS Code project? ● The open source project, which is the base of VS Code ○ Very active development and innovation ○ Driven by Microsoft + contributors ○ Use by other tools such as: ■ VS Codium ■ Eclipse Theia © 2020 EclipseSource | https://eclipsesource.com | Dr. Jonas Helming | Eclipse Theia vs Che vs VS Code 5 What is “VS Code Online”? ● Online version of VS Code hosted in VS Codespaces ○ Runs in the browser ○ Bound to Azure ○ Currently not open source © 2020 EclipseSource | https://eclipsesource.com | Dr. Jonas Helming | Eclipse Theia vs Che vs VS Code 6 What is Eclipse Theia? ● An open source platform for building web-based tools and IDEs ○ Supports local and cloud/online deployment ○ A modular and flexible architecture ○ Project fully open source and hosted at the Eclipse Foundation © 2020 EclipseSource | https://eclipsesource.com | Dr. Jonas Helming | Eclipse Theia vs Che vs VS Code 7 Product vs.
    [Show full text]
  • An Intro to Eclipse Che Next-Generation Eclipse IDE & Open Source Alternative to Intellij
    An Intro to Eclipse Che Next-Generation Eclipse IDE & Open Source Alternative to IntelliJ January 2016 Tyler Jewell, Eclipse Che Project Lead @TylerJewell The Application Trinity Develop Apps Deliver Apps Host Apps check out & issue mgmt source code repo unit test quality control test build code pre-production agile ide package & integration deploy to test production archiving testing environment deploy to pre- acceptance deploy to production testing production continuous packaging & code quality integration build tools analysis testing artifact release mgmt workspace frameworks repository 100 firms including Atlassian, JetBrains, Puppet, Chef, Ansible, ZeroTurnaround, IBM, Electric Cloud, Coverity, Sonatype, JFrog, and so on... Big Hairy Audacious Goal Let anyone contribute to any project anywhere at any time. no pre-installation required ready to participate in any branch flow always compiles and runs How http://someurl/factory?id=a_project 1. Create new, or load existing, workspace 2. Populate workspace with projects 3. Fetch source 4. Inject tools (compiler, ssh, intellisense) 5. Create runtime 6. Onboard developer into workspace A New Workspace Is Needed Eclipse Che - Next Generation Eclipse IDE Che: IDE + Workspace Server + Plug-Ins Cloud IDE Collaborative WS Server Plug-In Framework A no-installation browser IDE and Host Eclipse Che as a workspace Che includes a growing set of plug- IOE accessible from any local or server. Share tools, runtime and ins. You can also create and remote device. Thin, fast, and programming services across
    [Show full text]
  • Metadefender Core V4.12.2
    MetaDefender Core v4.12.2 © 2018 OPSWAT, Inc. All rights reserved. OPSWAT®, MetadefenderTM and the OPSWAT logo are trademarks of OPSWAT, Inc. All other trademarks, trade names, service marks, service names, and images mentioned and/or used herein belong to their respective owners. Table of Contents About This Guide 13 Key Features of Metadefender Core 14 1. Quick Start with Metadefender Core 15 1.1. Installation 15 Operating system invariant initial steps 15 Basic setup 16 1.1.1. Configuration wizard 16 1.2. License Activation 21 1.3. Scan Files with Metadefender Core 21 2. Installing or Upgrading Metadefender Core 22 2.1. Recommended System Requirements 22 System Requirements For Server 22 Browser Requirements for the Metadefender Core Management Console 24 2.2. Installing Metadefender 25 Installation 25 Installation notes 25 2.2.1. Installing Metadefender Core using command line 26 2.2.2. Installing Metadefender Core using the Install Wizard 27 2.3. Upgrading MetaDefender Core 27 Upgrading from MetaDefender Core 3.x 27 Upgrading from MetaDefender Core 4.x 28 2.4. Metadefender Core Licensing 28 2.4.1. Activating Metadefender Licenses 28 2.4.2. Checking Your Metadefender Core License 35 2.5. Performance and Load Estimation 36 What to know before reading the results: Some factors that affect performance 36 How test results are calculated 37 Test Reports 37 Performance Report - Multi-Scanning On Linux 37 Performance Report - Multi-Scanning On Windows 41 2.6. Special installation options 46 Use RAMDISK for the tempdirectory 46 3. Configuring Metadefender Core 50 3.1. Management Console 50 3.2.
    [Show full text]
  • Basic Guide: Using VIM Introduction: VI and VIM Are In-Terminal Text Editors That Come Standard with Pretty Much Every UNIX Op
    Basic Guide: Using VIM Introduction: VI and VIM are in-terminal text editors that come standard with pretty much every UNIX operating system. Our Astro computers have both. These editors are an alternative to using Emacs for editing and writing programs in python. VIM is essentially an extended version of VI, with more features, so for the remainder of this discussion I will be simply referring to VIM. (But if you ever do research and need to ssh onto another campus’s servers and they only have VI, 99% of what you know will still apply). There are advantages and disadvantages to using VIM, just like with any text editors. The main disadvantage of VIM is that it has a very steep learning curve, because it is operated via many keyboard shortcuts with somewhat obscure names like dd, dw, d}, p, u, :q!, etc. In addition, although VIM will do syntax highlighting for Python (ie, color code things based on what type of thing they are), it doesn’t have much intuitive support for writing long, extensive, and complex codes (though if you got comfortable enough you could conceivably do it). On the other hand, the advantage of VIM is once you learn how to use it, it is one of the most efficient ways of editing text. (Because of all the shortcuts, and efficient ways of opening and closing). It is perfectly reasonable to use a dedicated program like emacs, sublime, canopy, etc., for creating your code, and learning VIM as a way to edit your code on the fly as you try to run it.
    [Show full text]
  • Don't Build and Push, Move Your Inner Loop to Your Cluster!
    Don't build and push, move your inner loop to your cluster! RAMIRO BERRELLEZA | @RBERRELLEZA Hey everyone! • Co-founder of Okteto. • Former architect @ Atlassian, Software Engineer @ Azure. • @rberrelleza in most places. Application architecture has evolved a lot in the past few years... Challenges Challenges We solved production*, but at the expense of the development experience. Building Cloud Native Applications is hard. An inner loop full of friction makes it harder to develop even the simpler features. https://twitter.com/ellenkorbes/status/1143451907492 655105 Community Automate the inner loop • Skaffold • Draft • Garden • Tilt Community Dev environments on demand • Visual Studio Code Online • Code Ready workspaces (Eclipse Che) • Jenkins X But we're still waiting on builds and deploys. … and dev, stage and prod are completely different We started Okteto to give us a better developer experience in Kubernetes Demo time! • https://github.com/rberrelleza/movies-demo How does it work? With okteto you get • A manifest + container development environment • Automatic file synchronization between local and remote env • A remote terminal into your development environment • Forward and Reverse port-forwarding • Integration JetBrain and VSCode's remote development modes • Single binary, works on linux, macos and windows Developing in the same environment as your applications are going to run lets you go way faster. You are not waiting on builds and deploys. And you’re fully integrated from the very beginning. You can leverage the entire platform as well as your stack’s toolkit. Incremental builds. Hot reloaders. Debuggers! Okteto works with anything that speaks Kubernetes • Local clusters: Minikube, k3s, kind • Remote clusters: EKS, GKE, AKS, Digital Ocean, Civo • Kubernetes Manifests • Helm • Serverless functions • ….
    [Show full text]
  • Xtext / Sirius - Integration the Main Use-Cases
    Xtext / Sirius - Integration The Main Use-Cases White Paper December 2017 SUMMARY Chapter 1 Introduction 1 Chapter 2 Let’s start 2 Chapter 2.1 What modeling is about? 2 Chapter 2.2 Benefits of graphical modeling 3 Chapter 2.3 Benefits of textual modeling 5 Chapter 3 What is Xtext? 6 Chapter 4 What is Sirius? 8 Chapter 5 Xtext & Sirius in action 10 Chapter 5.1 Case 1: Editing the same models both graphically and textually 10 Chapter 5.2 Case 2: Embedding an Xtext Editor into Sirius 15 Chapter 6 How may we help you? 18 Introduction Introduction You are going to create a domain-specific modeling tool and you wonder how users will edit and visualize the models: textually with a dedicated syntax and a rich textual editor ? or graphically with diagrams drawn with a palette and smart tools? Both approaches are interesting and can be used complementary: While text is able to carry more detailed information, a diagram highlights the relationship between elements much better. In the end, a good tool should combine both, and use each notation where it suits best. In this white paper, we will explain the benefits of each approach. Then we will present Eclipse Xtext and Eclipse Sirius, two open-source frameworks for the development of textual and graphical model editors. And finally, we will detailed two use-cases where these two technologies can be integrated in the same modeling workbench. 1 Let’s start Let’s start What modeling is about? Before presenting the graphical and textual modeling approaches, it is important to briefly clarify what we mean by modeling.
    [Show full text]
  • Appendix a the Ten Commandments for Websites
    Appendix A The Ten Commandments for Websites Welcome to the appendixes! At this stage in your learning, you should have all the basic skills you require to build a high-quality website with insightful consideration given to aspects such as accessibility, search engine optimization, usability, and all the other concepts that web designers and developers think about on a daily basis. Hopefully with all the different elements covered in this book, you now have a solid understanding as to what goes into building a website (much more than code!). The main thing you should take from this book is that you don’t need to be an expert at everything but ensuring that you take the time to notice what’s out there and deciding what will best help your site are among the most important elements of the process. As you leave this book and go on to updating your website over time and perhaps learning new skills, always remember to be brave, take risks (through trial and error), and never feel that things are getting too hard. If you choose to learn skills that were only briefly mentioned in this book, like scripting, or to get involved in using content management systems and web software, go at a pace that you feel comfortable with. With that in mind, let’s go over the 10 most important messages I would personally recommend. After that, I’ll give you some useful resources like important websites for people learning to create for the Internet and handy software. Advice is something many professional designers and developers give out in spades after learning some harsh lessons from what their own bitter experiences.
    [Show full text]
  • Galileo Release Train 2009
    Galileo Release Train 2009 1 6 Years in a Row 33 Projects 24 million LOC 23 Projects 18 million LOC 21 Projects 17 million LOC 10 Projects WTP BIRT TPTP TPTP EMF CDT VE CDT Ganymede Galileo Eclipse 3.0 Eclipse 3.1 Callisto Europa June 28 2004 June 28 2005 June 30 2006 June 29, 2007 June 25, 2008 June 24, 2008 2 Galileo Stats - 33 project teams - 24+ million LOC - 44 companies providing committers 3 Why a release train? Help spur commercial adoption of Eclipse technology Consumers use many projects not just the Platform Inter-dependency between projects Eclipse project teams are independent BUT the project code is inter-dependent. Alignment of version compatibility Remove latency between project releases 4 How did we make it happen? Architecture Modular & Extensible Architecture vs Monolithic Release Governance Projects remain independent Process Open source development process Frequent milestone releases 5 Key Themes Advancement in Eclipse Runtime Technology Growth of Eclipse Modeling Domain Specific Languages Expanding Enterprise Adoption 6 Eclipse Runtime Technology New Support for OSGi in Equinox Implementation of the new OSGi 4.2 specification Distributed OSGi services PDE Improvements OSGI Declarative Services tooling Publish to a p2 repository API Analysis Tools Target platform support in PDE Make it easier to develop software that runs on EclipseRT runtimes EclipseRT runtime SDKs available in Galileo repository PDE tooling P2 Provisioning Improvements More flexible UI for RCP applications New Publisher tool that make it easier to publish content to repositories 7 Modeling Domain Specific Languages Developers need to deal with a growing set of APIs APIs for different infrastructure services, standards, business standards, etc.
    [Show full text]
  • Eclipse Roadmap V5
    Eclipse RoadMap v5 Introduction As required by the Eclipse Development Process, this document describes the 2010 Eclipse Roadmap. There are three main sections to this document: 1. This Preamble provides some background on Eclipse and the Foundation, and identifies the strategic goals of Eclipse. It also provides a brief overview of the scope of future projects 2. The Themes and Priorities which has been developed by the Eclipse Councils. 3. The Platform Release Plan which has been developed by the Eclipse Planning Council. The Roadmap is intended to be a living document which will see future iterations. This document is the fifth version of the Eclipse Roadmap, and is labeled as version 5.0. In order to preserve this document while the underlying information evolves, the pages have been frozen by copying them from their original project hosted locations. The goal of the Roadmap is to provide the Eclipse ecosystem with guidance and visibility on the future directions of the Eclipse open source community. An important element in this visibility is that the Roadmap help the EMO and the Board of Directors in determining which projects will be accepted by Eclipse during the life of this revision of the Roadmap. In other words, new projects must be consistent with the Roadmap. This does not mean that every new project must be explicitly envisaged by the Roadmap. It does mean that new projects cannot be inconsistent with the stated directions of Eclipse. In particular, Eclipse expects that incubator projects created in the Technology PMC will cover areas not explicitly described in the Roadmap.
    [Show full text]
  • Flexible Graphical Editors for Extensible Modular Meta Models
    X perf =1.00 X loss =0.01 SDSoftware Design and Quality Flexible Graphical Editors for Extensible Modular Meta Models Master’s Thesis of B.Sc. Michael Junker at the Department of Informatics Institute for Program Structures and Data Organization (IPD) Reviewer: Prof. Dr. Ralf Reussner Second reviewer: Jun.-Prof. Dr.-Ing. Anne Koziolek Advisor: Dipl.-Inform. Misha Strittmatter Second advisor: M.Sc. Heiko Klare 12. April 2016 – 11. October 2016 Karlsruher Institut für Technologie Fakultät für Informatik Postfach 6980 76128 Karlsruhe I declare that I have developed and written the enclosed thesis completely by myself, and have not used sources or means without declaration in the text. Karlsruhe, 10.October 2016 .................................... (B.Sc. Michael Junker) Abstract In model-driven software development, graphical editors can be used to create model instances more eciently and intuitively than with pure XML code. These graphical editors rely on models created on the basis of a meta-model. If such a meta-model is extended invasively not only its code has to be re-generated but also the graphical editor needs to be adapted. When developing multiple extensions, the meta-model as well as the corresponding graphical editor tend to get complex and error-prone. One way of coping with this complexity is to use modular meta-models and extending them noninvasively. However, having multiple meta-model fragments providing extended features is only half the job as equivalent graphical editors are needed as well. This master’s thesis therefore analyzes dierent types of extensions for meta-models as well as on graphical editor level.
    [Show full text]