Base on Wikipedia, I can have a hierarchical state decomposition, where I have multiple orthogonal regions, which can change state independently.
The diagram shows how the orthogonal regions are entered. I assume that the entry happens in parallel in all regions. What I want to know is, how do you express the exit? If each region has an exit, does the global parent state exits when the first child region exit, or when they have all exited? I want to express that the exit happens when they have all exited. And how do you express that the global parent state transitions to the next global state because all children regions have exited? Is that always implicit?
My concrete problem is that my FSM starts in the Initializing global state. It sends multiple queries to multiple external systems asynchronously in parallel. Only once it has received the answer to each query, it can then proceed. So I model each asynchronous parallel query as an orthogonal region inside the global Initializing state. Each child region can change state independently. When all child regions have reached an end-state, I can move on.
The FSM will be implemented in an Actor framework, where asynchronous messages (events) are the only way to communicate.
Ideally, I'd like the answer to point to an example image, as such things are difficult to express in words.
A completion transition from the orthogonal state will do the trick, since it will be taken when all of the orthogonal regions have finished.
When an composite state (state with inner states and/or orthogonal regions) is entered, each region starts at its initial state, to a different state in each region using fork pseudonodes, or to the last state of each region if the state is entered through a history pseudostate. Exiting the composite state can be done through a transition that starts at one of the inner states, which exists all of the orthogonal regions from their current state. If you want to exit when a the machine has come to a set of states in different regions, you can also use join pseudostates.
As you can see, the possibilities are almost endless. I can't add an image yet, but I'll do it later when I have a good UML editor at hand.
An now the example. Suppose you have the following state machine:
If both parallel regions finish (arrive at a final node), then the completion transition will take the machine from S1 to S5. If the
If the machine is currently at S3 and receives e1, it will exit S1 and go to S6.
If the machine is in S7 and S8 and they both finish, it will go to the join and then to S6.
This is the way I know state machines work.
Related
I have a state machine diagram for an application that has a UI and a thread that runs parallel. I model this using a state with 2 parallel regions. Now I want when that thread gives some message, for example an error, that the state of the UI changes, for example to an error screen state.
I was wondering what the correct method to do this is, as I was not able to find any example of this situation online.
The options that I thought of were creating a transition from every state to this error state when the error state is called, which in a big diagram would mean a lot of transitions. Or by just creating a transition from the thread to the error state (As shown in the image), which could possible be unclear.
Example of second option
You don't need a transition from every state. Just use a transition from the State State to the Error window state. It will then fire no matter what states are currently active.
Such a transition will also leave the Some process state. Since you didn't define initial states in the orthogonal regions, the right region of the state machine will then be in an undefined state. Some people allow this to happen, but for me it is not good practice. So, I suggest to add initial states to both regions. Then it is clear, which sub state will become active, when the State state is entered for any reason. The fork would also not be necessary then.
How you have done it in your example would also be Ok. However, since the Some process state is left by this transition, this region is now in an undefined state. Again, the solution to this is to have an initial state here. I would only use such a transition between regions, when it contains more than one state and the On error event shall not trigger a transition in all of the states.
If the Some process state is only there to allow for concurrent execution, there is an easier way to achieve this: The State state can have a do behavior, that is running while the sub states are active. Orthogonal regions should be used wisely, since they add a lot complexity.
I am not 100% sure what 'do' does in an UML statechart diagram.
Is my thinking correct:
If a transition happens, 'entry' will be executed first and then 'do' will be executed.
And if we are leaving the state only 'exit' will be executed.
Does this logic apply to reflexive transitions as well?
And what if a trigger happens, that does not set off a transition? Does this only execute 'do'?
The UML Specification tells us:
14.2.3.4.3 State entry, exit, and doActivity Behaviors
. . .
A State may also have an associated doActivity Behavior. This Behavior commences execution when the State is entered (but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be associated with the State, until:
it completes (in which case a completion event is generated) or
the State is exited, in which case execution of the doActivity Behavior is aborted.
The execution of a doActivity Behavior of a State is not affected by the firing of an internal transition of that State.
You :
Does this logic apply to reflexive transitions as well?
As said by the last sentence above that depends if the reflexive transition is internal or external.
To add to bruno's answer something more specific.
As stated in the UML specification (and quoted by bruno in his answer) the do activity is performed while the system is in a certain state (after entry activities were completed). It is performed during the whole time the system is in the state. The do activities cease to be performed only in two situations:
The transition taking you out of the State is triggered; in such case, the do activities are interrupted, exit activities if any, are performed and then the transition occurs. The transition can be reflexive (i.e. once completed the system returns to the same state), in which case first entry activities will be carried out and once they are completed, the do activities will start again.
The do activities finish on its own; in such case, once the do activities finish it's time to leave the state. So the eventual exit activities are performed and the transition is performed. A valid system should have one or more transitions without a triggering event (if more than one then they should have conditions allowing to uniquely determine which one will be used) that would be followed once the exit activities (or do if there was no exit) completes.
Let's have a more tangible example. Consider a washing machine. There are two interesting states in it, one is filling with water, the other one is drum rolling.
For the filling with water state, one can expect the following activities:
entry: open water valve
do: monitor water level
exit: close water valve
Now, once the washing machine gets into the state, the valve is being open (entry) and immediately afterwards the machine starts the do: to monitor the level of water (as water now flows in freely). Once the set water level for the current program and step is reached, the event "water level reached" is sent, initiating next transition. As a result the do activity is stopped (there is no more point in monitoring the water level) and the exit is carried out (valve is being closed), followed by the transition to the next state (e.g. heating or drum rolling depending on the program stage).
As you can clearly see, in such case the do activity is interrupted once the transition trigger is captured.
For the drum rolling the situation is quite different though. For the sake of simplicity we will have just one *do( activity, with no entry or exit activities:
do: rotate the drum for n seconds with n speed
When the washing machine enters this state, it immediately starts rolling the drum and (unless interrupted by some exceptional event) keeps doing it for the predefined amount of time. Once that time elapses, the do activity interrupts immediately and the transition to the next state happens. In such case, it is the do activity that controls when the next state transition occurs, at least in the typical scenario.
My system has two state machines, one master, one slave. And the states between the master and the slave are not one to one. The possible interactions are as follows.
If the master transits to certain master state, it will notify the slave to transit to certain slave state
The slave may request the master to enter certain master state; if master succeeds, the master will notify the slave to enter certain slave state.
The slave may request certain data from master
What is the proper UML diagram to describe those interactions? Statechart diagram is limited to state transition only and can't describe the request from the slave(either state transition or data); Interaction diagram is limited to class/object and can't applied on state.
You can describe those interactions using two UML state machine diagrams, one for the master and one for the slave. For example, to specify that a transition from state Idle to state Busy of the slave takes place upon receipt of signal Req from master, you draw a transition from Idle to Busy with transition label Req in the slave's state machine diagram. To specify that master sends signal Req when it enters state X, you write entry/Req inside the state symbol of X in the master's state machine diagram.
Alternatively, you may draw elements for sending and receiving signals (see sections 14.2.4.8.2 to 14.2.4.8.5 of UML 2.5.1 specification):
For example, to go from Idle to Busy upon receipt of signal Req with parameter id:
You also described the situation where the slave requests certain data from the master. For this, you need a third diagram (or a textual specification) of the interface provided by the master and required by the slave, for example:
In the slave's state machine diagram, you can call an operation defined in the interface. For example, to call the read operation of master when the slave enters state Busy and store it in local variable x, write entry/x:=master.read() inside the state symbol X.
For an introduction to the UML state machine diagram, please refer to wikipedia
What you describe is the interaction between the master and the slave.
There is no single solution to that and it is really difficult to have at the same picture both all possible states and the logic of the transaction (actually I don't think it is possible at all).
The main diagrams to be considered here would be:
Sequence diagram depicting the process of requesting/changing states (you may have few showing various triggers for the change and use alt/opt to show further behaviour)
Activity diagram depicting how the process of state changing is handled
Interaction overview diagram with state changes being shown at the "activity" level and negotiation between the master and the slave in the "sequence" parts.
Especially the last one is an interesting option here as it combines possibilities of activity and sequence diagrams. Usually it's an overkill but might be the best idea for your specific case.
In addition to those you may also use the state machine diagram (two, one for master and one for slave) but they will not be able to show the interaction between the two entities. It might be useful though to explain what are the available states.
If it is not clear feel free to comment this answer asking for more details. I will try building example of each of those diagrams then (activity diagram example you already have in the answer by www.admiraalit.nl).
According to the state machine below shown in chapter 9.3.3.6 Transition 011-C of the document Precise Semantics of UML State Machines from OMG it's fine to define a local transition from a substate to a containing state.
But what does that local transition T1.3 do when it's executed? I supposed that state S1.2 is left and after that the default entry of state S1 is applied, hence transition T1.1 is executed and finally state S1.1 is entered.
However, the run-to-completion steps table of that chapter shows that after transition 1.3 is executed, the completion event CE is generated and thus the state S1 is left by transition T3:
This left me puzzling, as the UML specification 2.5.1 states in chapter 14.2.3.8.3 Completion Transitions and completion events that a completion event of a composite state like S1 is only generated if all it's orthogonal regions have reached a final state. This certainly is not the case in the state machine shown above.
Now, which behavior is correct? May it be that the run-to-completion steps table is wrong?
The shown sub-state machine uses a so-called local transition (see the link in #Roman's comment). UML 2.5.1 describes a local transition on p. 314
kind = local is the opposite of external, meaning that the Transition does not exit its containing State (and, hence, the exit Behavior of the containing State will not be executed). However, for local Transitions the target Vertex must be different from its source Vertex. A local Transition can only exist within a composite State.
Examples of local transitions can be found on pp. 334 of the UML 2.5.1 specs.
So the sub-state machine will never exit and thus table and diagram do not match. Likely the author made a mistake and meant what I stated in my original answer below.
Original answer:
I never have seen the notation above, but assume that it should picture a sub-state exit (so T3 will be the next transition which complies with the table).
I guess the notation should rather be using a Final like this
shown in fig. 14.38 on p. 339 of the UML 2.5.1 specs.
I supposed that state S1.2 is left and after that the default entry of
state S1 is applied, hence transition T1.1 is executed and finally
state S1.1 is entered.
"T1.3" should lead to "S1.2" being left, "S1" remains active. "S1" is not left and not re-entred because "T1.3" is a local transition.
The only region of "S1" is not finished as no Final State was entered. Thus no completion transition.
May it be that the run-to-completion steps table is wrong?
Yes, I believe it is wrong.
This topic still did bother me despite your appreciated answers, thus I did some further study. On page 31 of the document Precise Semantics of UML State Machines I found this:
Completion of a region activation
RegionActivations never reach completion by being exited either
implicitly or explicitly. There are two ways to complete the execution
of a region.
The general rule is that a RegionActivation can only complete if a
FinalStateActivation (see 8.5.5) for a FinalState owned by the
Region is executed. This leads the RegionActivation to be marked as
being completed (its isCompleted attribute is set to true).
The above general rule is violated only in the situation where a
VertexActivation owned by a RegionActivation is exited and the
TransitionActivation that exits that VertexActivation has as its
target the StateActivation owning the RegionActivation. In this
case, and only in this case, does the RegionActivation that owns the
exited VertexActivation complete.
If I'm understanding this correctly, then rule 2 describes exactly the behavior of the state machine 9.3.3.6 Transition 011-C and in that case the run-to-completion table is actually correct.
Following on the discussion at State machine program design in FreeRTOS - vTaskStartScheduler in a switch statement, I have a state machine with 4 states, each of them with different tasks reading sensor data.
When a sensor data reaches a threshold, its task has to cause a state change.
The idea is to have a superior task which controls the states (and suspends/resumes corresponding tasks) with a switch statement. My question is: how should the sensor tasks communicate the STATE with the superior task?
One proposed solution is to have a set_state function which is called by the event generating task, but I read that having global variables in FreeRTOS is discouraged. I thought to implement it through Queues:
1- Task1 detects sensor threshold, and sends STATE to a Queue.
2- Superior task is blocked waiting to receive data from Queue. When it receives STATE, the switch statement processes the state change.
If this approach is correct, my doubt relates on how and where should be STATE defined (global, or just existing in the stack of each task, or the superior task...)
STATE should exist only where it needs to, 'in' the superior task. I'm presuming you're using C, so declare STATE as a static variable in "superior_task.c" (or whatever it's called). This means it can then only be affected within that file - the C equivalent to a private member variable in C++.
Then, if your inferior tasks need to affect a state change, they post a state change event to a queue managed by the superior task. When the queue is processed, the superior state makes the change to the private STATE variable.
If other tasks need to know what the state is for their own processing, they can use an accessor for the private variable, e.g., State get_state() { return STATE; }. As Martin says though, the other tasks shouldn't need to know the state, as otherwise there's inter-dependencies between tasks that shouldn't exist.