GuideTutorialMarkedGraph

GEMOC xDSML definition tutorial with MarkedGraph

Overview / What is expected at the end of this tutorial

This tutorial aims at demonstrating the power of the GEMOC studio to define an executable semantics and provide graphical animation for a DSML. It relies of the marked graph language.

TODO: Show an animated GIF or a video.

Note	A screencast of this tutorial can be found here (give URL when it will be available)…​

Please, read the introduction of tutorials to understand the GEMOC approach to define executable DSML or to have a better understanding of the abbreviations used in this tutorial.

Install the projects defining the Marked Graph AS and CS

Import the Marked Graph AS and CS

Marked Graph is a kind of Petri net in which every place has exactly one incoming arc and exactly one outgoing arc. As a consequence, it a concurrent language (several transitions may be fired) and has no conflict.

In this section, we first initialize the xDSML project for MarkedGraph with the provided Abstract Syntax (AS) and Concrete Syntax (CS). The next subsections explains MarkedGraph and can be skipped by the reader who already know that language.

Abstract Syntax

The Domain Model, also called Abstract Syntax or Metamodel, defines :

• A marked graph as a set of places and transitions.

• Each Place has exactly one input transition and one output transition and a token count.

• A transition has several input places and several output places.

Figure 1. Abstract Syntax (Metamodel) of MarkedGraph

Concrete Syntax and Sample Model

TODO: Provide an example.

The one of Wikipedia? Another one ?

Set up an xDSML project

Create an xDSML Project

Create a new xDSML project (New > Project > GEMOC Project / new xDSML Project), with the desired name (for instance org.gemoc.example.markedgraph).

TODO: Add a screenshot

Open xDSML View

A file project.xml has been created. When opened, it provides the xDSML view which summarizes all the important resources used in an xDSML project (which are part of and managed by other projects). This view is a kind of dashboard or control center to have quick access to any important resource of the project.

TODO: Add a screenshot

Select the AS

TODO: Click on …​ and select the ecore…​

TODO: Click on xxx to open the resource…​

TODO: Click on the genmodel and select generate all

TODO: Add a screenshot

Select the Graphical Editor XXX…​

The Graphical Editor defines a graphical concrete syntax which is user-friendly to edit or view a model.

TODO : Select desgin project.

Define the Execution Semantics

TODO: Provide the execution semantics overview.

A transition can be fired if there is at least one token in every of each entry place. When fired, one token is removed from each entry place and one token is added to each output place.

Only one transition is fired at a time.

One want to know the number of token in any place during the execution. For example, it can be shown as a number inside the circle representing a place and the size of the circle can be XXX proportionel at the number of it contains.

% XXX: Fireable transitions may be drawn in green.

Define DSA

When executing a Marked Graph model, we want to know the number of token of each place (it is an ED). When transition are fired (EF), tokens are moved from input places to outout places (XXX not really moved).

The DSA of Marked Graph is composed of :

• one ED called runtimeTokenCount defined on Place . It represents the number of token in a place when the model is executed.

• one EF called initialize() defined on MarkedGraph. It initializes the runtime token count of each place with the initial token count.

• one ED called fire() on Transition. It to remove one token from each of its input places and add one token to all its output places.

Create the DSA Project

Click on K3 project in the xDSML view (Behavioral definition / DSA definition). The wizard to create of new Kermeta 3 project is launched with the name of the project initialized (k3dsa is the last name).

Clicking again on K3 project will now allow to choose and open markedgraph.xtend. It has been initialized with a template that can be discarded.

Implement the DSA

Fill in the following code in the markedgraph.xtend resource:

link:MarkedGraph/markedgraph.xtend[role=include]

Create the Extented Model with Melange

Note: This step should become transparent in a next version of the GEMOC Stutio.

Define DSE

Create the DSE Project

Right click on the ECL project in the DSE definition part. Select the Ecore file markedgraph.ecore and the root container model element: markedgraph::MarkedGraph. The file markedgraph.ecl is created in the org.gemoc.example.markedgraph.dse.

Define DSE

This step has three main purposes:

• First, it specified DSE in the context of metaclasses of the AS.

• Then, it links them to EF form DSA --- when a DSE will occurs the associated EF will be executed.

• Finally, it defines constraints on the DSE to rule the possible scheduling. Constraints generally rely on relations which are defined in the MoCC.

Warning

Errors are present because the used Relations are not yet defined…​

Note	Please notice, that as often, DSE are defined at the language level, but at runtime they are instantiated as MSE on each object conforming to their containing metaclasse. In the same way, constraints apply to the instances of DSE (the MSE).

The file markedgraph.ecl

link:MarkedGraph/markedgraph.ecl[role=include]

What should be explained?

• The main principles (we can fire as much transition has the initial token count of a place, thus a delayed is introduce)

• We want to ensure that one init is done before any fire (and only once)

Provide a pointer to another tutorial (or a new part of this one) which explains how to capitalize pieces of MoCC in a library.

Provide a pointer to a MoCCML version which uses constraint automata to define the MoCC.

Define MoCC

Give the implementation of the relations used in the DSE.

MoCCLib…​ To be done…​

TODO: How to explain the defined relation?

TODO: Add a link to another tutorial which uses an automata to define the MoCC.

Define Animation Viewpoint

The purpose of the animation is to show the number of token in each places as well as the executable transitions.

As the animation is close to the graphical concrete syntax, we extend the existing diagram description.

Extend the existing diagram description

TODO: Explain…​

XXX: In Which eclipse?

TODO: The aird has to be provided!

Add a link to a tutorial for Sirius Animator.

Animate a Model

Start a runtime Eclipse

Import the project with a sample model

Create a Launch Configuration

Start the model

Select a logical step

What else?

Questions/Remarks…​

Questions on the MoCC from summerSchool :

• why delayedBy p.initialMarking and not delayedBy 1? ⇒ Because we can make as much read as there is initialMarking token in the place. Any write in that place, means that a new read can be done.

• is it still right if the initial marking is P2 = 1 (all other places is 0) ? ⇒ No. But in any case, this initialMarking will result in a deadlock.

• what if there is several places which are initially marked? ⇒ See read/write semantics

Questions on the implementation :

• A transition has no more that one input or output place. Should be any number !

Questions:

• use execute for the EF on transition instead of fire and use fire (or trigger) for the DSE instead of fireCall.

Questions on the form :

• Use of abbreviations like MoCC, DSA, EF, ED, AS, CS, etc.? Yes because using the full name will make the tutorial hard to read. ⇒ Explanations of acronyms must be provided somewhere.

• Avoid to split files in several parts? For example ED and EF are defined in the same files. It is thus useless to try to have two steps, one to define the ED and the other to define EF.

• How to name the project defining the abstract syntax? model or as? ⇒ If 'as' or 'metamodel' is used, then the wizard should be changed in order to avoid to have the language named 'as' or 'metamodel'.

TODO :

• Remove "example" in the name of the project?

• DONE: Domain model and then MetaModel (Abstract Syntax)

• Give insight on the debugging, tricks to resolve problms, etC. ⇒ A kind of FAQ must be provided.

• Look at the Mélanie’s Dashboard so that the steps in the tutorial corresponds to activities in the dashboard.

• Look at the tools guide written by Didier, Florent et Issa.