You know your team members are really catching onto this whole model-based way of thinking when they pull your leg over a few drinks in a bar and say (tongue in cheek): "So Nihit, the 'Action' of having this drink will take me from a 'Sober' state to a 'Drunk' state, right?".
Yes - exactly - it will (or maybe we need to accommodate degrees of drunkenness as well - not everyone is drunk after a single drink!?) and for completeness sake you can even have an Action Parameter for the type of drink being passed into the "DrinkAlcohol" action! Isn't that neat!? :)
Anyway, here's wishing everyone a wonderful 2007 ahead. Happy New Year!
I happened to have a look at your talk on Model Based Testing. It was really a learning example.
1. The whole talk seemed to revolve around use of model based testing for white-box testing.
2. Creating a model for on the BasketManager class was really challenging. But I feel it was because the context for creating model was not based on BasketManager class itself (as Stop Watch above). Rather, you started with a test case where BasketManager was just a part of the scenario.
I think MBT is not just coming out with FSM for some object but it could as well be an Activity Diagram for a Use Case. In fact, I feel your test case for BasketManager example was best fit for something explained here http://www-128.ibm.com/developerworks/rational/library/04/r-3217/index.html.
I would like to know what criteria do you use when you settle for creating a model for something and not consider other way of looking at the same thing?
And the event of passing time will slowly move you from a state of drunk back to a sober state. :)