LanguageLab A Meta-modelling Environment Terje Gjøsæter and Andreas Prinz, University of Agder, Norway SDL Forum 2015, Berlin, Germany

2 Outline Introduction Problem and Motivation Background Solution Approach LanguageLab Examples of Use Impressions from Initial Testing Summary and Future Work

Introduction Master ICT course at UiA covering DSLs, language design, compiler theory and metamodelling. Experiences from this course triggered the work on LanguageLab. Issues with the practical exercises – before LanguageLab: Based on Eclipse since students know it from previous courses. Having to find a consistent set of plugins for Eclipse that work nicely together. Each year. Update teaching materials accordingly. Anticipate and handle a wide range of issues Students often installed wrong versions Two students with seemingly same setup doing the same, get different results. 3

Problem and Motivation «Learning Metamodelling is difficult» Why? Because of the principles, or because of the tools used to teach it? Turns out it is a bit of both. Most of the available tools and technologies are rather complex. Do they really need to be that complex? Fundamental principles may be obscured by the complexity. When you go to the depth of the basic principles of MDA and metamodelling, the common understanding may not be as universal as we thought. E.g: How does MDA levels work for language aspects beyond structure? What is the nature of M0? So how can we make it easier to learn (and teach) metamodelling? Need a tool that is easy to learn to use AND conceptually clear Choice: Find one or create one? 4

Background MDA for language tools: Generating language tools from model- driven language specifications. Working on a higher level of abstraction compared to writing a compiler. Facilitates rapid development of DSLs Levels of the metamodel architecture: M0 to M3, closed loop at the top Different meta-languages cover different language aspects: structure, constraints, presentation / concrete syntax, behaviour / execution / transformation / code generation 5

Solution Approach Basic assumptions: Support all language aspects in the same hierarchy. All level transitions are of the same nature and can be handled similarly. Allows to move a model up and down among the levels. Module and Interface-based approach to simplify implementation. Meta-languages offer interfaces to be used in defining a language. Can generate an instantiation interface and move the language up to the meta-level, and create a language instance module the same way. That way we only need two levels in the tool; language and meta-language. 6

LanguageLab LanguageLab implements the proposed approach and is intended to be conceptually sound as well as student friendly. Allow working on a suitable level of abstraction. Avoid unnecessary complexity. Encourage best practices in metamodelling. Based on Eclipse/EMF but hiding these from the user. RCP standalone application. User has no access to Java/underlying platform, all has to be done with meta-languages Implemented cooperatively with help and input from several bachelor/master- students. 7

LanguageLab GUI Module-oriented interface. Upper part shows interfaces made available from loaded meta-modules. Left middle part is an optional tree view showing all elements of the module. Right middle part contains tabbed view of editors for different language aspects of the module. Lower part optionally shows the generated lower interface that contains elements that are made available when module is used as a meta-module. 8

The LanguageLab Module Model 9

The LanguageLab Module Model – RTStateInfo 10

Basic Modules and Bootstrapping Three basic meta-language modules bootstrapped (mutually self-defined): BasicStructure BasicMapping BasicTextEditor These can in turn be used to make simple language modules, or additional or more advanced meta- languages. 11

Presentation Aspect and Editors Integrating TEF (Textual Editing Framework) for defining textual editor No generation step needed – editor is grammar interpreter. BasicTextEditor meta-language module allows to define the grammar. 12

Behaviour Aspect, Instantiation and Execution BasicMapping provides a mapping language that can be used for: Instantiation semantics Generation of RTE Simple execution semantics (sufficient for e.g. PetriNet) 13

Examples of Use From M3 to M0 1. Load relevant meta-language modules 2. Create a language PetriNet based on these Create the structure of PetriNet based on BasicStructure. Define an editor using BasicTextEditor. Define a function for generating RTE with BasicMapping. Generate instantiation interface (as defined in BasicStructure) and RTE creation function. 3. Load the PetriNet module as meta-module. 4. Create MyPetriNet module. 5. Execute the PrepareToRun operation to generate runtime elements and execution functions 6. Load as meta-module and create RT_MyPetriNet 7. Execute it. 14

Examples of Use – Step 1 & 2 – PetriNet 1. Load relevant metalanguage- modules 2. Create a language PetriNet based on these Create the structure of PetriNet based on BasicStructure. Define an editor using BasicTextEditor. Define a function for generating RTE with BasicMapping. Generate instantiation interface (as defined in BasicStructure) and RTE creation function. 15

Examples of Use – Step 3, 4 & 5 – MyPetriNet 1. Load relevant meta-language modules 2. Create a language PetriNet based on these 3. Load the PetriNet module as meta-module. 4. Create MyPetriNet. 5. Execute the PrepareToRun operation to generate runtime elements and init, step, run functions. 16

Examples of Use – Step 6 & 7 – RT_MyPetriNet 1. Load relevant metalanguage-modules 2. Create a language PetriNet based on these 3. Now load the PetriNet module as meta-module. 4. Create MyPetriNet. 5. Execute the PrepareToRun operation to generate runtime elements 6. Load MyPetriNet as meta-module and create RT_MyPetriNet 7. Execute it. 17

Impressions from Initial Testing Tested on ICT Master-students in a course covering language theory, generative programming, compiler theory and meta-modelling. Given group work tasks related to understanding and changing a given set of modules. Extend the PetriNet module with some additional features Change the textual syntax of SimpleStructure to be more Java-like All groups finished the tasks successfully, Without being hindered or confused by tool complexity, Faster than expected compared to previous years’ experiences with comparable tasks in an Eclipse/EMF-based environment. Very little technical problems compared to previous years. One student initially had problems related to wrong or missing Java JRE. Students gave positive feedback on the usability and user-friendliness of LanguageLab No complaints, and no comments when asked about suggestions for improvement. On the right track, but more testing needed! 18

Summary New language workbench based on a component/interface-based view on the metamodel architecture. We are not changing the metamodel architecture but rather giving a clarifying simplified view. Component/Interface-based approach to language specification Prototype developed: Bootstrapped with basic simple modules for structure, textual editing and mapping / instantiation semantics. Covers the essential aspects of language design. Especially designed for conceptual clarity and simplicity. Successfully tested on students. 19

Future Work Future work: More basic meta-modules needed. Execution semantics Constraints. Graphical syntax. Improved error handling – meaningful error messages. Updated documentation – although intended to be intuitive. More systematic testing on a larger group of students. Making LanguageLab available to the public as Open Source. 20

The End Questions? Thank you! 21