Re: When do statemachine changes become effective



Re: When do statemachine changes become effective

From: Jörg Pleumann ^lt;joerg@pleumann.de>
Date: Thu 12 May 2005 - 09:51:02 BST
Message-ID: <428318F6.3040706@pleumann.de>
Hello,

thanks for the responses so far.

I understand that Les and Bernd think the answer depends on the action 
language used for the transitions. Well, in my case the action language 
is Java, but that is just for pragmatic reasons. It could be any 
language that allows to evaluate mathematical expressions and assign 
values to variables. The ";" means sequential composition here, which 
seems to imply that later parts of the action expression see changes 
resulting from earlier parts.

Yet, somehow I think that a property as fundamental as the question when 
changes become effective should be part of the core semantics of UML 
statemachines. It should not be left open to the action language.

Let me refine my examples a bit:

      evt/x=y         y=x
    -----------> O ---------->

I have split the compound action expression into two simple ones and put 
them on transition segments joined by a junction point. And, to put in 
yet another example, here's a situation where the transitions are 
supposed to fire in the same step (being in concurrent regions of a 
composite state):

      evt/x=y
    ----------->
- - - - - - - - -
      evt/y=x
    ----------->

In both cases, for a classical Harel statechart, the variables would be 
swapped when the transition(s) is/are executed, because any changes 
caused by the actions become effective in the next step only. Harel's 
old publications are very clear about this.

What's the situation for a UML statemachine, I wonder? As mentioned in 
the original post, my intuition says that for the first case both 
variables assume the former value of y. For the second case, I'd say the 
result is undefined, since you can't really foretell which transition 
fires first. The spec (I'm referring to 1.5 here, no new info in 2.0) 
gives some hints that seem to support this assumption:

(a) 2-160: "Actions are executed in sequence following their linear 
order along the segments of the transition: The closer the action to the 
source state, the earlier it is executed."

(b) 2-161: "Which of the enabled transitions actually fire is determined 
by the transition selection algorithm described below. The order in 
which selected transitions fire is not defined."

Yet, the spec doesn't make clear when changes become effective. (a) 
seems to be a hint that changes can be sensed in the same step. 
Otherwise it wouldn't make sense to have an ordering of actions at all. 
(b) seems to be a hint that multiple enabled (compound) transitions do 
not necessarily fire simultaneously. The existance of the dynamic choice 
point is another hint, too, because with changes being delayed to the 
next step, there'd be no need for a dynamic choice at all. All firing 
transitions could be determined once the input event has been looked at.

So, it seems that the spec implies that changes are visible immediately 
and can influence later actions of the same step. That's also how I 
always understood understand UML statemachines. But the spec doesn't say 
so explicitly. And since this is a rather big difference to Harel 
statecharts, I would have expected it to be mentioned somewhere (e.g. in 
the section "Comparison to classical statecharts" of the 1.5 spec).

Ok. This got rather lengthy, so thanks already for reading. Now, if 
somebody could shed some light on this topic, I'd be very grateful.

Regards, Jörg

----------------------------------------------------------------------
Dipl.-Inform. Joerg Pleumann      Fon : (+49) 0231/755-4712
Universitaet Dortmund             Fax : (+49) 0231/755-2061
Software-Technologie              Mail: joerg.pleumann@uni-dortmund.de
Baroper Strasse 301               Web : ls10-www.cs.uni-dortmund.de
D-44221 Dortmund                  ICQ : 137170325
----------------------------------------------------------------------
Received on Thu May 12 09:51:21 2005