TOPIC:

Hello all,

I have been looking at the TTCN-2 to TTCN-3 mapping and there is one
thing that still bogs my mind: At several discussions at ETSI and
here on the mailing, we have said that TTCN-2 test suite variables
does not have any correspondence in TTCN-3. For this reason, test
cases (TTCN-2) using TSVar:s supposedly couldn't be mapped to TTCN-3.

But, how about this:

module A
{

testcase t1 ( inout integer foo )
{
...
}

testcase t2 ( inout integer foo )
{
...
}

...

control
{
var X integer = 42; // This is our 'TSVar'

execute(t1(X));
execute(t2(X));

...
}
}


Wouldn't this provide the same functionality as TSVar:s w.r.t
passing values between test cases or have I missed something?

Season's greetings
/Johan

---

Telelogic Tau 4.3 - makes requirements visible during
UML development!
Read more about it at www.telelogic.com/tau43

---

Johan Nordin
Standardization Specialist, Uppsala Development Lab
Telelogic AB
S:t Persgatan 13
SE-75320 Uppsala, Sweden

Phone: +46 18 661865
Fax: +46 18 661870
Mobile: +46 706 424711

This email address is being protected from spambots. You need JavaScript enabled to view it.
www.telelogic.com

---

Telelogic - Putting you ahead in software development!

---

In einer eMail vom 12/21/01 2:47:15 PM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:


> Hello all,
>
> I have been looking at the TTCN-2 to TTCN-3 mapping and there is one
> thing that still bogs my mind: At several discussions at ETSI and
> here on the mailing, we have said that TTCN-2 test suite variables
> does not have any correspondence in TTCN-3. For this reason, test
> cases (TTCN-2) using TSVar:s supposedly couldn't be mapped to TTCN-3.
>
> But, how about this:
>
> module A
> {
>
> testcase t1 ( inout integer foo )
> {
> ...
> }
>
> testcase t2 ( inout integer foo )
> {
> ...
> }
>
> ...
>
> control
> {
> var X integer = 42; // This is our 'TSVar'
>
> execute(t1(X));
> execute(t2(X));
>
> ...
> }
> }
>
>
> Wouldn't this provide the same functionality as TSVar:s w.r.t
> passing values between test cases or have I missed something?
>
> Season's greetings
> /Johan

Hi Johan,
This sounds like a solution, but it is far from being a realistic
solution to TSVars. Can you imagine using this solution for
ATSs that have hundreds of TSVars???

Cheers,

Claude.

Yes I can,

This could be realized by collecting all TSVar:s in a record or similar and
pass this record
to all test cases using any of the TSVar:s in the test suite. This way it
would only add one
parameter to each concerned test case.

What do you think?

/Johan

---

Original Message

---

From: Claude Desroches [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 23 december 2001 21:57
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TTCN-2 TS Var:s and its TTCN-3 counterpart


In einer eMail vom 12/21/01 2:47:15 PM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:




Hello all,

I have been looking at the TTCN-2 to TTCN-3 mapping and there is one
thing that still bogs my mind: At several discussions at ETSI and
here on the mailing, we have said that TTCN-2 test suite variables
does not have any correspondence in TTCN-3. For this reason, test
cases (TTCN-2) using TSVar:s supposedly couldn't be mapped to TTCN-3.

But, how about this:

module A
{

testcase t1 ( inout integer foo )
{
...
}

testcase t2 ( inout integer foo )
{
...
}

...

control
{
var X integer = 42; // This is our 'TSVar'

execute(t1(X));
execute(t2(X));

...
}
}


Wouldn't this provide the same functionality as TSVar:s w.r.t
passing values between test cases or have I missed something?

Season's greetings
/Johan



Hi Johan,
This sounds like a solution, but it is far from being a realistic
solution to TSVars. Can you imagine using this solution for
ATSs that have hundreds of TSVars???

Cheers,

Claude.

Claude Desroches wrote:

> Hi Johan,
> This sounds like a solution, but it is far from being a realistic
> solution to TSVars. Can you imagine using this solution for
> ATSs that have hundreds of TSVars???

Dear Claude,

I hope you are having a great Christmans and that Santa was good to
you ;-)

I have to back up Johan on this one. To answer your question with a
new one...in what way does TTCN 2 provide a better solution for this?

I modern programing theory, it is a very well accepted fact that it is
very bad programming style to communicate between software modules/parts
using global variables. C and C++ allow the user to have such variables
and use them, but you see them used in this way very rarely.

I do agree that I think it is a limitation that TTCN 3 does not have
globabl variables, but it is nothing that limits the user in any way.

My two cents...

Best regards,

Fedde

---

Original Message

---

From: Johan Nordin [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: Thursday, December 27, 2001 10:23 AM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TTCN-2 TS Var:s and its TTCN-3 counterpart


Yes I can,

This could be realized by collecting all TSVar:s in a record or similar and
pass this record
to all test cases using any of the TSVar:s in the test suite. This way it
would only add one
parameter to each concerned test case.

What do you think?

/Johan

---

Original Message

---

From: Claude Desroches [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 23 december 2001 21:57
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TTCN-2 TS Var:s and its TTCN-3 counterpart


In einer eMail vom 12/21/01 2:47:15 PM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:




Hello all,

I have been looking at the TTCN-2 to TTCN-3 mapping and there is one
thing that still bogs my mind: At several discussions at ETSI and
here on the mailing, we have said that TTCN-2 test suite variables
does not have any correspondence in TTCN-3. For this reason, test
cases (TTCN-2) using TSVar:s supposedly couldn't be mapped to TTCN-3.

But, how about this:

module A
{

testcase t1 ( inout integer foo )
{
...
}

testcase t2 ( inout integer foo )
{
...
}

...

control
{
var X integer = 42; // This is our 'TSVar'

execute(t1(X));
execute(t2(X));

...
}
}


Wouldn't this provide the same functionality as TSVar:s w.r.t
passing values between test cases or have I missed something?

Season's greetings
/Johan



Hi Johan,
This sounds like a solution, but it is far from being a realistic
solution to TSVars. Can you imagine using this solution for
ATSs that have hundreds of TSVars???

Cheers,

Claude.

Hi all,

Just to clarify; the example I presented is in no way intended as a
recommended
TTCN-3 programming style but rather a way to translate TTCN-2 test suites to
TTCN-3. The alternative is to say that all test suites (or at least, all
test cases)
using Test Suite Variables cannot be ported to the new language, and I don't
think
that would impress TTCN users who are considering moving to the new
generation.

By the way, happy new year to y'all !
/Johan

---

Original Message

---

From: Frederico Engler [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 27 december 2001 14:26
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TTCN-2 TS Var:s and its TTCN-3 counterpart


Claude Desroches wrote:

> Hi Johan,
> This sounds like a solution, but it is far from being a realistic
> solution to TSVars. Can you imagine using this solution for
> ATSs that have hundreds of TSVars???

Dear Claude,

I hope you are having a great Christmans and that Santa was good to
you ;-)

I have to back up Johan on this one. To answer your question with a
new one...in what way does TTCN 2 provide a better solution for this?

I modern programing theory, it is a very well accepted fact that it is
very bad programming style to communicate between software modules/parts
using global variables. C and C++ allow the user to have such variables
and use them, but you see them used in this way very rarely.

I do agree that I think it is a limitation that TTCN 3 does not have
globabl variables, but it is nothing that limits the user in any way.

My two cents...

Best regards,

Fedde

---

Original Message

---

From: Johan Nordin [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: Thursday, December 27, 2001 10:23 AM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TTCN-2 TS Var:s and its TTCN-3 counterpart


Yes I can,

This could be realized by collecting all TSVar:s in a record or similar and
pass this record
to all test cases using any of the TSVar:s in the test suite. This way it
would only add one
parameter to each concerned test case.

What do you think?

/Johan

---

Original Message

---

From: Claude Desroches [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 23 december 2001 21:57
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TTCN-2 TS Var:s and its TTCN-3 counterpart


In einer eMail vom 12/21/01 2:47:15 PM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:




Hello all,

I have been looking at the TTCN-2 to TTCN-3 mapping and there is one
thing that still bogs my mind: At several discussions at ETSI and
here on the mailing, we have said that TTCN-2 test suite variables
does not have any correspondence in TTCN-3. For this reason, test
cases (TTCN-2) using TSVar:s supposedly couldn't be mapped to TTCN-3.

But, how about this:

module A
{

testcase t1 ( inout integer foo )
{
...
}

testcase t2 ( inout integer foo )
{
...
}

...

control
{
var X integer = 42; // This is our 'TSVar'

execute(t1(X));
execute(t2(X));

...
}
}


Wouldn't this provide the same functionality as TSVar:s w.r.t
passing values between test cases or have I missed something?

Season's greetings
/Johan



Hi Johan,
This sounds like a solution, but it is far from being a realistic
solution to TSVars. Can you imagine using this solution for
ATSs that have hundreds of TSVars???

Cheers,

Claude.

In einer eMail vom 12/27/01 2:46:18 PM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi Fedde!

>
>
>
>
>
> Claude Desroches wrote:
>
> > Hi Johan,
> > This sounds like a solution, but it is far from being a realistic
> > solution to TSVars. Can you imagine using this solution for
> > ATSs that have hundreds of TSVars???
>
> Dear Claude,
>
> I hope you are having a great Christmans and that Santa was good to
> you ;-)
>

Christmas has come and gone, and Santa will hopefully be
good to me when I visit my family in February.


> I have to back up Johan on this one. To answer your question with a
> new one...in what way does TTCN 2 provide a better solution for this?
>

Well, the question is not whether TTCN2 provides a better
solution, but rather one of transformation. If someone wishes
to transform a TTCN2 ATS into an equivalent TTCN3 ATS,
from a functionality point of view, you do need global variables.


> I modern programing theory, it is a very well accepted fact that it is
> very bad programming style to communicate between software modules/parts
> using global variables. C and C++ allow the user to have such variables
> and use them, but you see them used in this way very rarely.
>
I'm also of the opinion that global variables should be avoided,
and that the ultimate way of preventing them from being used
is to not provide them in a language. :-). Global variables when
used often times allow for unexpected and undesirable side effects, not to
mention that they also make the understanding
of an application (non trivial one albeit) much more difficult
IMHO.

In any case, whether global variables or other, someone will or
can always think of a way to misuse or abuse a language feature.



> I do agree that I think it is a limitation that TTCN 3 does not have
> globabl variables, but it is nothing that limits the user in any way.
>
> My two cents...
>

My two (Euro) cents :-).

Cheers,

Claude.



> Best regards,
>
> Fedde
>
>

In einer eMail vom 12/27/01 10:32:53 AM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:


Hi Johan,

>
> Yes I can,
>
> This could be realized by collecting all TSVar:s in a record or similar and
> pass this record
> to all test cases using any of the TSVar:s in the test suite. This way it
> would only add one
> parameter to each concerned test case.
>

That approach did cross my mind, however what would this mean from
an implementation point of view? For C or C++ it would be sufficient to
pass a pointer, however, how would that be achieved efficiently in Java,
or other languages that do not support pointers? Copying of a huge
data structure onto the heap/stack is not so efficient :-).


> What do you think?
>

See above.



> /Johan
>
>
Cheers,


Claude.

Hello Claude, I trust you have enjoyed the holidays?

> For C or C++ it would be sufficient to
> pass a pointer, however, how would that be achieved efficiently in Java,
> or other languages that do not support pointers? Copying of a huge
> data structure onto the heap/stack is not so efficient :-).

Ah, there's a great argument why we should all use C rather than Java :-)
No, seriously, you are absolutely right, but I think the problem is
academic:
Keep in mind that we are only talking about existing TTCN-2 test suites that
are to be converted into TTCN-3. Today, these test suites are used for
generating C code (there's no realistic alternative). The users are likely
to
have written other code to be compiled with the generated C code, like
encoders/decoders, user I/F etc.
If this is to be reused, the user would have to go for a C solution in their

TTCN-3 system as well.

Cheers,
/Johan

---

Original Message

---

From: Claude Desroches [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 28 december 2001 19:46
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TTCN-2 TS Var:s and its TTCN-3 counterpart


In einer eMail vom 12/27/01 10:32:53 AM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:


Hi Johan,




Yes I can,

This could be realized by collecting all TSVar:s in a record or similar and
pass this record
to all test cases using any of the TSVar:s in the test suite. This way it
would only add one
parameter to each concerned test case.




That approach did cross my mind, however what would this mean from
an implementation point of view? For C or C++ it would be sufficient to
pass a pointer, however, how would that be achieved efficiently in Java,
or other languages that do not support pointers? Copying of a huge
data structure onto the heap/stack is not so efficient :-).




What do you think?




See above.





/Johan




Cheers,


Claude.

In einer eMail vom 1/2/02 10:41:29 AM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:


> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
>

Hi Johan,


>
> Hello Claude, I trust you have enjoyed the holidays?
>

Yep, and they keep going, and going and going!


> > For C or C++ it would be sufficient to
> > pass a pointer, however, how would that be achieved efficiently in Java,
> > or other languages that do not support pointers? Copying of a huge
> > data structure onto the heap/stack is not so efficient :-).
>
> Ah, there's a great argument why we should all use C rather than Java :-)
> No, seriously, you are absolutely right, but I think the problem is
> academic:
>
I fully agree given the fact that the need for global variables is only to
allow
2 to 3 transformation. One can always choose to transform as much
as possible from TTCN-2 to TTCN-3 then redesign any parts related
to global variables directly in TTCN-3. Who says that the transformation
needs to be 100% automated? (It is better of course, but then again,
how much of a problem does or will it present). The likely situation is that
most existing TTCN-2 ATSs will continue to be maintained using TTCN-2,
and only new ATSs will be developed from scratch using TTCN-3.

Only in rare cases will there be a real need to transform an existing
ATS from TTCN2 to TTCN-3 to take advantage of TTCN-3 features. In most
cases however, I suspect that the cheapest and easiest approach will
be to keep the apples with the apples and plant some orange trees.
(apples = TTCN2) orange trees = TTCN3). :-).
ATS needs
Keep in mind that we are only talking about existing TTCN-2 test suites that
>
> are to be converted into TTCN-3. Today, these test suites are used for
> generating C code (there's no realistic alternative). The users are likely
> to
> have written other code to be compiled with the generated C code, like
> encoders/decoders, user I/F etc.
> If this is to be reused, the user would have to go for a C solution in
> their
> TTCN-3 system as well.
>

Egads, now wouldn't that be nice and portable :-) You can
kiss the security of intended operational semantic benefits
good-bye in this case.


Cheers, (and ho ho ho!!!!)

Claude.


> Cheers,
> /Johan
>
>

On Fri, 28 Dec 2001, Claude Desroches wrote:

> In einer eMail vom 12/27/01 10:32:53 AM W. Europe Standard Time schreibt
> This email address is being protected from spambots. You need JavaScript enabled to view it.:
>
>
> Hi Johan,
>
> >
> > Yes I can,
> >
> > This could be realized by collecting all TSVar:s in a record or similar and
> > pass this record
> > to all test cases using any of the TSVar:s in the test suite. This way it
> > would only add one
> > parameter to each concerned test case.
> >
>
> That approach did cross my mind, however what would this mean from
> an implementation point of view? For C or C++ it would be sufficient to
> pass a pointer, however, how would that be achieved efficiently in Java,
> or other languages that do not support pointers? Copying of a huge
> data structure onto the heap/stack is not so efficient :-).

As I don't know which kind of Java you are talking about, I am
very happy to report that the newest version of Java (and all before
that) support Object References, where an Object Reference is a pointer
to a structure (quite similar to a struct in C). Actually, it is the
same concept that is used in C++.

As passing something as an inout-parameter is like passing it by
reference which is like passing a pointer, in Java this would be
realized by passing an object reference.
No copying (except of the reference) is required.

Cheers, Jacob

In einer eMail vom 1/7/02 6:16:33 PM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi Jacob,

Thanks for the clarification.

Cheers,

Claude.


> In einer eMail vom 12/27/01 10:32:53 AM W. Europe Standard Time schreibt
> > This email address is being protected from spambots. You need JavaScript enabled to view it.:
> >
> >
> > Hi Johan,
> >
> > >
> > > Yes I can,
> > >
> > > This could be realized by collecting all TSVar:s in a record or similar
> and
> > > pass this record
> > > to all test cases using any of the TSVar:s in the test suite. This way
> it
> > > would only add one
> > > parameter to each concerned test case.
> > >
> >
> > That approach did cross my mind, however what would this mean from
> > an implementation point of view? For C or C++ it would be sufficient to
> > pass a pointer, however, how would that be achieved efficiently in Java,
> > or other languages that do not support pointers? Copying of a huge
> > data structure onto the heap/stack is not so efficient :-).
>
> As I don't know which kind of Java you are talking about, I am
> very happy to report that the newest version of Java (and all before
> that) support Object References, where an Object Reference is a pointer
> to a structure (quite similar to a struct in C). Actually, it is the
> same concept that is used in C++.
>
> As passing something as an inout-parameter is like passing it by
> reference which is like passing a pointer, in Java this would be
> realized by passing an object reference.
> No copying (except of the reference) is required.
>
> Cheers, Jacob
>
>
>