Hello all,

In MTS-IPT-SIP mailing list we encountered a question that could be of
interest of members of TTCN3 mailing list as well. I present that
question here in more abstract terms, more like as a "TTCN-3 design
pattern" issue.

First, I have a port type definition:

type port TwoMessages message
{
inout Message1, Message2
}

Then I have the following (number of) test cases:

l number of test cases: that use one TwoMessages port
m number of test cases: that use two TwoMessages ports (the same
port than l test cases plus one additional)
n number of test cases: that use three TwoMessages ports (the same
two ports than m test cases plus one additional)
Total l+m+n test cases.

Would it be more natural to use one test system interface common
for all test cases:

type component TSI_All
{
port TwoMessages P1, P2, P3;
}


Or would it make more sense to define three test system interfaces,
one for each type of test cases (using different number of ports)
and which one would be more according to ETSI TTCN-3 style guide:

type component TSI_1
{
port TwoMessages P1;
}

type component TSI_2
{
port TwoMessages P1, P2;
}

type component TSI_2
{
port TwoMessages P1, P2, P3;
}

Then test cases would use the specic test system interface they need:

testcase NeedingTwoPorts() runs on MyComponent system TSI_2
{
...
}

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

Hi Vesa-Matti,

I would say, it depends.

Like in "normal" software engineering you have to decide what you want.
Maintainability, extensibility, etc.

As I typically prefer a "clean" definition, without carrying around to
much overhead, I would go for the TSI_x solutions.

However as I am in certain occasions also very lazy, I could imagine
using also a solution like TSI_All. But in this case I would use for the
sake of scalability not "named" ports but a port array.
This would also help a SA implementor to choose the right implementation
concept.

I know, this does not help you much. But I believe there is no "natural"
way. It always depends on your goals and your application and /target
audience of your test suite.

Best regards,

Theo


Vesa-Matti Puro (OpenTTCN) wrote:

> Hello all,
>
> In MTS-IPT-SIP mailing list we encountered a question that could be of
> interest of members of TTCN3 mailing list as well. I present that
> question here in more abstract terms, more like as a "TTCN-3 design
> pattern" issue.
>
> First, I have a port type definition:
>
> type port TwoMessages message
> {
> inout Message1, Message2
> }
>
> Then I have the following (number of) test cases:
>
> l number of test cases: that use one TwoMessages port
> m number of test cases: that use two TwoMessages ports (the same
> port than l test cases plus one additional)
> n number of test cases: that use three TwoMessages ports (the same
> two ports than m test cases plus one additional)
> Total l+m+n test cases.
>
> Would it be more natural to use one test system interface common
> for all test cases:
>
> type component TSI_All
> {
> port TwoMessages P1, P2, P3;
> }
>
>
> Or would it make more sense to define three test system interfaces,
> one for each type of test cases (using different number of ports)
> and which one would be more according to ETSI TTCN-3 style guide:
>
> type component TSI_1
> {
> port TwoMessages P1;
> }
>
> type component TSI_2
> {
> port TwoMessages P1, P2;
> }
>
> type component TSI_2
> {
> port TwoMessages P1, P2, P3;
> }
>
> Then test cases would use the specic test system interface they need:
>
> testcase NeedingTwoPorts() runs on MyComponent system TSI_2
> {
> ...
> }
>
> --
> Vesa-Matti Puro
> OpenTTCN Oy
> E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. * Tel.: +358 440396461 * Web: www.openttcn.com
>

In einer eMail vom 9/17/04 12:26:21 PM W. Europe Daylight Time schreibt
_vmp@OES.FI_ (This email address is being protected from spambots. You need JavaScript enabled to view it.) :

Hi Vesa,

What you ask is more or less a philosophical question, or rather design
choice.

From a design point of view the second option is preferable. (my opinion).
Someone
looking at the test system where there are 3 ports, P1,P2,P3 might ask
oneself
why there is only one port used in a test case, yet there are three ports
are specified.

Granted, having one test system interface design makes for less code, but,
form does
not follow function in this case. Of course it works, but the intent is not
as clear as
when you use singleminded test interfaces, (that is, where there are 3
different test
system interfaces, one each used for the different number of ports as you
explain).

To take things further, one might consider placing each test system
interface and their
related test cases and place them in separate modules making things even
clearer.

moduleOnePort { oneport test cases and oneport test system interface }

moduleTwoPort { twoport test cases and twoport test system interface }

moduleThreePort { threeport test cases and threeport test system interface
}

Again, all of this is not necessary, however, it makes things clearer from
readability,
and maintainability point of view. Furthermore, unexpected types of errors
may be avoided
by using three test system interfaces. E.g. an engineer might attempt to
use two ports
in a test case which should only be using one port, thus causing problems
which may be
difficult to identify if the 3port test system interface is used for all
classes of test cases,
that is, 1,2, and 3 port test cases.

In the end,it remains a choice.


Hope this helps.

Cheers,

Claude.




Hello all,

In MTS-IPT-SIP mailing list we encountered a question that could be of
interest of members of TTCN3 mailing list as well. I present that
question here in more abstract terms, more like as a "TTCN-3 design
pattern" issue.

First, I have a port type definition:

type port TwoMessages message
{
inout Message1, Message2
}

Then I have the following (number of) test cases:

l number of test cases: that use one TwoMessages port
m number of test cases: that use two TwoMessages ports (the same
port than l test cases plus one additional)
n number of test cases: that use three TwoMessages ports (the same
two ports than m test cases plus one additional)
Total l+m+n test cases.

Would it be more natural to use one test system interface common
for all test cases:

type component TSI_All
{
port TwoMessages P1, P2, P3;
}


Or would it make more sense to define three test system interfaces,
one for each type of test cases (using different number of ports)
and which one would be more according to ETSI TTCN-3 style guide:

type component TSI_1
{
port TwoMessages P1;
}

type component TSI_2
{
port TwoMessages P1, P2;
}

type component TSI_2
{
port TwoMessages P1, P2, P3;
}

Then test cases would use the specic test system interface they need:

testcase NeedingTwoPorts() runs on MyComponent system TSI_2
{
...
}

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






Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Solonplatz 3 phone: +49 30 9606 7985
13088 Berlin fax: +49 30 9606 7987
Germany

Thanks Claude!

Yes, you are right that this is about design choise, you might call
this as a TTCN-3 design pattern, if you are familiar with Erich Gamma's
Design Patters book.

I agree about your suggestions, and I think that it would be important
to include, produce, and use this kind of material to/in ETSI's TTCN-3
training materials / coding conventions / recommendations. At least
discuss about it in this mailing list.

Best regards,
Vesa-Matti

Claude Desroches wrote:
> Hi Vesa,
>
> What you ask is more or less a philosophical question, or rather design
> choice.
>
> From a design point of view the second option is preferable. (my
> opinion). Someone
> looking at the test system where there are 3 ports, P1,P2,P3 might ask
> oneself
> why there is only one port used in a test case, yet there are three
> ports are specified.
>
> Granted, having one test system interface design makes for less code,
> but, form does
> not follow function in this case. Of course it works, but the intent is
> not as clear as
> when you use singleminded test interfaces, (that is, where there are 3
> different test
> system interfaces, one each used for the different number of ports as
> you explain).
>
> To take things further, one might consider placing each test system
> interface and their
> related test cases and place them in separate modules making things even
> clearer.
>
> moduleOnePort { oneport test cases and oneport test system interface }
> moduleTwoPort { twoport test cases and twoport test system interface }
> moduleThreePort { threeport test cases and threeport test system
> interface }
>
> Again, all of this is not necessary, however, it makes things clearer
> from readability,
> and maintainability point of view. Furthermore, unexpected types of
> errors may be avoided
> by using three test system interfaces. E.g. an engineer might attempt
> to use two ports
> in a test case which should only be using one port, thus causing
> problems which may be
> difficult to identify if the 3port test system interface is used for all
> classes of test cases,
> that is, 1,2, and 3 port test cases.
>
> In the end,it remains a choice.
>
>
> Hope this helps.
>
> Cheers,
>
> Claude.
>
>
> Hello all,
>
> In MTS-IPT-SIP mailing list we encountered a question that could be of
> interest of members of TTCN3 mailing list as well. I present that
> question here in more abstract terms, more like as a "TTCN-3 design
> pattern" issue.
>
> First, I have a port type definition:
>
> type port TwoMessages message
> {
> inout Message1, Message2
> }
>
> Then I have the following (number of) test cases:
>
> l number of test cases: that use one TwoMessages port
> m number of test cases: that use two TwoMessages ports (the same
> port than l test cases plus one additional)
> n number of test cases: that use three TwoMessages ports (the same
> two ports than m test cases plus one
> additional)
> Total l+m+n test cases.
>
> Would it be more natural to use one test system interface common
> for all test cases:
>
> type component TSI_All
> {
> port TwoMessages P1, P2, P3;
> }
>
>
> Or would it make more sense to define three test system interfaces,
> one for each type of test cases (using different number of ports)
> and which one would be more according to ETSI TTCN-3 style guide:
>
> type component TSI_1
> {
> port TwoMessages P1;
> }
>
> type component TSI_2
> {
> port TwoMessages P1, P2;
> }
>
> type component TSI_2
> {
> port TwoMessages P1, P2, P3;
> }
>
> Then test cases would use the specic test system interface they need:
>
> testcase NeedingTwoPorts() runs on MyComponent system TSI_2
> {
> ...
> }
>
> *
> **Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Solonplatz 3 phone: +49 30 9606 7985
> 13088 Berlin fax: +49 30 9606 7987
> Germany
> *

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

In einer eMail vom 9/27/04 9:04:56 AM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Thanks Claude!

Hi Vesa,

You are welcome.



Yes, you are right that this is about design choise, you might call
this as a TTCN-3 design pattern, if you are familiar with Erich Gamma's
Design Patters book.
I know of the book, but have yet to buy it. Some day... :-)




I agree about your suggestions, and I think that it would be important
to include, produce, and use this kind of material to/in ETSI's TTCN-3
training materials / coding conventions / recommendations. At least
discuss about it in this mailing list.

Agreed. There are hundreds of finer points one could expand on when
discussion
testing, test design, and test system architectures. I suspect that there
is no single
architecture that will fullfil all one's testing needs. However, proposing
general classes
or patterns of architectures for different classes of problems would be of
value to the
testing community at large. Since designing a test system is almost the
same as
designing the system to be tested, much of the same principles of software
engineering
can be directly applied to designing test systems (typing, hierarchy,
encapsulation,
information hiding, modularity, abstraction, and all that good stuff :-) ).

Is anyone working on a TTCN-3 Style Guide as offered with TTCN-2?

Cheers,

Claude.



Best regards,
Vesa-Matti

Claude Desroches wrote:
> Hi Vesa,
>
> What you ask is more or less a philosophical question, or rather design
> choice.
>
> From a design point of view the second option is preferable. (my
> opinion). Someone
> looking at the test system where there are 3 ports, P1,P2,P3 might ask
> oneself
> why there is only one port used in a test case, yet there are three
> ports are specified.
>
> Granted, having one test system interface design makes for less code,
> but, form does
> not follow function in this case. Of course it works, but the intent is
> not as clear as
> when you use singleminded test interfaces, (that is, where there are 3
> different test
> system interfaces, one each used for the different number of ports as
> you explain).
>
> To take things further, one might consider placing each test system
> interface and their
> related test cases and place them in separate modules making things even
> clearer.
>
> moduleOnePort { oneport test cases and oneport test system interface }
> moduleTwoPort { twoport test cases and twoport test system interface }
> moduleThreePort { threeport test cases and threeport test system
> interface }
>
> Again, all of this is not necessary, however, it makes things clearer
> from readability,
> and maintainability point of view. Furthermore, unexpected types of
> errors may be avoided
> by using three test system interfaces. E.g. an engineer might attempt
> to use two ports
> in a test case which should only be using one port, thus causing
> problems which may be
> difficult to identify if the 3port test system interface is used for all
> classes of test cases,
> that is, 1,2, and 3 port test cases.
>
> In the end,it remains a choice.
>
>
> Hope this helps.
>
> Cheers,
>
> Claude.
>
>
> Hello all,
>
> In MTS-IPT-SIP mailing list we encountered a question that could be of
> interest of members of TTCN3 mailing list as well. I present that
> question here in more abstract terms, more like as a "TTCN-3 design
> pattern" issue.
>
> First, I have a port type definition:
>
> type port TwoMessages message
> {
> inout Message1, Message2
> }
>
> Then I have the following (number of) test cases:
>
> l number of test cases: that use one TwoMessages port
> m number of test cases: that use two TwoMessages ports (the same
> port than l test cases plus one additional)
> n number of test cases: that use three TwoMessages ports (the same
> two ports than m test cases plus one
> additional)
> Total l+m+n test cases.
>
> Would it be more natural to use one test system interface common
> for all test cases:
>
> type component TSI_All
> {
> port TwoMessages P1, P2, P3;
> }
>
>
> Or would it make more sense to define three test system interfaces,
> one for each type of test cases (using different number of ports)
> and which one would be more according to ETSI TTCN-3 style guide:
>
> type component TSI_1
> {
> port TwoMessages P1;
> }
>
> type component TSI_2
> {
> port TwoMessages P1, P2;
> }
>
> type component TSI_2
> {
> port TwoMessages P1, P2, P3;
> }
>
> Then test cases would use the specic test system interface they need:
>
> testcase NeedingTwoPorts() runs on MyComponent system TSI_2
> {
> ...
> }
>
> *
> **Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Solonplatz 3 phone: +49 30 9606 7985
> 13088 Berlin fax: +49 30 9606 7987
> Germany
> *

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




Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Solonplatz 3 phone: +49 30 9606 7985
13088 Berlin fax: +49 30 9606 7987
Germany

Hi claude,

it seems to me that in TTCN-3 style guides at this point are (ETSI) project specific.
For now I know of one style guide for ETSI's SIP test suite.
Another one is currently under writing for ETSI's IPv6 test system (STF256/276).

Maybe anthony could say some words about this?

Moikka,
Stephan

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of ext Claude Desroches
Sent: 27 September, 2004 16:17
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Specification of test system interface



In einer eMail vom 9/27/04 9:04:56 AM W. Europe Daylight Time schreibt This email address is being protected from spambots. You need JavaScript enabled to view it.:

Thanks Claude!


Hi Vesa,

You are welcome.



Yes, you are right that this is about design choise, you might call
this as a TTCN-3 design pattern, if you are familiar with Erich Gamma's
Design Patters book.

I know of the book, but have yet to buy it. Some day... :-)




I agree about your suggestions, and I think that it would be important
to include, produce, and use this kind of material to/in ETSI's TTCN-3
training materials / coding conventions / recommendations. At least
discuss about it in this mailing list.


Agreed. There are hundreds of finer points one could expand on when discussion
testing, test design, and test system architectures. I suspect that there is no single
architecture that will fullfil all one's testing needs. However, proposing general classes
or patterns of architectures for different classes of problems would be of value to the
testing community at large. Since designing a test system is almost the same as
designing the system to be tested, much of the same principles of software engineering
can be directly applied to designing test systems (typing, hierarchy, encapsulation,
information hiding, modularity, abstraction, and all that good stuff :-) ).

Is anyone working on a TTCN-3 Style Guide as offered with TTCN-2?

Cheers,

Claude.



Best regards,
Vesa-Matti

Claude Desroches wrote:
> Hi Vesa,
>
> What you ask is more or less a philosophical question, or rather design
> choice.
>
> From a design point of view the second option is preferable. (my
> opinion). Someone
> looking at the test system where there are 3 ports, P1,P2,P3 might ask
> oneself
> why there is only one port used in a test case, yet there are three
> ports are specified.
>
> Granted, having one test system interface design makes for less code,
> but, form does
> not follow function in this case. Of course it works, but the intent is
> not as clear as
> when you use singleminded test interfaces, (that is, where there are 3
> different test
> system interfaces, one each used for the different number of ports as
> you explain).
>
> To take things further, one might consider placing each test system
> interface and their
> related test cases and place them in separate modules making things even
> clearer.
>
> moduleOnePort { oneport test cases and oneport test system interface }
> moduleTwoPort { twoport test cases and twoport test system interface }
> moduleThreePort { threeport test cases and threeport test system
> interface }
>
> Again, all of this is not necessary, however, it makes things clearer
> from readability,
> and maintainability point of view. Furthermore, unexpected types of
> errors may be avoided
> by using three test system interfaces. E.g. an engineer might attempt
> to use two ports
> in a test case which should only be using one port, thus causing
> problems which may be
> difficult to identify if the 3port test system interface is used for all
> classes of test cases,
> that is, 1,2, and 3 port test cases.
>
> In the end,it remains a choice.
>
>
> Hope this helps.
>
> Cheers,
>
> Claude.
>
>
> Hello all,
>
> In MTS-IPT-SIP mailing list we encountered a question that could be of
> interest of members of TTCN3 mailing list as well. I present that
> question here in more abstract terms, more like as a "TTCN-3 design
> pattern" issue.
>
> First, I have a port type definition:
>
> type port TwoMessages message
> {
> inout Message1, Message2
> }
>
> Then I have the following (number of) test cases:
>
> l number of test cases: that use one TwoMessages port
> m number of test cases: that use two TwoMessages ports (the same
> port than l test cases plus one additional)
> n number of test cases: that use three TwoMessages ports (the same
> two ports than m test cases plus one
> additional)
> Total l+m+n test cases.
>
> Would it be more natural to use one test system interface common
> for all test cases:
>
> type component TSI_All
> {
> port TwoMessages P1, P2, P3;
> }
>
>
> Or would it make more sense to define three test system interfaces,
> one for each type of test cases (using different number of ports)
> and which one would be more according to ETSI TTCN-3 style guide:
>
> type component TSI_1
> {
> port TwoMessages P1;
> }
>
> type component TSI_2
> {
> port TwoMessages P1, P2;
> }
>
> type component TSI_2
> {
> port TwoMessages P1, P2, P3;
> }
>
> Then test cases would use the specic test system interface they need:
>
> testcase NeedingTwoPorts() runs on MyComponent system TSI_2
> {
> ...
> }
>
> *
> **Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Solonplatz 3 phone: +49 30 9606 7985
> 13088 Berlin fax: +49 30 9606 7987
> Germany
> *

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




Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Solonplatz 3 phone: +49 30 9606 7985
13088 Berlin fax: +49 30 9606 7987
Germany

In einer eMail vom 9/28/04 6:24:44 AM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi claude,

Hi Stephan,

Nice to hear from you again! :-)
Thanks for the tip on SIP and IPv6. It should be possible to derive a
general/generic set
of guidelines which are technology independent. Style guides are just that
'suggestions'
on how one can do things. Is there any way to get one's hands on the SIP
and IPv6
style guides? Let me know.

Moi, moi!

Claude.



it seems to me that in TTCN-3 style guides at this point are (ETSI) project
specific.
For now I know of one style guide for ETSI's SIP test suite.
Another one is currently under writing for ETSI's IPv6 test system
(STF256/276).

Maybe anthony could say some words about this?

Moikka,
Stephan

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of ext Claude Desroches
Sent: 27 September, 2004 16:17
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Specification of test system interface


In einer eMail vom 9/27/04 9:04:56 AM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Thanks Claude!

Hi Vesa,

You are welcome.



Yes, you are right that this is about design choise, you might call
this as a TTCN-3 design pattern, if you are familiar with Erich Gamma's
Design Patters book.
I know of the book, but have yet to buy it. Some day... :-)




I agree about your suggestions, and I think that it would be important
to include, produce, and use this kind of material to/in ETSI's TTCN-3
training materials / coding conventions / recommendations. At least
discuss about it in this mailing list.

Agreed. There are hundreds of finer points one could expand on when
discussion
testing, test design, and test system architectures. I suspect that there
is no single
architecture that will fullfil all one's testing needs. However, proposing
general classes
or patterns of architectures for different classes of problems would be of
value to the
testing community at large. Since designing a test system is almost the
same as
designing the system to be tested, much of the same principles of software
engineering
can be directly applied to designing test systems (typing, hierarchy,
encapsulation,
information hiding, modularity, abstraction, and all that good stuff :-) ).

Is anyone working on a TTCN-3 Style Guide as offered with TTCN-2?

Cheers,

Claude.



Best regards,
Vesa-Matti

Claude Desroches wrote:
> Hi Vesa,
>
> What you ask is more or less a philosophical question, or rather design
> choice.
>
> From a design point of view the second option is preferable. (my
> opinion). Someone
> looking at the test system where there are 3 ports, P1,P2,P3 might ask
> oneself
> why there is only one port used in a test case, yet there are three
> ports are specified.
>
> Granted, having one test system interface design makes for less code,
> but, form does
> not follow function in this case. Of course it works, but the intent is
> not as clear as
> when you use singleminded test interfaces, (that is, where there are 3
> different test
> system interfaces, one each used for the different number of ports as
> you explain).
>
> To take things further, one might consider placing each test system
> interface and their
> related test cases and place them in separate modules making things even
> clearer.
>
> moduleOnePort { oneport test cases and oneport test system interface }
> moduleTwoPort { twoport test cases and twoport test system interface }
> moduleThreePort { threeport test cases and threeport test system
> interface }
>
> Again, all of this is not necessary, however, it makes things clearer
> from readability,
> and maintainability point of view. Furthermore, unexpected types of
> errors may be avoided
> by using three test system interfaces. E.g. an engineer might attempt
> to use two ports
> in a test case which should only be using one port, thus causing
> problems which may be
> difficult to identify if the 3port test system interface is used for all
> classes of test cases,
> that is, 1,2, and 3 port test cases.
>
> In the end,it remains a choice.
>
>
> Hope this helps.
>
> Cheers,
>
> Claude.
>
>
> Hello all,
>
> In MTS-IPT-SIP mailing list we encountered a question that could be of
> interest of members of TTCN3 mailing list as well. I present that
> question here in more abstract terms, more like as a "TTCN-3 design
> pattern" issue.
>
> First, I have a port type definition:
>
> type port TwoMessages message
> {
> inout Message1, Message2
> }
>
> Then I have the following (number of) test cases:
>
> l number of test cases: that use one TwoMessages port
> m number of test cases: that use two TwoMessages ports (the same
> port than l test cases plus one additional)
> n number of test cases: that use three TwoMessages ports (the same
> two ports than m test cases plus one
> additional)
> Total l+m+n test cases.
>
> Would it be more natural to use one test system interface common
> for all test cases:
>
> type component TSI_All
> {
> port TwoMessages P1, P2, P3;
> }
>
>
> Or would it make more sense to define three test system interfaces,
> one for each type of test cases (using different number of ports)
> and which one would be more according to ETSI TTCN-3 style guide:
>
> type component TSI_1
> {
> port TwoMessages P1;
> }
>
> type component TSI_2
> {
> port TwoMessages P1, P2;
> }
>
> type component TSI_2
> {
> port TwoMessages P1, P2, P3;
> }
>
> Then test cases would use the specic test system interface they need:
>
> testcase NeedingTwoPorts() runs on MyComponent system TSI_2
> {
> ...
> }
>
> *
> **Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Solonplatz 3 phone: +49 30 9606 7985
> 13088 Berlin fax: +49 30 9606 7987
> Germany
> *

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




Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Solonplatz 3 phone: +49 30 9606 7985
13088 Berlin fax: +49 30 9606 7987
Germany






Claude Desroches email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Solonplatz 3 phone: +49 30 9606 7985
13088 Berlin fax: +49 30 9606 7987
Germany