As the GEMOC Studio offer different engines that requires specific configurations, it currently offers one launch configuration per engine. The views offered when running or debugging a model may also vary depending on the execution mode and the engine kind.
Run and debug are configured using the launch configuration. An example of configuration:
- Model to execute : this is the model that will be executed
- Model initialization method and argument : if the choosen language has a valid method with the
@InitializeModel
annotation in its DSA, the field Model initialization method will be set and this method will be called before launching the animation. - Model initialization arguments : optional string arguments that can be passed to the initialization method. (one string per line)
- Melange languages : this field allows to select among the languages defined in Melange.
- Main method : the name of the method that can be used to start the engine. The possible value are specified by the language
designer in the language definition by adding an
@Main
annotation on methods in the DSA. - Main model element path : after having selected a main method, use the browse button to select a model element on wich this method will be called. This field presents its path in the model, the following field Main model element name displays a human readable name for this element.
The break at start tells to the debugger to add a virtual breakpoint on the first instruction that will run.
Note
@Main
and @InitializeModel
annotations used to declare possible methods used in this launcher are detailed in Section 1.1, “Defining the Domain-Specific Actions (DSA) Project for Sequential language”.
The run mode is the fastest way to execute a model. The execution cannot be paused. It can however be stopped. It offers a limited set of views :
- the Engine View allows to stop a running model.
- the MultiBranch Timeline View is displayed at the end of the execution in order to check the resulting execution trace.
If more feedback is required, please use one of the frontend or backend available for the xDSML, see Backends and frontends.
In debug mode, the engine offers more control over the execution. It allows to pause, add breakpoints, and execute the model in a step by step mode.
It reuses the Eclipse Debug perspective and some of its views and adds some Gemoc specific views.
- the Engine View allows to stop a running model.
- the Animation Manager View is displayed and updated in real-time during the simulation. It can display both an animation layer and a debug layer.
- the Debug View. This view presents an interface for Step by Step execution of the model.
- the Variable View. This view presents the Runtime Data as a (EMF based) tree.
When running a simulation in Debug mode, it is configured to activate automatically the Debug layer and the Animation layer in the Animation view.
On the engine addon tab, one can activate several optional addons.
- the MultiBranch Timeline View can be displayed during all the simulation.
- the MultiDimensional Timeline View can be displayed during all the simulation.
The engine view displays a list of execution engines and their status:
- number of execution steps,
- current running status.
The buttons available on the top right of this view respectively allow to:
- Stop the selected engine (red square button)
- Remove previously stopped engines from the view (crosses button)
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:
- StepBack Into
- StepBack Out
- StepBack Over
Warning
When going backward then forward again, the execution is a kind of replay
where only the model is updated. The DSA operations are not run. The DSA will run again normally when the engine will try to run the last Step in the timeline.
Note
This view currently works only with the Sequential engine. We’re working on extending its use to concurrent model execution too.
MutiDimensional Timeline.
Warning
Formerly known as Event Scheduling Timeline
view, this view is limited when run in Sequential. Since there is no choice of Logical Step like with the concurrent engine,
the branch mechanism is disabled and this view presents only a single line.
However, despite the Multidimensional trace, this view does not require to generate a specific trace addon for the language.
This view represents the line of the model’s execution. It displays:
- the different steps executed by the engine. Steps that have completely finished (ie. operation has returned) are shown in blue. Unfinished Steps are shown in yellow.
- the model specific events for each step.
Note
This view is enabled/disable in the launch configuration by checking "Event Scheduling Execution tracing" in the Engine Addons tab.
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 3, “Define a debug representation for Sirius”. 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:
- enabled
- disabled
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 3, “Define a debug representation for Sirius” 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.
Note
In order to improve the look and feel in Debug and Variable views with the sequential engine, the icons have been customized using the technique described in Section 3.3, “Defining a Concrete Syntax with EMF”
This view is available on the Debug perspective. When an execution is paused, this view presents the current Runtime Data of the model.
Note
To control which Runtime Data should be presented in the Variable view, you need to set an EAnnotation with nsURI set to aspect
on the corresponding EAttributes, EReferences or EClass in the ecore metamodel.
Tip
When the execution is paused, it is possible to edit the values in this view and then manually change the Runtime Data of the model.
If the Multidimenstional trace is activated, this tip works only if the execution is paused on the last instraction of the trace.
Run and debug are configured using the launch configuration. An example of configuration:
- Model to execute : this is the model that will be run
- Melange languages : this field allows to select among the languages defined in Melange.
-
Decider : this field allows to select the solver strategy used by the engine when several Logical Steps can be triggered. Possible choices are :
- Solver proposition : the solver internal strategy will be used to select a Logical Step
- Random : will randomly select one of the available Logical Step (warning: execution cannot be reproduced when using this Decider)
- Ask user : (available only in Debug mode), this option will use the Logical Step View or the MultiBranch Timeline View to present the available Logical Steps and pause if there are more than one Logical Step. The user will then need to click on one of the Logical Step to continue.
- Ask user (Step by step) : (available only in Debug mode), this option is similar to the previous one. However, it will pause on every Logical Step, even if there is only one Logical Step that can be triggered. This is more or less equivalent as putting a breakpoint on every MSE of the language.
More Deciders will be developed (for example for playing predefined scenario).
In run mode, it offers the faster way to run the model. It cannot be paused. However, you can stop it. It offers a limited set of views :
- the Engine View allows to stop a running model.
- the MultiBranch Timeline View is displayed at the end of the execution in order to control the resulting execution trace.
If more feedback are required, please use one of the frontend or backend available for the xDSML, see Backends and frontends.
In debug mode, the engine offers more control on the execution. It allows to pause, add breakpoint, and run in a step by step mode.
It reuses the Eclipse Debug perspective and some of its views and add some GEMOC specific views.
- the Engine View allows to stop a running model.
- the MultiBranch Timeline View can be displayed during all the simulation.
- the Logical Steps View is available for concurrent execution.
- the Stimuli Manager View is displayed during all the simulation.
- the Animation Manager View is displayed during all the simulation. It can display both an animation layer and a debug layer.
- the Debug View. This view presents an interface for Step by Step execution at the Logical Step level or even at the DSA level.
- the Variable View. This view presents the Runtime Data as a (EMF based) tree.
When running a simulation in Debug mode, it is configured to activate automatically the Debug layer and the Animation layer in the Animation view.
The break at start tells to the debugger to add a virtual breakpoint on the first instruction that will run.
Backends and frontends offer additionnal view that can respectively display informations from the running model or provide event input to the running model.
These backends and front ends usually open dedicated views. These views are always opened in all modes (Run or Debug).
The engine view displays a list of execution engine and their statuses:
- its number of execution steps,
- its current running status,
- and its logical steps deciding strategy.
The buttons available on top right of this views respectively allows to:
- Stop the selected Engine (red square button)
- Remove previously stopped engines from the view (crosses button)
- Change the current logical step decider (shield button).
Tip
When running in debug mode, You can easily "pause" an engine running with a solver or random decider by clicking on the change logical step decider (the shield button will be green when run in debug mode) this will automatically switch to the "Step by step decider". To restart, simply select back an automatic decider (solver or random) and select the next step in the LogicalStep view.
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.
Note
This view displays nothing when execution runs in "run mode", per say this view is only of use when running in "debug mode".
Formely known as Event Scheduling Timeline view, this view represents the line of the model’s execution. It displays:
- the different logical steps proposed by the solver in the past in blue color,
- the selected logical steps at each execution step in green color,
- and the possible future logical steps in yellow color,
- the model specific events for each logical step.
Note
This view can be enabled/disable in the launch configuration by checking "Execution tracing" in the Engine Addons tab.
Note
The possible future logical steps are shown under the condition that the model is executing.
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 resets the solver’s state to the selected execution step,
- and it resets the model’s state to the selected execution step,
- it also forks the current timeline and create a new branch of execution.
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 :
- Green down arrow : no user constraint for this MSE in the next LogicalStep
- Orange down arrow : forbid tick of this MSE in the next LogicalStep. The solver will propose only solutions where this MSE doesn’t tick.
- Orange up : force tick of this MSE in the next LogicalSteps. The solver will propose only solutions where this MSE ticks.
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.
Tip
This Stimuli Manager view can be used to manually simulate external events.
If you have defined a debug representation using Section 3, “Define a debug representation for Sirius”. 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:
- enabled
- disabled
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 3, “Define a debug representation for Sirius” 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.