Skip to content
barnettwilliam edited this page Feb 20, 2023 · 2 revisions

The MDENet education platfom aims to allow users to quickly start learning fundamental Model Driven Engineering techniques via a web browser.

Goals

  1. The goals of the MDENet education platform are

  2. To enable people interested in learning MDE (learners) technologies to get going quickly without having to install and configure a broad range of disparate technologies;

  3. To enable teachers of MDE to define learning activities that combine different MDE technologies exposing only those parts necessary for learners to develop a conceptual understanding;

  4. To enable providers of MDE technologies to integrate their tools seamlessly into the platform so that tool-specific learning resources can be created; and

  5. To provide a pathway to real-world use of the technologies (and out of the “sheltered” environment of the platform) for those learners who desire to use the technology in real projects;

  6. To support the creation of a community repository of shareable MDE learning activities.

System Vision

We envision that the combination of three technologies will allow us to achieve these goals:

  1. Web-based user interface on top of Git repositories stored on GitHub, GitLab etc., hosted on a Cloud service.

  2. Configuration of learning activities via configuration files.

  3. API-based interface for integration of different tools into the overall platform.

We briefly discuss each in more detail below.

Configuration of learning activities

Learning activities are defined via configuration files provided at the root of the repository. We may wish to define a bespoke DSML for these configuration files or we may want to use a simple YAML format. In any case, there should be CI/CD actions that allow configuration files to be validated for internal consistency.

Configurations consist of two parts, tool identification and specification of activity:

  1. Tool identification is done by referencing API specifications of the specific tools to be used in the learning activity – either by reference to a bespoke registry or using a repository reference similar to how GitHub Actions can be referenced.

  2. Activity specification means defining the specific UI elements and action buttons available to the user and what they do. Initially, we will focus on defining static UIs in the style of the Epsilon Playground, but over time we may want to explore allowing the definition of more dynamic user interfaces that show different panes only as and when they are required. What panes are available and what additional configuration information they require, depends on the tools being used.

API-based tool integration

To integrate into the MDENet education platform, MDE tools will need to implement an API similar in style to the language-server protocol (LSP). Different from LSP, the API will need to cover at least the following three aspects:

  1. Configuration schema meta-data. The API must be queryable for information about what can be configured for a learning activity using the tool. This covers the different types of panes provided by the tool, the different types of actions available, and which panes must be made available together.

  2. (G)LSP-style endpoints for providing editing support for models and specifications used by the tool. Different tools will provide different editing support for the specification files they require as well as for any resulting tools (e.g., an editor for a DSML developed using Xtext or Langium). To enable meaningful editing of these files, we will require suitable API endpoints so that tools can control the presentation and editing support. We will consider building on the LSP/GLSP protocols, but these may be too heavy a requirement for tool providers, so simpler APIs will also need to be explored.

  3. Endpoints for actions. For example, to trigger generation of language infrastructure in a language workbench or running a model-to-model transformation on a set of source files defined by the learner.

The MDENet education platform will define these APIs and will be the user of the API endpoints provided by different tools. It will be the responsibility of the tool developers to provide implementations of the APIs, although we will provide some example implementations for commonly used MDE tools.

A technical challenge to overcome will be how to share file data with tools where the API implementations may run on different hosts (or whether to define a mechanism to enable running the tools on the same host).

Work plan

We initially have funding for an RSE until the end of 2023. We, therefore, need to follow a clear and focused plan of work prioritising the core functionalities as documented below. Note that for each stage, we consider completion of the stage to include documentation on ow to build, deploy, and extend the system.

Milestone To achieve by
Understanding the architecture of Epsilon Playground and Gitpod and defining a high-level architecture for the MDENet education platform. mid-January 2023
Definition of generalised architecture. Reimplementation of core Epsilon Playground functionality and tool integration in the generalised architecture, demonstrated through some reimplemented examples from the playground March 2023
Integration of Xtext and corresponding refactoring of generalised architecture. Demonstration through an Xtext learning activity for a simple language June 2023
Integration of graphical notations (e.g., SiriusWeb, GLSP, …) and corresponding refactoring of generalised architecture. Demonstration through a SiriusWeb learning activity for a simple language October 2023
Wrap up and planning of next steps December 2023

Provisional Personas

This section defines the provisional personas for the three main user groups of the education platform Teachers, Tool Providers, and Learners. Scenarios for the user groups can be found here.

Carlos, the Senior lecturer

How does Carlos use the platform?

Carlos creates tutorials in order to teach a software engineering module on DSL’s. He wants to be able to share tutorials with his students that they can immediately start and focus on the lesson concepts and not unrelated technological details.

  • Creates lessons to deliver to his students.

  • Creates and makes available tutorial-specific files.

What’s important to Carlos?

For Carlos being able to adapt his tutorials without adding significant extra work.

  • He doesn’t want to have to have manually edit and create webpages.

  • He expects to be able to make the tutorials available to his students by sharing a link.

  • He expects there to be some example activities with some documentation on activity configuration.

Other Commonly used tools?

Xtext, Eclipse EMF, Eclipse, Git, Word processing such as latex.

Neena, the Software developer

How does Neena use the platform?

Neena is adding her organisation’s tool to the platform to increase its awareness to grow their userbase.

  • Adds and maintains the necessary backend components to support the tool.

  • Creates the platform tool configuration.

What’s important to Neena?

For Neena, being able to add her organisations tool using familiar workflows used in software development.

  • She expects to be able to integrate the platform support into existing development practices of her organisation.

  • She expects to be able to find examples and supporting documentation explaining how to add new tools to the platform.

Other Commonly used tools?

Eclipse, IDEs such as IntelliJ, Word processing using Microsoft office.

Ben, the Part-time Student

How does Ben use the platform?

Ben is working towards an undergraduate degree in software engineering and uses the platform because it is being used as part of his course.

  • follows and completes tutorials that have been assigned to him by his lecturer Carlos.

What’s important to Ben?

For Ben, learning the most he can from the tutorial exercises is the most important thing.

  • He expects being able to start tutorial activities quickly and be able to complete the assigned activities.

  • He wants to be able to resume activities after the tutorial in his spare time as there usually is not enough time to complete all activities.

  • He may want to extend the given examples so be able to export the project into a local version of the tool environment.

  • He expects his work not to be lost while using the platform.

Other Commonly used tools?

  • Word processing, Visual Studio Code with some experience of commercial projects, and advanced web user.