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

ID | Project | Category | View Status | Date Submitted | Last Update
0000378 | Part 01: TTCN-3 Core Language | Technical | public | 23-11-2006 13:49 | 21-04-2008 09:03

Reporter | Stephan Schulz |
Assigned To | Ina Schieferdecker |
Priority | high | Severity | minor | Reproducibility | N/A
Status | closed | Resolution | won't fix |
Platform |  | OS |  | OS Version |
Product Version | v2.2.1 (published 2003-02) |
Target Version | v3.4.1 (published 2008-09) | Fixed in Version |  |
Clause Reference(s) | $22, Annex A
Source (company - Author) | dr. György Réthy, Ericsson Hungary Lim.

Summary | 0000378: Return values of PTC behaviour functions

Description

In the standard no restriction applies to functions invoked by a start (test component) operation regarding the return clause. Such functions may have return clauses and specify return values like functions not invoked by start. This causes two problems:
1) It is undefined how the return value shall be handled by the system; intuitively it is lost, but exact behavior is not specified.
2) In several cases it is necessary to preserve variable values even when the PTC instance generating them has already ended its behaviour. For example when a PTC behaviour handles a complete incoming call and several outgoing calls wanted to be set-up using the same call reference afterwards; or on the contrary, values used by a (finished) PTC instance shall not be used again by subsequently started PTCs.
Today the only way to preserve PTC variable values of finished PTCs is by sending coordination messages. This solution has several disadvantages:
a) Coordination messages has to be caught by the addressee. This effects the addressee behaviour; as coordination messages may arrive in any moment, the most appropriate to use defaults to catch them; however, if the coordination message arrives when the addressee expects another receiving event(s), it causes an extra "side" snapshot and evaluation.
b) There may be more than one addressee and addressee(s) is(are) not necessary known at the time when the sender PTC is started (so their references shall be sent by other co-ordination message(s)).
c) In load tests unnecessary internal system load is generated decreasing the performance of the test system.
d) Test suites become needlessly complicated difficult to maintain and logs are loaded with messages not related to the real test behaviour.

Steps To Reproduce |

Additional Information

It is proposed that the return value of a PTC behaviour function ? if any - is stored by the test system when the PTC behaviour is finished(aside the status of PTC references). Allow any other running component to request this return value from the system by using a newly defined operation. Introduction of a new operation is necessary to avoid effects on the use of the done operation in alt statements.
As a result "distribution" of the return value is not controlled by the actually finishing PTC but obtained from the system by components wishing using it just at the moment of its use.
See detailed proposal in the attachment.

Tags | No tags attached.

Relationships

related to | 0000380 | closed | Ina Schieferdecker | Inout parameters for function in start test component operation

Attached Files | CR 224 Return values of PTC behaviour functions.doc (70,144) 23-11-2006 13:49 http://oldforge.etsi.org/mantis/file_download.php?file_id=32&type=bug

Issue History
Date Modified | Username | Field | Change
23-11-2006 13:49 | Stephan Schulz | New Issue |
23-11-2006 13:49 | Stephan Schulz | File Added: CR 224 Return values of PTC behaviour functions.doc |
23-11-2006 13:49 | Stephan Schulz | Clause Reference(s) | => $22, Annex A
23-11-2006 13:49 | Stephan Schulz | Source (company - Author) | => dr. György Réthy, Ericsson Hungary Lim.
23-11-2006 13:53 | Stephan Schulz | Status | new => assigned
23-11-2006 13:53 | Stephan Schulz | Assigned To | => Stephan Schulz
23-11-2006 13:54 | Stephan Schulz | Assigned To | Stephan Schulz =>
23-11-2006 13:54 | Stephan Schulz | Assigned To | => user10
23-11-2006 13:54 | Stephan Schulz | Status | assigned => acknowledged
23-11-2006 13:54 | Stephan Schulz | Status | acknowledged => assigned
23-11-2006 13:54 | Stephan Schulz | Assigned To | user10 => Stephan Schulz
23-11-2006 13:55 | Stephan Schulz | Assigned To | Stephan Schulz => Jens Grabowski
24-11-2006 15:08 | Stephan Schulz | Relationship added | related to 0000380
15-10-2007 16:52 | Ina Schieferdecker | Note Added: 0003624 |
18-10-2007 14:26 | Ina Schieferdecker | Target Version | => Edition 4.1.1 (not yet published)
18-10-2007 14:26 | Ina Schieferdecker | Additional Information Updated |
13-03-2008 15:37 | Ina Schieferdecker | Assigned To | Jens Grabowski => Ina Schieferdecker
14-03-2008 09:17 | Ina Schieferdecker | Note Added: 0005230 |
14-03-2008 09:18 | Ina Schieferdecker | Status | assigned => closed
14-03-2008 09:18 | Ina Schieferdecker | Resolution | open => won't fix
21-04-2008 09:03 | Ina Schieferdecker | Target Version | Edition 4.1.1 (not yet published) => Edition 3.4.1 (not yet published)

Notes

(0003624)
Ina Schieferdecker
15-10-2007 16:52

to be considered in 2008 in the context of test configurations

(0005230)
Ina Schieferdecker
14-03-2008 09:17

This CR would require to know the return type at every possible place of invoking the done operation - for example, by defining a return type in the component type definition. This would add another form of passing information - which can however also be resolved by explicit communiction by the test component, which is currently being considered not being worth the effort.
It might be reconsidered in the context of parallel execution and/or test configurations.