ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0005992 | Part 06: TTCN-3 Control Interface | Technical | public | 21-12-2011 17:19 | 14-12-2012 12:51

Reporter | Anthony Baire |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.3.1 (published 2011-06) |
Target Version | v4.5.1 (published 2013-04) | Fixed in Version | v4.5.1 (published 2013-04) |
Clause Reference(s) | 8.3.2.1 9.5 10.5.2.9 11.3.2.7 12.4.2.2
Source (company - Author) |

Summary | 0005992: TciParameterType allows only TCI Values
Description | TciParameterType allows only TCI Values. However, tliSEnter and tliSLeave may report other kind of parameters. Indeed TTCN-3 functions, testcases, altsteps allow non-value parameters : - templates - port references - timer references - component references
Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR_5992_v1.docx (435,441) 11-12-2012 15:36 http://oldforge.etsi.org/mantis/file_download.php?file_id=2766&type=bug CR_5992_v2.docx (440,951) 14-12-2012 10:14 http://oldforge.etsi.org/mantis/file_download.php?file_id=2782&type=bug

Issue History
Date Modified | Username | Field | Change
21-12-2011 17:19 | Anthony Baire | New Issue |
21-12-2011 17:19 | Anthony Baire | Clause Reference(s) | => 8.3.2.1 9.5 10.5.2.9 11.3.2.7 12.4.2.2
21-12-2011 17:19 | Anthony Baire | Source (company - Author) | =>
10-07-2012 14:18 | Gyorgy Rethy | Note Added: 0010760 |
10-07-2012 14:18 | Gyorgy Rethy | Assigned To | => Ina Schieferdecker
10-07-2012 14:18 | Gyorgy Rethy | Status | new => assigned
10-07-2012 14:18 | Gyorgy Rethy | Target Version | => Edition 4.5.1
13-07-2012 09:38 | Gyorgy Rethy | Assigned To | Ina Schieferdecker => Tomas Urban
13-07-2012 13:37 | Tomas Urban | Note Added: 0010922 |
08-08-2012 11:18 | Tomas Urban | Assigned To | Tomas Urban => Ina Schieferdecker
10-08-2012 12:21 | Ina Schieferdecker | Note Added: 0011030 |
10-08-2012 12:21 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Tomas Urban
11-12-2012 15:36 | Tomas Urban | File Added: CR_5992_v1.docx |
11-12-2012 15:50 | Tomas Urban | Note Added: 0011235 |
11-12-2012 15:50 | Tomas Urban | Assigned To | Tomas Urban => Ina Schieferdecker
14-12-2012 10:10 | Ina Schieferdecker | File Added: CR_5992_v2.docx |
14-12-2012 10:10 | Ina Schieferdecker | Note Added: 0011266 |
14-12-2012 10:11 | Ina Schieferdecker | Note Added: 0011267 |
14-12-2012 10:11 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Tomas Urban
14-12-2012 10:11 | Ina Schieferdecker | Resolution | open => fixed
14-12-2012 10:11 | Ina Schieferdecker | Fixed in Version | => Edition 4.5.1
14-12-2012 10:13 | Ina Schieferdecker | File Deleted: CR_5992_v2.docx |
14-12-2012 10:14 | Ina Schieferdecker | File Added: CR_5992_v2.docx |
14-12-2012 12:40 | Tomas Urban | Note Added: 0011275 |
14-12-2012 12:41 | Tomas Urban | Assigned To | Tomas Urban => Ina Schieferdecker
14-12-2012 12:51 | Ina Schieferdecker | Note Added: 0011277 |
14-12-2012 12:51 | Ina Schieferdecker | Status | assigned => closed

Notes

(0010760)
Gyorgy Rethy
10-07-2012 14:18

STF discussion 2012-07-10: to be checked

(0010922)
Tomas Urban
13-07-2012 13:37

The number of TCI functions affected by this problem is actually wider:
(TCI-TM)
tciStartTestCase
tciTestCaseStarted
tciTestCaseTerminated
(TCI-TL)
tliTcExecute
tliTcStart
tliTcStarted
tliTcTerminated
tliCStart
tliSEnter
tliSLeave
The component type is currently supported by the TCI. There's no dedicated Value class for it, but the Type class contains support for it (see Type.getTypeClass method description in chapter 7.2.2.1).
Adding support for the default, port and timer values is quite simple. It can be done in a similar way as the component type is supported, adding new type tags into the Type.getTypeClass method: DEFAULT, PORT, TIMER. The Type.newInstance description should be extended, saying that instances of default, port, timer and probably component type cannot be created by calling this method and that the method returns distinct value null in these cases.
These changes are quite easy to implement and are backwards compatible as well. It is up to further consideration, whether port, component, timer and default instances should use the Value class in its vanilla form, or whether new dedicated subclasses shall be added to the specification providing extended access to object data (e.g. states, IDs, names etc.).
The situations is more complicated with matching symbols. I have created three possible solutions as an input for further discussion:
1. Null value
A rule shall be added to the TciParameterType definition saying that during the conversion of parameter content into a TCI value object, all occurrences of matching symbols shall be replaced with a distinct value null.
Pros:
- No change in TCI interface required (no problems with backwards compatibility)
- Simple to implement by vendors
Cons:
- Information loss (parameter values or their parts will appear as uninitialized)
- Not possible to provide matching symbols when starting a test case using the tciStartTestCase function of the TCI-TM interface
2. Dedicated light-weight class for matching symbols
A new class MatchingSymbol shall be added to the chapter 7.2.2.2. This class shall be a subclass of the Value class. It shall contain just one method: TString getTemplateDef(), returning textual definition of the template.
In addition to that, a new isMatchingSymbol method shall be added to the Value class. This method shall return false if a the Value instance contain a value and true if it contains a matching symbol. The reason for adding the method is simple: currently the type tag obtained from the Value.getType().getTypeTag() distincitively identifies the actual class of the Value instance. It allows to safely cast the Value object to the particular subclass and get more details from it. With addition of the MatchingSymbol class, this paradigm will be no longer valid and for languages that do not contain runtime type information (C and in some cases C++), additional information is required to distinguish between standard values and matching symbols.
Note: I also considered use the existing TciValueTemplate class for this purpose. In this scenarion, the TciValueTemplate would be changed so that it is a subclass of the Value class. The benefit of this solution is that no additional class would be necessary. However, I didn't find such a solution suitable. Currently, TciValueTemplate is used in various TLI calls (such as tliMReceive_c) to represent a whole template, so e.g. a record template with matching symbols in its fields is represented by a single TciValueTemplate in these calls. However, when passing such a template as a paremeter in tliSEnter, a RecordValue with TciValueTemplate embedded in it would be passed. Thus there would be an unaxceptable diffence in the way how the class is used in different context. Of course it would be possible to replace all occurrences of TciValueTemplate with Value, but that would cause trouble with backwards compatibility.
Pros:
- Changes in the TCI interface are minor
- No backward compatibility issues (only code additions, no modifications or deleting of existing definitions)
- No information loss
Cons:
- Not possible to provide matching symbols when starting a test case using the tciStartTestCase function of the TCI-TM interface, as the MatchingSymbol class provides only read access.
3. Dedicated set of classes for matching symbols
Similar to the previous solution, but instead of one class there would be a whole set of classes representing all matching symbols defined in the core language specification. These classes would contain methods allowing to set the content of matching symbols.
Pros:
- No backward compatibility issues (only code additions, no modifications or deleting of existing definitions)
- No information loss
- It is possible to provide matching symbols when starting a test case using the tciStartTestCase function of the TCI-TM interface, as the new classes grant write access
Cons:
- Time consuming to write the specification and to implement it

(0011030)
Ina Schieferdecker
10-08-2012 12:21

Thank you for the good analysis. We discussed to go for option 2 and to have a newInstance method for the new subclass, so that also start test case from TM can have template parameters. If that support is implemented in a TM is due to the tool vendors.

(0011235)
Tomas Urban
11-12-2012 15:50

I slightly modified the proposal. It is still very similar to the 2nd option, but there are some important differences:
1. There's no new abstract data type for matching symbols. Instead, the top-level Value data type contains two additional operations: isMatchingSymbol (returns true for matching symbols) and valueToString (for printing value content in the same way as the log operation; can be used for displaying value content)
2. Matching symbols can be created using parseValue operation of the Type abstract data type. The operation requires a string argument, which shall be a value/template in TTCN-3 syntax. The output is either an instance of a Value abstract data type or null in case of failure or missing support from the tool side. This method is an optional part of the TCI.
3. Support for timers, ports, components and defaults is very basic: only type class codes have been added in most mappings and there are no dedicated value data types, because it is not expected the user will modify their values. The new valueToString operation can be used for logging purposes if needed.
Ina could you please check if the draft resolves all the issues mentioned in this CR?

(0011266)
Ina Schieferdecker
14-12-2012 10:10

Implemented with some technical and editorial changes

(0011267)
Ina Schieferdecker
14-12-2012 10:11

Please check

(0011275)
Tomas Urban
14-12-2012 12:40

I am fine with the changes, with one small correction: the "matching_symbol" element shall be added to the ComponentValue definition in Annex B as well.

(0011277)
Ina Schieferdecker
14-12-2012 12:51

Thanks.