Skip to main content
aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat (limited to 'plugins/doc/org.eclipse.papyrus.moka.doc/resource/moka.mediawiki')
-rwxr-xr-xplugins/doc/org.eclipse.papyrus.moka.doc/resource/moka.mediawiki42
1 files changed, 21 insertions, 21 deletions
diff --git a/plugins/doc/org.eclipse.papyrus.moka.doc/resource/moka.mediawiki b/plugins/doc/org.eclipse.papyrus.moka.doc/resource/moka.mediawiki
index cf4262b98af..0a82648b995 100755
--- a/plugins/doc/org.eclipse.papyrus.moka.doc/resource/moka.mediawiki
+++ b/plugins/doc/org.eclipse.papyrus.moka.doc/resource/moka.mediawiki
@@ -19,25 +19,25 @@ Moka can be easily extended to address new execution semantics. This can be don
This tutorial is based on a simple executable model. It consists in an active class, with a classifier behavior that indefinitely increments a counter. The corresponding Papyrus model is available here [https://wiki.eclipse.org/File:BasicActiveObjectExample.zip]. Download it, define a project in your workspace, and then import the model in this project. Once the model is imported and open in Papyrus, the Increment class should look like:
-[[Image:ActiveClassDiagram.png|The active class increment]]
+[[Image:images/ActiveClassDiagram.png|The active class increment]]
The behaviors associated with this class (i.e., IncrementClassifierBehavior, which is the classifier behavior, and incrementMethod, which is the implementation of operation increment) are specified by activity diagrams. Corresponding activities are executable, according to the semantics given in OMG standards fUML and PSCS. Anyway, in fUML and PSCS, the execution of a model usually starts by executing a kind of "main" activity, which is responsible for instantiating objects, and stimulate them if needed (through signals or operation calls). Moka provides some facilities to generate this kind of activities. Just right click on class Increment, then go to Moka / Modeling Utils / Generate Factory.
-[[Image:GenerateFactory.png]]
+[[Image:images/GenerateFactory.png]]
A factory activity for class Increment (Increment_Factory in the figure below) is then generated. This activity will be used in the next steps of this tutorial to actually start the execution of the model. Do not forget to save your model, otherwise the factory will not be visible in the launch configuration definition step described below in this tutorial.
-[[Image:modelExplorer_Create.png]]
+[[Image:images/modelExplorer_Create.png]]
== Selecting the execution engine ==
Since Moka is an extensible execution framework, multiple execution engines can be registered in your environment. Before starting an execution, you should make sure that the appropriate execution engine is selected. To do so, go to Eclipse preferences, as shown in the figure below.
-[[Image:Window_Preferences.png]]
+[[Image:images/Window_Preferences.png]]
Once the preference page is open, go to Papyrus/Moka. Moka is released with 3 execution engines. There are two versions of the PSCS execution engine (one is multi-threaded, with on thread per active object, and the other one is single-threaded). There is also an implementation of the fUML execution engine.
-[[Image:Papyrus_Moka_ExecutionEngines.png]]
+[[Image:images/Papyrus_Moka_ExecutionEngines.png]]
To make sure that the Increment example properly executes, you should select one of the two PSCS engines, press Apply and then OK.
@@ -45,19 +45,19 @@ To make sure that the Increment example properly executes, you should select one
Moka is integrated with the Eclipse Debug Framework. It implies that, in order to start an execution, a launch configuration has to be defined. A launch configuration can be created by clicking on the "Debug As" tool from the Eclipse tool bar, and then by pressing Debug Configurations.
-[[Image:Debug_Configuration.png]]
+[[Image:images/Debug_Configuration.png]]
Then create a new Moka launch configuration, as shown in the figure below.
-[[Image:New_Configuration.png]]
+[[Image:images/New_Configuration.png]]
A Moka launch configuration requires two pieces of information: the UML model from which the execution will be started, and the actual model element to be executed.
-[[Image:EmptyLaunchConfiguration.png]]
+[[Image:images/EmptyLaunchConfiguration.png]]
Press the Browse button to select a UML model from your workspace (a .uml file shall be selected). Then, select the actual model element to be executed in the list "Element to be executed". This list is sorted alphabetically, by qualified names. Note that, in the case of the fUML and PSCS execution engines provided by Moka, the "Element to be executed" shall be an Activity. Your launch configuration should now look like:
-[[Image:Setup_launch_configuration.png]]
+[[Image:images/Setup_launch_configuration.png]]
To start the execution, simply press the Debug button. In our example, according to the semantics of PSCS, the effect of executing activity Increment_Factory will be to instantiate an Increment object, to construct this object (please refer to the default construction strategy described in the PSCS specification), and then start its classifier behavior. Our increment object will start to increment, and will go on until you stop the execution. Note that a Launch configuration is a persistent artifact, so that, if you close Papyrus and then open it again, your launch configuration will still be available, and you will be able to relaunch it.
@@ -65,25 +65,25 @@ To start the execution, simply press the Debug button. In our example, according
In order to easily observe and control the state of you model at some specific points of the execution, Moka lets you associate breakpoints with model elements. This can be done through the contextual menu Moka/Debug, which is available from the model explorer and from diagrams.
-[[Image:ToggleBreakpointModelExplorer.png]]
+[[Image:images/ToggleBreakpointModelExplorer.png]]
-[[Image:ToggleBreakpoint.png]]
+[[Image:images/ToggleBreakpoint.png]]
Once a breakpoint has been created, a small icon (blue circle) appears on top of the corresponding model element.
-[[Image:BreakpointDiagramView.png]]
+[[Image:images/BreakpointDiagramView.png]]
Using the Moka/Debug menu, an existing breakpoing can also be de-activated (without being removed), using the "Toggle breakpoint activation" button. In this case, it will be depicted by a small white circle on top of the corresponding model element.
-[[Image:ToogleBreakpointActivation.png]]
+[[Image:images/ToogleBreakpointActivation.png]]
The set of existing breakpoints (as well as their status - Enabled / Disabled) is given in the breakpoint control panel, which is usually located in the upper, righ-hand part of the Debug perspective.
-[[Image:BreakpointsView.png]]
+[[Image:images/BreakpointsView.png]]
The breakpoint control panel more generally lets you enable, disable and remove breakpoints. Just right click in the panel, as depicted in the figure below.
-[[Image:RemoveBreakpoints.png]]
+[[Image:images/RemoveBreakpoints.png]]
From an execution standpoint, it is important to note that the selected execution engine (see section on "Selecting the execution engine") is responsible for interpreting breakpoints. In the case of the fUML and PSCS execution engines provided by Moka, only breakpoints associated with activity nodes or edges will be taken into account (even if Moka lets you associate breakpoints with any kind of model element). Other breakpoints are simply ignored.
@@ -91,11 +91,11 @@ From an execution standpoint, it is important to note that the selected executi
Executions can be controlled using the execution control panel, provided by the Eclipse Debug perspective.
-[[Image:ThreadStatusView_empty.png]]
+[[Image:images/ThreadStatusView_empty.png]]
It is thereby possible to resume, suspend, stop, or even do step-by-step executions. Note also that, when execution is suspended, variables may be observable in the variable panel.
-[[Image:VariableView.png]]
+[[Image:images/VariableView.png]]
The selected execution engine is responsible to determine what the visible variables are in the context of an execution. In the case of the fUML and PSCS engines provided by Moka, visible variables are properties of the context object in which in the suspended activity is executing (in our example, the suspended activity is the classifier behavior of class Increment, which executes in the context of a particular Increment object, which holds a value for property counter).
@@ -103,13 +103,13 @@ The selected execution engine is responsible to determine what the visible varia
By default, Moka is configured to animate diagrams during executions, without automatically giving focus / making visible a diagram where a model element being executed has a graphical representation. This can be configured in the Animation control panel, which is available in the Debug perspective.
-[[Image:AnimationConfiguration.png]]
+[[Image:images/AnimationConfiguration.png]]
The slide bar enables to control the artificial animation delay between two animation steps. Note that option "Open diagrams automatically" may decrease performances of the execution engine. By default, Moka is released with some default animation styles, which determine the emphasis style to be applied to graphical elements when the execution is suspended, or more generally for animation. This default style can be overloaded per diagram, by attaching a CSS style sheet, as depicted in the figures below.
-[[Image:PropertiesView_EmptyStyleSheets.png]]
+[[Image:images/PropertiesView_EmptyStyleSheets.png]]
-[[Image:NewStyleSheets.png]]
+[[Image:images/NewStyleSheets.png]]
-[[Image:MyStyleSheets.png]]
+[[Image:images/MyStyleSheets.png]]

Back to the top