Re: [Boost-users] [statechart ] UML2.0 local transitions and history

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