Comprehensive checker rule listing More...

Classes
class	Severity
	Severity of the checker rule. More...

Public Attributes
Severity.Warning	Core_Chk001
	Document name matches file name More...

Severity.Critical	Core_Chk002
	Package-wide uniqueness of document names More...

Severity.Critical	Core_Chk003
	No dead import links More...

Severity.Warning	Core_Chk004
	No unused imports More...

Severity.Critical	Core_Chk005
	No use of undefined import prefixes More...

Severity.Warning	Core_Chk006
	Match of imported document's data model version More...

Severity.Warning	Core_Chk007
	Have specification if no realisation exists More...

Severity.Critical	Core_Chk008
	Public main procedure More...

Severity.Critical	Core_Chk009
	Mandatory constant initialisation More...

Severity.Warning	Core_Chk010
	Unique node names More...

Severity.Warning	Core_Chk011
	No disabled nodes More...

Severity.Warning	Core_Chk012
	No unreachable realisations in Action and Group nodes More...

Severity.Critical	Core_Chk013
	Correct referencing of validities More...

Severity.Critical	Core_Chk014
	Correct locator variable type in for-each-loop More...

Severity.Critical	Core_Chk015
	Correct nesting of Parallel nodes More...

Severity.Warning	Core_Chk016
	No redundant exception catches More...

Severity.Warning	Core_Chk017
	Checked exceptions (1) More...

Severity.Warning	Core_Chk018
	Checked exceptions (2) More...

Severity.Critical	Core_Chk019
	Type-safe exception catches More...

Severity.Critical	Core_Chk020
	Correct nesting of Continue node More...

Severity.Critical	Core_Chk021
	Correct nesting of Break node More...

Severity.Critical	Core_Chk022
	Correct nesting of TerminateLanes node More...

Severity.Critical	Core_Chk023
	Type-safe assignments More...

Severity.Critical	Core_Chk024
	Correct target for ProcedureCall More...

Severity.Warning	Core_Chk025
	Procedure signature has at least one implementing procedure More...

Severity.Warning	Core_Chk026
	No duplicate validities for procedures implementing the same signature More...

Severity.Critical	Core_Chk027
	Procedure parameters match signature parameters More...

Severity.Warning	Core_Chk028
	No Operation (NOP) ProcedureCall More...

Severity.Critical	Core_Chk029
	Correct ProcedureCall arguments More...

Severity.Critical	Core_Chk030
	Input- and in&output-argument omission More...

Severity.Critical	Core_Chk031
	Type-safe ListConcatenate More...

Severity.Critical	Core_Chk032
	Type-safe ListAppendItems More...

Severity.Critical	Core_Chk033
	Type-safe ListInsertItems More...

Severity.Warning	Core_Chk034
	No use of init in list item type definition More...

Severity.Critical	Core_Chk035
	ListLiteral item type matches list declaration item type More...

Severity.Critical	Core_Chk036
	ListLiteral and ListCreate item types follow item type definition More...

Severity.Critical	Core_Chk037
	ListLiteral items are literal terms More...

Severity.Critical	Core_Chk038
	Type-safe MapPutItems More...

Severity.Critical	Core_Chk039
	Type-safe MapRemoveItems More...

Severity.Critical	Core_Chk040
	Type-safe MapContainsKey More...

Severity.Critical	Core_Chk041
	Type-safe MapContainsValue More...

Severity.Critical	Core_Chk042
	Type-safe MapUnion More...

Severity.Critical	Core_Chk043
	Unique keys in MapLiteral More...

Severity.Warning	Core_Chk044
	No use of init in map key type definition More...

Severity.Warning	Core_Chk045
	No use of init in map value type definition More...

Severity.Warning	Core_Chk046
	MapLiteral key&value types match map declaration key&value types More...

Severity.Critical	Core_Chk047
	MapLiteral and MapCreate key/value types follow key/value type definition More...

Severity.Critical	Core_Chk048
	MapLiteral items are literal terms More...

Severity.Critical	Core_Chk049
	Uniform relation operand type More...

Severity.Critical	Core_Chk050
	Type-safe variable and constant usage More...

Severity.Critical	Core_Chk051
	Immutability of constants, input parameters and context variables More...

Severity.Warning	Core_Chk052
	Identifier shadowing More...

Severity.Critical	Core_Chk053
	No dangling OtxLink associations More...

Severity.Warning	Core_Chk054
	Unused declarations More...

Severity.Critical	Core_Chk055
	Unreachable nodes More...

Severity.Critical	Core_Chk056
	No modification of collection inside foreach-loops More...

Severity.Warning	Core_Chk057
	No use of init in catch header exception type definition More...

Severity.Critical	Core_Chk058
	Unique OtxIds More...

Severity.Critical	Core_Chk059
	Type-safe ListContainsValue More...

Severity.Deprecation	Core_Chk060
	Usage of deprecated elements More...

Severity.Information	Core_Chk061
	Usage of util:Compare instead of IsEqual and IsNotEqual More...

Severity.Information	Core_Chk062
	Usage of string:Decode instead of ToString for ByteFields More...

Severity.Critical	Core_Chk063
	Locator or Value in for-each-loop More...

Severity.Critical	Core_Chk064
	Correct value variable type in for-each-loop More...

Severity.Critical	Core_Chk065
	No reading of state variables across documents More...

Severity.Critical	Core_Chk066
	Correct referencing of MutexLocks More...

Severity.Warning	Core_Chk067
	Procedure is visible from the implementing signature More...

Detailed Description

Comprehensive checker rule listing

To ensure OTX document quality and correctness, the OTX checker uses a two-stage approach:

The first stage is standard XML Schema validation which makes sure that the document is correct with respect to the XML grammar constraints given by the OTX Schema(s). The scope of validation is always on a single document, interdependencies in between documents are not resolved. A document failing this test is invalid and will not enter the second stage.
The second stage is needed for testing constraints that standard XML Schema validation cannot verify. Typical constraints which fall into this category are constraints of semantic and not of syntactic nature (e.g. cross-document interdependencies, like a procedure call into another OTX document, or co-occurrence interdependencies between elements which reside in entirely separate regions of the document, like a variable declaration in the declaration block and its use in a procedure flow etc.). An OTX document or a set of documents that pass the second stage is considered as standard conform.

The checker rules for the second stage are listed in the following.

Note: In addition to syntactic and semantic correctness, real standard-compliant interchangeability also includes completeness and target system independence!

Member Data Documentation

◆ Core_Chk001

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk001

Document name matches file name

Criterion: For OTX documents stored in a file system, the attribute name of the <otx> root element should match the filename of the containing file (without the extension ".otx").

Comment: For other document management systems (e.g. a OTX data base system), this rule is irrelevant. Here, the combination of package and document name represents a primary key for unambiguous document identification.

◆ Core_Chk002

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk002

Package-wide uniqueness of document names

Criterion: The value of the <otx> attribute name must be unique within the scope of all OTX documents belonging to the same package.

◆ Core_Chk003

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk003

No dead import links

Criterion: Imported OTX documents (referenced by package name and document name via <import> elements) should exist and should be accessible.

◆ Core_Chk004

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk004

No unused imports

Criterion: An imported OTX document should be used at least once in the importing document.

Comment: This avoids needless dependencies (imports of documents which are never used).

◆ Core_Chk005

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk005

No use of undefined import prefixes

Criterion: If an imported name is accessed by prefix in an OtxLink type attribute, the corresponding prefix definition has to exist in an <import> element.

◆ Core_Chk006

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk006

Match of imported document's data model version

Criterion: An imported OTX document (imported by an <import> element) shall be bound to the same data model version as the importing document. For this, the OTX XSD namespaces claimed by the <otx> root elements of both documents (attribute xmlns="http://iso.org/OTX/<version>") shall be identical.

◆ Core_Chk007

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk007

Have specification if no realisation exists

Criterion: For all elements with specification and realisation parts in an OTX document: if there is no <realisation> given, the according <specification> element should exist and have content (no empty string).

Comment: This aims towards gaining better documentation quality in OTX documents. Authors should at least provide a specification text if the realisation parts are not yet implemented.

◆ Core_Chk008

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk008

Public main procedure

Criterion: The value of <procedure> attribute visibility shall always be "PUBLIC" if the procedure name is "main".

◆ Core_Chk009

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk009

Mandatory constant initialisation

Criterion: Constant declarations will always be initialised.

Comment: Usually, non-initialised constants are the result of an author mistake – the author might just have forgotten to initialise the constant.

◆ Core_Chk010

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk010

Unique node names

Criterion: The value of a nodes name attribute should be unique among all nodes in a procedure.

◆ Core_Chk011

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk011

No disabled nodes

Criterion: A procedure should not contain any disabled nodes any more before it is rolled out (disabled attribute in Node types).

◆ Core_Chk012

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk012

No unreachable realisations in Action and Group nodes

Criterion: In a single Action or Group node, the values of the validFor attributes of all <realisation> elements should be distinct. Also, after a <realisation> without validFor attribute, no further <realisation> elements should exist.

Comment: This avoids that e.g. two realisations are connected to the same validity information which would result in unreachable code: The realisation which comes second-in-sequence is never executed. The same is true for realisations following a default realisation. Usually, unreachable code is an indicator for possible inconsistencies in the code. This rule helps identifying some of these problems.

◆ Core_Chk013

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk013

Correct referencing of validities

Criterion: The validFor attribute (in types Procedure, ActionRealisation, GroupRealisation) and the validity attribute (IsValid term) shall refer to a visible validity term, Boolean context variable or global Boolean constant only.

◆ Core_Chk014

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk014

Correct locator variable type in for-each-loop

Criterion: The locator variable used in for-each-loops shall be of the correct type: If the collection of the for-each-loop is a ListTerm, then the data type shall be Integer. If the collection is a MapTerm, the data type needs to match the key data type (Countable) of the map produced by the term.

Comment: To identify the key data type of the (potentially compound) MapTerm, the leaves of the term have to be analyzed. Possible leaves are MapValue, MapLiteral or MapCreate.

◆ Core_Chk015

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk015

Correct nesting of Parallel nodes

Criterion: If the nested Parallel lanes (optional) feature is not supported: Parallel nodes shall not contain other Parallel nodes. (In XML wording: A <parallel> element shall not be the descendant of another <parallel> element).

◆ Core_Chk016

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk016

No redundant exception catches

Criterion: In a <handler>, only one <catch> flow for one exception type should exist.

Comment: When this check fails, the author probably implemented an incorrect exception handling. The procedure might work nonetheless.

◆ Core_Chk017

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk017

Checked exceptions (1)

Criterion: Every unhandled checked exception that is to be expected in a procedure should be declared in that procedures <throws> declaration.

Comment: The only checked exceptions in OTX Core are the explicit exception UserException and its base type Exception. These may be thrown when calling a procedure which defines UserException or Exception in its throws-attribute, or by a Throw node. In these places (ProcedureCall action or Throw node), the checker should provide a warning message, if not listed in throws. When this check fails, the author probably implemented an incomplete exception handling. The procedure might work nonetheless.

Example: namespace ExpectedExceptionsPackage1

{

public procedure main()

{

Exception exception1;

try

{

// A procedure which throws a checked exception should be inside an error handler and the error handler should handle this exeption

ProcedureWhichThrowsAnException();

}

catch (Exception exception1)

{

HMI.ConfirmDialog(GetExceptionText(exception1), GetExceptionQualifier(exception1), @MessageType:ERROR);

}

}

private procedure ProcedureWhichThrowsAnException() throws UserException

{

Exception exception1;

Integer variable;

try

{

// Division by zero will throw an ArithmeticException

variable = variable/0;

}

catch (Exception exception1)

{

// The ArithmeticException is mapped to a UserException

throw UserExceptionCreate(GetExceptionQualifier(exception1), GetExceptionText(exception1));

}

}

}

◆ Core_Chk018

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk018

Checked exceptions (2)

Criterion: Every node which possibly throws a checked exception should be embedded in a Handler providing a <catch> applicable to that exception type, but only if the procedure does not already declare that explicit exception type in its throws-attribute (see Core_Chk017).

Comment: The only checked exceptions in OTX Core are the explicit exception UserException and its base type Exception. These may be thrown when calling a procedure which defines UserException or Exception in its throws-attribute, or by a Throw node. In these places (ProcedureCall action or Throw node), the checker should provide a warning message, if not handled. When this check fails, the author probably implemented an incomplete exception handling. The procedure might work nonetheless.

◆ Core_Chk019

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk019

Type-safe exception catches

Criterion: In the CatchHeader of a <catch> block, the data type of the to-be-caught exception (given by the <type> element) shall match or is a subtype of the type of the handle variable (given by the <handle> element).

Comment: This makes sure that a caught exception cannot be assigned to a variable of another exception type. The data type of the handle is defined in the declaration block.

◆ Core_Chk020

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk020

Correct nesting of Continue node

Criterion: The Continue node has to be nested inside of the targeted Loop (In XML wording: the <continue> element has to be a descendant of the targeted <loop> element). In the special case that a Continue node is nested inside of a Parallel node, the targeted Loop node has to be nested inside of the same Parallel node, too.

◆ Core_Chk021

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk021

Correct nesting of Break node

Criterion: The Break node has to be nested inside of the targeted Loop (In XML wording: the <break> element has to be a descendant of the targeted <loop> element). In the special case that a Break node is nested inside of a Parallel node, the targeted Loop node has to be nested inside of the same Parallel node, too.

◆ Core_Chk022

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk022

Correct nesting of TerminateLanes node

Criterion: A TerminateLanes node has to be nested inside of a Parallel node (In XML wording: the <terminateLanes> element has to be a descendant of a <parallel> element).

◆ Core_Chk023

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk023

Type-safe assignments

Criterion: In an Assignment action, the data type of the variable (identified by the <result> element) shall correspond to the data type of the value (given by <term>). Automatic type promotion has to be taken into account which allows assigning an Integer to a Float without explicit cast.

Comment: This ensures that e.g. a StringTerm value cannot be assigned to an Integer variable.

Comment

Type inference shall be supported in any depth.

This shall be handled for Numeric Terms , List Terms and Map Terms, thus the assignment of
Integer myIntegerVar = Add(Multiply(2,3),1); is valid, while the assignment of
Integer myIntegerVar = Add(Multiply(2,3.0),1); is invalid.
List<String> MyStringList = StringUtil.SplitString("Hallo world", " "); is valid
List<Integer> MyIntegerList = StringUtil.SplitString("1 2", " "); is invalid

◆ Core_Chk024

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk024

Correct target for ProcedureCall

Criterion: A ProcedureCall action's procedure attribute shall refer to a Procedure, a Signature without realisation or a Signature with ProcedureSignature realisation. No other SignatureRealisation type but the ProcedureSignature type shall be allowed.

Comment: This avoids situations where a ProcedureCall misleadingly calls e.g. an HMI ScreenSignature which has a totally different purpose.

◆ Core_Chk025

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk025

Procedure signature has at least one implementing procedure

Criterion: For each procedure signature called by a ProcedureCall action at least one implementing procedure should exist which is visible relative to the signature.

Comment: Missing implementation procedures are usually a hint for possible inconsistencies in the code. Most often it was simply forgotten to implement the signature.

◆ Core_Chk026

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk026

No duplicate validities for procedures implementing the same signature

Criterion: The values of the validFor attributes of all procedures implementing the same signature should be distinct.Also, there should only be one implementing procedure without validFor attribute.

Comment: This avoids that e.g. two procedures are connected to the same validity information which would result in unreachable code: One of these procedures will never be executed, even though it is valid also. Usually, unreachable code is an indicator for possible inconsistencies in the code. This rule helps identifying some of these problems.

◆ Core_Chk027

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk027

Procedure parameters match signature parameters

Criterion: Implementing procedures (implements attribute is set) will declare the same set of parameters like the corresponding signature, if the signature has a realisation.For each parameter, name and datatype will match exactly.If a signature parameter has an explicit init value, the corresponding procedure parameter will provide one also.

Comment: Explicit initial values are allowed to differ because an implementing procedure may define own initial values.

Comment: If the signature has no realisation, this rule is irrelevant because a call to such a signature is a NOP at runtime.

◆ Core_Chk028

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk028

No Operation (NOP) ProcedureCall

Criterion: For a ProcedureCall action, the called procedure or signature should have a realisation.

Comment: When a procedure is called that has no realisation, the call is a NOP at runtime. In general, calling such a procedure is an indication for a possible programming error.On the other hand, it might also be intended by the author. Therefore, the author should be warned when doing so.

◆ Core_Chk029

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk029

Correct ProcedureCall arguments

Criterion: In a ProcedureCall action, the given arguments will match to the corresponding procedure or signature parameter declaration, but only if the called procedure or signature has a realisation.This concerns parameter names as well as data types.

Comment: If the called procedure or signature has no realisation the call is a NOP. In this case it is pointless to match arguments to parameters because parameters are not described yet(specification stage).

Comment: Type inference will be supporting in any depth. (see comment at CheckerRule.Core_Chk023 – type-safe assignments.)

◆ Core_Chk030

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk030

Input- and in&output-argument omission

Criterion: For any omitted input- or in&output-argument (when calling a procedure), an initial value has to be defined in the declaration of the corresponding parameter.

◆ Core_Chk031

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk031

Type-safe ListConcatenate

Criterion: In a ListConcatenate action, the lists described by ListTerm (given by the otherList elements) will have identical data type structures as declared for the modified list(given by the list element).

Comment: This disallows concatenating e.g. a list of lists of integers to a list of lists of strings.

Comment: Type inference will be supporting in any depth. (see comment at CheckerRule.Core_Chk023 – type-safe assignments.)

◆ Core_Chk032

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk032

Type-safe ListAppendItems

Criterion: In a ListAppendItems action, the list items described by Term (given by the item elements) will have an identical data type structure as declared for the items of the modified list(referenced by the list element).

Comment: This disallows appending e.g. an integer item to a list of strings.

Comment: Type inference will be supporting in any depth. (see comment at CheckerRule.Core_Chk023 – type-safe assignments.)

◆ Core_Chk033

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk033

Type-safe ListInsertItems

Criterion: In a ListInsertItems action, the list items (given by the item elements) will have an identical data type structure as declared for the items of the modified list(referenced by the list element).

Comment: This disallows inserting e.g. an integer item into a list of strings.

Comment: Type inference will be supporting in any depth. (see comment at CheckerRule.Core_Chk023 – type-safe assignments.)

◆ Core_Chk034

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk034

No use of init in list item type definition

Criterion: The element itemType may, according to the OTX schema, have an init sub element. In its use solely for defining the item type in a List declaration, the init element should not occur here.

◆ Core_Chk035

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk035

ListLiteral item type matches list declaration item type

Criterion: The itemType of the ListLiteral described by the init element of a List declaration must match to the itemType definition of the declaration.

◆ Core_Chk036

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk036

ListLiteral and ListCreate item types follow item type definition

Criterion: In a ListLiteral or a ListCreate term, the types of the items in the items element must match exactly to the type defined by the itemType element.

◆ Core_Chk037

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk037

ListLiteral items are literal terms

Criterion: The item elements in a ListLiteral may, according to the OTX schema, be of any Term type, not only literal terms.In its use solely for describing literal items of a list, no other term types but literal terms are allowed here.

Comment: The OTX Core defines the literal terms IntegerLiteral, FloatLiteral, BooleanLiteral, StringLiteral, BooleanLiteral, ListLiteral, MapLiteral and UserExceptionLiteral.These are the only OTX Core terms allowed in a ListLiteral.

◆ Core_Chk038

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk038

Type-safe MapPutItems

Criterion: In a MapPutItems action, the map items described by MapItem (given by the item elements) will have an identical data type structure as declared for the items of the modified map(referenced by the map element). This applies in terms of key and value data type declarations.

Comment: Type inference will be supporting in any depth. (see comment at CheckerRule.Core_Chk023 – type-safe assignments.)

◆ Core_Chk039

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk039

Type-safe MapRemoveItems

Criterion: In a MapRemoveItems action, the key elements will have an identical data type structure as declared for the items of the target map.They must be of Countable type.

Comment: Type inference will be supporting in any depth. (see comment at CheckerRule.Core_Chk023 – type-safe assignments.)

◆ Core_Chk040

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk040

Type-safe MapContainsKey

Criterion: In every occurrence of the term MapContainsKey, the data type of key must match the key type of map.

Comment: Type inference will be supporting in any depth. (see comment at CheckerRule.Core_Chk023 – type-safe assignments.)

◆ Core_Chk041

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk041

Type-safe MapContainsValue

Criterion: In every occurrence of the term MapContainsValue, the data type of value must match the value type of map.

Comment: Type inference will be supporting in any depth. (see comment at CheckerRule.Core_Chk023 – type-safe assignments.)

◆ Core_Chk042

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk042

Type-safe MapUnion

Criterion: In a MapUnion action, the maps described by MapTerm (given by the otherMap elements) will have an identical data type structure as declared for the modified map(given by the map element). This applies in terms of key and value data type declarations.

Comment: Type inference will be supporting in any depth. (see comment at CheckerRule.Core_Chk023 – type-safe assignments.)

◆ Core_Chk043

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk043

Unique keys in MapLiteral

Criterion: A MapLiteral is wrongly defined if two or more key/value pairs (items) with the same key appear.

◆ Core_Chk044

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk044

No use of init in map key type definition

Criterion: The element keyType may, according to the OTX schema, have an init sub element. In its use solely for defining the key type in a Map declaration, the init element should not occur here.

◆ Core_Chk045

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk045

No use of init in map value type definition

Criterion: The element valueType may, according to the OTX schema, have an init sub element. In its use solely for defining the value type in a Map declaration, the init element should not occur here.

◆ Core_Chk046

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk046

MapLiteral key&value types match map declaration key&value types

Criterion: The keyType and valueType of the MapLiteral described by the init element of a Map declaration must match to the keyType and the valueType definition of the declaration.

◆ Core_Chk047

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk047

MapLiteral and MapCreate key/value types follow key/value type definition

Criterion: In a MapLiteral term, the types of the keys and values of items in the items element must match to the types defined by the keyType and the valueType element.

◆ Core_Chk048

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk048

MapLiteral items are literal terms

Criterion: The key and value elements of items in a MapLiteral may, according to the OTX schema, be of any SimpleTerm / Term type, not only literal terms.In its use solely for describing literal items of a list, no other term types but literal terms are allowed here.

Comment: The OTX Core defines the literal terms IntegerLiteral, FloatLiteral, BooleanLiteral, StringLiteral, BooleanLiteral, ListLiteral, MapLiteral and UserExceptionLiteral.These are the only OTX Core terms allowed in a MapLiteral.

◆ Core_Chk049

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk049

Uniform relation operand type

Criterion: The data types of all argument terms in a comparison operation will match. An exception of this rule are Integer and Float, these may appear mixed in comparison operations.

Comment: Otherwise, comparisons like "string" < 10 would be possible. With the exception of the rule, a numeric comparison e.g.of a float value and an integer value, e.g. " 10.0 < 11 ", is still allowed.

◆ Core_Chk050

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk050

Type-safe variable and constant usage

Criterion: When referring to a variable or constant via one of the dereferencing terms or a Variable subtype, the data type of the corresponding declaration has to correspond to the data indicated by the dereferencing term or Variable subtype.

Comment: This ensures that e.g. a BooleanValue or a BooleanVariable term can refer to Boolean type data only.The target of the referral can be stored top-level in a Boolean variable, constant or parameter, or inside of complex data structures like lists or maps. The rule will check both cases. The declarations give information about the data types.

◆ Core_Chk051

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk051

Immutability of constants, input parameters and context variables

Criterion: The value of a constant, input parameter or context variable is not allowed to be changed (after initialization). Therefore, all occurrences of Variable type elements in OTX documents will neither address constants nor input parameters or context variables.

Comment: E.g. in an Assignment action node, the result element will never refer to a constant or an input parameter.

◆ Core_Chk052

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk052

Identifier shadowing

Criterion: Locally declared identifiers (procedure parameter names as well as local constant and variable names) should not shadow globally declared identifiers(global constant, document variable and context names). Therefore, references which cause shadowing should be avoided.

Comment: This signals naming conflicts which may occur when a global identifier should be accessed but accidentally a local identifier of the same name is used.To solve the issue(after receiving the warning from the checker), authors may either rename the local or global identifier, so that they have distinct names, or they may self-import the local OTX document and use the import prefix in all references.

◆ Core_Chk053

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk053

No dangling OtxLink associations

Criterion: The target of any OtxLink type attribute shall exist and shall be accessible. Furthermore, if the target has a visibility attribute (see signatures and procedures), the visibility information has to be taken into account: An OtxLink attribute shall never link to a target which is not visible to the source document.

Furthermore, OtxLink type attributes shall point to the correct target category. In detail, this means that

for validFor attributes and the validity attribute (occurring in types Procedure, ActionRealisation, GroupRealisation and the IsValid term), a visible Validity term, Boolean context variable or global Boolean constant with corresponding package and name shall exist,
for the procedure attribute (occurring in type ProcedureCall), a visible Signature or Procedure with corresponding package and name shall exist,
for the implements attribute (occurring in type Procedure), a visible ProcedureSignature or unrealised Signature with corresponding package and name shall exist and that
for the name attributes and the valueOf attributes (occurring in the Variable types and the dereferencing terms), a local Declaration or a visible global Declaration with corresponding package and name shall exist.
for the mutexLock attribute (occurring in the MutexFlow type), a local Declaration or a visible global Declaration with corresponding package and name shall exist.

Comment: This is not important at authoring time, but critical for linking. Possible link targets are entities like e.g. validities, global constants, procedures, signatures and local parameters/constants/variables. They are referenced by an OtxLink which implicitly provides their package, document name and entity name. This rule is closely connected to rule Core_Chk003 – no dead import links.

◆ Core_Chk054

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk054

Unused declarations

Criterion: Global private declarations (except for state variable declarations) and private validities as well as local declarations should be read at least once in an OTX document.

Comment: Unused declarations are an indicator for possible inconsistencies in the code. This rule helps identifying some of these problems.Read accesses to declarations include, but are not limited to the valueOf attribute of dereferencing terms, the validFor attribute, or use as the counter of a ForLoop.

◆ Core_Chk055

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk055

Unreachable nodes

Criterion: Nodes in a procedure to which there is no path through the control flow will not be allowed.

Comment: The constraint "no nodes after an endnode" imposed by the OTX Schema works only on the toplevel of a local flow. When all embedded flows in an outer flow end with an endnode, XSD validation cannot identify this. This rule will ensure that all nodes are reachable.

◆ Core_Chk056

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk056

No modification of collection inside foreach-loops

Criterion: Inside of foreach-loops, the collection (List or Map) will not be modified.

Comment: Modifications can be identified by searching for occurences of the collection variable in the list property of a ListModifier action or in the map property of a MapModifier action, or for occurrences of the identifier as an l-value(cf.Variable type). This rule cannot fully prevent ConcurrentModificationExceptions to happen because the modification might happen outside of the loop, e.g. in a Parallel lane.

◆ Core_Chk057

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk057

No use of init in catch header exception type definition

Criterion: The element type in CatchRealisation may, according to the OTX schema, have an init sub element(if the to-be-caught exception type is set to UserException). Since the type element's use in a catch block is solely for defining the to-be-caught exception type, the init element should not occur here.

◆ Core_Chk058

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk058

Unique OtxIds

Criterion: The OtxIds of all elements which derive from NamedAndSpecified will be unique among all other ids in the same OTX document, even for those cases which are not covered by the "UniqueIds" key constraint.

◆ Core_Chk059

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk059

Type-safe ListContainsValue

Criterion: In every occurrence of the term ListContainsValue, the data type of value must match the value type of list.

Comment: Type inference will be supported in any depth. (see comment at CheckerRule.Core_Chk023 – type-safe assignments.)

◆ Core_Chk060

Severity.Deprecation OpenTestSystem.Otx.Core.CheckerRule.Core_Chk060

Usage of deprecated elements

Criterion: Elements which marked as DEPRECATED should not be used.

Comment: Deprecated elements could be removed in a future version.

◆ Core_Chk061

Severity.Information OpenTestSystem.Otx.Core.CheckerRule.Core_Chk061

Usage of util:Compare instead of IsEqual and IsNotEqual

Criterion: An information message is provided if IsEqual or IsNotEqual is called with a complex data type for which util:Compare would perform comparison by value, e.g. List, Map, ByteField or dataType:Structure.

Comment: For comparison of datatypes such as List, Map and ByteField, util:Compare may be more suitable than IsEqual. IsEqual checks for complex terms only the reference and not the content.

◆ Core_Chk062

Severity.Information OpenTestSystem.Otx.Core.CheckerRule.Core_Chk062

Usage of string:Decode instead of ToString for ByteFields

Criterion: An information message is provided if ToString is called on a ByteField.

Comment: To get a hexadecimal representation of a ByteField, string:Decode should be used with Encoding HEX.

◆ Core_Chk063

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk063

Locator or Value in for-each-loop

Criterion: The XML Schema defines that locator and value are optional. However, at least one shall be set; it is illegal to omit both locator and value.

◆ Core_Chk064

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk064

Correct value variable type in for-each-loop

Criterion: The value variable used in for-each-loops shall be of the correct type. If the collection of the for-each-loop is a ListTerm, then the data type needs to match the item data type of the list produced by the term. If the collection is a MapTerm, the data type needs to match the value data type of the map produced by the term.

Comment: To identify the item or value data type of the (potentially compound) ListTerm or MapTerm, the leaves of the term shall be analysed. Possible leaves are ListValue, ListLiteral or MapCreate.

◆ Core_Chk065

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk065

No reading of state variables across documents

Criterion: The value of a state variable shall not be be read unless the visibility is PRIVATE.

Comment: Reading state variable with a higher visibility would contradict the boundary Core_B07 "No global variables".

◆ Core_Chk066

Severity.Critical OpenTestSystem.Otx.Core.CheckerRule.Core_Chk066

Correct referencing of MutexLocks

Criterion: The mutexLock attribute (in type MutexFlow) shall refer to a MutexLock declaration.

◆ Core_Chk067

Severity.Warning OpenTestSystem.Otx.Core.CheckerRule.Core_Chk067

Procedure is visible from the implementing signature

Criterion: A procedure which implements a procedure signature shall be visible to the document defining that signature.

Classes

Public Attributes