!(standard-image small)images/5min_010_close_welcome.png(Closing the "Welcome" page)!
+# If the "Welcome" page is still open, close it.!(standard-image small)images/tuto_5min_010_close_welcome.png(Closing the "Welcome" page)!
# In the main menu, select _File → New → Example…_. # In the dialog, select _YAKINDU SCT Examples → Light Switch Example_, then click _Next >_. # In the next dialog, click _Finish_. The sample project named _light_switch_ is created. -# In the project explorer on the left-hand side of the window, open the _light_switch_ project by clicking on the small triangle left from the project name ("light_switch").!(standard-image small)images/5min_020_expand_project.png(Expand project)!
+# In the project explorer on the left-hand side of the window, open the _light_switch_ project by clicking on the small triangle left from the project name ("light_switch").!(standard-image small)images/tuto_5min_020_expand_project.png(Expand project)!
# The light switch statechart is defined in _LightSwitch.sct_. Double click on this file to open the model. h2(#oss_running-the-light-switch-simulation). Simulating the light switch # Right-click on _LightSwitch.sct_ and select _Run As → Statechart Simulation_ in the context menu. -# The statechart simulation starts and shows the light switch model in its _off_ state. The rectangle named *Off* is highlighted in red, meaning it is the active state.!(standard-image)images/light_switch_320_statechart_simulator_state_events.png(Light switch simulation in "off" state)!
+# The statechart simulation starts and shows the light switch model in its _off_ state. The rectangle named *Off* is highlighted in red, meaning it is the active state.!(standard-image)images/tuto_light_switch_320_statechart_simulator_state_events.png(Light switch simulation in "off" state)!
# At the right-bottom side of the window, the simulation view is located. In this view, you can change variable values and raise events during a simulation run. Click on the small triangle left from _internal_ to unfold the _operate_ link. This link represents the _operate_ event to switch the light on or off. -# Click on the _operate_ link. The active state changes accordingly from *Off* to *On*.!(standard-image)images/light_switch_330_statechart_simulator_state_on.png(Light switch simulation in "on" state)!
+# Click on the _operate_ link. The active state changes accordingly from *Off* to *On*.!(standard-image)images/tuto_light_switch_330_statechart_simulator_state_on.png(Light switch simulation in "on" state)!
# Click on _operate_ again to switch off the light. h2(standard #oss_generating-statechart-code). Generating statechart code @@ -35,10 +35,10 @@ You have developed and tested your statechart model, and now you need it as a C, As an example, we will take the light switch statechart and generate Java source code from it. Please proceed as follows: -# In the project explorer, right-click on _LightSwitch.sct_ and select _New → Code Generator Model_ in the context menu.!(standard-image)images/5min_110_new_code_generator_model.png(Creating a new code generator model)!
+# In the project explorer, right-click on _LightSwitch.sct_ and select _New → Code Generator Model_ in the context menu.!(standard-image)images/tuto_5min_110_new_code_generator_model.png(Creating a new code generator model)!
# In the dialog, replace @default.sgen@ by @light_switch.sgen@, then click _Next >_. # In the next dialog, check the checkbox left from _LightSwitch.sct_, then click _Finish_. -# Java classes implementing the statechart model are generated. You can find the generated source code in the folders _src_ and _src-gen_ within the _light_switch_ project.!(standard-image)images/5min_140_generated_java_source_code.png(Generated Java source code)!
+# Java classes implementing the statechart model are generated. You can find the generated source code in the folders _src_ and _src-gen_ within the _light_switch_ project.!(standard-image)images/tuto_5min_140_generated_java_source_code.png(Generated Java source code)!
That's it. If you want to know more, take the time and work through the "Comprehensive Tutorial":#oss_comprehensive-tutorial. @@ -54,9 +54,9 @@ This tutorial you will teach how to Please note that this tutorial will not explain statecharts in general, so you should familiarize yourself with the basic concepts of state machines first, see "UML state machine":http://en.wikipedia.org/wiki/UML_state_machine. -In order to get a fully-working statechart implementation that you can integrate with your project, you will have to familiarize yourself with _code generation_, which is covered by chapter "Code generation":#code-generation in this documentation. You can generate your state machine implementation as source code in C, C++, and Java out of the box. Alternatively, you can write your own code generator for other programming languages or for other purposes. +In order to get a fully-working statechart implementation that you can integrate with your project, you will have to familiarize yourself with _code generation_, which is covered by chapter "Code generation":#code-generation in this documentation. You can generate your state machine implementation as source code in C, C++, and Java out of the box. Alternatively, you can write your own code generator for other programming languages or for other purposes. -Before we get started, make sure you have YAKINDU Statechart Tools installed. For installation instructions, see the "YAKINDU Statechart Tools Installation Guide":00_installation#installation-guide. +Before we get started, make sure you have YAKINDU Statechart Tools installed. For installation instructions, see the "YAKINDU Statechart Tools Installation Guide":../installation/installation.html. h2(#the-light-switch-example). The light switch example @@ -82,13 +82,13 @@ h3(#creating-an-eclipse-project). Creating an Eclipse project The first step is to create a new Eclipse project that can serve as a container for our model. From the main menu, select _File → New → Project..._: -!(standard-image)images/light_switch_010_menu_file_new_project.png(Selecting "File → New → Project..." in the main menu)! +!(standard-image)images/tuto_light_switch_010_menu_file_new_project.png(Selecting "File → New → Project..." in the main menu)! p=. Selecting "File → New → Project..." in the main menu The _New Project_ wizard opens, showing a couple of different project types structured in various folders. -!(standard-image)images/light_switch_020_wizard_new_project_general_project.png(The "New Project" wizard)! +!(standard-image)images/tuto_light_switch_020_wizard_new_project_general_project.png(The "New Project" wizard)! p=. The "New Project" wizard @@ -96,7 +96,7 @@ Select _General → Project_ and click _Next >_. The wizard shows its next page: -!(standard-image)images/light_switch_040_wizard_new_project.png(Specifying project name and location)! +!(standard-image)images/tuto_light_switch_040_wizard_new_project.png(Specifying project name and location)! p=. Specifying project name and location @@ -106,7 +106,7 @@ Click _Finish_. Eclipse creates the new project: -!(standard-image)images/light_switch_060_project_created.png(Project "LightSwitch" created)! +!(standard-image)images/tuto_light_switch_060_project_created.png(Project "LightSwitch" created)! p=. Project "LightSwitch" created @@ -116,13 +116,13 @@ Now that we have created the Eclipse project, we can establish the statechart mo Right-click on the project's root, i. e. on *LightSwitch*, then select _New → Folder_ from the context menu. -!(standard-image)images/light_switch_100_menu_new_folder.png(Selecting "New → Folder" in the context menu)! +!(standard-image)images/tuto_light_switch_100_menu_new_folder.png(Selecting "New → Folder" in the context menu)! p=. Selecting "New → Folder" in the context menu The _New Folder_ wizard opens: -!(standard-image)images/light_switch_110_wizard_new_folder.png(The "New Folder" wizard)! +!(standard-image)images/tuto_light_switch_110_wizard_new_folder.png(The "New Folder" wizard)! p=. The "New Folder" wizard @@ -136,19 +136,19 @@ h4(#using-the-yakindu-statechart-wizard). Using the YAKINDU Statechart wizard Now we are going to create an empty statechart model in the _model_ folder. Right-click on the _model_ folder and select _New → Other_ in the context menu: -!(standard-image)images/light_switch_120_menu_new_other.png(Selecting "New → Other" in the context menu)! +!(standard-image)images/tuto_light_switch_120_menu_new_other.png(Selecting "New → Other" in the context menu)! p=. Selecting "New → Other" in the context menu The _New_ wizard opens. Select _YAKINDU SCT → Statechart model_ -!(standard-image)images/light_switch_130_wizard_new.png(Selecting "YAKINDU SCT → Statechart model")! +!(standard-image)images/tuto_light_switch_130_wizard_new.png(Selecting "YAKINDU SCT → Statechart model")! p=. Selecting "YAKINDU SCT → Statechart model" Click _Next >_. The wizard shows the _New YAKINDU Statechart_ dialog: -!(standard-image)images/light_switch_140_wizard_new_yakindu_statechart.png(The "New YAKINDU Statechart" dialog)! +!(standard-image)images/tuto_light_switch_140_wizard_new_yakindu_statechart.png(The "New YAKINDU Statechart" dialog)! p=. The "New YAKINDU Statechart" dialog @@ -160,7 +160,7 @@ Click _Finish_. Since there's a dedicated perspective for statechart models, Eclipse asks you whether you want to change to it now or not: -!(standard-image)images/light_switch_150_dialog_confirm_perspective_switch.png(Dialog "Confirm Perspective Switch")! +!(standard-image)images/tuto_light_switch_150_dialog_confirm_perspective_switch.png(Dialog "Confirm Perspective Switch")! p=. Dialog "Confirm Perspective Switch" @@ -173,7 +173,7 @@ h4(#the-initial-model). The initial model An empty statechart is created and displayed in the *statechart editor* in the middle of the Eclipse workbench. In the screenshot below the statechart editor is marked by a red rectangle. Subsequently, we will use the statechart editor to graphically develop the light switch statechart. p(#light_switch_220_statechart_editor). -!(standard-image)images/light_switch_220_statechart_editor.png(The statechart editor)! +!(standard-image)images/tuto_light_switch_220_statechart_editor.png(The statechart editor)! p=. The statechart editor @@ -199,7 +199,7 @@ This error marker exemplifies YAKINDU Statechart Tools' model validation capabil Hovering with the mouse over the error marker in the statechart editor reveals what the problem is. A small popup appears and displays the error description: "A state must have a name." -!(standard-image)images/light_switch_210_error_marker_and_popup.png(An error marker and a popup window explaining it)! +!(standard-image)images/tuto_light_switch_210_error_marker_and_popup.png(An error marker and a popup window explaining it)! p=. An error marker and a popup window explaining it @@ -221,41 +221,41 @@ As we have seen, the initial statechart is erroneous insofar as the state does n Remember the requirements of our light switch example? The first requirement demands the switch to be off initially. The erroneous state is reached from the initial state immediately, so it is appropriate to name it *Off*. table(scedit). -|<. Double-click on the string @!(standard-image)images/callhandling_300_java_integration_create_new_class.png! +# Name it _CallHandlingClient_.
!(standard-image)images/tuto_callhandling_300_java_integration_create_new_class.png! # Click _Finish_. Next, copy the following code into the created class: diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/advanced_simulation.textile b/plugins/org.yakindu.sct.doc.user/src/user-guide/advanced_simulation.textile new file mode 100644 index 0000000000..313a79ca9e --- /dev/null +++ b/plugins/org.yakindu.sct.doc.user/src/user-guide/advanced_simulation.textile @@ -0,0 +1,221 @@ + +p. + +==
==
+
+h1(#advsim_simulation). Debugging with breakpoints and snapshots
+
+h2(#advsim_introduction). Introduction
+
+This advanced feature makes it possible to attach *breakpoints* to states and transitions. If a statechart simulation reaches a transition or a state with a breakpoint, it suspends execution of the simulation. A breakpoint can be amended with a _condition_ in order to suspend the simulation only if the condition is fulfilled (true).
+
+You can also create *snapshots* of your statechart simulation. A snapshot contains everything making up your state machine simulation at any point in time. It describes the state of the state machine, if you will. Snapshots can be saved and restored later in order to continue the simulation from that point on that is specified by the snapshot.
+
+h3(#advsim_the-light-switch-example). The light switch example
+
+Throughout this chapter we will be using the _light switch_ statechart as an example. It models a lamp which can be turned on and off and also supports various brightness values.
+
+If you press the _pressLightOn_ button, the lamp turns on at its lowest brightness value. If you operate _pressLightOn_ repeatedly, each time the lamp becomes brighter until it reaches its maximum brightness. Pressing the _pressLightOff_ button, immediately turns off the light completely. The brightness can only be raised as long as it hasn't yet reached its maximum value of five. After that, the guard condition disallows to raise it any further.
+
+p(#advsim_fig-the-light-switch-sample-statechart).
+!(standard-image)images/advsim_010_lightswitch_010_statechart.png(The light switch sample statechart)!
+
+p=. The light switch sample statechart
+
+h2(#advsim-breakpoints). Breakpoints
+
+Breakpoints allow for automatically suspending the simulation when a certain element of the state machine is activated. Optionally, a halting condition can be specified to better control the behavior of a breakpoint. Breakpoints can be set on transitions or states. When a breakpoint is reached, the simulation pauses and the current state of variable values can be examined in the simulation view. It is possible to change values and to trigger events that will be raised when the simulation run is manually resumed.
+
+h2(#advsim_executing-in-debugging-mode). Executing in debugging mode
+
+To make use of breakpoints, the statechart simulation needs to be executed in debugging mode:
+
+# Right-click on the statechart model. The context menu opens.
+# Select _Debug As→Statechart Simulation_, see "Figure "Starting a simulation in debugging mode"":#advsim_fig-starting-a-simulation-in-debugging-mode.
+# The statechart simulation starts in the debugging mode.
+
+p(#advsim_fig-starting-a-simulation-in-debugging-mode).
+!(standard-image)images/advsim_020_start_debugging_010_debug_as_menu.png(Starting a simulation in debugging mode)!
+
+p=. Starting a simulation in debugging mode
+
+h3(#advsim_setting-a-breakpoint). Setting a breakpoint
+
+# Right-click on a state or transition. The context menu opens.
+# Select _Toggle Breakpoint_ from the context menu, see "Figure "Setting a breakpoint"":#advsim_fig-setting-a-breakpoint.
+
+p(#advsim_fig-setting-a-breakpoint).
+!(standard-image)images/advsim_030_breakpoint_010_setting_on_transition.png(Setting a breakpoint)!
+
+p=. Setting a breakpoint
+
+States and transitions having a breakpoint attached are labeled with a !(inlinemediaobject)images/advsim_symbol_breakpoint_enabled.png! symbol. "Figure "Breakpoints on transition and state"":#advsim_fig-breakpoints-on-transition-and-state shows an example.
+
+p(#advsim_fig-breakpoints-on-transition-and-state).
+!(standard-image)images/advsim_030_breakpoint_020_transition_and_state_with_breakpoints.png(Breakpoints on transition and state)!
+
+p=. Breakpoints on transition and state
+
+h3(#advsim_hitting-a-breakpoint). Hitting a breakpoint
+
+If the simulation runs into a state with a breakpoint, the state's entry actions, if any, are executed. After that, execution of the state machine is suspended. The state is highlighted by a small green border.
+
+!(standard-image)images/advsim_030_breakpoint_030_suspending_at_state.png(Highlighting a suspended state)!
+
+p=. Highlighting a suspended state
+
+If the simulation runs into a transition with a breakpoint, execution of the state machine is suspended. The transition is highlighted by drawing the transition arrow in green. The transition's actions, if any, are executed when the state machine is resumed.
+
+!(standard-image)images/advsim_030_breakpoint_040_suspending_at_transition.png(Highlighting a suspended transition)!
+
+p=. Highlighting a suspended transition
+
+
+h3(#advsim_continuing-the-simulation). Continuing the simulation
+
+In order to continue from a breakpoint, you have two options:
+
+* To continue execution, click the resume button !(inlinemediaobject)images/advsim_symbol_resume.png! or select _Run → Resume_ in the main menu. The statechart simulation continues until the next breakpoint is hit or the simulation is terminated.
+* To execute the next run-cycle of the simulation only and then suspend again, click the step-over button !(inlinemediaobject)images/advsim_symbol_stepover.png! or select _Run → Step Over_ in the main menu.
+
+h3(#advsim_using-the-breakpoints-view). Using the breakpoints view
+
+The _breakpoints_ view shows a list of all breakpoints. The respective breakpoint name identifies the state or transition in question. See "figure "Breakpoints view"":#advsim_fig-breakpoints-view for an example.
+
+You can use the _breakpoints_ view for disabling, enabling, and removing breakpoints as well as defining "conditional breakpoints":#advsim_conditional-breakpoints.
+
+p(#advsim_fig-breakpoints-view).
+!(standard-image)images/advsim_030_breakpoint_050_enabled_and_disabled_breakpoints.png(Breakpoints view)!
+
+p=. Breakpoints view
+
+h3(#advsim_enabling-and-disabling-breakpoints). Enabling and disabling breakpoints
+
+A breakpoint is either enabled or disabled.
+
+* An enabled breakpoint causes the statechart simulation to suspend when reaching it. In the statechart and in the _breakpoints_ view, an enabled breakpoint is visualized by a filled light blue circle with a grey border: !(inlinemediaobject)images/advsim_symbol_breakpoint_enabled.png!.
+* A disabled breakpoint is ignored by the statechart simulation. In the statechart and in the _breakpoints_ view, a disabled breakpoint is visualized by a hollow circle with a grey border: !(inlinemediaobject)images/advsim_symbol_breakpoint_disabled.png!.
+
+"Figure "Breakpoints view"":#advsim_fig-breakpoints-view is showing an enabled and a disabled breakpoint in the statechart editor and in the breakpoints view, respectively.
+
+You can instruct the statechart simulation to skip all breakpoints by clicking at the !(inlinemediaobject)images/advsim_button_breakpoint_skip_disengaged.png! button in the breakpoints view. The button will appear "pressed", and while it is, the "skip breakpoints" functionality is engaged. That means, the simulation will not suspend at any breakpoint.
+
+This is different from disabling all breakpoints, in that each breakpoint keeps its state of being enabled or disabled. Once you disengage the skip breakpoints functionality by clicking at the !(inlinemediaobject)images/advsim_button_breakpoint_skip_engaged.png! button again, the simulation will suspend again at enabled breakpoints and will not suspend at disabled breakpoints.
+
+h3(#advsim_removing-breakpoints). Removing breakpoints
+
+In order to remove _some_ breakpoints, select these breakpoints in the breakpoints view, then click at the !(inlinemediaobject)images/advsim_button_remove.png(remove)! button. The selected breakpoints will be removed.
+
+To remove _all_ breakpoints, click at the !(inlinemediaobject)images/advsim_button_remove_all.png(remove all)! button
+
+h3(#advsim_conditional-breakpoints). Conditional breakpoints
+
+A _conditional_ breakpoint has an associated condition and suspends the simulation only if
+* that condition is fulfilled (true) and
+* the breakpoint is enabled.
+
+In order to attach a condition to a breakpoint, proceed as follows:
+* In the _breakpoints_ view, select the breakpoint in question.
+* Check the _Conditional_ checkbox, see "figure "Breakpoints view"":#advsim_fig-breakpoints-view in the lower right area. The associated text field becomes writable.
+
+Enter the condition into the text field. Like in the statechart editor, a content assist is available when pressing @[Ctrl+Space]@. The expression is validated automatically. In the example shown in "figure "Breakpoints view"":#advsim_fig-breakpoints-view the transition suspends the simulation only if the variable _brightness_ has a value of 4.
+
+h2(#advsim_debugging-a-statechart). Debugging a statechart
+
+h3. 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
+
+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.
+
+However, while the simulation is suspended, you can raise multiple events, without instant execution. Once execution resumes, both events are handled at the same time, or, to be more exact, in the same run-to-completion step (RTS).
+
+Consider for example, you want to press the "light on" and "light off" buttons at the same time and observe what happens. "Figure "Raising multiple events simultaneously"":#advsim_fig-raising-multiple-events-simultaneously-1 is showing the scenario:
+
+p(#advsim_fig-raising-multiple-events-simultaneously-1).
+!(standard-image)images/advsim_040_multiple_events_010_events_not_raised.png(Raising multiple events simultaneously 1)!
+
+p=. Raising multiple events simultaneously 1
+
+* The simulation has encountered a breakpoint at the _LightOn_ state and has been suspended there.
+* The _simulation_ view shows the _LightOn_ and the _LightOff_ events. Both events are labeled with a !(inlinemediaobject)images/advsim_symbol_event.png(event)! symbol, meaning the respective event is not raised.
+
+p(#advsim_fig-raising-multiple-events-simultaneously-2).
+!(standard-image)images/advsim_040_multiple_events_020_events_raised.png(Raising multiple events simultaneously 2)!
+
+p=. Raising multiple events simultaneously 2
+
+* Clicking at an event raises it and adds a blue triangle to the event symbol: !(inlinemediaobject)images/advsim_symbol_event_raised.png(event raised)!. Since the simulation remains suspended, the user can raise multiple events.
+
+Both events are raised and will be handled by the state machine during the next run-to-completion step. The latter will be performed as soon as the user clicks on the step-over button !(inlinemediaobject)images/advsim_symbol_stepover.png! or the resume button !(inlinemediaobject)images/advsim_symbol_resume.png!.
+
+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
+
+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.
+
+The first transition whose condition is fulfilled will be executed. All remaining events are quashed.
+
+p(#advsim_fig-transition-priorities).
+!(standard-image)images/advsim_040_multiple_events_030_transition-priorities.png(Transition priorities)!
+
+p=. Transition priorities
+
+h2(#advsim_snapshots). Snapshots
+
+The snapshot feature allows to store and restore the state of a simulation run. A snapshot comprises all *active states* of the state machine as well as all *variable values* at the time of snapshot creation.
+
+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
+
+To create a snapshot of the current statechart simulation, proceed as follows:
+
+# Change to _Snapshots_ view.
+# Click at the camera button !(inlinemediaobject)images/advsim_button_camera.png(camera)! in the view's toolbar.
+# The snapshot is taken and appears in the snapshot list. It is labeled as "Snapshot" and tagged with the current timestamp. See "figure "A freshly taken snapshot"":#advsim_fig-a-freshly-taken-snapshot.
+
+p(#advsim_fig-a-freshly-taken-snapshot).
+!(standard-image)images/advsim_050_snapshots_010_a-freshly-taken-snapshot.png(A freshly taken snapshot)!
+
+p=. A freshly taken snapshot
+
+
+h3. The snapshots view
+
+The _snapshots_ view consists of two parts.
+* The _snapshot list_ contains all snapshots with their respective names and timestamps.
+* The _snapshot details_ part displays the contents of the snapshot. It contains two different views which can be toggled via the toolbar buttons:
+** !(inlinemediaobject)images/advsim_button_snapshot_variable_overview.png(image overview)!: shows all variable values
+** !(inlinemediaobject)images/advsim_button_snapshot_image_overview.png(image overview)!: shows an image of the state machine with highlighted active elements
+
+p(#advsim_fig-inspecting-the-variables-of-a-snapshots).
+!(standard-image)images/advsim_050_snapshots_025_details_view.png(Inspecting the variables of a snapshots)!
+
+p=. Inspecting snapshot details, on the left variables and the right its active elements
+
+h3. Restoring a snapshot
+
+To restore a snapshot for execution, proceed as follows:
+# Select the snapshot to be restored.
+# Click at the _restore_ button !(inlinemediaobject)images/advsim_button_snapshot_restore.png(restore snapshot)!.
+# The snapshot is restored as an additional executing state machine instance.
+
+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
+
+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
+
+* 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)!.
+
+==
==
+
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/c-domain.textile b/plugins/org.yakindu.sct.doc.user/src/user-guide/c-domain.textile
new file mode 100644
index 0000000000..557e08e036
--- /dev/null
+++ b/plugins/org.yakindu.sct.doc.user/src/user-guide/c-domain.textile
@@ -0,0 +1,551 @@
+
+p.
+
+====
+
+h1(#cdom_deep-c-integration). Deep C Integration: Integrating your C source code with your statecharts
+
+h2(#cdom_introduction). Introduction
+
+The YAKINDU Statechart Tools Professional Edition comes with a _Deep C Integration_ feature which allows for using C types, variables, and operations directly within the statechart model. C header files located in your workspace are automatically recognized by the tool and all contained type and operation declarations are made accessible in the statechart editor with all its editing features like code completion and validation. In addition to your custom C types, the C99 standard primitive types, like _int16_t_, are also available out of the box.
+
+Making your self-defined C types, structs, and unions available in YAKINDU statechart saves you a lot of time and hassle that would otherwise be needed to map data from your C-type variables to statechart variables and vice versa. The _Deep C Integration_, however, allows you to _directly_ create and manipulate your data structures in their native C types.
+
+
+bq.. *Please note:*
+
+Instead of "types, structs, and unions", subsequently we will speak of "types" only. While this does not precisely confirm with the C programming language nomenclature, it is much easier to read in a text. From a statechart's point of view, there is no relevant difference between types, structs, and unions anyway. Should it become necessary to differentiate between types, structs, and unions, we will do so explicitly.
+
+bq.. *Please also note:*
+
+This preliminary version of *YAKINDU Statechart Tools Professional Edition* does not support pointers and arrays yet. These types will be supported in the full version.
+
+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
+
+# In the Eclipse main menu, select _File → New → Project…_. The _New Project_ wizard opens.
+# Select _C/C++ → C Project_.
!(standard-image)images/cdom_geometry_010_new_c_project_010.png(Creating a new C project)! +# Click _Next >_. The _C Project_ dialog appears. +# Enter the name of your project into the _Project name_ field. For the sake of this example, we call the project *Geometry*. +# Specify the location of the project folder by either using the default location or by explicitly specifying a directory in the _Location_ field. +# Select the _Project type_. In order to keep things plain and simple, for this example we create an _Empty Project_. +# Select the toolchain you want to work with. It contains the necessary tools for C development. By default only the toolchains supporting your local platform are displayed. Since this example has been created on a Linux machine, the toolchain *Linux GCC* is shown.
!(standard-image)images/cdom_geometry_010_new_c_project_020.png(Specifying the C project's properties)! +# Click _Next >_. +# Specify platforms, configurations, and project settings. This is more specific to C than to YAKINDU Statechart Tools, so we won't go into any details here.
!(standard-image)images/cdom_geometry_010_new_c_project_030.png(Specifying platforms, configurations, and project settings)! +# Click _Finish_. +# 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 + +Now we can create a C header file specifying our own C type definitions which we can use in a statechart later. In order to create the file, let's proceed as follows: + +# In the project explorer view, right-click on the project. The context menu opens. +# In the context menu, select _New → Header File_.
!(standard-image)images/cdom_geometry_020_new_header_file_010.png(Creating a C header file)! +# The dialog _New Header File_ is shown. Specify the name of the header file. Here we choose *point.h*.
!(standard-image)images/cdom_geometry_020_new_header_file_020.png(Select a header file name)! +# Click _Finish_. +# The header file *point.h* is created.
+ +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. e. a 16-bit signed integer. The complete header file containing the struct definition looks like this: + +bc.. +/* + * point.h + * + */ + +#ifndef POINT_H_ +#define POINT_H_ + +#include
+
+typedef struct {
+ int16_t x;
+ int16_t y;
+} Point;
+
+#endif /* POINT_H_ */
+
+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
+
+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.
+
+# Right-click on the project. The context menu opens.
+# Select _New → C Statechart Model …_. The _New YAKINDU Statechart_ wizard is shown.
+# In the dialog, specify the directory and the filename for the new statechart model file. The filename should end with @.sct@.
+# Click _Finish_. If Eclipse asks you whether to switch to the _YAKINDU Modeling_ perspective, please confirm.
+# The new statechart model is created:
!(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 + +Variables are defined in the definition section on the left-hand side of the statechart editor. Double-click into the section to edit it. + +Let's declare a variable *pointA* of the _Point_ type defined above. In the statechart's definition section, enter the following text: + +bc. +interface: + var pointA: + +On the right-hand side of the colon in the variable declaration, the variable's type must follow. In order to see which types are available, press @[Ctrl+Space]@. The content assist opens and shows the C types available in our C project, i. e. +* the C basic standard types, +* the C99 types provided by including _stdint.h_, +* the self-defined _Point_ type. + +!(standard-image)images/cdom_geometry_040_c_types_010.png(Using the content assist to display available types)! + +p=. Using the content assist to display available types + +Selecting the _Point_ menu entry completes the variable definition: + +!(standard-image)images/cdom_geometry_040_c_types_020.png(A Point variable)! + +p=. A Point variable + +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. + +Let's consider the above example extended by an additional *count* variable of the C99 _int8_t_ standard type. Additionally, we add an event that will be used as a trigger to switch between states. + +bc. interface: + var count: int8_t + var pointA: point.Point + in event tick + +The statechart below uses these variables in various places, i. e. in transition actions, in internal actions, and in guard conditions. + +!(standard-image)images/cdom_geometry_050_using_c_type_variables_010.png(Using C-type variables)! + +p=. Using C-type variables + +Variables of primitive types like @var count: int8_t@ are accessed as expected, e. g. @count = 0@ or @count += 1;@ + +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 + +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. + +In case you are interested in the EMF model underlying SCT's type system, you can find it in the source code of the YAKINDU Statechart Tools open edition at _/org.yakindu.base.types/model/types.ecore_. + + + +h2(#cdom_namespaces). Namespaces + +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. + +At the beginning of the definition section, enter @import:@ and hit @[Ctrl+Space]@. The content assist shows all namespaces you can import, besides other syntactical elements that would be valid here. In our example there's a single namespace _point_ that can be imported. The content assist explains that it comes from _/Geometry/point.h_, i. e. from the file _point.h_ in the _Geometry_ project. + +!(standard-image)images/cdom_geometry_060_importing_namespace_010.png(Selecting a namespace to import)! + +p=. Using C-type variables + +If we had more than a single header file in the project, we would see them all. The content assist shows all header files in a project, including those in subdirectories. + +Click on the namespace entry in the menu to complete the @import@ statement. The result looks like this: + +bc.. import: point + +interface: + var pointA: point.Point + +p. Please note that adding the @import@ statement does not change the variable declaration. However, you can now change the latter to: + +bc. var pointA: Point + + +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. + +The file *point.h* in the main project directory contains the following defintion: + +bc. typedef struct { + int16_t x; + int16_t y; +} Point; + +Additionally, there is a file *three-d/point.h* which also defines a @struct Point@, but with different properties. This _Point_ is three-dimensional and supports _double_ coordinates: + +bc. typedef struct { + double x; + double y; + double z; +} Point; + +On the C side we would run into problems if we tried to use both _Point_ definitions simultaneously. However, in a statechart this is possible, because each header file represents a different namespace. + +A statechart definition section using a two-dimensional *pointA* and a three-dimensional *pointB* would look like this: + +bc. interface: + var pointA: point.Point + var pointB: three_d.point.Point + +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 ""Importing a namespace"":#cdom_importing_a_namespace, it is not advisable. Consider the following example: + +bc.. import: point +import: three_d.point + +interface: + var pointA: Point + var pointB: Point + +p. This won't work, because _Point_ is ambiguous. To define *pointA* and *pointB* correctly, you would still have to fully-qualify the _Point_ types: + +bc.. import: point +import: three_d.point + +interface: + var pointA: point.Point + var pointB: three_d.point.Point + +p. However, in this case the imports would be pointless (pun intended). What you could do is to import only one of the namespaces. Then an unqualified _Point_ denotes the one in the imported namespace, while all other _Point_ types must be fully-qualified. Example: + +bc.. import: point + +interface: + var pointA: Point + var pointB: three_d.point.Point + +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. + +The C header file *triangle.h* specifies the _Triangle_ type: + +bc.. #ifndef TRIANGLE_H_ +#define TRIANGLE_H_ + +#include "./point.h" + +typedef struct { + Point a, b, c; +} Triangle; + +#endif /* TRIANGLE_H_ */ + +p. A _Triangle_ consists of the three _Points_ _a_, _b_, and _c_. Let's define a _Triangle_ _t_ in a statechart's definition section as follows: + +bc.. import: triangle + +interface: + var t: Triangle + +p. With this definition we can use expressions like @t.a.x@, see the image below. Regardless of where you are currently editing an expression, you can always use the code assist to explore which fields are available at that very point and of which types these fields are. Example: + +!(standard-image)images/cdom_geometry_170_data_structure_traversal_010.png(Content assist in data structure traversal)! + +p=. Content assist in data structure traversal + + +h2(#cdom_simulation). Simulation + +During a statechart model simulation full access to the C data structures is possible on all layers. The user can inspect them as well as modify them in the simulation view. + +The state machine below exemplifies this. Initially it defines two rectangles _a_ and _b_ with certain widths and heights. The state machine calculates the rectangles' respective area size, stores their sizes in two _int32_t_ variables named _area_a_ and _area_b_, and compares them. Depending on the result, it proceeds to state *A is larger* or to *A is smaller*. Only if both _a_ and _b_ have the same area – not necessarily the same width and height –, the state machine proceeds to its final state. + +When one of the states *A is larger* or *A is smaller* is active, the rectangles' properties can be changed. Triggering the _compare_size_ event transitions to the *Check* state which repeats the area size comparison as described above. + +!(standard-image)images/cdom_geometry_080_simulation_010_statechart.png(The rectangle comparison statechart)! + +p=. The rectangle comparison statechart + +The state machine's definitions are as follows: + +bc.. import: rectangle + +interface: + var a: Rectangle + var b: Rectangle + var area_a: int16_t + var area_b: int16_t + +internal: + event compare_size + +p. The _Rectangle_ datatype is defined in a new header file _rectangle.h_ with the following contents: + +bc.. #include "./point.h" + +typedef struct { + Point lowerLeft; + int16_t width, height; +} Rectangle; + +p. In order to simulate the statechart, right-click on the statechart file in the project explorer and select _Run As → Statechart Simulation_ from the context menu. + +The statechart simulation +* starts, +* performs the initializing actions specified in the transition from the initial state to the *Check* state, +* in the *Check* state, calculates the rectangles' areas and stores the results in the _area_a_ and _area_b_ variables, +* 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 + +!(standard-image)images/cdom_geometry_080_simulation_020_inspecting.png(Inspecting C data structures)! + +p=. Inspecting C data structures + +The simulation view in the screenshot above is showing the state machine's variables and their values. Click to open or close the nested data structures. The image below shows in particular +* the rectangles' respective width and height values as have been set initially, +* the calculated areas of the _a_ and _b_ rectangles, +* the coordinates of the points defining the respective lower left corner of the rectangles. + +bq.. *Warning:* + +Simple C variables and fields in C data structure are *not* initialized. Never try to read a variable or field you haven't written before, because it might contain arbitrary values. + +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 + +Change a variable's or field's value as follows: +# Click on the _value_ displayed in the simulation view. +# Enter the new value into the text field, see figure ""Modifying C data values"":#cdom_fig_modifying_c_data_values where _a.height_ is being edited and the previous value 7 is replaced by 3. +# Press the @[Enter]@ key to quit editing and to write the new value to the variable or field. Giving the input focus to another window has the same effect. +# You can cancel editing by pressing the @[Esc]@ key. The variable's or field's value remains unchanged. + +p(#cdom_fig_modifying_c_data_values). + +!(standard-image)images/cdom_geometry_080_simulation_030_modifying.png(Modifying C data values)! + +p=. Modifying C data values + +In the example, click _compare_size_ to trigger the event. The state machine transitions to the *Check* state, recalculates the areas, and behaves as explained above. + +!(standard-image)images/cdom_geometry_080_simulation_040_rechecked.png(Rectangle areas modified and rechecked)! + +p=. Rectangle areas modified and rechecked + + +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. 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: + +!(standard-image)images/cdom_geometry_160_type_lookup_010.png(Looking up a C type)! + +p=. Looking up a C type + +Click on the hyperlink to open the header file containing the respective type declaration. + +p=. Showing the C type definition + + +h2(#cdom_enums). Enums + +Besides specifying structure types, it is also possible to declare enumeration types in a C header. Here's the header file *color.h* which defines the _Color_ enumeration type: + +bc.. #ifndef COLOR_H_ +#define COLOR_H_ + +typedef enum { + RED, GREEN, BLUE, YELLOW, BLACK, WHITE +} Color; + +#endif /* COLOR_H_ */ + +p. Now let's extend the _Triangle_ defined above by a fill color: + +bc.. #ifndef TRIANGLE_H_ +#define TRIANGLE_H_ + +#include "./point.h" +#include "./color.h" + +typedef struct { + Point a, b, c; + Color fillColor; + +} Triangle; + +#endif /* TRIANGLE_H_ */ + + +p. Similar to the _Triangle_ type or any other C type, the _Color_ enumeration type can be used in the statechart, e. g. by declaring an additional interface variable: + +bc.. import: color +import: triangle + +interface: + var t: Triangle + var c: Color = Color.BLUE + +p. Please note that in contrast to structured types, enumeration variables can be initialized directly in their definitions. + +In order to see which values are available the content assist, triggered by @[Ctrl+Space]@, is helpful again. + +!(standard-image)images/cdom_geometry_083_enum_010_content_assist.png(Using content assist to select an enumeration value)! + +p=. Using content assist to select an enumeration value + +Once initialized, the _c_ variable can now be used e. g. in an assignment to the triangle _t_'s fill color: + +bc. t.fillColor = c; + +Accordingly, during simulation the values of enum variables are displayed in the simulation view. It is also possible to modify them manually. + +!(standard-image)images/cdom_geometry_083_enum_020_simulation.png(Using content assist to select an enumeration value)! + +p=. Using content assist to select an enumeration value + +h2(#cdom_operations). Operations + +Functions declared in a C header file become available in a statechart. The state machine can call it as an _operation_. + +Let's say our *rectangle.h* header file not only defines the data type, but also declares one or more C functions to operate on them. The following line declares a function named _area_, taking a _Rectangle_ parameter by value and returning an _int32_t_ result. + +bc. extern int32_t area(Rectangle r); + +For the sake of the example, let's assume the function calculates the area of the given rectangle. Of course we could also do this with means built into the statechart language. However, in the general case you neither _can_ nor _want_ to do that. +* Implementing the functionality in the statechart language might not be possible, because the latter does not provide the necessary means, e. g. to pull some data from an external source. +* Even if it would be possible to implement the functionality in the statechart language, it might still not be desirable, if the functionality has been developed and fully tested in C already. You will neither want to re-invent the wheel nor would you want to introduce any new errors into an alternative implementation. + +YAKINDU Statechart Tools parses function declarations in header files and makes the functions available in the statechart language. It doesn't care where those functions are defined – or whether they are defined at all – nor what they do. Questions like these will become relevant later when the state machine is generated as C source code, compiled and linked to the functions' implementations. + +For now, once the statechart knows about the _area_ function's declaration in the C header file, the function can be used immediately in statechart language operations. Any @operation@ declaration in the statechart's definition section is not needed. Example: + +!(standard-image)images/cdom_geometry_090_operations_010_content_assist.png(Using content assist to enter a C function call)! + +p=. Using content assist to enter a C function call + +Here's the complete example with the area calculations done by the _area_ function: + +!(standard-image)images/cdom_geometry_090_operations_020_calling_area.png(Using content assist to enter a C function call)! + +p=. Using content assist to enter a C function call + + +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_generating_c_source_code). Generating C source code + +Code generation, i. 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 + +In the statechart model introduced above, do the following: + +# In the project view, right-click on the project's name. The context menu opens. +# In the context menu, select _New → Code Generator Model_. The _YAKINDU Generator Model_ wizard opens. +# Enter a file name into the _File name_ field, e. g. *c.sgen*, and click _Next >_. +# In the _Generator_ drop-down menu, select *YAKINDU SCT C Code Generator*. +# Select the statechart models to generate C source code for. Click _Finish_. + +YAKINDU Statechart Tools creates the following generator model in the file *c.sgen*: + +bc.. GeneratorModel for yakindu::c { + + statechart statechart { + + feature Outlet { + targetProject = "Geometry" + targetFolder = "src-gen" + libraryTargetFolder = "src" + } + } +} + +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 + +Particularly interesting are the files *Statechart.h* and *Statechart.c*. + +*Statechart.h* first includes the *sc_types.h* header followed by very same C header files that have been included in the statechart: + +bc. #include "sc_types.h" +#include "rectangle.h" + +The generated code in *Statechart.h* then uses the native standard and user-defined C data types. For example, the statechart implementation defines the type _StatechartIface_ as follows: + +bc. /*! Type definition of the data structure for the StatechartIface interface scope. */ +typedef struct +{ + Rectangle a; + Rectangle b; + int32_t area_a; + int32_t area_b; + Point p; +} StatechartIface; + +By including *Statechart.h* all definitions are available in *Statechart.c*, too. For example, a getter and a setter function for the _Rectangle_ variable _a_ are defined as follows: + +bc. Rectangle statechartIface_get_a(const Statechart* handle) +{ + return handle->iface.a; +} +void statechartIface_set_a(Statechart* handle, Rectangle value) +{ + handle->iface.a = value; +} + +The external _area_ function is called in the entry actions section of state _Check_: + +bc. /* Entry action for state 'Check'. */ +static void statechart_enact_main_region_Check(Statechart* handle) +{ + /* Entry action for state 'Check'. */ + handle->iface.area_a = area(handle->iface.a); + handle->iface.area_b = area(handle->iface.b); +} + + +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: + +* _bool_ +* _double_ +* _float_ +* _int16_t_ +* _int32_t_ +* _int64_t_ +* _int8_t_ +* _string_ +* _uint16_t_ +* _uint32_t_ +* _uint64_t_ +* _uint8_t_ +* _void_ + + +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 + +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 + +Type range validations are currently not implemented. As a consequence, it is possible to e. g. assign an _int32_t_ value to an _int8_t_ variable one without any warning. + +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 + +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! + +==
==
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/40_editing_statecharts.textile b/plugins/org.yakindu.sct.doc.user/src/user-guide/editing_statecharts.textile
similarity index 87%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/40_editing_statecharts.textile
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/editing_statecharts.textile
index 826a23fc2c..d1dc9fd7cd 100644
--- a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/40_editing_statecharts.textile
+++ b/plugins/org.yakindu.sct.doc.user/src/user-guide/editing_statecharts.textile
@@ -58,7 +58,7 @@ _SC Modeling_ is an Eclipse perspective supporting the modeling of statecharts.
h3(#canvas). Canvas
-The canvas is the statechart editor's drawing area. When you create a new statechart model, the canvas comprises the definition section and a single "region":30_statechart_language#region.
+The canvas is the statechart editor's drawing area. When you create a new statechart model, the canvas comprises the definition section and a single "region":../user-guide/statechart_language#region.
The following list gives an overview of what kind of actions you can perform on the canvas:
* Add or remove a region
@@ -74,34 +74,34 @@ The editor palette provides you with a set of various actions and statechart edi
You can hide the palette by clicking on the small triangle in the palette's title bar. Click on the triangle again to make the palette reappear.
-!(standard-image)images/editor-palette_010_overview.png(Editor palette)!
+!(standard-image)images/docu_editor-palette_010_overview.png(Editor palette)!
p=. Editor palette
h4(#oss-editing-action-tools). Editing action tools
Below its title bar, the palette contains a toolbar with the following editing action tools (from left to right):
-| !images/editor-palette_020_symbol_select.png(Editor palette symbol "Select")! | Select | |
-| !images/editor-palette_030_symbol_zoom_in.png(Editor palette symbol "Zoom in")! | Zoom in | Left-click to zoom in. Press @[Shift]@ and left-click to zoom out. Drag to zoom to selection. |
-| !images/editor-palette_040_symbol_zoom_out.png(Editor palette symbol "Zoom out")! | Zoom out | Left-click to zoom out. Press @[Shift]@ and left-click to zoom in. |
-| !images/editor-palette_070_symbol_note.png(Editor palette symbol "Note")! | Note | Create a note, a text or a note attachment. |
+| !images/docu_editor-palette_020_symbol_select.png(Editor palette symbol "Select")! | Select | |
+| !images/docu_editor-palette_030_symbol_zoom_in.png(Editor palette symbol "Zoom in")! | Zoom in | Left-click to zoom in. Press @[Shift]@ and left-click to zoom out. Drag to zoom to selection. |
+| !images/docu_editor-palette_040_symbol_zoom_out.png(Editor palette symbol "Zoom out")! | Zoom out | Left-click to zoom out. Press @[Shift]@ and left-click to zoom in. |
+| !images/docu_editor-palette_070_symbol_note.png(Editor palette symbol "Note")! | Note | Create a note, a text or a note attachment. |
h4(#oss-statechart-elements-tools). Statechart elements tools
The palette comprises a couple of tools serving to add statechart elements to the diagram (from top to bottom):
-| !images/editor-palette_210_tool_transition.png(Editor palette element tool "Transition")! |
-| !images/editor-palette_220_tool_state.png(Editor palette element tool "State")! |
-| !images/editor-palette_230_tool_composite_state.png(Editor palette element tool "Composite state")! |
-| !images/editor-palette_240_tool_orthogonal_state.png(Editor palette element tool "Orthogonal state")! |
-| !images/editor-palette_250_tool_region.png(Editor palette element tool "Region")! |
-| !images/editor-palette_260_tool_entry.png(Editor palette element tool "Entry")! |
-| !images/editor-palette_270_tool_shallow_history.png(Editor palette element tool "Shallow history")! |
-| !images/editor-palette_280_tool_deep_history.png(Editor palette element tool "Deep history")! |
-| !images/editor-palette_290_tool_final_state.png(Editor palette element tool "Final state")! |
-| !images/editor-palette_300_tool_exit_node.png(Editor palette element tool "Exit node")! |
-| !images/editor-palette_310_tool_choice.png(Editor palette element tool "Choice")! |
-| !images/editor-palette_320_tool_synchronization.png(Editor palette element tool "Synchronization")! |
+| !images/docu_editor-palette_210_tool_transition.png(Editor palette element tool "Transition")! |
+| !images/docu_editor-palette_220_tool_state.png(Editor palette element tool "State")! |
+| !images/docu_editor-palette_230_tool_composite_state.png(Editor palette element tool "Composite state")! |
+| !images/docu_editor-palette_240_tool_orthogonal_state.png(Editor palette element tool "Orthogonal state")! |
+| !images/docu_editor-palette_250_tool_region.png(Editor palette element tool "Region")! |
+| !images/docu_editor-palette_260_tool_entry.png(Editor palette element tool "Entry")! |
+| !images/docu_editor-palette_270_tool_shallow_history.png(Editor palette element tool "Shallow history")! |
+| !images/docu_editor-palette_280_tool_deep_history.png(Editor palette element tool "Deep history")! |
+| !images/docu_editor-palette_290_tool_final_state.png(Editor palette element tool "Final state")! |
+| !images/docu_editor-palette_300_tool_exit_node.png(Editor palette element tool "Exit node")! |
+| !images/docu_editor-palette_310_tool_choice.png(Editor palette element tool "Choice")! |
+| !images/docu_editor-palette_320_tool_synchronization.png(Editor palette element tool "Synchronization")! |
h3(#outline-view). Outline view
@@ -163,7 +163,7 @@ You can change the name of a region in the statechart editor as well as in the p
h2(#editing-hierarchies). Editing hierarchies
-Statecharts can get rather big and complex. *"Composite states":30_statechart_language#composite-state* are a way to reduce complexity and thus make statecharts easier to create, comprehend and maintain. A composite state comprises a state machine of its own within a "region":30_statechart_language#region. The states belonging to such a nested state machine are called *substates*. *"Orthogonal states":30_statechart_language#orthogonal-states* are a generalization of composite states, comprising two or more independent state machines in separate regions that are executed in parallel.
+Statecharts can get rather big and complex. *"Composite states":../user-guide/statechart_language#composite-state* are a way to reduce complexity and thus make statecharts easier to create, comprehend and maintain. A composite state comprises a state machine of its own within a "region":../user-guide/statechart_language#region. The states belonging to such a nested state machine are called *substates*. *"Orthogonal states":../user-guide/statechart_language#orthogonal-states* are a generalization of composite states, comprising two or more independent state machines in separate regions that are executed in parallel.
A complementary way to mitigate size are *subdiagrams*. A subdiagram externalizes the possibly large region(s) contained by a composite state into a subdiagram. In this case the composite state no longer displays its substates. Instead it is visualized very similar to a regular state, aside from a small label marking it as a composite state and giving access to its internal structure: the subdiagram. In this way a composite state consumes much less space and gives the user the opportunity to better see the overall picture. Section "Using subdiagrams":#using-subdiagrams explains how to work with subdiagrams, how to create them and how to inline them again, if needed.
@@ -175,7 +175,7 @@ h2(#using-subdiagrams). Using subdiagrams
When using composite states, a statechart model may easily become too big to give a comprehensive overview of the whole diagram. Subdiagrams come as a solution.
-!(standard-image)images/subdiagram_010_inline.png(Composite state)!
+!(standard-image)images/docu_subdiagram_010_inline.png(Composite state)!
p=. Composite state
@@ -183,13 +183,13 @@ When the _Extract Subdiagram_ "refactoring":#refactorings is executed on a compo
Extracting a subdiagram creates entry and exit nodes in the subdiagram as needed.
-!(standard-image)images/subdiagram_020_preview.png(Subdiagram popup window)!
+!(standard-image)images/docu_subdiagram_020_preview.png(Subdiagram popup window)!
p=. Subdiagram popup window
A click on the decorator opens the subdiagram in a separate editor tab. The breadcrumb at the top allows easy navigation throughout the hierachy levels.
-!(standard-image)images/subdiagram_030_subdiagram-editor.png(Subdiagram editor)!
+!(standard-image)images/docu_subdiagram_030_subdiagram-editor.png(Subdiagram editor)!
p=. Subdiagram editor
@@ -206,7 +206,7 @@ Using the _Rename_ refactoring, you can change the name of a variable, event or
To initiate renaming, right-click on the name of a variable, event or interface in the diagram editor, in the definition section, or in a text field in the _Properties_ view, then select _Rename …_.
-!(standard-image)images/refactoring-rename_010_renaming-variable.png(Renaming a variable)!
+!(standard-image)images/docu_refactoring-rename_010_renaming-variable.png(Renaming a variable)!
p=. Renaming a variable
@@ -220,7 +220,7 @@ The _Fold Incoming Actions_ refactoring moves these actions from the transitions
Consider the following model:
-!(standard-image)images/refactoring-fold-incoming-actions_010_example_01.png(Moving incoming actions to entry block)!
+!(standard-image)images/docu_refactoring-fold-incoming-actions_010_example_01.png(Moving incoming actions to entry block)!
p=. Moving incoming actions to entry block
@@ -228,7 +228,7 @@ Only the most-right action _y += 42_ can be moved to the entry block of the targ
Another aspect to take into account are transitions leading to target states that are nested in composite states. Consider the following example:
-!(standard-image)images/refactoring-fold-incoming-actions_020_example_02.png(Moving incoming actions into a nested state's entry block)!
+!(standard-image)images/docu_refactoring-fold-incoming-actions_020_example_02.png(Moving incoming actions into a nested state's entry block)!
p=. Moving incoming actions into a nested state's entry block
@@ -242,7 +242,7 @@ The _Fold Outgoing Actions_ refactoring is similar to "folding incoming actions"
Preconditions for this refactoring are analog to ""Folding incoming actions"":#folding-incoming-actions. Consider the following example:
-!(standard-image)images/refactoring-fold-outgoing-actions_010_example_01.png(Moving outgoing actions to exit block)!
+!(standard-image)images/docu_refactoring-fold-outgoing-actions_010_example_01.png(Moving outgoing actions to exit block)!
p=. Moving outgoing actions to exit block
@@ -264,7 +264,7 @@ This refactoring is the reverse of "folding outgoing actions":#folding-outgoing-
Transitions crossing the borders of composite states enclosing the source state might inhibit refactoring. Consider the following example:
-!(standard-image)images/refactoring-unfold-outgoing-actions_010_example_01.png(Unfolding exit actions to outgoing transitions)!
+!(standard-image)images/docu_refactoring-unfold-outgoing-actions_010_example_01.png(Unfolding exit actions to outgoing transitions)!
p=. Unfolding exit actions to outgoing transitions
@@ -319,7 +319,7 @@ The statechart editor allows for comparing two or even three statecharts to each
p(#oss_fig_comparing_two_statecharts).
-!(standard-image)images/comparing_statecharts_010_result.png(Comparing two statecharts)!
+!(standard-image)images/docu_comparing_statecharts_010_result.png(Comparing two statecharts)!
p=. Comparing two statecharts
@@ -352,13 +352,13 @@ A statechart can be saved as an image file as shown in the following steps:
In the statechart editor, right-click on the main region. The context menu appears.
-!(standard-image)images/exporting_statechart_as_image_010_save_as_menu_item.png(Selecting the "Save As Image File..." menu item)!
+!(standard-image)images/docu_exporting_statechart_as_image_010_save_as_menu_item.png(Selecting the "Save As Image File..." menu item)!
p=. Selecting the "Save As Image File..." menu item
In the context menu, select File → Save As Image File.... The _Save As Image_ dialog appears.
-!(standard-image)images/exporting_statechart_as_image_020_save_as_dialog.png(The "Save As Image File" dialog)!
+!(standard-image)images/docu_exporting_statechart_as_image_020_save_as_dialog.png(The "Save As Image File" dialog)!
p=. The "Save As Image File" dialog
@@ -393,7 +393,7 @@ The nice thing is that you don't have to remember all the places you took a note
p(#oss_fig_tasks-defined-by-tags-in-the-statechart-showing-up-in-the-tasks-view).
-!(standard-image)images/task_tags_010_task_view.png(Tasks defined by tags in the statechart showing up in the _Tasks_ view)!
+!(standard-image)images/docu_task_tags_010_task_view.png(Tasks defined by tags in the statechart showing up in the _Tasks_ view)!
p=. Tasks defined by tags in the statechart showing up in the _Tasks_ view
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/60_generating_code.textile b/plugins/org.yakindu.sct.doc.user/src/user-guide/generating_code.textile
similarity index 97%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/60_generating_code.textile
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/generating_code.textile
index eb7c7c5b0a..6c61e889b9 100644
--- a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/60_generating_code.textile
+++ b/plugins/org.yakindu.sct.doc.user/src/user-guide/generating_code.textile
@@ -10,7 +10,7 @@ To create a generator model with the wizard, proceed as follows:
# Choose the desired generator, i. e. _YAKINDU SCT Java Code Generator_.
# Check the model(s) to generate code from and click _Finish_.
-!images/genmodelwizardchooselanguage.jpg(Selecting code generator and models)!
+!images/docu_genmodelwizardchooselanguage.jpg(Selecting code generator and models)!
The result is an @.sgen@ file of the following format:
@@ -40,7 +40,7 @@ All generators can be customized by a generator model. This is a textual model i
To get started with the generator model, YAKINDU Statechart Tools includes a wizard that creates a basic configuration file with default values.
-!(standard-image)images/sGenEditor.png(SGen generator model with default values)!
+!(standard-image)images/docu_sGenEditor.png(SGen generator model with default values)!
p=. SGen generator model with default values
@@ -195,7 +195,7 @@ h2(#specifications-of-c-code). Specification of C code
The explanations below are using the _TrafficLight_ sample state machine to describe the API specifications of the code generated by the YAKINDU C and Java code generators. The image below is showing the statechart. It models a pedestrian crossing with push-button operated traffic lights ("pelican crossing").
-!(standard-image)images/TrafficLight.png(The traffic light model)!
+!(standard-image)images/docu_TrafficLight.png(The traffic light model)!
p=. The traffic light model
@@ -530,7 +530,7 @@ h3(#c-operation-callbacks). Operation callbacks
YAKINDU Statechart Tools support client code operations that can be used by a state machine and are executed as as actions. These operations have to be implemented in order to make a statechart executable. The figure below shows a sample statechart using an operation:
-!(standard-image)images/operationExample.png(Specifying an operation callback in the model)!
+!(standard-image)images/docu_operationExample.png(Specifying an operation callback in the model)!
p=. Specifying an operation callback in the model
@@ -739,7 +739,7 @@ h2(#cpp-code-specification). Specification of C++ code
The explanations below are using the _TrafficLight_ sample state machine to describe the API specifications of the code generated by the YAKINDU C and Java code generators. The image below is showing the statechart. It models a pedestrian crossing with push-button operated traffic lights ("pelican crossing").
-!(standard-image)images/TrafficLight.png(The traffic light model)!
+!(standard-image)images/docu_TrafficLight.png(The traffic light model)!
p=. The traffic light model
@@ -1107,7 +1107,7 @@ h3(#cpp-operation-callbacks). Operation callbacks
YAKINDU Statechart Tools support client code operations that can be used by a state machine and are executed as as actions. These operations have to be implemented in order to make a statechart executable. The figure below shows a sample statechart using an operation:
-!(standard-image)images/operationExample.png(Specifying an operation callback in the model)!
+!(standard-image)images/docu_operationExample.png(Specifying an operation callback in the model)!
p=. Specifying an operation callback in the model
@@ -1233,7 +1233,7 @@ h2(#java-code-specification). Specification of Java code
The explanations below are using the _TrafficLight_ sample state machine to describe the API specifications of the code generated by the YAKINDU C and Java code generators. The image below is showing the statechart. It models a pedestrian crossing with push-button operated traffic lights ("pelican crossing").
-!(standard-image)images/TrafficLight.png(The traffic light model)!
+!(standard-image)images/docu_TrafficLight.png(The traffic light model)!
p=. The traffic light model
@@ -1845,7 +1845,7 @@ h3(#java-operation-callback). Operation callbacks
YAKINDU Statechart Tools support _operations_ that are executed by a state machine as actions, but are implemented by client-side code. The figure below shows a sample statechart using an operation:
-!(standard-image)images/operationExample.png(Specifying an operation callback in the model)!
+!(standard-image)images/docu_operationExample.png(Specifying an operation callback in the model)!
p=. Specifying an operation callback in the model
@@ -1912,15 +1912,15 @@ h3(#JavaIntegratingGeneratedCode). Integrating generated code
To get a clue how to integrate a generated Java state machine with your project have a look at the @CrossingDemoCycleBased@ class and its abstract superclass @CrossingDemoBase@. The @main()@ method is in @CrossingDemoCycleBased@:
-bc.
+bc..
public static void main(String[] args) {
new CrossingDemoCycleBased().runTrafficLight();
}
-A new instance of the class is created and the method @runTrafficLight()@ is called. This method can be found in the superclass:
+p. A new instance of the class is created and the method @runTrafficLight()@ is called. This method can be found in the superclass:
-bc.
+bc..
public void runTrafficLight() {
setUpAndRunStatemachine();
@@ -1941,9 +1941,9 @@ public void runTrafficLight() {
tearDownStatemachine();
}
-This method sets up the state machine and creates the GUI content. In a while loop it reads the content of the state machine and repaints the GUI. If the user exits the GUI shell, the loop terminates and the state machine is torn down. The really interesting methods are setUpAndRunStatemachine(), readStatemachineOutput(), and tearDownStatemachine():
+p. This method sets up the state machine and creates the GUI content. In a while loop it reads the content of the state machine and repaints the GUI. If the user exits the GUI shell, the loop terminates and the state machine is torn down. The really interesting methods are setUpAndRunStatemachine(), readStatemachineOutput(), and tearDownStatemachine():
-bc.
+bc..
protected void setUpAndRunStatemachine() {
statemachine = new TrafficLightWaitingStatemachine();
@@ -1954,7 +1954,7 @@ protected void setUpAndRunStatemachine() {
RuntimeService.getInstance().registerStatemachine(statemachine, 100);
}
-First a new instance of the generated state machine is created. Since the traffic light statechart uses timing clauses, it is provided with a timer service, here with the default implementation of the @ITimerService@ interface. In the next steps the state machine is initialized and entered. After the @enter()@ method has been executed, the machine is in a defined state.
+p. First a new instance of the generated state machine is created. Since the traffic light statechart uses timing clauses, it is provided with a timer service, here with the default implementation of the @ITimerService@ interface. In the next steps the state machine is initialized and entered. After the @enter()@ method has been executed, the machine is in a defined state.
Finally the state machine is passed to the runtime service. This service executes the @runCycle()@ method of the state machine every 100 ms, that is the state machine executes a run-to-completion step every 100 ms.
@@ -1991,7 +1991,7 @@ h3(#simulating-operations-with-custom-java-code). Simulating operations with cus
To simulate a model with operations it is possible to use custom Java code that mocks the desired behavior or even to simulate against an existing Java backend. For this purpose it is required to provide one or more custom Java classes having a method with a matching signature.
-!(standard-image)images/java_simulating_operation_010_statechart_with_operation.png(A statechart model with an operation)!
+!(standard-image)images/docu_java_simulating_operation_010_statechart_with_operation.png(A statechart model with an operation)!
p=. A statechart model with an operation
@@ -2020,7 +2020,7 @@ This custom class can be passed to Eclipse's run configuration as an _Operation
When the simulation is executed, the variable _result_ gets the value 2.
-!(standard-image)images/java_simulating_operation_020_run_configuration.png(Configuring an operations class)!
+!(standard-image)images/docu_java_simulating_operation_020_run_configuration.png(Configuring an operations class)!
p=. Configuring an operations class
@@ -2040,7 +2040,7 @@ Creating custom code generators is a first-level concept in YAKINDU Statechart T
To set up a new (Xtend2/Java) generator project, select _File → New → Other... → YAKINDU SCT_ → Xtend2/Java Generator Project_ and click _Next_.
-!(standard-image)images/xtendGenerator.png(Creating an Xtend2 generator project)!
+!(standard-image)images/docu_xtendGenerator.png(Creating an Xtend2 generator project)!
p=. Creating an Xtend2 generator project
@@ -2048,7 +2048,7 @@ The wizard asks for a *Project name* and the name of the *Generator class*, whic
The check box *Configure for Plugin Export* adds all required extension point registrations to the new project for exporting it as a plugin. The generator model can refer to the new generator plugin via its unique *Generator ID*. If you want to contribute custom generator features for your code generator, check the *Create Feature Library* check box. Click _Finish_ to close the wizard.
-!images/generatornavigator.png(Created generator project)!
+!images/docu_generatornavigator.png(Created generator project)!
Voilà! The wizard creates a new generator project for you with a structure as shown above. The file _CustomGenerator.xtend_ contains a simple default code generator that simply prints the name of the statechart and all of its states to the target file.
@@ -2130,7 +2130,7 @@ h2. Different meta models for different use cases
*The SGraph meta model*
The SGraph meta model defines the structural aspects of the Statechart model and is similiar to the statemachine model defined by the Unified Modeling Language (UML). A simplified version is shown in the following diagram.
-!images/sgraph_simple.png(Simplified SGraph meta model)!
+!images/docu_sgraph_simple.png(Simplified SGraph meta model)!
* *Statechart* extends __CompositeElement__, therefore it contains 0..* __Regions__. It is the root element of the model.
* *CompositeElement* is an abstract type that contains __Regions__. Known subclasses are __Statechart__ and __State__.
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_010_lightswitch_010_statechart.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_010_lightswitch_010_statechart.png
new file mode 100644
index 0000000000..b1a562b6b3
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_010_lightswitch_010_statechart.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/advsim_010_lightswitch_020_simulation.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_010_lightswitch_020_simulation.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/advsim_010_lightswitch_020_simulation.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_010_lightswitch_020_simulation.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_020_start_debugging_010_debug_as_menu.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_020_start_debugging_010_debug_as_menu.png
new file mode 100644
index 0000000000..f3274a79ff
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_020_start_debugging_010_debug_as_menu.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_010_setting_on_transition.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_010_setting_on_transition.png
new file mode 100644
index 0000000000..e803baf640
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_010_setting_on_transition.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_020_transition_and_state_with_breakpoints.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_020_transition_and_state_with_breakpoints.png
new file mode 100644
index 0000000000..ac6b15e46d
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_020_transition_and_state_with_breakpoints.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_030_suspending_at_state.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_030_suspending_at_state.png
new file mode 100644
index 0000000000..c19fec0038
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_030_suspending_at_state.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_040_suspending_at_transition.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_040_suspending_at_transition.png
new file mode 100644
index 0000000000..e873d7f861
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_040_suspending_at_transition.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_050_enabled_and_disabled_breakpoints.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_050_enabled_and_disabled_breakpoints.png
new file mode 100644
index 0000000000..bb2c414671
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_030_breakpoint_050_enabled_and_disabled_breakpoints.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_040_multiple_events_010_events_not_raised.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_040_multiple_events_010_events_not_raised.png
new file mode 100644
index 0000000000..4816377ffb
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_040_multiple_events_010_events_not_raised.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_040_multiple_events_020_events_raised.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_040_multiple_events_020_events_raised.png
new file mode 100644
index 0000000000..63086466aa
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_040_multiple_events_020_events_raised.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_040_multiple_events_030_transition-priorities.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_040_multiple_events_030_transition-priorities.png
new file mode 100644
index 0000000000..f735b0e754
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_040_multiple_events_030_transition-priorities.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_010_a-freshly-taken-snapshot.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_010_a-freshly-taken-snapshot.png
new file mode 100644
index 0000000000..94588cb6dd
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_010_a-freshly-taken-snapshot.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_020_inspecting_variables.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_020_inspecting_variables.png
new file mode 100644
index 0000000000..2240cf2ffe
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_020_inspecting_variables.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_025_details_view.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_025_details_view.png
new file mode 100644
index 0000000000..8da81d8182
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_025_details_view.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_030_inspecting-a-snapshots-state-machine.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_030_inspecting-a-snapshots-state-machine.png
new file mode 100644
index 0000000000..d9ff8a1b16
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_030_inspecting-a-snapshots-state-machine.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_040_restoring-a-snapshot.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_040_restoring-a-snapshot.png
new file mode 100644
index 0000000000..bda6e224dd
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_050_snapshots_040_restoring-a-snapshot.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_breakpoint_skip_disengaged.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_breakpoint_skip_disengaged.png
new file mode 100644
index 0000000000..f8d092eefe
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_breakpoint_skip_disengaged.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_breakpoint_skip_engaged.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_breakpoint_skip_engaged.png
new file mode 100644
index 0000000000..0297698b9f
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_breakpoint_skip_engaged.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_camera.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_camera.png
new file mode 100644
index 0000000000..839b0c2c6c
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_camera.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_remove.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_remove.png
new file mode 100644
index 0000000000..917136ae52
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_remove.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_remove_all.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_remove_all.png
new file mode 100644
index 0000000000..9b3e4e3484
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_remove_all.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_remove_red.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_remove_red.png
new file mode 100644
index 0000000000..2e511f9284
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_remove_red.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_snapshot_image_overview.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_snapshot_image_overview.png
new file mode 100644
index 0000000000..e2f0cf2323
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_snapshot_image_overview.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_snapshot_restore.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_snapshot_restore.png
new file mode 100644
index 0000000000..d366b637bd
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_snapshot_restore.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_snapshot_variable_overview.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_snapshot_variable_overview.png
new file mode 100644
index 0000000000..92918fba55
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_button_snapshot_variable_overview.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_breakpoint_disabled.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_breakpoint_disabled.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_breakpoint_disabled.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_breakpoint_disabled.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_breakpoint_enabled.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_breakpoint_enabled.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_breakpoint_enabled.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_breakpoint_enabled.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_breakpoint_skip.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_breakpoint_skip.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_breakpoint_skip.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_breakpoint_skip.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_event.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_event.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_event.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_event.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_event_raised.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_event_raised.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_event_raised.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_event_raised.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_resume.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_resume.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_resume.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_resume.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_stepover.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_stepover.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_stepover.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/advsim_symbol_stepover.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_010_new_c_project_010.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_010_new_c_project_010.png
new file mode 100644
index 0000000000..c786699579
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_010_new_c_project_010.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_010_new_c_project_020.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_010_new_c_project_020.png
new file mode 100644
index 0000000000..28009372f6
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_010_new_c_project_020.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_010_new_c_project_030.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_010_new_c_project_030.png
new file mode 100644
index 0000000000..059bae88ce
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_010_new_c_project_030.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_020_new_header_file_010.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_020_new_header_file_010.png
new file mode 100644
index 0000000000..ab868dea94
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_020_new_header_file_010.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_020_new_header_file_020.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_020_new_header_file_020.png
new file mode 100644
index 0000000000..f905fcea6e
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_020_new_header_file_020.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_020_new_header_file_030.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_020_new_header_file_030.png
new file mode 100644
index 0000000000..25a0d1045a
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_020_new_header_file_030.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_030_new_statechart_model_010.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_030_new_statechart_model_010.png
new file mode 100644
index 0000000000..219e07eff8
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_030_new_statechart_model_010.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_030_new_statechart_model_030.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_030_new_statechart_model_030.png
new file mode 100644
index 0000000000..fc185d4002
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_030_new_statechart_model_030.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_040_c_types_010.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_040_c_types_010.png
new file mode 100644
index 0000000000..fa397c90cd
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_040_c_types_010.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_040_c_types_020.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_040_c_types_020.png
new file mode 100644
index 0000000000..8ffca5f252
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_040_c_types_020.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_050_using_c_type_variables_010.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_050_using_c_type_variables_010.png
new file mode 100644
index 0000000000..de94b4b5db
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_050_using_c_type_variables_010.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_060_importing_namespace_010.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_060_importing_namespace_010.png
new file mode 100644
index 0000000000..f80093be36
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_060_importing_namespace_010.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_070_typedefs_and_structs_010.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_070_typedefs_and_structs_010.png
new file mode 100644
index 0000000000..4cb546a4f1
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_070_typedefs_and_structs_010.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_080_simulation_010_statechart.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_080_simulation_010_statechart.png
new file mode 100644
index 0000000000..ed720ddc45
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_080_simulation_010_statechart.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_080_simulation_020_inspecting.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_080_simulation_020_inspecting.png
new file mode 100644
index 0000000000..8b7d05f601
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_080_simulation_020_inspecting.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_080_simulation_030_modifying.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_080_simulation_030_modifying.png
new file mode 100644
index 0000000000..76ec353166
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_080_simulation_030_modifying.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_080_simulation_040_rechecked.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_080_simulation_040_rechecked.png
new file mode 100644
index 0000000000..45fe227e86
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_080_simulation_040_rechecked.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_083_enum_010_content_assist.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_083_enum_010_content_assist.png
new file mode 100644
index 0000000000..4d2d226708
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_083_enum_010_content_assist.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_083_enum_020_simulation.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_083_enum_020_simulation.png
new file mode 100644
index 0000000000..d20a8b87de
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_083_enum_020_simulation.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_090_operations_010_content_assist.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_090_operations_010_content_assist.png
new file mode 100644
index 0000000000..b3cb5baa05
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_090_operations_010_content_assist.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_090_operations_020_calling_area.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_090_operations_020_calling_area.png
new file mode 100644
index 0000000000..78ee03704d
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_090_operations_020_calling_area.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_160_type_lookup_010.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_160_type_lookup_010.png
new file mode 100644
index 0000000000..0ad2f69e56
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_160_type_lookup_010.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_160_type_lookup_020.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_160_type_lookup_020.png
new file mode 100644
index 0000000000..8462d49002
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_160_type_lookup_020.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_170_data_structure_traversal_010.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_170_data_structure_traversal_010.png
new file mode 100644
index 0000000000..d54b3f8d3d
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/cdom_geometry_170_data_structure_traversal_010.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/TrafficLight.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_TrafficLight.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/TrafficLight.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_TrafficLight.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/YAKINDU_features.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_YAKINDU_features.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/YAKINDU_features.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_YAKINDU_features.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_advsim_010_lightswitch_020_simulation.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_advsim_010_lightswitch_020_simulation.png
new file mode 100644
index 0000000000..a2c30fecf9
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_advsim_010_lightswitch_020_simulation.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/comparing_statecharts_010_result.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_comparing_statecharts_010_result.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/comparing_statecharts_010_result.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_comparing_statecharts_010_result.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/cycleBasedVsEventDriven.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_cycleBasedVsEventDriven.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/cycleBasedVsEventDriven.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_cycleBasedVsEventDriven.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_010_overview.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_010_overview.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_010_overview.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_010_overview.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_020_symbol_select.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_020_symbol_select.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_020_symbol_select.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_020_symbol_select.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_030_symbol_zoom_in.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_030_symbol_zoom_in.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_030_symbol_zoom_in.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_030_symbol_zoom_in.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_040_symbol_zoom_out.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_040_symbol_zoom_out.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_040_symbol_zoom_out.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_040_symbol_zoom_out.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_070_symbol_note.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_070_symbol_note.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_070_symbol_note.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_070_symbol_note.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_210_tool_transition.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_210_tool_transition.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_210_tool_transition.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_210_tool_transition.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_220_tool_state.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_220_tool_state.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_220_tool_state.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_220_tool_state.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_230_tool_composite_state.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_230_tool_composite_state.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_230_tool_composite_state.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_230_tool_composite_state.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_240_tool_orthogonal_state.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_240_tool_orthogonal_state.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_240_tool_orthogonal_state.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_240_tool_orthogonal_state.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_250_tool_region.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_250_tool_region.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_250_tool_region.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_250_tool_region.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_260_tool_entry.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_260_tool_entry.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_260_tool_entry.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_260_tool_entry.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_270_tool_shallow_history.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_270_tool_shallow_history.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_270_tool_shallow_history.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_270_tool_shallow_history.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_280_tool_deep_history.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_280_tool_deep_history.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_280_tool_deep_history.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_280_tool_deep_history.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_290_tool_final_state.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_290_tool_final_state.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_290_tool_final_state.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_290_tool_final_state.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_300_tool_exit_node.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_300_tool_exit_node.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_300_tool_exit_node.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_300_tool_exit_node.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_310_tool_choice.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_310_tool_choice.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_310_tool_choice.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_310_tool_choice.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_320_tool_synchronization.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_320_tool_synchronization.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/editor-palette_320_tool_synchronization.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_editor-palette_320_tool_synchronization.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/exporting_statechart_as_image_010_save_as_menu_item.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_exporting_statechart_as_image_010_save_as_menu_item.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/exporting_statechart_as_image_010_save_as_menu_item.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_exporting_statechart_as_image_010_save_as_menu_item.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/exporting_statechart_as_image_020_save_as_dialog.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_exporting_statechart_as_image_020_save_as_dialog.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/exporting_statechart_as_image_020_save_as_dialog.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_exporting_statechart_as_image_020_save_as_dialog.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/generatornavigator.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_generatornavigator.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/generatornavigator.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_generatornavigator.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/genmodelwizardchooselanguage.jpg b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_genmodelwizardchooselanguage.jpg
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/genmodelwizardchooselanguage.jpg
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_genmodelwizardchooselanguage.jpg
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/java_simulating_operation_010_statechart_with_operation.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_java_simulating_operation_010_statechart_with_operation.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/java_simulating_operation_010_statechart_with_operation.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_java_simulating_operation_010_statechart_with_operation.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/java_simulating_operation_020_run_configuration.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_java_simulating_operation_020_run_configuration.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/java_simulating_operation_020_run_configuration.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_java_simulating_operation_020_run_configuration.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/launch_configuration_01.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_launch_configuration_01.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/launch_configuration_01.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_launch_configuration_01.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/launch_configuration_02.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_launch_configuration_02.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/launch_configuration_02.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_launch_configuration_02.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/launch_configuration_03.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_launch_configuration_03.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/launch_configuration_03.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_launch_configuration_03.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/launch_configuration_04.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_launch_configuration_04.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/launch_configuration_04.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_launch_configuration_04.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/operationExample.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_operationExample.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/operationExample.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_operationExample.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/operationsExample.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_operationsExample.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/operationsExample.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_operationsExample.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/orthogonalState_example.jpg b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_orthogonalState_example.jpg
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/orthogonalState_example.jpg
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_orthogonalState_example.jpg
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/parallelRegions.jpg b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_parallelRegions.jpg
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/parallelRegions.jpg
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_parallelRegions.jpg
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/refactoring-fold-incoming-actions_010_example_01.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_refactoring-fold-incoming-actions_010_example_01.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/refactoring-fold-incoming-actions_010_example_01.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_refactoring-fold-incoming-actions_010_example_01.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/refactoring-fold-incoming-actions_020_example_02.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_refactoring-fold-incoming-actions_020_example_02.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/refactoring-fold-incoming-actions_020_example_02.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_refactoring-fold-incoming-actions_020_example_02.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/refactoring-fold-outgoing-actions_010_example_01.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_refactoring-fold-outgoing-actions_010_example_01.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/refactoring-fold-outgoing-actions_010_example_01.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_refactoring-fold-outgoing-actions_010_example_01.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/refactoring-rename_010_renaming-variable.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_refactoring-rename_010_renaming-variable.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/refactoring-rename_010_renaming-variable.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_refactoring-rename_010_renaming-variable.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/refactoring-unfold-outgoing-actions_010_example_01.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_refactoring-unfold-outgoing-actions_010_example_01.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/refactoring-unfold-outgoing-actions_010_example_01.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_refactoring-unfold-outgoing-actions_010_example_01.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/sGenEditor.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_sGenEditor.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/sGenEditor.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_sGenEditor.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/sGenWizard.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_sGenWizard.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/sGenWizard.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_sGenWizard.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/sgraphMetaModel.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_sgraphMetaModel.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/sgraphMetaModel.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_sgraphMetaModel.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/sgraph_simple.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_sgraph_simple.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/sgraph_simple.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_sgraph_simple.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/shallowHistory01.jpg b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_shallowHistory01.jpg
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/shallowHistory01.jpg
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_shallowHistory01.jpg
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/shallowHistory02.jpg b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_shallowHistory02.jpg
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/shallowHistory02.jpg
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_shallowHistory02.jpg
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/shallowHistory03.jpg b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_shallowHistory03.jpg
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/shallowHistory03.jpg
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_shallowHistory03.jpg
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/simulationRunConfiguration.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_simulationRunConfiguration.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/simulationRunConfiguration.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_simulationRunConfiguration.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_entry.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_entry.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_entry.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_entry.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_entry_exit.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_entry_exit.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_entry_exit.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_entry_exit.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_entry_exit_final.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_entry_exit_final.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_entry_exit_final.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_entry_exit_final.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_entry_exit_final_explained.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_entry_exit_final_explained.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_entry_exit_final_explained.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_entry_exit_final_explained.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_entry_exit_final_explained.svg b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_entry_exit_final_explained.svg
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_entry_exit_final_explained.svg
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_entry_exit_final_explained.svg
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_initial_final.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_initial_final.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_initial_final.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_initial_final.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_synchronization.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_synchronization.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/state_synchronization.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_state_synchronization.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/subdiagram_010_inline.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_subdiagram_010_inline.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/subdiagram_010_inline.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_subdiagram_010_inline.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/subdiagram_020_preview.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_subdiagram_020_preview.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/subdiagram_020_preview.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_subdiagram_020_preview.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/subdiagram_030_subdiagram-editor.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_subdiagram_030_subdiagram-editor.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/subdiagram_030_subdiagram-editor.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_subdiagram_030_subdiagram-editor.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_breakpoint_disabled.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_breakpoint_disabled.png
new file mode 100644
index 0000000000..d34da3e928
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_breakpoint_disabled.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_breakpoint_enabled.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_breakpoint_enabled.png
new file mode 100644
index 0000000000..a05d051c0a
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_breakpoint_enabled.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_breakpoint_skip.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_breakpoint_skip.png
new file mode 100644
index 0000000000..0ff13be086
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_breakpoint_skip.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_event.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_event.png
new file mode 100644
index 0000000000..3703d9eb84
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_event.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_event_raised.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_event_raised.png
new file mode 100644
index 0000000000..5b4dded241
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_event_raised.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_resume.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_resume.png
new file mode 100644
index 0000000000..2d8e8eaa1b
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_resume.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_stepover.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_stepover.png
new file mode 100644
index 0000000000..d6ab821144
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_stepover.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_suspend.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_suspend.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_suspend.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_suspend.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_terminate.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_terminate.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/symbol_terminate.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_symbol_terminate.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/task_tags_010_task_view.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_task_tags_010_task_view.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/task_tags_010_task_view.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_task_tags_010_task_view.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/xtendGenerator.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_xtendGenerator.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/xtendGenerator.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_xtendGenerator.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/xtendwizard.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_xtendwizard.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/images/xtendwizard.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/docu_xtendwizard.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/licenses.txt b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/licenses.txt
new file mode 100644
index 0000000000..8e1c4443dc
--- /dev/null
+++ b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/licenses.txt
@@ -0,0 +1,8 @@
+Image Licenses:
+---------------
+
+camera16x16.png
+ created by FatCow Web Hosting (http://www.fatcow.com/free-icons/)
+ Licensed under the Creative Commons Attribution 3.0 United States license.
+ http://creativecommons.org/licenses/by/3.0/us/deed.en
+ Taken from http://commons.wikimedia.org/wiki/File:Farm-Fresh_camera.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_call_example.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_call_example.png
new file mode 100644
index 0000000000..57a542fd81
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_call_example.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_example_final.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_example_final.png
new file mode 100644
index 0000000000..8c76497925
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_example_final.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_genArtifacts.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_genArtifacts.png
new file mode 100644
index 0000000000..c8df4c4152
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_genArtifacts.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_junitSuc2.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_junitSuc2.png
new file mode 100644
index 0000000000..6979a40ef1
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_junitSuc2.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_namespace_sctunit.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_namespace_sctunit.png
new file mode 100644
index 0000000000..dbbb94bd4b
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_namespace_sctunit.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_project_after.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_project_after.png
new file mode 100644
index 0000000000..a7d03c6707
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_project_after.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_project_before.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_project_before.png
new file mode 100644
index 0000000000..f7d5430172
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_project_before.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_sctunit32.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_sctunit32.png
new file mode 100644
index 0000000000..e4db740325
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_sctunit32.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_sgenStatemachine.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_sgenStatemachine.png
new file mode 100644
index 0000000000..da0d35179c
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_sgenStatemachine.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_sgenTest.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_sgenTest.png
new file mode 100644
index 0000000000..5b52cfc29c
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_sgenTest.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_sgen_generic.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_sgen_generic.png
new file mode 100644
index 0000000000..bda511ea6a
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_sgen_generic.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_strg_statechart.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_strg_statechart.png
new file mode 100644
index 0000000000..34e1744894
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_strg_statechart.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_testcase.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_testcase.png
new file mode 100644
index 0000000000..5f1db6bcbf
Binary files /dev/null and b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/sctu_testcase.png differ
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/tuto_light_switch_300_statechart_simulator_run_as_statechart_simulation.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/tuto_light_switch_300_statechart_simulator_run_as_statechart_simulation.png
new file mode 120000
index 0000000000..fb3951da9a
--- /dev/null
+++ b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/tuto_light_switch_300_statechart_simulator_run_as_statechart_simulation.png
@@ -0,0 +1 @@
+../../tutorials/images/tuto_light_switch_300_statechart_simulator_run_as_statechart_simulation.png
\ No newline at end of file
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/images/tuto_light_switch_310_statechart_simulator_state_off.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/tuto_light_switch_310_statechart_simulator_state_off.png
new file mode 120000
index 0000000000..516e0d6ad9
--- /dev/null
+++ b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/tuto_light_switch_310_statechart_simulator_state_off.png
@@ -0,0 +1 @@
+../../tutorials/images/tuto_light_switch_310_statechart_simulator_state_off.png
\ No newline at end of file
diff --git a/plugins/org.yakindu.sct.doc.user/src/images/custom_generator_010_create_generator_project.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/unused_custom_generator_010_create_generator_project.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/images/custom_generator_010_create_generator_project.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/unused_custom_generator_010_create_generator_project.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/images/custom_generator_020_default_generator_project.png b/plugins/org.yakindu.sct.doc.user/src/user-guide/images/unused_custom_generator_020_default_generator_project.png
similarity index 100%
rename from plugins/org.yakindu.sct.doc.user/src/images/custom_generator_020_default_generator_project.png
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/images/unused_custom_generator_020_default_generator_project.png
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/10_overview.textile b/plugins/org.yakindu.sct.doc.user/src/user-guide/overview.textile
similarity index 97%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/10_overview.textile
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/overview.textile
index f8e3bea922..31a3a88b07 100644
--- a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/10_overview.textile
+++ b/plugins/org.yakindu.sct.doc.user/src/user-guide/overview.textile
@@ -11,7 +11,7 @@ The statechart tools are a central part of YAKINDU: the modular toolkit for mode
The following graph shows these features and their relation to each other:
-!(standard-image)images/YAKINDU_features.png(Features of YAKINDU Statechart Tools)!
+!(standard-image)images/docu_YAKINDU_features.png(Features of YAKINDU Statechart Tools)!
p=. Features of YAKINDU Statechart Tools
diff --git a/plugins/org.yakindu.sct.doc.user/src/user-guide/sctunit.textile b/plugins/org.yakindu.sct.doc.user/src/user-guide/sctunit.textile
new file mode 100644
index 0000000000..d3573367c1
--- /dev/null
+++ b/plugins/org.yakindu.sct.doc.user/src/user-guide/sctunit.textile
@@ -0,0 +1,349 @@
+
+p.
+
+==!(standard-image)images/cdom_geometry_010_new_c_project_010.png(Creating a new C project)! +# Click _Next >_. The _C Project_ dialog appears. +# Enter the name of your project into the _Project name_ field. For the sake of this example, we call the project *Geometry*. +# Specify the location of the project folder by either using the default location or by explicitly specifying a directory in the _Location_ field. +# Select the _Project type_. In order to keep things plain and simple, for this example we create an _Empty Project_. +# Select the toolchain you want to work with. It contains the necessary tools for C development. By default only the toolchains supporting your local platform are displayed. Since this example has been created on a Linux machine, the toolchain *Linux GCC* is shown.
!(standard-image)images/cdom_geometry_010_new_c_project_020.png(Specifying the C project's properties)! +# Click _Next >_. +# Specify platforms, configurations, and project settings. This is more specific to C than to YAKINDU Statechart Tools, so we won't go into any details here.
!(standard-image)images/cdom_geometry_010_new_c_project_030.png(Specifying platforms, configurations, and project settings)! +# Click _Finish_. +# 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 + +Now we can create a C header file specifying our own C type definitions which we can use in a statechart later. In order to create the file, let's proceed as follows: + +# In the project explorer view, right-click on the project. The context menu opens. +# In the context menu, select _New → Header File_.
!(standard-image)images/cdom_geometry_020_new_header_file_010.png(Creating a C header file)! +# The dialog _New Header File_ is shown. Specify the name of the header file. Here we choose *point.h*.
!(standard-image)images/cdom_geometry_020_new_header_file_020.png(Select a header file name)! +# Click _Finish_. +# The header file *point.h* is created.
+ +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. e. a 16-bit signed integer. The complete header file containing the struct definition looks like this: + +bc.. +/* + * point.h + * + */ + +#ifndef POINT_H_ +#define POINT_H_ + +#include
!(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 + +Variables are defined in the definition section on the left-hand side of the statechart editor. Double-click into the section to edit it. + +Let's declare a variable *pointA* of the _Point_ type defined above. In the statechart's definition section, enter the following text: + +bc. +interface: + var pointA: + +On the right-hand side of the colon in the variable declaration, the variable's type must follow. In order to see which types are available, press @[Ctrl+Space]@. The content assist opens and shows the C types available in our C project, i. e. +* the C basic standard types, +* the C99 types provided by including _stdint.h_, +* the self-defined _Point_ type. + +!(standard-image)images/cdom_geometry_040_c_types_010.png(Using the content assist to display available types)! + +p=. Using the content assist to display available types + +Selecting the _Point_ menu entry completes the variable definition: + +!(standard-image)images/cdom_geometry_040_c_types_020.png(A Point variable)! + +p=. A Point variable + +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. + +Let's consider the above example extended by an additional *count* variable of the C99 _int8_t_ standard type. Additionally, we add an event that will be used as a trigger to switch between states. + +bc. interface: + var count: int8_t + var pointA: point.Point + in event tick + +The statechart below uses these variables in various places, i. e. in transition actions, in internal actions, and in guard conditions. + +!(standard-image)images/cdom_geometry_050_using_c_type_variables_010.png(Using C-type variables)! + +p=. Using C-type variables + +Variables of primitive types like @var count: int8_t@ are accessed as expected, e. g. @count = 0@ or @count += 1;@ + +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 + +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. + +In case you are interested in the EMF model underlying SCT's type system, you can find it in the source code of the YAKINDU Statechart Tools open edition at _/org.yakindu.base.types/model/types.ecore_. + + + +h2(#cdom_namespaces). Namespaces + +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. + +At the beginning of the definition section, enter @import:@ and hit @[Ctrl+Space]@. The content assist shows all namespaces you can import, besides other syntactical elements that would be valid here. In our example there's a single namespace _point_ that can be imported. The content assist explains that it comes from _/Geometry/point.h_, i. e. from the file _point.h_ in the _Geometry_ project. + +!(standard-image)images/cdom_geometry_060_importing_namespace_010.png(Selecting a namespace to import)! + +p=. Using C-type variables + +If we had more than a single header file in the project, we would see them all. The content assist shows all header files in a project, including those in subdirectories. + +Click on the namespace entry in the menu to complete the @import@ statement. The result looks like this: + +bc.. import: point + +interface: + var pointA: point.Point + +p. Please note that adding the @import@ statement does not change the variable declaration. However, you can now change the latter to: + +bc. var pointA: Point + + +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. + +The file *point.h* in the main project directory contains the following defintion: + +bc. typedef struct { + int16_t x; + int16_t y; +} Point; + +Additionally, there is a file *three-d/point.h* which also defines a @struct Point@, but with different properties. This _Point_ is three-dimensional and supports _double_ coordinates: + +bc. typedef struct { + double x; + double y; + double z; +} Point; + +On the C side we would run into problems if we tried to use both _Point_ definitions simultaneously. However, in a statechart this is possible, because each header file represents a different namespace. + +A statechart definition section using a two-dimensional *pointA* and a three-dimensional *pointB* would look like this: + +bc. interface: + var pointA: point.Point + var pointB: three_d.point.Point + +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 ""Importing a namespace"":#cdom_importing_a_namespace, it is not advisable. Consider the following example: + +bc.. import: point +import: three_d.point + +interface: + var pointA: Point + var pointB: Point + +p. This won't work, because _Point_ is ambiguous. To define *pointA* and *pointB* correctly, you would still have to fully-qualify the _Point_ types: + +bc.. import: point +import: three_d.point + +interface: + var pointA: point.Point + var pointB: three_d.point.Point + +p. However, in this case the imports would be pointless (pun intended). What you could do is to import only one of the namespaces. Then an unqualified _Point_ denotes the one in the imported namespace, while all other _Point_ types must be fully-qualified. Example: + +bc.. import: point + +interface: + var pointA: Point + var pointB: three_d.point.Point + +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. + +The C header file *triangle.h* specifies the _Triangle_ type: + +bc.. #ifndef TRIANGLE_H_ +#define TRIANGLE_H_ + +#include "./point.h" + +typedef struct { + Point a, b, c; +} Triangle; + +#endif /* TRIANGLE_H_ */ + +p. A _Triangle_ consists of the three _Points_ _a_, _b_, and _c_. Let's define a _Triangle_ _t_ in a statechart's definition section as follows: + +bc.. import: triangle + +interface: + var t: Triangle + +p. With this definition we can use expressions like @t.a.x@, see the image below. Regardless of where you are currently editing an expression, you can always use the code assist to explore which fields are available at that very point and of which types these fields are. Example: + +!(standard-image)images/cdom_geometry_170_data_structure_traversal_010.png(Content assist in data structure traversal)! + +p=. Content assist in data structure traversal + + +h2(#cdom_simulation). Simulation + +During a statechart model simulation full access to the C data structures is possible on all layers. The user can inspect them as well as modify them in the simulation view. + +The state machine below exemplifies this. Initially it defines two rectangles _a_ and _b_ with certain widths and heights. The state machine calculates the rectangles' respective area size, stores their sizes in two _int32_t_ variables named _area_a_ and _area_b_, and compares them. Depending on the result, it proceeds to state *A is larger* or to *A is smaller*. Only if both _a_ and _b_ have the same area – not necessarily the same width and height –, the state machine proceeds to its final state. + +When one of the states *A is larger* or *A is smaller* is active, the rectangles' properties can be changed. Triggering the _compare_size_ event transitions to the *Check* state which repeats the area size comparison as described above. + +!(standard-image)images/cdom_geometry_080_simulation_010_statechart.png(The rectangle comparison statechart)! + +p=. The rectangle comparison statechart + +The state machine's definitions are as follows: + +bc.. import: rectangle + +interface: + var a: Rectangle + var b: Rectangle + var area_a: int16_t + var area_b: int16_t + +internal: + event compare_size + +p. The _Rectangle_ datatype is defined in a new header file _rectangle.h_ with the following contents: + +bc.. #include "./point.h" + +typedef struct { + Point lowerLeft; + int16_t width, height; +} Rectangle; + +p. In order to simulate the statechart, right-click on the statechart file in the project explorer and select _Run As → Statechart Simulation_ from the context menu. + +The statechart simulation +* starts, +* performs the initializing actions specified in the transition from the initial state to the *Check* state, +* in the *Check* state, calculates the rectangles' areas and stores the results in the _area_a_ and _area_b_ variables, +* 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 + +!(standard-image)images/cdom_geometry_080_simulation_020_inspecting.png(Inspecting C data structures)! + +p=. Inspecting C data structures + +The simulation view in the screenshot above is showing the state machine's variables and their values. Click to open or close the nested data structures. The image below shows in particular +* the rectangles' respective width and height values as have been set initially, +* the calculated areas of the _a_ and _b_ rectangles, +* the coordinates of the points defining the respective lower left corner of the rectangles. + +bq.. *Warning:* + +Simple C variables and fields in C data structure are *not* initialized. Never try to read a variable or field you haven't written before, because it might contain arbitrary values. + +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 + +Change a variable's or field's value as follows: +# Click on the _value_ displayed in the simulation view. +# Enter the new value into the text field, see figure ""Modifying C data values"":#cdom_fig_modifying_c_data_values where _a.height_ is being edited and the previous value 7 is replaced by 3. +# Press the @[Enter]@ key to quit editing and to write the new value to the variable or field. Giving the input focus to another window has the same effect. +# You can cancel editing by pressing the @[Esc]@ key. The variable's or field's value remains unchanged. + +p(#cdom_fig_modifying_c_data_values). + +!(standard-image)images/cdom_geometry_080_simulation_030_modifying.png(Modifying C data values)! + +p=. Modifying C data values + +In the example, click _compare_size_ to trigger the event. The state machine transitions to the *Check* state, recalculates the areas, and behaves as explained above. + +!(standard-image)images/cdom_geometry_080_simulation_040_rechecked.png(Rectangle areas modified and rechecked)! + +p=. Rectangle areas modified and rechecked + + +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. 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: + +!(standard-image)images/cdom_geometry_160_type_lookup_010.png(Looking up a C type)! + +p=. Looking up a C type + +Click on the hyperlink to open the header file containing the respective type declaration. + +p=. Showing the C type definition + + +h2(#cdom_enums). Enums + +Besides specifying structure types, it is also possible to declare enumeration types in a C header. Here's the header file *color.h* which defines the _Color_ enumeration type: + +bc.. #ifndef COLOR_H_ +#define COLOR_H_ + +typedef enum { + RED, GREEN, BLUE, YELLOW, BLACK, WHITE +} Color; + +#endif /* COLOR_H_ */ + +p. Now let's extend the _Triangle_ defined above by a fill color: + +bc.. #ifndef TRIANGLE_H_ +#define TRIANGLE_H_ + +#include "./point.h" +#include "./color.h" + +typedef struct { + Point a, b, c; + Color fillColor; + +} Triangle; + +#endif /* TRIANGLE_H_ */ + + +p. Similar to the _Triangle_ type or any other C type, the _Color_ enumeration type can be used in the statechart, e. g. by declaring an additional interface variable: + +bc.. import: color +import: triangle + +interface: + var t: Triangle + var c: Color = Color.BLUE + +p. Please note that in contrast to structured types, enumeration variables can be initialized directly in their definitions. + +In order to see which values are available the content assist, triggered by @[Ctrl+Space]@, is helpful again. + +!(standard-image)images/cdom_geometry_083_enum_010_content_assist.png(Using content assist to select an enumeration value)! + +p=. Using content assist to select an enumeration value + +Once initialized, the _c_ variable can now be used e. g. in an assignment to the triangle _t_'s fill color: + +bc. t.fillColor = c; + +Accordingly, during simulation the values of enum variables are displayed in the simulation view. It is also possible to modify them manually. + +!(standard-image)images/cdom_geometry_083_enum_020_simulation.png(Using content assist to select an enumeration value)! + +p=. Using content assist to select an enumeration value + +h2(#cdom_operations). Operations + +Functions declared in a C header file become available in a statechart. The state machine can call it as an _operation_. + +Let's say our *rectangle.h* header file not only defines the data type, but also declares one or more C functions to operate on them. The following line declares a function named _area_, taking a _Rectangle_ parameter by value and returning an _int32_t_ result. + +bc. extern int32_t area(Rectangle r); + +For the sake of the example, let's assume the function calculates the area of the given rectangle. Of course we could also do this with means built into the statechart language. However, in the general case you neither _can_ nor _want_ to do that. +* Implementing the functionality in the statechart language might not be possible, because the latter does not provide the necessary means, e. g. to pull some data from an external source. +* Even if it would be possible to implement the functionality in the statechart language, it might still not be desirable, if the functionality has been developed and fully tested in C already. You will neither want to re-invent the wheel nor would you want to introduce any new errors into an alternative implementation. + +YAKINDU Statechart Tools parses function declarations in header files and makes the functions available in the statechart language. It doesn't care where those functions are defined – or whether they are defined at all – nor what they do. Questions like these will become relevant later when the state machine is generated as C source code, compiled and linked to the functions' implementations. + +For now, once the statechart knows about the _area_ function's declaration in the C header file, the function can be used immediately in statechart language operations. Any @operation@ declaration in the statechart's definition section is not needed. Example: + +!(standard-image)images/cdom_geometry_090_operations_010_content_assist.png(Using content assist to enter a C function call)! + +p=. Using content assist to enter a C function call + +Here's the complete example with the area calculations done by the _area_ function: + +!(standard-image)images/cdom_geometry_090_operations_020_calling_area.png(Using content assist to enter a C function call)! + +p=. Using content assist to enter a C function call + + +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_generating_c_source_code). Generating C source code + +Code generation, i. 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 + +In the statechart model introduced above, do the following: + +# In the project view, right-click on the project's name. The context menu opens. +# In the context menu, select _New → Code Generator Model_. The _YAKINDU Generator Model_ wizard opens. +# Enter a file name into the _File name_ field, e. g. *c.sgen*, and click _Next >_. +# In the _Generator_ drop-down menu, select *YAKINDU SCT C Code Generator*. +# Select the statechart models to generate C source code for. Click _Finish_. + +YAKINDU Statechart Tools creates the following generator model in the file *c.sgen*: + +bc.. GeneratorModel for yakindu::c { + + statechart statechart { + + feature Outlet { + targetProject = "Geometry" + targetFolder = "src-gen" + libraryTargetFolder = "src" + } + } +} + +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 + +Particularly interesting are the files *Statechart.h* and *Statechart.c*. + +*Statechart.h* first includes the *sc_types.h* header followed by very same C header files that have been included in the statechart: + +bc. #include "sc_types.h" +#include "rectangle.h" + +The generated code in *Statechart.h* then uses the native standard and user-defined C data types. For example, the statechart implementation defines the type _StatechartIface_ as follows: + +bc. /*! Type definition of the data structure for the StatechartIface interface scope. */ +typedef struct +{ + Rectangle a; + Rectangle b; + int32_t area_a; + int32_t area_b; + Point p; +} StatechartIface; + +By including *Statechart.h* all definitions are available in *Statechart.c*, too. For example, a getter and a setter function for the _Rectangle_ variable _a_ are defined as follows: + +bc. Rectangle statechartIface_get_a(const Statechart* handle) +{ + return handle->iface.a; +} +void statechartIface_set_a(Statechart* handle, Rectangle value) +{ + handle->iface.a = value; +} + +The external _area_ function is called in the entry actions section of state _Check_: + +bc. /* Entry action for state 'Check'. */ +static void statechart_enact_main_region_Check(Statechart* handle) +{ + /* Entry action for state 'Check'. */ + handle->iface.area_a = area(handle->iface.a); + handle->iface.area_b = area(handle->iface.b); +} + + +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: + +* _bool_ +* _double_ +* _float_ +* _int16_t_ +* _int32_t_ +* _int64_t_ +* _int8_t_ +* _string_ +* _uint16_t_ +* _uint32_t_ +* _uint64_t_ +* _uint8_t_ +* _void_ + + +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 + +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 + +Type range validations are currently not implemented. As a consequence, it is possible to e. g. assign an _int32_t_ value to an _int8_t_ variable one without any warning. + +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 + +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! + +==
==
+
+h1. SCTUnit
+
+h2. What is SCTUnit for?
+
+!(inlinemediaobject){float: right; height: 10ex}images/sctu_sctunit32.png!
+
+In test driven development, the developer creates automated unit tests before writing the implementation logic. These unit tests define the behavior of a particular piece of code using assertions and are very important to avoid regression when refactoring code.
+
+Test driven development can and should also be used in the context of model-driven development. Since YAKINDU statecharts provide an interface definition for every statechart model, it is possible to write unit tests against these interfaces before creating the implementing statechart model.
+
+SCTUnit is a testing framework which allows to write unit tests for the YAKINDU Statechart Tools. You can validate the behavior of your statechart by writing a well-defined operational sequence with assertions about active states and values of variables. It allows test driven development of statechart models on the semantic level of statecharts.
+
+Based on these Unit tests, the framework generates JUnit tests to test the generated Java statechart as well as Google Tests for the generated C code.
+h1. Getting started
+
+h2. Introduction
+
+This tutorial will introduce the YAKINDU Statechart Tools Testing Framework *SCTUnit*. SCTUnit allows to write tests for statecharts in the the well known XUnit style. Now you can act test driven while creating a statechart for your need.
+
+In this tutorial you will learn how to create a test for a statechart and generate JUnit test code out of the model. You should already be familiar with statecharts and YAKINDU Statechart Tools should be installed.[ref Help SCT]
+
+
+h2. CallHandling example explained
+
+Let's assume that we want to create a software to control a simple phone. The example application we will create during this tutorial is a system for handling of incoming phone calls. After start up, the system is in an Idle state and waits for incoming calls. If a call comes in, the user can either accept the call and open a connection or dismiss it. If the connection is opened, the system tracks the duration of the call and waits for the user to hang up. After hang up, the system displays the total time of call and returns to its idle state. The complete statechart model is shown below:
+
+!(standard-image)images/sctu_call_example.png!
+
+
+h2. Prepare a project
+
+The first step is to create a new Project by choosing _File -> New -> Project_. The dialog offers a couple of different project types. Since we want to generate Java code later on, choose _Java -> Java Project_ from the wizard menu. Give the project a meaningful name, i.e. CallHandling and click finish. It is good practice to separate your models from the source code. Therefore, create a new folder to the projects root by choosing _File -> New -> Folder_ from the projects context menu and call it "model". You also need to create a folder for the generated code, create two more folders with the names "src-gen" and "test-gen". Further you need another folder for the generator file, call this folder "genmodel". At last we need a folder for our test files (.sctunit), call this folder "tests".
+You now need to add **src-gen** (**test-gen** will be automatically added) to the Java build path as source (_Properties-> Java Build Path-> Source Tab-> "AddFolder"_) and add JUnit to the Libraries (_Properties-> Java Build Path-> Libraries Tab->"Add Libary..."-> JUnit -> Next -> Finish_). Your project should now look like this picture:
+
+!(standard-image)images/sctu_project_before.png!
+
+
+h2. Create the statechart model
+
+Next, create a new statechart model by choosing _File -> New -> Other -> YAKINDU -> YAKINDU Statechart Model_. The wizard asks for the parent folder and we choose "CallHandling/model". Name the File CallHandling.sct and finish the wizard. Last, confirm the perspective switch with Yes. The statechart editor opens and show the definition of a very simple statechart. You should know how to create this statechart below (ref SCT help) :
+
+
+!(standard-image)images/sctu_example_final.png!
+
+
+h2. Create SCTUnit Test
+
+Now we create a "CallHandling.sctunit" file in the "tests" folder. In this example there are two tests, in the first test we accept the call and talk for 10s. In the second test we dismiss the call.
+
+!(standard-image)images/sctu_testcase.png!
+
+
+h2. Create Java-Code
+
+You cannot run the SCTUnit file directly, you have to generate Code first. In this tutorial we will generate Java code, but it's also possible to create C code. First of all we have to create a generator file for the tests. For this we create a new file in the folder "genmodel" and call it "tests.sgen".
+In this file you can specify what tests should be generated and where to. It looks like this:
+
+!(standard-image)images/sctu_sgentest.png!
+
+In Java we need also a statemachine which act like the statechart. For this we create another generator file which is called "model.sgen":
+
+
+!(standard-image)images/sctu_sgenstatemachine.png!
+
+You now have to create the Java code for both, tests and statemachine. Rightclick on the two generator files ("tests.sgen" and "model.sgen") and *generate the Statechart Artifacts*.
+
+
+!(standard-image)images/sctu_genArtifacts.png!
+
+After you did this, your project should look like this:
+
+!(standard-image)images/sctu_project_after.png!
+
+
+h2. Running the Test
+
+The most important reason to create something is to use it, so do we. For running the test you just have to rightclick on the "CallHandlingTest.java" file in the "test-gen" folder. Now the test should success like this:
+
+!(standard-image)images/sctu_junitSuc2.png!
+
+Grats, you just successfully created your first SCTUnit JUnit test. More details will be provided in the next chapter.
+h1. Details of SCTUnit
+
+
+h2. Creating a Test Group / Test Suite
+
+A SCTUnit file can contain a Test group or a Test Suite. In this chapter we introduce some useful details about the SCTUnit test files at all.
+
+h3. Test Group
+
+A Test Group is started by the keyword *testgroup* followed by the name of the Test Group. Further it's mandatory to define a statechart for which the test is written. This happens through the keywords *for statechart* followed by the Name of the statechart. The list of all possible statecharts is provided by *STRG+SPACE* (as seen on next picture).
+
+!(standard-image)images/sctu_strg_statechart.png!
+
+A Test group needs at least one test and a test needs at least one *enter* statement. It's not allowed to create more than one Test group per file. Following picture shows the minimum of a Test Group.
+
+!(standard-image)images/sctu_minimum_testgrp.png!
+
+h3. Test Suite
+
+In SCTUnit it is also possible to create Test Suites which contains a list of Test Groups that should be executed. Just create a Suite with the keyword *testsuite* followed by a name. Inside you can write the Test Groups you want to execute. In the picture below we have created another Test Group called "CallHandling2". As you can see the Test Groups are seperated by commas.
+
+!(standard-image)images/sctu_minimum_suite.png!
+
+h3. Namespaces
+
+It's not mandatory but you can use packages for your tests. This makes sense when you got a bunch of them. Write "namespace" followed by the name you wish. It's also possible to use full qualified names, look below:
+
+!(standard-image)images/sctu_namespace_sctunit.png!
+
+h2. SGen HowTo
+
+The Generator files (.sgen) are used to specify where the generated files are put. But SGen is not only used for this, you also can define many other attributes like for example a LiscenceHeader or debug information.
+
+A Generator file always starts with the keywords *GeneratorModel for* followed by the kind of generator and the subtype. With *STRG+SPACE* you get a list of possible Generators. As you can see there is not only SCTUnit:
+
+!(standard-image)images/sctu_sgen_generic.png!
+
+For a SCTUnit Generator we choose "sctunit::" followed by "java" for this example. This matches the "SCTUnit Generator for Java".
+
+!(standard-image)images/sctu_sgen_java_01.png!
+
+Further we need to define a test, started with the keyword "test". With *STRG+SPACE* we get again all possible entries:
+
+!(standard-image)images/sctu_sgen_java_04.png!
+
+For a test a "Outlet Feature" is mandatory, so we create it. The outlet feature got two attributes which also need to be defined: "target Project" and "targetFolder". There is a macro which can be used to create a default outlet feature.
+
+!(standard-image)images/sctu_sgen_java_02.png!
+
+The "targetProject" describes the Project in the actual Workspace where the test should be created. The default name is the project in which the file exist, but it's also possible to choose another project. For a better overview we change the default "targetFolder" from "src-gen" to "test-gen". This is not a must, just best practise, you can call the directory anything you want.
+
+!(standard-image)images/sctu_sgen_java_03.png!
+
+h3. Statemachine
+
+In java we also need a statemachine which is created in a similar way than the tests. We have to create another Generator file. Now we choose a *GeneratorModel for* for "yakindu::java".
+
+!(standard-image)images/sctu_sgen_yakindu_01.png!
+
+In this Generator file we have to add the stetechart for which the statemachine should be generated. With *STRG+SPACE* we get all possible entries, just like before in the Generator file for the tests. This artifact also need a outlet feature, so we use the macro as we seen before. We can keep the "src-gen" as "targetFolder" because we allready put the tests into "test-gen". The name of the folder is not a must, just best practise, you can call the directory anything you want.
+
+!(standard-image)images/sctu_sgen_yakindu_02.png!
+
+h2. Folders meaning
+
+Take a look at the following picture. There are many different folders. The following list gives an overview about the function of each.
+
+!(standard-image)images/sctu_project_after.png!
+
+* *src*: This is the default source folder, it's not used by SCTUnit.
+
+* *src-gen*: If you use SCTUnit for java this folder is used for the mandatory statemachine. You can change the name of this directory in the corresponding generator file.
+
+* *test-gen*: This folder is the output directory for the tests. It's the same in java and C. You can change the name of this directory in the corresponding generator file.
+
+* *genmodel*: This folder contents the Generator files. In java you need two Generator files (statemachine and tests), in C only one Generator file is used (tests). You can execute them by right clicking on them and use *Generate Statechartart Artifacts*.
+
+* *model*: In this directory the statecharts itself should be stored.
+
+* *tests*: This directory contains the SCTUnit files. A SCTUnit file can contain a Test group or a Test Suite.
+
+All names are recommendations, you can change them as you want.
+
++*Warning:*+ When *Generating Statechart Artifacts* the files in the target folder will be overwritten! Also the directory will not be cleaned from old code. So take care if you change a namespace or something else. Best practise is to delete the generated content in the target folder if you have any issues.
+
+
+h2. Reference
+
+h3. Test Group / Test Suite
+
+A SCTUnit file (*.sctunit*) can contain either a test group or a test suite. A test group contains one or more test cases. A test suite is a composite of tests groups.
+
+====
+
+h4. Testgroup
+
+A test group consists of one ore more tests (the namespace is not required and optionally splits the testgroups into packages). Further its possible to create a testsuite or testgroup. In this example we create a testgroup which needs a name and is used for an existing statechart, which is shown with the *for* keyword. A testgroup needs at least one *test* which needs at least one *enter* statement.
+
+Following example shows a minimal Test Group with namespace:
+
+bc(sctunit).
+testgroup MyExample for statechart SomeStatechart {
+ test firstTest{
+ enter
+ }
+}
+
+p. ====
+====
+
+h4. Testsuite
+
+A Test Suite also can contain a namespace, just as seen at Test Group. A Test Suite is made to hold a list of Test Groups. Following example shows a minimal Test Suite:
+
+bc(sctunit).
+testsuite MySuite{
+ TestGroup1,
+ Testgroup2
+}
+
+p. ====
+
+====
+
+h4. Test
+
+A Testgroup needs at least one test. A test is like a script with commands and asserts that are executed from above to bottom. A test must at least contain a "enter" statement. An example for a test is shown here:
+
+bc(sctunit).
+testgroup MyExample for statechart SomeStatechart {
+ test MyTest{
+ enter
+ raise exampleEvent1
+ cycle
+ assert active (StateName)
+ }
+}
+
+p. ====
+
+
+====
+
+h4(#namespace). Namespace
+
+It is optional possible to create namespaces. This namespaces work like packages. You can use full qualified names for a namespace.
+
+bc(sctunit).
+namespace my.namespace.is.here
+testgroup MyTestGroup{
+...
+}
+
+p. ====
+
+
+h3. Statements
+
+*SCTUnit* provides a list of statements that should be familiar for most programmers:
+
+====
+
+h4. assert
+
+The expression followed by the 'assert' keyword expects a boolean condition to be true, the test will fail otherwise. It is possible to add an optional message to the assertion statement to clarify the expressions intention. The following example shows a statement that asserts if a state is 'active' or not.
+
+bc(prettyprint). assert active(MyStatechart.regionName.StateName) "Expected StateName to be active"
+assert !active(MyStatechart.regionName.AnotherStateName)
+
+It is also possible to assert variable values. You can use any boolean comparator and its also possible to access variables in Interfaces and values of events:
+
+bc(prettyprint). assert myVariable1 == 42
+assert myVariable2 == "Sense of life"
+assert myVariable3 => 41
+assert InterfaceName.MyEvent == 5
+
+p. ====
+====
+
+h4. cycle
+
+Since SCTUnit does not make any assumptions on the the execution behavior of the statemachine, it is required to execute a cycle manually with the 'cycle' keyword.
+
+bc(prettyprint). cycle
+
+p. ====
+====
+====
+
+h4. enter / exit
+
+The 'enter' statements marks the entry of a statechart and is mandatory in every test. The 'exit' statement is only used if a statechart is leaved while the test is running.
+
+bc(prettyprint). enter
+exit
+
+====
+====
+====
+
+
+h4. raise
+
+With the 'raise' statement it is possible to raise in events. Since SCTUnit tests are considered as black-box-tests, it is only allowed to raise in-events. Internal and out-events are not raisable from SCTUnit.
+
+bc(prettyprint). raise myEvent
+raise MyInterface.myEvent
+
+====
+====
+====
+
+h4. if / else
+
+The 'if' statement works like in every other programming language. The only thing noticeable is, that the condition expression is surrounded by square brackets. The body must contain at least one statement.
+
+bc(prettyprint). if[variable1 > variable2]{
+ raise MyInterface.myEvent
+} else {
+ raise MyInterface.myEvent2
+}
+
+====
+====
+====
+
+h4. while
+
+The 'while' statement continually executes a block of statements while a particular condition evaluates to true. The while statement evaluates the conditional expression. If the expression is true, the while statement executes the statement(s) in the while body. The body must contain at least one statement.
+
+bc(prettyprint). while [value < 5] {
+ cycle
+ value=+1
+}
+
+====
+====
+
+
+h4. var
+
+SCTUnit supports the declaration of local variables. A variable can be declared with the 'var' statement, followed by an unique identifier and a type. Optionally, a default value can be specificed.
+
+bc(prettyprint). var myVar1 : integer
+var myVar2 : integer = 42
+var readonly const : string = "SCTUnit"
+var external ext : boolean = true
+
+====
+====
+
+h4. wait
+
+The 'wait' statement causes the currently executing test to sleep for the specified time interval. the following time units are supported: seconds (s), milliseconds (ms), microseconds (us) and nanoseconds (ns). This statement depends on the precision and accuracy of system timers and schedulers.
+
+bc(prettyprint). wait 500 ms
+wait 1000 us
+wait 10000 ns
+wait 5s
+
+====
+
+==
==
diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/50_simulating_statecharts.textile b/plugins/org.yakindu.sct.doc.user/src/user-guide/simulating_statecharts.textile
similarity index 87%
rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/50_simulating_statecharts.textile
rename to plugins/org.yakindu.sct.doc.user/src/user-guide/simulating_statecharts.textile
index 0237da64fe..1fcc326e1c 100644
--- a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/50_simulating_statecharts.textile
+++ b/plugins/org.yakindu.sct.doc.user/src/user-guide/simulating_statecharts.textile
@@ -5,7 +5,7 @@ Simulating a statechart model means to execute it, raise events manually, have t
You can run multiple state machines in parallel and even multiple instances of the same state machine.
-An introduction to simulation is given in section ""Simulating the light switch model"":20_tutorial#simulating-the-light-switch-model.
+An introduction to simulation is given in section ""Simulating the light switch model"":../tutorials/tutorials#simulating-the-light-switch-model.
h2(#starting-a-simulation). Starting a simulation
@@ -19,7 +19,7 @@ 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/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
@@ -85,7 +85,7 @@ When a transition is taken, the transition arc leading from the source state to
p(#oss_fig_the-sc-simulation-perspective).
-!(standard-image)images/light_switch_310_statechart_simulator_state_off.png(The _SC Simulation_ perspective)!
+!(standard-image)images/tuto_light_switch_310_statechart_simulator_state_off.png(The _SC Simulation_ perspective)!
p=. The _SC Simulation_ perspective
@@ -103,16 +103,16 @@ Depending on your screen resolution and font size settings, you might not be abl
"Figure "The SC Simulation perspective"":#oss_fig_the-sc-simulation-perspective is demonstrating this: The user has hovered the mouse pointer over a tab that is just displaying the starting letter 'S' of its title. However, a popup window right besides the pointer is showing the tab's full title "Simulation".
p(#oss_fig-simulation-view).
-!(standard-image)images/advsim_010_lightswitch_020_simulation.png(Simulation view)!
+!(standard-image)images/docu_advsim_010_lightswitch_020_simulation.png(Simulation view)!
p=. Simulation view – The actual _Simulation_ view is the pane right from the statechart editor.
h2(#controlling-a-simulation). Controlling a simulation
-* To terminate the simulation, click on the _Terminate_ button !(inlinemediaobject)images/symbol_terminate.png! or select _Run → Terminate_ in the main menu.
-* To suspend the simulation, click on the _Suspend_ button !(inlinemediaobject)images/symbol_suspend.png! or select _Run → Suspend_ in the main menu.
-* To resume a suspended simulation, click on the _Resume_ button !(inlinemediaobject)images/symbol_resume.png! or select _Run → Resume_ in the main menu.
-* Use the _Step Over_ button !(inlinemediaobject)images/symbol_stepover.png! or select _Run → Step Over_ in the main menu to execute a single run-to-completion step.
+* To terminate the simulation, click on the _Terminate_ button !(inlinemediaobject)images/docu_symbol_terminate.png! or select _Run → Terminate_ in the main menu.
+* To suspend the simulation, click on the _Suspend_ button !(inlinemediaobject)images/docu_symbol_suspend.png! or select _Run → Suspend_ in the main menu.
+* To resume a suspended simulation, click on the _Resume_ button !(inlinemediaobject)images/docu_symbol_resume.png! or select _Run → Resume_ in the main menu.
+* Use the _Step Over_ button !(inlinemediaobject)images/docu_symbol_stepover.png! or select _Run → Step Over_ in the main menu to execute a single run-to-completion step.
h2(#interacting-with-a-simulation). Interacting with a simulation
@@ -146,14 +146,14 @@ Section ""Creating and executing a launch configuration"":#oss_creatin
The present chapter describes how to create and configure a new launch configuration for a statechart simulation.
-# In the main menu, select _Run → Run Configurations…_. The _Run Configurations_ dialog appears. !(standard-image)images/launch_configuration_01.png(The _Run Configurations_ dialog)!
-# In the _Run Configurations_ dialog, right-click on _Statechart Simulation_ and select _New_ in the context menu. !(standard-image)images/launch_configuration_02.png(The _Run Configurations_ dialog)!Alternatively, you can select _Statechart Simulation_ and then click on the _New_ symbol near the top-left corner of the dialog. !(standard-image)images/launch_configuration_03.png(The _Run Configurations_ dialog)!
However you do it, a new launch configuration is created and displayed in the main area of the _Run Configurations_ dialog. The launch configuration's _Main_ tab is opened. +# In the main menu, select _Run → Run Configurations…_. The _Run Configurations_ dialog appears. !(standard-image)images/docu_launch_configuration_01.png(The _Run Configurations_ dialog)! +# In the _Run Configurations_ dialog, right-click on _Statechart Simulation_ and select _New_ in the context menu. !(standard-image)images/docu_launch_configuration_02.png(The _Run Configurations_ dialog)!
Alternatively, you can select _Statechart Simulation_ and then click on the _New_ symbol near the top-left corner of the dialog. !(standard-image)images/docu_launch_configuration_03.png(The _Run Configurations_ dialog)!
However you do it, a new launch configuration is created and displayed in the main area of the _Run Configurations_ dialog. The launch configuration's _Main_ tab is opened. # Enter the launch configuration's parameters as necessary: ** In the _Name_ text field, change the default name @New_configuration@ to something sensible, e. g. @Light switch@. ** In the _Model file_ text field, enter the path to the statechart model you want to simulate. Click on the _Search_ button to browse for statechart models. ** If your model uses Java operations, specify the Java class implementing those operations in the _Operation class_ text field. If you have multiple Java classes, specify them as a comma-separated list. ** Specify the _Execution type_ as being either _cycle-based_ (default) or _event-based_. In a _cycle-based execution_, the simulation performs a run-to-completion step in regular intervalls and processes the events that have occurred since the previous run-to-completion step. See the next field for the period of time between two consecutive run-to-completion steps. – In an _event-based execution_, the simulation performs a run-to-completion step each time an event occurs. _Please note: In contrast to the statechart simulation any generated code does not necessarily conform to the event-based execution semantics._ -** If the execution type is cycle-based, specify the period of time between two run-to-completion steps in the _Cycle time_ text field. If the execution type is event-based, this field is deactivated. !(standard-image)images/launch_configuration_04.png(The _Run Configurations_ dialog)! +** If the execution type is cycle-based, specify the period of time between two run-to-completion steps in the _Cycle time_ text field. If the execution type is event-based, this field is deactivated. !(standard-image)images/docu_launch_configuration_04.png(The _Run Configurations_ dialog)! bq.. *Note* diff --git a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/30_statechart_language.textile b/plugins/org.yakindu.sct.doc.user/src/user-guide/statechart_language.textile similarity index 93% rename from plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/30_statechart_language.textile rename to plugins/org.yakindu.sct.doc.user/src/user-guide/statechart_language.textile index 547d9ba1be..dce1815cf2 100644 --- a/plugins/org.yakindu.sct.doc.user/src/Part2-User-Guide/30_statechart_language.textile +++ b/plugins/org.yakindu.sct.doc.user/src/user-guide/statechart_language.textile @@ -36,7 +36,7 @@ h3(#region). Region As already mentioned, the YAKINDU statecharts are self-contained. They are organized in regions. Due to this it is possible to organize multiple state machines in different regions and to run them concurrently. -!(standard-image)images/parallelRegions.jpg(Parallel regions)! +!(standard-image)images/docu_parallelRegions.jpg(Parallel regions)! p=. Parallel regions @@ -48,7 +48,7 @@ h3(#transition). Transition A transition is the transfer of one state to another. Transitions are diagrammed as arrows. They can have events and actions, but don't need to. -The syntax of events and actions is defined by a "textual description language":#the-statechart-language. Please refer to section "Events":#events of this documentation for more details! For more details on actions please see chapter "Actions":#reaction-triggers. +The syntax of events and actions is defined by a "textual description language":#the-statechart-language. Please refer to "section "Events"":#events for more details. "Section "Reaction triggers"":#reaction-triggers has more on actions. If a state has more than a single outgoing transition without event, then among those transitions the one that has been modeled first will be carried out. @@ -61,7 +61,7 @@ An entry has a single outgoing transistion and no incoming ones. Its outgoing tr An entry is depicted as a filled circle, see "figure "Entry, exit, and final state"":#fig_state_entry_exit_final_explained. p(#fig_state_entry_exit_final_explained). -!(standard-image)images/state_entry_exit_final_explained.png(Entry, exit, and final state)! +!(standard-image)images/docu_state_entry_exit_final_explained.png(Entry, exit, and final state)! p=. Entry, exit, and final state @@ -86,7 +86,7 @@ Named entries have no equivalent in the UML. The sample statechart in "Figure "Entry state"":#fig_state_entry has a composite state named _Handle result_. This composite state has a default entry as well as an entry called _failure_. If state _A_ is active and the _error_ trigger fires, control is transitioned to the _Handle result_ composite state. The notation @error # >failure@ specifies that the _failure_ entry is to be used. p(#fig_state_entry). -!(standard-image)images/state_entry.png(Entry state)! +!(standard-image)images/docu_state_entry.png(Entry state)! p=. Entry state @@ -125,13 +125,13 @@ The order of exit and entry points in a transition specification is irrelevant. Alternatively, _Process_ could have been modeled with two different error exit states, say _error_1_ and _error_2_. This would allow to respond differently to different error conditions, while still enabling to catch them both with a single flow. A transition with @# >error_1 >error_2 problem>@ would do so. p(#fig_state_entry_exit). -!(standard-image)images/state_entry_exit.png(Entries and exits)! +!(standard-image)images/docu_state_entry_exit.png(Entries and exits)! p=. Entries and exits h3(#final). Final state -A _final state_ denotes the end of the execution flow of a state machine or region. See "section "Exit state"":#exit for a different way to terminate a composite state. +A _final state_ denotes the end of the execution flow of a state machine or region. See "section "Exit"":#exit for a different way to terminate a composite state. A final state is depicted as an unfilled circle with a smaller filled black circle inside, see "figure "Entry, exit, and final state"":#fig_state_entry_exit_final_explained. @@ -139,7 +139,7 @@ A final state can have multiple incoming transitions and has no outgoing ones. Within a region, only a single final state is allowed, but each region may have its own final state. -When a region reaches its final state, control stops there and waits until all other orthogonal regions, if any, have reached their respective final states, too. The semantics of final states is different from that of exits; please see "section "Exit state"":#exit for details. +When a region reaches its final state, control stops there and waits until all other orthogonal regions, if any, have reached their respective final states, too. The semantics of final states is different from that of exits; please see "section "Exit"":#exit for details. bq.. *Note* @@ -165,7 +165,7 @@ A synchronization state is shown as a thick horizontal or vertical line, as can p(#fig_state_synchronization). -!(standard-image)images/state_synchronization.png(Synchronization state)! +!(standard-image)images/docu_state_synchronization.png(Synchronization state)! p=. Synchronization state @@ -175,7 +175,7 @@ For a synchronization to actually join the incoming transitions and execute the * All guard conditions that are specified must be fulfilled. * If one or more triggers are defined, at least one trigger must fire at a point in time while the conditions above are met. -"Synchronization state":#fig_state_synchronization shows an sample statechart containing a forking and a joining synchronization. After having left the @Initialize@ state, the synchronization state forks the execution flow into two regions @r1@ and @r2@. Both are part of the @Process@ composite state and both are executed in parallel. That is, when activating @Process@, the substates @Line A 1@ and @Line B 1@ also become active. When the flows continues and both @Line A 2@ and @Line B 2@ have been reached, the synchronization state on the right-hand side joins the flows and transitions to substates @Cleanup@, making it the active state. However, as long as only one of them is active, the synchronization will wait for the other one to also become active before proceeding to @Process@. +"Figure "Synchronization state"":#fig_state_synchronization shows a sample statechart containing a forking and a joining synchronization. After having left the @Initialize@ state, the synchronization state forks the execution flow into two regions @r1@ and @r2@. Both are part of the @Process@ composite state and both are executed in parallel. That is, when activating @Process@, the substates @Line A 1@ and @Line B 1@ also become active. When the flows continues and both @Line A 2@ and @Line B 2@ have been reached, the synchronization state on the right-hand side joins the flows and transitions to substates @Cleanup@, making it the active state. However, as long as only one of them is active, the synchronization will wait for the other one to also become active before proceeding to @Process@. The example also demonstrates different lengths and orientations of the synchronization symbol. In the statechart editor, first select the synchronization symbol, the use a handle in one of the symbol's corners to change length or orientation. The handles in the middle of the symbol have no effect. @@ -191,7 +191,7 @@ h3(#orthogonal-states). Orthogonal states In the context of state machines orthogonal states are states that are independent of each other. The presumably most famous example is the keyboard example: -!(standard-image)images/orthogonalState_example.jpg(Orthogonal states)! +!(standard-image)images/docu_orthogonalState_example.jpg(Orthogonal states)! p=. Orthogonal states @@ -201,17 +201,17 @@ The shallow history state is a pseudo state that is placed inside regions of com The following example, showing the answering of a questionaire, explains this: -!(standard-image)images/shallowHistory01.jpg(Shallow history [1])! +!(standard-image)images/docu_shallowHistory01.jpg(Shallow history [1])! p=. Shallow history [1] Particularly interesting in this statechart are the events @checkProgress@ and @goon@. The event @checkProgress@ jumps back to the @init@ state while assigning the current progress count to the variable @temp@. The event @goon@ jumps to the shallow history state that was placed inside the composite state. -!(standard-image)images/shallowHistory02.jpg(Shallow history [2])! +!(standard-image)images/docu_shallowHistory02.jpg(Shallow history [2])! p=. Shallow history [2] -!(standard-image)images/shallowHistory03.jpg(Shallow history [3])! +!(standard-image)images/docu_shallowHistory03.jpg(Shallow history [3])! p=. Shallow history [3] diff --git a/plugins/org.yakindu.sct.doc.user/src/website/calltoaction.download.htmlf b/plugins/org.yakindu.sct.doc.user/src/website/calltoaction.download.htmlf new file mode 100644 index 0000000000..e005301128 --- /dev/null +++ b/plugins/org.yakindu.sct.doc.user/src/website/calltoaction.download.htmlf @@ -0,0 +1,10 @@ + + + +
+
+
+
+
diff --git a/plugins/org.yakindu.sct.doc.user/src/website/calltoaction.download.local.files.htmlf b/plugins/org.yakindu.sct.doc.user/src/website/calltoaction.download.local.files.htmlf
new file mode 100644
index 0000000000..d663f88cca
--- /dev/null
+++ b/plugins/org.yakindu.sct.doc.user/src/website/calltoaction.download.local.files.htmlf
@@ -0,0 +1,4 @@
+
+ 
\ No newline at end of file
diff --git a/plugins/org.yakindu.sct.doc.user/src/website/footer.htmlf b/plugins/org.yakindu.sct.doc.user/src/website/footer.htmlf
new file mode 100644
index 0000000000..b2ae4d9cca
--- /dev/null
+++ b/plugins/org.yakindu.sct.doc.user/src/website/footer.htmlf
@@ -0,0 +1,38 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+ {{ standard_footer_includes }}
+