A Finite State machine is in state s. When event e occurs a state change to state t is triggered.
My colleague who is doing the user interface insists that he has to be capable of displaying the device statii corresponding to event e while state s is on display, whereas I say that is not necessary. The user interface needs to display the state t with the device statii corresponding to event e because the FSM has already changed state by that time
He is effectively insisting on two UI states for each of my FSM states: one showing state s with the conditions of event e, and the other showing state t with the conditions of event e.
The state change is as near as dammit instantaneous: as long as it takes to write a new value to an 8 bit variable, and certainly takes a lot less time to do than transmit the new FSM state and device statii using a SOAP interface.
I say he is mistaken. Anyone else have an opinion?
"Working" software has only unobserved bugs. (Parroty Error: Pieces of Nine! Pieces of Nine!)
Seriously: If you value it, take/fetch it yourself
Comments
Seriously: If you value it, take/fetch it yourself
Seriously: If you value it, take/fetch it yourself
Seriously: If you value it, take/fetch it yourself
He says he still reads the message to see if the device statii are what he expects them to be, so he's still got to inspect the device statii anyway. I don't mind if he wants to raise some kind of error if there's a device in the opposite state to what he thinks it should be (they're all OFF or ON).
Seriously: If you value it, take/fetch it yourself