Statement on State Machines Discussion Kevin Cleary 24 Oct 2005
From IGSTK
Statement on State Machines Kevin Cleary 22 October 2005
As you are all aware, we have had many discussions about state machines and how they will be implemented in IGSTK. In the interest of moving the project forward, I had some discussions with Luis and Kevin Gary and am proposing the following for the Monday tcon.
First, by way of background, we decided to use state machines early in the project for these reasons that Luis outlined in “Purpose of State Machines in IGSTK�? on the Wiki. This was a major decision and in some ways I think the use of state machines is one of the defining points of IGSTK. We are breaking new ground here in my opinion and therefore it is not surprising that we are struggling some here.
However, I still believe state machines are worth the effort and we actually have made a lot of progress to date in starting to put in state machines at the component level. From my discussions with Luis and Kevin Gary, there seem to be three major issues with the state machines:
1) Our design is getting complicated. This will make IGSTK hard to use if we are not careful.
2) We have not solved the problem of how the state machines will interact together. This may be the major technical challenge of IGSTK in my opinion and it seems we do not have examples of other systems that have been built with state machines to go by. We can put state machines in the components and in the application no doubt, but how will they interact together?
3) We have not agreed on a mechanism as to how the state machines will communicate information with each other and how we will get information into the state machine. Luis has introduced the idea of using an event/observer mechanism to communicate information (similar to the slots/signals method of Qt) rather than using Get() methods, but there is disagreement still as to whether this is a good solution.
Therefore, at this point I propose the following:
1) Regarding the design getting too complicated, this is just something we need to pay attention to as we proceed. I would agree with Luis that code safety is a higher priority than coder convenience, but I would not want to build a toolkit that is so complex no one can use it. However, we can have complexity in the internals of core components provided that the interface is more straightforward. We can also help here with programming examples and providing a few well known patterns of interaction as is the case with most any control framework.
2) Regarding the interaction between components, the dispatcher seems like a reasonable solution. There are some issues with the dispatcher implementation first suggested by Luis and Andinet at the tcon last week, but in general this seems to be a good path to pursue. I recommend we discuss this a little more on Monday, but plan to pursue this as the solution for interaction between components in the next release of the software.
3) Regarding how the state machines will communicate with each other, I am not ready to sign onto the event/observer mechanism at this point. I think this should be discussed more at the board meeting / one year review on Nov. 10. For now, I am OK with people using Get() methods to communicate and I am OK with Luis/Andinet experimenting with the event/observer method to see how it works in practice.
Therefore, at the tcon on Monday, I will propose we move forward this way. I will limit the tcon to two hours, with the first hour for discussion of these issues and the second hour to make an action plan and summarize the outstanding issues. We have some other things to discuss such as creating consistent design patterns in the state machines, the use of exceptions, and state machines in base versus derived classes but these are lower level issues to me at the moment and we will see if there is time to discuss them on Monday or not.
I certainly appreciate everyone’s input on these issues and I feel we have a very talented technical team, so it is natural that there may be some differences of opinion. But I also feel that we need to move the project forward so that is why I have stepped in (of course, if I have to start coding again, then we are really in trouble and I recommend you all abandon ship!). Any comments or suggestions are welcome.
(end)
