Re: When do statemachine changes become effective



Re: When do statemachine changes become effective

From: Bernd Westphal ^lt;Bernd.Westphal@Informatik.Uni-Oldenburg.DE>
Date: Thu 12 May 2005 - 10:50:25 BST
Message-ID: <20050512095025.GA7291@kalk.Informatik.Uni-Oldenburg.DE>
Moin.

I think many people agree to

On Thu, May 12, 2005 at 10:51:02AM +0200, Jörg Pleumann wrote:
> [...]
> 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.
> [...]
>
but -- unbelievable but true -- up to 1.5.AS the UML standard did care _at_
_all_.  It considered, to my understanding, a transition annotation as

  <event> [ <condition> ] / <action>

where <condition> and <action> are uninterpreted "blobs".  "strings" if you
want to (in the corresponding XMI they are strings).

You (or the modeling tool or whoever) decides how these "blobs" are
interpreted.  Only with the classes from the Action Semantics meta-model can
can further _structure_ this "blob" using UML, not an own decision.

Could be that you want to read that document.  There are basically entities
for assignment, loops, composition etc. that have in- and out-"ports" and
are somehow plugged together.  The expression

  x := y ; y := x + 1

should map to a parse tree in these terms.  And then the Action Semantics
document (informally, prosaically) explains what happens when (possibly
concurrently).


> [...]
> (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."
> 
This refers to a sequence of transitions with pseudo-states involved. 

I would read this as "if you know, what the semantics of a single transition
'blob' is, then hereby we (the UML standard consortium) require that the
effects of these single transitions occur one after another".

> (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. 
>
(a) is about the ordering of these 'blobs'.  There may be an action language
where the effect is like Harel statecharts, but if the action language is
like Java, then the outcome is different from Harel Statecharts by (a).

> [...]
> 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).
> 
I would not draw this conclusion.  IMHO the difference is the following:
Harel-Statecharts are a complete programming language, with data-types,
expression and action language, concrete syntax and formal semantics.

UML-Statecharts are only a framework to plug an action language into.  Given
an Action Language we can determine the meaning of a statechart using the
guidelines the standard provides (your (a) and (b) above); but the standard
(before 1.5.AS) did not restrict the choice of Action Language, in particular
not the choice of its semantics.  You could right away use the Harel-State-
chart action language.  Then ';' is something different from sequential
composition in the classical sense.
 
If a vendor of a UML modeling tool provides Java code-generation and Java
as transition annotation language, then he decides what to do with (b).
The generated code may sequentialise the concurrent regions and evaluate
the second transition's condition on the effect of the first transition. 
Or it may buffer the initial state and have all transitions start with
these values.  A matter of choice.

HTH,
  Bernd

------------------------------------------------------------------------------
Bernd Westphal                    <bernd.westphal@informatik.uni-oldenburg.de>
Abteilung Sicherheitskritische Eingebettete Systeme, Department für Informatik
Carl von Ossietzky Universität Oldenburg,           D-26111 Oldenburg, Germany
http://ses.informatik.uni-oldenburg.de       tel: +49 441 9722-506 (fax: -502)
Received on Thu May 12 10:50:29 2005