TOPIC:

Hello Jens and all,

(Long time, no see!)

Now that Stephan brought up a question about differences between TTCN-2
and TTCN-3, I wanted to do the same regarding the semantics of defaults
in TTCN-3.

TTCN-3 is a rather new language and tool vendors are just about now
starting to provide the market with acceptable tools for large scale
projects.

A tool of importance in this scope is any tool that can help customers
migrate their old TTCN-2 suites to TTCN-3 ones. As these tools are
rather new as well, some of the problems with the mappings from TTCN-2
to TTCN-3 have not yet surfaced. But the problems that have surfaced
seem to be the same for different vendors and for this reason I thought
this forum would be a proper place where I could ask this question.

TTCN-2 defaults are much more local than TTCN-3 defaults. In TTCN-3 a
default list is more global and is kept for a test component. Using
"activate" to change the list of defaults has the mysterious definition
of appending the new default to the current default list, instead of
replacing it with a new default list.

In this way a called step "inherits" the default list of the caller in
such way that the callers default(s) will be invoked before the defaults
added with the local "activate" command. It is possible in TTCN-3 to
clear the default list by using "deactivate" without arguments, but then
there is no way to restore that list in a simple way, specially because
a called step doesn't know from how many places it can be called and
with which default lists.

Why have the default semantics been redesigned to something so different
in TTCN-3? Do you remember the ideas behind this design? Without a
proper mechanism at language level in TTCN-3 to allow something similar
as in TTCN-2 some of the generated solutions from tool vendors are
really too complex.

If you have the time, could you explain to me why we have this major
difference? Also, with the arguments above, would it be easy to get a CR
through to address these problems? I have several ideas in my head that
in rather simple ways would provide some kind of solution...

Best regards,

Fedde

Hi Fedde,

you are now with NOKIA? Where? In Finnland or in Sweden?

To answer your questions will cost me some time, which I haven't
today. I will answer them tomorrow.

Regards
Jens


> Federico Engler schrieb:
>
> Hello Jens and all,
>
> (Long time, no see!)
>
> Now that Stephan brought up a question about differences between
> TTCN-2
> and TTCN-3, I wanted to do the same regarding the semantics of
> defaults
> in TTCN-3.
>
> TTCN-3 is a rather new language and tool vendors are just about now
> starting to provide the market with acceptable tools for large scale
> projects.
>
> A tool of importance in this scope is any tool that can help customers
> migrate their old TTCN-2 suites to TTCN-3 ones. As these tools are
> rather new as well, some of the problems with the mappings from TTCN-2
> to TTCN-3 have not yet surfaced. But the problems that have surfaced
> seem to be the same for different vendors and for this reason I
> thought
> this forum would be a proper place where I could ask this question.
>
> TTCN-2 defaults are much more local than TTCN-3 defaults. In TTCN-3 a
> default list is more global and is kept for a test component. Using
> "activate" to change the list of defaults has the mysterious
> definition
> of appending the new default to the current default list, instead of
> replacing it with a new default list.
>
> In this way a called step "inherits" the default list of the caller in
> such way that the callers default(s) will be invoked before the
> defaults
> added with the local "activate" command. It is possible in TTCN-3 to
> clear the default list by using "deactivate" without arguments, but
> then
> there is no way to restore that list in a simple way, specially
> because
> a called step doesn't know from how many places it can be called and
> with which default lists.
>
> Why have the default semantics been redesigned to something so
> different
> in TTCN-3? Do you remember the ideas behind this design? Without a
> proper mechanism at language level in TTCN-3 to allow something
> similar
> as in TTCN-2 some of the generated solutions from tool vendors are
> really too complex.
>
> If you have the time, could you explain to me why we have this major
> difference? Also, with the arguments above, would it be easy to get a
> CR
> through to address these problems? I have several ideas in my head
> that
> in rather simple ways would provide some kind of solution...
>
> Best regards,
>
> Fedde

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

Hello Jens,

Yes...I work for Nokia here in Helsinki :-)

I don't mean to push or anything, but I feel this subject might again fall
away. I am very interested in knowing what arguments were highlighthed for
the selection of the current default handling semantics. Surely some extra
benefits must have been identified to make the change?

I would simply like to know the history of this...

Best regards,

Fedde

>

---

Original Message

---

> From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 26 February, 2003 15:44
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Question about design of default handling...
>
>
> Hi Fedde,
>
> you are now with NOKIA? Where? In Finnland or in Sweden?
>
> To answer your questions will cost me some time, which I haven't
> today. I will answer them tomorrow.
>
> Regards
> Jens
>
>
> > Federico Engler schrieb:
> >
> > Hello Jens and all,
> >
> > (Long time, no see!)
> >
> > Now that Stephan brought up a question about differences between
> > TTCN-2
> > and TTCN-3, I wanted to do the same regarding the semantics of
> > defaults
> > in TTCN-3.
> >
> > TTCN-3 is a rather new language and tool vendors are just about now
> > starting to provide the market with acceptable tools for large scale
> > projects.
> >
> > A tool of importance in this scope is any tool that can
> help customers
> > migrate their old TTCN-2 suites to TTCN-3 ones. As these tools are
> > rather new as well, some of the problems with the mappings
> from TTCN-2
> > to TTCN-3 have not yet surfaced. But the problems that have surfaced
> > seem to be the same for different vendors and for this reason I
> > thought
> > this forum would be a proper place where I could ask this question.
> >
> > TTCN-2 defaults are much more local than TTCN-3 defaults.
> In TTCN-3 a
> > default list is more global and is kept for a test component. Using
> > "activate" to change the list of defaults has the mysterious
> > definition
> > of appending the new default to the current default list, instead of
> > replacing it with a new default list.
> >
> > In this way a called step "inherits" the default list of
> the caller in
> > such way that the callers default(s) will be invoked before the
> > defaults
> > added with the local "activate" command. It is possible in TTCN-3 to
> > clear the default list by using "deactivate" without arguments, but
> > then
> > there is no way to restore that list in a simple way, specially
> > because
> > a called step doesn't know from how many places it can be called and
> > with which default lists.
> >
> > Why have the default semantics been redesigned to something so
> > different
> > in TTCN-3? Do you remember the ideas behind this design? Without a
> > proper mechanism at language level in TTCN-3 to allow something
> > similar
> > as in TTCN-2 some of the generated solutions from tool vendors are
> > really too complex.
> >
> > If you have the time, could you explain to me why we have this major
> > difference? Also, with the arguments above, would it be
> easy to get a
> > CR
> > through to address these problems? I have several ideas in my head
> > that
> > in rather simple ways would provide some kind of solution...
> >
> > Best regards,
> >
> > Fedde
>
> --
>
> ======================================================================
> Dr. Jens Grabowski
> Institute for Telematics phone: +49 451 500 3723
> University of Luebeck fax: +49 451 500 3722
> Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> (Germany) WWW: www.itm.mu-luebeck.de
> ======================================================================
>

Hi Fedde,

first of congratulations for your new job. Hope it was your wish to
change from Sweden to Finnland.

A complete discussion/comparison of both default mechanisms would
require a lot of time, therefore I only sketch a few issues.

The default mechanism of TTCN-3 has been redesigned several times
during the time I was involved in the TTCN-3 development. The
main requirements for the TTCN-3 mechanism were:

- removal of the macro expansion mechanism of TTCN-2
- introduction of scope into defaults
- allow to have defaults related to test components rather
then defaults related to one behaviour definition only.


However, some people may think that the TTCN-2 mechanism is more
simple, but it isn't.

First of all, it is a macro expansion mechanism without scope.
One drawback of this is that in TTCN-2 a default definition can only
be analysed after its expansion in the behaviour definition. The
same name may have different meanings in different behaviour
definitions. Another drawback of this is the think that you call
'much more local' it is not possible (at least not easily and
definitely not easy to understand) to make the macro mechanism
less local, e.g., defining a general default for a component.

Second, the TTCN-2 default mechanism is not that local as most
people think, consider the following example

TestStep1 with Default2
PCO3 ? m5
PCO4 ? m6

Testcase1 with Default1
PCO1 ! m1
PCO1 ? m2
+ TestStep1
PCO2 ? m3

The question now is: What defaults are used in TestStep1 if
TestStep1 is expanded in Testcase1? The answer might be a little
bit suprising. For the first level of indentation in Teststep1
Default1 (the default of Testcase1) has to be used and not
Default2. For the second level of indentation, Default2 is used.


The default mechanism of TTCN-3 avoids the TTCN-2 problems and
offers more flexibility for the use of defaults. The drawback
is that due to the transfer of defaults into different scope units,
the active defaults are not always visible, but as you have seen
in the example above, this is also true for some special cases
of TTCN-2.

Best regards
Jens








> Federico Engler schrieb:
>
> Hello Jens and all,
>
> (Long time, no see!)
>
> Now that Stephan brought up a question about differences between
> TTCN-2
> and TTCN-3, I wanted to do the same regarding the semantics of
> defaults
> in TTCN-3.
>
> TTCN-3 is a rather new language and tool vendors are just about now
> starting to provide the market with acceptable tools for large scale
> projects.
>
> A tool of importance in this scope is any tool that can help customers
> migrate their old TTCN-2 suites to TTCN-3 ones. As these tools are
> rather new as well, some of the problems with the mappings from TTCN-2
> to TTCN-3 have not yet surfaced. But the problems that have surfaced
> seem to be the same for different vendors and for this reason I
> thought
> this forum would be a proper place where I could ask this question.
>
> TTCN-2 defaults are much more local than TTCN-3 defaults. In TTCN-3 a
> default list is more global and is kept for a test component. Using
> "activate" to change the list of defaults has the mysterious
> definition
> of appending the new default to the current default list, instead of
> replacing it with a new default list.
>
> In this way a called step "inherits" the default list of the caller in
> such way that the callers default(s) will be invoked before the
> defaults
> added with the local "activate" command. It is possible in TTCN-3 to
> clear the default list by using "deactivate" without arguments, but
> then
> there is no way to restore that list in a simple way, specially
> because
> a called step doesn't know from how many places it can be called and
> with which default lists.
>
> Why have the default semantics been redesigned to something so
> different
> in TTCN-3? Do you remember the ideas behind this design? Without a
> proper mechanism at language level in TTCN-3 to allow something
> similar
> as in TTCN-2 some of the generated solutions from tool vendors are
> really too complex.
>
> If you have the time, could you explain to me why we have this major
> difference? Also, with the arguments above, would it be easy to get a
> CR
> through to address these problems? I have several ideas in my head
> that
> in rather simple ways would provide some kind of solution...
>
> Best regards,
>
> Fedde

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

Dear Jens,

Thank you for your congratulations and also for taking the time to
give me some feedback on the question about defaults. What you write
to me regarding the design is known to me before and I completely
agree that the rule about the callers default applying only on the
first level of an attached step is strange endeed :-)

I still find that rule to be less problematic than the current design
in TTCN-3, because in TTCN-2 you at least knew that an old default
list applied on the first step level and then not further down. In
TTCN-3, if you have a long chain of calls, you have to trace that
code backwards to get some kind of idea about the default list you
are bringing down to a called step. This affects greatly the way in
which users now should design their defaults.

Please understand that I in no way am asking that we should remove
this. I am sure several discussions have been had around this issue.
What I am asking on the other hand is for an additional simple
mechanism to allow TTCN-3 users to emulate the previous behaviour if
they find the need for it.

In other words...TTCN-3 as it is would still have the current
semantics, but with a mechanism to be allowed to save and restore a
complete default list at any level the user wishes. Such mechanism
would give additional flexibility in what the user can model in terms
of default behaviour.

Without any single doubt, the biggest reason for designing a mapping
from TTCN-2 to TTCN-3 was to make sure that the TTCN-2 users would
not feel left out and would feel there was a way for them to easily
move into the TTCN-3 world without time consuming efforts. With the
current default handling design there is a great effort of revising
your whole default handling.

Looking at it from the point of view of language design, to get
another angle on the matter, it looks to me like there is a big "hole"
in the design, which is what I am asking to address. The "hole" is
the following...you are allowed to activate and deactivate a single
default in TTCN-3. Then by using "deactivate" without parameters you
are allowed to clear a whole default list...so naturally I ask myself
where is the mechanism to also restore or set a complete default list?
Another weakness with deactivate is that you need to know which default
to deactivate, which you can't always know, as a test can be called
from so many different places.

So to summarize...what I am asking for is nothing that breaks the
current solution. I am asking for an additional mechanism that also
makes it easier for tool vendors to provide straight-forward solutions
to this problem. If the cost of moving from TTCN-2 to TTCN-3 becomes
too big in the eyes of potential customers, we are shooting ourselves
in the foot by slowing down the spread of the language. The additions
I am asking for are small and there are several ways of doing this.
Here is one proposal:

* Extend "deactivate" to do the same as it does today, but also return
the current default list so that it can be stored.

* Allow "activate" or some other machanism to set a complete default
list to avoid having to add a whole set of new list handling
funcitons.

I know you are very busy, but please let me know if it at least is worth
for me to write a CR on this?

Best regards,

Fedde

>

---

Original Message

---

> From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 04 March, 2003 14:23
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Question about design of default handling...
>
>
> Hi Fedde,
>
> first of congratulations for your new job. Hope it was your wish to
> change from Sweden to Finnland.
>
> A complete discussion/comparison of both default mechanisms would
> require a lot of time, therefore I only sketch a few issues.
>
> The default mechanism of TTCN-3 has been redesigned several times
> during the time I was involved in the TTCN-3 development. The
> main requirements for the TTCN-3 mechanism were:
>
> - removal of the macro expansion mechanism of TTCN-2
> - introduction of scope into defaults
> - allow to have defaults related to test components rather
> then defaults related to one behaviour definition only.
>
>
> However, some people may think that the TTCN-2 mechanism is more
> simple, but it isn't.
>
> First of all, it is a macro expansion mechanism without scope.
> One drawback of this is that in TTCN-2 a default definition can only
> be analysed after its expansion in the behaviour definition. The
> same name may have different meanings in different behaviour
> definitions. Another drawback of this is the think that you call
> 'much more local' it is not possible (at least not easily and
> definitely not easy to understand) to make the macro mechanism
> less local, e.g., defining a general default for a component.
>
> Second, the TTCN-2 default mechanism is not that local as most
> people think, consider the following example
>
> TestStep1 with Default2
> PCO3 ? m5
> PCO4 ? m6
>
> Testcase1 with Default1
> PCO1 ! m1
> PCO1 ? m2
> + TestStep1
> PCO2 ? m3
>
> The question now is: What defaults are used in TestStep1 if
> TestStep1 is expanded in Testcase1? The answer might be a little
> bit suprising. For the first level of indentation in Teststep1
> Default1 (the default of Testcase1) has to be used and not
> Default2. For the second level of indentation, Default2 is used.
>
>
> The default mechanism of TTCN-3 avoids the TTCN-2 problems and
> offers more flexibility for the use of defaults. The drawback
> is that due to the transfer of defaults into different scope units,
> the active defaults are not always visible, but as you have seen
> in the example above, this is also true for some special cases
> of TTCN-2.
>
> Best regards
> Jens
>
>
>
>
>
>
>
>
> > Federico Engler schrieb:
> >
> > Hello Jens and all,
> >
> > (Long time, no see!)
> >
> > Now that Stephan brought up a question about differences between
> > TTCN-2
> > and TTCN-3, I wanted to do the same regarding the semantics of
> > defaults
> > in TTCN-3.
> >
> > TTCN-3 is a rather new language and tool vendors are just about now
> > starting to provide the market with acceptable tools for large scale
> > projects.
> >
> > A tool of importance in this scope is any tool that can
> help customers
> > migrate their old TTCN-2 suites to TTCN-3 ones. As these tools are
> > rather new as well, some of the problems with the mappings
> from TTCN-2
> > to TTCN-3 have not yet surfaced. But the problems that have surfaced
> > seem to be the same for different vendors and for this reason I
> > thought
> > this forum would be a proper place where I could ask this question.
> >
> > TTCN-2 defaults are much more local than TTCN-3 defaults.
> In TTCN-3 a
> > default list is more global and is kept for a test component. Using
> > "activate" to change the list of defaults has the mysterious
> > definition
> > of appending the new default to the current default list, instead of
> > replacing it with a new default list.
> >
> > In this way a called step "inherits" the default list of
> the caller in
> > such way that the callers default(s) will be invoked before the
> > defaults
> > added with the local "activate" command. It is possible in TTCN-3 to
> > clear the default list by using "deactivate" without arguments, but
> > then
> > there is no way to restore that list in a simple way, specially
> > because
> > a called step doesn't know from how many places it can be called and
> > with which default lists.
> >
> > Why have the default semantics been redesigned to something so
> > different
> > in TTCN-3? Do you remember the ideas behind this design? Without a
> > proper mechanism at language level in TTCN-3 to allow something
> > similar
> > as in TTCN-2 some of the generated solutions from tool vendors are
> > really too complex.
> >
> > If you have the time, could you explain to me why we have this major
> > difference? Also, with the arguments above, would it be
> easy to get a
> > CR
> > through to address these problems? I have several ideas in my head
> > that
> > in rather simple ways would provide some kind of solution...
> >
> > Best regards,
> >
> > Fedde
>
> --
>
> ======================================================================
> Dr. Jens Grabowski
> Institute for Telematics phone: +49 451 500 3723
> University of Luebeck fax: +49 451 500 3722
> Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> (Germany) WWW: www.itm.mu-luebeck.de
> ======================================================================
>

In einer eMail vom 3/5/03 10:14:23 AM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi Fedde,

The reason that defaults are only attached from level of indentation 1
instead of
level of indentation 0 in test steps (as opposed to test cases where they are
attached at level of indentation 0), is to prevent test step defaults from
'hiding' other alternatives which might follow at the level of indentation at
which
a test step was attached. Usually most defaults include a reference to
an pcox ? OTHERWISE.

E.g. TC1 with Def1 TS1 with Def2 (containing an otherwise)

TC1 TS1 Def2
!x ?w1 ?
OTHERWISE
?y ?zz
?w ?a
+TS1
?z
!j
If we would expand defaults the same way in test steps as in test cases we
would have
the following:
!x
?y
?w
?w1 (TS1 expansion)
?zz
?OTHERWISE (Def2 expansion
?a
?OTHERWISE
?z (dead code from this point on)
!j
+Def1 (not expanded)
+Def1 (not expanded


> Thank you for your congratulations and also for taking the time to
> give me some feedback on the question about defaults. What you write
> to me regarding the design is known to me before and I completely
> agree that the rule about the callers default applying only on the
> first level of an attached step is strange endeed :-)
>

Cheers,


Claude.

Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany

In einer eMail vom 3/5/03 10:14:23 AM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi Fedde,

> Please understand that I in no way am asking that we should remove
> this. I am sure several discussions have been had around this issue.
> What I am asking on the other hand is for an additional simple
> mechanism to allow TTCN-3 users to emulate the previous behaviour if
> they find the need for it.

The simplest way to emulate TTCN-2 defaults behaviour in TTCN-3 is to
use altsteps. This of course will make your test cases larger, but you
will be able to implement exactly the behaviour you wish to have. On top
of that, you can use inout parameters for each formal parameter argument
in altstep, as TTCN-3 defaults only permit the use of in formal parameter
arguments. :-)

Hope this helps.


Cheers,

Claude.

Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany

Hi Claude,

I have had this discussion with other people so other people
who read this might think I am repeating myself here :-)

Your proposed solution with altsteps is unfortunately not an
acceptable one for users in terms of user friendly TTCN or
maintainability. Also such solution forces the user to more
or less take charge of the default handling in a hard-wired way,
which again is not an acceptable.

Best regards,

Fedde

---

Original Message

---

From: ext Claude Desroches [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 05 March, 2003 16:55
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Question about design of default handling...


In einer eMail vom 3/5/03 10:14:23 AM W. Europe Standard Time schreibt This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi Fedde,



Please understand that I in no way am asking that we should remove
this. I am sure several discussions have been had around this issue.
What I am asking on the other hand is for an additional simple
mechanism to allow TTCN-3 users to emulate the previous behaviour if
they find the need for it.



The simplest way to emulate TTCN-2 defaults behaviour in TTCN-3 is to
use altsteps. This of course will make your test cases larger, but you
will be able to implement exactly the behaviour you wish to have. On top
of that, you can use inout parameters for each formal parameter argument
in altstep, as TTCN-3 defaults only permit the use of in formal parameter
arguments. :-)

Hope this helps.


Cheers,

Claude.

Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany

Federico Engler schrieb:
>
> Dear Jens,
>
> Thank you for your congratulations and also for taking the time to
> give me some feedback on the question about defaults. What you write
> to me regarding the design is known to me before and I completely
> agree that the rule about the callers default applying only on the
> first level of an attached step is strange endeed :-)
>
> I still find that rule to be less problematic than the current design
> in TTCN-3, because in TTCN-2 you at least knew that an old default
> list applied on the first step level and then not further down. In
> TTCN-3, if you have a long chain of calls, you have to trace that
> code backwards to get some kind of idea about the default list you
> are bringing down to a called step. This affects greatly the way in
> which users now should design their defaults.
>
> Please understand that I in no way am asking that we should remove
> this. I am sure several discussions have been had around this issue.
> What I am asking on the other hand is for an additional simple
> mechanism to allow TTCN-3 users to emulate the previous behaviour if
> they find the need for it.
>
> In other words...TTCN-3 as it is would still have the current
> semantics, but with a mechanism to be allowed to save and restore a
> complete default list at any level the user wishes. Such mechanism
> would give additional flexibility in what the user can model in terms
> of default behaviour.
>
> Without any single doubt, the biggest reason for designing a mapping
> from TTCN-2 to TTCN-3 was to make sure that the TTCN-2 users would
> not feel left out and would feel there was a way for them to easily
> move into the TTCN-3 world without time consuming efforts. With the
> current default handling design there is a great effort of revising
> your whole default handling.
>
> Looking at it from the point of view of language design, to get
> another angle on the matter, it looks to me like there is a big "hole"
> in the design, which is what I am asking to address. The "hole" is
> the following...you are allowed to activate and deactivate a single
> default in TTCN-3. Then by using "deactivate" without parameters you
> are allowed to clear a whole default list...so naturally I ask myself
> where is the mechanism to also restore or set a complete default list?
> Another weakness with deactivate is that you need to know which default
> to deactivate, which you can't always know, as a test can be called
> from so many different places.
>
> So to summarize...what I am asking for is nothing that breaks the
> current solution. I am asking for an additional mechanism that also
> makes it easier for tool vendors to provide straight-forward solutions
> to this problem. If the cost of moving from TTCN-2 to TTCN-3 becomes
> too big in the eyes of potential customers, we are shooting ourselves
> in the foot by slowing down the spread of the language. The additions
> I am asking for are small and there are several ways of doing this.
> Here is one proposal:
>
> * Extend "deactivate" to do the same as it does today, but also return
> the current default list so that it can be stored.
>
> * Allow "activate" or some other machanism to set a complete default
> list to avoid having to add a whole set of new list handling
> funcitons.
>
> I know you are very busy, but please let me know if it at least is worth
> for me to write a CR on this?
>
> Best regards,
>
> Fedde
>
> >

---

Original Message

---

> > From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > Sent: 04 March, 2003 14:23
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Re: Question about design of default handling...
> >
> >
> > Hi Fedde,
> >
> > first of congratulations for your new job. Hope it was your wish to
> > change from Sweden to Finnland.
> >
> > A complete discussion/comparison of both default mechanisms would
> > require a lot of time, therefore I only sketch a few issues.
> >
> > The default mechanism of TTCN-3 has been redesigned several times
> > during the time I was involved in the TTCN-3 development. The
> > main requirements for the TTCN-3 mechanism were:
> >
> > - removal of the macro expansion mechanism of TTCN-2
> > - introduction of scope into defaults
> > - allow to have defaults related to test components rather
> > then defaults related to one behaviour definition only.
> >
> >
> > However, some people may think that the TTCN-2 mechanism is more
> > simple, but it isn't.
> >
> > First of all, it is a macro expansion mechanism without scope.
> > One drawback of this is that in TTCN-2 a default definition can only
> > be analysed after its expansion in the behaviour definition. The
> > same name may have different meanings in different behaviour
> > definitions. Another drawback of this is the think that you call
> > 'much more local' it is not possible (at least not easily and
> > definitely not easy to understand) to make the macro mechanism
> > less local, e.g., defining a general default for a component.
> >
> > Second, the TTCN-2 default mechanism is not that local as most
> > people think, consider the following example
> >
> > TestStep1 with Default2
> > PCO3 ? m5
> > PCO4 ? m6
> >
> > Testcase1 with Default1
> > PCO1 ! m1
> > PCO1 ? m2
> > + TestStep1
> > PCO2 ? m3
> >
> > The question now is: What defaults are used in TestStep1 if
> > TestStep1 is expanded in Testcase1? The answer might be a little
> > bit suprising. For the first level of indentation in Teststep1
> > Default1 (the default of Testcase1) has to be used and not
> > Default2. For the second level of indentation, Default2 is used.
> >
> >
> > The default mechanism of TTCN-3 avoids the TTCN-2 problems and
> > offers more flexibility for the use of defaults. The drawback
> > is that due to the transfer of defaults into different scope units,
> > the active defaults are not always visible, but as you have seen
> > in the example above, this is also true for some special cases
> > of TTCN-2.
> >
> > Best regards
> > Jens
> >
> >
> >
> >
> >
> >
> >
> >
> > > Federico Engler schrieb:
> > >
> > > Hello Jens and all,
> > >
> > > (Long time, no see!)
> > >
> > > Now that Stephan brought up a question about differences between
> > > TTCN-2
> > > and TTCN-3, I wanted to do the same regarding the semantics of
> > > defaults
> > > in TTCN-3.
> > >
> > > TTCN-3 is a rather new language and tool vendors are just about now
> > > starting to provide the market with acceptable tools for large scale
> > > projects.
> > >
> > > A tool of importance in this scope is any tool that can
> > help customers
> > > migrate their old TTCN-2 suites to TTCN-3 ones. As these tools are
> > > rather new as well, some of the problems with the mappings
> > from TTCN-2
> > > to TTCN-3 have not yet surfaced. But the problems that have surfaced
> > > seem to be the same for different vendors and for this reason I
> > > thought
> > > this forum would be a proper place where I could ask this question.
> > >
> > > TTCN-2 defaults are much more local than TTCN-3 defaults.
> > In TTCN-3 a
> > > default list is more global and is kept for a test component. Using
> > > "activate" to change the list of defaults has the mysterious
> > > definition
> > > of appending the new default to the current default list, instead of
> > > replacing it with a new default list.
> > >
> > > In this way a called step "inherits" the default list of
> > the caller in
> > > such way that the callers default(s) will be invoked before the
> > > defaults
> > > added with the local "activate" command. It is possible in TTCN-3 to
> > > clear the default list by using "deactivate" without arguments, but
> > > then
> > > there is no way to restore that list in a simple way, specially
> > > because
> > > a called step doesn't know from how many places it can be called and
> > > with which default lists.
> > >
> > > Why have the default semantics been redesigned to something so
> > > different
> > > in TTCN-3? Do you remember the ideas behind this design? Without a
> > > proper mechanism at language level in TTCN-3 to allow something
> > > similar
> > > as in TTCN-2 some of the generated solutions from tool vendors are
> > > really too complex.
> > >
> > > If you have the time, could you explain to me why we have this major
> > > difference? Also, with the arguments above, would it be
> > easy to get a
> > > CR
> > > through to address these problems? I have several ideas in my head
> > > that
> > > in rather simple ways would provide some kind of solution...
> > >
> > > Best regards,
> > >
> > > Fedde
> >
> > --
> >
> > ======================================================================
> > Dr. Jens Grabowski
> > Institute for Telematics phone: +49 451 500 3723
> > University of Luebeck fax: +49 451 500 3722
> > Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> > (Germany) WWW: www.itm.mu-luebeck.de
> > ======================================================================
> >

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

Hi Fedde,

your Email go in different directions. First you asked for reasons
for the change of the default mechanism and now you give arguments
for the re-introduction of the macro-based default mechanism.

Some comments (the first three items only repeat my standpoint on this
issue, the fourth item is related to your concrete proposal):

First of all, you can model the TTCN-2 default mechanism with the
current TTCN-3 default mechanism. In some cases, the TTCN-3 code
may look a little bit clumsy, but this is the normal case if you
translate constructs from one formalism into another.

Second, TTCN-3 is different to TTCN-2. This also means that
'Hardcore TTCN-2 users' cannot always use the same test specification
style when using TTCN-3. I consider this as normal: a change of
tools requires a change of working style. If your users don't want
to make this change, they should continue to use TTCN-2.
(This does not mean that the old users are old fashioned or stupid,
it only means that you should use the tools/languages that are best
for you and for solving your problems.)

Third, the TTCN-3 default mechanism was heavily discussed. I don't
believe that a duplication of features by the re-introduction of
the old macro-based mechanism has no chance as CR. It was a major
goal of TTCN-3 to remove these macro mechanisms.

Fourth, your concrete proposal:
> Here is one proposal:
>
> * Extend "deactivate" to do the same as it does today, but also return
> the current default list so that it can be stored.
>
> * Allow "activate" or some other machanism to set a complete default
> list to avoid having to add a whole set of new list handling
> funcitons.

I undestand all your arguments for this proposal, even though I don't
see the concrete relation to TTCN-2 users. In TTCN-2 you only have one
default activated at a time, or activation and deactivation of defaults
within one behaviour. This you can easily do in TTCN-3. Therefore, I do
not see the need to retrieve/restore complete lists of defaults.

However, after thinking a little bit about the essence of your proposal,
you are mainly asking for a function which returns a list (or array)
of all active defaults. By having this function, it is easy
to write the required extensions of activate and deactivate yourself
(and possibly put these extensions as useful functions into an annex,
if we do not want to change the current activate and deactivate
operations). I think it might be worth for you to write a CR on this.

Regards
Jens








Federico Engler schrieb:
>
> Dear Jens,
>
> Thank you for your congratulations and also for taking the time to
> give me some feedback on the question about defaults. What you write
> to me regarding the design is known to me before and I completely
> agree that the rule about the callers default applying only on the
> first level of an attached step is strange endeed :-)
>
> I still find that rule to be less problematic than the current design
> in TTCN-3, because in TTCN-2 you at least knew that an old default
> list applied on the first step level and then not further down. In
> TTCN-3, if you have a long chain of calls, you have to trace that
> code backwards to get some kind of idea about the default list you
> are bringing down to a called step. This affects greatly the way in
> which users now should design their defaults.
>
> Please understand that I in no way am asking that we should remove
> this. I am sure several discussions have been had around this issue.
> What I am asking on the other hand is for an additional simple
> mechanism to allow TTCN-3 users to emulate the previous behaviour if
> they find the need for it.
>
> In other words...TTCN-3 as it is would still have the current
> semantics, but with a mechanism to be allowed to save and restore a
> complete default list at any level the user wishes. Such mechanism
> would give additional flexibility in what the user can model in terms
> of default behaviour.
>
> Without any single doubt, the biggest reason for designing a mapping
> from TTCN-2 to TTCN-3 was to make sure that the TTCN-2 users would
> not feel left out and would feel there was a way for them to easily
> move into the TTCN-3 world without time consuming efforts. With the
> current default handling design there is a great effort of revising
> your whole default handling.
>
> Looking at it from the point of view of language design, to get
> another angle on the matter, it looks to me like there is a big "hole"
> in the design, which is what I am asking to address. The "hole" is
> the following...you are allowed to activate and deactivate a single
> default in TTCN-3. Then by using "deactivate" without parameters you
> are allowed to clear a whole default list...so naturally I ask myself
> where is the mechanism to also restore or set a complete default list?
> Another weakness with deactivate is that you need to know which default
> to deactivate, which you can't always know, as a test can be called
> from so many different places.
>
> So to summarize...what I am asking for is nothing that breaks the
> current solution. I am asking for an additional mechanism that also
> makes it easier for tool vendors to provide straight-forward solutions
> to this problem. If the cost of moving from TTCN-2 to TTCN-3 becomes
> too big in the eyes of potential customers, we are shooting ourselves
> in the foot by slowing down the spread of the language. The additions
> I am asking for are small and there are several ways of doing this.
> Here is one proposal:
>
> * Extend "deactivate" to do the same as it does today, but also return
> the current default list so that it can be stored.
>
> * Allow "activate" or some other machanism to set a complete default
> list to avoid having to add a whole set of new list handling
> funcitons.
>
> I know you are very busy, but please let me know if it at least is worth
> for me to write a CR on this?
>
> Best regards,
>
> Fedde
>
> >

---

Original Message

---

> > From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > Sent: 04 March, 2003 14:23
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Re: Question about design of default handling...
> >
> >
> > Hi Fedde,
> >
> > first of congratulations for your new job. Hope it was your wish to
> > change from Sweden to Finnland.
> >
> > A complete discussion/comparison of both default mechanisms would
> > require a lot of time, therefore I only sketch a few issues.
> >
> > The default mechanism of TTCN-3 has been redesigned several times
> > during the time I was involved in the TTCN-3 development. The
> > main requirements for the TTCN-3 mechanism were:
> >
> > - removal of the macro expansion mechanism of TTCN-2
> > - introduction of scope into defaults
> > - allow to have defaults related to test components rather
> > then defaults related to one behaviour definition only.
> >
> >
> > However, some people may think that the TTCN-2 mechanism is more
> > simple, but it isn't.
> >
> > First of all, it is a macro expansion mechanism without scope.
> > One drawback of this is that in TTCN-2 a default definition can only
> > be analysed after its expansion in the behaviour definition. The
> > same name may have different meanings in different behaviour
> > definitions. Another drawback of this is the think that you call
> > 'much more local' it is not possible (at least not easily and
> > definitely not easy to understand) to make the macro mechanism
> > less local, e.g., defining a general default for a component.
> >
> > Second, the TTCN-2 default mechanism is not that local as most
> > people think, consider the following example
> >
> > TestStep1 with Default2
> > PCO3 ? m5
> > PCO4 ? m6
> >
> > Testcase1 with Default1
> > PCO1 ! m1
> > PCO1 ? m2
> > + TestStep1
> > PCO2 ? m3
> >
> > The question now is: What defaults are used in TestStep1 if
> > TestStep1 is expanded in Testcase1? The answer might be a little
> > bit suprising. For the first level of indentation in Teststep1
> > Default1 (the default of Testcase1) has to be used and not
> > Default2. For the second level of indentation, Default2 is used.
> >
> >
> > The default mechanism of TTCN-3 avoids the TTCN-2 problems and
> > offers more flexibility for the use of defaults. The drawback
> > is that due to the transfer of defaults into different scope units,
> > the active defaults are not always visible, but as you have seen
> > in the example above, this is also true for some special cases
> > of TTCN-2.
> >
> > Best regards
> > Jens
> >
> >
> >
> >
> >
> >
> >
> >
> > > Federico Engler schrieb:
> > >
> > > Hello Jens and all,
> > >
> > > (Long time, no see!)
> > >
> > > Now that Stephan brought up a question about differences between
> > > TTCN-2
> > > and TTCN-3, I wanted to do the same regarding the semantics of
> > > defaults
> > > in TTCN-3.
> > >
> > > TTCN-3 is a rather new language and tool vendors are just about now
> > > starting to provide the market with acceptable tools for large scale
> > > projects.
> > >
> > > A tool of importance in this scope is any tool that can
> > help customers
> > > migrate their old TTCN-2 suites to TTCN-3 ones. As these tools are
> > > rather new as well, some of the problems with the mappings
> > from TTCN-2
> > > to TTCN-3 have not yet surfaced. But the problems that have surfaced
> > > seem to be the same for different vendors and for this reason I
> > > thought
> > > this forum would be a proper place where I could ask this question.
> > >
> > > TTCN-2 defaults are much more local than TTCN-3 defaults.
> > In TTCN-3 a
> > > default list is more global and is kept for a test component. Using
> > > "activate" to change the list of defaults has the mysterious
> > > definition
> > > of appending the new default to the current default list, instead of
> > > replacing it with a new default list.
> > >
> > > In this way a called step "inherits" the default list of
> > the caller in
> > > such way that the callers default(s) will be invoked before the
> > > defaults
> > > added with the local "activate" command. It is possible in TTCN-3 to
> > > clear the default list by using "deactivate" without arguments, but
> > > then
> > > there is no way to restore that list in a simple way, specially
> > > because
> > > a called step doesn't know from how many places it can be called and
> > > with which default lists.
> > >
> > > Why have the default semantics been redesigned to something so
> > > different
> > > in TTCN-3? Do you remember the ideas behind this design? Without a
> > > proper mechanism at language level in TTCN-3 to allow something
> > > similar
> > > as in TTCN-2 some of the generated solutions from tool vendors are
> > > really too complex.
> > >
> > > If you have the time, could you explain to me why we have this major
> > > difference? Also, with the arguments above, would it be
> > easy to get a
> > > CR
> > > through to address these problems? I have several ideas in my head
> > > that
> > > in rather simple ways would provide some kind of solution...
> > >
> > > Best regards,
> > >
> > > Fedde
> >
> > --
> >
> > ======================================================================
> > Dr. Jens Grabowski
> > Institute for Telematics phone: +49 451 500 3723
> > University of Luebeck fax: +49 451 500 3722
> > Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
> > (Germany) WWW: www.itm.mu-luebeck.de
> > ======================================================================
> >

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

>

---

Original Message

---

> From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>
> Hi Fedde,

Hello again Jens,


> your Email go in different directions. First you asked for reasons
> for the change of the default mechanism and now you give arguments
> for the re-introduction of the macro-based default mechanism.

If you get this image, I guess I have been unclear in the way I have
written things. I am in no way trying to re-introduce the macro-based
mechanism. I think I stated that clearly in my mail. I am only asking
for a mechanism that would allow users to easily model the TTCN-2
default behaviour, if such need appears (which it initialy does when
people move from TTCN-2 to TTCN-3). Also observe clearly that my
proposal for the requiered additions in no way change the current
TTCN-3 default mechanism. Surely you do see that?


> First of all, you can model the TTCN-2 default mechanism with the
> current TTCN-3 default mechanism. In some cases, the TTCN-3 code
> may look a little bit clumsy, but this is the normal case if you
> translate constructs from one formalism into another.

I agree that you can model it with what is available in TTCN-3 now,
but the solution is extremely clumsy and at the end of the day, the
success of TTCN-3 is directly connected to how useful it becomes to
the people that really are going to use it. Also it is not just the
case it looks clumsy, it is a nightmare when looking at it from the
point of maintainability. In my current position within Nokia I have
customers who simply will not move into the TTCN-3 world if the
result of a conversion is that their TTCN-2 test cases result in
TTCN-3 test cases that are twice as large and twice as hard to
understand and maintain.


> Second, TTCN-3 is different to TTCN-2. This also means that
> 'Hardcore TTCN-2 users' cannot always use the same test specification
> style when using TTCN-3. I consider this as normal: a change of
> tools requires a change of working style. If your users don't want
> to make this change, they should continue to use TTCN-2.
> (This does not mean that the old users are old fashioned or stupid,
> it only means that you should use the tools/languages that are best
> for you and for solving your problems.)

Again I agree, but in this case the solution is not that far away. As
I mentioned before, I am NOT asking for a redesign of the current
language solution. I am asking for a small addition that seems to be
missing anyway, to narrow the gap between the two languages. You
must not forget that customers think in terms of time and money and
if things take too much time and money to convert, they will stick to
old solutions...something that at the end is negative for all of us
by slowing down the success of TTCN-3.


> Third, the TTCN-3 default mechanism was heavily discussed. I don't
> believe that a duplication of features by the re-introduction of
> the old macro-based mechanism has no chance as CR. It was a major
> goal of TTCN-3 to remove these macro mechanisms.

I am really confused about why you keep repeating that I want to
re-introduce the old macro mechanism. Please read my previous e-mails
again. Clearly all of them clearly state that I DON'T want to change
the current solution. Let me answer this to you by asking you two
questions:

1) In what way does the proposal to be able to store a default list
impose that I would like to re-introduce the macro mechanism?

2) In what way does the proposal to be able to activate a whole
default list impose that I would like to re-introduce the macro
mechanism?


> However, after thinking a little bit about the essence of
> your proposal,
> you are mainly asking for a function which returns a list (or array)
> of all active defaults. By having this function, it is easy
> to write the required extensions of activate and deactivate yourself
> (and possibly put these extensions as useful functions into an annex,
> if we do not want to change the current activate and deactivate
> operations). I think it might be worth for you to write a CR on this.

I am simply asking for a mechanism to at some point have the chance
of setting a default or default list, without "inheriting" the default
or defaults of the caller by first saving that old list, using the one
I want locally and the restoring it when I leave. It is up to the user
to write such code when the need arrise or for tool vendors of
convertor tools to provide better mappings which at the end of the
day are more easy to maintain. I will be sending in a CR about this
and it will NOT be a CR to re-introduce the old macro mechanism :-)

Best regards,

Fedde

Hi Fedde,


> > First of all, you can model the TTCN-2 default mechanism with the
> > current TTCN-3 default mechanism. In some cases, the TTCN-3 code
> > may look a little bit clumsy, but this is the normal case if you
> > translate constructs from one formalism into another.
>
> I agree that you can model it with what is available in TTCN-3 now,
> but the solution is extremely clumsy and at the end of the day, the
> success of TTCN-3 is directly connected to how useful it becomes to
> the people that really are going to use it. Also it is not just the
> case it looks clumsy, it is a nightmare when looking at it from the
> point of maintainability. In my current position within Nokia I have
> customers who simply will not move into the TTCN-3 world if the
> result of a conversion is that their TTCN-2 test cases result in
> TTCN-3 test cases that are twice as large and twice as hard to
> understand and maintain.


If you have a translator into TTCN-3, you do not necessarily have
to work on the TTCN-3 level for the maintenance of TTCN-2 test cases.
You can make the maintenance of old TTCN-2 test cases in TTCN-2 and
translate afterwards. The readability is then not important.

In an optimal environment tools may be integrated in such a way that
you are able to import TTCN-2 definitions into TTCN-3 modules (not
macros, but type definitions and test cases and possibly test
operations).

....


> > However, after thinking a little bit about the essence of
> > your proposal,
> > you are mainly asking for a function which returns a list (or array)
> > of all active defaults. By having this function, it is easy
> > to write the required extensions of activate and deactivate yourself
> > (and possibly put these extensions as useful functions into an annex,
> > if we do not want to change the current activate and deactivate
> > operations). I think it might be worth for you to write a CR on this.
>
> I am simply asking for a mechanism to at some point have the chance
> of setting a default or default list, without "inheriting" the default
> or defaults of the caller by first saving that old list, using the one
> I want locally and the restoring it when I leave. It is up to the user
> to write such code when the need arrise or for tool vendors of
> convertor tools to provide better mappings which at the end of the
> day are more easy to maintain. I will be sending in a CR about this
> and it will NOT be a CR to re-introduce the old macro mechanism :-)

I am not sure that this functionality really is needed, but I might be
mistaken.

If you want such a functionality, I am not sure that your proposal of
changing activate and deactivate is on the right level of abstraction.
I would not go the way of changing activate and deactivate. Instead, I
would leave the handling of the 'active' and 'passive lists of defaults'
to the compiler. For this, we only need a new function/altstep interface
(possibly just a new keyword like 'noDefault')
which indicates that the scope defined by the function/altstep does not
inherit defaults. However, this solution also requires some static
restrictions for the usage of altsteps/functions which do not inherit
defaults. But I think this can be done.

Regards
Jens

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================

In einer eMail vom 3/6/03 8:50:45 AM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:


>
> Hi Claude,
>

Hi Fedde,


> I have had this discussion with other people so other people
> who read this might think I am repeating myself here :-)
>
> Your proposed solution with altsteps is unfortunately not an
> acceptable one for users in terms of user friendly TTCN or
> maintainability. Also such solution forces the user to more
> or less take charge of the default handling in a hard-wired way,
> which again is not an acceptable.
>
The proposed solution was the only one we found which
did not require a CR to be issued, reviewed and
accepted by the TTCN-3 design team. :-).

I do admit, that more work is required by the user, and yes
the test cases do get larger, in cases where there are many
defaults.

An option which you might consider, is to modify the compiler
implementation by adding an compilation option which allows
users to write TTCN-3 code, but have it use TTCN-2 run-time
semantics and behaviour. There is no rule that prevents a tool
vendor from doing this of course! :-).

Your proposal which you submitted to Jens is worth thinking about!



Cheers,

Claude.

>
> Best regards,
>
> Fedde
>


Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany

Hi again, Jens!

>

---

Original Message

---

> From: ext Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>
> If you have a translator into TTCN-3, you do not necessarily have
> to work on the TTCN-3 level for the maintenance of TTCN-2 test cases.
> You can make the maintenance of old TTCN-2 test cases in TTCN-2 and
> translate afterwards. The readability is then not important.

That is of course one way to do it, but it requires that the customer
has two tool sets, which doubles the costs for them. These customers
want to move into the TTCN-3 world and stay there to make the future
additions at TTCN-3 level. In that case readability is a big issue.

> In an optimal environment tools may be integrated in such a way that
> you are able to import TTCN-2 definitions into TTCN-3 modules (not
> macros, but type definitions and test cases and possibly test
> operations).

Yes, but if such tools ever exist, they are way ahead in the future and
our customers need t move now :-)

> I am not sure that this functionality really is needed, but I might be
> mistaken.

I have customers specifically requesting this, so in their eyes this is
endeed needed.

> If you want such a functionality, I am not sure that your proposal of
> changing activate and deactivate is on the right level of abstraction.
> I would not go the way of changing activate and deactivate. Instead, I
> would leave the handling of the 'active' and 'passive lists
> of defaults'
> to the compiler. For this, we only need a new
> function/altstep interface
> (possibly just a new keyword like 'noDefault')
> which indicates that the scope defined by the
> function/altstep does not
> inherit defaults. However, this solution also requires some static
> restrictions for the usage of altsteps/functions which do not inherit
> defaults. But I think this can be done.

I'll write a CR and register it. We can then use those channels to get
to a solution that fits us all best.

Again, thanks for taking your time to answer all my questions about this ;-)


Best regards,

Fedde

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

Hi Jens,

This is a good solution, but I think it misses an important point. Most
customers
do not, or are not willing to support multiple testing environments. They
will want
to break away from TTCN-2 so that they can use TTCN-3 exclusively. Your
costs
increase of course when you are forced to use two different environments.
Many will want to translate their TTCN-2 ATSs to TTCN-3, move away from
TTCN-2
and continue with further development using TTCN-3 exclusively.

Requiring that your developers be familiar with TTCN-2 and TTCN-3 adds costs.
Since
TTCN-3 has more 'sex-appeal' than TTCN-2, especially for those already
familiar with
Java, C, C++, or other similar imperative, high level languages, my
experience is that
it has been a hard sell, to try to get engineers to use TTCN-2.

>
> If you have a translator into TTCN-3, you do not necessarily have
> to work on the TTCN-3 level for the maintenance of TTCN-2 test cases.
> You can make the maintenance of old TTCN-2 test cases in TTCN-2 and
> translate afterwards. The readability is then not important.
>
> In an optimal environment tools may be integrated in such a way that
> you are able to import TTCN-2 definitions into TTCN-3 modules (not
> macros, but type definitions and test cases and possibly test
> operations).

What about test steps and defaults (same as test cases I gather)?
Some more food for thought! :-). In this environment, which semantics would
you use? TTCN-2 or TTCN-3 ( I would want to use TTCN-3 of course).

Cheers,


Claude.


Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany