Components documentation


The code of GEMOC studio is gathered in several main groups.

The organization of these groups is driven by feature but also try to minimize dependencies.

Components overview

Figure 49. Components overview

1. Commons


The commons component groups various helper plugins that do not directly contributes to the GEMOC Framework and that can be reused by other projects.


As these plugins can be used in other contexts than GEMOC context, several feature are provided to group the plugins in order to install only a subset of these plugins.

1.1. DSL

The plugins named org.eclipse.gemoc.dsl* provides an xtext editor for editing .dsl files.

1.2. GExpression

The plugins named org.eclipse.gemoc.gexpressions* provides a metamodel and an xtext editor for specifying logical expressions. This metamodel is designed to be extendable and reused in other languages. For example it is used in the coordinatin language BCOoL.

GExpression ecore

Figure 50. GExpression ecore

1.3. Commons Eclipse

The plugins org.eclipse.gemoc.commons.eclipse* offers various services or reusable classes in order to simplify coding in the context of Eclipse.

They are organized in order to minimize the dependencies to Eclipse.

  • org.eclipse.gemoc.commons.eclipse: various helper classes for manipulating eclipse.core.resources, eclipse.emf resources (it includes an EMF resource merger)
  • org.eclipse.gemoc.commons.eclipse.jdt: various helper classes for manipulating java projects
  • org.eclipse.gemoc.commons.eclipse.jdt.autosrcfolder: plugin (and ui) that offers to automatically create missing source folders in the workspace
  • org.eclipse.gemoc.commons.eclipse.messagingsystem.api: helper classes allowing to manipulate Eclipse console, Eclipse log and markers
  • org.eclipse.gemoc.commons.eclipse.messagingsystem.ui: UI for messagingsystem.api
  • org.eclipse.gemoc.commons.eclipse.pde: various helper classes and abstract classes allowing to manipulate plugin definition (modify manifest, classpath,; it also offers a base new project wizard supporting extensible templates.
  • org.eclipse.gemoc.commons.eclipse.ui

1.4. Timeline

The org.eclipse.gemoc.timeline plugin offers some basic/reusable code to draw a timeline view in Eclipse.

1.5. Commons Thirdparty

GEMOC sometimes reuses standard jars from thirdparty that needs to be bundled as Eclipse plugins.

The current list of such jars is:

  • org.eclipse.gemoc.groovy (org.codehaus.groovy groovy-all 2.4.9)
  • org.jaxen (jaxen 1.1.6)
  • org.jdom2 (jdom 2.0.6)

2. Simulation model animation framework



The initial design of this component comes from GEMOC ANR project. Some relevant architecture information not copied yet in this document may be found in


The content of this framework can be used standalone in order to use only basic animation and debug services. The concrete implementation then has to create its own engine and launcher architecture (Ie. reproduce the other parts of the GEMOC framework in order to integrate the DSL in the IDE UI). An example of such implementation can be found with the Arduino Designer demo

2.1. Debugger

This is the base for the debugger.

Base DSLDebugger overview

Figure 51. Base debugger presentation overview

2.2. Debug model presentation

The debug model presentation is responsible for GUI representation of the debug model. It provides icons and labels. It also opens editor when a breakpoint is hit, or an instruction must be displayed for a given stack frame The DSL debugger provides a default implementation for generated EMF editors integration.

It can be used via the following extension:

<extension point="org.eclipse.debug.ui.debugModelPresentations">

It can also be extended for specific needs. For example, the GEMOC Framework provides an extended version of the Debug model presentation. See Section 3.1.2, “Debug model presentation”.

Base Debug model presentation overview

Figure 52. Base debug model presentation overview

3. GEMOC framework

3.1. Execution Framework


Figure 53, “ExecutionEngine overview” shows a typical concrete engine implementation. In this diagram, we use the concrete classes coming from the JavaEngine (see Section 5.1, “Java Execution”). Where the PlainK3ExecutionEngine is able to correctly deal with the step notifications to the IEngineAddon thanks to an IStepManager implementation in K3. This management of the Step notification may differ depending on the Engine and the technology used to implement the DSL behavior (mocml, ALE, XMOF, …​).

ExecutionEngine overview

Figure 53. ExecutionEngine overview

Figure 54, “ExecutionEngine typical flow” shows a typical execution flow of the Engine. The couple Engine and execution transformation must implement the IExecutionEngine interface (cf. Figure 57, “Execution Framework API Interfaces overview”) and are in charge of calling the methods of IengineAddon during the model execution.

In this sequence diagram, calls to Addons are actually a call to the corresponding method to all registered classes implementing IEngineAddon for the current execution context.

ExecutionEngine typical flow

Figure 54. ExecutionEngine typical flow

In most situation, the registration of addons is done using the org.eclipse.gemoc.gemoc_language_workbench.engine_addon or the org.eclipse.gemoc.gemoc_language_workbench.xdsml plugin extension points. Addons registered via extension points can be enabled or disabled by the end user in the launch configuration tab. (see Section 1.1.1, “Sequential Engine Launch Configuration” and Section 1.1.2, “Concurrent Launch configuration” in the Modeling Workbench User Guide)

Addons registered on org.eclipse.gemoc.gemoc_language_workbench.engine_addon extension point are supposed language agnostic and should apply to any DSL. However they may be engine dependent. They are typically designed by GEMOC contributors who wish to extend GEMOC features.

Addons registered on org.eclipse.gemoc.gemoc_language_workbench.xdsml extension point are supposed language specific and should apply to a single DSL. They are typically designed by a Language designer who which to offer a specific feature for the language he is developing.

Mandatory addons do not need to be declared as extension point, they are directly handled by the engine/launcher implementation. (search for a call to addEngineAddon in order to find addons that are programmatically added to the execution.

Two main examples for mandatory addons are:

  • the Sirius animation used by Sirius services is registered in AbstractSequentialGemocLauncher.launch
  • the debugger itself is registered in AbstractGemocLauncher.getDebugger. As it is responsible for pausing the execution flow on steps according to the breakpoints, it listens the calls to the engine events.

3.1.1. Execution Framework Debugger

The debugger of the GEMOC Execution Framework is based on the DSLDebugger of the Simulation and model animation framework (see Section 2.1, “Debugger”).

ExecutionFramework DSLDebugger overview

Figure 55. Execution framework debugger overview

3.1.2. Debug model presentation

The GEMOC Framework implements an extension of the Debug model presentation structure of the Simulation and model animation framework (see Section 2.1, “Debugger”).

Execution framework debug model presentation overview

Figure 56. Execution framework debug model presentation overview


3.2. Framework Commons


Figure 57, “Execution Framework API Interfaces overview” shows some of the major interfaces of the execution framework API. Most notably, the IEngineAddon and IExecutionEngine interfaces that are the entry points when implementing an Addon for GEMOC.

Execution Framework API Interfaces overview

Figure 57. Execution Framework API Interfaces overview


The section Section 2.1, “Developing new Addons” contains some details and code snippets about how to write an engine addon.

3.3. XDSML Framework


The XDSML framework relies on the Section 3.2, “Framework Commons” and offers some base classes for implementing the Language workbench UI.

4. Trace framework

Unresolved directive in master.asciidoc - include::../../../../../../gemoc-studio-modeldebugging/trace/docs/dev/Trace.asciidoc[]

Unresolved directive in master.asciidoc - include::../../../../../../gemoc-studio-modeldebugging/trace/docs/dev/TraceCommons.asciidoc[]

Unresolved directive in master.asciidoc - include::../../../../../../gemoc-studio-modeldebugging/trace/docs/dev/TraceGenerator.asciidoc[]

Unresolved directive in master.asciidoc - include::../../../../../../gemoc-studio-modeldebugging/trace/docs/dev/TraceManager.asciidoc[]

5. Execution engines

5.1. Java Execution


The Java execution offers a way to express sequential behavior using Java and compatible languages such as xtend+K3.

As usual in the studio, the code is split between part dedicated to the Language Workbench or to the Modeling Workbench. Th code for the Language workbench is located in the java_xdsml folder, the code for the modeling workbench is in java_engine.

5.1.1. Java XDSML


This component implements the user interface and services for the language workbench dedicated to the case of the JavaEngine. As seen in Figure 49, “Components overview”, it is based on the XDSML Framework from GEMOC Framewok.

5.1.2. Java Engine


This component implements the services and user interface modeling workbench dedicated to the case of the JavaEngine. As seen in Figure 49, “Components overview”, it is based on the Execution Framework from GEMOC Framewok.

The engine provides the class org.eclipse.gemoc.execution.sequential.javaengine/src/org/eclipse/gemoc/execution/sequential/javaengine/ as a base implementation for the class.

It relies on IStepManager and StepManagerRegistry provided by K3 in order to correctly do the notification calls to the Addons for each of the method that have been annotated with the @Step annotation.

PlainK3ExecutionEngine overview

Figure 58. PlainK3ExecutionEngine overview

PlainK3ExecutionEngine typical flow

Figure 59. ExecutionEngine typical flow

5.2. ALE Execution


The ALE execution offers a way to express sequential behavior using ALE language.

5.2.1. ALE XDSML


This component implements the user interface and services for the language workbench dedicated to the case of the ALE Engine. As seen in Figure 49, “Components overview”, it is based on the XDSML Framework from GEMOC Framewok.

5.2.2. ALE Interpreted Engine


This component implements the services and user interface modeling workbench dedicated to the case of the JavaEngine. As seen in Figure 49, “Components overview”, it is based on the Execution Framework from GEMOC Framewok.

The engine provides the class org.eclipse.gemoc.ale.interpreted.engine/src/org/eclipse/gemoc/ale/interpreted/engine/ as a base implementation for the class.

Similarly to K3, it relies on annotations in the ALE code in order to correctly do the notification calls to the Addons.

This includes @step, @main, and @init annotations.

In order to achieve this, it registers to

ALE Interpreter Execution Engine overview

Figure 60. ALE Interpreter ExecutionEngine overview