GEMOC Studio Documentation
Modeling workbench user guide

^[34]

^[35]

^[37]

The engine view displays a list of execution engines and their status:

Figure 17. Engine View

In Figure 17, “Engine View”, the buttons available on the top right of this view respectively allow to:

1.3.1.1. CCSLJava addition to Engine View

^[38]

The CCSLJava engine adds some commands to the Engine view.

Figure 18. CCSLJava addition to Engine View

It adds a new button (represented as a shield on top right of Figure 18, “CCSLJava addition to Engine View”) that allows to change the current Logical Step decider used by the CCSLJava engine.

Tip

When running a model, You can easily "pause" the 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.

Warning

Even if they both pause the execution, choosing a "Step by step decider" is currently different from the "suspend" of a breakpoint from the Debug commands. The former ask the user for a decision about the logical step to execute and the later suspends the execution in order to analyze it.

Help is welcome to contribute a way to align them.

^[39]

The Logical Step View is provided by the CCSLJava Engine.

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.

^[40]

The Stimuli Manager View is provided by the CCSLJava Engine.

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.

By default the Sirius animation will refresh on every engine notification and will wait for the end of the refresh before processing the next steps. While providing precise display, on complex diagram (for example with many queries or several views) this can significantly slow down the model execution speed.

In order to speed up the model execution, GEMOC provides several Sirius animation strategies:

These strategies are set in the Preferences → Run/Debug → GEMOC Sirius Animation (see Figure 21, “GEMOC Sirius animation preference page.”)

Figure 21. GEMOC Sirius animation preference page.

^[50]

The Multidimensional Timeline view provides an interactive representation of the execution trace being captured and the states of the Runtime Data. 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 runtime data 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. Bullets and line in orange correspond to the current state.

MutiDimensional Timeline Overview. 

Each bullets on top of the view represent a state of the Runtime Data. The lines between states represent the method call as a kind of stack. Dot lines indicate that the model has been set back to a previous state (ie. currently navigating in the past and also represented by the icon )

In this mode, the Debug commands are extended with backward actions that behave on the call stack similarly to their forward counterparts, but follow execution steps in the opposite direction: StepBack Into, StepBack Out, and StepBack Over.

Each row below represent one runtime data dimension. Ie. an attribute or a reference in the model. In these rows, a line indicate that the given data has not changed during these states (Ie. the state has been recorded due to a change in another data)

When exploring the trace, the navigation buttons Navigate backward Navigate forward allows to go directly to the previous or next state where the given data has changed.

The Jump to state command allows to jump directly to a given state by providing its number.

The check box at the beginning of each row allows to hide the corresponding data. When unchecked, it is actually put at the bottom of the list.

The state coloration command allows to set some unique color on the states using only dimensions that are not hidden.

A trace can be saved and reloaded using the commands on top of the view. Saved traces can then be compared using the Timeline Diff view or displayed in the State Graph View.

MutiDimensional Timeline Implicit States. 

In some cases, like states 6 and 9 in MutiDimensional Timeline Implicit States, some states may use a diagonal hash pattern color. This indicates that some changes in the runtime data have been recorded between 2 declared steps. This can happen for example with nested steps where runtime data are changed in the caller step;

@Step
def public void outerStep() {
	... // change some runtime data before calling innerStep() 

	_self.innerStep()

	... // change some runtime data after calling innerStep() 
}

@Step
def public void innerStep() {
	... // change some runtime data 
}

^[52]

Formerly known as Event Scheduling Timeline view, this view represents the lines of the model’s execution with a focus for concurrent behavior and LogicalSteps events. It displays:

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:

3.5.2.1. Java engine specific support for multibranch timeline

^[53]

As the Java engine doesn’t offer execution branches (no possible concurrent actions), all commands related to branches are disabled and the timeline will allow to display only a straight line.

Figure 26. Multibranch timeline with Java engine

Warning

When going backward then forward again using the Java Engine, 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 recorded Step in the timeline.

^[54]

This view allows to compare the Runtime Data dimensions of two saved traces.

Obtaining traces can be done using the save command in the Section 3.5.1, “Multidimentional timeline view”.

^[55]

This view allows to search for cycles in the current trace.

This view is synchronized with the Section 3.5.1, “Multidimentional timeline view” and uses the hide/show dimension checkboxes information in order to display the state graph only for visible data.

^[56]

If you have defined a debug representation using Section 2.1, “Define a debug representation and commands for Sirius”. You can use the following actions to start a debug session and toggle breakpoints.

Usually, elements with a break point are decorated with a blue bullet.

Additionally, when suspended during the execution in Debug mode, the target of the current instruction in the call stack can be highlighted. In the following example, (Figure 27, “Sirius debug stack highlighting”) the selected element in the Debug stack (top left) is highlighted in yellow in Sirius (bottom left) thanks to the Debug layer added to the editor.

Figure 27. Sirius debug stack highlighting

^[57]

If your language has a concrete syntax specified using XText, when running a model, the debugger will take care to highlight the correct line in the xtext editor corresponding to the target model element of the selected call in the call stack.

In the following example, (Figure 28, “Xtext debug stack highlighting”) the selected element in the Debug stack (top left) is highlighted with an arrow in Xtext (bottom right).

Figure 28. Xtext debug stack highlighting