Given this HSM example model - http://www.embedded.com/design/system-integration/4008251/8/A-crash-course-in-UML-state-machines-Part-2 - I'm wondering what should be the RIGHT moment of executing transition action. Let's say that this machine is in its initial state S211 and event G is dispatched (S21 -> S1) - let's assume that there's some action for this event. Should the sequence be like that:
exit to the least common ancestor (S) - transition action - entry to destination state (S1) - init actions of target...
or maybe like this:
exit to the source state of transition (S21) - transition action - exit to the least common ancestor (S) - entry to destination state (S1) - init action of target
?
In short - is the transition action associated with the "source of transition" or the "least common ancestor"?
The example with description at wikipedia is too trivial to give these details... The UML specs seem to suggest the LCA answer to be the right one, but I'm not sure.
Thx in advance (;
Automata theory suggests that the action does not occur in either the source or the target. But neither does automata theory generally consider hierarchical states. So yes, the LCA is as good a theoretical assumption as any for a transition action.
However, the state-machine code devised by Miro Samek (QHSM) actually performs the transition action within the source state. Please understand, this is not either a problem or a flaw.
As any particular implementation is concerned, all that matters is that the transition action occurs in a consistent way. That is the case with Miro's code.
If for whatever reason you really need the transition action to occur in the LCA or target state, you could use "extended state" to achieve the result. But in practice, it really isn't ever necessary.
Related
I have a system with 3 states. I wanted to handle failures. That is, when the system reboots, it doesn't know the state it's in. Is the following state diagram correct?
This not a valid UML State Machine Diagram for several reasons:
The start node is the wrong symbol. It should be a bullet.
The arrows fork. Each arrow (transition) should begin and end on a node.
The Y and N don't have square brackets.
Regarding the semantics:
The decisions don't have meaningful text (should refer to previously stored state). They may be combined to one decision "storedState = " which has four outgoing transitions guarded as [S1], [S2], [S3] and [empty].
The actions to store the state in persistent storage, in order to be restored in case of crash, are not present.
In case all decisions yield N, the object is destroyed immediately, instead of ending in some default state.
I don't understand the intention of A1, A2 and A3.
Perhaps it would be good to first show the diagram without reboot logic and then tell us what you try to add to that diagram to handle the failures.
In UML 2.5.1, the initial pseudostate of a state machine is defined as follows:
An initial Pseudostate represents a starting point for a Region; that
is, it is the point from which execution of its contained behavior
commences when the Region is entered via default activation. It is the
source for at most one Transition, which may have an associated effect
Behavior, but not an associated trigger or guard. There can be at
most one initial Vertex in a Region.
In other words, a UML state machine should almost always contain exactly one initial pseudostate, which should have exactly one outgoing transition.
However, can an initial pseudostate have incoming transitions as well? For example:
I cannot find anything forbidding it in the UML specification, yet I cannot find any example online where this case happen, therefore I was wondering whether or not I overlooked anything.
EDIT: To go into more detail, if we look into the OCL constraints stated in the specification, we can only find the following one that affects outgoing transitions (section 14.5.6.7):
inv: (kind = PseudostateKind::initial) implies (outgoing->size() <= 1)
but I cannot find any constraint regarding incoming transitions
EDIT2: I have just realized that my model is wrong! Considering this sentence of the specification (cited above): "It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard."
Therefore the transition between init and s1 should actually have zero triggers, instead of having e1 as a trigger.
Note that while this does not invalidate the initial question.
I see nothing in the UML 2.5.1 Specification that prohibits a transition whose target is the initial pseudostate.
Such a transition would be meaningless at best and confusing at worst, which is likely why no examples are found.
Edit: see the comments!
On p. 423 UML 2.5:
15.7.18 InitialNode [Class]
15.7.18.4 Constraints
• no_incoming_edges
An InitialNode has no incoming ActivityEdges.
inv: incoming->isEmpty()
N.B. If you intend to have a self-transition for e1 then why not just using that? The Initial can anyway have only on singular outgoing edge, namely to the first state (here s1).
No this is not allowed. And why would one Do that? As you already stated in the cited text,it can only have one outgoing edge without any guard. So what is the added value, as you cannot reuse anything.
I think the text is pretty clear as-is: "[An initial Pseudostate] is the point from which execution of its contained behavior commences when the Region is entered via default activation." If you connect a transition back around to the initial psuedostate, the initial psuedostate is no longer "the point from which execution of its contained behavior commences," it is something else, and is therefore undefined.
We are learning in school that behavioral State diagram's transition has syntax:
list of events [guard condition] / list of actions
But I couldn't find any example on Internet where is used transition with multiple events. Is it really possible? If yes, how does it behave? Does it mean that transaction is realized when one of this events occurs (and of course condition is fulfilled)?
Yes, a transition can be triggered by one of many events in a list. You would use such a construct to avoid multiple lines between states, making a tidier diagram.
Here is what the 2.5 spec says:
14.2.3.9.2 Enabled Transitions
A Transition is enabled if and only if:
[ . . . ]
At least one of the triggers of the Transition has an Event that is matched by the Event type of the dispatched Event occurrence.
These logically OR'ed transitions are specified textually as a comma-separated list on the transition, as specified in §14.2.4.9:
[<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]
Unfortunately the UML spec is not specific in that respect (I thought, but Jim has the right answer). Anyway:
14.2.4.9 Transition
The default textual notation for a Transition is defined by the following BNF expression:
[<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]
Where is the standard notation for Triggers (see sub clause 13.3.4), is a Boolean expression for a guard, and the optional is an expression specifying the effect Behavior written in some vendor- specific or standard textual surface language (see sub clause 16.1). The trigger may be any of the standard trigger types. SignalEvent triggers and CallEvent triggers are not distinguishable by syntax and must be discriminated by their declaration elsewhere.
There are other places in the specs where this paragraph appears in similar way, but without explaining how multiple triggers will be treated. I assume that it's an OR-condition. But that's only an assumption. Alas, since you have not seen examples (me neither) it is probably an unknown fact. Just don't use it - that's indeed possible ;-) And if you happen to find an example, just ask the author what he meant. UML is about talking to each other.
I'm writing a simple finite state machine and realized that there are situations where an event can take a state to more than one possible results. Basically, from state A, if Event E happens, the state could be either C or D.
I'm currently using the Javascript Finite State Machine code written here: https://github.com/jakesgordon/javascript-state-machine
From the documentation I don't see an obvious way that makes this possible. More so, I feel like maybe this is actually a flow in my original design.
Essentially, in a Finite State Machine, should there be a situation where a transition happens, and based on some logic result in one of multiple states (1 to many), or should it be that we check the logic to see which transition needs to takes place (1 to 1)?
Congratulations, you've just discovered non-deterministic finite state machines! The ideas are similar to that of a deterministic state machine, except that there may be multiple ways to transition from a state given the same input symbol. How this is actually done is unspecified (randomness, user input, branch out and run them all at once, etc.).
I'm trying to collect informations to be able to program a correct transition selection algorithm for an UML State Machine.
The UML Superstructure Specification (15.3.12 StateMachine) states
Only transitions that occur in mutually orthogonal regions may be fired simultaneously.
Does "mutually orthogonal" imply that the regions are on the same nesting level?
For each state at a given level, all originating transitions are evaluated to determine if they are enabled.
This sounds to me like they have to be on the same nesting level. Right? Because if a transition is found on a certain nesting level, the search ends...
The seciton "Transition selection algorithm" once again is not totally clear to me:
The only non-trivial issue is resolving transition conflicts across orthogonal states on all levels. This is resolved by terminating the search in each orthogonal
state once a transition inside any one of its components is fired.
To make this a little more haptic I created 2 models:
Model 1
Model 2
Active state configuration:
State1, State3, State4, State7
Example 1a
In case of an event Event1 which transitions fire?
a. Does only the one from State7 to State 5 fire?
b. Or also then one from State3 to State8?
Both variations would yield in a legal active state configuration.
But my understanding is, that a is correct
Example 1b
Same for model 2.
Example 2a
In case of an event Event2 which transitions fire?
a. Does only the one from State7 to State 5 fire?
b. Or also then one from State3 to State2?
In this case I would say that b would lead to an illegal active state configuration.
Does this mean the model is ill-formed or would only one of the transitions be fired?
Example 2b
Same for model 2. Any difference?
I'd interpret mutually orthogonal to mean that the side effects of the transitions have no impact on each other.
So in either of your diagrams, the transitions triggered by Event1 can be deemed to be mutually orthogonal as the transitions are both contained within [A] and [B] and may be fired simultaneously. Event2 cannot as the transition from within [A] leaves A and State1 (and therefore also [B]).