| Subject: |
|
Re: event handling question |
| Name: |
|
Miro Samek |
| Date Posted: |
|
Jul 14, 08 - 9:29 AM |
| Email: |
|
miro@quantum-leaps.com |
| Website: |
|
http://www.quantum-leaps.com |
| Message: |
|
The biggest problem with the solution described by Tad is that it is difficult to represent it in a UML-compliant state diagram.
But, UML allows one particular situation in which processing can occur at several levels (at the level of a substate and also at the level of superstates) and this is when evaluating guards. If a guard of a transition (internal or regular) evaluates to FALSE, the event is supposed to be propagated to the superstate(s). In QEP, this is the only situation when you are allowed to use the "break" statement legitimately (please recall the HSM coding rules of QEP).
I believe that this offers an opportunity to depict the behavior graphically in a UML-compliant state diagram. You can depict the action Processing_Specific_To_State_A() as a guard (returning always FALSE, perhaps). This guard will have side effects, obviously, which is strongly discouraged by UML. But at least you'd be able to show [Processing_Specific_To_State_A()] in substate A, [Processing_Specific_To_State_B()] in substate B, and so on.
Finally, I'd like to note that the new way of coding transitions in QEP v4 is significantly safer, with respect to the issue discussed here, than in the earlier versions of QEP. The biggest problem with processing an event at several levels of nesting is the potential of conflicting transitions. Suppose, for example, that substate A takes a transition to state X, while the superstate of A takes a different transition to state Y. As it turns out, it is impossible to code this in QEP v4, because a transition is now coded as "return Q_TRAN(...)". This "return" necessarily stops the propagation of an event. Before, a transition was coded simply as "Q_TRAN(...)", and so it was possible to use Q_TRAN() at several levels.
Miro |
|
Replies:
|
|
|
|
|
Reply
Forum
bravenet.com