The xDSML Project is the core project of languages created using the GEMOC Studio. It has one main purposes:

In the GEMOC Studio, go to: File > New > Project…​ > New GEMOC Language Project. This will create a new xDSML Project in your workspace.

The .melange file is the main element of the xDSML Project.

From the information contained in this file, the project generates additional code that is used by the Execution Engine during the execution of models conforming to the xDSML (see Part II, “GEMOC Modeling workbench ”).

The GEMOC Language Workbench provides an xDSML perspective. It is available in the menu Window > Open Perspective > Other.

This perspective eases the creation of a new xDSML project. In the menu File > New, you have direct access to

On a right click on an xDSML project you have access to this menu containing theses commands:

On a right click on a .melange file you have access to this menu containing theses commands:

Melange is a Language designing tool. Through a .melange file you can define a Language as an assembly of abstract syntaxes with operational semantics and also as a composition of Languages. To do so, Melange is provided with a textual Languages editor.

package your.language.namespace

package org.gemoc.sample.tfsm.xdsml

language Tfsm {

	/*
	 * Declare abstract syntax
	 */
	syntax "platform:/resource/org.gemoc.sample.tfsm.plaink3.model/model/tfsm.ecore"

	/*
	 * Set name of the ModelType (ie: the type of this language)
	 */
	exactType TfsmMT
}

package org.gemoc.sample.tfsm.xdsml

language Tfsm {

	/*
	 * Declare abstract syntax
	 */
	syntax "platform:/resource/org.gemoc.sample.tfsm.plaink3.model/model/tfsm.ecore"

	/*
	 * Declare DSA
	 */
	with org.gemoc.sample.tfsm.plaink3.dsa.TFSMAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.TFSMVisitorAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.FSMEventAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.FSMClockAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.FSMClockVisitorAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.StateAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.StateVisitorAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.TransitionAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.TransitionVisitorAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.GuardVisitorAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.TemporalGuardVisitorAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.EventGuardVisitorAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.TimedSystemAspect
	with org.gemoc.sample.tfsm.plaink3.dsa.TimedSystemVisitorAspect

	/*
	 * Set name of the ModelType (ie: the type of this language)
	 */
	exactType TfsmMT
}

1.1.7.2. Content assist

You can press Ctrl+Space to have a content assist in the Melange editor.

• In language { …​ }

   — Create a Domain Model Project — 

  Create a new EMF project and upadte the syntax of your language.

   — Create a DSA Project — 

  Create an new K3 project. Based on the syntax of your language, it automatically create Aspects for each class of your Domain. Theses Aspects are also added in your Language.

   — Import existing DSA project — 

  Automatically imports all Aspects from a K3 project

• After syntax

Display the list of available .ecore in your workspace and update syntax with the path to the selection.

• After with

Display the list of accessible Java classes from your project dependencies. K3 Aspects are displayed first.

• After ecl

Display the list of available .ecl in your workspace and update ecl with the path to the selection.

1.1.7.3. Outline

The outline view is available when you open a .melange file. It gives an overview of the file content.

The plugin.xml file is the link between the Languages and the Modelling Workbench. It is mainly composed of two extension points:

Gemoc extension points declare Languages availables in the Modelling Workbench. It also give the class able to load models for each Language.

GEMOC language. 

<extension point="org.gemoc.gemoc_language_workbench.sequential.xdsml">
<XDSML_Definition
modelLoader_class="org.gemoc.executionframework.extensions.sirius.modelloader.DefaultModelLoader"
name="org.gemoc.sample.tfsm.xdsml.Tfsm"
xdsmlFilePath="/org.gemoc.sample.tfsm.plaink3.xdsml/bin/org/gemoc/sample/tfsm/xdsml/Main.melange"
>

Melange extension points declare semantic of Languages as list of Domain model classes associated to their K3 Aspects. It also gives the available entry points for the execution, which are the Aspects methods tagged with @Main.

Melange Language. 

<extension point="fr.inria.diverse.melange.language">
<language
aspects="FSMClock:org.gemoc.sample.tfsm.plaink3.dsa.FSMClockAspect,org.gemoc.sample.tfsm.plaink3.dsa.FSMClockVisitorAspect;..."
entryPoints="org.gemoc.sample.tfsm.plaink3.dsa.TimedSystemAspect.main(org.gemoc.sample.tfsm_plaink3.TimedSystem)"
exactType="org.gemoc.sample.tfsm.xdsml.TfsmMT"
id="org.gemoc.sample.tfsm.xdsml.Tfsm"
uri="http://tfsmmt/"
>

The dashboard is available on .xdsml files from the Project Explorer or the Model Explorer views. See Section 1.1, “xDSML Project” to view how to create an xDSML project.

When the Gemoc Dashboard menu is selected a new editor opens.

This editor is divided in three main parts:

The overview allows to access to the different parts of the Part I, “GEMOC Language Workbench ” process:

When you click on a step in the overview the related actions are automatically presented in the sections part.

This part provides sections which depends on the selected overview. The sections contain links that can be used to activate the different actions: create the domain model project, edit the DSA project, define a concrete syntax…​

1.2.3.1. Description

Each section provides a help button which shows the description associated to the section and explains the process step and which actions are available.

1.2.3.2. Links

When a link is selected, the corresponding action is launched: open a wizard, open the documentation…​

On the right side of the dashboard, a tree viewer shows the projects associated to the current xDSML project.

1.2.4.1. Synchronize

The section toolbar provides a synchronize action. This action filters the content of the tree viewer to keep only projects relevant according to the current process step represented by the section.

1.2.4.2. Open existing projects

By double-clicking on a project in the tree viewer, it is possible to open and update the corresponding file.

The Domain Model Project specifies the concepts of the domain at hand and the structural relations between the concepts.

The GEMOC Studio relies on the Eclipse Modeling Framework for its Domain Model Projects. See the EMF website for more information on how to create an EMF project in Eclipse. The Domain Model is materialized as an Ecore metamodel.

When your EMF Project is done, connect your xDSML Project to it by specifying in the .melange file the path to your Ecore metamodel thanks the keyword syntax. See Section 1.1.7, “Melange editor” for more informations about Melange keywords and the content assist.

If you wish to modify your Domain Model, do not forget to reload the associated genmodel and regenerate the EMF model code (and edit/editor code if you use them).

See the Xtext website.

If you want to create a graphical concrete syntax you can use Sirius. The Sirius documentation provides information for Sirius Specifier Manual.

EMF provides several services, as seen in Section 2.1, “Defining a Domain Model Project” , EMf allwos to generate many artifacts. In addition to generate the java code for the metamodel and provide a reflective tree editor, EMF allows to generate a customizable Tree Editor.

On the .genmodel right click on the root element then Generate Edit Code and Generate Editor Code.

Some very easy customizations can be done in the .edit project:

Table Table 2.1, “Example of customization of icons on Timed Finite State Machine tree editor.” illustrates the value of adding dedicated icons for a given domain.

One benefit of assigning an execution semantics onto a DSL is to pave the way for exhaustive exploration. Exhaustive exploration is a technique used in complex and safety system design to ensure the correct adequacy between the system requirements and the real behavior of the system. This is made possible by exploring and verifying properties on an exhaustive finite state space of the system representing the whole set of relevant configurations your system may reach.

Gemoc provides the first step towards exploration and verification by building the graph of all the possible schedules of a system model constrained with MoCCML. It can then be used in a model-checking tool to verify behavioral properties of the MoCCML models. Thanks to Gemoc approach the execution model is explicited and can be manipulated to for instance:

In the Gemoc approach the steps toward exploration and verification during language design are:

In the Gemoc approach the steps toward exploration and verification during modeling design are described in Section 9.3, “Exhaustive Exploration and Verification at Model Design Time”: The flow toward exhaustive exploration and verification in Gemoc is presented in figure Figure 3.3, “The exploration and verification flow in Gemoc” and described in the following sections.

Figure 3.3. The exploration and verification flow in Gemoc

3.2.3.1. Generating inputs for Exhaustive Exploration tools : T1 at Language Level

ECL specification is the starting point toward exploration. In this specification we define events associated with the actions of the DSA and also events associated with the DSE events. On these event bindings we apply the MoccML relations of the MoC Library to schedule the events. A finite state space of a system uses such scheduling constraints and therefore a configuration file to target an exhaustive exploration tool must be generated:

T1 transformation generates a configuration file to later target exhaustive exploration or simulation tools. T1 takes as input the ECL mapping definition between the DSL and the MoCCML to generate a transformation T2 describing transformation rules that will be used to produce the processes for the DSL related functions and data (DSA) and the behavioral processes corresponding to the MoCCML constraints.

T1 is automatically generated from ecl model and results are stored in mtl-gen folder.

However to execute T1 manually right-click on the ECL file → Exhaustive Exploration → Generate ClockSystem transformation from ECL model as illustrated in figure Figure 3.4, “Using T1 Tranformation”.T2 is generated in the repository <mtl-gen>.

Figure 3.4. Using T1 Tranformation

This wizard creates a layer to represent the current instruction and add commands in order to manage breakpoints and launch a simulation in debug mode. This is a default implementation, it can be customized to represent runtime data for instance. The customization uses the Sirius description definition, see the Sirius Specifier Manual for more details. The wizard presents three ways to implement this layer:

4.1.1.1. Create a debug diagram description

It creates a diagram representation with a default debug layer. The representation does not depend on another representation. A typical use case is a language where the runtime data representation is too far from the language graphical syntax.

4.1.1.2. Extend an existing diagram description

It creates a diagram representation with a default debug layer that extends an existing representation. This allows to have a debug layer based on the representation of the language concrete syntax. The language concrete syntax can be deployed without the debug representation. A typical use case is the reuse of an existing diagram definition that you cannot modify by yourself. For instance if you want to use UML, you can reuse the UML Designer.

You can select any diagram description.

And then define the new diagram description which extends the one you previously selected.

4.1.1.3. Add a debug layer to an existing diagram description

It creates a default debug layer in an existing diagram representation. This should be used if you are also in charge of the language concrete syntax.

In this case, you can only select a diagram description from the workspace.

Implementation details are for advanced use and troubleshooting. It explains how the implementation works behind the scene. There are two main elements covered here : the debugger services class and the debug layer itself.

4.1.2.1. Debugger services

The debugger services class is use to tell which representations should be activated and refreshed during debug (see the getRepresentationRefreshList() method). It also provides a method to know if an element of the diagram is the current instruction. This is provided by the isCurrentInstruction() method.

4.1.2.2. Debug layer

The default debug layer adds action to start the simulation in debug mode and to toggle breakpoints (1). When a breakpoint exists for an element of the diagram, a visual feedback is displayed according to the breakpoint state (2). The current instruction is also highlighted in yellow by default (3).

This is a default debug layer, it can be customized to fit your needs. The customization use the Sirius description definition, see the Sirius Specifier Manual for more details.

BCOoL is a dedicated language to explicitly specify coordination patterns, i.e., to specify, at the language level, how some models conforming to different DSMLs can be coordinated. This enables the integrator to capture the knowledge of integration of systems. In BCOoL, the specification relies on Operators. Once an operator is defined between different DSMLs, it can be used to generate a coordination model between any models conforming the DSMLs used in the operator.

Figure 5.1. Overview of the approach.

BCOoL is developed on top of the eclipse platform as a set of plugins. More precisely, it is integrated to the GEMOC studio.

BCOoL is based on the EMF and its abstract syntax has been developed using Ecore (i.e., the meta-language associated with EMF). The textual concrete syntax has been developed using Xtext, providing advanced editing facilities.

BCOoL adds coordination facilities to the GEMOC studio. In the language workbench, an integrator can develop BCOoL operators to specify coordination patterns between languages, and then a system designer can use these operators in the modeling workbench to coordinate (possibly heterogeneous) models.

The GEMOC studio includes example operators that can be automatically deployed by using the wizard. Such examples can be a good starting point with BCOoL.

If you have defined a debug representation using Section 4.1, “Defining a debug representation”. You can use the following actions to start a debug session and toggle breakpoints.

The engine view displays a list of execution engines and their status:

The buttons available on the top right of this view respectively allow to:

The Multidimensional Timeline view provides an interactive representation of the execution trace being captured. When double-clicking on a previous state represented in the timeline, the model is brought back into this state. Moreover, the timeline represents all the different dimensions captured in a trace, each being the sequence of values taken by one specific element of the model. When double-clicking on a value that was reached by an element, the complete model is brought back in the state corresponding to this value.

In this mode, the Debug interface is extended with backward actions that behave similarly to their forward counterparts, but follow execution steps in the opposite direction:

MutiDimensional Timeline. 

This view represents the line of the model’s execution. It displays:

Sequential Execution MultiBranch Timeline. 

It is possible to select a logical step and use the contextual menu to show its caller by selecting the corresponding model element in the Sirius editor:

If you have defined a debug representation using Section 4.1, “Defining a debug representation”. You can use the following actions to start a debug session and toggle breakpoints.

A decorator is shown on all element holding a breakpoint. The decorator also reflects the state of the breakpoint:

When you hit a breakpoint on an element and are debugging with the decider "Step by step user decider", in order to restart the execution you must clic the resume button from the debug perspective. Then don’t forget to select the next logical step to execute. Do the same when debugging in step by step with the decider "Step by step user decider".

While executing you can visualize execution data. This setting must be defined by hand since the data are language dependent (see Section 4.1, “Defining a debug representation” for more details). Here the current state is decorated with a green arrow.

The default definition highlights the current instruction in yellow.

This view is part of the Debug perspective. It presents an interface for Step by Step execution of the model.

When an execution is paused, this view presents a stack containing all ongoing steps, with the last started step at the top of the stack.

At the bottom of the stack is a particular stackframe named Global context. When selected, this stackframe displays the runtime data in the Variable View.

When paused, the usual debugging tools (step into, step over and step return) can be used to control the execution step by step. With the multidimentional trace enabled, the execution can be controlled backward using the StepBack Into, StepBack Out and StepBack Over commands.

Debug and Variable views with the sequential engine. 

This view is available on the Debug perspective. When an execution is paused, this view presents the current Runtime Data of the model.

The engine view displays a list of execution engine and their statuses:

The buttons available on top right of this views respectivley allows to:

The logical steps view displays the list of possible future executions. This list is provided by the solver. This view is organized around a tree. For each logical step, its underlying events can be seen and possibly for each event the associated operation is visible.

Formely known as Event Scheduling Timeline view, this view represents the line of the model’s execution. It displays:

In addition to displaying information, it also provides interaction with the user. During execution, it is possible to come back into the past by double-clicking on any of the blue logical steps. It does three things:

It is also possible to select a logical step and use the contextual menu to show its caller in the Sirius editor:

The Stimuli Manager view display the list of MSE and has interactions with the Logical Steps view.

When selecting an MSE you can constrain it by clicking on :

Depending of your choice, the list of proposals will be changed in the Logical Steps view.

Moreover selecting an element in the Logical Steps view will highlight the MSE involved in the Stimuli Manager view.

If you have defined a debug representation using Section 4.1, “Defining a debug representation”. You can use the following actions to start a debug session and toggle breakpoints.

A decorator is shown on all element holding a breakpoint. The decorator also reflects the state of the breakpoint:

When you hit a breakpoint on an element and are debugging with the decider "Step by step user decider", in order to restart the execution you must click the resume button from the debug perspective. Then don’t forget to select the next logical step to execute. Do the same when debugging in step by step with the decider "Step by step user decider".

While executing you can visualize execution data. This setting must be defined by hand since the data are language dependent (see Section 4.1, “Defining a debug representation” for more details). Here the current state is decorated with a green arrow.

The default definition highlights the current instruction in yellow.

This view is part of the Debug perspective. It presents an interface for Step by Step execution at the Logical Step level or even at the DSA level. When an execution is paused, this view presents the current Logical Step.

When paused on a Logical Step, the Step over command allows to go to the next Logical Step. The Step Into command allows to run separately each of the internal DSA calls associated to the Logical Step.

This view is available on the Debug perspective. When an execution is paused, this view presents the current Runtime Data as an EMF based tree.

ECL specification is the starting point toward exploration. In this specification we define events associated with the actions of the DSA and also events associated with the DSE events. On these event bindings we apply the MoccML relations of the MoC Library to schedule the events. A finite state space of a system uses such scheduling constraints and therefore is generated from using a transformation:

In the Modeling workbench where the DSL instance model is realized, the transformation T2 takes as input the instance system model to generate a MOCC instance model described in ClockSystem specification format. Th call the transformation right-click on your model → Exhaustive Exploration → Generate ClockSystem file from DSL model.

A wizard allows you to select one xdsml project referencing a concurrent model, click on finish to execute the transformation. T2 generates the .clocksystem file corresponding to the Mocc-based specification model to take as input in ClockSystem.

Figure 9.1. Xdsml Wizard

The properties are expressed using assertions or/and observer automata with appropriate variables and clocks of the model instance. Several groups of properties are interesting to verify at different level in the Gemoc process. Properties can be expressed on the model instance based on variables and clocks of one (or several) model element(s) and allows to check deadlocks, precedency between events, reachability etc…​ The expression of the properties are model dependent so on each instance you must rewrite the properties. However properties can also be related to representative instances which are based on a mapping between a generic abstract syntax, or a metamodel pattern and a mapped Mocc on this abstract syntax. In this approach we are looking for a reducing number of instance to verify and increase the generality of the verification approach. A representative instance is a model that spreads a configuration that is structuraly relevant regarding the metamodel pattern. On this representative model, we can verify properties tightly linked with the MoCCML semantics.

For instance the model Figure 9.6, “Exploration Graph for an Instance” can be considered as a representative instance of a Classifier-Relationship metamodel pattern. On it wish to apply a Mocc SDF semantics and therefore generic properties can be expressed as: - If all the input ports of a Block haven’t enought data to consume then the Block canno’t execute. - If the number of data of an output port is less than the Connector capacity minus the current size of the Connector then the Block can execute. - In any case, the current size of a Connector canno’t exceed its capacity.

These properties are representatives of the Mocc and could be verified for every model. So we verify these properties on the representative model instance, to improve the trust on our pattern.

// Size of connector A to B never exceeds its capacity
predicate p2 is { {connectorAB}1 : currentsize <= 4 }

// If Output channel is full the Block does not execute
predicate p3 is { {connectorBA}1 : currentsize + {outport1}1 : rate <= {connectorBA}1 : capacity }
property o1 is {
	start -- / p3 // -> s1
	; s1 -- / / eB / -> reject
	; s1 -- / not p3 / / -> start
}

// Select the properties to be checked
cdl representativeInstance is {
	properties
	, o1
	assert p1
	; assert p2
	main is {skip}
}

To execute the coordinated system, we first need to go to Debug Configuration and configure the Gemoc Coordinated eXecutable Models as shown in the picture.

Figure 10.3. Debug Configuration of the Gemoc Coordinated eXecutable Models.

The execution can be launched by using either a BCOoL or a BFLoW specification. In the first case, the BCOoL specification is in the modeling workbench and the model of coordination is built by applying the BCOoL specification between all the models. In such a case, it is mandatory to specify the launchers of the individual models before to launch the execution.

In the case that a BFLoW specification is used (as shown in Figure 3), the model of coordination is built by using the BFLoW specification. If the BFLoW specification does not define the launchers, they must be manually defined by clicking on "Add Configuration" (see Figure 4).

Figure 10.4. Debug Configuration of the Gemoc Coordinated eXecutable Models with launchers.

Once launched, the engine provides several options to drive the execution of the models. For instance, it enables a system designer to select the next valid execution step (see Figure 5). Also, the workbench provides the animation of models.

Figure 10.5. Step by step execution of the coordinated models.

For further information about BCOoL please visit BCOoL site. If you are experimenting problems during the compilation of the example, please email to me.