[boost] [Boost.Msm] On the necessity of state-boundary-crossing transitions

Subject: [boost] [Boost.Msm] On the necessity of state-boundary-crossing transitions
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2008-10-22 14:41:12

Unfortunately, the original thread on this subject has led to so many side
arguments that IMO the main point hasn't gotten the attention it deserves.
I'll therefore try to summarize the main point here, so that hopefully a
more focused discussion results.

State machine behavioral standards like e.g. Harel & UML allow that
transitions can cross state boundaries. One example for when this is
beneficial is given in Fig. 8 of Harel's paper, which can be found here:

<http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Statecharts.pdf>

In this example, the main reason for the existence of the "alarms-beep"
composite state is to avoid duplicating the two transitions triggered by the
"any button pressed" and "30 sec in alarms-beep" events.

The design of Boost.Msm and the arguments presented in the thread titled
"New library in Vault: Msm (Meta State Machine)" seem to amount to the
following claim:

It is *invariably* bad practice to let transitions cross state boundaries.

It follows that a state machine like the one shown in Fig. 8 should *always*
be redesigned so that the transitions no longer need to cross state
boundaries [1]. For Fig. 8, I claim that any such redesign will lead to
information duplication in the diagram and the code implementing it.
Moreover, it's probably safe to say that the ultimate bad practice in
software engineering is expressing the same piece of information more often
in the code than minimally required by the language [2]. Therefore, if
following a best practice leads to code duplication then common sense would
mandate to choose the lesser of the two evils. So, boundary-crossing
transitions cannot always be avoided.

Therefore, the challenge is to show that my claim for Fig. 8 is wrong by
coming up with an alternative state machine design with the same observable
behavior where transitions no longer cross state boundaries without
duplicating anything (transitions, events, states) [3]. Note that the
leaf-state in which the machine currently resides is part of the observable
behavior. So any redesign must have at least the states "alarm 1 beeps",
"alarm 2 beeps", "both beep" and "displays". Anything else can be changed to
suit.

Note that Fig. 8 shows just one widely used pattern that employs
boundary-crossing transitions. Other patterns employ them as well. So, even
if Fig. 8 can be redesigned without boundary-crossing transitions and
without duplicating any information then this is just one data point.
Suitable redesigns for the other patterns would have to be shown as well.

[1] UML's entry & exit points are "just" encapsulation tools that allow the
designer of a composite state to only expose the parts of the inner workings
that must be visible from the outside world. So, a transition destined to an
entry point does in fact still cross the state boundary. The same goes for a
transition originating at an exit point.

[2] Of course, all rules come with exceptions: In some cases code
duplication can increase performance, which in turn might help to meet
system requirements that otherwise couldn't be met. Under such circumstances
of course the lesser evil is the code duplication.

[3] The obvious solution of moving the "displays" state into the
"alarms-beep" state just replaces the crossings of the transitions triggered
by the "T hits ..." events with the crossings of the transitions triggered
by the "any button pressed" and the "30 sec in alarms-beep" events.
Depending on how the latter transitions are drawn, the crossings might not
be visible graphically but on the conceptual level they still exist. This is
why such transitions are often drawn as the one triggered by y shown in
Figure 2 here: <http://www.codeproject.com/KB/cpp/Statechart.aspx>

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap from
the address shown in the header.