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.
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[]
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, …).
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.
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.
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.
The XDSML framework relies on the Section 2.2, “Framework Commons” and offers some base classes for implementing the Language workbench UI.
Note
The initial design of this component comes from GEMOC ANR project. Some relevant architecture information may be found in http://gemoc.irisa.fr/ins-pub/m30/gemoc-anr-d4.3.1-v1.0.pdf
Tip
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 https://github.com/mbats/arduino
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[]
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.
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.
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/PlainK3ExecutionEngine.java as a base implementation for the AbstractCommandBasedSequentialExecutionEngine.java 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.
[33] asciidoc source of this page: https://github.com/eclipse/gemoc-studio/tree/master/docs/org.eclipse.gemoc.studio.doc/src/main/asciidoc/dev/Components_headContent.asciidoc.
[34] asciidoc source of this page: https://github.com/eclipse/gemoc-studio-modeldebugging/tree/master/execution_framework/execution_framework/docs/dev/ExecutionFramework.asciidoc.
[35] asciidoc source of this page: https://github.com/eclipse/gemoc-studio-modeldebugging/tree/master/execution_framework/xdsml_framework/docs/dev/FrameworkCommons.asciidoc.
[36] asciidoc source of this page: https://github.com/eclipse/gemoc-studio-modeldebugging/tree/master/execution_framework/xdsml_framework/docs/dev/XdsmlFramework.asciidoc.
[37] asciidoc source of this page: https://github.com/eclipse/gemoc-studio-modeldebugging/tree/master/simulationmodelanimation/docs/dev/SimulationModelAnimation.asciidoc.
[38] asciidoc source of this page: https://github.com/eclipse/gemoc-studio-modeldebugging/tree/master/java_execution/java_engine/docs/dev/JavaExecution.asciidoc.
[39] asciidoc source of this page: https://github.com/eclipse/gemoc-studio-modeldebugging/tree/master/java_execution/java_engine/docs/dev/JavaXdsml.asciidoc.
[40] asciidoc source of this page: https://github.com/eclipse/gemoc-studio-modeldebugging/tree/master/java_execution/docs/dev/JavaEngine.asciidoc.
