| Chapter 9. Execute, animate and debug models | ||
|---|---|---|
| Prev | Part II. Modeling workbench User Guide  | Next |
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:
@InitializeModel annotation in its DSA, the field Model initialization method will be set and this method will be called before launching the animation.@Main annotation on methods in the DSA.The break at start tells to the debugger to add a virtual breakpoint on the first instruction that will run.
@Main and @InitializeModel annotations used to declare possible methods used in this launcher are detailed in Section 3.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 :
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.
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 engine view displays a list of execution engines and their status:
The buttons available on the top right of this view respectively allow to:
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 OverWhen 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.
This view currently works only with the Sequential engine. We’re working on extending its use to concurrent model execution too.
MutiDimensional Timeline. 
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:
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 4.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:
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 4.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. 
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 2.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.
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.
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:
Decider : this field allows to select the solver strategy used by the engine when several Logical Steps can be triggered. Possible choices are :
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 :
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.
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:
The buttons available on top right of this views respectively allows to:
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.
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:
This view can be enabled/disable in the launch configuration by checking "Execution tracing" in the Engine Addons tab.
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 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 :
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.
This Stimuli Manager view can be used to manually simulate external events.
If you have defined a debug representation using Section 4.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:
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 4.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.
