Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: Issues and problems with TTCN-3

Issues and problems with TTCN-3 19 Sep 2001 11:13 #5933

Hi,

from our tools development the following issues have been highlighted:

1) What is the scope of component variables?
If I execute a function on a test component and that function has
no runs on clause can this function 'see' the component variables?
The issue here is that the scope for ports is clearly stated in the
standard
i.e. if no runs on is defined the ports must be passed as parameters
into
the function. For variables it is not stated and if they have global
scope
within the component.

2) At present the start operation can use a function without a runs on
clause.
It is stated that all necessary information must be passed in as
parameters.
Can this function 'see' the component variables without them being
passed in as parameters?
How could I pass component variable (or for that matter ports and
timers) as
parameters?

At present the parameters to the function do not allow reference to the
component
instance. i.e.

At present I can write something like (NB syntax wrong):

type component PTC {
port X;
variable Y;
}

function Fn01( port PCO1){
...
}

testcase TC01 {
CompRef := create( PTC);

CompRef.start( Fn01(X));
}

the question is how can I know what X here is referring to? In my
opinion it should
be qualified with the component ref i.e.

CompRef.start( Fn01(CompRef.X));

In a similar way we could reference timers and variables from the
component instance
as actual parameters into the function.

2) at present the BNF allows the runs on parameter in a testcase or
function to take
the value mtc. This is in my opinion wrong.

3)At present the with statement allows the attribute to be specified for
a particular
type identifier. It should be clarified that the type identifier option
may only be
used on user defined types which are included within the body of the
enclosing structure associated with the with statement (i.e. group or
module). It may not be used to refer to
the type identifiers within type definitions or templates (in this case
the field reference shall be used).


}
The administrator has disabled public write access.

Issues and problems with TTCN-3 19 Sep 2001 14:06 #5934

On Wed, 19 Sep 2001, Willcock Colin wrote:

> Hi,
>
> from our tools development the following issues have been highlighted:
>
> 1) What is the scope of component variables?
> If I execute a function on a test component and that function has
> no runs on clause can this function 'see' the component variables?
> The issue here is that the scope for ports is clearly stated in the
> standard
> i.e. if no runs on is defined the ports must be passed as parameters
> into
> the function. For variables it is not stated and if they have global
> scope
> within the component.

I think it would be very bad style if in any scope any identifiers
should be known which are not explicitely added to the scope
by either the parameters or members of the runs on component type
(i.e. component ports, timers, constants, and variables).

Otherwise, a proper context/typecheck it is not easily feasable
(if at all) at compile-time (because a function with a missing
runs on has different semantics dependent on the point of
invocation) and thus a lot more would have to be done at runtime.

It also would make specifications unreadable
and programming error-prone (if you mis-type a port-name it is
not clear if that port does not exist because you mistyped it or
because it is hallucinated into the scope implicitely).

> 2) At present the start operation can use a function without a runs on
> clause.
> It is stated that all necessary information must be passed in as
> parameters.
> Can this function 'see' the component variables without them being
> passed in as parameters?

I would think not. As the function sees only those ports and
timers of the component type on which it runs, this should also
apply for constants and variables.

> How could I pass component variable (or for that matter ports and
> timers) as parameters?

If that is not allowed by the standard it should be added to pass
parameters of all (predefined and user defined) types to functions.
It is probably intended, anyway as there can be component variables.
Why should there not be port or timer variables as well?
(and parameters are only a kind of variable, after all).
In any implementation, these entities should, of course, ALWAYS be
passed call-by-reference (and not copied).

I don't know if signature parameters should be an exception, but
I don't see any particular reason why references to components,
ports and timers should not also be passed to another component
or the SUT.

> At present the parameters to the function do not allow reference to the
> component instance. i.e.
>
> At present I can write something like (NB syntax wrong):
>
> type component PTC {
> port X;
> variable Y;
> }
>
> function Fn01( port PCO1){
> ...
> }
>
> testcase TC01 {
> CompRef := create( PTC);
>
> CompRef.start( Fn01(X));
> }
>
> the question is how can I know what X here is referring to? In my
> opinion it should
> be qualified with the component ref i.e.

Yes, it must be as the testcase does not run on PTC,
but only creates one.

> CompRef.start( Fn01(CompRef.X));
>
> In a similar way we could reference timers and variables from the
> component instance as actual parameters into the function.
>
> 2) at present the BNF allows the runs on parameter in a testcase or
> function to take the value mtc. This is in my opinion wrong.

I often wondered what this should mean and up till now
came only to the conclusion that the 'any component' type is
meant (i.e. that without any members). But I agree with your
assessment. If a function/testcase/teststep should run on
any component, it should leave out its 'runs on' clause.

Jacob Wieland, Compiler Construction - TU-Berlin
The administrator has disabled public write access.

Issues and problems with TTCN-3 19 Sep 2001 14:57 #5935

Hi,

> I think it would be very bad style if in any scope any identifiers
> should be known which are not explicitely added to the scope
> by either the parameters or members of the runs on component type

I agree 100% with Jacob. The 'runs on' directive as far as I can see,
is meant to provide the scope. If it's not there, the function should
not know anything about the component on which it is running.

Regards,
/Johan

Original Message
From: Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 19 september 2001 16:06
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Issues and problems with TTCN-3


On Wed, 19 Sep 2001, Willcock Colin wrote:

> Hi,
>
> from our tools development the following issues have been highlighted:
>
> 1) What is the scope of component variables?
> If I execute a function on a test component and that function has
> no runs on clause can this function 'see' the component variables?
> The issue here is that the scope for ports is clearly stated in the
> standard
> i.e. if no runs on is defined the ports must be passed as parameters
> into
> the function. For variables it is not stated and if they have global
> scope
> within the component.

I think it would be very bad style if in any scope any identifiers
should be known which are not explicitely added to the scope
by either the parameters or members of the runs on component type
(i.e. component ports, timers, constants, and variables).

Otherwise, a proper context/typecheck it is not easily feasable
(if at all) at compile-time (because a function with a missing
runs on has different semantics dependent on the point of
invocation) and thus a lot more would have to be done at runtime.

It also would make specifications unreadable
and programming error-prone (if you mis-type a port-name it is
not clear if that port does not exist because you mistyped it or
because it is hallucinated into the scope implicitely).

> 2) At present the start operation can use a function without a runs on
> clause.
> It is stated that all necessary information must be passed in as
> parameters.
> Can this function 'see' the component variables without them being
> passed in as parameters?

I would think not. As the function sees only those ports and
timers of the component type on which it runs, this should also
apply for constants and variables.

> How could I pass component variable (or for that matter ports and
> timers) as parameters?

If that is not allowed by the standard it should be added to pass
parameters of all (predefined and user defined) types to functions.
It is probably intended, anyway as there can be component variables.
Why should there not be port or timer variables as well?
(and parameters are only a kind of variable, after all).
In any implementation, these entities should, of course, ALWAYS be
passed call-by-reference (and not copied).

I don't know if signature parameters should be an exception, but
I don't see any particular reason why references to components,
ports and timers should not also be passed to another component
or the SUT.

> At present the parameters to the function do not allow reference to the
> component instance. i.e.
>
> At present I can write something like (NB syntax wrong):
>
> type component PTC {
> port X;
> variable Y;
> }
>
> function Fn01( port PCO1){
> ...
> }
>
> testcase TC01 {
> CompRef := create( PTC);
>
> CompRef.start( Fn01(X));
> }
>
> the question is how can I know what X here is referring to? In my
> opinion it should
> be qualified with the component ref i.e.

Yes, it must be as the testcase does not run on PTC,
but only creates one.

> CompRef.start( Fn01(CompRef.X));
>
> In a similar way we could reference timers and variables from the
> component instance as actual parameters into the function.
>
> 2) at present the BNF allows the runs on parameter in a testcase or
> function to take the value mtc. This is in my opinion wrong.

I often wondered what this should mean and up till now
came only to the conclusion that the 'any component' type is
meant (i.e. that without any members). But I agree with your
assessment. If a function/testcase/teststep should run on
any component, it should leave out its 'runs on' clause.

Jacob Wieland, Compiler Construction - TU-Berlin
The administrator has disabled public write access.
  • Page:
  • 1

FacebookTwitterGoogle BookmarksRedditNewsvineTechnoratiLinkedin