"Andreas Huber" <ah2003@gmx.net> writes:
Assumptions: A1. When a state machine object is destructed, the modeled state machine must also be terminated (i.e. the destructor of the state machine unconditionally terminates the state machine before returning to the client).
I've got a problem with that assumption. It seems to be an association made because of a conflation of C++'s notions of termination with the UML standard's use of the word "terminate" to denote something unrelated, at least as you described it in snipped text.
Actually, the UML standard in one place (2.12.4.4) hints in this direction but it is far from clear whether this assumption is covered by the UML standard (and could thus be put in the hard facts section).
A2. If an exit action fails, the state associated with the exit action has not been left.
I'm fine with that assumption. In fact, that seems provable. <snip>
I realize that the above reasoning is far from water-tight, as it is based qon two assumptions. However, I believe that most people proficient in the FSM domain will agree that it is safe to assume A1 & A2.
I can't speak for them, but as I said, A1 seems far from obvious to me.
Moreover, one could also question whether the UML standard should have any bearing for an FSM library that implements behavior that is not covered in the standard (i.e. exit action failures). I see failing exit actions as an addition or enhancement to the behavior defined in the standard. If such an enhancement breaks the behavior defined in the standard, I think the enhancement should be rejected.
Another thing I should mention: the finite state machine abstraction was around long before UML and will stay around long after UML has crumbled to dust because of its overbearing weight and its OO orthodoxy <wink>. Actually I think that UML _state charts_ seem like a pretty good representation, but I'm not sure that I would want to read the UML spec like a bible when approaching the project of building a C++ state machine framework.
The above is the best reasoning I can currently give to show that failing exit actions do not make any sense. For me, this is more than enough to not ever consider them again (at least for an FSM library implemented in C++).
Well, I guess we're done then.
I will answer questions arising from this post and I am interested in feedback whether this convinces people but I will not try to reason any further as I have run out of arguments and I think I have already invested too much time into this.
I know how you feel ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com