Merge branch 'master' of https://github.com/Yakindu/statecharts.git

plugins/org.yakindu.sct.doc.user/src/user-guide/advanced_simulation.textile

@@ -5,7 +5,7 @@ p.
 
 p(edit-on-github). "Edit on GitHub":https://github.com/Yakindu/statecharts/edit/master/plugins/org.yakindu.sct.doc.user/src/user-guide/advanced_simulation.textile
 
-h1(#advsim_simulation). Debugging with breakpoints and snapshots
+h1(#advsim_debugging-with-breakpoints-and-snapshots). Debugging with breakpoints and snapshots
 
 h2(#advsim_introduction). Introduction
 
@@ -124,11 +124,11 @@ Enter the condition into the text field. Like in the statechart editor, a conten
 
 h2(#advsim_debugging-a-statechart). Debugging a statechart
 
-h3. Changing variable values
+h3(#advsim_changing-variable-values). Changing variable values
 
 In the suspended status of a statechart simulation you can change variable values using the _simulation_ view. When continuing execution – see section "Continuing the simulation":#advsim_continuing-the-simulation – you can observe how your state machine behaves with those modified values.
 
-h3. Raising multiple events simultaneously
+h3(#advsim_raising-multiple-events-simultaneously). Raising multiple events simultaneously
 
 If you click on an event's name in the _simulation_ view to raise that event in normal simulation, i. e. while execution isn't suspended, the state machine immediately processes that event and takes the corresponding transition, if any.
 
@@ -155,7 +155,7 @@ Both events are raised and will be handled by the state machine during the next
 
 bq. Please note: While the execution is still suspended, you can "unraise" an already raised event by clicking at the event symbol !(inlinemediaobject)images/advsim_symbol_event_raised.png(event raised)! a second time. The blue triangle will disappear, and upon continuation of the simulation the event will not be handled.
 
-h4. Transition priorities
+h4(#advsim_transition-priorities). Transition priorities
 
 It is important to understand that there is not queue of events. That is, in case several events occur simultaneously, the state machine consults the active state's transitions priorities in the order that is specified in the corresponding property, see "figure "Transition priorities"":#advsim_fig-transition-priorities. You can change the transitions priorities by selecting a transition and moving it up or down by clicking at the respective button.
 
@@ -172,7 +172,7 @@ The snapshot feature allows to store and restore the state of a simulation run.
 
 This feature is especially useful when testing complex state machines in which a number of steps need to be taken before reaching a desired situation. Using snapshots, you can store this desired situation once and simply restore it again without repeating all the steps to reach it. Depending on the complexity of the usecase, this can be a huge time-saver.
 
-h3. Creating a snapshot
+h3(#advsim_creating-a-snapshot). Creating a snapshot
 
 To create a snapshot of the current statechart simulation, proceed as follows:
 
@@ -186,7 +186,7 @@ p(#advsim_fig-a-freshly-taken-snapshot).
 p=. A freshly taken snapshot
 
 
-h3. The snapshots view
+h3(#advsim_the-snapshots-view). The snapshots view
 
 The _snapshots_ view consists of two parts.
 * The _snapshot list_ contains all snapshots with their respective names and timestamps.
@@ -199,7 +199,7 @@ p(#advsim_fig-inspecting-the-variables-of-a-snapshots).
 
 p=. Inspecting snapshot details, on the left variables and the right its active elements
 
-h3. Restoring a snapshot
+h3(#advsim_restoring-a-snapshot). Restoring a snapshot
 
 To restore a snapshot for execution, proceed as follows:
 # Select the snapshot to be restored.
@@ -208,13 +208,13 @@ To restore a snapshot for execution, proceed as follows:
 
 bq. Please note: When the semantics of the underlying state machine have been changed, it might not be possible to restore a snapshot, e.g. when the active state has been deleted.
 
-h3. Naming a snapshot
+h3(#advsim_naming-a-snapshot). Naming a snapshot
 
 The label of a snapshot can be changed as follows:
 # Click at its label. The label becomes an editable field.
 # Enter the new snapshot name and press @[Return]@ or click anywhere outside the editable field.
 
-h3. Deleting a snapshot
+h3(#advsim_deleting-a-snapshot). Deleting a snapshot
 
 * To delete one or more snapshots, select the snapshots to be deleted, then click at the _remove_ button !(inlinemediaobject)images/advsim_button_remove_red.png(remove)!.
 * To delete _all_ snapshots, click at the _remove all_ button !(inlinemediaobject)images/advsim_button_remove_all.png(remove all)!.

plugins/org.yakindu.sct.doc.user/src/user-guide/c-domain.textile

@@ -25,7 +25,7 @@ This preliminary version of *YAKINDU Statechart Tools Professional Edition* does
 p. The subsequent sections will explain how to use the C integration in practice, using a sample project. In this example, we will define some geometry types like _Point_ or _Triangle_ in C header files and demonstrate how to make them available and use them in a statechart model.
 
 
-h2(#cdom_creating_a_new_c_project). Creating a new C project
+h2(#cdom_creating-a-new-c-project). Creating a new C project
 
 # In the Eclipse main menu, select _File → New → Project…_. The _New Project_ wizard opens.
 # Select _C/C++ → C Project_.<br/>!(standard-image)images/cdom_geometry_010_new_c_project_010.png(Creating a new C project)!
@@ -40,7 +40,7 @@ h2(#cdom_creating_a_new_c_project). Creating a new C project
 # Eclipse asks whether it should associate this kind of project with the C/C++ perspective. Usually this is what you want, so set a checkmark at _Remember my decision_ and click _Yes_.
 # Eclipse creates the C project, here *Geometry*.
 
-h2(#cdom_creating_a_c_header_file). Creating a C header file
+h2(#cdom_creating-a-c-header-file). Creating a C header file
 
 Now we can create a C header file specifying our own C type definitions which we can use in a state machine later. In order to create the file, let's proceed as follows:
 
@@ -50,7 +50,7 @@ Now we can create a C header file specifying our own C type definitions which we
 # Click _Finish_. 
 # The header file *point.h* is created.<br/>
 
-h2(#cdom_defining_a_c_struct). Defining a C struct
+h2(#cdom_defining-a-c-struct). Defining a C struct
 
 In the created header file we define a struct type named *Point*, which we will later use in a statechart. A (two-dimensional) point consists of an _x_ and a _y_ coordinate. We choose *int16_t* to represent a coordinate, i.&#8239;e. a 16-bit signed integer. The complete header file containing the struct definition looks like this:
 
@@ -76,9 +76,9 @@ bq.. *Please note:*
 
 In C it is possible to define structs, unions and enums without a _typedef_. They can be referenced by using the corresponding qualifying keyword (_struct_, _union_, or _enum_, respectively). As the statechart language does *not* support these qualifiers, the usage of struct, union and enumeration types is currently restricted to those defined by a _typedef_.
 
-h2(#cdom_using_a_c_struct_in_a_statechart). Using C types in a statechart
+h2(#cdom_using-a-c-struct-in-a-statechart). Using C types in a statechart
 
-h3(#cdom_creating_a_statechart_model). Creating a statechart model
+h3(#cdom_creating-a-statechart-model). Creating a statechart model
 
 Let's create a statechart model now to make use of the C type _Point_ we have just defined.
 
@@ -88,7 +88,7 @@ Let's create a statechart model now to make use of the C type _Point_ we have ju
 # Click _Finish_. If Eclipse asks you whether to switch to the _YAKINDU Modeling_ perspective, please confirm.
 # The new statechart model is created:<br/>!(standard-image)images/cdom_geometry_030_new_statechart_model_030.png(New statechart model)!
 
-h3(#cdom_defining_a_c_type_variable). Defining a C-type variable in a statechart
+h3(#cdom_defining-a-c-type-variable-in-a-statechart). Defining a C-type variable in a statechart
 
 Variables are defined in the definition section on the left-hand side of the statechart editor. Double-click into the section to edit it.
 
@@ -113,7 +113,7 @@ Selecting the _Point_ menu entry completes the variable definition:
 
 p=. A Point variable
 
-h3(#cdom_using_a_c_type_variable_in_a_statechart). Using a C-type variable in a statechart
+h3(#cdom_using-a-c-type-variable-in-a-statechart). Using a C-type variable in a statechart
 
 A statechart variable with a C type can be used everywhere a "normal" statechart variable can be used.
 
@@ -135,7 +135,7 @@ Variables of primitive types like @var count: int8_t@ are accessed as expected,
 The dot notation is used to access structure elements. For example, @pointA.x = 0; pointA.y = 0@ sets *pointA* to the origin of the coordinate system.
 
 
-h3(#cdom_the_statechart_type_system). The statechart type system
+h3(#cdom_the-statechart-type-system). The statechart type system
 
 When parsing a C header file YAKINDU Statechart Tools are mapping the C data types to an internal type system. You can open a C header file in Eclipse with the _Sample Reflective Ecore Model Editor_ to see how the mapping result looks like.
 
@@ -145,7 +145,7 @@ In case you are interested in the EMF model underlying SCT's type system, you ca
 
 h2(#cdom_namespaces). Namespaces
 
-h3(#cdom_importing_a_namespace). Importing a namespace
+h3(#cdom_importing-a-namespace). Importing a namespace
 
 Instead of using the fully-qualified type name – as in _point.Point_ – it is also possible to import the definitions provided by a C header file as a namespace.
 
@@ -169,7 +169,7 @@ p. Please note that adding the @import@ statement does not change the variable d
 bc. var pointA: Point
 
 
-h3(#cdom_differentiating_between_namespaces). Differentiating between namespaces
+h3(#cdom_differentiating-between-namespaces). Differentiating between namespaces
 
 Let's consider a scenario with several different _Point_ definitions now. There are two header files, each defining a _Point_ type, but with different properties.
 
@@ -198,7 +198,7 @@ bc. interface:
 
 The example above shows that pathnames of header files are mapped to namespace names. The example also shows that characters that are valid in a filesystem pathname (here: '-') are mapped to replacement characters that are allowed to occur in statechart type names (here: '_'). If you are unsure how to map a pathname to a type name, you can always use the content assist to do the mapping for you.
 
-Although it is possible to *import* both namespaces as described in section "&quot;Importing a namespace&quot;":#cdom_importing_a_namespace, it is not advisable. Consider the following example:
+Although it is possible to *import* both namespaces as described in section "&quot;Importing a namespace&quot;":#cdom_importing-a-namespace, it is not advisable. Consider the following example:
 
 bc.. import: point
 import: three_d.point
@@ -224,7 +224,7 @@ interface:
     var pointA: Point
     var pointB: three_d.point.Point
 
-h2(#cdom_data_structure_traversal_via_dot_notation). Data structure traversal via dot notation
+h2(#cdom_data-structure-traversal-via-dot-notation). Data structure traversal via dot notation
 
 The dot notation to access structure members can traverse an arbitrary number of stages. As an example, let's define a datatype named _Triangle_. A triangle is defined by three points. Using dot notation in a statechart, you can navigate from a triangle to its individual points and further on to the points' coordinates.
 
@@ -298,7 +298,7 @@ The statechart simulation
 * transitions to the *A is larger* state, because its guard condition is fulfilled, and
 * stops, waiting for the _compare_size_ event to occur.
 
-h3(#cdom_inspecting_inspecting_c_data_structures). Inspecting C data structures
+h3(#cdom_inspecting-c-data-structures). Inspecting C data structures
 
 !(standard-image)images/cdom_geometry_080_simulation_020_inspecting.png(Inspecting C data structures)!
 
@@ -315,7 +315,7 @@ Simple C variables and fields in C data structure are *not* initialized. Never t
 
 Even if the _Point_ data structures in the example above look like having been initialized to defined values, they are not. Without going into details, in C, variables are generally *not* initialized. This also holds for statechart variables from the C integration. If you are reading a variable, make sure you have written to it before. Otherwise you might get surprising and non-deterministic results.
 
-h3(#cdom_inspecting_modifying_c_data_structures). Modifying C data structures
+h3(#cdom_modifying-c-data-structures). Modifying C data structures
 
 Change a variable's or field's value as follows:
 # Click on the _value_ displayed in the simulation view.
@@ -336,7 +336,7 @@ In the example, click _compare_size_ to trigger the event. The state machine tra
 p=. Rectangle areas modified and rechecked
 
 
-h2(#cdom_looking_up_a_type_definition). Looking up a type definition
+h2(#cdom_looking-up-a-type-definition). Looking up a type definition
 
 Given a variable definition in a statechart's definition section, you can lookup the corresponding type definition. The definition section must be in editing mode, i.&#8239;e. you must have double-clicked into it. Now press the @[Ctrl]@ key and move the mouse pointer over the type name. The former changes its shape into a hand symbol and the latter changes into a hyperlink:
 
@@ -438,7 +438,7 @@ bq.. *Please note:*
 State machines calling C functions as operations are debarred from simulation and debugging. The simulator is not yet capable to call C functions.
 
 
-h2(#cdom_defines). Macro Definitions
+h2(#cdom_macro-definitions). Macro Definitions
 
 Macro definitions declared in a C header file via the @#define@ keyword are also accessible in the statechart. There are two kinds of macro definitions leading to different interpretations in the context of state machines:
 
@@ -447,11 +447,11 @@ Macro definitions declared in a C header file via the @#define@ keyword are also
 * Parameterized macros, like @#define MIN(x,y) ((x<y) ? x : y)@, are translated into operations. They can be used within a statechart just like normal operations, but are not interpreted during a simulation.
 
 
-h2(#cdom_generating_c_source_code). Generating C source code
+h2(#cdom_generating-c-source-code). Generating C source code
 
 Code generation, i.&#8239;e. turning a statechart model into source code of a programming language, is explained in the section _Generating state machine code_. Therefore we won't go into the details here, but instead only put some emphasis on code generation specialties of the _Deep C Integration_.
 
-h3(#cdom_creating_a_generator_model). Creating a generator model
+h3(#cdom_creating-a-generator-model). Creating a generator model
 
 In the statechart model introduced above, do the following:
 
@@ -477,7 +477,7 @@ bc.. GeneratorModel for yakindu::c {
 
 p. YAKINDU Statechart Tools creates the target folders _src_ and _src-gen_ and generates the C source representing the statemachine into them.
 
-h3(#cdom_the_generated_c_code). The generated C code
+h3(#cdom_the-generated-c-code). The generated C code
 
 Particularly interesting are the files *Statechart.h* and *Statechart.c*.
 
@@ -520,7 +520,7 @@ static void statechart_enact_main_region_Check(Statechart* handle)
 }
 
 
-h2(#cdom_currently_supported_primitive_types). Currently supported primitive types
+h2(#cdom_currently-supported-primitive-types). Currently supported primitive types
 
 The _Deep C Integration_ natively supports the following primitive C types. That is, in a statechart without any additional data type definitions, the following types are readily available:
 
@@ -539,15 +539,15 @@ The _Deep C Integration_ natively supports the following primitive C types. That
 * _void_
 
 
-h2(#cdom_current_restrictions). Current restrictions
+h2(#cdom_current-restrictions). Current restrictions
 
 The current beta version of the YAKINDU Statechart Tools is still missing some essential C functionalities that will be approached as soon as possible by subsequent releases. Among others, the following issues are known to be not available yet:
 
-h3(#cdom_current_restrictions_arrays_pointers). Arrays and pointers
+h3(#cdom_arrays-and-pointers). Arrays and pointers
 
 Currently YAKINDU Statechart Tools cannot handle arrays and pointers. This also means that all structs containing arrays or pointer types as members, or operations using these types as parameters can not be accessed. Usage of these types will produce error markers in the statechart, stating "The used type is not supported".
 
-h3(#cdom_current_restrictions_ranges). Type range checks
+h3(#cdom_current-type-range-checks). Type range checks
 
 Type range validations are currently not implemented. As a consequence, it is possible to e.&#8239;g. assign an _int32_t_ value to an _int8_t_ variable one without any warning.
 
@@ -555,7 +555,7 @@ h3(#cdom_plain-struct-union-and-enum-types). Plain struct, union, and enum types
 
 In C it is possible to define structs, unions and enums without a _typedef_. They can be referenced by using the corresponding qualifying keyword (_struct_, _union_, or _enum_, respectively). As the statechart language does *not* support these qualifiers, the usage of struct, union and enumeration types is currently restricted to those defined by a _typedef_.
 
-h3(#cdom_please_get_in_touch_with_us). Please get in touch with us
+h3(#cdom_please-get-in-touch-with-us). Please get in touch with us
 
 Please note that the preceding list of restrictions might not be complete. If you discover any further problems, please do not hesitate to contact us! Your feedback is highly appreciated!
 

plugins/org.yakindu.sct.doc.user/src/user-guide/overview.textile

@@ -17,7 +17,7 @@ The following graph shows these features and their relation to each other:
 
 p=. Features of YAKINDU Statechart Tools
 
-h2(#oss_which-licensing-rules-do-apply). Which licensing rules do apply to YAKINDU Statechart Tools?
+h2(#which-licensing-rules-do-apply-to-yakindu-statechart-tools). Which licensing rules do apply to YAKINDU Statechart Tools?
 
 The source code of YAKINDU Statechart Tools is provided under the "Eclipse Public License":http://www.eclipse.org/legal/epl-v10.html.
 

plugins/org.yakindu.sct.doc.user/src/user-guide/simulating_statecharts.textile

@@ -13,7 +13,7 @@ h2(#starting-a-simulation). Starting a simulation
 
 You have several options to start a statechart simulation.
 
-h3(#oss_via-statechart-model-file-context-menu). Via statechart model file context menu
+h3(#using-the-statechart-model-file-context-menu). Using the statechart model file context menu
 
 The most direct way is to start the simulation based on the statechart model file.
 # In the _Project Explorer_ view, right-click on the statechart model file. The context menu opens.
@@ -21,11 +21,11 @@ The most direct way is to start the simulation based on the statechart model fil
 
 p(#oss_fig_run-as-statechart-simulation). 
 
-!(standard-image)images/tuto_light_switch_300_statechart_simulator_run_as_statechart_simulation.png(Selecting "Run As → Statechart Simulation" in the context menu)!
+!(standard-image)images/tuto_light_switch_300_statechart_simulator_run_as_statechart_simulation.png(Selecting "Run As → Statechart Simulation" in the context menu)!
 
 p=. Selecting "Run As → Statechart Simulation" in the context menu
 
-h3(#oss_repeat-the-last-simulation). Repeat the last simulation
+h3(#repeating-the-last-simulation). Repeating the last simulation
 
 In order to re-run the simulation you have most recently executed, simply
 * press @[Ctrl+F11]@ on the keyboard
@@ -34,9 +34,9 @@ or
 
 To be exact, this operation does not necessarily re-run the last _simulation_, but rather the last executed _launch_. So if, for example, you first run a statechart simulation followed by running a Java program, then upon press @[Ctrl+F11]@, that Java program is executed once again, not the statechart simulation.
 
-h3(#oss_repeat-a-former-simulation). Repeat an earlier simulation
+h3(#repeating-a-former-simulation). Repeating an earlier simulation
 
-Let's consider a scenario where you want to execute a simulation you have run before, but not as the most recently executed launch. So you cannot use the procedure described in section ""Repeat the last simulation"":#oss_repeat-the-last-simulation.
+Let's consider a scenario where you want to execute a simulation you have run before, but not as the most recently executed launch. So you cannot use the procedure described in section ""Repeating the last simulation"":#repeating-the-last-simulation.
 
 However, as long as you haven't launched too many other programs in between, chances are good to find your simulation in the _history_.
 
@@ -44,7 +44,7 @@ Try the following:
 # In the main menu, open the _Run_ menu and move your mouse pointer over the _Run History_ entry.
 # A submenu attached to the _Run History_ menu entry opens, containing the most recently executed launches. Check whether the simulation you want to execute is available in the submenu. If it is, select it to start the simulation.
 
-h3(#oss_creating-and-executing-a-run-configuration). Creating and executing a launch configuration
+h3(#creating-and-executing-a-run-configuration). Creating and executing a launch configuration
 
 When a statechart is simulated for the first time, a _launch configuration_ is automatically created. A _launch configuration_ describes the parameters used for a particular launch. In case of a statechart simulation, it describes which statechart is to be simulated and the simulation mode (event-driven or cycle-based). For details on how to create and modify a launch configuration, see section ""Configuring a simulation"":#configuring-a-simulation.
 
@@ -54,11 +54,11 @@ To execute an existing launch configuration, proceed as follows:
 # Click on _Run_ to execute the launch configuration.
 
 
-h2(#oss_the-sc-simulation-perspective). The SC Simulation perspective
+h2(#the-sc-simulation-perspective). The SC Simulation perspective
 
 The _SC Simulation_ perspective provides selected views that are most useful when running a statechart simulation.
 
-h3(#oss_engaging-the-sc-simulation-perspective). Engaging the SC Simulation perspective
+h3(#engaging-the-sc-simulation-perspective). Engaging the SC Simulation perspective
 
 When a simulation starts, the perspective usually changes to the _SC Simulation_ perspective. If this doesn't happen, you can manually engage the _SC Simulation_ perspective as follows:
 
@@ -69,17 +69,17 @@ Alternatively, you can do the following:
 * In the _Open Perspective_ dialog, select _SC Simulation_.
 * Click on _Okay_. The _SC Simulation_ perspective opens.
 
-h3(#oss_views-contained-in-the-sc-simulation-perspective). Views contained in the SC Simulation perspective
+h3(#views-contained-in-the-sc-simulation-perspective). Views contained in the SC Simulation perspective
 
 By default, the _SC Simulation_ perspective shows the following views:
 * _Project Explorer_ (left): This view displays your workspace and projects, folders, and files contained therein. You can also use the _Project Explorer_ to inspect the internal structure of your statechart models.
 * _Debug_ (top middle): This view is showing all statechart instances and allows to select one of them. YAKINDU Statechart Tools allow multiple executions of the same statechart as well as parallel executions of different statecharts at the same time.
 * _Outline_ (right): This view is a bird's eye view on the opened statechart. It also indicates the current viewport for better orientation in large models.
-* _Simulation_ (right): This view shows the current state of all variables and events during a simulation. A detailed description is available in section ""The Simulation view"":#oss_the-simulation-view.
+* _Simulation_ (right): This view shows the current state of all variables and events during a simulation. A detailed description is available in section ""The Simulation view"":#the-simulation-view.
 * %(pro-feature)_Breakpoints_ (right): This view shows a list of all breakpoints. You can use it for disabling, enabling, or removing breakpoints as well as for defining conditional breakpoints.%
 * %(pro-feature)_Snapshots_ (right): This view contains all snapshots with their respective names and timestamps.%
 
-h3(#oss_displaying-simulation-progress-in-the-statechart-editor). Displaying simulation progress in the statechart editor
+h3(#displaying-simulation-progress-in-the-statechart-editor). Displaying simulation progress in the statechart editor
 
 The _SC Simulation_ perspective also includes the statechart editor. In a running simulation, the statechart editor highlights active states by coloring their backgrounds in red.
 
@@ -92,9 +92,9 @@ p(#oss_fig_the-sc-simulation-perspective).
 p=. The _SC Simulation_ perspective
 
 
-h2(#oss_the-simulation-view). The Simulation view
+h2(#the-simulation-view). The Simulation view
 
-The _Simulation_ view is used to manually raise events and to inspect and modify variables of a running simulation. By default that view is located on the right-hand side of the "_SC Simulation_":#oss_the-sc-simulation-perspective perspective, see "figure "Simulation view"":#oss_fig-simulation-view for an example.
+The _Simulation_ view is used to manually raise events and to inspect and modify variables of a running simulation. By default that view is located on the right-hand side of the "_SC Simulation_":#the-sc-simulation-perspective perspective, see "figure "Simulation view"":#oss_fig-simulation-view for an example.
 
 The _Simulation_ view groups events and variables by their _interfaces_. The unnamed interface appears as _default_ in the interface list. Click on the small triangle left from a interface's name to show or hide the interface's contents, i. e. events and variables.
 
@@ -120,13 +120,13 @@ h2(#interacting-with-a-simulation). Interacting with a simulation
 
 You can interact with a running simulation by manually raising events and by inspecting and modifying variables. You can do so at any point in time, but in most cases you will do so while the simulation "sits idle" at its active state and waits for an event to trigger a transition.
 
-h3(#oss_raising-an-event). Raising an event
+h3(#raising-an-event-in-the-simulation). Raising an event in the simulation
 
 To raise an event, proceed as follows:
 # In the _Simulation_ view, click on the small triangle to open the interface containing the event, if needed.
 # Click on the event to it for the next run-to-completion step.
 
-h3(#oss_inspecting-a-variable). Inspecting a variable
+h3(#inspecting-a-variable). Inspecting a variable
 
 To inspect a variable's value, proceed as follows:
 # In the _Simulation_ view, click on the small triangle to open the interface containing the variable, if needed.
@@ -134,7 +134,7 @@ To inspect a variable's value, proceed as follows:
 
 Watch the displayed value change as the simulation progresses and actions in states or transitions are executed that modify the variable's contents.
 
-h3(#oss_Modifying-a-variable). Modifying a variable
+h3(#modifying-a-variable). Modifying a variable
 
 To manually modify a variable's value, proceed as follows:
 # In the _Simulation_ view, click on the small triangle to open the interface containing the variable, if needed.
@@ -144,7 +144,7 @@ To manually modify a variable's value, proceed as follows:
 
 h2(#configuring-a-simulation). Configuring a simulation
 
-Section ""Creating and executing a launch configuration"":#oss_creating-and-executing-a-run-configuration describes how to start an existing launch configuration.
+Section ""Creating and executing a launch configuration"":#creating-and-executing-a-run-configuration describes how to start an existing launch configuration.
 
 The present chapter describes how to create and configure a new launch configuration for a statechart simulation.
 

plugins/org.yakindu.sct.generator.builder/src/org/yakindu/sct/generator/builder/efs/SCTEclipseResourceFileSystemAccess.java

@@ -10,10 +10,15 @@
 */
 package org.yakindu.sct.generator.builder.efs;
 
+import java.io.File;
+
+import org.eclipse.core.resources.IFile;
 import org.eclipse.core.resources.IProject;
 import org.eclipse.core.resources.IWorkspace;
 import org.eclipse.core.runtime.NullProgressMonitor;
+import org.eclipse.emf.common.util.URI;
 import org.eclipse.xtext.builder.EclipseResourceFileSystemAccess2;
+import org.eclipse.xtext.generator.OutputConfiguration;
 import org.yakindu.sct.generator.core.filesystem.ISCTFileSystemAccess;
 
 import com.google.inject.Inject;
@@ -38,5 +43,23 @@ public class SCTEclipseResourceFileSystemAccess extends EclipseResourceFileSyste
 		IProject project = ws.getRoot().getProject(projectName);
 		super.setProject(project);
 	}
+	
+	@Override
+	public URI getURI(String path, String outputConfiguration) {
+		OutputConfiguration outputConfig = getOutputConfig(outputConfiguration);
+		String outputDir = outputConfig.getOutputDirectory();
+		if (isRootPath(outputDir) && isRootPath(path)) {
+			return URI.createFileURI(getProject().getLocationURI().getPath());
+		}
+		IFile file = getProject().getFile(outputDir + File.separator + path);
+		if (file != null) {
+			return URI.createFileURI(file.getLocationURI().getPath());
+		}
+		return super.getURI(path);
+	}
+	
+	protected boolean isRootPath(String path) {
+		return (".".equals(path) || "/".equals(path) || "./".equals(path) || "".equals(path));
+	}
 
 }