GEMOC Studio Documentation
Developer Guide

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

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.

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.

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

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

The current list of such jars is:

This is the base for the debugger.

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">
	<debugModelPresentation
		class="org.eclipse.gemoc.dsl.debug.ide.sirius.ui.DSLDebugModelPresentation"
		id="com.example.dsl.ui.debugModel">
	</debugModelPresentation>
</extension>

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”.

^[74]

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, …​).

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.

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:

^[75]

List of plugins:

The org.eclipse.gemoc.ws.server plugin offers services to add websocket endpoints in an Eclipse application (with UI or headless).

The plugin starts a websocket server on a free port of the system. It uses Jetty as server.

It defines an extension point to define websocket endpoint so any other plugin can contribute their endpoint.

Example of use declaring a test endpoint:

In your plugin.xml:

<extension point="org.eclipse.gemoc.ws.server.endpoint">
  <GEMOC_WS_EndPoint
    class="org.example.endpoint.TestEndPoint" 
    id="org.example.TestEndPoint">
  </GEMOC_WS_EndPoint>
</extension>

Class implementing the endpoint.

package org.example.endpoint;

import javax.websocket.OnMessage;
import javax.websocket.server.ServerEndpoint;

@ServerEndpoint("/test") 
public class TestEndPoint {

    @OnMessage
    public void handleOnMessage(String message) {
        System.out.println("Message received by WebSocket : "+message); 
    }
}

On start, the server look for an available port (this is displayed on the console).

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.

^[76]

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

^[77]

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.

^[80]

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