ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007798 | Part 01: TTCN-3 Core Language | New Feature | public | 21-09-2018 08:07 | 08-01-2020 09:25

Reporter | Jacob Wieland - Spirent |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version |  | Fixed in Version | 4.12.1 (published 2020-05) |
Clause Reference(s) | 20.2, C.5
Source (company - Author) | Spirent - Jacob Wieland

Summary | 0007798: Address problems with implicit default alt invocation

Description

There's some problems with default alts that sometimes lead to surprising/unexpected results for those developing testcases.
A very common pattern is:
t.start;
t.timeout;
Almost nobody expects default alternatives to be evaluated when checking for the timeout. But, if some default alternative like
alt { [] p.receive { repeat } }
is active, this will read all messages from the port p while waiting for the timeout (which might carry significance for the rest of the testcase).
Another of those patterns is
comp.start(..)
comp.done;
A similar problem is if there are multiple channels of communication like the sync communication between components or upper tester communication.
In such instances, while waiting for the answer on port p1, default alts reading messages from another port can influence the test result negatively.
A possible way to deal with this problem is to add boolean component variables and use them for all guards in default alternatives that should not be active all the time. It is then necessary to set/unset these flags before every alt statement.
Of course, this requires a lot of additional code and is very error prone if the number of flags gets bigger and possibly needs to be amended whenever a new default alternative is added to the testcase.
Ideas to address this problem:
1)
Default alternatives should be added a category upon activation and alt statements should allow giving one (or maybe a list) of such categories whose defaults should be active.
2)
For simple non-port alternatives (short form without syntactically enclosing alt like given above), normal defaults should either never be active (unless they are marked specially upon activation) or some modifier @nodefault could be placed in front of them to make it more explicit (to avoid backward incompatibility issues)
3)
Implicity deactivate all alternatives in defaults which do not deal with the entities in the non-default alt-part. E.g. if an alt statement only treats messages on port p (like the upper tester port), alternatives for ports mapped to the system under test should be inactive for the duration of that alt statement.
Of course, while option 3, in my opinion, would be the most logical solution wich requires the least amount of change by the users and as it is the closest to what people expect when they write an alt statement, it is also the most backward incompatible one (though some of the 'incompability' would probably result in fixing unintended behavior in existing, standardized test suites)
As a compromise between 1 and 3 which is not backward incompatible, the categories given to the alt statement could be the the covered ports/timers/components as a list (normally one) with an additional short-form which results in the semantics of 3 (i.e. active for those entities that are covered by the non-default alternatives).
alt (p, t) { [] p.receive(X) {} [] t.timeout {} }
// no default alternatives for things not happening on p or t
alt (?) { [] p.receive(X) {} [] t.timeout {} }
// same semantics as above

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR7798.docx (192,796) 06-08-2019 14:59 http://oldforge.etsi.org/mantis/file_download.php?file_id=3819&type=bug CR7798-2.docx (366,108) 07-08-2019 12:47 http://oldforge.etsi.org/mantis/file_download.php?file_id=3831&type=bug CR7798-3.docx (296,378) 07-08-2019 13:34 http://oldforge.etsi.org/mantis/file_download.php?file_id=3835&type=bug

Issue History
Date Modified | Username | Field | Change
21-09-2018 08:07 | Jacob Wieland - Spirent | New Issue |
08-10-2018 14:49 | Jens Grabowski | Note Added: 0015207 |
08-10-2018 14:50 | Jens Grabowski | Assigned To | => Jens Grabowski
08-10-2018 14:50 | Jens Grabowski | Status | new => assigned
06-08-2019 12:28 | KristÃ³f Szabados | Note Added: 0015374 |
06-08-2019 12:28 | KristÃ³f Szabados | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
06-08-2019 14:59 | Jacob Wieland - Spirent | File Added: CR7798.docx |
06-08-2019 14:59 | Jacob Wieland - Spirent | Note Added: 0015376 |
06-08-2019 14:59 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
06-08-2019 14:59 | Jacob Wieland - Spirent | Status | assigned => confirmed
07-08-2019 12:47 | Tomas Urban | File Added: CR7798-2.docx |
07-08-2019 12:50 | Tomas Urban | Note Added: 0015401 |
07-08-2019 12:50 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
07-08-2019 13:34 | Jacob Wieland - Spirent | File Added: CR7798-3.docx |
07-08-2019 13:34 | Jacob Wieland - Spirent | Note Added: 0015405 |
07-08-2019 13:35 | Jacob Wieland - Spirent | Status | confirmed => resolved
07-08-2019 13:35 | Jacob Wieland - Spirent | Resolution | open => fixed
07-08-2019 13:35 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
08-01-2020 08:54 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-01-2020 09:25 | Gyorgy Rethy | Note Added: 0015606 |
08-01-2020 09:25 | Gyorgy Rethy | Status | resolved => closed
08-01-2020 09:25 | Gyorgy Rethy | Fixed in Version | => 4.12.1 (published 2020-05)

Notes

(0015207)
Jens Grabowski
08-10-2018 14:49

STF discussion: Usefull extensions. It needs to be checked how the extensions may become part of existing features (e.g., call, wait (RT extension), stopping/starting of ports).

(0015374)
KristÃ³f Szabados
06-08-2019 12:28

STF discussion: the @nodefault solution will be elaborated. The semantics should be to ignore all activated defaults for the duration of the following alt statement.

(0015376)
Jacob Wieland - Spirent
06-08-2019 14:59

please review

(0015401)
Tomas Urban
07-08-2019 12:50

The proposal is fine. I only added missing BNF rules, updated syntax of the related statements and added a restriction on when the modifier can be used. Please check.

(0015405)
Jacob Wieland - Spirent
07-08-2019 13:34

Renamed ReceivingCommunicationStatement to ReceivingStatement and added missing CheckStatement to it in BNF

(0015606)
Gyorgy Rethy
08-01-2020 09:25

Implemented in final draft V4.11.4