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 28. Components overview

1. Commons

Unresolved directive in master.asciidoc - include::../../../../../../gemoc-studio/commons/docs/dev/Commons_headContent.asciidoc[]

Unresolved directive in master.asciidoc - include::../../../../../../gemoc-studio/commons/docs/dev/GemocCommons.asciidoc[]

Unresolved directive in master.asciidoc - include::../../../../../../gemoc-studio/commons/docs/dev/GemocGExpressions.asciidoc[]

Unresolved directive in master.asciidoc - include::../../../../../../gemoc-studio/commons/docs/dev/GemocDsl.asciidoc[]

2. GEMOC Framework

2.1. Execution Framework


Figure 29, “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 29. ExecutionEngine overview

Figure 30, “ExecutionEngine typical flow” shows a typical execution flow of the Engine. The couple Engine and execution transformation must implement the IExecutionEngine interface (cf. Figure 31, “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 30. 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 2.1, “Sequential Launch configuration” and Section 3.1, “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.

2.2. Framework Commons


Figure 31, “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 31. Execution Framework API Interfaces overview

2.3. XDSML Framework


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

3. Simulation Model Animation Framework



The initial design of this component comes from GEMOC ANR project. Some relevant architecture information 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

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 28, “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 28, “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 32. PlainK3ExecutionEngine overview

PlainK3ExecutionEngine typical flow

Figure 33. ExecutionEngine typical flow