Naomod days 2022

Eclipse GEMOC Studio training

Erwan Bousse

Nantes University

23/02/2022

Who am I?

Hello!

  • Since 2018, I am Associate Professor at Nantes University teaching software engineering (including MDE and SLE) at the Department of Computer Science

  • I am also member of the NaoMod research group in the LS2N lab, with different research interests:

    • Software Language Engineering (SLE)

    • Model Driven Engineering (MDE)

    • Domain-Specific Languages (DSLs)

    • Model execution and simulation

    • Debugging and testing of models

    • …

Today’s plan

1. Lecture

  • Small introduction about Software Language Engineering (SLE)

  • Presentation of the Eclipse GEMOC Studio

  • Step-by-step presentation of how to make a very small DSL (Finite State Machine) with the Eclipse GEMOC Studio

2. Tutorial (this is where you work)

  • Creation of a Character Simulation DSL from scratch using the GEMOC Studio

Software Language Engineering (SLE)

You say MDE? I hear SLE

Context: increasing complexity of systems

examples

  • Cyber physical systems, internet of things, massively multiplayer online games, artificial intelligence, …

    • complexity everywhere!

    • involving multiple stakeholders and concerns from heterogeneous domains

  • Increasing use of software, aka. software−intensive systems

Model-Driven Engineering (MDE)

mde

My view of MDE in a nutshell

  1. Separation of concerns through the use of models

    • defined using domain specific languages (DSLs)

    • each representing a particular aspect of a system

  2. Composition of all often heterogeneous models

  3. Implementation (or generation) of the final resulting system

Domain-Specific Languages (DSLs)

Definition

  • Well scoped language, often small

  • Targets particular tasks in a certain domain

  • Relies on dedicated notations (textual or graphical)

Promises

  • Less redundancy

  • Better separation of concerns

  • Accessible for domain experts

dsls examples3

Engineering Domain Specific Languages (DSLs)

mde lifecycle 0

Engineering Domain Specific Languages (DSLs)

mde lifecycle 2

Engineering Domain Specific Languages (DSLs)

mde lifecycle 3

Engineering Domain Specific Languages (DSLs)

mde lifecycle 4

Engineering Domain Specific Languages (DSLs)

mde lifecycle 5

Anatomy and tooling of a DSL

dsl tools 1

Anatomy and tooling of a DSL

dsl tools 2

Anatomy and tooling of a DSL

dsl tools 3

Example of (executable) DSL

dsl petrinet example 1

Example of (executable) DSL

dsl petrinet example 2

Example of (executable) DSL

dsl petrinet example 3

Example of (executable) DSL

dsl petrinet example 4

Example of (executable) DSL

dsl petrinet example 5

Example of (executable) DSL

dsl petrinet example 6

The Eclipse GEMOC Studio

An SLE research playground

Description

  • Open-source Eclipse-based workbench atop the Eclipse Modeling Framework (EMF), in two parts:

    • language workbench: used by language designers to build and compose new executable DSLs,

    • modeling workbench: used by domain designers to create, execute and coordinate models conforming to executable DSLs.

gemoc screenshot with logo

Status and purpose

Status of the Eclipse GEMOC Studio

  • Handled by the GEMOC initiative, an informal group with partners from both the academia and the industry

  • Now also an official research consortium of the Eclipse foundation

Purpose of the Eclipse GEMOC Studio

  • Research platform to experiment with SLE research proof-of-concepts / prototypes, and to integrate them together

  • The Eclipse GEMOC Studio is not an industry-ready tool, and will never be one!

A First Journey with the Eclipse GEMOC Studio

Illustrated with a Finite State Machine DSL

Goal: FSM DSL

  • We want to be able to create and execute finite state machine (FSM) models

  • We consider FSMs that are able to parse an input string, and produce an output string, when firing transitions

fsm model

Here if we give btt as input string, it first goes to Yellow, then Red, then Green again.

Part 1: Creating the abstract syntax

  • The abstract syntax must be defined using the Ecore metamodeling language

  • Each class of the metamodel is a concept of the DSL

  • Essentially, using the DSL means creating and/or editing a model conforming the the metamodel defining the abstract syntax

Note
Important to generate the code from the metamodel, so that we can create and manipulate model elements from the semantics later on

FSM abstract syntax

k3fsm

Part 2: Creating the semantics − 1

The execution semantics of a DSL must comprise two parts:

  • The definition of the runtime state of a model of the DSL under execution

  • The definition of the interpreter, which executes a model of the DSL by modifying the runtime state

Runtime state definition

  • We use Ecore to define the runtime state, in the same file as the abstract syntax

  • We can either add new references directly in existing classes (we do that in the FSM example), or define new more separated classes (we do that in the tutorial later)

Part 2: Creating the semantics − 2

Interpreter definition

  • The Eclipse GEMOC Studio provides different ways to define the interpreter, both "official" ones (K3, Moccml+K3, ALE) and third-party ones (Henshin, xMOF).

  • We will focus for now on K3, an aspect-oriented language to "weave" the semantics inside each concept of the language. K3 is a set of annotations for the Xtend programming language:

    • The @Aspect annotation is used to define operations in existing classes − here we will use this to add operations in classes of our abstract syntax

    • The @Step annotation is used to declare that a given execution method produces an observable execution step (required for the GEMOC debugger to work)

    • The @InitializeMethod is used to declare what is the initialiation method of the interpreter, ie. how is the first execution state constructed

    • The @Main operation is used to declare what is the entry point of the interepter

Result (1)

k3fsm2

Result (2)

fsm semantics 1

Result (3)

fsm semantics 2

Part 3: Creating the concrete syntax

  • The graphical concrete syntax can be defined using the Sirius language from Obeo

  • In a nutshell, we must define how each of our concept is graphically represented in an editor (eg. a State is a rounded rectangle, an initial State is orange, a Transition is an arrow, etc.)

Result

fsm cs

Part 4: Creating a graphical animator

  • Using the GEMOC Studio, we can easily extend the Sirius graphical concrete syntax to also display extra information during the execution of a model. This is what we call model animation.

  • This is achieved by the definition of a Debug layer in the Sirius representation.

Result

fsm anim

Part 5: Trying the DSL

  • We can now try our DSL by loading it into a new Eclipse instance!

  • When loaded in this instance, this DSL will directly benefit from all the existing generic tools of the GEMOC Studio (eg. debugger and animator).

Result

fsm debug

Lecture over!

Now move here for the practical training:

https://gitlab.univ-nantes.fr/bousse-e/naomod-days-2022-gemoc-training