From: Tim Milward (tim.milward_at_[hidden])
Date: 2006-05-02 06:02:18
>>or are there any plans to extend it, to model the more
>>useful local transitions from the 2.0 spec?
>
>
> There weren't any plans until I read your post :-). It seems that any
> local transition can always be converted to an external transition or an
> in-state reaction. The only benefit I see is improved performance (one
> state exit & entry less) under IME rare circumstances. So, the question
> is: How often do you use such transitions?
Unfortunately I have no practical experience of using state charts yet,
(I have done a lot of research/reading/designing), so can't answer your
question. I want to use simple HSMs to control the threads in a GUI
application (a more complex version of the Dining Philosophers Problem
essentially).
In my designs I very often use a composite state as the source for a
transition, simply to avoid repetition (- avoid lots of transition lines
from each sub-state on my diagrams). However the behavior I want is
exactly the same as if I'd sourced the transition explicitly from each
sub state. That is, I explicitly don't want the entry and exit actions
of the composite to be called. That is perhaps why UML added local
transitions - not for performance reasons, but for behavioral
flexibility and expressivity. If you only model external transitions and
want to use entry/exit actions you've essentially lost much the power of
HSM's to represent FSM's more efficiently. This is I think a killer
argument.
>
>>Tests with deep history produce a static assertion if you attempt to
>>transition to history of a containing state. UML 2.0 explicitly
>>permits this.
>
>
> I disallowed such transitions because they don't seem to make sense and
> there was no indication that they are allowed under UML 1.5. IIUC, such
> a transition would simply leave & reenter the current state, right? If
> so, what good is history for when the same effect can be achieved by
> simply giving the state a normal transition to itself?
Giving a state a normal transition to itself would invoke it's
entry/exit actions, or if modeled as an internal transition (in-state
reaction) do none. Transitioning to deep history (of a containing state)
should (in my opinion) invoke the entry/exit actions all the way back up
to (but not including) the state containing the history. So as you can
see I was interested in notationally efficient ways to invoke chains of
entry/exit actions back up the hierarchy. The other thing to note is
that this sort of transition to history technically doesn't require any
extra storage of the deep history since it is just the current state
(the composite state might not need to be parameterised with
has_deep_history).
> Thanks for the feedback!
Hope that all makes sense. If I do use HSMs for my app, I think I'll use
boost/statechart, and for now avoid entry/exit actions. Having reviewed
several implementations, every time I think about writing my own HS
library I realise how many options there are. Also you've already done
all the queuing and locking for me.
Yours,
Tim Milward