I'm having trouble understanding the semantics of the mtc, self, and
system component designations: Is, in general, anything known statically
about these types, i.e. does the compiler check, say, port references in
a connect statement like so:

connect( mtc:pt_sync, ptc1:pt_sync );

statically, or does this happen completely dynamically? If anything is
known statically, what is it?

--
Regards,
Mike

Hi Michael,

In any case you will know the type of the reference "self" through the
"runs on" associated. In case of "mtc" and "system" you will know them
only inside a testcase, since the runs on of the testcase will always
be the type of the MTC, and if system is not present it will take the
"runs on" type as well

Regards,
Jes

Hi Mike,

mtc, self and system just identify the handles (references) of some specific components; the type of the component the handle refers to may be important in some cases but not relevant in other cases.

mtc and self are used in two contexts:
- in component operations like self.stop, self.kill, mtc.stop etc. (but not in create or start, of course)
- in port operations like in your example below.
system is used in the second context only.

In the first context the type of the component is unimportant, there is nothing to check compile time (the RTE shall, of course, disconnect/unmap the still remaining port connections and release other resources before cleaning the process from the system, but this need not be reflected in the TTCN-3 code).

In the second context the type of the component is known in some cases (e.g. when used in a testcase or self is used in a function/altstep with a runs on clause) but not known in other cases (e.g. a PTC maps a port of the mtc to a port of the system or self is used in a function/altstep without runs on clause).

The standard says about this in $21.1.1
"e) Since TTCN 3 allows dynamic configurations and addresses, not all of these consistency checks can be made statically at compile-time. All checks, which could not be made at compile-time, shall be made at run-time and shall lead to a test case error when failing."

I think, that a reasonable design decision is to check all connect/map disconnect/unmap operations dynamically, instead of checking some of these operations statically and others dynamically. But all tools take its own decisions...

BR, Gyorgy

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Michael Sperber
> Sent: Wednesday, 18 June, 2008 7:41 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Types of mtc, self, system
>
> I'm having trouble understanding the semantics of the mtc,
> self, and system component designations: Is, in general,
> anything known statically about these types, i.e. does the
> compiler check, say, port references in a connect statement like so:
>
> connect( mtc:pt_sync, ptc1:pt_sync );
>
> statically, or does this happen completely dynamically? If
> anything is known statically, what is it?
>
> --
> Regards,
> Mike
>

Thanks very much for the prompt answer!

György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:

> The standard says about this in $21.1.1 "e) Since TTCN 3 allows
> dynamic configurations and addresses, not all of these consistency
> checks can be made statically at compile-time. All checks, which could
> not be made at compile-time, shall be made at run-time and shall lead
> to a test case error when failing."

> I think, that a reasonable design decision is to check all connect/map
> disconnect/unmap operations dynamically, instead of checking some of
> these operations statically and others dynamically. But all tools take
> its own decisions...

I had read 2.1.1 e) - the wording seems unnecessarily vague, as it
doesn't specify *which* consistency checks an implementation would be
allowed to relegate to run-time. Moreover (barring subtype
restrictions), most of the rest of the type system is statically
decidable - it just seems odd that this bit isn't. It seems, as a
compiler writer, I'd even need to track the names of the ports within a
component in its run-time representation. Correct?

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Hi Mike,

"the wording seems unnecessarily vague, as it doesn't specify *which* consistency checks an implementation would be allowed to relegate to run-time" => intentionally. It is beyond the scope of an international standard to specify implementation details/decisions. This has been taken by each tool designer individually.

"most of the rest of the type system is statically decidable - it just seems odd that this bit isn't." => if you think about it, it is not. First, the TSI and the MTC are created and started implicitly, therefore they do not have stored handles like PTCs. Secondly, to be able to check them compile time, mtc and system should be allowed in testcases only. E.g. if the user wanted to map an MTC port with a TSI port from a PTC, the component references should have been sent to the PTC by co-ordination messages. But the receiving can only be checked runtime anyway, as you do not know the actual MTC and TSI type when the receive is executed. So, we even would loss performance by disallowing mtc and system in functions/altsteps, as the test system can solve checking and/or passing them to PTCs more efficiently, and consistency is assured (i.e. mtc and system will always be valid component references in the test system). Thirdly, configuration operations are rare (especially because of alive PTCs), so runtime checking does not significantly influence the performance of the whole test campaign.

BR, Gyorgy

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Michael Sperber
> Sent: Friday, 20 June, 2008 9:37 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Types of mtc, self, system
>
> Thanks very much for the prompt answer!
>
> György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:
>
> > The standard says about this in $21.1.1 "e) Since TTCN 3 allows
> > dynamic configurations and addresses, not all of these consistency
> > checks can be made statically at compile-time. All checks,
> which could
> > not be made at compile-time, shall be made at run-time and
> shall lead
> > to a test case error when failing."
>
> > I think, that a reasonable design decision is to check all
> connect/map
> > disconnect/unmap operations dynamically, instead of
> checking some of
> > these operations statically and others dynamically. But all
> tools take
> > its own decisions...
>
> I had read 2.1.1 e) - the wording seems unnecessarily vague,
> as it doesn't specify *which* consistency checks an
> implementation would be allowed to relegate to run-time.
> Moreover (barring subtype restrictions), most of the rest of
> the type system is statically decidable - it just seems odd
> that this bit isn't. It seems, as a compiler writer, I'd
> even need to track the names of the ports within a component
> in its run-time representation. Correct?
>
> --
> Cheers =8-} Mike
> Friede, Völkerverständigung und überhaupt blabla
>

Hello folks,

I also think this is an unfortunate situation.

It could be remedied (at least for the system component) by allowing a
*system* clause not only
for testcases, but also everywhere else where a *runs on* clause (with
the same restrictions as for
*runs on*) can be declared. This way, it would at least be possible
(without clumsily passing the *system*
component around as a parameter) for the user to write down consistent
code which can be checked
statically.

As an idea, to solve the problem also for *mtc*, we could introduce an
*mtc* clause (analogous to *runs on*
and *system* clauses, also with the same restrictions) for functions and
altsteps (for testcases this would not
be necessary since there *self* is always equal to *mtc* and therefore
already declared by the *runs on* clause)
that should run on ptcs.

This approach would lead to a consistent language design in respect to
the possibility of static analysis of
the ports of *system* and *mtc* in configuration statements. Thus, the
number of warnings that must be
generated at compile time (and the number of checks that have to be done
at runtime) could be reduced.

What is your opinion? Should I introduce a CR for this issue?

Best regards,

Jacob Wieland

Michael Sperber wrote:
> Thanks very much for the prompt answer!
>
> György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:
>
>
>> The standard says about this in $21.1.1 "e) Since TTCN 3 allows
>> dynamic configurations and addresses, not all of these consistency
>> checks can be made statically at compile-time. All checks, which could
>> not be made at compile-time, shall be made at run-time and shall lead
>> to a test case error when failing."
>>
>
>
>> I think, that a reasonable design decision is to check all connect/map
>> disconnect/unmap operations dynamically, instead of checking some of
>> these operations statically and others dynamically. But all tools take
>> its own decisions...
>>
>
> I had read 2.1.1 e) - the wording seems unnecessarily vague, as it
> doesn't specify *which* consistency checks an implementation would be
> allowed to relegate to run-time. Moreover (barring subtype
> restrictions), most of the rest of the type system is statically
> decidable - it just seems odd that this bit isn't. It seems, as a
> compiler writer, I'd even need to track the names of the ports within a
> component in its run-time representation. Correct?
>
>


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

July 17 & August 13, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

September 22-24, TTCN-3 Tutorial, Berlin (Germany)
Theory and Practice of TTCN-3
www.testingtech.com/services/ttcn3_tutorial.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

July 17 & August 13, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

September 22-24, TTCN-3 Tutorial, Berlin (Germany)
Theory and Practice of TTCN-3
www.testingtech.com/services/ttcn3_tutorial.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hi Jacob,

I'm lost with your ideas.

"by allowing a system clause not only for testcases, but also everywhere else where a runs on clause (with the same restrictions as for
runs on) can be declared." => it is allowed! There is no restriction in using mtc, system and self in any functions or altsteps - at least if I have not overlooked something. Anyway, I do not understand, how the runs on clause helps compile time checking, e.g. in the case
function MyFunc() runs on MyComp_CT {
map (mtc:P, system:P)
}
You do not even know if the function will be called on the MTC or on a PTC.

"we could introduce an mtc clause (analogous to runs on and system clauses, also with the same restrictions) for functions and altsteps " => Wouldn't really help. First of all, it should be optional for backward compatibility and because there are functions which are called on PTCs in different test cases using different MTC types (possibly all having e.g. port P!). Secondly, it would not solve checking the system handle. Therefore, you still must check consistency runtime and could give max. warnings compile time where the mtc clause exists and the MTC does not have the port referred to (anyway, connecting/mapping ports without runtime checking is not a healthy thing). So, it could be an overkill for still not being able to check everything compile time.

TTCN-3, by definition, is a distributed test system, therefore it sould be clear that the complete system-level consistency can be checked runtime only (as I wrote earlier, some cases, e.g. when the user handles all test configuration in the MTC, can be checked compile time). This is the difference to other (type) checkings, which are verifying local consistency (that I agree shall be maximized). As ports are connected/mapped via the TM through TCI, all infos about the port compatibility are sent around/available anyway.

BR, Gyorgy



________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: Friday, 20 June, 2008 11:47 AM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Types of mtc, self, system


Hello folks,

I also think this is an unfortunate situation.

It could be remedied (at least for the system component) by allowing a system clause not only
for testcases, but also everywhere else where a runs on clause (with the same restrictions as for
runs on) can be declared. This way, it would at least be possible (without clumsily passing the system
component around as a parameter) for the user to write down consistent code which can be checked
statically.

As an idea, to solve the problem also for mtc, we could introduce an mtc clause (analogous to runs on
and system clauses, also with the same restrictions) for functions and altsteps (for testcases this would not
be necessary since there self is always equal to mtc and therefore already declared by the runs on clause)
that should run on ptcs.

This approach would lead to a consistent language design in respect to the possibility of static analysis of
the ports of system and mtc in configuration statements. Thus, the number of warnings that must be
generated at compile time (and the number of checks that have to be done at runtime) could be reduced.

What is your opinion? Should I introduce a CR for this issue?

Best regards,

Jacob Wieland

Michael Sperber wrote:

Thanks very much for the prompt answer!

György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:



The standard says about this in $21.1.1 "e) Since TTCN 3
allows
dynamic configurations and addresses, not all of these
consistency
checks can be made statically at compile-time. All checks,
which could
not be made at compile-time, shall be made at run-time and
shall lead
to a test case error when failing."





I think, that a reasonable design decision is to check all connect/map
disconnect/unmap operations dynamically, instead of checking
some of
these operations statically and others dynamically. But all
tools take
its own decisions...



I had read 2.1.1 e) - the wording seems unnecessarily vague, as it
doesn't specify *which* consistency checks an implementation would
be
allowed to relegate to run-time. Moreover (barring subtype
restrictions), most of the rest of the type system is statically
decidable - it just seems odd that this bit isn't. It seems, as a
compiler writer, I'd even need to track the names of the ports
within a
component in its run-time representation. Correct?





--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

July 17 & August 13, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

September 22-24, TTCN-3 Tutorial, Berlin (Germany)
Theory and Practice of TTCN-3
www.testingtech.com/services/ttcn3_tutorial.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

July 17 & August 13, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

September 22-24, TTCN-3 Tutorial, Berlin (Germany)
Theory and Practice of TTCN-3
www.testingtech.com/services/ttcn3_tutorial.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hello Gyorgy,

I'll give you an example of what I meant:

function f() runs on CompType system SystemType mtc MtcType {
...
}

In this function, self has type CompType, system has type SystemType and
mtc has type MtcType.

Therefore, it would be statically known which ports exist in each of
self, mtc, system. No runtiime checks are
necessary anymore for connection statements.

Basically, I propose to consistently add the possibility of declaring
the types of system and mtc everywhere where
it is necessary.

A function with a system and mtc clause can then only be called from a
function which has a more (or equally) specific mtc and more (or
equally) specific system clause (otherwise, a warning could be generated
or it could be rejected as an error) - which is the same as for the runs
on clause.

A function with a system and mtc clause can only be started an a
component from a context where mtc is of a more (or equally) specific
type than the mtc clause type (either known via the mtc clause of the
calling function or the runs on clause of the calling test case). The
same restriction applies to the system clause.

I really don't see what the runtime aspect has to do with the static
checking of port names.

And yes, of course these clauses should be optional.

More specific answers to your answer can be found inline.

Remaining completely unconvinced,

Jacob

György Réthy wrote:
> Hi Jacob,
>
> I'm lost with your ideas.
>
> "by allowing a *system* clause not only for testcases, but also
> everywhere else where a *runs on* clause (with the same restrictions
> as for
> *runs on*) can be declared." => it is allowed!
I'm talking about system CLAUSE and mtc CLAUSE analogous to the runs on
CLAUSE. Not about the mtc and system handles.
> There is no restriction in using mtc, system and self in any functions
> or altsteps - at least if I have not overlooked something. Anyway, I
> do not understand, how the runs on clause helps compile time checking,
> e.g. in the case
> function MyFunc() runs on MyComp_CT {
> map (mtc:P, system:P)
> }
> You do not even know if the function will be called on the MTC or on a
> PTC.
But, if you had the mtc and system clause, you could check, whether the
given types contain P ports.
>
> "we could introduce an *mtc* clause (analogous to *runs on *and
> *system* clauses, also with the same restrictions) for functions and
> altsteps " => Wouldn't really help. First of all, it should be
> optional for backward compatibility and because there are functions
> which are called on PTCs in different test cases using different MTC
> types (possibly all having e.g. port P!).
Therefore, you would only specify a general mtc type which contains only
those ports which you actually refer to (same as with the runs on).
> Secondly, it would not solve checking the system handle.
It would, if you give a system clause. Giving no system clause would
still have the same behavior as before, if you have one, though, you can
check all ports referenced from the system handle against that type.
> Therefore, you still must check consistency runtime and could give
> max. warnings compile time where the mtc clause exists and the MTC
> does not have the port referred to (anyway, connecting/mapping ports
> without runtime checking is not a healthy thing). So, it could be an
> overkill for still not being able to check everything compile time.
These arguments could be applied to every typed entity in TTCN-3, but
still we use a strictly typed environment (which is a good thing!). The
only exception (I know of) is the mtc and system handles. Lets get rid
of this strange and unnecessary exception.
>
> TTCN-3, by definition, is a distributed test system, therefore it
> sould be clear that the complete system-level consistency can be
> checked runtime only (as I wrote earlier, some cases, e.g. when the
> user handles all test configuration in the MTC, can be checked compile
> time). This is the difference to other (type) checkings, which are
> verifying local consistency (that I agree shall be maximized). As
> ports are connected/mapped via the TM through TCI, all infos about the
> port compatibility are sent around/available anyway.
>
> BR, Gyorgy
>
>
>

---

> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active members
> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Jacob Wieland
> *Sent:* Friday, 20 June, 2008 11:47 AM
> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
> *Subject:* Re: Types of mtc, self, system
>
> Hello folks,
>
> I also think this is an unfortunate situation.
>
> It could be remedied (at least for the system component) by
> allowing a *system* clause not only
> for testcases, but also everywhere else where a *runs on* clause
> (with the same restrictions as for
> *runs on*) can be declared. This way, it would at least be
> possible (without clumsily passing the *system*
> component around as a parameter) for the user to write down
> consistent code which can be checked
> statically.
>
> As an idea, to solve the problem also for *mtc*, we could
> introduce an *mtc* clause (analogous to *runs on*
> and *system* clauses, also with the same restrictions) for
> functions and altsteps (for testcases this would not
> be necessary since there *self* is always equal to *mtc* and
> therefore already declared by the *runs on* clause)
> that should run on ptcs.
>
> This approach would lead to a consistent language design in
> respect to the possibility of static analysis of
> the ports of *system* and *mtc* in configuration statements. Thus,
> the number of warnings that must be
> generated at compile time (and the number of checks that have to
> be done at runtime) could be reduced.
>
> What is your opinion? Should I introduce a CR for this issue?
>
> Best regards,
>
> Jacob Wieland
>
> Michael Sperber wrote:
>> Thanks very much for the prompt answer!
>>
>> György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:
>>
>>
>>> The standard says about this in $21.1.1 "e) Since TTCN 3 allows
>>> dynamic configurations and addresses, not all of these consistency
>>> checks can be made statically at compile-time. All checks, which could
>>> not be made at compile-time, shall be made at run-time and shall lead
>>> to a test case error when failing."
>>>
>>
>>
>>> I think, that a reasonable design decision is to check all connect/map
>>> disconnect/unmap operations dynamically, instead of checking some of
>>> these operations statically and others dynamically. But all tools take
>>> its own decisions...
>>>
>>
>> I had read 2.1.1 e) - the wording seems unnecessarily vague, as it
>> doesn't specify *which* consistency checks an implementation would be
>> allowed to relegate to run-time. Moreover (barring subtype
>> restrictions), most of the rest of the type system is statically
>> decidable - it just seems odd that this bit isn't. It seems, as a
>> compiler writer, I'd even need to track the names of the ports within a
>> component in its run-time representation. Correct?
>>
>>
>
>
> --
>

---

> Jacob Wieland
> Software Engineer
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18
> 10179 Berlin, Germany
>
> Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>

---

>
> UPCOMING EVENTS!
>
> July 17 & August 13, Free TTCN-3 Webinar
> TTCN-3 for Test Automation
> www.testingtech.com/services/ttcn3_webinar.php
>
> September 22-24, TTCN-3 Tutorial, Berlin (Germany)
> Theory and Practice of TTCN-3
> www.testingtech.com/services/ttcn3_tutorial.php
>
>

---

> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
> Handelsregister HRB 77805, Amtsgericht Charlottenburg
> Ust ID Nr.: DE 813 143 070
>
> This e-mail may contain confidential and privileged material for the
> sole use of the intended recipient. Any review, use, distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive for the recipient), please contact
> the sender by reply e-mail and delete all copies of this message.
>
>
>
> --
>

---

> Jacob Wieland
> Software Engineer
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18
> 10179 Berlin, Germany
>
> Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>

---

>
> UPCOMING EVENTS!
>
> July 17 & August 13, Free TTCN-3 Webinar
> TTCN-3 for Test Automation
> www.testingtech.com/services/ttcn3_webinar.php
>
> September 22-24, TTCN-3 Tutorial, Berlin (Germany)
> Theory and Practice of TTCN-3
> www.testingtech.com/services/ttcn3_tutorial.php
>
>

---

> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
> Handelsregister HRB 77805, Amtsgericht Charlottenburg
> Ust ID Nr.: DE 813 143 070
>
> This e-mail may contain confidential and privileged material for the
> sole use of the intended recipient. Any review, use, distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive for the recipient), please contact
> the sender by reply e-mail and delete all copies of this message.
>
>


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

July 17 & August 13, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

September 22-24, TTCN-3 Tutorial, Berlin (Germany)
Theory and Practice of TTCN-3
www.testingtech.com/services/ttcn3_tutorial.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hi Jacob,

In this case you have to check runtime if the function is _really_ called on a test case in which the actual type of the MTC is MtcType and the type of the TSI is SystemType. So, no checking is spared.

Again, these new clauses should be optional, not only for backward compatibility but also because users want to write functions which can be called in different test cases, using different MTC and TCI types. They could extend the possibility _for the user_ to make more checks compile time but I still do not believe that full compile time checking could be possible.

BR, Gyorgy


________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: Friday, 20 June, 2008 2:41 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Types of mtc, self, system


Hello Gyorgy,

I'll give you an example of what I meant:

function f() runs on CompType system SystemType mtc MtcType {
...
}

In this function, self has type CompType, system has type SystemType and mtc has type MtcType.

Therefore, it would be statically known which ports exist in each of self, mtc, system. No runtiime checks are
necessary anymore for connection statements.

Basically, I propose to consistently add the possibility of declaring the types of system and mtc everywhere where
it is necessary.

A function with a system and mtc clause can then only be called from a function which has a more (or equally) specific mtc and more (or equally) specific system clause (otherwise, a warning could be generated or it could be rejected as an error) - which is the same as for the runs on clause.

A function with a system and mtc clause can only be started an a component from a context where mtc is of a more (or equally) specific type than the mtc clause type (either known via the mtc clause of the calling function or the runs on clause of the calling test case). The same restriction applies to the system clause.

I really don't see what the runtime aspect has to do with the static checking of port names.

And yes, of course these clauses should be optional.

More specific answers to your answer can be found inline.

Remaining completely unconvinced,

Jacob

György Réthy wrote:

Hi Jacob,

I'm lost with your ideas.

"by allowing a system clause not only for testcases, but also everywhere else where a runs on clause (with the same restrictions as for
runs on) can be declared." => it is allowed!

I'm talking about system CLAUSE and mtc CLAUSE analogous to the runs on CLAUSE. Not about the mtc and system handles.


There is no restriction in using mtc, system and self in any
functions or altsteps - at least if I have not overlooked something. Anyway, I do not understand, how the runs on clause helps compile time checking, e.g. in the case
function MyFunc() runs on MyComp_CT {
map (mtc:P, system:P)
}
You do not even know if the function will be called on the MTC or on
a PTC.

But, if you had the mtc and system clause, you could check, whether the given types contain P ports.



"we could introduce an mtc clause (analogous to runs on and system clauses, also with the same restrictions) for functions and altsteps " => Wouldn't really help. First of all, it should be optional for backward compatibility and because there are functions which are called on PTCs in different test cases using different MTC types (possibly all having e.g. port P!).

Therefore, you would only specify a general mtc type which contains only those ports which you actually refer to (same as with the runs on).


Secondly, it would not solve checking the system handle.

It would, if you give a system clause. Giving no system clause would still have the same behavior as before, if you have one, though, you can check all ports referenced from the system handle against that type.


Therefore, you still must check consistency runtime and could give max. warnings compile time where the mtc clause exists and the MTC does not have the port referred to (anyway, connecting/mapping ports without runtime checking is not a healthy thing). So, it could be an overkill for still not being able to check everything compile time.

These arguments could be applied to every typed entity in TTCN-3, but still we use a strictly typed environment (which is a good thing!). The only exception (I know of) is the mtc and system handles. Lets get rid of this strange and unnecessary exception.



TTCN-3, by definition, is a distributed test system, therefore it sould be clear that the complete system-level consistency can be checked runtime only (as I wrote earlier, some cases, e.g. when the user handles all test configuration in the MTC, can be checked compile time). This is the difference to other (type) checkings, which are verifying local consistency (that I agree shall be maximized). As ports are connected/mapped via the TM through TCI, all infos about the port compatibility are sent around/available anyway.

BR, Gyorgy



________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active
members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: Friday, 20 June, 2008 11:47 AM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Types of mtc, self, system


Hello folks,

I also think this is an unfortunate situation.

It could be remedied (at least for the system component) by
allowing a system clause not only
for testcases, but also everywhere else where a runs on clause
(with the same restrictions as for
runs on) can be declared. This way, it would at least be
possible (without clumsily passing the system
component around as a parameter) for the user to write down consistent code which can be checked
statically.

As an idea, to solve the problem also for mtc, we could
introduce an mtc clause (analogous to runs on
and system clauses, also with the same restrictions) for
functions and altsteps (for testcases this would not
be necessary since there self is always equal to mtc and
therefore already declared by the runs on clause)
that should run on ptcs.

This approach would lead to a consistent language design in
respect to the possibility of static analysis of
the ports of system and mtc in configuration statements. Thus,
the number of warnings that must be
generated at compile time (and the number of checks that have
to be done at runtime) could be reduced.

What is your opinion? Should I introduce a CR for this issue?

Best regards,

Jacob Wieland

Michael Sperber wrote:

Thanks very much for the prompt answer!

György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:



The standard says about this in $21.1.1 "e) Since
TTCN 3 allows
dynamic configurations and addresses, not all of
these consistency
checks can be made statically at compile-time. All
checks, which could
not be made at compile-time, shall be made at run-
time and shall lead
to a test case error when failing."





I think, that a reasonable design decision is to
check all connect/map
disconnect/unmap operations dynamically, instead
of checking some of
these operations statically and others
dynamically. But all tools take
its own decisions...



I had read 2.1.1 e) - the wording seems unnecessarily
vague, as it
doesn't specify *which* consistency checks an
implementation would be
allowed to relegate to run-time. Moreover (barring
subtype
restrictions), most of the rest of the type system is
statically
decidable - it just seems odd that this bit isn't. It
seems, as a
compiler writer, I'd even need to track the names of the
ports within a
component in its run-time representation. Correct?





--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

UPCOMING EVENTS!

July 17 & August 13, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

September 22-24, TTCN-3 Tutorial, Berlin (Germany)
Theory and Practice of TTCN-3
www.testingtech.com/services/ttcn3_tutorial.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan
Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material
for the
sole use of the intended recipient. Any review, use,
distribution or
disclosure by others is strictly prohibited. If you are not
the intended
recipient (or authorized to receive for the recipient), please
contact
the sender by reply e-mail and delete all copies of this
message.


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

UPCOMING EVENTS!

July 17 & August 13, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

September 22-24, TTCN-3 Tutorial, Berlin (Germany)
Theory and Practice of TTCN-3
www.testingtech.com/services/ttcn3_tutorial.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan
Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material
for the
sole use of the intended recipient. Any review, use,
distribution or
disclosure by others is strictly prohibited. If you are not
the intended
recipient (or authorized to receive for the recipient), please
contact
the sender by reply e-mail and delete all copies of this
message.




--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

July 17 & August 13, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

September 22-24, TTCN-3 Tutorial, Berlin (Germany)
Theory and Practice of TTCN-3
www.testingtech.com/services/ttcn3_tutorial.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hello Jacob and Gyorgy,

I support Gyorgy's point that such additional clauses have to be optional. Firstly, for the sake of backwards compatibility. Secondly, most functions/altsteps do not need to know the mtc nor system. Even more they should not know these entities. Refering to mtc and system always means to make assumptions on the environment or context, and in my opinion this should be avoided as much as possible.

Jacob's suggestion should be considered together with extensions regarding configurations. Jacob, you might simply add a note to CR2143 t-ort.etsi.org/view.php?id=2143, such that your proposal is not forgotten.

Best regards

Thomas



________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext György Réthy
Sent: Friday, 20. June 2008 14:53
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Types of mtc, self, system


Hi Jacob,

In this case you have to check runtime if the function is _really_ called on a test case in which the actual type of the MTC is MtcType and the type of the TSI is SystemType. So, no checking is spared.

Again, these new clauses should be optional, not only for backward compatibility but also because users want to write functions which can be called in different test cases, using different MTC and TCI types. They could extend the possibility _for the user_ to make more checks compile time but I still do not believe that full compile time checking could be possible.

BR, Gyorgy


________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: Friday, 20 June, 2008 2:41 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Types of mtc, self, system


Hello Gyorgy,

I'll give you an example of what I meant:

function f() runs on CompType system SystemType mtc MtcType {
...
}

In this function, self has type CompType, system has type SystemType
and mtc has type MtcType.

Therefore, it would be statically known which ports exist in each of
self, mtc, system. No runtiime checks are
necessary anymore for connection statements.

Basically, I propose to consistently add the possibility of
declaring the types of system and mtc everywhere where
it is necessary.

A function with a system and mtc clause can then only be called from
a function which has a more (or equally) specific mtc and more (or equally) specific system clause (otherwise, a warning could be generated or it could be rejected as an error) - which is the same as for the runs on clause.

A function with a system and mtc clause can only be started an a component from a context where mtc is of a more (or equally) specific type than the mtc clause type (either known via the mtc clause of the calling function or the runs on clause of the calling test case). The same restriction applies to the system clause.

I really don't see what the runtime aspect has to do with the static
checking of port names.

And yes, of course these clauses should be optional.

More specific answers to your answer can be found inline.

Remaining completely unconvinced,

Jacob

György Réthy wrote:

Hi Jacob,

I'm lost with your ideas.

"by allowing a system clause not only for testcases, but also
everywhere else where a runs on clause (with the same restrictions as for
runs on) can be declared." => it is allowed!

I'm talking about system CLAUSE and mtc CLAUSE analogous to the runs
on CLAUSE. Not about the mtc and system handles.


There is no restriction in using mtc, system and self in any functions or altsteps - at least if I have not overlooked something. Anyway, I do not understand, how the runs on clause helps compile time checking, e.g. in the case
function MyFunc() runs on MyComp_CT {
map (mtc:P, system:P)
}
You do not even know if the function will be called on the MTC
or on a PTC.

But, if you had the mtc and system clause, you could check, whether
the given types contain P ports.



"we could introduce an mtc clause (analogous to runs on and
system clauses, also with the same restrictions) for functions and altsteps " => Wouldn't really help. First of all, it should be optional for backward compatibility and because there are functions which are called on PTCs in different test cases using different MTC types (possibly all having e.g. port P!).

Therefore, you would only specify a general mtc type which contains
only those ports which you actually refer to (same as with the runs on).


Secondly, it would not solve checking the system handle.

It would, if you give a system clause. Giving no system clause would
still have the same behavior as before, if you have one, though, you can check all ports referenced from the system handle against that type.


Therefore, you still must check consistency runtime and could
give max. warnings compile time where the mtc clause exists and the MTC does not have the port referred to (anyway, connecting/mapping ports without runtime checking is not a healthy thing). So, it could be an overkill for still not being able to check everything compile time.

These arguments could be applied to every typed entity in TTCN-3,
but still we use a strictly typed environment (which is a good thing!). The only exception (I know of) is the mtc and system handles. Lets get rid of this strange and unnecessary exception.



TTCN-3, by definition, is a distributed test system, therefore
it sould be clear that the complete system-level consistency can be checked runtime only (as I wrote earlier, some cases, e.g. when the user handles all test configuration in the MTC, can be checked compile time). This is the difference to other (type) checkings, which are verifying local consistency (that I agree shall be maximized). As ports are connected/mapped via the TM through TCI, all infos about the port compatibility are sent around/available anyway.

BR, Gyorgy



________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active
members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: Friday, 20 June, 2008 11:47 AM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Types of mtc, self, system


Hello folks,

I also think this is an unfortunate situation.

It could be remedied (at least for the system component)
by allowing a system clause not only
for testcases, but also everywhere else where a runs on
clause (with the same restrictions as for
runs on) can be declared. This way, it would at least be
possible (without clumsily passing the system
component around as a parameter) for the user to write
down consistent code which can be checked
statically.

As an idea, to solve the problem also for mtc, we could
introduce an mtc clause (analogous to runs on
and system clauses, also with the same restrictions) for
functions and altsteps (for testcases this would not
be necessary since there self is always equal to mtc and
therefore already declared by the runs on clause)
that should run on ptcs.

This approach would lead to a consistent language design
in respect to the possibility of static analysis of
the ports of system and mtc in configuration statements.
Thus, the number of warnings that must be
generated at compile time (and the number of checks that
have to be done at runtime) could be reduced.

What is your opinion? Should I introduce a CR for this
issue?

Best regards,

Jacob Wieland

Michael Sperber wrote:

Thanks very much for the prompt answer!

György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:



The standard says about this in $21.1.1 "e) Since
TTCN 3 allows
dynamic configurations and addresses, not all of
these consistency
checks can be made statically at compile-time. All
checks, which could
not be made at compile-time, shall be made at run-
time and shall lead
to a test case error when failing."





I think, that a reasonable design decision is to
check all connect/map
disconnect/unmap operations dynamically, instead
of checking some of
these operations statically and others
dynamically. But all tools take
its own decisions...



I had read 2.1.1 e) - the wording seems
unnecessarily vague, as it
doesn't specify *which* consistency checks an
implementation would be
allowed to relegate to run-time. Moreover
(barring subtype
restrictions), most of the rest of the type system
is statically
decidable - it just seems odd that this bit isn't.
It seems, as a
compiler writer, I'd even need to track the names
of the ports within a
component in its run-time representation.
Correct?





--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

UPCOMING EVENTS!

July 17 & August 13, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

September 22-24, TTCN-3 Tutorial, Berlin (Germany)
Theory and Practice of TTCN-3
www.testingtech.com/services/ttcn3_tutorial.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles,
Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged
material for the
sole use of the intended recipient. Any review, use,
distribution or
disclosure by others is strictly prohibited. If you are
not the intended
recipient (or authorized to receive for the recipient),
please contact
the sender by reply e-mail and delete all copies of this
message.


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

UPCOMING EVENTS!

July 17 & August 13, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

September 22-24, TTCN-3 Tutorial, Berlin (Germany)
Theory and Practice of TTCN-3
www.testingtech.com/services/ttcn3_tutorial.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles,
Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged
material for the
sole use of the intended recipient. Any review, use,
distribution or
disclosure by others is strictly prohibited. If you are
not the intended
recipient (or authorized to receive for the recipient),
please contact
the sender by reply e-mail and delete all copies of this
message.




--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email
This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

July 17 & August 13, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

September 22-24, TTCN-3 Tutorial, Berlin (Germany)
Theory and Practice of TTCN-3
www.testingtech.com/services/ttcn3_tutorial.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please
contact
the sender by reply e-mail and delete all copies of this message.

Thanks Thomas,

I will do that.

And, as I already said, the clauses should be optional (in my opinion,
too) for backwards compatiblity.

Secondly, I agree that mappings to system ports will always have to be
checked at runtime, too, but inter-component connections (between self
and mtc) could very well be checked at compile-time (using proposed
clauses) and runtime-checking for them spared.

Thirdly, the clauses would only need to be added to functions which want
to make connections/mappings between mtc, self, system, so these clauses
would have to be used sparingly anyway. Only when the type of the
entity-to-be-connected is statically known in both the calling and the
called scope, an error can be generated at compile-time, otherwise,
accessing a potentially non-existing port should only generate a warning.

Finally, the open-testsystem-specification argument is not really valid
as it is very well possible to define and use general component types
which only comprise those ports that are actually mentioned due to the
component type compatibility rules. Therefore, it would still be
possible to define open test systems where every configuration statement
is still statically checkable.

Best regards,

Jacob

Thomas Deiss wrote:
> Hello Jacob and Gyorgy,
>
> I support Gyorgy's point that such additional clauses have to be
> optional. Firstly, for the sake of backwards compatibility. Secondly,
> most functions/altsteps do not need to know the mtc nor system. Even
> more they should not know these entities. Refering to mtc and system
> always means to make assumptions on the environment or context, and in
> my opinion this should be avoided as much as possible.
>
> Jacob's suggestion should be considered together with extensions
> regarding configurations. Jacob, you might simply add a note to CR2143
> t-ort.etsi.org/view.php?id=2143, such that your proposal is not
> forgotten.
>
> Best regards
>
> Thomas
>
>
>

---

> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active members
> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *ext György Réthy
> *Sent:* Friday, 20. June 2008 14:53
> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
> *Subject:* Re: Types of mtc, self, system
>
> Hi Jacob,
>
> In this case you have to check runtime if the function is _really_
> called on a test case in which the actual type of the MTC
> is MtcType and the type of the TSI is SystemType. So, no checking
> is spared.
>
> Again, these new clauses should be optional, not only for backward
> compatibility but also because users want to write functions which
> can be called in different test cases, using different MTC and TCI
> types. They could extend the possibility _for the user_ to make
> more checks compile time but I still do not believe that full
> compile time checking could be possible.
>
> BR, Gyorgy
>
>

---

> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Jacob
> Wieland
> *Sent:* Friday, 20 June, 2008 2:41 PM
> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
> *Subject:* Re: Types of mtc, self, system
>
> Hello Gyorgy,
>
> I'll give you an example of what I meant:
>
> function f() runs on CompType system SystemType mtc MtcType {
> ...
> }
>
> In this function, self has type CompType, system has type
> SystemType and mtc has type MtcType.
>
> Therefore, it would be statically known which ports exist in
> each of self, mtc, system. No runtiime checks are
> necessary anymore for connection statements.
>
> Basically, I propose to consistently add the possibility of
> declaring the types of system and mtc everywhere where
> it is necessary.
>
> A function with a system and mtc clause can then only be
> called from a function which has a more (or equally) specific
> mtc and more (or equally) specific system clause (otherwise, a
> warning could be generated or it could be rejected as an
> error) - which is the same as for the runs on clause.
>
> A function with a system and mtc clause can only be started an
> a component from a context where mtc is of a more (or equally)
> specific type than the mtc clause type (either known via the
> mtc clause of the calling function or the runs on clause of
> the calling test case). The same restriction applies to the
> system clause.
>
> I really don't see what the runtime aspect has to do with the
> static checking of port names.
>
> And yes, of course these clauses should be optional.
>
> More specific answers to your answer can be found inline.
>
> Remaining completely unconvinced,
>
> Jacob
>
> György Réthy wrote:
>> Hi Jacob,
>>
>> I'm lost with your ideas.
>>
>> "by allowing a *system* clause not only for testcases, but
>> also everywhere else where a *runs on* clause (with the same
>> restrictions as for
>> *runs on*) can be declared." => it is allowed!
> I'm talking about system CLAUSE and mtc CLAUSE analogous to
> the runs on CLAUSE. Not about the mtc and system handles.
>> There is no restriction in using mtc, system and self in any
>> functions or altsteps - at least if I have not overlooked
>> something. Anyway, I do not understand, how the runs on
>> clause helps compile time checking, e.g. in the case
>> function MyFunc() runs on MyComp_CT {
>> map (mtc:P, system:P)
>> }
>> You do not even know if the function will be called on the
>> MTC or on a PTC.
> But, if you had the mtc and system clause, you could check,
> whether the given types contain P ports.
>>
>> "we could introduce an *mtc* clause (analogous to *runs on
>> *and *system* clauses, also with the same restrictions) for
>> functions and altsteps " => Wouldn't really help. First of
>> all, it should be optional for backward compatibility and
>> because there are functions which are called on PTCs in
>> different test cases using different MTC types (possibly all
>> having e.g. port P!).
> Therefore, you would only specify a general mtc type which
> contains only those ports which you actually refer to (same as
> with the runs on).
>> Secondly, it would not solve checking the system handle.
> It would, if you give a system clause. Giving no system clause
> would still have the same behavior as before, if you have one,
> though, you can check all ports referenced from the system
> handle against that type.
>> Therefore, you still must check consistency runtime and could
>> give max. warnings compile time where the mtc clause exists
>> and the MTC does not have the port referred to (anyway,
>> connecting/mapping ports without runtime checking is not a
>> healthy thing). So, it could be an overkill for still not
>> being able to check everything compile time.
> These arguments could be applied to every typed entity in
> TTCN-3, but still we use a strictly typed environment (which
> is a good thing!). The only exception (I know of) is the mtc
> and system handles. Lets get rid of this strange and
> unnecessary exception.
>>
>> TTCN-3, by definition, is a distributed test system,
>> therefore it sould be clear that the complete system-level
>> consistency can be checked runtime only (as I wrote
>> earlier, some cases, e.g. when the user handles all test
>> configuration in the MTC, can be checked compile time). This
>> is the difference to other (type) checkings, which are
>> verifying local consistency (that I agree shall be
>> maximized). As ports are connected/mapped via the TM through
>> TCI, all infos about the port compatibility are sent
>> around/available anyway.
>>
>> BR, Gyorgy
>>
>>
>>

---

>> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active
>> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of
>> *Jacob Wieland
>> *Sent:* Friday, 20 June, 2008 11:47 AM
>> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
>> *Subject:* Re: Types of mtc, self, system
>>
>> Hello folks,
>>
>> I also think this is an unfortunate situation.
>>
>> It could be remedied (at least for the system component)
>> by allowing a *system* clause not only
>> for testcases, but also everywhere else where a *runs on*
>> clause (with the same restrictions as for
>> *runs on*) can be declared. This way, it would at least
>> be possible (without clumsily passing the *system*
>> component around as a parameter) for the user to write
>> down consistent code which can be checked
>> statically.
>>
>> As an idea, to solve the problem also for *mtc*, we could
>> introduce an *mtc* clause (analogous to *runs on*
>> and *system* clauses, also with the same restrictions)
>> for functions and altsteps (for testcases this would not
>> be necessary since there *self* is always equal to *mtc*
>> and therefore already declared by the *runs on* clause)
>> that should run on ptcs.
>>
>> This approach would lead to a consistent language design
>> in respect to the possibility of static analysis of
>> the ports of *system* and *mtc* in configuration
>> statements. Thus, the number of warnings that must be
>> generated at compile time (and the number of checks that
>> have to be done at runtime) could be reduced.
>>
>> What is your opinion? Should I introduce a CR for this issue?
>>
>> Best regards,
>>
>> Jacob Wieland
>>
>> Michael Sperber wrote:
>>> Thanks very much for the prompt answer!
>>>
>>> György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:
>>>
>>>
>>>> The standard says about this in $21.1.1 "e) Since TTCN 3 allows
>>>> dynamic configurations and addresses, not all of these consistency
>>>> checks can be made statically at compile-time. All checks, which could
>>>> not be made at compile-time, shall be made at run-time and shall lead
>>>> to a test case error when failing."
>>>>
>>>
>>>
>>>> I think, that a reasonable design decision is to check all connect/map
>>>> disconnect/unmap operations dynamically, instead of checking some of
>>>> these operations statically and others dynamically. But all tools take
>>>> its own decisions...
>>>>
>>>
>>> I had read 2.1.1 e) - the wording seems unnecessarily vague, as it
>>> doesn't specify *which* consistency checks an implementation would be
>>> allowed to relegate to run-time. Moreover (barring subtype
>>> restrictions), most of the rest of the type system is statically
>>> decidable - it just seems odd that this bit isn't. It seems, as a
>>> compiler writer, I'd even need to track the names of the ports within a
>>> component in its run-time representation. Correct?
>>>
>>>
>>
>>
>> --
>>

---

>> Jacob Wieland
>> Software Engineer
>>
>> Testing Technologies IST GmbH
>> Michaelkirchstraße 17/18
>> 10179 Berlin, Germany
>>
>> Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>>

---

>>
>> UPCOMING EVENTS!
>>
>> July 17 & August 13, Free TTCN-3 Webinar
>> TTCN-3 for Test Automation
>> www.testingtech.com/services/ttcn3_webinar.php
>>
>> September 22-24, TTCN-3 Tutorial, Berlin (Germany)
>> Theory and Practice of TTCN-3
>> www.testingtech.com/services/ttcn3_tutorial.php
>>
>>

---

>> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
>> Handelsregister HRB 77805, Amtsgericht Charlottenburg
>> Ust ID Nr.: DE 813 143 070
>>
>> This e-mail may contain confidential and privileged material for the
>> sole use of the intended recipient. Any review, use, distribution or
>> disclosure by others is strictly prohibited. If you are not the intended
>> recipient (or authorized to receive for the recipient), please contact
>> the sender by reply e-mail and delete all copies of this message.
>>
>>
>>
>> --
>>

---

>> Jacob Wieland
>> Software Engineer
>>
>> Testing Technologies IST GmbH
>> Michaelkirchstraße 17/18
>> 10179 Berlin, Germany
>>
>> Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>>

---

>>
>> UPCOMING EVENTS!
>>
>> July 17 & August 13, Free TTCN-3 Webinar
>> TTCN-3 for Test Automation
>> www.testingtech.com/services/ttcn3_webinar.php
>>
>> September 22-24, TTCN-3 Tutorial, Berlin (Germany)
>> Theory and Practice of TTCN-3
>> www.testingtech.com/services/ttcn3_tutorial.php
>>
>>

---

>> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
>> Handelsregister HRB 77805, Amtsgericht Charlottenburg
>> Ust ID Nr.: DE 813 143 070
>>
>> This e-mail may contain confidential and privileged material for the
>> sole use of the intended recipient. Any review, use, distribution or
>> disclosure by others is strictly prohibited. If you are not the intended
>> recipient (or authorized to receive for the recipient), please contact
>> the sender by reply e-mail and delete all copies of this message.
>>
>>
>
>
> --
>

---

> Jacob Wieland
> Software Engineer
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18
> 10179 Berlin, Germany
>
> Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>

---

>
> UPCOMING EVENTS!
>
> July 17 & August 13, Free TTCN-3 Webinar
> TTCN-3 for Test Automation
> www.testingtech.com/services/ttcn3_webinar.php
>
> September 22-24, TTCN-3 Tutorial, Berlin (Germany)
> Theory and Practice of TTCN-3
> www.testingtech.com/services/ttcn3_tutorial.php
>
>

---

> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
> Handelsregister HRB 77805, Amtsgericht Charlottenburg
> Ust ID Nr.: DE 813 143 070
>
> This e-mail may contain confidential and privileged material for the
> sole use of the intended recipient. Any review, use, distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive for the recipient), please contact
> the sender by reply e-mail and delete all copies of this message.
>
>


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

July 17 & August 13, Free TTCN-3 Webinar
TTCN-3 for Test Automation
www.testingtech.com/services/ttcn3_webinar.php

September 22-24, TTCN-3 Tutorial, Berlin (Germany)
Theory and Practice of TTCN-3
www.testingtech.com/services/ttcn3_tutorial.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:

> "most of the rest of the type system is statically decidable - it just
> seems odd that this bit isn't." => if you think about it, it is
> not. First, the TSI and the MTC are created and started implicitly [...]

Many thanks for explaining!

Now, am I right in assuming that a reference to "self" that occurs in a
function with a "runs on" clause always resolves to a component of the
"runs on" type?

Are there rules governing the calls between two
functions/altsteps/whatever, each of which have a "runs on" clause? I
was assuming that the associated component types have to be compatible,
but I see this example from the Blue Book:

www.wiley.com//legacy/wileychi/ttcn-3/supp/tupleSpace.ttcn

The alt_procCreate altstep, running on TsCompProc, calls the
f_processCreateReq function, running on TsComp:

altstep alt_procCreate () runs on TsCompProc {
[...]
if ( f_processCreateReq( name, keyPos, id, errorCode ) ) {

function f_processCreateReq ( in TupleSpaceName p_v_name,
in KeyPos p_v_keyPos,
inout TupleSpaceId p_v_id,
inout ErrorCode p_v_errorCode )
runs on TsComp [...]

Here's the TsComp component type:

// specific port type
type port TsPort message { inout TsPrims };

// the server component type
type component TsComp {
port TsPort g_pt_ts;
var Worker g_v_sender;
var TupleSpaceList g_v_tupleSpaces
} //endtype component TsComp

Here's the TsCompProc component type:

type port TsPortProc procedure {
inout CreateProc;
inout IdProc
}

type component TsCompProc {
port TsPortProc g_pt_ts;
var Worker g_v_sender;
var TupleSpaceList g_v_tupleSpaces
}

These component types are incompatible (right)? What's the semantics of
the call, then? If it's legal, what if the callee tries to access
g_pt_ts, which has the wrong dynamic type?

--
Regards,
Mike

Hi Mike,

From the runs on clause you do not know the type of the actual component instance a function/altstep will be called on but you always can check statically if the self is used correctly within the concrete testcase/function/altstep. This is because you can call e.g. a function on a component instance that is a superset of what is defined in the runs on clause of the function.

I think in this respect the standard is clear ($6.3.3):
"2) Runs on compatibility: a function or altsteps referring to component type "A" in its runs on clause may be called or started on a component instance of type 'B' if all the definitions of "A" have identical definitions in "B".
Identity of definitions in "A" with definitions of "B" is determined based on the following rules:
a) For port instances both the type and the identifier shall be identical.
b) For timer instances identifiers shall be the identical and either both shall have identical initial durations or both shall have no initial duration.
c) For variable instances and constant definitions the identifiers, the types and initialization values shall be the identical (in case of variables this means that either missing in both definitions or be the same).
d) For local template definitions the identifiers, the types, the formal parameter lists and the assigned template or template field values shall be identical."

From the above it is clear that the example is not a correct TTCN-3 code, as - just you mentioned - TsComp (used in the runs on clause of f_processCreateReq) is not compatible with TsCompProc (used in the runs on clause of alt_procCreate) -> the type of port g_pt_ts differs.


BR, Gyorgy

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Michael Sperber
> Sent: Monday, 30 June, 2008 2:15 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Types of mtc, self, system
>
> György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:
>
> > "most of the rest of the type system is statically
> decidable - it just
> > seems odd that this bit isn't." => if you think about it,
> it is not.
> > First, the TSI and the MTC are created and started implicitly [...]
>
> Many thanks for explaining!
>
> Now, am I right in assuming that a reference to "self" that
> occurs in a function with a "runs on" clause always resolves
> to a component of the "runs on" type?
>
> Are there rules governing the calls between two
> functions/altsteps/whatever, each of which have a "runs on"
> clause? I was assuming that the associated component types
> have to be compatible, but I see this example from the Blue Book:
>
> www.wiley.com//legacy/wileychi/ttcn-3/supp/tupleSpace.ttcn
>
> The alt_procCreate altstep, running on TsCompProc, calls the
> f_processCreateReq function, running on TsComp:
>
> altstep alt_procCreate () runs on TsCompProc {
> [...]
> if ( f_processCreateReq( name, keyPos, id, errorCode ) ) {
>
> function f_processCreateReq ( in TupleSpaceName p_v_name,
> in KeyPos p_v_keyPos,
> inout TupleSpaceId p_v_id,
> inout ErrorCode
> p_v_errorCode )
> runs on TsComp [...]
>
> Here's the TsComp component type:
>
> // specific port type
> type port TsPort message { inout TsPrims };
>
> // the server component type
> type component TsComp {
> port TsPort g_pt_ts;
> var Worker g_v_sender;
> var TupleSpaceList g_v_tupleSpaces
> } //endtype component TsComp
>
> Here's the TsCompProc component type:
>
> type port TsPortProc procedure {
> inout CreateProc;
> inout IdProc
> }
>
> type component TsCompProc {
> port TsPortProc g_pt_ts;
> var Worker g_v_sender;
> var TupleSpaceList g_v_tupleSpaces
> }
>
> These component types are incompatible (right)? What's the
> semantics of the call, then? If it's legal, what if the
> callee tries to access g_pt_ts, which has the wrong dynamic type?
>
> --
> Regards,
> Mike
>