Hi Frederique, hi Ina, hi all others,
there were two reasons not to allow local variables in test steps:
1. we tried to minimize the syntactial changes when changing from named
alternatives to test steps
2. we tried to avoid the possible side-effects when a local variable is
instantiated (note, the initial value might be the result of a
function
call).
The top alternative in a test step is considered something like the
continuation of the alternative in which the test step is called
(either
explicitly or implicitly by the default mechanism).
As side effects during the instantiation of a local test step
variable the following things to consider may happen:
(a) the guards of the following alternatives may be changed
(b) the snapshot may be changed, e.g., by restarting or stopping an
expired timer
which may remove timeouts from the timeout list.
However, the points 1 and 2(a) I don't consider as big problems. For the
resolution
of point 2(b), we would need some static rules disallowing all
operations that
potentially change the snapshot. These operations will be for example,
all receiving
operations, timer operations that potentially remove timeouts from the
list and also
port control operations that clear ports.
In most cases, noone will even think of using a variable instantiation
with such
ugly side effects and such a rule will cause no problem. My personal
concern is that
we will have an(other) exceptional rule for variable instantiation in
test steps.
Merry Christmas and a happy new Year!
Jens
Frederique Aurouet schrieb:
>
> Dear I did not realize too, and it has been used every where in SIP ATS....
> I completly agree Ina, we need it absolutly!
>
> Best regards
>
> Frederique
>
>
Original Message
> From: I. Schieferdecker [
This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 20 December 2001 10:12
> To:
This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Local variables within test steps
>
> Dear all,
>
> we realized that TTCN-3 does not allow local variables within test steps.
> However, it would be very useful to allow it, for example to store an
> incoming
> message or to do some internal calculations.
>
> An example would be
>
> teststep ATMN0_UNEXPECTED(...) runs on MTC
> {
> var STAT STAT_LocalVar;
> ...
> alt {
> [] T.receive(ST_R2V) -> value STAT_LocalVar
> { ...}
> ...
> }
> }
>
> This would mean to change the BNF not only to enable local declarations but
> also e.g. to have an alt statement instead of just an alt guard list. Well,
> the second point is a matter of taste, but we think that for readability it
> would be better to have the alt keyword within a teststep definition.
>
> Looking forward to receive your comments.
>
> With best regards,
>
> Ina.
>
>
> Ina Schieferdecker
> Fraunhofer FOKUS email:
This email address is being protected from spambots. You need JavaScript enabled to view it.
> Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
> D-10589 Berlin fax: ++49-30-3463-8241
>
--
======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail:
This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or
This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW:
www.itm.mu-luebeck.de
======================================================================
