BM__Toc32045235BM__Toc15879505BM__Toc15699763Hi all,

In the TTCN3 Core Language standard you can read the following words :


BM__Toc32045234BM__Toc15879504BM__Toc1569976221.0 General


TTCN-3 allows the activation of altsteps (see clause 16.2) as defaults. For
each test component the defaults, i.e. activated altsteps, are stored in
form of a list. The defaults are listed in the order of their activation.
The TTCN-3 operations activate (see clause 21.3) and deactivate (see clause
21.4) operate on the list of defaults. An activate appends a new default to
the end of the list and a deactivate removes a default from the list. A
default in the default list can be identified by means of default reference
that is generated as a result of the corresponding activate operation.


21.1 The default mechanism


The default mechanism is evoked at the end of each alt statement, if due to
the actual snapshot none of the specified alternatives could be executed. An
evoked default mechanism invokes the first altstep in the list of defaults
and waits for the result of its termination. The termination can be
successful or unsuccessful. Unsuccessful means that none of the top
alternatives of the altstep (see clause 16.2) defining the default behaviour
could be selected, successful means that one of the top alternatives has
been selected and executed.

In case of an unsuccessful termination, the default mechanism invokes the
next default in the list. If the last default in the list has terminated
unsuccessfully, the default mechanism will return to the place in the alt
statement in which it has been invoked, i.e. at the end of the alt
statement, and indicate an unsuccessful default execution. An unsuccessful
default execution will also be indicated if the list of defaults is empty.



I would like understand why the list is not check in the other way.

For example I have the following testcase :



testcase TC_MyTest() runs on MyComponentType {

var default default1Var, default2Var := null;

default1Var := activate(MyAltstep1());



// Some more code here...



default2Var := activate(MyAltstep2());

alt {

[] p1.receive(MyMessage0) {

setverdict(pass); } // test OK

stop;

} // END alt

deactivate(default1Var);

deactivate(default2Var);



} // END testcase TC_MyTest()



The default behaviors are defined below:

altstep MyAltstep1() runs on MyComponentType {

[] any port.receive { // Do something }

[] any timer.timeout { // Do something }

}

altstep MyAltstep2() runs on MyComponentType {

[] p1.receive(MyMessage1) { // Do something }

[] p1.receive(MyMessage2){ // Do something }

}

If I understand well the standard when the default mechanism is invoked it
should check first "MyAltstep1" and then "MyAltstep2".

But in my case, it never check my second default because my first default is
matching with all the possible events.



So, I would like understand what is the reason of the evaluation order of
the default list.

How I should write my TTCN3 to describe such behavior.

Should I have to desactivate my first default then activate my second
default and reactivate my first default ?



Thank in advance for your answers.

Jean-Marc GUEVEL

---

Texas Instruments

Wireless Chipset Business Unit
BP5 - 06271 Villeneuve-Loubet Cedex
France

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

---

Hi,

The order of default activation has been changed as the result of CR 157 (agreed
on 11-Aug-2002), the new default is added to the list as the first element.
With the reversed order of default evaluation your example becomes OK but if you
change it to:
default1Var := activate(MyAltstep2());



// Some more code here...



default2Var := activate(MyAltstep1());



the evaluation never reaches MyAltstep2() after the activation of MyAltstep1()
(again); Except for a few cases you can choose the order of activating defaults.
One of the cases when you can not is e.g. if you activate a default in a
function/altstep called by another function/altstep. Naturally default
activation in the calling function/altstep is always happens earlier then the
default activation of the called function/altstep. This is the reason for the
reverse default evaluation order, in this way the default activated in the
"embedded" function/altstep becomes an "embedded" default, i.e. evaluated before
then the default activated in the outer function/altstep.



Gyorgy

---

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 Guevel, Jean-Marc
Sent: Monday, January 26, 2004 3:47 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Evaluation order of the list of default



BM__Toc32045235BM__Toc15879505BM__Toc15699763Hi all,

In the TTCN3 Core Language standard you can read the following words :


BM__Toc32045234BM__Toc15879504BM__Toc1569976221.0 General


TTCN-3 allows the activation of altsteps (see clause 16.2) as defaults. For each
test component the defaults, i.e. activated altsteps, are stored in form of a
list. The defaults are listed in the order of their activation. The TTCN-3
operations activate (see clause 21.3) and deactivate (see clause 21.4) operate
on the list of defaults. An activate appends a new default to the end of the
list and a deactivate removes a default from the list. A default in the default
list can be identified by means of default reference that is generated as a
result of the corresponding activate operation.


21.1 The default mechanism


The default mechanism is evoked at the end of each alt statement, if due to the
actual snapshot none of the specified alternatives could be executed. An evoked
default mechanism invokes the first altstep in the list of defaults and waits
for the result of its termination. The termination can be successful or
unsuccessful. Unsuccessful means that none of the top alternatives of the
altstep (see clause 16.2) defining the default behaviour could be selected,
successful means that one of the top alternatives has been selected and
executed.

In case of an unsuccessful termination, the default mechanism invokes the next
default in the list. If the last default in the list has terminated
unsuccessfully, the default mechanism will return to the place in the alt
statement in which it has been invoked, i.e. at the end of the alt statement,
and indicate an unsuccessful default execution. An unsuccessful default
execution will also be indicated if the list of defaults is empty.



I would like understand why the list is not check in the other way.

For example I have the following testcase :



testcase TC_MyTest() runs on MyComponentType {

var default default1Var, default2Var := null;

default1Var := activate(MyAltstep1());



// Some more code here...



default2Var := activate(MyAltstep2());

alt {

[] p1.receive(MyMessage0) {

setverdict(pass); } // test OK

stop;

} // END alt

deactivate(default1Var);

deactivate(default2Var);



} // END testcase TC_MyTest()



The default behaviors are defined below:

altstep MyAltstep1() runs on MyComponentType {

[] any port.receive { // Do something }

[] any timer.timeout { // Do something }

}

altstep MyAltstep2() runs on MyComponentType {

[] p1.receive(MyMessage1) { // Do something }

[] p1.receive(MyMessage2){ // Do something }

}

If I understand well the standard when the default mechanism is invoked it
should check first "MyAltstep1" and then "MyAltstep2".

But in my case, it never check my second default because my first default is
matching with all the possible events.



So, I would like understand what is the reason of the evaluation order of the
default list.

How I should write my TTCN3 to describe such behavior.

Should I have to desactivate my first default then activate my second default
and reactivate my first default ?



Thank in advance for your answers.

Jean-Marc GUEVEL

---

Texas Instruments

Wireless Chipset Business Unit
BP5 - 06271 Villeneuve-Loubet Cedex
France

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

---

Salut Jean-Marc,

>If I understand well the standard when the default mechanism is invoked it
>should check first "MyAltstep1" and then "MyAltstep2".
>
>But in my case, it never check my second default because my first default is
>matching with all the possible events.
>

Which is the intent. Defaults are executed in the order in which they are found
in the list of active defaults.

The order in which defaults are verified is dependent on the order in which you
have activated and deactivated your defaults.
Newly added defaults are always appended to the list of active defaults. When
you deactivate a default, it is simply removed from the active list of defaults.

Activating a previously deactivated default always causes it to be appended to
the end of the default list, irrespective of where it might have existed before.

The list of defaults is dynamically updated as you activate and deactivate
defaults.

code default list

---

---

activate (def1) def1 .
activate (def2) def1, def2 .
activate (def3) def1, def2, def3 .
deactivate( def1) def2, def3 .
activate (def1) def2, def3, def1 .

Which defaults you activate first will depend on the purpose of your default.
The behaviour you specify in one default, may very well cause any other defaults
coming after it to become
decode, as in your case. So you have judge carefully the order
in which you activate your defaults.



>altstep MyAltstep1() runs on MyComponentType {
>
> [] any port.receive { // Do something }
>
> [] any timer.timeout { // Do something }
>
>}

The above default is a catch all. Any default activated after
this is basically dead code. These defaults will never be
executed... Like I said, you need to be aware of what is
inside the various defaults. Sometimes, you get unexpected,
or unwanted behaviour.


You pose two questions which are unclear.

>How I should write my TTCN3 to describe such behavior.

Which behaviour do you wish to describe?

>I would like understand why the list is not check in the other way.

In which other way? Do you mean, first verify the last activated default? If
so, the standard does not speficy the order of evaluation to be as such. Then
again, you could modify the run time behaviour in your tool to implement such a
behaviour... However, I think it is better if you rethink the activation order
of your defaults to achieve the needed behaviour. Just switch the activation
order of MyAltstep1()
and MyAltstep2().

Hope this helps.

Ciao,


Claude.




--
Claude Desroches email:CDesroche@aol.com
Conformance Technologies Ltd. phone: +49 30 9606 7986
685 Cedar Point Road fax: +49 30 9606 7987
Penetanguishene Ontario, mobile 0174 701 6792
Canada

Solonplatz 3/2
13088 Berlin
Germany

Hi Jean-Marc,

I just read György's mail. Disregard my mail.

Sorry about that.

Cheers,

Claude.


--
Claude Desroches email:CDesroche@aol.com
Conformance Technologies Ltd. phone: +49 30 9606 7986
685 Cedar Point Road fax: +49 30 9606 7987
Penetanguishene Ontario, mobile 0174 701 6792
Canada