I'm trying to model a state machine which reuses a state in order to reduce complexity.
I've got three states: State A, B and X.
My state X can either be entered via a transaction from state A or B.
State X includes multiple substates with lots of complexity and I don't wont to implement it twice.
After the process in state X is completed I need to transition back to back to state A or B based on which one was the previous state.
Is there a elegant way to solve this?
State X includes multiple substates with lots of complexity and I don't wont to implement it twice
Define a submachine corresponding to your state X and in your current machine use submachine state to instantiate it where you need
See ยง14.2.3.4.7 Submachine States and submachines page 311 in formal-17-12-05 :
Submachines are a means by which a single StateMachine specification can be reused multiple times. They are similar to encapsulated composite States in that they need to bind incoming and outgoing Transitions to their internal Vertices.
...
NOTE. Each submachine State represents a distinct instantiation of a submachine, even when two or more submachine States reference the same submachine.
A SubMachine will help you to reuse several time part of your state modelling.
But if you want to be able to enter into your state X from A or B and then retun to the previous state, ShallowHistory Would be a good idea.
In the following state machine, I modeled a SubMachine X referenced by both states X1 and X2. I also wanted to model the fact that state X2 in processed after A or B and then next state if the previous one.
Another solution consists in playing with transition guards or events/triggers. You must keep in mind that transitions are triggered when specific events occurs or when its guard is true cf. following screenshot.
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.
I am working my way through an MIT OCW course, Introduction to Electrical Engineering and Computer Science I, in which state machines are employed. I have noticed that the course instructors do not draw state transition diagrams for most of the state machines they discuss.
One problem is to design & Python code a state machine whose state is the input from two time intervals in the past. I think that this is an infinite state machine for which a state transition diagram might be useful for getting the general idea while showing only a few of the states.
I am wondering if a state transition diagram can be drawn for such double delay machine. All the examples, so far, have a transition line emerging from a state bubble marked with an input and the resulting output and then pointing at the next state. For a double delay machine the input of consequence is entered two time periods previous. The problem instructions state that all state memory for the machine be in one argument. No mention is made of input memory, which I would think necessary.
My questions:
Can a state transition diagram be drawn for this state machine?
Is it necessarily the case that input memory be a part of this design?
It is impossible to draw a diagram since the set of all possible states includes any value of any data type, given in the example for the (single) delay state machine in the readings. So the number of possible states can't be defined. See Chapter 4: State Machines.
In the problem description it states that:
It is essential that the init and getNextValues methods in any state machine not set or read any instance variables except self.startState (not even self.state). All memory (state) must be in the state argument to getNextValues. Look at the examples in the course notes, section 4.1.
So the state is all the memory you need. There is no reason not to use an array as state to keep the last two inputs.
First we save both values in memory (state)
class Delay2Machine(StateMachine):
def __init__(self, val0, val1):
self.startState = (val0, val1)
Following the super class SM step function implementation also given in the readings:
def step(self, inp):
(s, o) = self.getNextValues(self.state, inp)
self.state = s
return o
The output will be the first of the values saved in memory, and the state will be updated to include the new input
def getNextValues(self, state, inp):
return ((state[1], inp), state[0])
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.).
Let's assume we have the following state diagram (from UML reference book) which describes states of some object:
If object now is in state Y and e event is triggered will the object come in state Z after coming to final state, assuming that after e event there are NO more events? I am asking as for me it is not quite clear.
Citing Superstructures for 2.5 (FinalState):
14.5.2.1 Description
A special kind of State, which, when entered, signifies that the enclosing Region has completed. If the enclosing Region is directly contained in a StateMachine and all other Regions in that StateMachine also are completed, then it means that the entire StateMachine behavior is completed.
That means in your concrete case: when e happens the state X is finalized and transfers unconditionally to z.
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]).