DOCSLIB.ORG

Developing User Interfaces with EMF Parsley

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Developing User Interfaces with EMF Parsley Developing User Interfaces with EMF Parsley Lorenzo Bettini∗ Dipartimento di Informatica, Universita` di Torino, Torino, Italy Keywords: EMF, Modeling, Eclipse, User Interface, DSL. Abstract: In this paper we describe the main features of EMF Parsley, a new Eclipse project for implementing appli- cations based on the Eclipse Modeling Framework (EMF). EMF Parsley aims at complementing the EMF reflective mechanisms with respect to rapidly creating user interfaces based on models, without having to deal with internal details and setup code. In particular, EMF Parsley uses injection mechanisms to easily customize all the aspects of such applications. Moreover, it provides a set of reusable user interface components like trees, tables and detail forms that manage the model with the introspective EMF capabilities, together with reusable views, editors and dialogs. Besides project wizards, to easily create projects based on EMF Pars- ley, the main developing tool is a DSL, implemented with Xtext/Xbase, that provides a rapid customization mechanism. 1 INTRODUCTION Xtext (Itemis, 2014; Eysholdt and Behrens, 2010; Bettini, 2013a), for making the use of our framework The Eclipse Modeling Framework (EMF) (Steinberg easier: customizations can be specified in a compact et al., 2008) simplifies the development of complex form in a single file. software applications with its modeling mechanisms. EMF Parsley is the evolution of EMF Compo- However, the development of user interfaces based on nents (Bettini, 2012; Bettini, 2013b); EMF Compo- EMF still requires an extensive setup and the knowl- nents was a first experiment with building automati- edge of many internal details. For these reasons, in cally applications based on EMF models. EMF Pars- this paper, we present a new Eclipse framework, EMF ley is a huge evolution with this respect: we focused Parsley; this has been recently approved as an official to make the initial setup easier (using project wiz- Eclipse project and it is in its incubation phase. ards); the same holds for customizations of all the EMF Parsley provides a framework to easily de- behaviors, in particular the DSL helps a lot with this velop user interfaces based on EMF models. The respect. framework hides most of the complexity of internal The paper is structured as follows: in Section 2 we details. Creating a JFace viewer and connecting it introduce our motivations, while in Section 3 we de- to an EMF resource, usually requires a few lines of scribe the design choices and the main features of our code. Furthermore, the customization of specific be- framework by examples. Section 4 describes our DSL haviors is also easy thanks to the use of Google Guice, (and some examples) and Section 5 presents some ad- a Dependency Injection framework, and thanks to the ditional features of EMF Parsley. Section 6 concludes polymorphic method dispatch mechanism that allows the paper with related work and hints for future direc- to write cleaner declarative code. This maximizes tions. code reuse and promotes a programming style where the classes implemented by the programmer are usu- ally very small and deal with only a few aspects. The 2 MOTIVATIONS framework comes with some UI widgets to be used out-of-the-box (including trees, tables, dialogs and forms, and view and editor parts). EMF.Edit (Steinberg et al., 2008) is an EMF frame- We also provide a DSL, implemented in work with generic reusable classes for editing EMF models. The programmer can use these mechanisms ∗The paper was partly supported by RCP Vision, to implement UI parts for the EMF models. The prob- www.rcp-vision.com. lem is that all these mechanisms have to be setup and 58 Bettini L.. Developing User Interfaces with EMF Parsley. DOI: 10.5220/0004990800580066 In Proceedings of the 9th International Conference on Software Paradigm Trends (ICSOFT-PT-2014), pages 58-66 ISBN: 978-989-758-037-6 Copyright c 2014 SCITEPRESS (Science and Technology Publications, Lda.) DevelopingUserInterfaceswithEMFParsley 1 adFact = new ComposedAdapterFactory( public class BookItemProvider extends ... ComposedAdapterFactory.Descriptor.Registry. 2 f INSTANCE); /∗∗ @generated NOT ∗/ adFact.addAdapterFactory(new 4 @Override public Object getImage(Object object) ResourceItemProviderAdapterFactory()); f 3 adFact.addAdapterFactory(new return overlayImage(object, MyModelItemProviderAdapterFactory()); 6 getResourceLocator().getImage("mypath/ adFact.addAdapterFactory(new custom_book.png")); g ReflectiveItemProviderAdapterFactory()); 5 8 /∗∗ @generated NOT ∗/ BasicCommandStack cmdStack = new @Override public String getText(Object object) f BasicCommandStack(); 10 return "Book: " + "" + ((Book)object). 7 cmdStack.addCommandStackListener(new getTitle(); CommandStackListener()f...g); g 9 edDom = new AdapterFactoryEditingDomain( Listing 2: An example of typical customization of EMF adFact,cmdStack,...); labeling. 11 Tree tree = new Tree(composite, SWT.MULTI); ResourceLocator, etc.). Furthermore, if we want TreeViewer viewer = new TreeViewer(tree); to customize the labels and images for all the ele- 13 ments of the model, we need to modify all generated viewer.setContentProvider(new ItemProvider classes. With this respect, we want to AdapterFactoryContentProvider(adFact)); provide in EMF Parsley a much easier customization 15 viewer.setLabelProvider(new AdapterFactoryLabelProvider(adFact)); mechanism. viewer.setInput(edDom.getResourceSet()); A problem with the @generated and @generated 17 NOT mechanism is that it is difficult to keep track of new AdapterFactoryTreeEditor(viewer.getTree(), custom modifications to the generated code. Indeed adFact); generated and custom code are mixed together in the Listing 1: An example of typical use of EMF.Edit. same Java file. This makes such code much harder to maintain. A more appealing solution is the Gen- eration Gap (Vlissides, 1996), a pattern that solves initialized correctly in order to achieve the desired the problem of maintainability of coexisting gener- features. This initialization phase takes many lines ated and manual code by relying on class inheritance: of code, and usually requires some deeper knowledge there will be a class that encapsulates generated code of EMF internals. In Listing 1 we show the typical and another one class that encapsulates modifications. Java code one needs to write to setup a viewer with We will follow this pattern in the DSL (as we will EMF.Edit. As we will show in the next sections, our show in Section 4). By using this pattern, generated goal is to factor out this boilerplate code in such a way and custom code are clearly separated in different files that UI components can be setup with only a few lines and are then much easier to maintain (in our case, they of code. are also stored in different source folders). Keeping EMF has some generation mechanisms for the generated and custom code separate also makes it eas- user interface. However, there are many problems ier to store them in source control systems (e.g., Git, when using this generated code; we will detail such SVN, etc.); not to mention that when using a contin- problems in the following. uous integration build system, generated code needs EMF generation mechanisms are based on not to be checked in the version control system, since Javadoc comments @generated for fields, methods it can be generated during the build. This significantly and classes. Future generations will overwrite all the reduces the size of the source control system database. previously generated Java code elements unless the For all these reasons we felt the need of creating a programmer removes that @generated from specific new framework built on top of EMF, to avoid all the declarations (or replaces it with @generated NOT). above issues and to make the creation, customization In Listing 2 we show an example of customiza- and maintenance of EMF applications much easier, as tion of labeling in a class generated by EMF (related we will show in the next sections. to the classic EMF Library example). In order to specify the image for instances of Book we need to go into the generated ItemProvider class, and spec- ify the path of the image (note the presence of other distracting and internal details like overlayImage, 59 ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends 3 EMF PARSLEY 1 class MyModule extends EmfParsleyGuiceModule f In this Section we present the most relevant fea- public Class<? extends ResourceLoader> bindResourceLoader() f tures of EMF Parsley through examples; this Eclipse 3 return MyResourceLoader.class; project is still in the incubation phase, thus more fea- g tures will be provided in the future (see also Section 6 5 public Class<? extends ILabelProvider> for future work). bindILabelProvider() f return MyLabelProvider.class; 7 g 3.1 Overview public Class<? extends IContentProvider> bindIContentProvider() f Our main design choice in developing EMF Parsley 9 return MyContentProvider.class; was to split responsibilities into small classes; this g way, customizing a single aspect of UI parts does not 11 ... g require to subclass the parts themselves, but only to customize the class related to that specific aspect. Listing 3: A Guice module with bindings. In order to handle the customized behaviors in a consistent way, we heavily use Google Guice, a 3. “Inject” one of our classes; Dependency Injection framework. With respect to 4. Customize specific aspects and configure the manual implementation of existing patterns (Gamma Guice module to use the custom implementations. et al.,
Load more

Recommended publications
  • 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]
  • 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]
  • PRISM Model Checker As an Eclipse-Plugin
    MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345<yA|NFORMATICS PRISM model checker as an Eclipse-plugin DIPLOMA THESIS Bc. Milan Malota Brno, Autumn 2015 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. In Brno, January 11, 2016 Bc. Milan Malota Advisor: RNDr. Vojtechˇ Rehˇ ak,´ Ph.D. ii Acknowledgement I would like to thank my advisor Vojtechˇ Rehˇ ak´ for valuable advice, com- ments, support and patience during the writing of this thesis. I also want to express my gratitude to my family and my girlfriend for their support during studies. iii Abstract PRISM is a probabilistic model checker and is used in many different ap- plication domains and is well known among scientists dealing with formal modeling and analysis of systems that exhibit random or probabilistic be- havior. PRISM’s GUI was developed in the beginning of the PRISM life cycle and technologies made great progress so it can seem obsolete. That is why the request for a new GUI was pronounced. One of the platforms suitable for integrating an application and preferred by the original development team is the Eclipse platform. In the scope of this thesis we analyze available Eclipse platforms and notable graphical user interface frameworks. On the basis of the analysis new graphical user interface allowing all funcionality of the current PRISM GUI is implemented. iv Keywords PRISM, Eclipse RCP, Eclipse e4, AWT, Swing, SWT, JFace, Albireo v Contents 1 Introduction ...............................3 1.1 Motivation .............................3 2 Preliminaries ..............................5 2.1 PRISM model checker ......................5 2.1.1 The PRISM language .
    [Show full text]
  • Code Smell Prediction Employing Machine Learning Meets Emerging Java Language Constructs"
    Appendix to the paper "Code smell prediction employing machine learning meets emerging Java language constructs" Hanna Grodzicka, Michał Kawa, Zofia Łakomiak, Arkadiusz Ziobrowski, Lech Madeyski (B) The Appendix includes two tables containing the dataset used in the paper "Code smell prediction employing machine learning meets emerging Java lan- guage constructs". The first table contains information about 792 projects selected for R package reproducer [Madeyski and Kitchenham(2019)]. Projects were the base dataset for cre- ating the dataset used in the study (Table I). The second table contains information about 281 projects filtered by Java version from build tool Maven (Table II) which were directly used in the paper. TABLE I: Base projects used to create the new dataset # Orgasation Project name GitHub link Commit hash Build tool Java version 1 adobe aem-core-wcm- www.github.com/adobe/ 1d1f1d70844c9e07cd694f028e87f85d926aba94 other or lack of unknown components aem-core-wcm-components 2 adobe S3Mock www.github.com/adobe/ 5aa299c2b6d0f0fd00f8d03fda560502270afb82 MAVEN 8 S3Mock 3 alexa alexa-skills- www.github.com/alexa/ bf1e9ccc50d1f3f8408f887f70197ee288fd4bd9 MAVEN 8 kit-sdk-for- alexa-skills-kit-sdk- java for-java 4 alibaba ARouter www.github.com/alibaba/ 93b328569bbdbf75e4aa87f0ecf48c69600591b2 GRADLE unknown ARouter 5 alibaba atlas www.github.com/alibaba/ e8c7b3f1ff14b2a1df64321c6992b796cae7d732 GRADLE unknown atlas 6 alibaba canal www.github.com/alibaba/ 08167c95c767fd3c9879584c0230820a8476a7a7 MAVEN 7 canal 7 alibaba cobar www.github.com/alibaba/
    [Show full text]
  • Xtext User Guide
    Xtext User Guide Xtext User Guide Heiko Behrens, Michael Clay, Sven Efftinge, Moritz Eysholdt, Peter Friese, Jan Köhnlein, Knut Wannheden, Sebastian Zarnekow and contributors Copyright 2008 - 2010 Xtext 1.0 1 1. Overview .................................................................................................................... 1 1.1. What is Xtext? ................................................................................................... 1 1.2. How Does It Work? ............................................................................................ 1 1.3. Xtext is Highly Configurable ................................................................................ 1 1.4. Who Uses Xtext? ................................................................................................ 1 1.5. Who is Behind Xtext? ......................................................................................... 1 1.6. What is a Domain-Specific Language ..................................................................... 2 2. Getting Started ............................................................................................................ 3 2.1. Creating a DSL .................................................................................................. 3 2.1.1. Create an Xtext Project ............................................................................. 3 2.1.2. Project Layout ......................................................................................... 4 2.1.3. Build Your Own Grammar ........................................................................
    [Show full text]
  • Easy Development of Web Applications Using Webodra2 and a Dedicated IDE
    International Journal on Advances in Internet Technology, vol 6 no 3 & 4, year 2013, http://www.iariajournals.org/internet_technology/ 156 Easy Development of Web Applications using WebODRA2 and a Dedicated IDE Mariusz Trzaska Chair of Software Engineering Polish-Japanese Institute of Information Technology Warsaw, Poland [email protected] Abstract - The modern Web requires new ways for creating proposed to solve or reduce the problem. In particular, applications. We present our approach combining a web following Trzaska [2], the solution could use a single model framework with a modern object-oriented database and a both for the business logic and data. dedicated Integrated Development Environment (IDE). It Aside of frameworks, one of the most popular software, makes it easier to develop web applications by rising the level of widely utilized by programmers, is an Integrated abstraction. In contrast to many existing solutions, where the Development Environment (IDE). Various IDEs are on the business logic is developed in an object-oriented programming scene for many years. They provide many different services language and data is stored and processed in a relational system, and are invaluable help during software development. At the our proposal employs a single programming and query basic level they just support a programming language. language. Such a solution, together with flexible routing rules, However, their real power can be experienced when they have creates a coherent ecosystem and, as an additional benefit, reduces the impedance mismatch. Our research is supported by dedicated functionalities for particular frameworks. Similarly a working prototype of the IDE and a web framework for our to the situations with the frameworks, prototype solutions are own object-oriented database management system.
    [Show full text]
  • DSLFORGE: Textual Modeling on the Web
    DSLFORGE: Textual Modeling on the Web Amine Lajmi1, Jabier Martinez2;3, and Tewfik Ziadi3 1 Software Architect, Paris, France, [email protected] 2 SnT, University of Luxembourg, Luxembourg, [email protected] 3 LIP6, Universit´ePierre et Marie Curie, Paris, France, [email protected] Abstract. The use of Model-Driven Engineering in software develop- ment is increasingly growing in industrial applications as the technolo- gies are becoming more mature. In particular, domain-specific languages bring to end-users simplicity of use and productivity by means of var- ious artifacts generators. However, end-users still need to cope with heavy modeling infrastructures and complex deployment procedures, be- fore being able to work on models. In this paper, we propose a central- ized lightweight approach for performing textual modeling through web browsers. DSLFORGE is a generator of online text editors. Given a lan- guage grammar, the tool allows to generate lightweight web editors, sup- porting syntax highlighting, syntax validation, scoping, and code com- pletion. DSLFORGE allows also automatic integration of existing code generators into the generated web editor providing a complete online modeling user experience. Demo: http://youtu.be/KN6cneWhhKY Keywords: textual modeling, online editor, model-driven engineering, domain-specific languages 1 Introduction Domain-Specific Languages (DSL) [10] let end-users feel the advantages of using domain abstractions instead of general-purpose language constructs. Therefore, Model-Driven Engineering (MDE) is gaining more success in industrial applica- tions as the available methods and tools are becoming more mature. Modeling technologies have made big steps towards better integration and simplicity of use and, as a consequence, domain-specific standards have met great success within multiple communities (e.g.
    [Show full text]
  • Xtext Documentation.Pdf
    Xtext Documentation September 26, 2014 Contents I. Getting Started 9 1. 5 Minutes Tutorial 10 1.1. Creating A New Xtext Project . 10 1.2. Generating The Language Infrastructure . 10 1.3. Try The Editor . 11 1.4. Conclusion . 12 2. 15 Minutes Tutorial 14 2.1. Create A New Xtext Project . 14 2.2. Write Your Own Grammar . 16 2.3. Generate Language Artifacts . 19 2.4. Run the Generated IDE Plug-in . 20 2.5. Second Iteration: Adding Packages and Imports . 20 3. 15 Minutes Tutorial - Extended 27 3.1. Writing a Code Generator With Xtend . 29 3.2. Unit Testing the Language . 34 3.3. Creating Custom Validation Rules . 35 4. Five simple steps to your JVM language 37 4.1. Step One: Create A New Xtext Project . 38 4.2. Step Two: Write the Grammar . 38 4.3. Step Three: Generate Language Artifacts . 43 4.4. Step Four: Define the Mapping to JVM Concepts . 43 4.5. Step Five : Try the Editor! . 48 II. Seven JVM Languages Built With Xbase 50 5. Introduction 51 5.1. Write the Grammar . 51 5.2. Map to Java . 51 5.3. CAUTION: This is Provisional API . 52 5.4. Common Requirements . 52 5.5. Getting the Code . 53 2 5.6. A Short Xtend Primer . 53 6. Scripting Language 57 6.1. Overview . 57 6.2. Running the Example . 58 6.3. Grammar . 58 6.4. Translation to Java . 59 7. Build Language 61 7.1. Overview . 61 7.2. Running the Example . 62 7.3. Grammar . 62 7.4.
    [Show full text]
  • An Extended Survey of Open Source Model-Based Engineering Tools
    An Extended Survey of Open Source Model-Based Engineering Tools Report prepared for Ericsson by: Kenn Hussey, Bran Selic, and Toby McClean Revision E (May 11, 2010) Zeligsoft 115, rue Principale, Suite 300 Gatineau, QC J9H 3M2 T (819) 684-9639 F (819) 684-5249 http://www.zeligsoft.com Zeligsoft Introduction This report presents the results of a study that was undertaken, by Zeligsoft on behalf of Ericsson, to investigate the current state of the art and trends in the domain of open source modeling tools and capabilities. The study had the following objectives: To describe the different open source projects, tools, and capabilities that are currently available, with special focus on the Eclipse environment; To identify the state of the different projects, tools, and capabilities To identify which organizations are involved in developing open source capabilities in this domain; and To identify which organizations are using open source capabilities in this domain. Open Source Modeling Survey (rev.1) 1 Zeligsoft Executive Summary During the analysis phase, it became apparent that there is significant fragmentation and duplication of effort in the domain of open source modeling tools, even within the narrow context of the Eclipse ecosystem where some of the technology is fairly mature. Consequently, it seems apparent that a major consolidation is needed to ensure a critical mass of contributors required for long-term survival and evolution of the various projects; as things currently stand, there is some concern as to the availability of long-term support for key capabilities. There is also a noticeable shift from vendor-driven to end-user-driven development in open source; this shift will require strong end-user participation to be viable in the long term.
    [Show 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.
    [Show full text]