On 8 October 2010 14:48, Marnen Laibow-Koser <[email protected]> wrote: > Colin Law wrote: >>... >> I think we are just going to have to agree to differ on this one, > > I would rather not do that. In general, that's a sign that more > discussion is needed, as one or both of us is probably missing > something. Certainly I'm learning a lot from this discussion. > > However, I'm perfectly willing to start a new thread for this.
Done I think I would like to start again as I realise (having been forced to defend my corner and think more about what I am rabbiting on about) that it not so much _when_ the models are identified that is the issue for me but _how_ they are identified. To go back to your original suggestion: > when I > put together an application, I usually think first about how I want it > to present itself to the user and what the user should be able to > accomplish (and write Cucumber scenarios accordingly). Only as a result > of making those scenarios reality do I write model classes or anything > else. I read into this (possibly incorrectly) that the purpose of the models is purely to satisfy the scenarios and they are identified by examining the scenarios and generating a set of models to satisfy them. I think that that is too narrow a view to take, particularly considering that we are in the first phase of a project and we know there will be many modifications and extensions to the requirements in the future. Generally an app is in some sense simulating or mapping things in the real world (or some conceptual world), users, shopping carts, products and so on. I suggest that one should examine the scenarios and identify the underlying objects in that real world without worrying too much about the _details_ of the scenarios. The models then represent those objects and one can work out how to satisfy the scenarios using those models. I believe this should provide a better base on which to build the app. Scenarios will be modified and added to dramatically over time but the underlying objects in the requirements are less likely to change (I don't mean that their behaviour will not change, but their existence). If the identification of the objects is correct (or optimum or whatever) at the start then this will minimise the effort in tracking the changing requirements. I am still not sure that I am expressing myself very well. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
