| | 1 | === Structure of Data === |
| | 2 | |
| | 3 | ==== Alphabetic Ordering of Types withing Groups ==== |
| | 4 | - '''Symbolic Name in XML Configuration''': checkTypeDefOrderInGroup |
| | 5 | - '''Dependant Tags in XML Configuration''': - |
| | 6 | |
| | 7 | This quality check analyzes type definitions within groups in the same module and throws a warning if type definitions within the same group are not alphabetically (or alpha-numerically, where numbers come before letters) ordered. The ordering is case-insensitive. |
| | 8 | |
| | 9 | ==== Grouping of Ports and Related Messages ==== |
| | 10 | - '''Symbolic Name in XML Configuration''': checkPortMessageGrouping |
| | 11 | - '''Dependant Tags in XML Configuration''': - |
| | 12 | |
| | 13 | This quality check verifies that port definitions are grouped together with all the message types or signatures referenced within the port definition. The ports and the message types / signatures related to them shall be grouped within the same group in the same module. Limited nested grouping is allowed, where the message / signatures may be grouped in a subgroup within the group in which the port to which they are related was defined. This can be best illustrated by examples: |
| | 14 | |
| | 15 | [[Include(source:trunk/t3q-examples/checkPortMessageGrouping/checkPortMessageGrouping.ttcn3, text/x-rst)]] |
| | 16 | |
| | 17 | In the above module definition, the contents of group {{{correct}}} are OK, where as the contents of group {{{incorrect}}} are not, because the message types are not defined under the same group where the port they are related to is defined. |
| | 18 | |
| | 19 | If a port is defined outside a group, it automatically means that the related message types cannot be defined within the same group and they are not further analyzed. If a message type is defined outside a group, it also means that it is not in the same group as the port definition it is related to. If a message type is defined within a group with the same name as the one where the port it is related to is defined, but within a different module, it is also considered a violation of the constraint and a warning will be thrown. If a message type related to a port type definition cannot be resolved, it is considered a violation of the constraint as well and an appropriate warning is thrown. |
| | 20 | |
| | 21 | The standard (first) line numbers in the output indicate the reference point - on which lines within the port type definition has the violating message type been referenced. Additionally, next to the message type / signature name and the port type name, location triples <startLine,moduleName,groupName> are provided to facilitate the easier identification and localization of the elements violating the constraint. |
| | 22 | |
| | 23 | Additionally, if nesting is present as in the above example, but does not violate the constraints, an information message will be provided in the output to inform the user of the occurrence. |
| | 24 | |
| | 25 | ==== No All Keyword in Port Type Definitions ==== |
| | 26 | - '''Symbolic Name in XML Configuration''': checkNoAllKeywordInPortDefinitions |
| | 27 | - '''Dependant Tags in XML Configuration''': - |
| | 28 | |
| | 29 | The check makes sure that there are no all keywords in port type definitions. |
