DOCSLIB.ORG

Flexible Graphical Editors for Extensible Modular Meta Models

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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. Next, a short analysis of extension mechanisms follows. These mechanisms are used for dierent realizations of extension types. Like the extension types, the mechanisms are also analyzed for both meta-models and for graphical editors. While the classication of extensions resembles one part of this thesis’ concept, their mapping from meta-model level to graphical editor level marks the second part. This mapping is done in order to show possible impacts of a meta-model extension to its corresponding graphical editor. To validate this concept, the analyzed mappings are implemented exemplarily in two dierent frameworks. Furthermore, the two prototypes show the dierent possibilities each framework has to oer when it comes to their capabilities of extension. Therefore, this thesis can also be seen as guideline for extending a given graphical editor. i Zusammenfassung Im Bereich der modellgetriebenen Softwareentwicklung werden oftmals graphische Edi- toren eingesetzt um die Entwicklung von Modellen zu erleichtern. Diese graphischen Editoren sind dabei auf das den Modellen zugrunde liegende Metamodell angepasst. Falls dieses Metamodell invasiv erweitert wird, muss nicht nur der gesamte Code erneut gene- riert werden, der graphische Editor muss dann ebenfalls an die Erweiterung angepasst werden. Im Falle mehrerer Erweiterungen wird so nicht nur das Metamodell, sondern auch der graphische Editor komplex und fehleranfällig. Weiterhin kann es passieren, dass Endnutzer nicht alle Funktionalitäten des Metamodells und des Editors nutzen möchten, sondern nur einen Teil davon. Weitere Erweiterungen senken dann unter Umständen die Attraktivität des Gesamtprodukts. Eine Möglichkeit dieser Komplexität entgegen zu wirken, ist die Einführung von mo- dularen Metamodellen und damit einhergehend auch Erweiterungen nicht-invasiv zu gestalten. Nichtsdestotrotz sind modulare Metamodelle auch nur dann sinnvoll, wenn die graphischen Editoren auch entsprechend umgesetzt sind, da ansonsten dennoch die gesamte Funktionalität der Metamodelle in einem Editor steckt. Aufgrund dieser Faktoren beschäftigt sich diese Masterarbeit mit den verschiedenen Typen von Erweiterungen auf Metamodell-Ebene sowie auf Ebene der graphischen Editoren. Neben der Klassikation der einzelnen Erweiterungstypen wird dabei auch auf einzelne Mechanismen eingegangen, die zu bestimmten Erweiterungstypen führen können. Während die Klassikation der Erweiterungen eine große Rolle in dieser Arbeit spielt, müssen die Erweiterungen auf beiden Ebenen noch in Zusammenhang gebracht werden. Dabei werden mehrere Abbildungen geschaen, die es erlauben von einer Metamodel- lerweiterung auf mögliche Erweiterungen auf graphischer Editorenebene zu schließen. Dadurch lassen sich die verschiedenen Auswirkungen einer Erweiterung auf Metamodel- lebene auf graphische Editoren besser erkennen. Validiert wird dieses Konzept durch eine exemplarische Implementierung der Abbildungen in zwei verschiedenen Frameworks. Weiterhin zeigen die beiden implementierten Prototy- pen welche Möglichkeiten und Grenzen die beiden Frameworks aufweisen. Dadurch kann diese Arbeit auch als Richtlinie betrachtet werden, mit Hilfe derer die Entwicklung einer Erweiterung vereinfacht werden soll. iii Contents Abstract i Zusammenfassung iii 1 Introduction 1 1.1 Motivation . .1 1.2 Goals of this thesis . .2 1.3 Outline . .2 2 Foundations 5 2.1 Model-Driven Software Development . .5 2.2 Models and Meta-Models . .5 2.3 Domain-Specic Languages . .7 2.4 Modularity . .8 2.5 Extensibility . .9 2.6 Eclipse Modeling Framework . 10 2.7 Graphical Editors . 11 2.7.1 The Graphiti Framework . 12 2.7.2 The Sirius Framework . 13 3 Related Work 15 3.1 Extension of Meta-Models . 15 3.2 Modular Meta-Models . 16 3.3 Language Workbenches . 17 3.4 Extension of Graphical Editors . 18 4 Classification of Extensions 21 4.1 General Approach . 21 4.2 Extension Types and Mechanisms . 22 4.3 Extension Types on Meta-Model Level . 23 4.3.1 New Meta-Class . 25 4.3.2 New Information to Existing Classes . 27 4.4 Extension Mechanisms on Meta-Model Level . 28 4.4.1 Referencing . 28 4.4.2 Inheritance . 31 4.4.3 Realization . 31 4.4.4 Stereotyping . 32 4.4.5 Combination of Extension Mechanisms . 32 v Contents 4.5 Summary of Meta-Model Extension Types and their Realizations . 33 4.6 Extension Types for Graphical Editors . 34 4.6.1 Extend Existing Notation Element . 34 4.6.2 New Notation Element . 38 4.6.3 Add Palette Entry . 39 4.6.4 Add Properties Entry . 39 4.6.5 Extension of Outline View . 39 4.6.6 Add Toolbar Button . 40 4.6.7 Add Button to Context Dependent Menu . 41 4.6.8 Create New View . 42 4.7 Combination of Extension Types for Graphical Editors . 42 4.8 Extension Mechanisms for Graphical Editors . 43 4.8.1 Extension Mechanisms in Graphiti . 43 4.8.2 Extension Mechanisms in Sirius . 44 5 Mapping of Extensions between Meta-Models and Graphical Editors 45 5.1 Mapping of Meta-Class Instance Below Root Node to Graphical Editors . 45 5.1.1 Supported Realizations on Graphical Editor Level . 46 5.1.2 Unsupported Realizations on Graphical Editor Level . 47 5.2 Mapping of Meta-Class Instances as Part of Other Instances to Graphical Editors . 48 5.2.1 Supported Realizations on Graphical Editor Level . 49 5.2.2 Unsupported Realizations on Graphical Editor Level . 51 5.3 Mapping of Adding Attributes to Existing Classes to Graphical Editors . 52 5.3.1 Supported Realizations on Graphical Editor Level . 52 5.3.2 Unsupported Realizations on Graphical Editor Level . 55 5.4 Mapping of Adding a Containment to Existing Classes to Graphical Editors 56 5.4.1 Supported Realizations on Graphical Editor Level . 56 5.4.2 Unsupported Realizations on Graphical Editor Level . 58 5.5 Mapping of the Relation Extension Type to Graphical Editors . 59 5.5.1 Supported Realizations on GRaphical Editor Level . 59 5.5.2 Unsupported Realizations on Graphical Editor Level . 60 6 Implementation and Validation 63 6.1 Overview on Available Scenarios . 63 6.2 Smart Grid Resilience Framework . 64 6.3 Implementation of the Core Meta-Model in Graphical Editors . 66 6.3.1 Sirius Implementation . 66 6.3.2 Graphiti Implementation . 72 6.4 The Input Model Extension . 79 6.4.1 The Input Meta-Model . 80 6.4.2 Adding a Second Model to the Editor . 81 6.4.3 Implementing the Input Model with Sirius . 84 6.4.4 Implementing the Input Model with Graphiti . 90 vi Contents 6.5 The Output Model . 93 6.5.1 The Output Meta-Model . 94 6.5.2 Implementing the Output Model with Sirius . 95 6.5.3 Implementing the Output Model with Graphiti . 97 6.5.4 Problems with Two or More Active Extensions . 100 6.6 Further Extension of the Smart Grid . 101 6.6.1 The Articial Extension Meta-Model . 102 6.6.2 Mapping of the Individual Extension Types . 103 6.6.3 Implementation of a MDSD Prole . 104 6.6.4 Sirius Implementation . 106 6.6.5 Graphiti Implementation . 113 6.7 Summary of the Validated Mappings . 117 6.7.1 Summary of the Validation on Meta-Model Level . 118 6.7.2 Comparison of Extension Types on Graphical Editor Level . 118 6.7.3 Validation of the Mapping in Sirius . 119 6.7.4 Validation of the Mapping in Graphiti . 121 7 Evaluation 123 7.1 Comparison Between the Graphiti and the Sirius Framework . 123 7.1.1 Creating the core editor . 123 7.1.2 Toolbar . 124 7.1.3 Creating the extension . 124 7.1.4 Adding an extension model to the diagram . 124 7.1.5 Further drawbacks . 125 7.2 Content not Supported by the Current Graphical Editor . 125 7.3 Further Scenarios . 126 7.3.1 IntBIIS . 126 7.3.2 Security Extensions . 128 7.3.3 Architectural Data Flow Analysis . 128 8 Conclusion 131 8.1 Conclusion . 131 8.2 Future Work . 132 Bibliography 135 vii List of Figures 2.1 The four meta-levels of OMG described by Stahl et al. [54] . .6 4.1 General approach showing extensions on meta-model and graphical editor level....................................... 22 4.2 A simplied version of the ecore meta-model based on the complete meta- model in [55] . 24 4.3 An exemplary core meta-model and three fragments extending the core meta-model . 25 4.4 The extension type of adding a new meta-class .
Load more

Recommended publications
  • Modeling for Rapid Systems Prototyping: Hospital Situational Awareness System Design †
    systems Article Modeling for Rapid Systems Prototyping: Hospital Situational Awareness System Design † Avi Shaked Israel Aerospace Industries ELTA Systems, Ashdod 7710202, Israel; [email protected] † This paper includes a significant elaboration of the work “Shaked, A. On the Road to Hospital Digital Transformation: Using Conceptual Modeling to Express Domain Ontology”. In Proceedings of the 12th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2020), Online, 2–4 November 2020. Abstract: The COVID-19 pandemic caught hospitals unprepared. The need to treat patients remotely and with limited resources led hospitals to identify a gap in their operational situational awareness. During the pandemic, Israeli Aerospace Industries helped hospitals to address the gap by designing a system to support their effective operation, management and decision making. In this paper, we report on the development of a functional, working prototype of the system using model-based engineering approach and tools. Our approach relies on domain-specific modeling, incorporating metamodeling and domain-specific representations based on the problem domain’s ontology. The tools practiced are those embedded into the Eclipse Modeling Framework—specifically, Ecore Tools and Sirius. While these technological tools are typically used to create dedicated, engineering-related modeling tools, in this work, we use them to create a functional system prototype. We discuss the advantages of our approach as well as the challenges with respect to the existing tools and their underlying technology. Based on the reported experience, we encourage practitioners to adopt model-based engineering as an effective way to develop systems. Furthermore, we call researchers and tool developers to improve the state-of-the-art as well as the existing implementations of pertinent tools to support model-based rapid prototyping.
    [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]
  • 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]
  • 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]
  • AMASS Platform Developers' Guide
    ECSEL Research and Innovation actions (RIA) AMASS Architecture-driven, Multi-concern and Seamless Assurance and Certification of Cyber-Physical Systems AMASS Platform Developers’ Guide Work Package: WP2: Reference Architecture and Integration Dissemination level: PU = Public Status: Final Date: 21st November 2018 Responsible partner: Ángel López (Tecnalia Research & Innovation) Contact information: [email protected] Document reference: AMASS_Platform_DevelopersGuide_WP2_TEC_V1.0 PROPRIETARY RIGHTS STATEMENT This document contains information that is proprietary to the AMASS Consortium. Permission to reproduce any content for non-commercial purposes is granted, provided that this document and the AMASS project are credited as source. This deliverable is part of a project that has received funding from the ECSEL JU under grant agreement No 692474. This Joint Undertaking receives support from the European Union’s Horizon 2020 research and innovation programe and from Spain, Czech Republic, Germany, Sweden, Italy, United Kingdom and France. Contributors Names Organisation A. Ruiz, H. Espinoza, A. Lopez TECNALIA Research & Innovation (TEC) I. Ayala, B. Gallina, M. A. Javed Maelardalens Hoegskola (MDH) S. Puri INTECS (INT) Reviewers Names Organisation C. Martinez (Quality Manager) TECNALIA Research & Innovation (TEC) H2020-JTI-ECSEL-2015 # 692474 Page 2 of 68 AMASS AMASS Platform Developers’ Guide V1.0 TABLE OF CONTENTS Executive Summary...............................................................................................................................
    [Show full text]
  • Visual Environment for Editing and Solving Flowsheets : Design
    Visual environment for editing and solving flowsheets : design and implementation of a visual environment for editing and solving flowsheets to produce heat and material balances for urea plant designs Citation for published version (APA): Raptis, K. (2017). Visual environment for editing and solving flowsheets : design and implementation of a visual environment for editing and solving flowsheets to produce heat and material balances for urea plant designs. Technische Universiteit Eindhoven. Document status and date: Published: 28/09/2017 Document Version: Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers) Please check the document version of this publication: • A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website. • The final author version and the galley proof are versions of the publication after peer review. • The final published version features the final layout of the paper including the volume, issue and page numbers. Link to publication General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research.
    [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]
  • 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.
    [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]
  • CIIRC Testbed 77 9.1 Resources
    A Graphical Toolkit for ISA-95 Empowering End Users to Develop Bridges between ERP and MES MASTER’S THESIS submitted in partial fulfillment of the requirements for the degree of Master of Science in Business Informatics by Laurens Lang, B.Sc. Registration Number 11719751 to the Faculty of Informatics at the TU Wien Advisor: a.o. Univ.-Prof. Mag. Dr. Christian Huemer Assistance: Bernhard Wally, MSc Vienna, 1st April, 2020 Laurens Lang Christian Huemer Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.at Danksagung An dieser Stelle möchte ich allen Personen danken, die mit ihrer Unterstützung zum Gelingen dieser Arbeit beigetragen haben. Ich möchte meinem Betreuer Bernhard Wally danken. Er hat mir nicht nur mit großer Hilfsbereitschaft und kritischen Hinweisen bei der Erstellung dieser Arbeit geholfen, sondern auch viele neue Einblicke in das wissenschaftliche Arbeiten gegeben. Die Exkurse nach Prag, Linz und Hamburg haben mir sehr gut gefallen und ich möchte mich herzlich bedanken, dass mir so viel Raum für das Ausleben meiner Ideen gegeben wurde. Außerdem konnte ich extrem viel von ihm lernen. Außerdem möchte ich Herrn Prof. Dr. Christian Huemer danken, der es mir ermöglicht hat, diese Arbeit in der Business Informatics Group (BIG) zu schreiben. Desweiteren möchte ich Prof. Dr. Manuel Wimmer und dem Christian Doppler For- schungslabor für Intelligente Modellintegrierte Produktion, die es ermöglicht haben, dass ich die Inhalte der Arbeit in zwei Papers publizieren durfte. Außerdem danke ich dem Czech Institute of Informatics, Robotics and Cybernetics für die Einblicke in ihre Arbeit und den zwei Einladungen nach Prag.
    [Show full text]
  • Actes Des 17Èmes Journées Approches Formelles Dans L'assistance Au Développement De Logiciels
    Actes des 17emes` journees´ sur les Approches Formelles dans l’Assistance au Developpement´ de Logiciels Edit´ es´ par Antoine Rollet et Arnaud Lanoix Les 13, 14 et 15 juin 2018 a` Grenoble Approches Formelles dans l’Assistance au Developpement´ de Logiciels – AFADL’18 Preface´ L’atelier francophone AFADL sur les Approches Formelles dans l’Assistance au Developpement´ de Logiciels, se tiendra pour sa 17eme` edition´ les 13, 14 et 15 juin 2018 a` Grenoble. Cette annee´ encore, cet atelier est organise´ conjointement avec les journees´ du GDR-GPL, la Conference´ en IngenieriE´ du Logiciel (CIEL) et la Conference´ francophone sur les Architectures Logicielles (CAL). L’atelier AFADL rassemble de nombreux acteurs academiques´ et industriels francophones interes-´ ses´ par la mise en œuvre des techniques formelles aux divers stades du developpement´ des logiciels et/ou des systemes.` Il a pour objectif de mettre en valeur les travaux recents´ effectues´ autour de themes` comme la preuve, la verification,´ le test, l’analyse de code, etc... ou toute autre approche formelle permettant de developper´ des applications sures,ˆ allant de la specification´ du systeme` a` sa vie operationnelle.´ AFADL reste un lieu privilegi´ e´ pour les echanges´ et les discussions. En encourageant un format court, et graceˆ a` des types de soumissions varies,´ comportant des articles courts, des demonstrations´ d’outils, des presentations´ de projets, des resum´ es´ longs de travaux dej´ a` publies´ et des travaux de doctorants, AFADL permet d’entrevoir l’activite´
    [Show full text]