Please explain to me if I get right the meaning of these 3 state machines.
1, StateA Enter action is called (which is nothing at the moment) and then the timer is set up. When the timer triggers Acion1 is executed, then the StateA Exit action (also nothing) is executed, then the whole loop repeats. So StateA Enter action, setting up the timer, etc. This makes a kind of polling with Action1
2, StateB Enter action is called, timer set up and triggers after 10ms and executes Action2. The timer will be not renewed, so it is a kind of delayed action on the state
3, StateC Enter action, Timer is set up, when triggers then Action3 is called, then StateC Exit action and finally StateD Enter action is executed.
Please confirm or correct if it is correct.
1: Your description is correct, with one exception: the exit action is executed before Action1 is executed, at least, that is how I interpret the UML 2.5 spec. Section 14.2.3.4.6 says:
If the composite State has an exit Behavior defined, it is executed (...) before any effect Behavior of the outgoing external Transition.
I think you can safely assume that this is also true for non-composite states, but the UML 2.5 spec should be more explicit in this respect.
2: I don't think this is a proper UML notation, so I cannot confirm or deny your description.
3: This state machine diagram does not specify whether the initial state is StateC or StateD. If it is StateC, then your description is correct, with the exception that StateC's exit action is executed before Action3. To be unambiguous, the diagram should have an initial pseudostate (filled circle) with a transition from the initial pseudostate to StateC.
Generally states are drawn with rounded rect.
1) The notation along the transition is <trigger>/<effect>. The semantics of After(10) leaves some room for interpretation. So when the <trigger> fires it will perform <effect> and return to the same state.
2) I don't know this notation. You can specify entry/do/exit operations like this
3) Is like 1 but enters a new state.
Related
I am looking on a sequence diagram similar to the attached snapshot, object A instantiated 3 actions on same activation bar and received by object B with same activation bar as well.
So can I say the 3 functions are being executed one after one? Since they are solid arrowhead, I not sure my understanding is correct.
Please advise, thanks.
can I say the 3 functions are being executed one after one? Since they are solid arrowhead
The arrows indicate synchronous messages, so the second message cannot be send before the end of the execution of function A, the first cannot be sent before the end of the execution of function B and ExecutionSpecification on the lifeline of Object A cannot end before the end of the execution of function C.
object A instantiated 3 actions on same activation bar
All these three messages can start from the same ExecutionSpecification on the lifeline of Object A
3 actions ... received by object B with same activation bar
This is invalid, an ExecutionSpecification represents the execution of one and only action/behavior, so you need three ExecutionSpecification on the lifeline of the Object B, you cannot have only one.
A valid diagram can be :
or also showing the returns :
(on them function_c is not immediately called when function_b returns, the execution on object a does 'something' before introducing a delay, and also 'something' after)
from your remark :
From the requirements saying these 3 functions should be executed by objectB concurrently. That means i should use line arrow head instead of solid arrow head? And can i use the same ExecutionSpecification on objectB if functions are executed concurrently?
If you use asynch calls (open arrow head) there is no return message, so object a cannot know when the execution ends and it can sent immediately the next message.
The fact the 3 functions should be executed by object b concurrently is something else, asynch calls can be executed in sequence by the receiver, and the fact the receiver does concurrent executions does not imply asynch calls, but yes you can use asynch calls.
You still have to use 3 ExecutionSpecification on object b, to show concurrent execution just use a combined fragment "par".
So for instance :
I'm just reading into the theory of state machines. Please consider this:
event[guard]/action
State A -----------------------------> State B
Here's my question: If I define a transition between states A and B, with event, guard, and action, like in the above "picture"; and furthermore the event is received and the guard expression evaluates to true, then: will the action be performed while my object is in state A, or B?
In other words, do I need the action to be configured to be performable in state A, or B (let's assume I want to choose only one state in which the action can be performed)?
Google finds tell me that the action will be performed at the exact time of transitioning; but my brain has problems to accept it: imo my object needs to be in a certain state while the action is being performed (just because my object needs to always be in a certain state). And the performing of the action may take a while.
Related: What happens if an error occurs during the performing of the action. Will my object stay in state A, or will it transition to state B anyways (remember that the event was received and the guard expression evaluated to true)?
This is fairly easy to check with a custom state machine listener, in which you override the corresponding methods for entering/exiting state and transitions.
will the action be performed while my object is in state A, or B?
Your action (which is on transition) will be performed while you're in state A.
The order of what happens is the following:
Started transition
State Entered: A
SM changed states from:null to: A
Ended transition
---
Executing guard logic
Started transition
Executing normal action //action is executed before exiting State A
State exited: A
State Entered: B
SM changed states from:A to: B
Ended transition
What happens if an error occurs during the performing of the action.
Will my object stay in state A, or will it transition to state B
anyways
You will stay in State A.
As you can see in the above output, the exit of the state happens after the action is executed (successfully). If an exception occurs before that you will still be in state A.
The action will be performed while your object is in state A.
If an error happens during action your state machine will not go to target state B and remain in state A. Additionally you can also define custom Action() for error scenario when actual action() throws exception.
I've used PlusCal to model a trivial state machine that accepts strings matching the regular expression (X*)(Y).
(*--fair algorithm stateMachine
variables
state = "start";
begin
Loop:
while state /= "end" do
either
\* we got an X, keep going
state := "reading"
or
\* we got a Y, terminate
state := "end"
end either;
end while;
end algorithm;*)
Even though I've marked the algorithm fair, the following temporal condition fails because of stuttering ... the model checker allows for the case where the state machine absorbs an X and then simply stops at Loop without doing anything else ever again.
MachineTerminates == <>[](state = "end")
What does fairness actually mean in the context of a simple process like this one? Is there a way to tell the model checker that the state machine will never run out of inputs and thus will always terminate?
Okay, so this is very weird and should pass, but not for the the reason you'd think. To understand why, we first have to talk about the "usual" definition of fairness, then the technical one.
Weak fairness says that if an action is never disabled, it will eventually happen. What you probably expected is the following:
Loop could pick "end" but doesn't.
Loop could pick "end" but doesn't. This happens some arbitrary number of times.
Since Loop is fair*, it is forced to pick "end".
We're done.
But that's not the case. Fairness, in pluscal, is at the label level. It doesn't say anything about what happens in the label, just that label itself must happen. So this is a perfectly valid behavior:
Because loop is never disabled, it eventually happens. It picks "reading".
Because loop is never disabled, it eventually happens. It picks "reading".
Because loop is never disabled, it eventually happens. It picks "reading".
This keeps going forever.
This corresponds to you inputting a string of infinite length, consisting only of X's. If you only want finite strings, you have to explicitly express that, either as part of the spec or as one of the preconditions to your desired temporal property. For example, you could make your temporal property state = "end" ~> Termination, you could model the input string, you could add a count for "how many x's before the y", etc. This gets out of what's actually wrong and into what's good spec design, though.
That's the normal case. But this is a very, very specific exception to the rule. That's because of how "fairness is defined". Formally, WF_vars(A) == <>[](Enabled <<A>>_v) => []<><<A>>_v. We usually translate that as
If the system is always able to do A, then it will keep on doing A.
That's the interpretation I was using up until now. But it is wrong in one very big way. <<A>>_vars == A /\ (vars' /= vars), or "A happens and vars changes. So our definition actually is
If the system is always able to do A in a way that changes its state, then it will keep on doing A in a way that changes its state.
Once you have pc = "Loop" /\ state = "reading", doing state := "reading" does not change the state of the system, so it doesn't count as <<Next>>_vars. So <<Next>>_vars didn't actually happen, but by weak fairness it must eventually happen. The only way for <<Next>>_vars to happen is if the loop sets state := "reading, which allows the while loop to terminate.
This is a pretty unstable situation. Any slight change we make to the spec is likely to push us back into more familiar territory. For example, the following spec will not terminate, as expected:
variables
state = "start";
foo = TRUE;
begin
Loop:
while state /= "end" do
foo := ~foo;
either
\* we got an X, keep going
state := "reading"
or
\* we got a Y, terminate
state := "end"
end either;
end while;
end algorithm;*)
Even though foo doesn't affect the rest of the code, it allows us to have vars' /= vars without having to update state. Similarly, replacing WF_vars(Next) with WF_pc(Next) makes the spec fail, as we can reach a state where <<Next>>_pc is disabled (aka any state where state = "reading").
*Loop isn't fair, the total algorithm is. This can make a big difference in some cases, which is why we spec. But it's easier in this case to talk about Loop, as it's the only action.
In UML state machines, what exactly happens to the history of a composite state if a final state of a substate is entered?
Consider the state machine shown below. After the trigger sequence T1-T2-T3-T4 it will end up in the final state. By entering the final state the history of the region of State21 gets cleared, and since the region also gets completed by this, the completion transition to State1 will be executed. Now, when trigger T5 gets enabled, the state machine enters the deep history state. I suppose that in this situation the deep history state represents State21, which means the state machine enters State21 and then executes the transition from the initial pseudostate of State21 to State211. Is this correct?
I prefer the behavior described above, but I can see an alternative in which the history of State2 also gets cleared when the final state in State21 is entered. In that case the state machine executes the transition from the the initial pseudostate of State2 to to State22. So what do you think?
From my understanding of deepHistory description
This type of Pseudostate is a kind of variable that represents the most recent active state configuration of its owning Region. As explained above, a Transition terminating on this Pseudostate implies restoring the Region to that same state configuration, but with all the semantics of entering a State (see the Subclause describing State entry).
Your first behavior description seems to be the good one. By trigerring T1, T2, T3, T4, and T5 transitionns you are back to State21 entry i.e. State211.
I read this diagram in the following way:
While in State1 you can enter into State2 by calling T1 (which is a fresh sequence) or via T2 (a retry of the previous sequence).
When the application / system is in State1 it appears to have logic in it that allows for retrying a previous State2 sequence in certain situations. As such deep history keeps those process variables around in the parent state until State1 can make a decision on which way it wants to proceed.
However ambiguities exist in the example state machine model:
The transition back to State1 is not named/numbered, and
An intermediate partially complete state, that requires deep history, has not been defined. The model needs an exit state / criteria defined as a sub-state within State21 that serves as the source for this unnamed transition back to State1.
The current flow within State21 only has one end state and therefore runs to completion every time. Its only when you need to re-enter a state at a given sub-state location that deep history makes sense.
I thought I could differentiate between event and guard. But I came across an event being similar to guard:
counter > 4 [pin is high] / switch on
^^^^^^^^^^^
event
where I viewed the variable counter changes from some value smaller than 4 to that greater than 4 as event. Does that mean event can also be a condition like guard?
An event is the thing that triggers the transition. In your case counter > 4 is a change event, meaning "the counter value has changed and its value is now greater than 4".
The code between the brackets is the guard. In your case pin is high, meaning "the transition is only enabled if the pin is high".
switch on is the behavior that is executed when the transition is executed.
Footnote: In your example the event is indeed very similar to the guard.
In C it could look like that:
/**
* this interrupt is triggered when the
* counter exceeds the threshold (4)
*/
static void counter_isr(void)
{
if (pin_is_high(PIN))
switch_on();
}
From the UML 2.5 specification:
14.2.3.8 Transitions
...
A Transition may own a set of Triggers, each of which specifies an Event
whose occurrence, when dispatched, may trigger traversal of the
Transition. A Transition trigger is said to be enabled if the dispatched
Event occurrence matches its Event type.
14.2.4.9 Transition ...
The default textual notation for a Transition is defined by
the following BNF expression:
[<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]
In other words: trigger [guard] / behavior