Commit 13f179c6 authored by Kristof Szabados's avatar Kristof Szabados
Browse files

fixed some typos.


Signed-off-by: Kristof Szabados's avatarKristof Szabados <Kristof.Szabados@ericsson.com>
parent 4a8e95a3
......@@ -72,7 +72,7 @@ There are two ways to add files to a project. The first one, using wizards, is t
[[using-wizards-to-add-files-to-the-project]]
=== Using Wizards to Add Files to the Project
Wizards are available to create some of the TITAN modulesfootnote:[The terms "modules" and "files" are used interchangeably in this section.] (TTCN-3, ASN.1 and Configuration files). This functionality is reached by selecting *File / New* (see Figure 26 above).
Wizards are available to create some of the TITAN modules footnote:[The terms "modules" and "files" are used interchangeably in this section.] (TTCN-3, ASN.1 and Configuration files). This functionality is reached by selecting *File / New* (see Figure 26 above).
In the Project Explorer view, the wizards "TTCN-3 Module", "ASN.1 Module" and "Configuration file" can be reached by **right click**ing the content area and selecting *New / Other…* .
......@@ -457,7 +457,7 @@ image::images/4_F57.png[title="Remote build attributes"]
On this property page one or more hosts can be chosen to build the project remotely. The modalities of the remote build process on these hosts are also set.
To set the project properties for remote build first *right click* the projectand select *Properties* than select *Remote build* on the left pane(Figure 57). (If *Remote build* is missing from the left pane, *left click* the *⊞* sign next to the *TITAN Project Property*; see Figure 52.)
To set the project properties for remote build first *right click* the project and select *Properties* than select *Remote build* on the left pane(Figure 57). (If *Remote build* is missing from the left pane, *left click* the *⊞* sign next to the *TITAN Project Property*; see Figure 52.)
The checkbox *Execute the build commands in parallel* controls how the provided build commands should be executed.
......@@ -487,9 +487,9 @@ The *New…* button is used to create a new remote build host. It brings up the
image::images/4_F58.png[title="Remote build attributes of a host"]
The *Edit…* buttonis used to edit the attributes of an existing remote build host. Before pressing the button, the host to be edited must be selected from the table. By pressing the button, the remote build host configuration window (Figure 58) will appear, showing with the current properties of the selected host. Changes made to the host can be revoked by pressing the *Cancel* button, while modifying the host is done by pressing the *OK* button.
The *Edit…* button is used to edit the attributes of an existing remote build host. Before pressing the button, the host to be edited must be selected from the table. By pressing the button, the remote build host configuration window (Figure 58) will appear, showing with the current properties of the selected host. Changes made to the host can be revoked by pressing the *Cancel* button, while modifying the host is done by pressing the *OK* button.
The *Copy…* buttonis used to create a copy of an already existing host. Pressing this button will create an exact copy of the currently selected host. This way of creating a new host can be beneficial for example when the build command of the new host only slightly differs from the build command of the source host. Copying is abandoned by pressing the *Cancel* button, while it is confirmed by pressing the *OK* button.
The *Copy…* button is used to create a copy of an already existing host. Pressing this button will create an exact copy of the currently selected host. This way of creating a new host can be beneficial for example when the build command of the new host only slightly differs from the build command of the source host. Copying is abandoned by pressing the *Cancel* button, while it is confirmed by pressing the *OK* button.
The *Remove…* button is used to remove an existing host from list of remote build hosts. The command is abandoned by pressing the *Cancel* button, while it is confirmed by pressing the *OK* button.
......
......@@ -45,7 +45,7 @@ In Eclipse the fundamental difference to all previous systems is that in this ca
On one side this is a limitation, on the other side this means, that anyone can extend his projects with additional capabilities, either by developing his Eclipse extensions (for example a builder that converts some 3rd party file format into TTCN-3 files), or by using existing 3rd party tools (for example CDT for working with C/C++ and Makefiles, JDT for Java, documentation supporting tools, supporting writing command line scripts easier … and the list goes on).
The following ways of structuring are provided by Eclipsefootnote:[There is one more dimension of structuring in Eclipse when several plug-ins are used on the same project /_by default all plug-ins are active on all projects _/.If there are several plug-ins active in/on a given project, this can create several ``layers'' of responsibilities. This is an important feature, as this makes it possible to mix plug-ins that each provide some separate functionality into a working environment that best supports the user’s daily work routine. For example on a parallel cooperation the Designer supports editing TTCN-3, ASN.1 and configuration files, while CDT support editing C/C++ and Makefiles practically covering all aspects of working with TITAN by default. For an example of sequential cooperation we can say, that the working directory we use to output the final product of TITAN (the executable test system), can be viewed by CDT as the source of information for debugging/profiling the generated executable.]:
The following ways of structuring are provided by Eclipse footnote:[There is one more dimension of structuring in Eclipse when several plug-ins are used on the same project /_by default all plug-ins are active on all projects _/.If there are several plug-ins active in/on a given project, this can create several ``layers'' of responsibilities. This is an important feature, as this makes it possible to mix plug-ins that each provide some separate functionality into a working environment that best supports the user’s daily work routine. For example on a parallel cooperation the Designer supports editing TTCN-3, ASN.1 and configuration files, while CDT support editing C/C++ and Makefiles practically covering all aspects of working with TITAN by default. For an example of sequential cooperation we can say, that the working directory we use to output the final product of TITAN (the executable test system), can be viewed by CDT as the source of information for debugging/profiling the generated executable.]:
* Each file and folder below the project’s folder is part of the project, and by default should be used to operate the project. However, plug-ins working on the project can choose to ignore some of them on their own. For folders this is very much like file groups in mctr_gui, but in this case all files/folders in a given folder are part of that project by default.
......
......@@ -4,7 +4,7 @@
In this chapter a detailed, stepbystep procedure description is provided about how to build a project according to the workflow.
Building a project from the TTCN–3 or ASN.1 source modules and perhaps test port files is a procedure consisting of several steps. In the TITAN Designer plugin, the procedure is fully automated. The commands issued by the build related functionalities and their progress messages are displayed in the TITAN console, so the successful completion of the processes can easily be verified. Also, in case of an error, the analysis of the progress messages helps to find the cause of the problem (this is also automated to some extent; please refer <<7-editing_with_titan_designer_plugin.adoc#mark-occurrences, here>>). The build process also provides Eclipse with userfriendly information about its progress.
Building a project from the TTCN–3 or ASN.1 source modules and perhaps test port files is a procedure consisting of several steps. In the TITAN Designer plugin, the procedure is fully automated. The commands issued by the build related functionalities and their progress messages are displayed in the TITAN console, so the successful completion of the processes can easily be verified. Also, in case of an error, the analysis of the progress messages helps to find the cause of the problem (this is also automated to some extent; please refer <<7-editing_with_titan_designer_plugin.adoc#mark-occurrences, here>>). The build process also provides Eclipse with user friendly information about its progress.
The building process is automated; that is, the executable is updated in the background when project resources change (because they have been created, deleted or updated). There is no need for user interaction—provided that automatic building is enabled.
......@@ -52,7 +52,7 @@ This step, if needed, is carried out manually by the user.
=== Module Compilation
In this step C++ files are generated from virgin TTCN-3 and ASN.1 files. When a C++ file already exists, then the timestamp of the Compile file is used to decide whether a C++ file in question is uptodate or not. A C++ file is refreshed only if the corresponding TTCN–3 or ASN.1 module was modified later than the timestamp in the Compile file indicates, or the project was refreshed by *right clicking* the projectand selecting *Refresh*; otherwise the generated C++ file is considered uptodate.
In this step C++ files are generated from virgin TTCN-3 and ASN.1 files. When a C++ file already exists, then the timestamp of the Compile file is used to decide whether a C++ file in question is uptodate or not. A C++ file is refreshed only if the corresponding TTCN–3 or ASN.1 module was modified later than the timestamp in the Compile file indicates, or the project was refreshed by *right clicking* the project and selecting *Refresh*; otherwise the generated C++ file is considered uptodate.
The first compilation of the modules will result in addition of the following files in the working directory:
......@@ -266,7 +266,7 @@ NOTE: This file will only hold information relevant from the point of view of TI
After switching to a newer version of the test executor or simply to save disk space, the project might need to be cleaned by removing the generated files from the working directory.
To remove all generated files from the project, select *Clean* inthe *Project* menu option in Eclipse.
To remove all generated files from the project, select *Clean* in the *Project* menu option in Eclipse.
The following files will be deleted from the working directory:
......
......@@ -18,7 +18,7 @@ The TITAN Designer plugin includes editors for the following file types supporte
* Configuration (`.cfg`)
Additional file extensions can be associated to these editors by selecting the Eclipse menu point *Windows / Preferences / General / Editors / File Associations*, but this is discouraged for source files. Although the file will be wellcolored, the dynamic analyses will not work. For the same reason it is also discouraged to use the extensions listed above for other file types.
Additional file extensions can be associated to these editors by selecting the Eclipse menu point *Windows / Preferences / General / Editors / File Associations*, but this is discouraged for source files. Although the file will be well colored, the dynamic analysis will not work. For the same reason it is also discouraged to use the extensions listed above for other file types.
NOTE: The editors may throw an exception if a file is deleted while being edited.
......@@ -143,7 +143,7 @@ To define macros outside of files the Eclipse TITAN plug-in uses the settings gi
[width="100%",cols="m,",,]
|===
|#define MACRO_NAME <expression> |Define a macro, its value is the value of the integer expression
|#define MACRO_NAME <expression> |Define a macro, it’s value is the value of the integer expression
|#undef MACRO_NAME |Delete a macro
|#ifdef MACRO_NAME |The code in this branch is active if the macro `MACRO_NAME` was defined previously
|#ifndef MACRO_NAME |The code in this branch is inactive if the macro `MACRO_NAME` was defined previously
......@@ -164,7 +164,7 @@ NOTE: ttcnpp files are not analyzed incrementally even if incremental analysis i
=== Limitations
The on-the-fly parser does not support the single line comment in ASN.1 files when placed right after non-comment elements. A simple workaround for this problem is to insert a SPACE character between the last non-comment character and the "``" sign.
The on-the-fly parser does not support the single line comment in ASN.1 files when placed right after non-comment elements. A simple workaround for this problem is to insert a SPACE character between the last non-comment character and the "`—`" sign.
Limitations of preprocessing:
......@@ -237,7 +237,7 @@ The highest level of content assistance is available for TTCN-3 and ASN.1 files.
. From the smallest scope found the scope hierarchy is traversed in a bottom-up manner to find the possible definitions. (The definitions imported are checked after the definitions of the actual module).
. When a relevant definition is found the search for possible proposals continues inside its structure. For example, if the definition is a variable of a structured type, the reference is used to detect the subtypes or fields that the reference could point to if it were to be completed that way.
The proposals are ordered in the following way (definitions dont hide each other in the proposal list):
The proposals are ordered in the following way (definitions don’t hide each other in the proposal list):
. Dynamic elements available in the given scope. The elements are ordered by the distance of the element definition from the completion point in the scope hierarchy. For example, a local variable will always precede module definitions. The definitions that are most likely to be used are placed earlier in the list. If there is more than one proposal from the same scope, they are ordered alphabetically.
. Skeletons available in the given scope. The skeletons are ordered alphabetically.
......@@ -245,7 +245,7 @@ The proposals are ordered in the following way (definitions don’t hide each ot
=== Content Assistance Limitations
Full context sensitivity is not possible yet. Only the scopes and the type structures are used to filter the list of proposals. For this reason, the content assistant might offer completion proposals, which are possible in the actual scope but not in the actual context. It is the users task to choose the right proposal.
Full context sensitivity is not possible yet. Only the scopes and the type structures are used to filter the list of proposals. For this reason, the content assistant might offer completion proposals, which are possible in the actual scope but not in the actual context. It is the user’s task to choose the right proposal.
Only data gathered and stored by the on-the-fly parsers can be offered. If this data is outdated or not complete, the content assistance will also offer outdated or limited information. Section 3.1 explains how this can happen.
......@@ -274,7 +274,7 @@ Open Declaration works for TTCN-3 and ASN.1 modules and configuration files. For
Open configuration files listed in the include section. If the selected configuration file cannot be found the error is reported in the *TITAN Debug Console* and *the status line of Eclipse*.
Find module parameter declarations. If the module parameter is given as a module specific module parameter (e.g. `module.parameter`) only the given module is searched through for the declaration. Otherwise (e.g. `.parameter` or `parameter`) all modules of the project are taken into account. Duplicate module parameter declarations and errors are reported in the same way as for macro definitions.
Find module parameter declarations. If the module parameter is given as a module specific module parameter (e.g. `module.parameter`) only the given module is searched through for the declaration. Otherwise (e.g. `.parameter` or `parameter`) all modules of the project are taken into account. Duplicate module parameter declarations and errors are reported in the same way as for macro definitions.
[[find-references]]
== Find References
......@@ -297,7 +297,7 @@ type record MyRec {
...
var MyRec v_myrec;
...
v_myrec.rec.rec.rec.str := “foo”;
v_myrec.rec.rec.rec.str := “foo�;
----
Searching for field rec will give 3 hits in the above line, because the reference `v_myrec.rec.rec.rec.str` contains the identifier of the rec field 3 times.
......@@ -370,9 +370,9 @@ The graphical pages are explained in detail in the sections below.
=== Module Parameters Section
On this page (new) values can be assigned to parameters defined in the TTCN3 modules.
On this page (new) values can be assigned to parameters defined in the TTCN–3 modules.
A new parameter can be added by clicking the *Add* button. The column *Module name* contains the name of the module where the parameter is used. The parameter can be used in all modules when this column is left blank or filled with an asterisk. The column *Module parameter name* is self-explanatory. The value of the parameter is determined by the string in the pane *Module parameter details* in free form as parameters may have different formats.
A new parameter can be added by clicking the *Add…* button. The column *Module name* contains the name of the module where the parameter is used. The parameter can be used in all modules when this column is left blank or filled with an asterisk. The column *Module parameter name* is self-explanatory. The value of the parameter is determined by the string in the pane *Module parameter details* in free form as parameters may have different formats.
Highlighted existing parameters are removed by clicking the *Remove* button.
......@@ -386,7 +386,7 @@ Changes made to the parameters must be saved by the shortcut key *Ctrl+S*.
The values of all parameters on this page are passed to test ports.
A new parameter can be added by clicking the *Add* button. The column *Component name* contains the name of the component defining the test port. An asterisk (*) denotes all ports of the Test System Interface. The column *Test port name* is the name of the test port. The column *Parameter name* is self-explanatory. The value of the parameter is determined by the string in the pane *Test port parameter details* in free form as parameters may have different formats.
A new parameter can be added by clicking the *Add…* button. The column *Component name* contains the name of the component defining the test port. An asterisk (*) denotes all ports of the Test System Interface. The column *Test port name* is the name of the test port. The column *Parameter name* is self-explanatory. The value of the parameter is determined by the string in the pane *Test port parameter details* in free form as parameters may have different formats.
Highlighted existing parameters are removed by clicking the *Remove* button.
......@@ -420,7 +420,7 @@ The *Use of unix domain socket communication* field can turn on or off the usage
The aim of the *Components* table is to restrict component execution to certain (group of) hosts. These constraints are useful when distributed tests are executed in a heterogeneous environment. The participating computers may have different hardware setup, computing capacity or operating system.
A new restriction is added by clicking the *Add* button to the right of the first table. The column *Component name* contains component to be restricted. The column *Host name* contains either a host name, a group of hosts (see <<group-section, here>>) or an IP address of a host.
A new restriction is added by clicking the *Add…* button to the right of the first table. The column *Component name* contains component to be restricted. The column *Host name* contains either a host name, a group of hosts (see <<group-section, here>>) or an IP address of a host.
Highlighted components are removed by the button *Remove*.
......@@ -461,7 +461,7 @@ The field *End testcase* contains the path to the shell script executed after a
This table points out parts of the test suite to be executed. Only test cases having no parameters can be executed from this section.
A new test case is added by clicking the *Add* button to the right of the table. The column *Module name* contains the name of the module where the test case is defined. The column *Testcase* lists the test cases to be executed. An asterisk (*) denotes that all test cases in the given module must be executed.
A new test case is added by clicking the *Add…* button to the right of the table. The column *Module name* contains the name of the module where the test case is defined. The column *Testcase…* lists the test cases to be executed. An asterisk (*) denotes that all test cases in the given module must be executed.
Highlighted test cases are removed by the button *Remove*.
......@@ -479,7 +479,7 @@ Changes made to the parameters must be saved by the shortcut key *Ctrl + S*.
This table lists the configuration files to be imported. This way there is no need to merge configuration files when parameter definitions needed are dispersed over several files.
A new configuration file is imported by clicking the *Add* button to the right of the upper table. The column *File name* contains between quotation marks the name of the files to be imported.
A new configuration file is imported by clicking the *Add…* button to the right of the upper table. The column *File name* contains between quotation marks the name of the files to be imported.
Highlighted files are removed by the button *Remove*.
......@@ -489,7 +489,7 @@ The field *Total* under the buttons shows the number of the imported files.
This table contains macro definitions that can be used in other configuration file sections.
A new macro definition is added by clicking the *Add* button to the right of the lower table. The column *Definition* contains the macro name whereas the column *Definition value* contains the macro itself between quotation marks.
A new macro definition is added by clicking the *Add…* button to the right of the lower table. The column *Definition* contains the macro name whereas the column *Definition value* contains the macro itself between quotation marks.
Highlighted macros are removed by the button *Remove*.
......@@ -506,7 +506,7 @@ image::images/7_F101.jpg[title="Figure Logging"]
In the components and plug-ins section a tree of components and plug-ins can be created and managed.
On the first level of the tree components can be added using the _Add component_ button.Using the _Add plug-in_ button plug-ins can be added under each component on the second level of the tree.
On the first level of the tree components can be added using the _Add component…_ button.Using the _Add plug-in…_ button plug-ins can be added under each component on the second level of the tree.
Both component and plug-in names must be valid identifiers. The only exception is the "\*" component, this can be used to specify settings which are applied to all components and plug-ins.The "*" plug-in is automatically inserted; this can be used to specify settings which are applied to all plug-ins of the selected component. To specify settings for a specific component and plug-in one of the tree elements must be selected.
......@@ -525,15 +525,15 @@ Any component or plug-in can be deleted using the _Remove selected_ button.
`Seconds` results relative timestamps in format `s.microsec.`
*SourceInfoFormat* controls the appearance of the test event location information (position in the TTCN3 source code). The option can take one of the three possible values: `None`, `Single` and `Stack`. If set to `Single`, the location information of the TTCN3 statement is logged that is currently being executed. When `Stack` is used, the entire TTCN3 call stack is logged. The value `None` disables the printing of location information.
*SourceInfoFormat* controls the appearance of the test event location information (position in the TTCN–3 source code). The option can take one of the three possible values: `None`, `Single` and `Stack`. If set to `Single`, the location information of the TTCN–3 statement is logged that is currently being executed. When `Stack` is used, the entire TTCN–3 call stack is logged. The value `None` disables the printing of location information.
*AppendFile* controls whether the run-time environment shall keep the contents of existing log files when starting execution. The possible values are `Yes` or `No`. The default is No, which means that all events from the previous test execution will be overwritten.
*AppendFile* controls whether the run-time environment shall keep the contents of existing log files when starting execution. The possible values are `Yes` or `No`. The default is No, which means that all events from the previous test execution will be overwritten.
*LogEventTypes* can be useful for log post-filtering scripts. The possible values are `Yes`, `No`, `Detailed` and `Subcategories`. These values are explained in the section `LogEventTypes` of <<12-references.adoc#_4, [4]>>.
*LogEntityName:* if set to `Yes`, the name of the TTCN3 entity is indicated in the log file along with the file name and line number.
*LogEntityName:* if set to `Yes`, the name of the TTCN–3 entity is indicated in the log file along with the file name and line number.
*MatchingHints:* controls the verbosity of the logger regarding to template matching. The possible values are `Compact` and `Detailed`. The default is `Compact`, which shows the matched/unmatched fields of messages in a dot-separated notation. The Detailed version is similar to the former logging format. Its more verbose and preserves the message structures.
*MatchingHints:* controls the verbosity of the logger regarding to template matching. The possible values are `Compact` and `Detailed`. The default is `Compact`, which shows the matched/unmatched fields of messages in a dot-separated notation. The Detailed version is similar to the former logging format. It’s more verbose and preserves the message structures.
*Log file size* limits log file growth: when the file reaches the limit given in kilobytes, the log file is closed and a new one is opened with a different name. The naming scheme is explained in the section `LogFileSize` of <<12-references.adoc#_4, [4]>>.
......
......@@ -24,7 +24,7 @@ This document describes detailed information of using the TITAN Designer for the
== Copyright
Copyright (c) 2000-2018 Ericsson Telecom AB. +
All rights reserved. This program and the accompanying materialsare made available under the terms of the Eclipse Public License v2.0which accompanies this distribution, and is available at
All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v2.0 which accompanies this distribution, and is available at
https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html.
......
......@@ -45,8 +45,7 @@ The console shows all related information about build procedure, and execution.
+
This views are not part of the TITAN Executor, however, shows any Executor related information, for example, errors during a project build.
By default, the *Launch Commands* are enabled in this perspective, as shown in <<Figure-4,Figure 4>>. Only the *Run Configuration* is supported by the Executor plug-in.With this tool, new launch configurations can be created, or existing ones modified.
By default, the *Launch Commands* are enabled in this perspective, as shown in <<Figure-4,Figure 4>>. Only the *Run Configuration* is supported by the Executor plug-in. With this tool, new launch configurations can be created, or existing ones modified.
[[Figure-4]]
image::images/2_Figure4.png[title="Launch Commands"]
......@@ -11,11 +11,11 @@ image::images/3_Figure5.png[title="TITAN Executing perspective"]
The following options can be set on the TITAN Executor preferences page:
* **Set the default log folder.**The tests executed by the TITAN Executor will create the log files in the given folder.This option is enabled by default. This option is overridden if the `"FileName"` option is set in the `[LOGGING]` section of the runtime configuration file.
* **Set the default log folder.**The tests executed by the TITAN Executor will create the log files in the given folder. This option is enabled by default. This option is overridden if the `"FileName"` option is set in the `[LOGGING]` section of the runtime configuration file.
* **Delete log files before execution.**The log files in the default log folder will be deleted before each test execution. Files with `.log` extensions are considered to be log files. This option is only available if the default log folder has been set, by default it is disabled.If the files cannot be deleted, an error message will be displayed.
* **Delete log files before execution.**The log files in the default log folder will be deleted before each test execution. Files with `.log` extensions are considered to be log files. This option is only available if the default log folder has been set, by default it is disabled. If the files cannot be deleted, an error message will be displayed.
* **Merge the log files after test execution.**When the test execution is finished, the log files found in the default log directory will be merged into a single file.This option is available if the default log folder has been set, by default it is enabled.
* **Merge the log files after test execution.**When the test execution is finished, the log files found in the default log directory will be merged into a single file. This option is available if the default log folder has been set, by default it is enabled.
== TITAN Executor Project Properties
......@@ -23,4 +23,3 @@ To open project properties: *right click* the project and select *Properties*. +
On the project property page it is possible to override the workspace settings for the selected project.
image::images/3_Figure6.png[title="Executor property page"]
......@@ -119,7 +119,7 @@ On this page it is possible to set:
* The name of the project.
+
Please note that it is not important to provide the name of the project, it is only provided to support automatic filling of the other fields. If you enter the name of a valid project with TITAN nature (or select one by browsing, as can be seen <<Figure-13,below>>), having the needed build options set, then the fields of the working directory and the executable will be filled in automatically.The entered name is checked for validity.
Please note that it is not important to provide the name of the project, it is only provided to support automatic filling of the other fields. If you enter the name of a valid project with TITAN nature (or select one by browsing, as can be seen <<Figure-13,below>>), having the needed build options set, then the fields of the working directory and the executable will be filled in automatically. The entered name is checked for validity.
[[Figure-13]]
image::images/4_F13.png[title="Selecting a project"]
......@@ -130,11 +130,11 @@ In single mode the built executable and in Mctr_cli mode the Main Controller is
* The executable of the project.
+
Please note that this executable is used to fill in the list of testcases on the Testsets page, if you change the path, it will be re-checked, and the data for the Testsets page will be re-evaluated.The entered file path is checked for validity.
Please note that this executable is used to fill in the list of testcases on the Testsets page, if you change the path, it will be re-checked, and the data for the Testsets page will be re-evaluated. The entered file path is checked for validity.
* The path of the configuration file.
+
Please note that not only the existence but also the validity of the configuration file is evaluated here. If a problem was found while trying to process the configuration file, the launch process will be interrupted here.Please note that this evaluation is done every time this configuration page becomes active, meaning that switching to and from this page can take some time.The entered file path is checked for validity.
Please note that not only the existence but also the validity of the configuration file is evaluated here. If a problem was found while trying to process the configuration file, the launch process will be interrupted here. Please note that this evaluation is done every time this configuration page becomes active, meaning that switching to and from this page can take some time. The entered file path is checked for validity.
* Whether you wish to start executing the configuration file automatically when the launcher is started.
+
......@@ -315,11 +315,11 @@ With this option the maximum amount of notification messages, which can be kept
* Setting it to 0:
+
This means, that every notification message (console logs and error messages) will be kept available.Please note that in a lengthy execution, the amount of used memory might become very high.Please also note that the views refreshing speed might depend on the amount of elements, which need to be redrawn.
This means, that every notification message (console logs and error messages) will be kept available. Please note that in a lengthy execution, the amount of used memory might become very high. Please also note that the views refreshing speed might depend on the amount of elements, which need to be redrawn.
* Setting it to a positive number:
+
This means that the maximum amount of notification messages that are accessible will be around this amount. Please note that if older messages are not needed this is a good way to decrease memory requirements, and possibly increase execution speed.Please also note that the real amount of accessible notifications might somewhat exceed this threshold. This is because of performance reasons, as removing several elements at once is much faster than removing elements one by one.
This means that the maximum amount of notification messages that are accessible will be around this amount. Please note that if older messages are not needed this is a good way to decrease memory requirements, and possibly increase execution speed. Please also note that the real amount of accessible notifications might somewhat exceed this threshold. This is because of performance reasons, as removing several elements at once is much faster than removing elements one by one.
* Verdict extraction from notification messages:
+
......@@ -416,7 +416,7 @@ For us the two most important parts of this page are:
* The Save as region:
+
Here you can select a directory where the data of the launch configuration will be saved. The file will be named after the name of the launch configuration, with the extension "launch". Eclipse is automatically taking care of such files, if it finds such a file anywhere in the directories of the projects, it will be offered to the user.Please note that for this reason it is advised to put the launch configurations in the project’s directories. On this way if a project is closed, the launch configurations belonging to it won’t be displayed. +
Here you can select a directory where the data of the launch configuration will be saved. The file will be named after the name of the launch configuration, with the extension "launch". Eclipse is automatically taking care of such files, if it finds such a file anywhere in the directories of the projects, it will be offered to the user. Please note that for this reason it is advised to put the launch configurations in the project’s directories. On this way if a project is closed, the launch configurations belonging to it won’t be displayed. +
Please note that if you choose not to save the launch configuration it will still be saved, but to an internal point in Eclipse’s inner data hierarchies. output:
* Standard input and output:
......@@ -436,4 +436,3 @@ If this option is not set, then every time a new process is started it will eras
--
+
NOTE: In JNI mode launch the Standard input and output handling part is not supported.
......@@ -328,4 +328,3 @@ A solution can be to start Eclipse with the following command forcing the Java V
(This command must be executed in the directory where Eclipse was installed to)
* Execution in JNI mode is not supported on Windows
......@@ -24,7 +24,7 @@ This document describes detailed information of using the TITAN Executor for the
== Copyright
Copyright (c) 2000-2018 Ericsson Telecom AB. +
All rights reserved. This program and the accompanying materialsare made available under the terms of the Eclipse Public License v2.0which accompanies this distribution, and is available at
All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v2.0which accompanies this distribution, and is available at
https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html.
......@@ -52,4 +52,4 @@ include::4-launching_the_test_suite.adoc[]
include::5-executing_and_controlling_the_execution_of_test_su.adoc[]
include::6-other_available_functions.adoc[]
include::7-references.adoc[]
endif::[]
\ No newline at end of file
endif::[]
......@@ -46,7 +46,7 @@ The TitaniumRefactoring tool is an Eclipse plug-in, extending the TITAN Designer
The TitaniumRefactoring plug-in is extending the TITAN Designer plug-in, which is an implementation of TTCN–3 Core Language standard (<<_3, [3]>>), supporting of ASN.1 language (<<_4, [4]>>).
The limitations present in the Designer plug-in also apply here: there are TTCN–3 language constructs which are not yet supported in the current version, while there are also some non-standard extensions implemented by TITAN.Information on these limitations and extensions and also some clarifications of how the standard has been implemented in TITAN, can be found in the <<_2, TITAN Programmer’s Technical Reference>>.
The limitations present in the Designer plug-in also apply here: there are TTCN–3 language constructs which are not yet supported in the current version, while there are also some non-standard extensions implemented by TITAN. Information on these limitations and extensions and also some clarifications of how the standard has been implemented in TITAN, can be found in the <<_2, TITAN Programmer’s Technical Reference>>.
== Intended audience
......
......@@ -45,7 +45,7 @@ The Titanium tool is an Eclipse plug-in, built upon the TITAN Designer for the E
Titanium extends the already existing feature of the Designer with higher level code analysis features such as:
* Detecting and reporting code smellsfootnote:[Code smells are described in Wikipedia as: "In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem. Code smells are usually not bugs—they are not technically incorrect and don't currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future."] in TTCN-3 and ASN.1 source codes;
* Detecting and reporting code smells footnote:[Code smells are described in Wikipedia as: "In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem. Code smells are usually not bugs—they are not technically incorrect and don't currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future."] in TTCN-3 and ASN.1 source codes;
* Measuring and displaying code quality metrics on TTCN-3 source codes;
* Extracting and displaying an architectural overview of the projects;
......@@ -158,7 +158,7 @@ image::images/3_F1.png[title="Code smell preferences"]
Code smells are indicators of suspicious code that is not erroneous (i.e. the code compiles), but most of the times they are not preferable. In this preference page, one can control the way of reporting the available code smells.
The first item on this page is the option to enable on-the-fly processing. When this option is enabled the code smells will be checked immediately after whenever the Designer’s on-the-fly analyser executes.When this option is disabled the code smells have to be explicitly requested by the *Check code for code smells* action on the menu bar.
The first item on this page is the option to enable on-the-fly processing. When this option is enabled the code smells will be checked immediately after whenever the Designer’s on-the-fly analyser executes. When this option is disabled the code smells have to be explicitly requested by the *Check code for code smells* action on the menu bar.
The reporting level of all code smells is configurable to be *Ignore*, *Warning* or *Error*. Code smells set to be reported as *Ignore* will not be analysed and reported. Code smells configured to be reported as *Warning* or *Error* will be reported with that severity level.
......@@ -277,12 +277,12 @@ This page gives a short overview about the following subpages that are related t
== Metric limits preferences
image::images/3_F6.png[title="Metric limits"]
This page provides the possibility of fine-tuning the metric highlight mechanism.Metrics generally work as follows:
This page provides the possibility of fine-tuning the metric highlight mechanism. Metrics generally work as follows:
* A metric calculates a concrete value for the measured entity (for example, the *`Number of functions`* metric counts the number of functions in a TTCN3 module.
* When set, classifies this value as *NO*, *LOW* or *HIGH* risk.
Some metrics have default pre-set limits, but here they can be customized.First, a method of warning has to be selected:
Some metrics have default pre-set limits, but here they can be customized. First, a method of warning has to be selected:
* *Never warn:* the metric will never classify anything as "suspicious". In the Metrics View, in the Top Riskiest Modules View and in the Module Graph View this metric will show everything in *green* colour.
* *Low risk:* the metric will classify entities to be "a bit suspicious", if the measured value is above a set limit. These entities will be shown in *yellow* colour.
......@@ -463,7 +463,7 @@ Clicking the New or Edit buttons will bring up a dialog window, where you can se
The Titanium plug-in offers several commands which can be called in headless mode. This way it can be used from command line, and for example integrated into nightly build systems.
In headless mode eclipse plug-ins can offer entry point, called applications, through which the user is able to invoke functionalities of the plug-in without starting the graphical interface of Eclipse.In this mode everything is working exactly the same way as it is when invoked from the graphical user interface, but there are no windows popping up, no user interaction.
In headless mode eclipse plug-ins can offer entry point, called applications, through which the user is able to invoke functionalities of the plug-in without starting the graphical interface of Eclipse. In this mode everything is working exactly the same way as it is when invoked from the graphical user interface, but there are no windows popping up, no user interaction.
NOTE: As in this mode there is no interaction between eclipse and the user, all of the settings should be set beforehand. Otherwise the operation might not be able to work properly, or produce un-expected result.
......@@ -610,7 +610,7 @@ The entry points can be invoked as:
[source,subs="+quotes"]
*eclipse.exe -noSplash -data c:\Users\ekrisza\runtime_headless -application org.eclipse.titanium.applications.SaveGraph c:\ekrisza\temporal\TitanSim\NightlyGraphs_*
These entry points take one obligatory parameter: the prefix of the output path.This prefix will be appended with the name of the project and the ".net"/�.dot� ending, creating a separate output file for every project. This parameter must be the first parameter of the application
These entry points take one obligatory parameter: the prefix of the output path. This prefix will be appended with the name of the project and the ".net"/�.dot� ending, creating a separate output file for every project. This parameter must be the first parameter of the application
The second optional parameter is the clustering parameter. A clusterer algorithm maybe set to export cluster graph and not the original module graph. This parameter can be provided by a "_–c<algorithm_name>_" parameter, for example:
......@@ -710,7 +710,7 @@ The file containing the setting can be downloaded from https://sharepoint.ericss
image::images/6_F20.png[title="The preference importation wizard selected"]
In the window that pops up select the file that was just downloaded. As this file only contains settings for the *Problems* view both selecting the configuration, and selecting to *Import all* will lead to the loading of the contents.To finish the procedure the *Finish* button has to be selected, and after eclipse loads the settings, the configurations will automatically appear in the *Problems* view.
In the window that pops up select the file that was just downloaded. As this file only contains settings for the *Problems* view both selecting the configuration, and selecting to *Import all* will lead to the loading of the contents. To finish the procedure the *Finish* button has to be selected, and after eclipse loads the settings, the configurations will automatically appear in the *Problems* view.
image::images/6_F21.png[title="Import preferences selector"]
......@@ -889,7 +889,7 @@ The metric popup window can be opened by right clicking on a selected node
image::images/10_F31.png[title="The info window and a selected node"]
The edges belonging to *c* are drawn red, and all the other edges are drawn very soft, grey. This feature visualizes the neighbours of a given node.In the metrics window the *Number of functions* metric is selected in the metrics menu (see Figure 31). The colour of the row in this view is the same as the selected node’s colour, which represents how bad it was according to the selected metric
The edges belonging to *c* are drawn red, and all the other edges are drawn very soft, grey. This feature visualizes the neighbours of a given node. In the metrics window the *Number of functions* metric is selected in the metrics menu (see Figure 31). The colour of the row in this view is the same as the selected node’s colour, which represents how bad it was according to the selected metric
=== Menu functions
......@@ -1009,7 +1009,7 @@ In the clustering menu the following clustering methods can be chosen:
* *By linked file location:* The modules will be grouped by their absolute path on the file system.
* *By module location:* Modules contained in eclipse folders will be grouped by their relative path, while modules contained in linked resources will be grouped by their full path.
* *Using regular expressions:* The modules will be grouped by matching the module name to the regular expressions given on the _Graph/Clusters/Using regular expressions_ preference page. See <<clustering-using-regular-expressions-preferences, here>>.
* *Automatically:* First the other methods will be used to create an initial clustering. Then they will be improved and the best one displayed. The clustering achieved tries to better reflect the structure of the project.For details on how the algorithm works, see <<_6, [6]>>.
* *Automatically:* First the other methods will be used to create an initial clustering. Then they will be improved and the best one displayed. The clustering achieved tries to better reflect the structure of the project. For details on how the algorithm works, see <<_6, [6]>>.
* *By module names:* This algorithm results in a hierarchical grouping. The module names will get to separate clusters according their main part (for example prefix name), then get to more accurate subgroups according their secondary name, and so on. In case of using this algorithm in grouping mode you only get separate groups according to the prefixes of the modules. If you use this algorithm with cluster graph you will see the whole hierarchy from the level of the main module names down to the actual module names. The subgroup separator here is determined according to the most usual symbols (“_� sign, Upper case, etc.).
NOTE: In case of using this algorithm with cluster graph you will automatically change to General Directed Graph layout. This selection naturally can be change through the *Layout* menu. After changing back to the original graph you will again get an ISOM layout.
......
......@@ -278,9 +278,9 @@ addField(b1);
==== Using parameters
It is also possible to ask for parameters from the user on this page. In which case the parameter must also be a preference setting, and have a place on the preference window, preferably next to its main option.Please don’t forget to provide a default value for each parameter, so that the code smell can work out of the box if needed.
It is also possible to ask for parameters from the user on this page. In which case the parameter must also be a preference setting, and have a place on the preference window, preferably next to its main option. Please don’t forget to provide a default value for each parameter, so that the code smell can work out of the box if needed.
In the following example we would like to have a minimum length for identifiers. This threshold has a default value, but it should be changeable by the user.Figure 1 shows a sample window, consisting of all the parameters which are responsible for the minimum lengths of the identifiers. The default value is 4, but the user can change the threshold values any time here.
In the following example we would like to have a minimum length for identifiers. This threshold has a default value, but it should be changeable by the user. Figure 1 shows a sample window, consisting of all the parameters which are responsible for the minimum lengths of the identifiers. The default value is 4, but the user can change the threshold values any time here.
image::images/2_F1.png[title="Preferences window with user parameters"]
......@@ -385,7 +385,7 @@ For the graph building (generation) we use *`GraphGenerator`*, this class implem
After this step the editor window takes back the control, and displays the graph through JUNG API. Because of synchronization issues the editor doesn’t wait for the generator, the generator can set a new graph and thus launch the process of display through a method call on the inherited *`SetGraph()`* method. Here the most important steps are the following:
. Handling of *`DrawArea`* (this is a Swing component that displays the graph).
. Handling of *`SatelliteView`* (this is handled through a refrence).
. Handling of *`SatelliteView`* (this is handled through a reference).
As Jung is compatible with Java AWT (it finally returns a subclass of AWT *`Component`*), we add everything to these two swing objects.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment