Hi,
I think you can do it even three and more times.
> var MyAnswer Answer1 := MyAnswer.create;
> Answer1.start(YesItIsAllowed);
> Answer1.start(NoItIsNotAllowed);
> Answer1.start(IDoNotKnow);
> Answer1.start(ItIsBadProgrammingStyle);
> Answer1.start(ItIsBadPTCDesign);
// etc.
Well, I am joking :-)
This example at first look is as strange as e.g. 'return true and false'
which
looks funny but is correct.
I gathered some loose notes, maybe useful:
1) It is not described in the spec if already started component can be
started again with different behaviour. Should be described as in case of
'start' operation for timers.
2) An example looks 'a little bit useful' if between 'start' operations some
action is placed. During this time ptc1 may do 'something useful' before
test
system will replace behaviour by new one. But still it is an example of bad
design of test system.
> var MyPTCType ptc1 := MyPTCType.create;
> ptc1.start(FirstBehaviour);
// some action
> ptc1.start(SecondBehaviour);
3) Usually change of PTC behaviour should be done in PTC under certain
conditions (message, event, timeout, counter, etc.) and not should be forced
by test system.
PTC behaviour should be foreeseen as an independent logical task. For new
task test
system should create new PTC instead of overwriting the old PTC with new
behaviour.
4) Looking at the 'stop' operation the only way to change the once bounded
behaviour
for already running PTC is to force the change without stopping it.
Stopping of component in TTCN-3 means not only stopping but also discarding
PTC resources. It is next example of implicit system behaviour.
Although language looks to be a little bit object oriented with construction
similar to constructor use
> var MyPTCType ptc1 := MyPTCType.create;
but there is no separate destructor and it is realized by 'stop' operation.
That why it is impossible to make a proper code in a form of:
> var MyPTCType ptc1 := MyPTCType.create;
> ptc1.start(FirstBehaviour);
> ptc1.stop;
> ptc1.start(SecondBehaviour);
because after component stopping the 'ptc1' reference is invalidated.
5) Can test system change the behaviour of PTC in a painless way?
Starting again of different component behaviour means leaving current loop
of input events in an alt or altstep behaviour in component/component
default or breaking loop of sending events. Port queues may remain intact.
It may be possible although not elegant.
My conclusion:
There is lack in the specification for this case.
I think this was not included because of PTC design rules, which are quite
clear.
PTCs are components created and started by MTC but with behaviour
independent from MTC after the start operation. The PTC acts as an
independent communication and event driven unit, where events are external
or internal. The only actions allowed from MTC is to control PTC via
communication ports or stop PTC completely.
Forcing change of PTC behaviour in such a brutal way is against all design
rules for test systems.
BR,
Mariusz Kupiec
Original Message
From: "??隆盲??隆楼" <
This email address is being protected from spambots. You need JavaScript enabled to view it.>
To: <
This email address is being protected from spambots. You need JavaScript enabled to view it.>
Sent: Thursday, December 26, 2002 2:37 AM
Subject: May I start a component two times?
> hi, all
>
> May I start a component two times continuously after i create it?
> e.g
> MyPTCType ptc1 := MyPTCType.create;
> ptc1.start(FirstBehaviour);
> ptc1.start(SecondBehaviour);
>
> Thanks in advance.
>
>
This email address is being protected from spambots. You need JavaScript enabled to view it.
>
>
> Oficjalny serwis Polskiej Reprezentacji Skoczkow Narciarskich!
> >>>
link.interia.pl/f16b1
>
>
>
>
Oficjalny serwis Polskiej Reprezentacji Skoczkow Narciarskich!
>>>
link.interia.pl/f16b1 
