Hello all!

Here are some comments about global data.

Cheung Ray-RCHEUNG1 wrote:

> This discussion touches on something that I've always regarded as a bit of
> an impediment in TTCN-3. That is the disallowance of global data, which, if
> I understand correctly, is due to consideration for TTCN-3 vendors
> implementing on a process-based, as opposed to a thread-based,
> environment/operating system.

The TTCN-3 allows some global data, for example:
o module parameters
o constants defined in a module
o external constants

What is missing, are "global variables."

The TTCN modules has been traditionally based on interconnected test
components that communicate with each other using inter-process like
coordination points and coordination messages (in TTCN-3 these are
just "connected" ports and normal messages exchanged between these
ports.

Introduction of global variables would limit the implementation options
of test components and the applicability of TTCN-3 to various different
types of testing proposed.

The current test component model of TTCN-3, allows implementation of the
tools using either local (test components withing the same process
space) or distributed architecture (test components are running in
different processes in the same or remote PCs).

Introduction of dynamic creation of test components using the "create"
statement allows specification of testers that create a large number
of test components for load or performance testing purposes, or
for some other reason.

In my opinion, the inter test component communication should be limited
to traffic between ports, implicit verdict updates, and the indication
of the end of the test execution. This would keep the TTCN-3 as widely
applicable as possible, and keeps the implementation options open.


> It seems an unfortunate side effect is that issues like those identified by
> György (and other issues that I can think of) require unnatural solutions,
> such as using extra PTCs to keep track data. For me, I'm using external
> functions to do the job because a lot of times, I only require an MTC and
> don't want the complication of PTCs and passing forwards and backwards of
> unnecessary messages and cluttering up my code.

Are you saying that you use only MTC?

If you would need to preserve data between execution of different test
cases, could you use local variables defined in the control part?

Or are you proposing actually that there would be variables that would
hold data accessible within one test component, but from one test case
to another. These would correspond to the test suite variables of
TTCN-2, and would not break the current TTCN model, but would be
just a little bit against of common software engineering principles.

> So the question is, why not allow global data and let the process-based
> TTCN-3 vendors (are there that many of them anyway?) tackle the issue of
> global data (writing to files, or passing messages to an auxiliary process
> that maintains global data, etc). I know that, for at least 2
> implementations (Telelogic Tau G2 Tester and Testing Technologies), this
> should not be a problem because they are or can be thread-based. I think the
> natural solution of allowing global data would benefit everyone using TTCN-3
> in the long run.

For a couple of years, we (OpenTTCN) have been implementing TTCN using
an implementation where test components are distributed to different
processes within one PC or to multiple PCs. If necessary these test
components can be implemented within one process and its address space
too.

Now in the implementation of TTCN-3, we see that the current
architecture of TTCN-3 gives a powerful mechanisms for the test suite
writers when appropriate tools are used.

Best regards,
Vesa-Matti

--
Vesa-Matti Puro
E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Tel.: +358 440396461
OpenTTCN Oy
Web: www.openttcn.com

Dear all,

I want to support the views expressed by Thomas and Vesa-Matti. TTCN-3
has currently a clear concept of test components and the exchange of
information between test components via connected ports. Either the
introduction of global variables or the addition of implicit connected
ports between a test component and its creating or all other test
components would only complicate things. The gain (in length of TTCN-3
code) possible in some cases is paid by the impliciteness and additional
assumptions about the concurrent execution of test components.

Cheers, Ina.

Vesa-Matti Puro wrote:
> Hello all!
>
> Here are some comments about global data.
>
> Cheung Ray-RCHEUNG1 wrote:
>
>> This discussion touches on something that I've always regarded as a
>> bit of
>> an impediment in TTCN-3. That is the disallowance of global data,
>> which, if
>> I understand correctly, is due to consideration for TTCN-3 vendors
>> implementing on a process-based, as opposed to a thread-based,
>> environment/operating system.
>
>
> The TTCN-3 allows some global data, for example:
> o module parameters
> o constants defined in a module
> o external constants
>
> What is missing, are "global variables."
>
> The TTCN modules has been traditionally based on interconnected test
> components that communicate with each other using inter-process like
> coordination points and coordination messages (in TTCN-3 these are
> just "connected" ports and normal messages exchanged between these
> ports.
>
> Introduction of global variables would limit the implementation options
> of test components and the applicability of TTCN-3 to various different
> types of testing proposed.
>
> The current test component model of TTCN-3, allows implementation of the
> tools using either local (test components withing the same process
> space) or distributed architecture (test components are running in
> different processes in the same or remote PCs).
>
> Introduction of dynamic creation of test components using the "create"
> statement allows specification of testers that create a large number
> of test components for load or performance testing purposes, or
> for some other reason.
>
> In my opinion, the inter test component communication should be limited
> to traffic between ports, implicit verdict updates, and the indication
> of the end of the test execution. This would keep the TTCN-3 as widely
> applicable as possible, and keeps the implementation options open.
>
>
>> It seems an unfortunate side effect is that issues like those
>> identified by
>> György (and other issues that I can think of) require unnatural
>> solutions,
>> such as using extra PTCs to keep track data. For me, I'm using external
>> functions to do the job because a lot of times, I only require an MTC and
>> don't want the complication of PTCs and passing forwards and backwards of
>> unnecessary messages and cluttering up my code.
>
>
> Are you saying that you use only MTC?
>
> If you would need to preserve data between execution of different test
> cases, could you use local variables defined in the control part?
>
> Or are you proposing actually that there would be variables that would
> hold data accessible within one test component, but from one test case
> to another. These would correspond to the test suite variables of
> TTCN-2, and would not break the current TTCN model, but would be
> just a little bit against of common software engineering principles.
>
>> So the question is, why not allow global data and let the process-based
>> TTCN-3 vendors (are there that many of them anyway?) tackle the issue of
>> global data (writing to files, or passing messages to an auxiliary
>> process
>> that maintains global data, etc). I know that, for at least 2
>> implementations (Telelogic Tau G2 Tester and Testing Technologies), this
>> should not be a problem because they are or can be thread-based. I
>> think the
>> natural solution of allowing global data would benefit everyone using
>> TTCN-3
>> in the long run.
>
>
> For a couple of years, we (OpenTTCN) have been implementing TTCN using
> an implementation where test components are distributed to different
> processes within one PC or to multiple PCs. If necessary these test
> components can be implemented within one process and its address space
> too.
>
> Now in the implementation of TTCN-3, we see that the current
> architecture of TTCN-3 gives a powerful mechanisms for the test suite
> writers when appropriate tools are used.
>
> Best regards,
> Vesa-Matti
>
> --
> Vesa-Matti Puro
> E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Tel.: +358 440396461
> OpenTTCN Oy
> Web: www.openttcn.com


--

---

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

---

Dear All,

Yes, Vesa-Matti is quite right. I forgot about the option of distributing
load to remote PCs, which obviously does not go at all well with the global
variables suggestion. Please consider the suggestion retracted, and thanks
for reminding me of it.

Best Regards

Ray Cheung

---

Original Message

---

From: Ina Schieferdecker [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 23 September 2003 09:58
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Extension of DONE operation / global variables


Dear all,

I want to support the views expressed by Thomas and Vesa-Matti. TTCN-3
has currently a clear concept of test components and the exchange of
information between test components via connected ports. Either the
introduction of global variables or the addition of implicit connected
ports between a test component and its creating or all other test
components would only complicate things. The gain (in length of TTCN-3
code) possible in some cases is paid by the impliciteness and additional
assumptions about the concurrent execution of test components.

Cheers, Ina.

Vesa-Matti Puro wrote:
> Hello all!
>
> Here are some comments about global data.
>
> Cheung Ray-RCHEUNG1 wrote:
>
>> This discussion touches on something that I've always regarded as a
>> bit of
>> an impediment in TTCN-3. That is the disallowance of global data,
>> which, if
>> I understand correctly, is due to consideration for TTCN-3 vendors
>> implementing on a process-based, as opposed to a thread-based,
>> environment/operating system.
>
>
> The TTCN-3 allows some global data, for example:
> o module parameters
> o constants defined in a module
> o external constants
>
> What is missing, are "global variables."
>
> The TTCN modules has been traditionally based on interconnected test
> components that communicate with each other using inter-process like
> coordination points and coordination messages (in TTCN-3 these are
> just "connected" ports and normal messages exchanged between these
> ports.
>
> Introduction of global variables would limit the implementation options
> of test components and the applicability of TTCN-3 to various different
> types of testing proposed.
>
> The current test component model of TTCN-3, allows implementation of the
> tools using either local (test components withing the same process
> space) or distributed architecture (test components are running in
> different processes in the same or remote PCs).
>
> Introduction of dynamic creation of test components using the "create"
> statement allows specification of testers that create a large number
> of test components for load or performance testing purposes, or
> for some other reason.
>
> In my opinion, the inter test component communication should be limited
> to traffic between ports, implicit verdict updates, and the indication
> of the end of the test execution. This would keep the TTCN-3 as widely
> applicable as possible, and keeps the implementation options open.
>
>
>> It seems an unfortunate side effect is that issues like those
>> identified by
>> György (and other issues that I can think of) require unnatural
>> solutions,
>> such as using extra PTCs to keep track data. For me, I'm using external
>> functions to do the job because a lot of times, I only require an MTC and
>> don't want the complication of PTCs and passing forwards and backwards of
>> unnecessary messages and cluttering up my code.
>
>
> Are you saying that you use only MTC?
>
> If you would need to preserve data between execution of different test
> cases, could you use local variables defined in the control part?
>
> Or are you proposing actually that there would be variables that would
> hold data accessible within one test component, but from one test case
> to another. These would correspond to the test suite variables of
> TTCN-2, and would not break the current TTCN model, but would be
> just a little bit against of common software engineering principles.
>
>> So the question is, why not allow global data and let the process-based
>> TTCN-3 vendors (are there that many of them anyway?) tackle the issue of
>> global data (writing to files, or passing messages to an auxiliary
>> process
>> that maintains global data, etc). I know that, for at least 2
>> implementations (Telelogic Tau G2 Tester and Testing Technologies), this
>> should not be a problem because they are or can be thread-based. I
>> think the
>> natural solution of allowing global data would benefit everyone using
>> TTCN-3
>> in the long run.
>
>
> For a couple of years, we (OpenTTCN) have been implementing TTCN using
> an implementation where test components are distributed to different
> processes within one PC or to multiple PCs. If necessary these test
> components can be implemented within one process and its address space
> too.
>
> Now in the implementation of TTCN-3, we see that the current
> architecture of TTCN-3 gives a powerful mechanisms for the test suite
> writers when appropriate tools are used.
>
> Best regards,
> Vesa-Matti
>
> --
> Vesa-Matti Puro
> E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Tel.: +358 440396461
> OpenTTCN Oy
> Web: www.openttcn.com


--

---

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

---

Hi,

Ina, I'm lost what is the view Thomas expressed? He (btw. correctly) analysed different situations. But I could not have found any view (or even pro or contra) in his mail. Yes, the user shall use this feature with knowledge and care - but this is true for many other TTCN-3 features.

Ina's statement "TTCN-3 has currently a clear concept of test components and the exchange of information between test components via connected ports" sounds well but unfortunately has not much to do with the given topic (except that today this is the only option for the user).:
1. Ina, would you clarify pls. what do you mean on "implicit connected ports"? I cannot find something like this in mails before yours and has nothing to do with the value returning done proposal either.
2. When you write
AnotherPTC.done;
the status information regarding the another PTC's status is not communicated via a port.
Also: create, start(component), running, stop(component) are all a form of inter-component communication handled by the test system (and we could list here mtc and system used in a PTC) and not via communication ports. Value returning done is about to add one more information (not even an operation) to the EXISTING inter-component communication model. It has nothing to do with global variables or with a different model than specified today.



I would like also to draw the attention to another aspect that I think much more important.
The use of co-ordination messages between components is rather inconvenient & peevish for the USER. However, no other mean when TIMING is important (so when really used for co-ordination between components). But do not force the USER to nasty solutions (like external functions as Cheung Ray mentioned) when timing is unimportant. That's annoying and do not increase the popularity of TTCN-3.

I often cannot get rid of the feeling (as with this discussion) that tool providers care about nice & simple tool implementation ONLY and do forget about USERs' convenience and usability of the language. This discussion should be about what users wish to see in the language and not about what tool implementers wish to implement. Only those features should be criticized by tool implementers which are technically really non-implementable (that I believe is NOT the case for value returning done even - as Thomas pointed out - the type of the returned value can be checked run-time).

PS: In my examples I have written "When the SCCP connection is handled by a PTC..."; so it should be clear that when giving example for the use of value returning done, I'm talking about how to get the value out of the PTC (by the MTC) and not how to save it between test cases (for the example to work both is needed, of course)

BR, Gyorgy

>

---

Original Message

---

> From: Ina Schieferdecker [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Tuesday, September 23, 2003 10:58 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Extension of DONE operation / global variables
>
>
> Dear all,
>
> I want to support the views expressed by Thomas and
> Vesa-Matti. TTCN-3
> has currently a clear concept of test components and the exchange of
> information between test components via connected ports. Either the
> introduction of global variables or the addition of implicit
> connected
> ports between a test component and its creating or all other test
> components would only complicate things. The gain (in length
> of TTCN-3
> code) possible in some cases is paid by the impliciteness and
> additional
> assumptions about the concurrent execution of test components.
>
> Cheers, Ina.
>
> Vesa-Matti Puro wrote:
> > Hello all!
> >
> > Here are some comments about global data.
> >
> > Cheung Ray-RCHEUNG1 wrote:
> >
> >> This discussion touches on something that I've always
> regarded as a
> >> bit of
> >> an impediment in TTCN-3. That is the disallowance of global data,
> >> which, if
> >> I understand correctly, is due to consideration for TTCN-3 vendors
> >> implementing on a process-based, as opposed to a thread-based,
> >> environment/operating system.
> >
> >
> > The TTCN-3 allows some global data, for example:
> > o module parameters
> > o constants defined in a module
> > o external constants
> >
> > What is missing, are "global variables."
> >
> > The TTCN modules has been traditionally based on interconnected test
> > components that communicate with each other using inter-process like
> > coordination points and coordination messages (in TTCN-3 these are
> > just "connected" ports and normal messages exchanged between these
> > ports.
> >
> > Introduction of global variables would limit the
> implementation options
> > of test components and the applicability of TTCN-3 to
> various different
> > types of testing proposed.
> >
> > The current test component model of TTCN-3, allows
> implementation of the
> > tools using either local (test components withing the same process
> > space) or distributed architecture (test components are running in
> > different processes in the same or remote PCs).
> >
> > Introduction of dynamic creation of test components using
> the "create"
> > statement allows specification of testers that create a large number
> > of test components for load or performance testing purposes, or
> > for some other reason.
> >
> > In my opinion, the inter test component communication
> should be limited
> > to traffic between ports, implicit verdict updates, and the
> indication
> > of the end of the test execution. This would keep the
> TTCN-3 as widely
> > applicable as possible, and keeps the implementation options open.
> >
> >
> >> It seems an unfortunate side effect is that issues like those
> >> identified by
> >> György (and other issues that I can think of) require unnatural
> >> solutions,
> >> such as using extra PTCs to keep track data. For me, I'm
> using external
> >> functions to do the job because a lot of times, I only
> require an MTC and
> >> don't want the complication of PTCs and passing forwards
> and backwards of
> >> unnecessary messages and cluttering up my code.
> >
> >
> > Are you saying that you use only MTC?
> >
> > If you would need to preserve data between execution of
> different test
> > cases, could you use local variables defined in the control part?
> >
> > Or are you proposing actually that there would be variables
> that would
> > hold data accessible within one test component, but from
> one test case
> > to another. These would correspond to the test suite variables of
> > TTCN-2, and would not break the current TTCN model, but would be
> > just a little bit against of common software engineering principles.
> >
> >> So the question is, why not allow global data and let the
> process-based
> >> TTCN-3 vendors (are there that many of them anyway?)
> tackle the issue of
> >> global data (writing to files, or passing messages to an auxiliary
> >> process
> >> that maintains global data, etc). I know that, for at least 2
> >> implementations (Telelogic Tau G2 Tester and Testing
> Technologies), this
> >> should not be a problem because they are or can be thread-based. I
> >> think the
> >> natural solution of allowing global data would benefit
> everyone using
> >> TTCN-3
> >> in the long run.
> >
> >
> > For a couple of years, we (OpenTTCN) have been implementing
> TTCN using
> > an implementation where test components are distributed to different
> > processes within one PC or to multiple PCs. If necessary these test
> > components can be implemented within one process and its
> address space
> > too.
> >
> > Now in the implementation of TTCN-3, we see that the current
> > architecture of TTCN-3 gives a powerful mechanisms for the
> test suite
> > writers when appropriate tools are used.
> >
> > Best regards,
> > Vesa-Matti
> >
> > --
> > Vesa-Matti Puro
> > E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Tel.: +358 440396461
> > OpenTTCN Oy
> > Web: www.openttcn.com
>
>
> --
>

---

>

---

> 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
>

---

>

---

>

Hello György,

you observed quite correctly that I mainly stated some issues, but I neither argued in the one or other direction.

That I do not have an example means also that so far I did not miss the ability to return a value from a function started on a PTC as a return value instead of sending it by a message.

There should be no real technical problems for tool vendors, if it is possible to distribute to other components whether a ptc has finished, then it should be no problem to distribute a return value also.

In terms of convenience for the user: Yes, such a return value could be convenient, even if I did not miss it so far. But on the other, so far a function or altstep could just stop the component without caring about return values. With a return value, one has to take care that whenever the behaviour terminates a return value is returned or no return value is returned. Personally -- as a user -- I would therefore most probably stick to the already available mechanism of sending messages.

Best regards

Thomas

>

---

Original Message

---

> From: ext György Réthy (IJ/ETH) [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Tuesday, September 23, 2003 4:37 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Extension of DONE operation / global variables
>
>
> Hi,
>
> Ina, I'm lost what is the view Thomas expressed? He (btw.
> correctly) analysed different situations. But I could not
> have found any view (or even pro or contra) in his mail. Yes,
> the user shall use this feature with knowledge and care - but
> this is true for many other TTCN-3 features.
>
> Ina's statement "TTCN-3 has currently a clear concept of test
> components and the exchange of information between test
> components via connected ports" sounds well but unfortunately
> has not much to do with the given topic (except that today
> this is the only option for the user).:
> 1. Ina, would you clarify pls. what do you mean on "implicit
> connected ports"? I cannot find something like this in mails
> before yours and has nothing to do with the value returning
> done proposal either.
> 2. When you write
> AnotherPTC.done;
> the status information regarding the another PTC's status is
> not communicated via a port.
> Also: create, start(component), running, stop(component) are
> all a form of inter-component communication handled by the
> test system (and we could list here mtc and system used in a
> PTC) and not via communication ports. Value returning done is
> about to add one more information (not even an operation) to
> the EXISTING inter-component communication model. It has
> nothing to do with global variables or with a different model
> than specified today.
>
>
>
> I would like also to draw the attention to another aspect
> that I think much more important.
> The use of co-ordination messages between components is
> rather inconvenient & peevish for the USER. However, no other
> mean when TIMING is important (so when really used for
> co-ordination between components). But do not force the USER
> to nasty solutions (like external functions as Cheung Ray
> mentioned) when timing is unimportant. That's annoying and do
> not increase the popularity of TTCN-3.
>
> I often cannot get rid of the feeling (as with this
> discussion) that tool providers care about nice & simple tool
> implementation ONLY and do forget about USERs' convenience
> and usability of the language. This discussion should be
> about what users wish to see in the language and not about
> what tool implementers wish to implement. Only those features
> should be criticized by tool implementers which are
> technically really non-implementable (that I believe is NOT
> the case for value returning done even - as Thomas pointed
> out - the type of the returned value can be checked run-time).
>
> PS: In my examples I have written "When the SCCP connection
> is handled by a PTC..."; so it should be clear that when
> giving example for the use of value returning done, I'm
> talking about how to get the value out of the PTC (by the
> MTC) and not how to save it between test cases (for the
> example to work both is needed, of course)
>
> BR, Gyorgy
>
> >

---

Original Message

---

> > From: Ina Schieferdecker [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > Sent: Tuesday, September 23, 2003 10:58 AM
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Re: Extension of DONE operation / global variables
> >
> >
> > Dear all,
> >
> > I want to support the views expressed by Thomas and
> > Vesa-Matti. TTCN-3
> > has currently a clear concept of test components and the
> exchange of
> > information between test components via connected ports. Either the
> > introduction of global variables or the addition of implicit
> > connected
> > ports between a test component and its creating or all other test
> > components would only complicate things. The gain (in length
> > of TTCN-3
> > code) possible in some cases is paid by the impliciteness and
> > additional
> > assumptions about the concurrent execution of test components.
> >
> > Cheers, Ina.
> >
> > Vesa-Matti Puro wrote:
> > > Hello all!
> > >
> > > Here are some comments about global data.
> > >
> > > Cheung Ray-RCHEUNG1 wrote:
> > >
> > >> This discussion touches on something that I've always
> > regarded as a
> > >> bit of
> > >> an impediment in TTCN-3. That is the disallowance of
> global data,
> > >> which, if
> > >> I understand correctly, is due to consideration for
> TTCN-3 vendors
> > >> implementing on a process-based, as opposed to a thread-based,
> > >> environment/operating system.
> > >
> > >
> > > The TTCN-3 allows some global data, for example:
> > > o module parameters
> > > o constants defined in a module
> > > o external constants
> > >
> > > What is missing, are "global variables."
> > >
> > > The TTCN modules has been traditionally based on
> interconnected test
> > > components that communicate with each other using
> inter-process like
> > > coordination points and coordination messages (in TTCN-3 these are
> > > just "connected" ports and normal messages exchanged between these
> > > ports.
> > >
> > > Introduction of global variables would limit the
> > implementation options
> > > of test components and the applicability of TTCN-3 to
> > various different
> > > types of testing proposed.
> > >
> > > The current test component model of TTCN-3, allows
> > implementation of the
> > > tools using either local (test components withing the same process
> > > space) or distributed architecture (test components are running in
> > > different processes in the same or remote PCs).
> > >
> > > Introduction of dynamic creation of test components using
> > the "create"
> > > statement allows specification of testers that create a
> large number
> > > of test components for load or performance testing purposes, or
> > > for some other reason.
> > >
> > > In my opinion, the inter test component communication
> > should be limited
> > > to traffic between ports, implicit verdict updates, and the
> > indication
> > > of the end of the test execution. This would keep the
> > TTCN-3 as widely
> > > applicable as possible, and keeps the implementation options open.
> > >
> > >
> > >> It seems an unfortunate side effect is that issues like those
> > >> identified by
> > >> György (and other issues that I can think of) require unnatural
> > >> solutions,
> > >> such as using extra PTCs to keep track data. For me, I'm
> > using external
> > >> functions to do the job because a lot of times, I only
> > require an MTC and
> > >> don't want the complication of PTCs and passing forwards
> > and backwards of
> > >> unnecessary messages and cluttering up my code.
> > >
> > >
> > > Are you saying that you use only MTC?
> > >
> > > If you would need to preserve data between execution of
> > different test
> > > cases, could you use local variables defined in the control part?
> > >
> > > Or are you proposing actually that there would be variables
> > that would
> > > hold data accessible within one test component, but from
> > one test case
> > > to another. These would correspond to the test suite variables of
> > > TTCN-2, and would not break the current TTCN model, but would be
> > > just a little bit against of common software engineering
> principles.
> > >
> > >> So the question is, why not allow global data and let the
> > process-based
> > >> TTCN-3 vendors (are there that many of them anyway?)
> > tackle the issue of
> > >> global data (writing to files, or passing messages to an
> auxiliary
> > >> process
> > >> that maintains global data, etc). I know that, for at least 2
> > >> implementations (Telelogic Tau G2 Tester and Testing
> > Technologies), this
> > >> should not be a problem because they are or can be
> thread-based. I
> > >> think the
> > >> natural solution of allowing global data would benefit
> > everyone using
> > >> TTCN-3
> > >> in the long run.
> > >
> > >
> > > For a couple of years, we (OpenTTCN) have been implementing
> > TTCN using
> > > an implementation where test components are distributed
> to different
> > > processes within one PC or to multiple PCs. If necessary
> these test
> > > components can be implemented within one process and its
> > address space
> > > too.
> > >
> > > Now in the implementation of TTCN-3, we see that the current
> > > architecture of TTCN-3 gives a powerful mechanisms for the
> > test suite
> > > writers when appropriate tools are used.
> > >
> > > Best regards,
> > > Vesa-Matti
> > >
> > > --
> > > Vesa-Matti Puro
> > > E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > > Tel.: +358 440396461
> > > OpenTTCN Oy
> > > Web: www.openttcn.com
> >
> >
> > --
> >

---

> >

---

> > 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
> >

---

> >

---

> >
>

Hi all,


György Réthy (IJ/ETH) wrote:
> Ina's statement "TTCN-3 has currently a clear concept of test
> components and the exchange of information between test components
> via connected ports" sounds well but unfortunately has not much to
> do with the given topic (except that today this is the only option
> for the user).

I think that it is good that there is a clear concepts of components in
TTCN-3. Usually components are associated with encapsulatation, i.e.
internals of the components are hidden. The behavior of the component
can be manipulated and monitored with create, start, running, stop,
done, ... operations. Secondly, the user's test case logic communicates
through ports.


> 2. When you write
> AnotherPTC.done;
> the status information regarding the another PTC's status is not
> communicated via a port. Also: create, start(component), running,
> stop(component) are all a form of inter-component communication
> handled by the test system (and we could list here mtc and system
> used in a PTC) and not via communication ports. Value returning
> done is about to add one more information (not even an operation)
> to the EXISTING inter-component communication model. It has nothing
> to do with global variables or with a different model than specified
> today.

What comes to value returning done, we think that's fine for us, if
that is needed. You are right that it does not break the existing
"TTCN-3 component model". But as Thomas in his 23.9. email anlysed,
there are some complexities there, for example, what happens if
no value is returned. These needs to be just taken into account.

If value returning done is though as some kind return value concept,
I think that it could be restricted to be available in the
component that originally started the component returning values.


> I would like also to draw the attention to another aspect that
> I think much more important. The use of co-ordination messages
> between components is rather inconvenient & peevish for the USER.
> However, no other mean when TIMING is important (so when really
> used for co-ordination betwee ncomponents). But do not force the
> USER to nasty solutions (like external functions as Cheung Ray
> mentioned) when timing is unimportant. That's annoying and do not
> increase the popularity of TTCN-3.

I think that the communication though ports is the price to pay
from the fact that the TTCN-3 standard does not specify how
components are implemented... which is a good because it keeps
different implementation strategies open.


But this could be still solved somehow, here are some ideas:

1) let's allow to specify a component "local" (like ports can be
specified "message" or "procedure"), this could open access
to global variables that would have TTCN-2 test suite variables
semantics (i.e. preserve value from one testcase to another).

2) let's define "threads" in TTCN-3, user could start a
parallelly executing function that could access the
variables of a componentn where it was started.
This would preserve components as encapsulated
(and possibly distributed) objects, and the user could
use threads if she/he merely needs local parallel
processing. These threads could have start, stop,
running, done, ... i.e. the same methods as components
have but they would be guaranteed to be able to access
component variables.

3) let's define "attributes" (like in IDL) for the MTC,
the attributes would be like global variables and
visible for all components,
the user would have some reminder that read/write
operations of these attributes are not guaranteed
to happen in the same address space.


> I often cannot get rid of the feeling (as with this discussion)
> that tool providers care about nice & simple tool implementation
> ONLY and do forget about USERs' convenience and usability of the
> language. This discussion should be about what users wish to see
> in the language and not about what tool implementers wish to
> implement. Only those features should be criticized by tool
> implementers which are technically really non-implementable (that
> I believe is NOT the case for value returning done even - as Thomas
> pointed out - the type of the returned value can be checked run-time).

At the moment, TTCN-3 is already one of the most complex computer
languages designed. It includes features like "import w/ language"
that allows combining all other languages with it, and "attributes"
that also provides an open ended extensions.

I think the value of this list is increased by the users who
give feedback what is needed, and by the tool implementors who
give feedback about implementability and consequences of the
proposals.

It has also some value to keep the TTCN-3 stable for some time.
This would allow the users to adopt the language, before it is
changed next time.


> PS: In my examples I have written "When the SCCP connection is handled by a
PTC...";
> so it should be clear that when giving example for the use of value returning
done,
> I'm talking about how to get the value out of the PTC (by the MTC) and not how
to
> save it between test cases (for the example to work both is needed, of course)

Maybe TTCN-2 style test suite variable semantics could be
introduced. I would sound more natural to keep the state inside
a component that move values back and forth between the "control
part" and test cases.


Best regards,
Vesa-Matti


--
Vesa-Matti Puro
E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Tel.: +358 440396461
OpenTTCN Oy
Web: www.openttcn.com

Hi Gyorgy,

György Réthy (IJ/ETH) wrote:
> Hi,
>
> Ina, I'm lost what is the view Thomas expressed? He (btw. correctly) analysed different situations. But I could not have found any view (or even pro or contra) in his mail. Yes, the user shall use this feature with knowledge and care - but this is true for many other TTCN-3 features.
>

I meant that his analysis shows that it is rather unclear how to include
this new feature into the set of existing features dealing with the
termination of test components. There are many cases where it is not
clear what should happen - even if we would decide on a semantics for
all the mentioned cases it could be counter-intuitive.

> Ina's statement "TTCN-3 has currently a clear concept of test components and the exchange of information between test components via connected ports" sounds well but unfortunately has not much to do with the given topic (except that today this is the only option for the user).:
> 1. Ina, would you clarify pls. what do you mean on "implicit connected ports"? I cannot find something like this in mails before yours and has nothing to do with the value returning done proposal either.

The current paradigm of TTCN-3 is that information (values of
predefined/user defined types) is exchanged via ports only. The
operations done/running are a special case.

Therefore, I read the proposal on extending done with a return value to
mean an implicit port between a component to all other components. This
thinking is also driven by the way TCI is defined.

This port should be able to carry all possible types - as the return
type is e.g. not part of a component type definition and is therefore
open to any type. You can currently start on a test component any
function which is type compatible to the component type - but the return
type is not considered and hence, any type can be used.


> 2. When you write
> AnotherPTC.done;
> the status information regarding the another PTC's status is not communicated via a port.
> Also: create, start(component), running, stop(component) are all a form of inter-component communication handled by the test system (and we could list here mtc and system used in a PTC) and not via communication ports. Value returning done is about to add one more information (not even an operation) to the EXISTING inter-component communication model. It has nothing to do with global variables or with a different model than specified today.

The difference - I think - comes with the fact that the value return can
be of any type. So far, we have as global data of specific kinds only:
test component handles (mtc, system), boolean-like-kind for done/running
information, and event-like-lind for create/start/stop.

Even if we would solve the question on the return type (for example, we
could extend the type component definition to include a return type -
however, I haven't seen so far a component approach where component
return values - rather they offer all the information via their
well-defined interfaces - in case of TTCN-3 the ports) I see more open
questions than answered:

in addition to the cases described by Thomas: is the test component
verdict altered whenever a test component is stopped or terminates
without producing a return? Is it a test case error?

How long is the return value available. Currently, a test component
could check many times whether a test component is done - can it then
also "receive" several times the return value?

What about the all.done?

>
>
>
> I would like also to draw the attention to another aspect that I think much more important.
> The use of co-ordination messages between components is rather inconvenient & peevish for the USER. However, no other mean when TIMING is important (so when really used for co-ordination between components). But do not force the USER to nasty solutions (like external functions as Cheung Ray mentioned) when timing is unimportant. That's annoying and do not increase the popularity of TTCN-3.
>
> I often cannot get rid of the feeling (as with this discussion) that tool providers care about nice & simple tool implementation ONLY and do forget about USERs' convenience and usability of the language. This discussion should be about what users wish to see in the language and not about what tool implementers wish to implement. Only those features should be criticized by tool implementers which are technically really non-implementable (that I believe is NOT the case for value returning done even - as Thomas pointed out - the type of the returned value can be checked run-time).
>

Indeed, when you made the proposal I thought it is worth consideration -
however, after a while of thinking I found that this new feature has
interferences with existing features - and I do not see how to solve them.

If we find a clear (hopefully intuitive) semantics it could be
implemented in TTCN-3 if users demands it. But could you please explain
before how to define this new construct semantically.

With best regards,

Ina.

> PS: In my examples I have written "When the SCCP connection is handled by a PTC..."; so it should be clear that when giving example for the use of value returning done, I'm talking about how to get the value out of the PTC (by the MTC) and not how to save it between test cases (for the example to work both is needed, of course)
>
> BR, Gyorgy
>
>
>>

---

Original Message

---

>>From: Ina Schieferdecker [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>>Sent: Tuesday, September 23, 2003 10:58 AM
>>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>Subject: Re: Extension of DONE operation / global variables
>>
>>
>>Dear all,
>>
>>I want to support the views expressed by Thomas and
>>Vesa-Matti. TTCN-3
>>has currently a clear concept of test components and the exchange of
>>information between test components via connected ports. Either the
>>introduction of global variables or the addition of implicit
>>connected
>>ports between a test component and its creating or all other test
>>components would only complicate things. The gain (in length
>>of TTCN-3
>>code) possible in some cases is paid by the impliciteness and
>>additional
>>assumptions about the concurrent execution of test components.
>>
>>Cheers, Ina.
>>
>>Vesa-Matti Puro wrote:
>>
>>>Hello all!
>>>
>>>Here are some comments about global data.
>>>
>>>Cheung Ray-RCHEUNG1 wrote:
>>>
>>>
>>>>This discussion touches on something that I've always
>>>
>>regarded as a
>>
>>>>bit of
>>>>an impediment in TTCN-3. That is the disallowance of global data,
>>>>which, if
>>>>I understand correctly, is due to consideration for TTCN-3 vendors
>>>>implementing on a process-based, as opposed to a thread-based,
>>>>environment/operating system.
>>>
>>>
>>>The TTCN-3 allows some global data, for example:
>>> o module parameters
>>> o constants defined in a module
>>> o external constants
>>>
>>>What is missing, are "global variables."
>>>
>>>The TTCN modules has been traditionally based on interconnected test
>>>components that communicate with each other using inter-process like
>>>coordination points and coordination messages (in TTCN-3 these are
>>>just "connected" ports and normal messages exchanged between these
>>>ports.
>>>
>>>Introduction of global variables would limit the
>>
>>implementation options
>>
>>>of test components and the applicability of TTCN-3 to
>>
>>various different
>>
>>>types of testing proposed.
>>>
>>>The current test component model of TTCN-3, allows
>>
>>implementation of the
>>
>>>tools using either local (test components withing the same process
>>>space) or distributed architecture (test components are running in
>>>different processes in the same or remote PCs).
>>>
>>>Introduction of dynamic creation of test components using
>>
>>the "create"
>>
>>>statement allows specification of testers that create a large number
>>>of test components for load or performance testing purposes, or
>>>for some other reason.
>>>
>>>In my opinion, the inter test component communication
>>
>>should be limited
>>
>>>to traffic between ports, implicit verdict updates, and the
>>
>>indication
>>
>>>of the end of the test execution. This would keep the
>>
>>TTCN-3 as widely
>>
>>>applicable as possible, and keeps the implementation options open.
>>>
>>>
>>>
>>>>It seems an unfortunate side effect is that issues like those
>>>>identified by
>>>>György (and other issues that I can think of) require unnatural
>>>>solutions,
>>>>such as using extra PTCs to keep track data. For me, I'm
>>>
>>using external
>>
>>>>functions to do the job because a lot of times, I only
>>>
>>require an MTC and
>>
>>>>don't want the complication of PTCs and passing forwards
>>>
>>and backwards of
>>
>>>>unnecessary messages and cluttering up my code.
>>>
>>>
>>>Are you saying that you use only MTC?
>>>
>>>If you would need to preserve data between execution of
>>
>>different test
>>
>>>cases, could you use local variables defined in the control part?
>>>
>>>Or are you proposing actually that there would be variables
>>
>>that would
>>
>>>hold data accessible within one test component, but from
>>
>>one test case
>>
>>>to another. These would correspond to the test suite variables of
>>>TTCN-2, and would not break the current TTCN model, but would be
>>>just a little bit against of common software engineering principles.
>>>
>>>
>>>>So the question is, why not allow global data and let the
>>>
>>process-based
>>
>>>>TTCN-3 vendors (are there that many of them anyway?)
>>>
>>tackle the issue of
>>
>>>>global data (writing to files, or passing messages to an auxiliary
>>>>process
>>>>that maintains global data, etc). I know that, for at least 2
>>>>implementations (Telelogic Tau G2 Tester and Testing
>>>
>>Technologies), this
>>
>>>>should not be a problem because they are or can be thread-based. I
>>>>think the
>>>>natural solution of allowing global data would benefit
>>>
>>everyone using
>>
>>>>TTCN-3
>>>>in the long run.
>>>
>>>
>>>For a couple of years, we (OpenTTCN) have been implementing
>>
>>TTCN using
>>
>>>an implementation where test components are distributed to different
>>>processes within one PC or to multiple PCs. If necessary these test
>>>components can be implemented within one process and its
>>
>>address space
>>
>>>too.
>>>
>>>Now in the implementation of TTCN-3, we see that the current
>>>architecture of TTCN-3 gives a powerful mechanisms for the
>>
>>test suite
>>
>>>writers when appropriate tools are used.
>>>
>>>Best regards,
>>>Vesa-Matti
>>>
>>>--
>>>Vesa-Matti Puro
>>>E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>>Tel.: +358 440396461
>>>OpenTTCN Oy
>>>Web: www.openttcn.com
>>
>>
>>--
>>

---

>>

---

>>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
>>

---

>>

---

>>
>
>


--

---

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

---

Hi,

take items one by one:

1) I would not say, that the semantic is very unclear. It has not taken too much time for Thomas to summarize the correct semantics. The only point of the whole thing that we miss in the standard today is the handling of values returned by a function started on a component. The semantics proposed for it is the "receiving semantics" already existing in the language.
Basically all cases in Thomas's mail are topics for a TTCN-3 tutorial/course not for the language specification. I know the example may seem to simplified, but the language does not specify either what shall happen if a component is stopped which actually executes a function with a return clause... (but I do not have any objection to include more clarification text into the standard, of course).

2) "The current paradigm of TTCN-3 is that information (values of predefined/user defined types) is exchanged via ports only. The operations done/running are a special case."

I do not think this is a specified paradigm; both inter-component communication via port connections and done are simply inherited from TTCN-2. Value returning done is not the first (and hopefully not the last) new language feature to be introduced into TTCN-3 to make it more user friendly than TTCN-2 was.

3) I do not think the "implicit port" concept is valid in this case.
First of all, there is always one or more concrete addressee (implicitly via connect/map or explicitly using to or both) when sending something on a port. This is not the case here. Every component interested in the returned value picks it up itself from the system. If you send something on a port, it arrives to the addressee(s) immediately and has to be processed ASAP otherwise will cork the incoming queue of the port at the receiver side. This is not the case for returned values (no queue concept at all). Simply the whole thing behaves differently than a port connection (to my mind this is its major strength).

4) Type of the return value.
Yes. The system shall be prepared to store values of any possible types (if not simply preparing itself to store the set of types defined as return types in all functions with a given runs-on clause - this is still a limited set). But after solving the anytype exercise it should not be a breaking problem. I do not think that it is more complex than supporting e.g.
type port MyPort message { inout all }

5) "Unresolved semantic problems". If they exist, do not have direct relation to the value returning done operation. But if you think it is needed, no objection to clarify any point as I'm, you know, always at the side of making a clear standard.
Is the component verdict changed today when the function started on a component has a return clause and does not return a value? Is the component verdict changed when a component is stopped by another component? Note pls., there is no difference in component & verdict handling as defined today if we allow to other components to pick up the actual value returned.

6) Regarding your question on multiple receipt of returned values. Yes, the return value - if any - is "provided for processing" each time when the done operation is invoked. But like any other receiving operation, you may simply neglect the concrete value if you whish:
Myport.receive; //simply does not care what concrete message arrived,
//it is enough to know the fact;
MyComp.done; //the concrete returned value is unimportant in this case;

BR, Gyorgy

>

---

Original Message

---

> From: Ina Schieferdecker [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Wednesday, September 24, 2003 12:10 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Extension of DONE operation / global variables
>
>
> Hi Gyorgy,
>
> György Réthy (IJ/ETH) wrote:
> > Hi,
> >
> > Ina, I'm lost what is the view Thomas expressed? He (btw.
> correctly) analysed different situations. But I could not
> have found any view (or even pro or contra) in his mail. Yes,
> the user shall use this feature with knowledge and care - but
> this is true for many other TTCN-3 features.
> >
>
> I meant that his analysis shows that it is rather unclear how
> to include
> this new feature into the set of existing features dealing with the
> termination of test components. There are many cases where it is not
> clear what should happen - even if we would decide on a semantics for
> all the mentioned cases it could be counter-intuitive.
>
> > Ina's statement "TTCN-3 has currently a clear concept of
> test components and the exchange of information between test
> components via connected ports" sounds well but unfortunately
> has not much to do with the given topic (except that today
> this is the only option for the user).:
> > 1. Ina, would you clarify pls. what do you mean on
> "implicit connected ports"? I cannot find something like this
> in mails before yours and has nothing to do with the value
> returning done proposal either.
>
> The current paradigm of TTCN-3 is that information (values of
> predefined/user defined types) is exchanged via ports only. The
> operations done/running are a special case.
>
> Therefore, I read the proposal on extending done with a
> return value to
> mean an implicit port between a component to all other
> components. This
> thinking is also driven by the way TCI is defined.
>
> This port should be able to carry all possible types - as the return
> type is e.g. not part of a component type definition and is therefore
> open to any type. You can currently start on a test component any
> function which is type compatible to the component type - but
> the return
> type is not considered and hence, any type can be used.
>
>
> > 2. When you write
> > AnotherPTC.done;
> > the status information regarding the another PTC's status
> is not communicated via a port.
> > Also: create, start(component), running, stop(component)
> are all a form of inter-component communication handled by
> the test system (and we could list here mtc and system used
> in a PTC) and not via communication ports. Value returning
> done is about to add one more information (not even an
> operation) to the EXISTING inter-component communication
> model. It has nothing to do with global variables or with a
> different model than specified today.
>
> The difference - I think - comes with the fact that the value
> return can
> be of any type. So far, we have as global data of specific
> kinds only:
> test component handles (mtc, system), boolean-like-kind for
> done/running
> information, and event-like-lind for create/start/stop.
>
> Even if we would solve the question on the return type (for
> example, we
> could extend the type component definition to include a return type -
> however, I haven't seen so far a component approach where component
> return values - rather they offer all the information via their
> well-defined interfaces - in case of TTCN-3 the ports) I see
> more open
> questions than answered:
>
> in addition to the cases described by Thomas: is the test component
> verdict altered whenever a test component is stopped or terminates
> without producing a return? Is it a test case error?
>
> How long is the return value available. Currently, a test component
> could check many times whether a test component is done - can it then
> also "receive" several times the return value?
>
> What about the all.done?
>
> >
> >
> >
> > I would like also to draw the attention to another aspect
> that I think much more important.
> > The use of co-ordination messages between components is
> rather inconvenient & peevish for the USER. However, no other
> mean when TIMING is important (so when really used for
> co-ordination between components). But do not force the USER
> to nasty solutions (like external functions as Cheung Ray
> mentioned) when timing is unimportant. That's annoying and do
> not increase the popularity of TTCN-3.
> >
> > I often cannot get rid of the feeling (as with this
> discussion) that tool providers care about nice & simple tool
> implementation ONLY and do forget about USERs' convenience
> and usability of the language. This discussion should be
> about what users wish to see in the language and not about
> what tool implementers wish to implement. Only those features
> should be criticized by tool implementers which are
> technically really non-implementable (that I believe is NOT
> the case for value returning done even - as Thomas pointed
> out - the type of the returned value can be checked run-time).
> >
>
> Indeed, when you made the proposal I thought it is worth
> consideration -
> however, after a while of thinking I found that this new feature has
> interferences with existing features - and I do not see how
> to solve them.
>
> If we find a clear (hopefully intuitive) semantics it could be
> implemented in TTCN-3 if users demands it. But could you
> please explain
> before how to define this new construct semantically.
>
> With best regards,
>
> Ina.
>
> > PS: In my examples I have written "When the SCCP connection
> is handled by a PTC..."; so it should be clear that when
> giving example for the use of value returning done, I'm
> talking about how to get the value out of the PTC (by the
> MTC) and not how to save it between test cases (for the
> example to work both is needed, of course)
> >
> > BR, Gyorgy
> >
> >
> >>

---

Original Message

---

> >>From: Ina Schieferdecker [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> >>Sent: Tuesday, September 23, 2003 10:58 AM
> >>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >>Subject: Re: Extension of DONE operation / global variables
> >>
> >>
> >>Dear all,
> >>
> >>I want to support the views expressed by Thomas and
> >>Vesa-Matti. TTCN-3
> >>has currently a clear concept of test components and the
> exchange of
> >>information between test components via connected ports. Either the
> >>introduction of global variables or the addition of implicit
> >>connected
> >>ports between a test component and its creating or all other test
> >>components would only complicate things. The gain (in length
> >>of TTCN-3
> >>code) possible in some cases is paid by the impliciteness and
> >>additional
> >>assumptions about the concurrent execution of test components.
> >>
> >>Cheers, Ina.
> >>
> >>Vesa-Matti Puro wrote:
> >>
> >>>Hello all!
> >>>
> >>>Here are some comments about global data.
> >>>
> >>>Cheung Ray-RCHEUNG1 wrote:
> >>>
> >>>
> >>>>This discussion touches on something that I've always
> >>>
> >>regarded as a
> >>
> >>>>bit of
> >>>>an impediment in TTCN-3. That is the disallowance of global data,
> >>>>which, if
> >>>>I understand correctly, is due to consideration for TTCN-3 vendors
> >>>>implementing on a process-based, as opposed to a thread-based,
> >>>>environment/operating system.
> >>>
> >>>
> >>>The TTCN-3 allows some global data, for example:
> >>> o module parameters
> >>> o constants defined in a module
> >>> o external constants
> >>>
> >>>What is missing, are "global variables."
> >>>
> >>>The TTCN modules has been traditionally based on
> interconnected test
> >>>components that communicate with each other using
> inter-process like
> >>>coordination points and coordination messages (in TTCN-3 these are
> >>>just "connected" ports and normal messages exchanged between these
> >>>ports.
> >>>
> >>>Introduction of global variables would limit the
> >>
> >>implementation options
> >>
> >>>of test components and the applicability of TTCN-3 to
> >>
> >>various different
> >>
> >>>types of testing proposed.
> >>>
> >>>The current test component model of TTCN-3, allows
> >>
> >>implementation of the
> >>
> >>>tools using either local (test components withing the same process
> >>>space) or distributed architecture (test components are running in
> >>>different processes in the same or remote PCs).
> >>>
> >>>Introduction of dynamic creation of test components using
> >>
> >>the "create"
> >>
> >>>statement allows specification of testers that create a
> large number
> >>>of test components for load or performance testing purposes, or
> >>>for some other reason.
> >>>
> >>>In my opinion, the inter test component communication
> >>
> >>should be limited
> >>
> >>>to traffic between ports, implicit verdict updates, and the
> >>
> >>indication
> >>
> >>>of the end of the test execution. This would keep the
> >>
> >>TTCN-3 as widely
> >>
> >>>applicable as possible, and keeps the implementation options open.
> >>>
> >>>
> >>>
> >>>>It seems an unfortunate side effect is that issues like those
> >>>>identified by
> >>>>György (and other issues that I can think of) require unnatural
> >>>>solutions,
> >>>>such as using extra PTCs to keep track data. For me, I'm
> >>>
> >>using external
> >>
> >>>>functions to do the job because a lot of times, I only
> >>>
> >>require an MTC and
> >>
> >>>>don't want the complication of PTCs and passing forwards
> >>>
> >>and backwards of
> >>
> >>>>unnecessary messages and cluttering up my code.
> >>>
> >>>
> >>>Are you saying that you use only MTC?
> >>>
> >>>If you would need to preserve data between execution of
> >>
> >>different test
> >>
> >>>cases, could you use local variables defined in the control part?
> >>>
> >>>Or are you proposing actually that there would be variables
> >>
> >>that would
> >>
> >>>hold data accessible within one test component, but from
> >>
> >>one test case
> >>
> >>>to another. These would correspond to the test suite variables of
> >>>TTCN-2, and would not break the current TTCN model, but would be
> >>>just a little bit against of common software engineering
> principles.
> >>>
> >>>
> >>>>So the question is, why not allow global data and let the
> >>>
> >>process-based
> >>
> >>>>TTCN-3 vendors (are there that many of them anyway?)
> >>>
> >>tackle the issue of
> >>
> >>>>global data (writing to files, or passing messages to an
> auxiliary
> >>>>process
> >>>>that maintains global data, etc). I know that, for at least 2
> >>>>implementations (Telelogic Tau G2 Tester and Testing
> >>>
> >>Technologies), this
> >>
> >>>>should not be a problem because they are or can be
> thread-based. I
> >>>>think the
> >>>>natural solution of allowing global data would benefit
> >>>
> >>everyone using
> >>
> >>>>TTCN-3
> >>>>in the long run.
> >>>
> >>>
> >>>For a couple of years, we (OpenTTCN) have been implementing
> >>
> >>TTCN using
> >>
> >>>an implementation where test components are distributed to
> different
> >>>processes within one PC or to multiple PCs. If necessary these test
> >>>components can be implemented within one process and its
> >>
> >>address space
> >>
> >>>too.
> >>>
> >>>Now in the implementation of TTCN-3, we see that the current
> >>>architecture of TTCN-3 gives a powerful mechanisms for the
> >>
> >>test suite
> >>
> >>>writers when appropriate tools are used.
> >>>
> >>>Best regards,
> >>>Vesa-Matti
> >>>
> >>>--
> >>>Vesa-Matti Puro
> >>>E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >>>Tel.: +358 440396461
> >>>OpenTTCN Oy
> >>>Web: www.openttcn.com
> >>
> >>
> >>--
> >>

---

> >>

---

> >>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
> >>

---

> >>

---

> >>
> >
> >
>
>
> --
>

---

>

---

> 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
>

---

>

---

>