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

ID | Project | Category | View Status | Date Submitted | Last Update
0003627 | Part 01: TTCN-3 Core Language | New Feature | public | 24-06-2008 12:55 | 12-12-2008 11:43

Reporter | Pavel Yakovenko |
Assigned To | Thomas DeiÃŸ |
Priority | normal | Severity | minor | Reproducibility | always
Status | closed | Resolution | won't fix |
Platform |  | OS |  | OS Version |
Product Version | v3.3.2 (published 2008-04) |
Target Version | v4.1.1 (published 2009-06) | Fixed in Version |  |
Clause Reference(s) | 6.2.9, F.3
Source (company - Author) | Pavel Yakovenko, ISPRAS

Summary | 0003627: Bring "inout all" back with relaxed semantics

Description

Propose:
1) Clear "deprecated" notice from port "inout all" statement (clause F.3).
2) Declare that "inout all" covers any arbitrary type (clause 6.2.9).
Problem description:
One of the approaches to map classes (C++, UML, etc) to TTCN-3 is to put every class into separate module and represent every class instance as a separate parallel component. Public class methods are mapped to signatures. Accesses to public class data members are translated into get/set signatures. At the same time we may want to hide communication operations into proxy functions that are not tied to a component (i.e. do not have runs on clause). Proxy function must have two additional parameters: a reference to accessed component instance and a reference to a port which is used to send procedure call and receive reply.
The problem is in the set of ports that calling component must have to access other components. If class ClassA invokes methods from ClassB and ClassC then corresponding component for ClassA must declare two ports â€“ one for ClassB and one for ClassC. The more different classes are used the more different ports component must declare.
This issue could be solved if â€œinout allâ€ in the port type declaration would cover all possible types defined in the whole test suite (not in the current module). This would eliminate the need to have lots of ports to access class methods and would also remove the necessity to pass port instance to a proxy function.
Example:
Suppose we have ClassA, ClassB and ClassC classes and ClassA inokes methods from opther two classes.
class ClassB
{
public: int f() {return 1;}
}
class ClassC
{
public: int g() {return 2;}
}
class ClassA
{
ClassB m_B;
ClassC m_C;
void h()
{
int v = m_B.f() + m_C.g();
}
}
Currently we need to put two ports into component declaration for ClassA and pass port instance to every proxy function (look at the Part1 in the attached InOutAll.ttcn)
Having â€œinout allâ€ cover any arbitrary type makes TTCN-3 code more structured. We may put port declaration to access class operations into a â€œrootâ€ component type and declare every component as an extension of the â€œrootâ€ one. Proxy functions are declared as running on â€œrootâ€ component hence we may remove port instance from the list of formal parameters (look at the Part2 in the attached InOutAll.ttcn).

Steps To Reproduce |

Additional Information

1) Making "inout all" to cover arbitrary types doesn't influence type checking in any way. All invoked signatures and templates still must be visible in the module.
2) Keeping current semantics of "inout all" doesn't help.
Yes, we may declare PT port type with "inout all" in every module and use one and the same port to invoke operations on every component. But still we must pass port reference to proxy function since component ClassA.CT and ClassB.CT are not compatible and we may not declare f_proxy with "runs on".

Tags | No tags attached.
Relationships |
Attached Files | InOutAll.ttcn (3,871) 24-06-2008 12:55 http://oldforge.etsi.org/mantis/file_download.php?file_id=1528&type=bug CR_3627_TD_18_July_2008.doc (61,952) 18-07-2008 14:41 http://oldforge.etsi.org/mantis/file_download.php?file_id=1573&type=bug CR_3627_Bring_inout_all_back.zip (29,018) 13-08-2008 05:36 http://oldforge.etsi.org/mantis/file_download.php?file_id=1589&type=bug

Issue History
Date Modified | Username | Field | Change
24-06-2008 12:55 | Pavel Yakovenko | New Issue |
24-06-2008 12:55 | Pavel Yakovenko | Status | new => assigned
24-06-2008 12:55 | Pavel Yakovenko | Assigned To | => Ina Schieferdecker
24-06-2008 12:55 | Pavel Yakovenko | File Added: InOutAll.ttcn |
24-06-2008 12:55 | Pavel Yakovenko | Clause Reference(s) | => 6.2.9, F.3
24-06-2008 12:55 | Pavel Yakovenko | Source (company - Author) | => Pavel Yakovenko, ISPRAS
18-07-2008 09:20 | Thomas DeiÃŸ | Note Added: 0006320 |
18-07-2008 09:20 | Thomas DeiÃŸ | Assigned To | Ina Schieferdecker => Thomas DeiÃŸ
18-07-2008 09:20 | Thomas DeiÃŸ | Status | assigned => feedback
18-07-2008 11:33 | Pavel Yakovenko | Note Added: 0006336 |
18-07-2008 14:40 | Thomas DeiÃŸ | Note Added: 0006339 |
18-07-2008 14:41 | Thomas DeiÃŸ | File Added: CR_3627_TD_18_July_2008.doc |
18-07-2008 14:42 | Thomas DeiÃŸ | Note Added: 0006340 |
18-07-2008 14:42 | Thomas DeiÃŸ | Status | feedback => assigned
13-08-2008 05:33 | Thomas DeiÃŸ | Note Added: 0006503 |
13-08-2008 05:36 | Thomas DeiÃŸ | File Added: CR_3627_Bring_inout_all_back.zip |
13-08-2008 05:38 | Thomas DeiÃŸ | Note Added: 0006504 |
13-08-2008 05:38 | Thomas DeiÃŸ | Status | assigned => closed
13-08-2008 05:38 | Thomas DeiÃŸ | Resolution | open => won't fix
12-12-2008 11:43 | Ina Schieferdecker | Target Version | => Edition 4.1.1 (not yet published)

Notes

(0006320)
Thomas DeiÃŸ
18-07-2008 09:20

The proposal refers to the use of proxy functions and it is stated that these are not tied to component and therefore do not have a runs on clause. No reason is given in the proposal why the runs on clause should be avoided.
Assuming that the proxy functions have a runs on clause, the problem could be solved quite simply: Assume there is a class A, providing a set of methods. A port type Port_A can be defined to call these methods and a corresponding component CT_A type with such a port pt_A can be defined too. The proxy function would then have clause 'runs on CT_A' allowing to access the port pt_A without having to pass it as parameter. The actual test component types used in behaviour functions would then be defined as extensions of CT_A and of other component types CT_B, CT_C, etc if methods of other classes would have to be invoked, too. Using this approach there would be no need to reintroduce 'inout all'.
For further processing of the CR an explanation we need an explanation why the runs on clause has to be avoided.

(0006336)
Pavel Yakovenko
18-07-2008 11:33

Yes, that's what I propose but "runs on ROOT" instead of "runs on CT_A" (see example 2 in the InOutAll.ttcn).
If we add "runs on CT_A" to a proxy function of class A then we must add CT_A component to the extension list of every component that calls any operation from class A. This is very inconvenient from my point of view especially when writing code manually. Imagine extensions lists with tens of elements in it.
And it doesn't differ much from adding pt_A port to the body of the calling component. In fact what extension mechanism does for us in this case is that it hides from the user addition of pt_A to the body of calling component. But actually it does more job - it adds all the component elements from parent component to the extended one. As a result extended component contains lots of members that are never used (except communication port) but we need to pay attention to possible name clashes. That is we need to make ports, port types, and other component elements (like "this" varaible storing class members) globally unique. For example we must declare this_A in class A instead of simply "this" and this_B for class B, because if class C calls both A and B it must extend component CT_C with CT_A and CT_B and having two "this" members (from A and B) will result in compile error.
Now imagine if we have ROOT component with "inout all" port. It has only one component member (instance of that dispatching port), all components extend ROOT component and may use that port to communicate between each other as long as "inout all" covers transmited signature. We do not need to put every communicated component into the extension list, we do not need to care about name clashes since they may not occur.

(0006339)
Thomas DeiÃŸ
18-07-2008 14:40

Ok, argument understood.
One might have to use a more sophisticated mapping, actually one separating between the interface of a class from the implementation of a class, see the attached file CR_3627_TD_18_July_2008.doc. This should help to limit the amount of elements in the component types. And this should also help to avoid the name clashes among the 'this' component variables. Still, the extends clauses would be longer, agreed.

(0006340)
Thomas DeiÃŸ
18-07-2008 14:42

explanation from Pavel received. Discussion within STF can continue.

(0006503)
Thomas DeiÃŸ
13-08-2008 05:33

email from Pavel, August 12th, 2008: ... Your suggestion to split interface and realization works well. I think increasing number of ports is an acceptable tradeoff over changing language semantics in this case. So let's close the case. ...

(0006504)
Thomas DeiÃŸ
13-08-2008 05:38

Alternative mapping of classes to component types solves the original problem without reintroducing 'inout all'. Therefore the CR can be closed as won't fix. The attached zip file contains a more detailed explanation of the alternative mapping and some example.